http://m.youtube.com/watch?sa=X&v=7xNSgBkum7o&ved=0CAsQqwQ&ei=Aip9UuaIO8eX1AXUioHwBw&desktop_uri=%2Fwatch%3Fv%3D7xNSgBkum7o%26sa%3DX%26ei%3DAip9UuaIO8eX1AXUioHwBw%26ved%3D0CAsQqwQ

I have a support ticket open with JAMF. I have tried everything in this thread and still am getting the error. Anyone have any new updates?

*fingers crossed*

ndudley, did you get any response from JAMF?

I am running into the same issue. For me running update_dyld_shared_cache -force then re enrolling works.

Dan

I did. They said they are aware of the issue and recommended I update to 9.21. They were unable to provide an eta for when this issue will be resolved.

It now seems very hit or miss. I had a computer that wouldn't enroll, but waited a day or so and it enrolled. Hopefully they come up with a fix soon.

Sorry. Duplicate post.

@tkimpton][/url You should be able to regenerate apsd.keychain without restarting by:

• launchctl stop com.apple.apsd


• rm /Library/Keychains/apsd.keychain


• launchctl start com.apple.apsd

My two cents on the issues:

Running a Remote Enrollment in Recon fixes the issue every time.

Thankfully we are not deploying a fleet of new units right now.

Just a heads up that you may get this error if the date on your system is not set correctly. The JSS will think that the certificate is invalid.

Same issue here guys.

Image new machine, works great.
Reimage this machine, get the error.
Delete the computer object from the JSS and reimage, works great.
Reimage again, get the error.

Will be submitting logs to Jamf today.

Running Imaging/JSS 9.21.

Cheers,
Gav

Ok, this is a bit weird: I have a new 9.21 JSS that I'm setting up. As a test for migration, I grabbed the QuickAdd.pkg obtained from the /enroll page (using another machine) and tested pushing this out to a client via policy.

Policy says it never ran on the old JSS - kind of expected, if a change is made it won't get the report.

Machine does not show up in the new JSS. Did a command-line recon on the client and got the Device Signature error (which led me to this discussion). Tried sudo jamf enroll first, but it complained about needing an invitation or credentials, so I went with sudo jamf enroll -prompt, and entered in my credentials.

It then enrolled the client - into the new JSS. Strange...

Recently upgraded to 9.21 (from 8.72) and I am having this issue as well. For me, the re-enrolling through Recon seems to resolve it, but I just discovered it recently so I am wary that it may return based on this thread.

How do you know if this is an issue without manually running the terminal command on each of the machines?

I have ran the terminal command "sudo jamf policy" on a few of my machines that have come into the helpdesk for other issues and I am seeing this error also.

In the web console of the JSS the machines seem to look fine, the last check-in and last inventory has a current date, but the machines are still getting the Device Sign error.

This has occurred for me on 9.21 with 2 different machines. The first was newly imaged and reconned. It wasn't working yesterday but i was able to remotely install a package today. The second machine was failing this morning and I used recon to do an remote enrolment and was able to install the package after.

I will be upgrading to 9.22 this week.

I was getting the same "Device Signature Error - A valid device signature is required to perform the action" error on new machines I was deploying and once I noticed the time was off on the client machines compared to the server, I forced it to update its local time to the time server and once I did that they all started enrolling fine immediately.

I had a computer which couldn't be enrolled, not with Recon.app, nor with a Quick-Package. During the installation of the Quick-Package I get this error:

Error enrolling computer: Unable to establish trust with the JSS - Could not connect to the JSS

But the jamf binary was installed and this commando executed on the client helped at least:

sudo jamf createConf -server [servername] -k

I too am experiencing the following:

Connection Failure "the connection host jamf.f5.com is not accessible"
+
Device Signature Error - A valid device signature is required to perform this action

ran sudo jamf manage

gettingmanagement framework from the JSS...

There was an errors

Device Signature Error - A valid device signature is required to perform this action

ran :
-sudo update_dyld_shared_cache -force
-sudo jamf removeFramework
-sudo rm (-rf) (path to any JAMF resource: i.e. /Library/Preferences/com.jamf* and /Volumes/"Volume"/Users/*/Library/Application Support/JAMF
reboot
install quickadd

is everyone just adding packages OVER an apple installed OS? or are you replacing the OS during imaging?

has anyone seen this resolved?

: )
those errors seem to be benign.

I pared down my config to JUST install an admin user and management account.

Now, using Casper imaging I simply install just a local admin (using MagerValp's CreateUserPkg app) as a first run installer, reboot and login to local admin and open console.

I still see Connection Failure "the connection host jamf.f5.com is not accessible" BUT after "enforcing management framework" runs 4 or 5 times, 5min, the management account is created then i see "Device Signature Error - A valid device signature is required to perform this action" then "enforcing management framework" runs again and BAM!!!! polices flow...

Sweet Relief!

We @ Sydney Uni are getting some similar results

Situation 1.
If we use simple Configurations with imaging an existing machine in the JSS, everything works fine. The machine reboots, runs through the enroll process, flushes all policies assigned to it, in short everything works as expected

Situation 2.
If we use a even slightly complex configuration with imaging an existing machine in the JSS. After imaging and rebooting totally nothing works ie enroll doesn't complete properly, get device signature errors and policies don't flush. When I say complex configurations, this includes simply running a simple configuration with autorun data, a smart configuration, and/or packages set to install after imaging time.

Interesting is that if we have scripts set to run at reboot running in a "simple" configuration. We get a great deal of inconsistency. Sometimes the script/s run, sometimes they don't, sometimes only 1 runs, sometimes all run. Its very hit or miss.

Situation 2 is really annoying to us as sometimes we have to image 50 or so machines per lab on mass for various reasons. Autorun would be awsome ! but we can't use it since the machines don't end up working with Casper after imaging. In addition if we delete the machine out of the JSS we start losing data for that machine that management love to see ie Application usage logs, login logs, etc

We are also seeing this as well. Wondering if this is related to the bug that shows up in casper imaging in 9.23 and 9.24 where it does not show all the smart configurations, (thereby forcing you to use a "simple" base configuration). I have had nothing but inconsistent issues since moving to Casper 9.
I wanted our organization to be prepared for 9.3 and the new MDM features for iOS.
I had done some testing with the beta of 9 and a little bit with 9.1 but didn't see most of these issues until we fully migrated over. I just need to get through a few images and am quite stuck.
Tried adding the quick add pkg but guess I'll try some of the other suggestions listed here.
Gabe Shackney
Princeton Public Schools

Luckily for us we only had a few machines out a few hundred with this issue. Sadly the only way to get passed the device signature error or inability to install quick add package via ARD was to manually reimage via carbon copy cloner or a restore in disk utility. Once we did that though enrollment went fine no matter the method.
We had tried deleting the JAMF keychain and removing framework as well. Also, this only seemed to be a factor on 10.6 machines.

My problem was solved with entering all local addresses to be bypassed in the proxy.

My issue with failed enrollment at the time of imaging has been resolved in the latest 9.3 release.

Did anyone have a good way to tell machines that were experiencing the device signature error? At one point I thought I saw an extension attribute that searched the console logs for this error. I still see a few machines with this, but I believe it is because of us using a different account for the push certificate for a brief period and now I just need to find the group of them and re-enroll them.

Gabe Shackney
Princeton Public Schools

Wow.... @Suggett

We are getting exactly the same thing... we have slightly complex smart config and all you say happens to us...

you confirm that standard config works all the time ? might worth changing our strategy....

Hi Everyone,

Sorry to hear everyone is having problems with the device signature error. I have seen this happen at a few sites, and it can be caused by a few things, but are not limited to:

1. Legacy version 8 devices enrolled with the same MAC address (i.e. same USB/TB Ethernet Adapter, or TB display)


2. Migration Assistant was used from an existing managed device to a new device


3. The JAMF.keychain has somehow been corrupted, or damaged


4. Certificates have expired


5. Devices were migrated from one JSS to another and failed enrollment


6. Imaging techs bake the JAMF binary in the image

There are probably more reasons why this can happen, but those are the ones I have seen. Most commonly I have seen the issues I listed above be the culprit. Now there are several ways to fix this, and typically you want to re-enroll the device when this happens. You can choose one of the following (but not limited to) workflows:

1) If you have ARD Admin setup and can reach your Macs in your organization, a simple quickadd package over ARD can fix this.

2) Turn off certificate based authentication in the JSS and then use a quickadd package to re-enroll all your devices. WARNING - in my testing of this workflow, if you use MDM for anything (configuration profiles) and certificate based authentication is disabled, the next time it updates the framework it will remove your profiles. The plus side to this workflow is that devices check in, do not need to authenticate with the certificate, and can run a quickadd package via policy and become enrolled again, and it doesn't require having ARD, or setting up anything outside the JSS. This will remove all configuration profiles in the meantime. So, this workflow should only be explored if you aren't using configuration profiles.

3) Modify the database to ignore signatures - Contact JAMF Support before attempting this. This basically is similar to workflow 2, but should be overall safer if you are deploying Configuration Profiles at your Organization. Again, please contact support before doing this.

4) Have users enroll again via OTA enrollment. If you allow users to enroll over the air, you can have them just re-enroll themselves.

I also recommend some sort of self healing, and/or contingency plan for things like this. The last time I dealt with this, a whole remote office had been migrated to new Macs with migration assistant. I came up with a launchd and a script that will basically self heal the binary and re-enroll the device if communication fails. I have been exchanging emails with @rtrouton][/url on how to improve this. I have put it on JAMF Support's GitHub account, and would love to see some feedback, some forks, and improvements on it. There are two methods of enrolling devices, one is a cached and/or curl'd down quickadd package, another is just an enrollment script that downloads the binary from the web app.

My idea is not to rule with an iron fist as a system administrator with this script/launchd solution. I see it more as a self healing solution. That is because there is no need to fight end users that have local admin rights. End users with local admin always win. I have tested this in multiple scenarios in a very small virtual test environment. So, this is still proof of concept and would need to be tested on your end.

https://github.com/JAMFSupport/autoenroll

Maybe some of you can improve what we came up with.

Hope this helps!

Thanks,
Tom