We re-image machines all the time with no extra effort. The existing database record simply updates itself.
If your using the Enrollment Complete policy trigger, there may be considerations there. We're not using that trigger.
@cgiordano we just re-image. The JSS tidies up the record as needed post imaging & updates our smart groups.
One consideration may be policies. In the past a re-image would flush policies but that has changed a few times. In our environment it doesn't flush policies so we have to remember to do that each time.
@strider.knh Ahh, ours are mostly scoped via Smart Groups.
Policy completes = Mac drops out of smart group.
Yep, if you push updates (that aren't part of your imaging config) and have the policies scoped via Once Per Computer, you'll have to flush the policy histories to get them to run again on the newly-reimaged machine.
If you use Ongoing, have a Recon and scope to Smart Groups, no flush is necessary (i.e. Smart Group criteria has Microsoft Word.app like 14, does not have 14.4.9, install the Office 2011 14.4.9.pkg and run a recon. Machine reimages with 14.3.0, recons, falls into smart group, update policy runs, recons, falls out of smart group. Re-image, lather/rinse/repeat).
Not sure if this helps, but in our environment the auto-flushing of policies was also not happening upon re-imaging/re-enrollment. After talking with our jamf support rep, he let us know that we need to enable the setting in our database. Your exact steps may vary depending on your setup, and I'd recommend talking with your jamf support rep if needed, but here are the steps we took to enable the auto-flushing of policies:
run the commands:
/usr/local/mysql/bin/mysql -u root
use jamfsoftware;
SELECT flush_management_history_on_remanage FROM mac_os_x_enrollment;
In the table view return, if you have a 0 then the auto-flushing is disabled. If you have a 1 then it's enabled. So to change it from 0 to 1 to enable the setting, run the command:
UPDATE mac_os_x_enrollment SET flush_management_history_on_remanage=1;
I prefer to remove the machine from the JSS prior to reimaging. We noticed that the users list that could unlock FileVault would be incorrect in the JSS if we left it in the JSS and updated. It would have the prior and new users.
Same for me, I know you are supposed to be able to leave the record in the JSS, and we would prefer to be able to do that, but in a lot of cases we get a load of problems if we do. Macs not enrolling properly, MDM not functioning, etc.
A few years ago I used to just flush the policy history but since Casper 9 I've found that to not be enough so it's either removeFramework for us or we just manually delete the record before imaging.
