After upgrading to V9.01 I'm seeing some machines now say " Device Signature Error - A valid device signature is required to perform the action." while trying to run recon. I've re-enrolled the machine, it works for a day or so but then reverts back to this message.
I have a ticket open on the same issue. I think I just figure it out. The problem resides on the device certificate and the Certificate Authority that are pulled when enrolling. It could be a bug on the server or on OS X client, either way the solution was... (These steps even work on 10.9 beta 7).
Step 1. Reset the Login Keychain
Step 2. Remove any instances of the JSS CA in the keychain
Step 3. Open terminal and ran "sudo jamf removeFramework"
Step 4. Remove all related JSS preferences in /Library/Preferences and /Users/username/Library/Preferences
Step 5. Reboot
Step 6. Re-enroll by downloading the QuickAdd.pkg from the JSS and installing the pkg.
Step 7. Open keychain Access and checked that the device CA and JSS CA were installed.
Getting same error on building, re-enrolling does fix but shouldnt be needed on all new builds.
I haven't even setup buildings.. I know i'm seeing it on clients that were fine before upgrade..
Same issue here.
thanks, truncated here but on email comes through as:
--------------------------------
Same issue here. Running this with ARD fixes most but not all computers.
rm -rf /Library/Application Support/JAMF/Downloads/.*
---------------------------------------------------
Anyone know if this contains a cert or anything else to give a clue here, is empty on my test machine here.
Doesnt work here in any case.
I know I posted a possible solution, but apparently was only temporarily. So out of frustration I renewed the MDM Push Certificate in JSS, even when it still showed active till 2014.
So far its working since today in the morning. Then I re-enrolled the Macs using the sudo jamf enroll -prompt.
In imaging (i meant this when i said building earlier) we have been advised to try using a quick add package as a delayed at boot install within a configuration rather than the built-in management settings. Seems better so far.
try removing the apsd.keychain from /Library/Keychains then re-enroll the device or reinstall the quick add
we are also getting this issue, as well as our homeShare mounting is broken.
Hi guys, same issue here, any easy fix for massive number of computers?
Sorry, got confused by the -prompt feature, working fine now.
Hrm... ditto here. Most computers imaging, recon(ing) and running properly. However, a number of them will function properly . It certainly looks like it's an issue with the device CA. However, I'm having a heck of a time trying to figure out why, after some random IT problem solving it will start to function again almost magically and then stop after 12 or so hours. Actually, once it stops working (the ability to enroll machines) then anything we try to re-enroll gets a corrupted CA. Man, does it feel like the JSS is corrupting the CA's it issues. Unfortunately, I'm not quite sure where to start checking that.
currently the 'temporary' solution involves running
sudo update_dyld_shared_cache -force
... and then we can run the enroll or quickadd. Unfortunately we still have no idea why properly reporting systems are falling back this way.
Re-enrolling works for me but its badly killing the build process as i have a set of policies set to run after imaging and the process dies half way. Please everyone log with JAMF if you are experiencing this. They are looking into this.
The dyld shared cache command ran, but I cannot re-enroll via OTA or manual quick-add. I also tried removing the apsd.keychain and tried to re-enroll... still no dice. The QuickAdd package fails.
The only thing that works for me is remote enrollment from the Recon app. I don't know if it will keep its enrollment. I will have to watch it. I have a webex scheduled for Monday to see if we can correct this.
to make an addition here. Our problem ended up being the result of a mixture of things.
1) The probable beginning on a HDD failure on the drive that hosted the JSSs MySQL database (though no failure could be detected of course!). A swap out to an SSD for the Tomcat and MySQL services solved all of our performance issues
2) There was a bug in 9.01 that caused some enrollment issues. We're still waiting to see if re-enrollment of those devices stick. JAMF just had the 9.1 and 9.11 patches and we're holding hope that it solves any lingering issues from that!
3) We did have some network ARP caching issues contributing the DNS timeouts during early recon processes that have been resolved.
4) We used this as an excuse to improve the network topography surrounding the various services related to the Casper suite.
As for a mass-re-enrollment I have the following suggestions.
-Using packages (or any other packaging tool... though composer might have issues with this)
Create a package with the following
1) A package including at least the following
-Script that includes the following:
-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
*In some circumstances the jamf software keychain items will need to be removed. I haven't tried scripting that yet. I'm sure that someone here could come up with it quickly if I don't happen to sit down to it Monday.
-(possible) restart after those scripts
-install quickadd.pkg. If after reboot then as a as first run or temp launchd item.
I've run these processes on the few units I've had to deal with after the rest of the cleanup so something like what I've mentioned could run easily from ARD.
If you're having other issues then run sudo jamf enroll -verbose and post the results here. I have a funny feeling that your conference call will go over a lot of this sort of thing. I had one with JAMF late last week regarding very much the same stuff.
The 9.1 and 9.11 patches did not solved the "Device Signature Error". Still have this error after remote recon a machine:
*Mon Sep 23 09:22:38 mbpr-ps jamf[32488]: Enforcing management framework...
Mon Sep 23 09:22:40 mbpr-ps jamf[32488]: The computer was not enrolled in MDM with the JSS. The device certificate did not install.
[...]
Mon Sep 23 09:53:44 mbpr-ps jamf[45650]: Checking for policies triggered by "recurring check-in"...
Mon Sep 23 09:53:44 mbpr-ps jamf[45650]:
There was an error.
Device Signature Error - A valid device signature is required to perform the action.*
apparently 9.11 is mostly to do with ios7, there may be a fix for this in the next update after. Turning off "certificate-based authentication" altogether in security does seem to resolve for us (but will also knock out mdm if you have that selected), have also been advised updating the cert might help.
update_dyld_shared_cache -force
Worked for me! Thanks.
concerning Step 1. Reset the Login Keychain
how did you manage to do that. do you have a command line for that ?
mbracco - something like this:
rm /Users/myusername/Library/Keychains/login.keychain
I found that the problem with the mdm not enrolling error seemed to be a time out or something.
I created my own quickadd package and postflight script that went something like
jamf enroll -invitation 234234123412341 -noManage -noRecon
jamf recon
jamf manage
jamf manage
jamf manage
I ran the jamf manage 3x times to ensure that it would enroll the device, so far this has been 100% successful.
YMMV
I am now seeing this on a workstation that WAS enrolled but lost all management/communication abilities from JAMF and I'm getting it on my attempts to re-enroll it. So far tried a few of these steps and nothing seems to work.
Any one have a fix for this?
i have this on 29 machines.
On my machine i
- remove jamfFramework
- deleted /Library/Keychains/apsd.keychain
- Rebooted
- Downloaded a fresh QuickAdd pkg and installed it
cant do this on 29 machines
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.