Out of order policy execution..

[ImAMacGuy]

I'm seeing occasional issues where a machine going through our self service provisioning process occasionally get interrupted by our 'catch all' post deployment pushes (designed to catch machines that for whatever reason didn't get an app install/update when we were pushing out during the change request - it's on a recurrent check-in with a smart group of the app not being installed).

 For this particular app it cuts off all internet traffic until the user signs into the app and during the deployment as the last application installed for this reason, but we're seeing our 'catch all' policy trigger on some devices while the provisioning policy is running and install the app before the other apps are done.

What would be the easiest way to put a check in to prevent the catch all policy from triggering while the device is provisioning? 

[scottlep]

Create a smart group for computers enrolled less than one day, use that as an exclusion. Another option is to create a way to tag a Mac as enrollment complete by dropping a file somewhere at the end of the enrollment process. Create a smart group for enrollment complete/incomplete based on this existence of this file, use those groups for scoping/exclusion, etc.

[AJPinto]

You can have a policy that runs that places a flag file (just a random file in a directory) to denote the configuration has completed. Then an extension attribute to read the existence of that file with a smart group to know what devices have that file. Target your network security tool at the smart group that says the configuration finished due to that flag file existing. You can also reverse this process and know that devices that dont have that flag did not configure correctly.

[cdev]

Payload-less packages work well too, as you get an installation receipt that shows in Jamf to identify those devices that built successfully and can use Smart Groups to find them