Best practices for macOS software installs? (Ongoing, once per computer, and so on)

[rahern]

We are installing Adobe Creative Cloud (the self service installer), Microsoft Office, and a few other things on all of our Faculty/Staff Macs. For new Macs, it's pretty simple, install all the software once per computer when they enroll.

For computers that we're repurposing though, we want the software to install again once we do a full wipe. I don't think I want to choose 'ongoing' for the trigger though as if it fails, it just keeps trying. 

So for your policies that install software packages, what trigger do you use to ensure everyone, new Mac or repurposed, gets the right software?

[danitree]

Hi @rahern,

What is you main concern with ongoing? You could try to make different Policies with the apps you want installed in those Computers with a Scope based on a Smart Group that don’t have the apps you want installed and let them on a recurring check-in trigger.

That would install at its own pace and won’t run if it doesn’t meet the criteria of the Smart Group.

They might be many other ways. You could use also for example DEPNotify along DEPNotify Starter with a trigger of Enrollement Complete on Ongoing. That will guarantee you to have certain apps on a new device and wiped when an account is created.

Hope it helps.

[williamsad]

You can have Jamf clear the policy logs after a wipe and re-enrollment within Settings -> Global Management -> Re-enrollment so that the "Once Per Computer" frequency applies again.

As for me, I use DEPNotify to install needed apps with the Enrollment Complete trigger and then I create smart groups for the important apps, like suggested by @danitree, but slightly different. One bug that I have noticed for awhile is that randomly some computers will report back as having 0 applications installed. That would cause the application to reinstall again even though it really only needs inventory to be updated again so that it falls out of the smart group. Instead, I run a script that will check for the application. If it is there, it just updates inventory. If it is not there, it will install the application based on a Custom event trigger.

#!/bin/bash
#Paramater 4: Application Name
#Paramater 5: Custom Event Name

if [[ $4 == "" || $5 == "" ]]; then
	echo "One or both paramaters are missing"
    exit 1
fi

if [[ -d "/Applications/$4.app" ]]; then
	echo "$4 is installed. Updating inventory."
    jamf recon
else
	echo "$4 is not installed. Attempting to install."
    jamf policy -event $5
fi

exit 0

I try to avoid having Ongoing policies that contain large packages, if possible.

[AJPinto]

I second  @danitree automate this. Ongoing can be setup to stop after 1, 2 or 3 failures. You can also set the policy to not install if certain conditions are met. 

It is best to make the policy ongoing on recurring check in, run the inventory update payload and set an exclusion to prevent the policy from looping. The best exclusion is a smart group that checks for the applications presence. The added benefit of this is it enforces persistence. If the user deletes the app they will be removed from the smart group which will remove them from the exemption to the policy, and the policy will run again installing the app.

If you don’t want any kind of persistence and don’t want to deal with smart groups. Set the policy to ongoing and run once per device. Make sure to go in to Settings > Global Management > Re-enrollment > and check clear policy logs on computers so the policy will run again if the device is reprovisioned.

Build the policy as usual. Package payload, and Files and Processes, everything else is optional.

Run an inventory update with a payload. You want this so JAMF knows the application is installed and can act accordingly without having to wait for your weekly check in.

No idea why I have this one set to run recon as a command. Its too early to think about it. Use the maintenance payload and inventory update instead.

Now for the important stuff your scope. Set your target up however need to, in this case I have it set to all devices.

Now for what you need, the exclusions. This is what will prevent the policy from running over and over again.

In my example.

• We are installing Sentinel One with a Recurring Check-in, and a custom event to ALL devices once a day.
  • When a device is enrolled support uses a configuration policy that will run the custom event. We have both just so it’s easy to call at enrollment and support does not have to wait on things to happen.
• Sentinel One will install, and the policy will update inventory, so we know Sentinel One is installed on this computer
• If the devices meets any of the exclusions, one of which is if Sentinel One is installed it is no longer targeted by the policy.
  • If someone runs the custom trigger and Sentinel One is installed, you just get an error back saying it’s not in scope for the policy.
• Due to the auto check in if someone somehow removed Sentinel One it would just reinstall at next check in which is really good for a security tool like this.