Device Signature Error on build

@roiegat Did you ever resolve this issue? If so, what did you do to fix?

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

@roiegat Could you clarify what that script does?