Why are policies skipped sometimes?

[boberito]

I have 3 enrollment policies set up to run on machines enrolled through a PreStage enrollment via DEP.

I'd say I can count on 2 of the 3 always being run with it going 3 for 3 only sometimes. But for example, I just did a test with a machine and it ran 2 of the 3. The one is just left saying "Pending..."

Is this something that happens to others? A bug? Or something I can potentially figure out a workaround for.

[CasperSally]

I'd suggest using the enrollment trigger to start one policy that contains a script.

In that script you can call other policies via custom triggers and time out everything as you want it to happen, i.e. set time zone before binding, etc.

It seems to work pretty well in my experience.

[mm2270]

I'd second the approach mentioned by @CasperSally. A script that calls the policies by either their IDs or custom triggers in the order you want them to run will work best here. Relying on all necessary policies being called by the Enrollment trigger is a recipe for problems. It's fine for a few policies, but when you start getting to 3 or more, you're bound to see some random issues like this.

[Look]

If these are existing machines (aka re-enrollments) you might find the deletion of policy and other logs is taking too long and the machine is not in scope for the policy at the time of trigger execution. If the policy is set to run-once and the logs are not yet deleted the JSS thinks it has already been run, by the time you look at it in the JSS the deletion has completed so it becomes pending, but of course by then the trigger is no longer being called.
You can confirm this by deleting the machines from the JSS first, if this fixes it then thats the likely cause. We have basically the same thing happening in our environment, although it wasn't enrollment triggered but a custom trigger because it was being done via a script I simply put a two minute pause in the problem went away as the JSS had time to delete the information before checking elligibility for the specified trigger.
The underlying cause (in our environment at least) appeared to be the absolutely massive user and location data you end up with when you have had a machine in a JSS for a while as the issue doesn't happen with devices that have only been in the environment for a short while.

[gachowski]

We are just like @mm2270 and @CasperSally !!!

A script that calls the policies by either their IDs or custom triggers in the order you want them to run is the best solution and it makes troubleshooting easier too!!!

C