Re-Enroll After Login Board Replacement

[kishjayson]

Been meaning to inquire about this one for awhile...

Anytime we replace the Logic Board in a system, I've found that I will have to re-enroll the system with the JSS and delete the old inventory record. Is there a way around this, or is this just how it is?

[dgreening]

As JAMF uses the UDID now instead of the serial or MAC address, re-enrolling is really the only way around it.

[davidacland]

Yep, I work for an AASP. We can add the Mac's serial number to the new board but not the UDID/UUID.

A re-enroll will be the simplest route unfortunately.

[mm2270]

Yep, you need to re-enroll, because as far as the JSS is concerned, its a new piece of hardware due to the logic board replacement. We as humans can see its the same Mac, but the JSS can't know that.

If I'm not mistaken, there's a feature request out there to add a function to merge records together, since upon re-enrollment you'll have both the old dead record and the new one. This can be problematic in the case of FV2 encrypted systems, since that escrowed Recovery key will only be in the old record, not the new one, and there isn't a way to manually move the key over, other than issuing fdesetup commands to tell the Mac to issue a new key and pull that into the record.

[kishjayson]

Makes sense. Just wanted to be sure there wasn't an easier way. Thanks again!

[bvrooman]

I usually just modify the record and put in the new UDID. It will get new MAC addresses, etc. at the next inventory update.

[kishjayson]

@bvrooman Does this typically work? What affect would it have on things like Configuration Profile updates?

[nadams]

@bvrooman This is what the integrator doing my Jumpstart recommended. Or delete the record and re-enroll.

[kishjayson]

Interesting. And I take it this change has to be made directly agains the MySQL database?

[mm2270]

Hmm, never really looked into changing the original record's UDID to match, but may be something to try. Although, I have seen times when after a LB replacement the client gets device signature errors upon jamf recon's etc. so I'm not sure if that would get fixed with just changing out the UDID.

@nadams (Sorry, meant to tag @kish.jayson) You can change the UDID in the Mac's record in the JSS directly. No need to do anything with MySQL. Open the record and click on "Hardware" in the side panel and then the Edit button. There's a field for the UDID there.

[bentoms]

@mm2270 & @kish.jayson, if you want the Mac to retain it's old record. You'll need to update the old new record (if that makes sense) with the new UUID, delete the old record & re-enroll.

[kishjayson]

Just changed the UUID on the JSS for a workstation that recently had the logic board replaced. I'm happy to report that this resolved the device checkin issue and it's running policy now. Thanks everyone! This made my day.

[mm2270]

Ever since I had read about the possibility of changing the UUID in Casper, I've been using this same method with good success. So instead of doing a re-enroll, which usually ends up creating a new JSS record, I grab the new UUID from the Mac and then update the existing record in Casper with that new UUID string. After that, in most cases all communication starts up again. In some rare cases, I still need to do a re-enroll, but the good news is it just pairs up with the existing record. This is good in cases where you use Casper to store FV2 Recovery keys, like we do. When a new record is created, it won't pull over the Recovery Key stored in the older defunct record, of course. So its a bit problematic unless you take some actions to re-issue a recovery key or something to that effect.
Updating the UUID for us makes a lot more sense, because it rejoins the old record and everything is retained and is good again.