Device Signature Error on All macOS Mojave (10.14.6) Machines

MNussbaum
New Contributor III

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.

1 ACCEPTED SOLUTION

sdagley
Honored Contributor III

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

View solution in original post

13 REPLIES 13

sdagley
Honored Contributor III

@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
New Contributor III

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
New Contributor II

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
Honored Contributor III

@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
New Contributor II

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
New Contributor II

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
New Contributor II

Hi Everyone,

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

ETsavaris
New Contributor II

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

ETsavaris
New Contributor II

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
New Contributor II

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
New Contributor II

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
New Contributor II

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

user-JqUTUNOxpb
New Contributor

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.