Posted on 09-03-2021 06:52 AM
I made two polices based on this posting:https://www.jamf.com/blog/reinstall-a-clean-macos-with-one-button/
I've been able to get them to work a few times by purging the logs and waiting until check-in but since yesterday they don't seem to be functioning anymore and I'm trying to figure out why.
The machine in question is online (and located about a foot from me) and while it does have Big Sur on it these policies have previously worked to download, wipe and reinstall Big Sur and then start the enrollment process.
I've set the scope to specifically this one test machine as I previously have done but the logs don't show any changes. I was wondering if anyone has any ideas. I'd like to be able to re-apply these policies when needed without any issues.
Posted on 09-03-2021 07:52 AM
The erase policy will have to run after the policy that caches the Big Sur installer. You can try running them manually from your test Mac in the correct order and see if something shows the problem.
If Terminal reports no policies are found, then verify the Scopes for each policy. You may need to adjust the criteria of your group if you're scoping to a group.
Posted on 09-03-2021 08:07 AM
Well part of it started working. The installer/erase policy failed but makes sense because the download hadn't completed. I'm waiting for this policy to try again.
Has anyone ever run into these two policies creating three Macintosh HD's? Two show the standard contents and one is blank. This is on the desktop which has "show disk" enabled.
09-08-2021 05:10 AM - edited 09-08-2021 08:45 PM
Hello @MBlank,
I am having the same problem, but not necessarily have access to the user's machine so re-enrolling might not be an option now.
Btw, where can I find a policy's ID so I can run sudo jamf policy -id xxx ?
Cheers
09-08-2021 05:12 AM - edited 09-08-2021 08:44 PM
..
Posted on 11-24-2021 02:13 AM
I found the Policy ID in the URL (https://xxxxxx.jamfcloud.com/policies.html?id=7&o=l)
Posted on 05-18-2025 02:39 AM
Yeah, this kind of issue pops up now and then. When a policy just sits in "Pending," even after a log purge and check-in, it usually means something’s out of sync. I’d start by forcing a full recon on the machine using sudo jamf recon
just to be sure the inventory is fully updated. Also, double-check how the trigger is set—if it’s on "Recurring Check-In" and nothing’s happening, try changing it to something like "Custom" and run it directly with sudo jamf policy -id [policyID]
to see if that kicks it off. If it’s scoped to just one test machine, you might want to un-scope and re-scope it to kind of “refresh” the link. I’ve also seen cases where moving the Mac to a new static group helped the policy fire properly again. And if nothing works, removing the Jamf framework (sudo jamf removeFramework
) and re-enrolling the Mac tends to fix weird behavior like this. Sometimes the policy database on the client just needs a hard reset.
Posted on 05-18-2025 02:41 AM
Yeah, this kind of issue pops up now and then. When a policy just sits in "Pending," even after a log purge and check-in, it usually means something’s out of sync. I’d start by forcing a full recon on the machine using sudo jamf recon
just to be sure the inventory is fully updated. Also, double-check how the trigger is set, if it’s on "Recurring Check-In" and nothing’s happening, try changing it to something like "Custom" and run it directly with sudo jamf policy -id [policyID]
to see if that kicks it off.
If it’s scoped to just one test machine, you might want to un-scope and re-scope it to kind of “refresh” the link. I’ve also seen cases where moving the Mac to a new static group helped the policy fire properly again. And if nothing works, removing the Jamf framework (sudo jamf removeFramework
) and re-enrolling the Mac tends to fix weird behavior like this. Sometimes the policy database on the client just needs a hard reset.