Skip to main content
Solved

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

K
Forum|alt.badge.img+3

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?

Best answer by mm2270

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 original
    Did this topic help you find an answer to your question?

    2 replies

    mm2270
    Forum|alt.badge.img+16
    • mm2270
    • Legendary Contributor
    • 7880 replies
    • Answer
    • July 2, 2015

    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.

    V
    Forum|alt.badge.img+3
    • Volker
    • New Contributor
    • 15 replies
    • July 3, 2015

    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.

    Reply


    Most helpful members this week

    Terms & ConditionsCookie settingsAccessibility statement

    Cookie policy

    We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

     
    Cookie settings