I just fixed a device signature error on a single machine occurrence by running jamf enroll -prompt -noPolicy. The latter switch just to save a little time I think...
This worked in our environment. Thank you!
We're seeing this in our environment too. I have an API script to run a mass command on the delinquent Macs so they repair the jamf framework, but it isn't working on some devices so they have to be touched manually. Still talking about 30-40 of them. I've only had it start happening in June, sometime. Does anyone know if there is a product issue for this?
Do you think you could share your API script/call to fix these machines?
We have older machines in our environment exhibiting this behavior, but we have specific pre-stage enrollment groups that are also having the issue and I can't seem to figure out what could be causing it.
Like, on a recently reconfigured MB Air, it got about 13 or so MDM commands from JAMF pro before throwing up a "device busy" error on the device record . When you try to force any of the regular jamf commands (policy, recon, etc.) it gives the device signature error. If I put the same device in a different pre-stage it seems to be fine after reconfiguring. Put it back to the original pre-stage and nuke and we've got the same issue again.
I've combed through the config profiles and policies at a pretty base level and haven't found anything that seems that different.... Still looking tho...
Do you think you could share your API script/call to fix these machines?
We have older machines in our environment exhibiting this behavior, but we have specific pre-stage enrollment groups that are also having the issue and I can't seem to figure out what could be causing it.
Like, on a recently reconfigured MB Air, it got about 13 or so MDM commands from JAMF pro before throwing up a "device busy" error on the device record . When you try to force any of the regular jamf commands (policy, recon, etc.) it gives the device signature error. If I put the same device in a different pre-stage it seems to be fine after reconfiguring. Put it back to the original pre-stage and nuke and we've got the same issue again.
I've combed through the config profiles and policies at a pretty base level and haven't found anything that seems that different.... Still looking tho...
Allow me to chime in on my experience. If it's the "/v1/jamf-management-framework/redeploy/{id}" API, then that didn't work on most of the "Device Signature Error" in my environment because I suspect Apple's Migration Assistant messed up the /Library/Application Support/JAMF/JAMF.keychain by replacing it with the cert from the old machine, causing communication between JSS and the new computer to be cut off. The only method to get that API to work, as far as I discovered is to disable certificate-based authentication in Settings > Computer Management > Security. The effect of disabling that is all configuration profiles are removed from all managed computers until it is re-enabled. That causes a major security issue in my environment so there is no way my environment can resort to that. Currently, I had Apple and Jamf work on a collaborative case to figure this out.
I'll attach the script the Jamf technician sent me. He said he received it from an engineer. You should see the places to insert your own info; basically you put in your instance, an admin account and then put in all the Jamf IDs of the devices not reporting in. This mostly solved our problem, but I have a few Macs that are completely hosed and will need to be touched manually to remove the framework, delete device record and re-enroll. Not optimal, but at least it's only 50 or so instead of like, 200.
#!/bin/zsh
# server connection information
URL="https://instancename.jamfcloud.com"
userName="username"
password="password"
# use base64 to encode credentials
encodedCredentials=$( printf "$userName:$password" | iconv -t ISO-8859-1 | base64 -i - )
# generate an auth token
authToken=$( /usr/bin/curl "$URL/api/v1/auth/token" \\
--silent \\
--request POST \\
--header "Authorization: Basic $encodedCredentials" )
# parse authToken for token, omit expiration
token=$( /usr/bin/awk -F \\" '/token/{ print $4 }' <<< "$authToken" | /usr/bin/xargs )
function heal() {
/usr/bin/curl $URL/api/v1/jamf-management-framework/redeploy/$1 --silent --header "Authorization: Bearer $token" --header "Accept: application/json" --request POST
}
# list of computer IDs separated by returns
computerList="30
37"
# recurse through the computer list and run the heal command for each computer
for aComputer in $computerList
do
heal "$aComputer"
echo "healing $aComputer"
done
# expire the auth token
/usr/bin/curl "$URL/api/v1/auth/invalidate-token" \\
--silent \\
--request POST \\
--header "Authorization: Bearer $token"
exit 0
I'll attach the script the Jamf technician sent me. He said he received it from an engineer. You should see the places to insert your own info; basically you put in your instance, an admin account and then put in all the Jamf IDs of the devices not reporting in. This mostly solved our problem, but I have a few Macs that are completely hosed and will need to be touched manually to remove the framework, delete device record and re-enroll. Not optimal, but at least it's only 50 or so instead of like, 200.
#!/bin/zsh
# server connection information
URL="https://instancename.jamfcloud.com"
userName="username"
password="password"
# use base64 to encode credentials
encodedCredentials=$( printf "$userName:$password" | iconv -t ISO-8859-1 | base64 -i - )
# generate an auth token
authToken=$( /usr/bin/curl "$URL/api/v1/auth/token" \\
--silent \\
--request POST \\
--header "Authorization: Basic $encodedCredentials" )
# parse authToken for token, omit expiration
token=$( /usr/bin/awk -F \\" '/token/{ print $4 }' <<< "$authToken" | /usr/bin/xargs )
function heal() {
/usr/bin/curl $URL/api/v1/jamf-management-framework/redeploy/$1 --silent --header "Authorization: Bearer $token" --header "Accept: application/json" --request POST
}
# list of computer IDs separated by returns
computerList="30
37"
# recurse through the computer list and run the heal command for each computer
for aComputer in $computerList
do
heal "$aComputer"
echo "healing $aComputer"
done
# expire the auth token
/usr/bin/curl "$URL/api/v1/auth/invalidate-token" \\
--silent \\
--request POST \\
--header "Authorization: Bearer $token"
exit 0
Can anyone tell what permissions I need to set for an API user in order to post to the jamf-management-framework/redeploy?
Can anyone tell what permissions I need to set for an API user in order to post to the jamf-management-framework/redeploy?
It's documented here: https://developer.jamf.com/jamf-pro/docs/privileges-and-deprecations
It's documented here: https://developer.jamf.com/jamf-pro/docs/privileges-and-deprecations
Thanks! I appreciate the reference to this document.
I made the changes accordingly but still got the return code with the HTTP status 401. Even try with admin credentials to test and still got 401.
I wonder if there is something else to try.
Our company also experienced device signature errors while re-enrolling Macs with DEP and UIE. We worked with Jamf Support and it turns out that one of the VPP Mac apps was preventing the device certificate from installing. We excluded the VPP app from our Mac environment scope and the issue was resolved.
Our company also experienced device signature errors while re-enrolling Macs with DEP and UIE. We worked with Jamf Support and it turns out that one of the VPP Mac apps was preventing the device certificate from installing. We excluded the VPP app from our Mac environment scope and the issue was resolved.
How did you go about identifying which app was preventing the device certificate from installing?
Another way to fix this is to type in terminal
sudo jamf enroll -prompt
wherein the JSS username and password is an account with enrolment privileges. And the SSH username and password is a local admin.
Thanks. Just fixed this on one of our macs using this. Had the MDM profile set to not be allowed to remove, so couldn't just click the minus button. Device was an old Mojave device.
I would like to add that I recently had this problem on a DEP unit we used Migration Assistant on. We set up a temp user and then transferred data via migration assistant. For whatever reason JAMF was "stuck" in the temp user and never completed the enrolling. Logging back into the temp user and running sudo jamf policy allowed whatever needed to be done to finalize, works fine now.
Our company also experienced device signature errors while re-enrolling Macs with DEP and UIE. We worked with Jamf Support and it turns out that one of the VPP Mac apps was preventing the device certificate from installing. We excluded the VPP app from our Mac environment scope and the issue was resolved.
I second @Leadehh's questions. I am having an issue with the device signature, my school uses the VPP however I don't have any apps being pushed from Pre stage enrollment only in my policies.
Anyone know why this even happens? I saw the one person above said a VPP app. I've had a sudden rash of them. Should I run...
profiles renew -type enrollment...on a weekly policy?
For what it's worth. What turned out to be my issue is that we were adding our management account in both the global settings (Settings Cog > User-initiated enrollment > MacOS ) AND in the pre-stage enrollment group. Once we took the management account out of the Pre-stage enrollment group, we stopped having these issues.
For what it's worth. What turned out to be my issue is that we were adding our management account in both the global settings (Settings Cog > User-initiated enrollment > MacOS ) AND in the pre-stage enrollment group. Once we took the management account out of the Pre-stage enrollment group, we stopped having these issues.
This worked for me! Thank you so much!!
For this, you need to follow these steps:
1. Check Laptop "Profile" (Simply search for it if you don't find it)
2. Check CA Certificate is there or not
3. If CA is not there, go to your company's JAMF cloud manual enrolment portal.
4. Download the certificate then install this certificate from Laptop "Profile"
Then this issue will get fixed.
I just had a machine that showed the device signature error. I re-enrolled it from the command line, and it was good. It apparently updated self service and the binary too I guess, and then the device signature error returned. I re-re-enrolled it again, and it was fine after that. Weird...
I was only seeing this on the M2s. I ended up creating another PreStage but not enabling Account Settings (so no local administrator account was going to be created before Setup Assistant). I moved the devices over to that PreStage and never got that error again. Not sure if that is the fix but that's what worked for us.
Anyone know why this even happens? I saw the one person above said a VPP app. I've had a sudden rash of them. Should I run...
profiles renew -type enrollment...on a weekly policy?
Something to note when using this... If you have sites, the computer object gets put into none site....
I am, but trying to find a more elegant solution as we usually enroll with unremovable MDM.
i agree, that is way too long an unnecessarily complex. someone posted this below which i have used with success in the past. short and sweet.
sudo jamf enroll -prompt
wherein the JSS username and password is an account with enrollment privileges. And the SSH username and password is a local admin.
much simpler way to fix this, as stated below.
sudo jamf enroll -prompt
wherein the JSS username and password is an account with enrolment privileges. And the SSH username and password is a local admin.
