I have some MacBooks that are pre-stage enrolled that have stopped checking in and stopped inventorying. I have others that are User initiated enrolled that stopped checking in but I just had them remove the profiles and redo the enrollment and they are working again. These are all remote users so I cannot be hands on. I had a few of the pre-stage enrolled devices attempt to run sudo jamf recon and sudo jamf policy from terminal but they are receiving "Device Signature Error - A valid device signature is required to perform the action" Other postings I've seen that are quite a bit older mention unenrolling devices and reenrolling them. Not really an option if they are pre-stage enrolled from what I understand. Does anyone know what I can do get these devices reporting properly?
I believe for the device signature error. The one of these 2 terminal commands should resolve it. sudo profiles renew -type enrollment or sudo jamf enroll -prompt
sudo jamf enroll -prompt is what i usually use
My understanding is that the binary does not find the device certificate that is needed so that the server accepts requests from the device. Potential reasons are
- the device signature has been deleted
- the device signature went into the wrong keychain
- an invalid device signature is found in the keychain
- ?
Had a user attempt sudo jamf enroll -prompt and they received
"An error occurred while enrolling computer: Permission Error - The user specified does not have permission to perform the action.
Restoring JAMF.keychain since an error occurred.
Device Signature Error - A valid device signature is required to perform the action.
Checking in the background for policies that use the Enrollment Complete trigger
Enroll return code: 70"
Any user should be able to enroll a device, but that is a User Initiated an enrollment so not sure if it is a permissions issue in Jamf for him? If it is I can always add him in Jamf to be able to do enrollments if that fixes it and then remove his permissions.
I did have a laptop in my inventory pop the same error when I was trying to do sudo jamf recon. I did sudo jamf enroll -prompt and used my credentials when asked and it worked. I created an enroll Jamf user that does enrollments and I am having a few users trying the sudo jamf enroll -prompt with that Jamf user account. I believe that will resolve the issue. I will post again once I know results.
I had this happen for a user yesterday. Everything installed but self service and it does report to jamf after doing a recon command. New issue for me.
I did have a laptop in my inventory pop the same error when I was trying to do sudo jamf recon. I did sudo jamf enroll -prompt and used my credentials when asked and it worked. I created an enroll Jamf user that does enrollments and I am having a few users trying the sudo jamf enroll -prompt with that Jamf user account. I believe that will resolve the issue. I will post again once I know results.
I ended up needing to make the enroll account I created a full admin to get my user working normally. I am not sure why but it seems like doing a re-enrollment a standard enrollment account just doesn't have permissions to do it. If someone knows what I'm missing for permissions please let me know. I may create a ticket with Jamf over it.
In those kinds of situations dnorman, I would run sudo jamf manage and then sudo jamf policy
Had a user attempt sudo jamf enroll -prompt and they received
"An error occurred while enrolling computer: Permission Error - The user specified does not have permission to perform the action.
Restoring JAMF.keychain since an error occurred.
Device Signature Error - A valid device signature is required to perform the action.
Checking in the background for policies that use the Enrollment Complete trigger
Enroll return code: 70"
Any user should be able to enroll a device, but that is a User Initiated an enrollment so not sure if it is a permissions issue in Jamf for him? If it is I can always add him in Jamf to be able to do enrollments if that fixes it and then remove his permissions.
I have this same issue still. It seems to be when restore a TimeMachine image to a machine that's auto-enrolled via prestage enrolment. It seems if someone can easily disable the JamfFramework by just restoring a user from TimeMachine it's sort of defeats the usability of this as an MDM tool. We seem to have this with 10.14 all the way to 12.x.
Did you ever find a solution?
I have this same issue still. It seems to be when restore a TimeMachine image to a machine that's auto-enrolled via prestage enrolment. It seems if someone can easily disable the JamfFramework by just restoring a user from TimeMachine it's sort of defeats the usability of this as an MDM tool. We seem to have this with 10.14 all the way to 12.x.
Did you ever find a solution?
That issue specifically was because the regular users didn't have all the proper permissions it works with my enroll account I created after I went through a gave all enroll abilities to the account. The TimeMachine restore issue is intriguing and might explain why some of these developers break Jamf. I could see some of them using TimeMachine and doing restores.
sudo profiles renew -type enrollment
Worked for us when we had the dreaded "Device Signature Error" when trying to do a manual recon on a device that stopped talking to Jamf Pro.
Thanks for the tip!
What if none of these work? What's the next step?
My situation is related to Migration Assistant, and it has worked on dozens of other laptops/Users but I have two that will no longer communicate after moving a User over.
What if none of these work? What's the next step?
My situation is related to Migration Assistant, and it has worked on dozens of other laptops/Users but I have two that will no longer communicate after moving a User over.
My Go-To for that was to remove the framework entirely, and then do a reinstall using a QuickAdd pkg. Thought I haven't had this in a while, you may be able to just use the online enrolment method instead of a QuickAdd.
My Go-To for that was to remove the framework entirely, and then do a reinstall using a QuickAdd pkg. Thought I haven't had this in a while, you may be able to just use the online enrolment method instead of a QuickAdd.
Thanks for the reply bmcdade! That did not work for me as the Users' Library just had something so old and junky it was messing everything up. Using TimeMachine and moving everything over manually (except the Library) fixed it up.
Appreciate the assist.
Had a user attempt sudo jamf enroll -prompt and they received
"An error occurred while enrolling computer: Permission Error - The user specified does not have permission to perform the action.
Restoring JAMF.keychain since an error occurred.
Device Signature Error - A valid device signature is required to perform the action.
Checking in the background for policies that use the Enrollment Complete trigger
Enroll return code: 70"
Any user should be able to enroll a device, but that is a User Initiated an enrollment so not sure if it is a permissions issue in Jamf for him? If it is I can always add him in Jamf to be able to do enrollments if that fixes it and then remove his permissions.
I've got that issue too, I just use an admin account for Jamf in JSS Username and the SSH is the local admin
Thanks for this script. I have a machine that is not checking in with Jamf anymore so I gave this a try through terminal (copied the script through terminal).
When I execute this script the result is this:
{
"httpStatus" : 404,
"errors" : [ {
"code" : "INVALID_ID",
"description" : "computer with given id does not exist or user does not have site access",
"id" : "2",
"field" : null
} ]
}{
"httpStatus" : 404,
"errors" : [ {
"code" : "INVALID_ID",
"description" : "computer with given id does not exist or user does not have site access",
"id" : "3",
"field" : null
} ]
}%
My useraccount and password are right so that could not be the problem.
@Musicmaker the above script may. work or not. They did get rid off QUickadd but you can still use it
for cloud https://domain/enroll/?type=QuickAdd this will re ignite the framework
for on prem use the :8443 for anyone that had an issue with this on prem and your services were done correctly, please let us know here bc that will point to the upgrade.
We are not doing any of these methods and are switching out 20 machines so they stay in the correct prestage enrollment. We are also asking for us not to be upgraded, they need to ask and wait till we read the release notes and feel comfortable with the upgrade - going forward.
My Go-To for that was to remove the framework entirely, and then do a reinstall using a QuickAdd pkg. Thought I haven't had this in a while, you may be able to just use the online enrolment method instead of a QuickAdd.
This will work. But if you have a 0 touch prestage they will now be user initiated... If you have things subsetted like that in the future this will break other things. After you fix it, re enroll it again via the correct prestage or we swapped machines. Not ideal, but these effected were new hires and it was cause by a jamf upgrade going wrong.
Hi @jmancuso , was this script placed in GitHub? I'd love to use as a refence if you could provide the URL.
Thank you!
sudo jamf enroll -prompt is what i usually use
This worked for me.
I had to use my JSS creds.
I want to know does this happen often and is this a maintenance piece we should do on the regular?
Do we know why this happens?
This worked for me.
I had to use my JSS creds.
I want to know does this happen often and is this a maintenance piece we should do on the regular?
Do we know why this happens?
I know this is an old thread but I just wanted to echo that this worked for me.
We do a yearly inventory audit, and we have a report for anything that hasn't checked in in >30 days. So far we've run into a handful. You could set up a similar report and then have it email you whenever a new device meets the criteria, so that it's a continual maintenance thing. Or do a periodic audit like we do.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.