Proper steps for machine prior to re-imaging?

cgiordano
Contributor

I'm just curious what the "proper" steps are prior to re-imaging a machine that's currently enrolled? Should i run

sudo jamf removeFramework

then delete the machine from the JSS or will re-enrolling after imaging simply re-assume the previous machine but rename it to what's current?

From an inventory and license perspective I'm leaning more toward removing the framework and deleting from the JSS just to be totally safe. Just wanted to check in and see what other workflows seemed to be working.

Thanks!
Chris

8 REPLIES 8

dpertschi
Valued Contributor

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.

bentoms
Release Candidate Programs Tester

@cgiordano we just re-image. The JSS tidies up the record as needed post imaging & updates our smart groups.

strider_knh
Contributor II

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.

bentoms
Release Candidate Programs Tester

@strider.knh Ahh, ours are mostly scoped via Smart Groups.

Policy completes = Mac drops out of smart group.

RobertHammen
Valued Contributor II

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).

alexk
New Contributor III

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;

pblake
Contributor III

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.

davidacland
Honored Contributor II
Honored Contributor II

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.