Bump: This just happened to us on a 2014 MacBook Pro and Casper Suite 9.63. The unit is not pre-existing in the JSS; it's a new unit. Also won't let me enroll with QuickAdd. Only way to enroll is using "sudo jamf enroll -prompt". Will advise if I find a solution.

EDIT: It seems related to downgrading a Yosemite-delivered Mac to Mavericks (as that's our standard build/workflow).

I've been seeing this error again after moving to 9.6x for OS X 10.10 testing within our environment. So far the only fix has been to re-enroll to the JSS with a quickadd package. Our workflow has been using Casper Imaging to deploy equipment from one user to the next. On boot post image I'm seeing a fail on any enrollment. My FirstRun directory exists with content, and upon reboot it's gone (implying execution to me). However I don't get any enrollment to my test JSS, I can communicate to it, as verified with a```
jamf checkjssconnection
``` but any other attempts to communicate to the JSS fail with the "Device Signature" error.... Le Sigh...

I see this error about 50% of the time, after swapping HDs between machines. Our workflow is this: 1:1 Laptop comes in for repair; I swap the SSD between it and a Loaner. Student leaves with a Loaner. Several days later, the student comes back with the Loaner, I swap SSDs back, and then this bug rears its head. The "fix" is to re-run QuickAdd or use "sudo jamf enroll -prompt" to re-enroll the machine into JSS, after which the machine shows up in JSS twice with the same serial number, same UUID. I typically end up deleting the "inactive" machine record from JSS and leave the "new" active machine record in place.

Before Casper 9, we used to swap HDs constantly and never had this problem. It seems to have been introduced with Casper 9 (or perhaps OS X 10.8). And it's frustratingly inconsistent. About 50% of the time, the SSDs can be swapped between machines and the machine doesn't lose its identity or enrollment into JSS.

I just saw this on a 10.10 machine I built using Casper 9.5. We never saw this with or 10.9 boxes with 9.5. Bringing JSS to the latest and building a new quickadd fixed the issue for me. I doubt I needed to build a new quickadd but I wanted to make sure I covered all my bases. Time will tell if this becomes an issue like others have mentioned.

we just had a mac that would not recon locally or remotely. The Frameworks would not remove...it would hang on "Removing JAMF Daemon Log Files" Ended up being the management admin account had some bad permissions. Reset using the restore partition - opened terminal and did
resetpassword

A prompt comes up and at the bottom you can reset permissions for users.
Rebooted and the frameworks removed no issue.

I am seeing issues with Macs that I am using Casper Imaging to enrol on 9.65.

Have had to throw a QuickAdd pkg in, install on boot volume to get a reliable enrolment, or manually enrol with jamf enrol -prompt

A workaround, but a little ugly. Not enough time to dig deeper into why the device certificates aren't right at the moment.

@loceee How are you Imaging? I was using target disk imaging with an InstallESD file and getting this error. JAMF Support indicated the cloned image was the better route for imaging, though I've not made the full change to see if that solved the issue.

I have had this error from time to time when machines attempt to run policies, or jamf recon. I have noticed that it is intermittent with random machines being they could just need a reboot, or time checked to make sure it and the JSS are in sync.
Usually I will watch the systems that have the error after I clear it to see if they fail again, I have yet to need to re-join a system to the JSS due to this error.
Although since we have updated in the past few weeks up to current 9.65, we have not seen the error come about, and our count for "Not checked in group" has went back down to before the issues started appearing.

I'm seeing what @loceee mentions above in 9.65. Not consistent enrollment when imaging unless I do quickadd at reboot.

I have learned way more than I ever wanted to the past week dealing with this issue, so I thought I'd share what I learned:

Check EA's
Make sure you don't have any extension attributes that are hanging up recon. For example, we had a script that set the hostname variable with a "scutil --get HostName"

But even if hostname is present in Sharing Preference Pane, it may not be recognized by scutil - especially if hostname was created dynamically. So that command will just hang - causing recon to hang.

When you enroll, a quick computer record is created in JSS, containing very little system info - MAC addresses, Serial Number, etc. And a UUID and JSS Computer ID is generated for the record. But the MDM enrollment does NOT occur until after the recon is done with enrollment.

At any rate - the "No Name" record will appear in JSS until a full recon is done.

For testing - it may be beneficial to create a quick add, but then modify the enroll command with a "-noRecon" option. For example --

/usr/sbin/jamf enroll -invitation 123456789876543212345678976543 -noRecon -verbose

Then, run a

jamf recon -verbose

to try to determine where the hangup is

Verify JAMF Keychain
As part of your troubleshooting, make sure your system is actually receiving its device certificate. The device certificate is NOT in the System Keychain. It's in the /Library/Application Support/JAMF/JAMF.keychain

To verify

sudo security dump-keychain /Library/Application Support/JAMF/JAMF.keychain

You should see a public key, a private key, and a certificate. This of course is assuming that you are using the built-in JSS CA.

JSS CA Problems
If you have attempted to enroll the computer several times, there is a chance that the internal JSS CA is just plain mucked up and confused, and when it issues a device certificate, it can't verify it because there have been too many certs issued.

JAMF is aware of this issue. I don't think a defect is official yet.

The solution below is NOT official by any means, but it worked for me (to an extent)

1. In JSS - find the computer that is failing to enroll (should be a "No Name"). Find by MAC address, or serial number. Under Inventory / Hardware - find the UUID


2. Then navigate to Global Management - PKI - Issued Certificates


3. Search the page for the UUID you found in step 1


4. Are there more than one for that UUID


5. If yes - you may need to purge some of those via MySQL


6. Copy the DEVICE certificate name that corresponds to that UUID. Should look like "CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate"


7. Then in MySQL - as root or user with write access --

use jamfsoftware;

SELECT * FROM certificate_authority_issued where subject_name="CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate";

That should simply list all the corresponding certificates that are found. Better to do this before running the delete command, just in case. Make sure that all those found are actually ones you want to delete. Then run

delete  FROM certificate_authority_issued where subject_name="CN=C9E7JK12-GH44-63F9-8Z8B-A66777888999,OU=JAMF Device Certificate";

Obviously - replace the certificate from my example with the certificate you copied in step 6

Conclusion
Even after saying all that - we are STILL having trouble with clients who were in one JSS enrolling into a new, clean JSS. The steps above helped me with a few scenarios, but we still have many lingering failed enrollments.

Also - for anyone who "wishes" to recreate this issue, we have been able to recreate at will - even in a completely vanilla JSS or even in our JAMF Cloud test instance.

I strongly recommend you only do this on a dev JSS, but by simply enrolling over and over again (sometimes a dozen or so enrolls) - we can produce the same device certificate errors - at least in 9.72 (haven't tried other versions)

I would love to know how many of you are able to reproduce this.