Before I start I did see the other posts about this issue, but seem like all the fixes are manual ones. Since this occurs during our imaging process which is hands free, I'm looking to see if there is something I can do to remediate this.
Quick Background: This occurs on desktop machines (mac mini's and imacs) and some older laptops. Newer laptops it doesn't have any issues with. Casper is running at 9.72.
Were currently booting up with a netboot and imaging the machines. During the first reboot phase it runs a script to bind to active directory (needed in the middle for security reasons). We use a manual trigger to call a policy thats sole function is to bind to the domain. On new laptops it works without issues. But on Mac Mini, iMacs, and some older laptops it connect to Casper, looks for the policy, and then gets:
There was an error. Device Signature Error - a valid device signature is required to perform the action.
The odd part is that everything before and after this still works fine and talks with Casper with no issues. Even when it's done all the updated information seems to get in Casper. So it's this one policy (which I have several versions of to try to test) that's been failing.
@cshepp11 It has something to do with the system keychain. The casper device signature (or rather the machines half) is kept there. It sounds like the system keychain is getting overwritten half way through the imaging process, changing the device signature.
I had something similar where a time machine restore of only the applications would kill the object it casper requiring re-enrollment.
Hope this helps.
@jack_bishop Seems that my issue might have been that the script was running before the machine was into management. I added the following to the beginning of my script, and it worked great.
#!/bin/sh jamf=$(which jamf) # Check if JAMF binary exists if [[ -e "$jamf" ]] then /bin/echo "Jamf binary present, continuing as planned..." else /bin/echo "Jamf binary is not present, then halt and catch fire" exit 1 fi logme "======== Starting Post Imaging Configuration ========" # Checking to make sure the JSS is available before proceeding "$jamf" checkJSSConnection -retry 0 until [ $? = 0 ] do "$jamf" checkJSSConnection -retry 0 done
of course there is more to the script, but wanted to share this part.
We have determined that in our environment, this issue only occurs on Macs that are being re-imaged and thus already have a computer record in the JSS. I wonder if that's what the OP meant when comparing "older laptops" to "newer laptops." Certificates are definitely related. Our thinking (along with our TAM) is that during imaging, a new cert is created but at some point, the JSS attempts to apply data from the old computer record into the newly imaged Mac's Keychain, thus triggering the mismatch error. In the end, the Macs won't be manageable, and manually re-enolling has been our solution because it seems to re-create the entire cert chain on both ends.
Currently, our workflow does not involve deleting computer records in advance, and to be honest it shouldn't be necessary, but to make it easier on our provisioners, we're considering adding this as a step to lower the number of issues they encounter. In our case, we don't mind losing the historical data associated with the computer record.
In our case I found using the follow command every now and then in the code kept things pretty fresh:
sudo jamf createConf -url 'https://jss.company.com:8443/' -k;sudo jamf startSSH;sudo jamf enroll -invitation 166222421695850711274991501866187933345;sudo jamf policy -id 6737 -verbose
Since we rarely ever delete machines from Casper before re-imaging them, this little code seems to help quite a bit.