Casper and alternating between bootable partitions

donmontalvo
Esteemed Contributor III

Ok, so we have some users who alternate between bootable partitions, including IT folks. :)

Casper seems to need a kick in the @$$ whenever the Mac is toggled between partitions...running sudo jamf enroll -prompt after switching bootable partitions fixes things. ;)

Is there a best-practice for this scenario? How do we ensure once-per-computer policies run on each of the partitions? What if partitions are different OS'es? Casper should be intelligent enough to adjust during the standard inventory update, no?

Thanks,
Don

--
https://donmontalvo.com
2 ACCEPTED SOLUTIONS

mm2270
Legendary Contributor III

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?

View solution in original post

SamF
Contributor II
Contributor II

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.

View solution in original post

7 REPLIES 7

mm2270
Legendary Contributor III

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?

donmontalvo
Esteemed Contributor III

@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. :(

--
https://donmontalvo.com

SamF
Contributor II
Contributor II

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.

donmontalvo
Esteemed Contributor III

@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

--
https://donmontalvo.com

Chris_Hafner
Valued Contributor II

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.

SamF
Contributor II
Contributor II

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.

Chris_Hafner
Valued Contributor II

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