Flushing policy question

[mconners]

Hello Everyone,

We are about to begin our mass deployment of Mojave and all the updated apps. Over the past 6 months, I have created a very nice workflow that utilized a script to trigger the events to begin. If I run this via Jamf remote, it works really well with the one exception of generating a false positive error. As it triggers the next policy to begin the downloading of the OS installer and wiping the drive, the original script never really ends and we see an error occurred in the casper remote logs. I can physically see the Mac running the OS installer just fine.

Consulting with Jamf Support, we have created a new policy to do the same thing so we can do this in mass. The problem here is, once the computer is wiped and reset and finally re-enrolled, this initial policy status is flipped back to pending, meaning it will re-run and cause the process to begin again.

Is there any work around to NOT having this one policy flushed? I have it set to run once per computer but it doesn't matter if all the policies are flushed.

Thoughts?

[mm2270]

So, are the Macs that will be running this already on Mojave, or are they on an older OS version to start with? It sounds from your post like it's the latter. If so, then I would think simple Smart Group scoping to make sure the "upgrade" policy would only get scoped to Macs not already on the OS version you'll be deploying. In that way, the machines that get go through the upgrade successfully will get dropped from scope, at least once they submit an inventory collection after the upgrade.

Would that solve your issue?

[bramstedtb]

I don't know about not having a single policy log flush, but you could create a smart group of last enrollment after, and put the date you start this process. Then add that group to the exclusions of the policy. That should prevent the policy from re-running after a machine is wiped.

[mconners]

@mm2270 and @bramstedtb your ideas are BRILLIANT!! I never even considered the scoping piece. Yes, we are wiping and resetting everything to Mojave, so I can configured a smart group for the 100 computers in rooms X and Z with High Sierra, then when they are wiped and reset, they will fall out of scope and be ready to go. Thank you!!

[mconners]

Hey @mm2270 I am building this concept out as you mentioned, very cool. Let me ask, once I have all of our labs over to Mojave, how would you propose I scope a smart group in the future for a simple wipe and reset from Mojave to Mojave? I suspect if we find a specific lab/room computer enrolled from a specific day and before, this would cause any newer enrolled computers to drop out of scope.

[mm2270]

@mconners Would you want this wipe and reset policy scoped to any Mac already on Mojave, as a just in case they need it sort of thing, or do you feel these would be handled on a case by case basis? If there's a way these Macs can be added in to the policy scope on an as needed basis, then you can use a Static Group to add to the scope, and just add Macs to the Static Group as needed.

Or, one other thing I've done is use an "enrollment" style Self Service policy where it just does something simple like drop a hidden file on the Mac, or change an entry in a plist when the policy is executed. This can be picked up in an Extension Attribute looking for that file or value, etc. and then use that to build a Smart Group of Macs that have enrolled into the upgrade or wipe/reset or whatever. The actual policy would then show up for them in Self Service once inventory is collected.
And, once it actually gets wiped, it would fall out of scope again because the hidden file or setting is removed.

[mconners]

Thank you @mm2270 these are some great ideas. We are going to use a mixture of ideas here to create an even more automated workflow. We are considering creating smart groups for all of our lab deployments AND based on the enrollment date. When we need to erase and install a lab in the future, we simply move the date of the enrollment. This will catch those computers and re-run automatically without us really doing much.

Our automated workflow is really slick, but this was the missing piece to automate it overnight for a fresh start in the morning.

Now, if we can get Apple to allow those of us using DEP to skip past the United States location screen, US keyboard screen and accept remote management screen, as we have remote management as mandatory, it would be perfect.