Posted on 07-31-2013 10:59 AM
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
Solved! Go to Solution.
Posted on 07-31-2013 11:11 AM
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?
Posted on 07-31-2013 12:57 PM
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.
Posted on 07-31-2013 11:11 AM
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?
Posted on 07-31-2013 11:15 AM
@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. :(
Posted on 07-31-2013 12:57 PM
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.
Posted on 07-31-2013 01:31 PM
@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
Posted on 08-01-2013 12:17 PM
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.
Posted on 08-01-2013 01:02 PM
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.
Posted on 08-01-2013 03:22 PM
Heh, I has to slap my own forehead over that one. Of course!