Policy w/ Exclusion based on Package being Installed

[dan_berlyoung]

I have about a dozen policies installing Adobe CC applications (PS, Il, ID, etc.) that then exclude themselves when the "Application Title" returns true for that app. They all work great except for one inefficiency.

If the process is interrupted and starts over (the system gets turned off over night for instance), it starts reinstalling all the packages because the inventory is stale and Jamf doesn't want to update the inventory until all policies are run.

Is there any way I can force an inventory update after a policy runs? I have the "Update Inventory" box checked in the Maintenance tab but it does't to it after the policy finishes.

Is there an alternate way to tell if the package has installed w/o an inventory update? Would sensing the package install via Casper work better?

Thanks in advance!

[akw0045]

You could try making a startup or log on policy to run Sudo jamf recon. This should fix the computer gets turned off mid install issue.

[MrRoboto]

If the process is interrupted then I would not expect the applications to function correctly. Either missing supporting files or crashing during use.

Update Inventory under Maintenance in Policies usually works ok. I only see it skip this step when the network connection drops out.

Alternatively you can change you exclusion Smart Group criteria from "when Application Title is found" to "does not have Packages Installed By Casper".

[dan_berlyoung]

I should have been clearer when I said "process is interrupted." The process I was referring to was the installation of all 12 packages are scoped. If, for instance, 5 packages installed successfully (with 7 to go) and the system was shutdown, when it starts back up again, it starts from the first package again. Reinstalling all 5 before going further. The inventory doesn't get updated to let it know that they are there and do not need to be installed. If I could force the inventory update after each policy/package, then it would not reinstall them.

[MrRoboto]

Ok that makes sense. You can try separating the policies create one per Adobe package, scope to target computers, exclude computers with the app or package already installed via smart group, run once per day, do not include inventory in each policy. Create a final policy to run inventory, name it ZZ Inventory so it runs last based on alpha order, set to once per day.

You could also build this out to a single Adobe policy that calls other policies based on a common custom trigger, and includes an update inventory. Scope this to all target computers, run once per day. The other policies would be scoped to all computers, excluding computers with package already installed based on smart group, ongoing frequency, custom trigger.

[dan_berlyoung]

I have them broken out into separate policies as you suggest. Each one has the "update inventory" box checked but Jamf does not do the inventory at the end of each policy. If it senses multiple policies, it only updates the inventory after they are all successfully executed. If that process gets interrupted and only executes some, then it starts all over and reinstalls any packages already there.

This is a policy set that I use to set up new machines so I would like to have them execute at first startup so running once per day is not optimal.

Having them run as separate policies called from a single policy is a possibility that I need to think more about.

[MrRoboto]

Update Inventory after each policy package isn't recommended. Once after the main policy that calls the sub policies via custom trigger is okay. Alternatively you can use a short script that runs the jamf policy customer trigger followed by a recon.

To prevent policies from re-running unnecessarily try changing smart group criteria. Use the 'packages installed by casper' option. This goes based on the receipts written to /Library/Application Support/JAMF/Receipts. If a package installer gets interrupted then a receipt will not be written.

You can have the main policy triggered at startup or check-in, frequency can be what setting is best for your environment. I recommended once per day in case a policy fails it won't keep trying every hour or so.