HI All,
"Device Signature Error - A valid device signature is required to perform the action."
I am imaging lots of student Macbook Airs this summer. I started to see this issue, which I determined to be devices not getting enrolled during the re-image process. Not ALL computers, but many. I also was seeing policy errors that LOOKED like a replication problem (policies mounting multiple drives, packages getting skipped. etc)

Then I discovered that computers imaged at another building in my absence did not have these issues.
I also was seeing VERY limited net boot capacity, (topping at about 6...) whereas at the other building it was reported being able to net boot 18 at a time.

Once I gathered this data, our network admin put my imaging switch directly into the core switch, all issues of enrollment, policy errors and net boot were resolved.
I was able to recover by running a quick add where needed for the most part.
I am not sure what these switching issues are/were....
Just saying, some issues may be environmental.

I am using JSS v 9.3.2, net booting a 10.7.5 image from a 10.9.3 and a 10.6.8 OS X server.

Sandy

Bumped into this today after building a new 10.9.4 for our newest 13" MacBook Airs. After seeing this post when the issue appeared that is when it dawned on me I forgot to make the machine clean (remove it from the jss and remove the binary framework) before constructing the image.

Resolution - Deleted the machine form the jss, removed the binary framework. Reconstructed the image and no issues afterwards.

So what @tlarkin mentioned as #6 on his list is accurate.

FWIW, we've seen this too.

Luckily the macs affected were only affected as their Time settings were out.

Correcting the time resolved for us.

FYI.

@mahughe glad it worked, hope all is well in KC

@bentoms ah yes, the good old clock skew mismatch for certificate based authentication, this is also a factor.

Thanks,
Tom

Hi I am using the fastest but rude way to do it.
1:sudo jamf removeFramwork
2: re_enroll again.

Any one know if this is fixed in JSS 9.5?

@Araneta][/url I'm having this issue after upgrading to JSS 9.5.

Edit: If I enroll VIA "sudo jamf enroll -prompt", it enrolls without an issue.

Thanks @Johnny.Kim for pointing it out.
I use the same fix(/usr/sbin/jamf createConf -url 'https://jssserver' -k
/usr/sbin/jamf enroll -invitation xxxxxxxxxxxxxxxxxxxxxxxxx) as part of my first run script to re-enroll my clients

Our Macs that were affected by this also had a problem with the time synchronization. Stopping and started the NTP fixed if for us.

I have read through this thread and I don't really see any concrete resolution to this issue. I have tried all the suggestions in this thread and I am still unable to enroll my Mac.

I am experiencing the same issue as the name of the thread (Device Signature Error - A valid device signature is required to perform the action.) when attemping a jamf recon.

I get the following error when running the quickadd package.
/var/log/jamf.log
There was an error.
Error enrolling computer: Permission Error - The user specified does not have permission to perform the action.

Any help would be greatly appreciated.

Thanks,
Archie

@archspangler Make sure that the JSS account you used to create the quickadd package is allowed to enroll devices in your "JSS User Accounts & Groups" permissions.

@jescala Verified the JSS account used has the proper permissions. Still failing with the same error.

@archspangler

We sometimes run into this as well - obviously there is not THAT fix. Last time this issue came up we updated to 9.61 (Linux manually), the Backup folder we usually create under /var/lib/tomcat/webapps was the problem. After moving this to a different location and re-writing all tomcat files it worked again.

Another time we could solve the issue by disabling /Settings/Computer Management/Security/Enable SSL certificate verification. Of course, last solution was just a part time solution - means after rebooting and re-enabling it, NO ISSUES.

Also check if the specific client which shows this issue can be found under Computers. Sometimes, for any reason I don't know yet, it might happen that the framework becomes corrupt on the devices.

Hope that helps!

Still having this issue myself.

Randomly systems will "fall off" the JSS for lack of a better term. These are 10.9 MacBook Pros in our environment. A system will work for months and suddenly a user won't be able to install a new package via Self Service or we'll notice they stop reporting into the JSS.

Only known solution I've found is remove system from JSS and re-enroll. It's a hassle and requires hands-on time.

I can't yet re-produce this reliably nor have I identified a commonality among the users experiencing it.

Same for me... once a while randomly some computers stops being reporting to jss... i just install on top with the same quickadd package and starts to work again

@jmercier][/url @monogrant][/url Do the machines just check in but have "MDM Capability: No"?

script the following 2 lines, and run as a policy on affected machines (use the built-in Verify MDM Enrollment Extension Attribute to find those with: Not Enrolled as their status, and create a Smart Group with that status, then scope the policy to that Smart Group).

jamf removeMdmProfile
jamf mdm

May also want to verify that the machines have a valid serial number, and that the date & time are correct...

Actually a little % of the machines stops checking in... but the biggest part of the problem machines checks in and just stops responding to policies

@RobertHammen

The jamf mdm command is no longer valid in version 9 and above. Its been put into the jamf manage command I believe...

Gabe Shackney
Princeton Public Schools

@gshackney it was brought back in 9.6

Oooo,
Good to know! I was missing that one.

Never noticed it in the release notes I guess...

Gabe Shackney
Princeton Public Schools

It appears that upgrading to 9.62 has resolved my issues.

This issue is very much still alive for me.
I have opened a support ticket but would still love any new input others may have regarding this issue.

I was having this issue recently on Macbook Airs when imaged over netboot using thunderbolt adapters. My TAM was able to provide me with a workaround, and then the issue was resolved when I updated to 9.6.2. Be sure to replace your Casper Imaging app with the newest version.

I have not seen any instances of previously enrolled OS X devices falling out of enrollment. My issues were all at re-imaging, when the timing of the enrollment was coming before the Thunderbolt ethernet was activated.

Our environment was riddled with these errors previously, but I have not seen one in several versions.

As mentioned by others, the imaging app was a critical update for us. We place higher priority on updating this on our netboot image than we previously did.

Cheers!

just had this issue not 5 mins ago, not 100% sure why however a jamf enroll got they user going again... Now the Mac is in the database twice with two UUIDs and the same serial #.