How to deal with wiping computers and avoid the 'Once per computer' execution frequency restriction

kdowley
New Contributor

Hey all,

I'd like to be able to wipe a computer and start fresh with a new user, however I keep running into issues where policies that have a 'once per computer' execution frequency don't get triggered due to them being triggered before the wipe.

I can't delete the computer in the jss because I need to preserve logs and any data attached to the physical machine, like purchasing info.

If I use 'Once per user' I'm worried about running into conflicts where a single user has multiple computers.

I don't want to clear logs individually because that is not a scalable solution.

Get my drift?

1 ACCEPTED SOLUTION

mm2270
Legendary Contributor III

This has been mentioned on other threads, but there is a specific command you need to run on the device to reset the policy history.

jamf flushPolicyHistory

You just need to include that in a script that would run against the Mac. It will instruct the JSS to flush the entire policy history for that one Mac. (There's no global way to do this for a batch of machines at once) Then all Once per Computer policies will execute again at the next check-in or trigger, etc.

View solution in original post

2 REPLIES 2

mm2270
Legendary Contributor III

This has been mentioned on other threads, but there is a specific command you need to run on the device to reset the policy history.

jamf flushPolicyHistory

You just need to include that in a script that would run against the Mac. It will instruct the JSS to flush the entire policy history for that one Mac. (There's no global way to do this for a batch of machines at once) Then all Once per Computer policies will execute again at the next check-in or trigger, etc.

Volker
New Contributor III

I'm very new to Casper myself, and our shop is VERY imaging-heavy, so we've come up against this.

One thing that's helped is considering what the policy itself is doing; for example, let's say we need to rename a folder on newly-reimaged boxes. What you could do there is:

  • write a Casper extension attribute that returns whether or not the folder's got its old name (i.e. needs changing)
  • create a Casper smart group whose membership is determined by the state of given client's (above) extension attribute (a "to-do" list group, as it were)
  • set the scope of the policy to that smart group, and the execution to ongoing, with an appropriate trigger

So as clients are added to the smart group, the policy applies to them, the job gets done, and then they no longer meet the criteria for being in the smart group, and so the job doesn't try to run anymore.

This way, you aren't just applying policies blindly. That can sometimes get you (me!) into problems.