Device Signature Error on All macOS Mojave (10.14.6) Machines

[MNussbaum]

We just discovered that the portion of our fleet still running macOS Mojave (10.14.6) are no longer checking in, updating their inventory, or of course executing any policies or receiving any patches.

When manually triggering a policy check-in or recon, we get this error:

There was an error.

Device Signature Error - A valid device signature is required to perform the action.

This appears to have happened to all of these machines around the same time, all showing a last check-in/update on Friday 8/12 or Monday 8/15. It doesn't appear to be happening on any of our machines on 10.15 or later.

The computers all still show they are managed, supervised, enrolled, and have MDM profile expiration dates far in the future.

Initial spot testing using the Jamf binary self-heal with Jamf API seems to get it reenrolled successfully. Unfortunately we're unsure if this will stick since we have no idea what the cause was, nor do we know if there will be any other ill effects from this error or from the self-heal. Hoping to figure out what is going on so we can be confident in a solution and a plan moving forward.

(Note that we have macOS upgrades for all of these machines planned for the coming weeks to get away from these old versions of macOS, but we now need to solve this to be able to roll them out!)

I spent some time on a call with Jamf support this morning and have an open case with them, but wanted to see if anyone else has experienced this and may have some insight while they try to track down a cause.

[sdagley · Accepted solution]

@MNussbaum Sounds like PI110463. As posted on MacAdmins Slack:

"Thank you for contacting Jamf Support about this issue. Sorry about that problem! We have opened Product Issue PI110463 for this. It seems that some work was done in 10.40 to improve the enrollment experience with 10.14 machines, but something caused a side effect to break existing enrollments when the binary was upgraded. Re-enrolling the machines via the sudo jamf enroll method or via the API method to re-deploy the framework are the suggested workarounds. Sorry for the inconvenience on this! Please let us know if there are further questions."

[MNussbaum]

Thank you so much! The timing of it and the fact that it only effected the one version of macOS made it seem likely that something very specific caused it as a one time thing. I really appreciate you digging that up and replying with it so quickly!

[orlandinim]

Hi @sdagley ,

re-rolling each machine is not a viable solution except in very small realities.
We have hundreds of systems out of order, it's a very serious problem that Jamf has to solve very quickly if he wants to see his contract renewed!
Is it possible that these things are not tried before an update is distributed? we are talking about an obvious and blocking problem, not a detail. Such lightness in behavior is inadmissible, it is a sign of lack of attention and seriousness.

[sdagley]

@orlandinim I'm simply relaying the info on the problem. You should contact your Jamf rep with your concerns regarding the impact and why the issue wasn't discovered until after JSS 10.40 was released since macOS 10.14.4 or later is still listed in the Minimum Supported section of the 10.40 release notes.

[orlandinim]

Yeah sorry @sdagley, obviously I wasn't mad at you!
Of course we have already involved our dealer, but I am very annoyed by the current situation caused by Jamf.

[ETsavaris]

Hey all! Utilizing the Jamf Pro API to bring these computers back worked for me.

I've attached a script I wrote to get this done a bit quicker for those of us with hundreds of computers out there inaccessible.

#!/bin/zsh

# Script to force computers to refresh the management framework.

# WorkFlow: Computers don't check in due to known issue PI110463, push out framework redeploy with what you gather from smart or static group

# You'll need to authorize yourself first
JSS="$(osascript -e 'Tell application "System Events" to display dialog "Please provide your Jamf Pro URL in the format, https://yourjamfinstance.jamfcloud.com" default answer "" with title "Jamf Instance" with text buttons {"Next"} default button 1' -e 'text returned of result')"
API_USER="$(osascript -e 'Tell application "System Events" to display dialog "Please log in with your Jamf Pro Admin account" default answer "" with title "API Username" with text buttons {"Next"} default button 1' -e 'text returned of result')"
API_PASS="$(osascript -e 'Tell application "System Events" to display dialog "Please enter the password for this account" default answer "" with title "API Password" with text buttons {"Next"} default button 1 with hidden answer' -e 'text returned of result')"
COMPUTER_LIST="$(osascript -e 'Tell application "System Events" to display dialog "Please provide the filepath to your computer text file" default answer "" with title "Computer List" with text buttons {"Send it!"} default button 1' -e 'text returned of result')"
response=`curl -u $API_USER:$API_PASS --basic --request POST --url $JSS/api/v1/auth/token --header 'Accept: application/json'`
token=$(echo $response | grep '"token" :' | awk -F '"' '{print $4}')

# Start yourself a handy little loop to go through each serial number in the plain text file you are 
while read serialNumber; do
    echo "Redeploying $serialNumber"

    # Now that you've authenticated, grab the id of the computer within jamf
    response=`curl --oauth2-bearer "$token" --request GET --url $JSS/JSSResource/computers/serialnumber/$serialNumber/subset/General --header 'Content-Type: application/xml'`
    echo $response

    # next, parse the id from the xml response
    ID=$(echo $response | awk -F '<' '{print $5}' | awk -F '>' '{print $2}')
    echo "Computer ID is $ID"

    # Id has been grabbed, moving on to sending the framework redeployment command
    response=`curl --oauth2-bearer "$token" --request POST --url $JSS/api/v1/jamf-management-framework/redeploy/$ID --header 'Content-Type: application/xml'`
    echo $response
done < $COMPUTER_LIST

It's written in zsh and utilizes AppleScript to gather your input for instance URL, Username, Password, and a plaintext file generated by copying all serial numbers that I exported using a Smart group targeting computers with a last check in of August 13th-15th, since this is about when the update to 10.40 took place for our instance.

Hope this helps someone running into the same issue!

[mertala]

Hi Everyone,

We're also facing with the same issue. How about performing an OS upgrade on Mojave devices? 

[ETsavaris]

Yes updating the devices to an OS after Mojave, then redeploying the framework remotely or locally fixes the issue.

[ETsavaris]

You'll need to update the devices before you push the redeployment of the framework though, otherwise the issue will persist.
However, we've found that just updating the devices and not re-enrolling does not resolve the issue though.

[mertala]

Hi ETsavaris,

Thank you for your reply! I will give a try to OS upgrade and redeploy the framework as you suggested. By the way, re-enrolling the Mac devices doesn't cause any duplicate recordings in Jamf console does it? Additionally, it doesn't redeploy any configuration or policy, right?

Best Regards.

[ETsavaris]

I've heard of duplicate profiles being created whenever a device is re-enrolled, but I've never seen it personally.
I would be curious to see whether a computer will still be able to have its framework re-deployed via API if its record is deleted from Jamf, and the computer is not under a Prestage.

In regards to your second question, our environment has a mix of Prestage enrolled devices, as well as user-initiated enrolled devices. We've seen that the only thing triggered were any policies set to execute on the "Enrollment Complete" event. All other configuration profiles that were scoped to the computers initially were either retained or were removed/added once the computers checked in again based on what they should have.

We don't use Enrollment Customization though, so I don't know if anything there would be affected or not.

[ETsavaris]

Another thing to note, is if you utilize any kind of computer configuration automation like DEPNotify or the Notify options used in Jamf Connect (In our case DEPNotify) note the computers that were enrolled BEFORE the automation was engineered as they won't have the log files needed to error out the process (a.k.a. /var/tmp/depnotify.log or others.)

[CrepuscularDave]

We are seeing this exact issue on Monterey, and our Jamf Pro was updated to 10.41 in September. About this time individual machine jamf logs show connection issues to the Jamf server, but the Device Signature error seems to have started around Oct 12/13th. We have 971 managed computers so manually re-enrolling them is not an option.  Currently have a Support ticket open with Jamf about this, but will post a link to this thread in the ticket and ask them if they think it is the same issue.

[mgermano]

Did you hear back from Support on your issue? If so, what did they say? We also have hundreds of machines with the same issue.

[ETsavaris]

These devices will either need the Jamf Binary redeployed through API or by other means.

You should able to remove the Jamf framework through the command

jamf removeFramework

Rather than having to wipe the machine.

>From there, re-enroll the machine via whatever means are standard for your organization.

If you're using DEP, you should be able to use "sudo profiles renew -type enrollment" to bring back whatever enrollment profiles are deleted through the removeFramework command.

Emmanuel Tsavaris|Endpoint Technology Services Administrator
Support: 877-756-9822
7101 Sharondale Court, Suite 200, Brentwood, TN37027
A CLEAR PATH TO A CONNECTED WORLD.

[CrepuscularDave]

When we adopted Jamf for our Mac estate (before i got involved) we created an admin account on every enrolled mac. This account was also used as the Management account. As of 10.40 this caused issues, including this one, when we upgraded to 10.41 (we passed on 10.40 as it occurred during a moratorium period).  We have an ongoing case with Jamf Pro and have gone through several suggestions with them, so my suggestion is for you to raise a case directly with them. It's too complex to go into here, as the case is still ongoing.  For example we now have a separate Management account called (not very originally) "jamfadmin". This should have resolved the issue, except it appeared on a newly-enrolled machine just a day or two later.   The latest suggestion was that since our MDM cert is up for renewal in April, we should manually upgrade all certs now.  This is taking time, and the jury's still out as to whether it will fix the issue or not.