Policies get applied in alphabetical order?

[metalfoot77]

I have a bunch of policies that install software and a few that do some maintenance type things like executing docutil and wallpaper. I would prefer to have these maintenance type policies run last and after all the software policies finish up. I am noticing that policies tend to apply in alphabetical order based on the policy name. I have attached a screenshot showing how over a couple of hours, these policies applied to one machine.

How are people pushing lots of policies in a managed order? Are you simply naming them "zzz - my policy" just to force them to run last?

[Sandy]

You could number them, numbers would go before letters I believe

If it is critical that a specific policy must come before or after another policy you could use a custom trigger to trigger policy B
Policy B is set to a custom trigger: gonow (or whatever you want)

Policy A calls Policy B using a command line in the policy: jamf policy -event gonow

This goes in Policy>Options>Files & Processes>Execute Command

[mm2270]

To jump off of what @Sandy mentions, it sounds like you're doing a sort of "set up" process where you have a new Mac just enrolled and are setting it up with a bunch of default software and settings. If so, another recommendation is to use a single "set up" policy that runs a script which calls all the other set up policies individually in the order you want them in, by their policy id or a custom trigger. (Correct scoping still applies here)

Doing it that way, you can get quite sophisticated in making sure only the policies you need, based upon on the fly conditions, get run on those Macs. For example, the setup script could check the OS version and run the appropriate policy for that OS, if there is one, or check the FileVault status and run the FV2 enable policy if needed.
Just some examples.

The bottom line is, either chaining policies like mentioned above, or running them from within one larger policy script, are the only ways to ensure the policies run in the exact order you want.

[metalfoot77]

Thank you both very much. This helps me immensely!

[metalfoot77]

@mm2270 So just to clarify, I have, let's say, 10 policies for software installs. I make a script in Settings->Computer Management->Scripts that calls out each of the policy ids in the order I want. Just like so...

#!/bin/sh

jamf policy -id 30
jamf policy -id 1
jamf policy -id 45
jamf policy -id 58

Then I create a new policy that just calls the new script above. My questions is then how would I go about scoping this correctly so that a machine doesn't now get each individual software policy in addition to the "all software" policy I've set above?

[mm2270]

Hi @kricotta Yes, something like that. I would suggest putting the full path to the jamf binary in the commands though, just as a precaution.

As for the scope, I would take whatever scope you have set up right now for all those 10 policies and add the same Smart Groups or whatever to that one policy. As for making sure the individual policies don't also run on those same machines, that's a little trickier. Are you collecting inventory at the end of the policies to make sure machines fall out of any Smart Groups? In general, once it runs in the one large policy, it should not run again on those same Macs for the individual policies, as long as you're using inventory data as the scoping, and those policies collect new inventory.

I would also look at making some way to have that one "set up" policy run first before anything else gets run. Like maybe use the enrollment complete trigger (assuming it works on the version of Jamf Pro you have) or some other method, like a tech calling the policy manually in Terminal on a freshly set up Mac. How you do that is going to be kind of individual, so I don't know if I can make any more specific recommendation than that.

[metalfoot77]

@mm2270 Alrighty, I have created the master script as I want it and have set the trigger for it to run after enrollment is complete. I also included the full path to the Jamf binary as you mentioned, thanks for that tip too.

The rest of my individual software policies I have just have triggered at "check-in" and to run once on a computer. I am not currently running an inventory collection on each software policy as I'm not sure if I need to since we primarily use static computer groups (these are lab computers). However, I do have a separate policy called Update Inventory which is scoped to all managed machines and runs once a week at check-in. Not sure how that factors in but was recommended during our Jumpstart a few weeks back.

I am in the process of wiping a test machine and will enroll it to see if it triggers this "Install All" policy as I expect it to.

[fredb]

I am very new to Jamf and am having the same issue getting our Policies to execute in a specific order.

I want to try the suggestion of calling the policies in a script as you mention above, however I can't seem to locate the Policy ID.

Where do I find the ID for each Policy?

[jrippy]

Alternatively, you could set up detection smart group (App Installed, Package installed by Casper/Jamf, etc.) and structure your scope such that policy B doesn't fire if computer is in smart group A.
I'd say a master script is still probably more predictable for complex multi-step processes, but this should work as well.

[wesleya]

I would definitely recommend using meaningful custom triggers. An example of what we have implemented is below:

#!/bin/sh

jamf policy -event BindComputer

jamf policy -event SetARDField3 #Sets ARD Field 3 to staff or student

jamf policy -event AppInstall #Installs PKGs (Chrome, Firefox, Flash, Word, etc.)

jamf policy -event ConfigureComputer #Runs config scripts drops DMGs (yuck) where necessary

exit 0

Some of these call into a "family" of policies with the same custom trigger (AppInstall and ConfigureComputer), and they really do work. Custom triggers have been crucial to our DEP deployments.

Inventory can get kind of tricky here, as Jamf puts it at the back of line (will update inventory once queued actions are complete), but I would say less is more. Maybe add a recon at the end, and if you see these running over and over, back off the execution frequency (we're going to have to go from Ongoing to Once per day for a lot of these).