Wouldn't it just be seeing the Mac as the same machine in the JSS inventory since its using the hardware MAC address as the primary identifier? Doesn't matter what partition or external volume I boot my Mac from, the Ethernet or Airport MAC address is the same. Could that be why you're seeing this issue?

@mm2270 Yep, I'm hoping that there can be a way to ensure the jamf binary continues to work, even if it means a full recon will update the computer details on the next scheduled recon. I've got my fingers crossed that there's a solution for the broken enrollment after the switch between partitions. :(

If you're using certificate based communication, the JAMF.keychain in /Library/Application Support/JAMF must match the JSS database record. I haven't tested, but copying the keychain from the working partition to the non-working partition may resolve the issue. Make sure to preserve permissions. A re-enroll recreates both the client keychain and database record, which would explain why that resolves the issue.

@Sam.Fortuna Wow, this is exactly the kind of workaround we were looking for. And it's totally reasonable, one partition MUST already be enrolled, then the user would be responsible for copying over the JAMF.keychain to each partition. They're power users, so we'll hold them accountable for following these steps. You guys rock! :D

PS, er...I guess I should test this first. :B

Don

Here's an interesting question. Do you think that the publicly proposed shift to UUID (https://jamfnation.jamfsoftware.com/featureRequest.html?id=366) based records will cause the licensing to "double" on these systems? Mind you, that's a simple fix but this question made me think of it.

Chris- The UDID should be based on the physical hardware, and changing from one bootable partition to another shouldn't change the UDID. Therefore, it should just overwrite the existing record.

Heh, I has to slap my own forehead over that one. Of course!