Best trigger for self service?

[pchrichard]

We're in the middle of building a prototype MacOS build, when packages are deployed and made available in self service, they don;t reappear after the Mac is wiped and rebuilt.

I also have some policies which seems to apply twice, for instance adding self service into the dock, if the self service app is open, it seems to add it again leaving two dock shortcuts in place?

What's best practice for triggers in this case to ensure policies/deployments only occur once, but are available to machines after their state changes?

[arivera]

Could you say what is the way you currently have it setup right now such as trigger, frequency and what not? For myself when I want something on self service that might be ran more than once I just setup ongoing frequency but I’m not sure what you want to accomplish since there isn’t a real way to trigger a policy based on the computer being wiped as far as I know unless you were to delete the record of the computer from the jamf pro server.

[mschroder]

We use smart groups to exclude Macs that have an app installed already, so that the Self-Service does not propose these apps again. This requires that the inventory is updated after each install or removal via the Self-Service, and of course also after the Macs have been rebuild. For most policies we set the frequency to 'Ongoing', so that users can de-install and re-install at their leisure. In a few cases we have set the frequency to 'Once per day' to 'hide' the policy faster from the Self-Service display after it has run.

[pchrichard]

Ongoing frequency seems to what I need for the self service apps, but I have other packages deployed, such as antivirus and asset inventory which only install once, and never re-attempt installation after the machine is rebuilt unless I flush the logs - this won;t work for us in terms of the intended workflow unless there's a better trigger, or a way to flush the logs for all installation during enrollment.

[mschroder]

I don't understand what the problem is, just use one policy per app and select the appropriate frequency.

[stevewood]

@pchrichard You'll want to add a line to your provisioning process, early on in the process, that flushes the policy history. There is no need to delete a device from Jamf for a re-deploy, just add /usr/bin/local/jamf flushPolicyHistory to your process and that will clear all policy history for your "Once per" frequencies.

[pchrichard]

@mschroder

What would the ideal appropriate trigger and frequency be for something like corporate antivirus installation, to ensure the policy applies after the machine is wiped and re-enrolled?

@stevewood

Is it possible to add a script to the pre-stage enrollment process?

[pchrichard]

I found this in the guide:

https://docs.jamf.com/10.10.0/jamf-pro/administrator-guide/Re-enrollment_Settings.html

Presumbly enabling this will force policies to re-apply?

Clear policy logs on computers

This setting clears all information from the Policy Logs category on the History tab in computer inventory information during re-enrollment with Jamf Pro. For more information about the policy logs for computers, see Viewing the History for a Computer.

In addition, this setting clears the logs for a policy for re-enrolled computers that have run the policy. For information on viewing and flushing logs for a policy, see Managing Policies.

When the computer is re-enrolled with Jamf Pro, any policies that the computer is in the scope of are re-run on the computer at the policy's next trigger.

[mm2270]

Yes, that setting will clear policy logs. Check that option and on any re-enrollment, a machine will re-run any previously run policies, regardless of the frequency of the policy. Note however, that scope still applies, so if you have a Smart Group looking for the absence of application X, and the system already has application X installed (assuming it was not wiped that is), then the policy won't run again.

If you're wiping the systems, then everything should run again on it when that option is enabled.

[stevewood]

@pchrichard I forgot about that setting. That's the better way to handle this rather than the flushPolicyHistory setting.

As far as your question about A/V software installation, we handle that by having a policy that is set to Ongoing, scoped to all computers, with an exclusion smart group of "AV Software Installed".