@msample have you tried looking at this post?

https://jamfnation.jamfsoftware.com/discussion.html?id=8225

let me know

Thanks, Sherwin... I did see this post, but it doesn't carry a resolve...seems very sparsed with comments.

I find I only see that error now, if time is off, or if i'm running recon before casper has actually finished the enroll on imaging.
- RD

I'm encountering this on a regular basis post-enroll, we just updated from 9.63 to 9.65. Not sure if it's related or not.

As rderewianko said, I've noticed that when the time is slightly off it will give the error. Just like a kerberos token requires time to be synced, jamf requires it as well.

I usually just restart their mac and run recon afterwards which would correct the signature error it throws.

@dferrara ...@jjones....I found a pretty slick command line that eventually helped me get things back into sync.

Try these two commands from the mac you're trying to enroll:

sudo jamf enroll -verbose

then...

sudo jamf enroll -prompt

This should prompt you for the JSS login, and password.

Eventually I could recon the system, and I didn't get the device error message.

Awesome, it works! Thanks @msample!

I am starting to see this since upgrading to 9.65. Computers that were imaged fine with 9.65, randomlmy the next day they get device signature errors. Has anyone gotten anywhere with support troubleshooting the issue? Support telling me to just re-enroll isn't a good enough answer in my opinion. I have no idea what clients aren't talking to the JSS without trying to judge based on inventory times, etc.

I ran across this issue after our Certificate expired. required re-enrollment.

I've seen this before and could fix it, but now I'm getting this on one particular Mac and I've not seen it before. Just for posterity's sake, I'm putting it here. For the moment, I've been unable to fix it remotely via the command line with attempted re-enrolls, etc. I'm now asking the user to try and manually re-enroll.

From the jamf.log:

Fri Sep 25 12:00:03 <snip> jamf[1448]: 

There was an error.



     Unknown Error - An unknown error has occurred.



Fri Sep 25 12:08:10 <snip> jamf[1765]: 

There was an error.



     Error enrolling computer: Unknown Error - An unknown error has occurred.

@yellow try resting PRAM/NVRAM.

The odd time I've tried EVERYTHING & still now joy, that worked.

I am getting this error now after upgrading the JSS from 9.72 to 9.81. Is re-enrollment the only way to fix it? That would be a huge pain for me...

Edit - we just reverted our JSS back, had too many errors. Will do more testing before we upgrade.

I've seen this in our environment occasionally when we forget to plug in a network cable after the imaging reboot. I've also had to do the sudo jamf enroll -prompt method when it happens.

Can confirm that the 'Sudo jamf -enroll -prompt is successful in stopping the errors.. Just had the same issues here.

This was after upgrading from 9.65 to 9.8

We discovered recently that the sudo jamf -enroll -prompt sets the management account to the account you entered credentials for in the SSH portion of the command. Casper Remote might have a problems.

Could use CasperCheck to get the Mac clients to re-enroll themselves
https://derflounder.wordpress.com/2014/04/23/caspercheck-an-auto-repair-process-for-casper-agents/

I found if I removed jamf:

sudo jamf removeFramework

...and ran the QuickAdd installer again, it got rid of this error. Our JSS cert is self-signed which may also be a factor. I recently had to renew the cert. We are using 9.82.

I use a script (based heavily on something that @rtrouton created (check out his blog for more great stuff: https://derflounder.wordpress.com)), that pretty much helps me out when I have issues that really need a 'nuke-from-orbit' solution, but the Mac is not physically accessible to me or a field tech.

#!/bin/bash



qaURL="http://server.location.edu/QuickAdd.pkg.zip"





if /sbin/ping -oq anotherserver.location.edu &> /dev/null



    then



    /bin/echo "grabbing package"

    /usr/bin/curl --silent --output QuickAdd.pkg.zip "$qaURL"



    /bin/echo "unzipping package"

    sudo unzip QuickAdd.pkg.zip -d .;sudo rm -rf __MACOSX



    /bin/echo "updating time"

    sudo ntpdate -u $(systemsetup -getnetworktimeserver|awk '{print $4}')



    /bin/echo "removing jamf framework"

    sudo jamf removeFramework -verbose



    /bin/echo "installing QuickAdd package"

    sudo installer -dumplog -verbose -pkg QuickAdd.pkg -target /



    /bin/echo "running a(nother) recon"

    sudo /usr/local/bin/jamf recon -verbose



## Thanks to Rich Trouton for the following gem!    



    /bin/echo "installing CasperCheck"

    sudo /usr/local/bin/jamf policy -trigger installCasperCheck





    /bin/echo "flushing policy history"

    sudo /usr/local/bin/jamf flushPolicyHistory



    /bin/echo "running policy"

    sudo /usr/local/bin/jamf policy -verbose



else



/bin/echo "Can't reach Casper.  Quitting."



fi



exit 0

I stage this on all Macs via policy and if there's a Mac that just isn't behaving properly for whatever reason, as long as I can ssh in, I can run this script and reset the Mac's enrollment. Quite useful for "device signature" issues (which is what I intended it to be used for initially), or devices that haven't been seen in a long time, or just plain wonky stuff.

You just need to stage a QuickAdd package on an accessible web server to your network's location.

Again, all praise to @rtrouton.

Hope it helps you too!

Does anyone know what causes this Device Signature issue? As we are starting to see this occuring when we are reimaging some of our Macs.

@DanJ_LRSFC is the JSS SSL cert internally signed? I've seen this immediately after imaging myself, usually if autorun imaging is set:

$sudo jamf policy -verbose
verbose: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}

There was an error.

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

We are seeing this sporadically when enrolling as part of the 9.96 Imaging workflow:

jamf[2720]: Error Domain=com.jamf.jamfsecurity.error Code=-25300 "The specified item could not be found in the keychain." UserInfo={NSLocalizedDescription=The specified item could not be found in the keychain.}

Running "jamf enroll -prompt" fixes us back up after installing a createusrpkg (our management account is created at enrollment) of our management account.

I have a ticket open with our TAM.

Just wanted to chime in on this that we have now seen this as well on 2 of our Macs. We've been running 10.10.6 since July 2016 and only just started running into this issue when reimaging machines. Never ran into this prior. We're still on JSS 9.82.

My workaround was just delete the computer record from our JSS and reimage again.

I'm going to reach out to our TAM this weekend.

I would suggest that anyone who is seeing this issue reach out to their TAM. I was able to rule out any of our packages causing this by creating a new configuration with only our 10.11.6 base (AutoDMG), and the machine WILL NOT enroll as part of imaging. Having the only work-around be to pre-delete Macs before imaging them is not acceptable, as we are not going to be giving out local support folks rights to remove machines from Jamf. It is VERY strange that this just popped up out of the blue, and is looking like a defect in the product with no immediate timeline for fix.

Not ideal, but in theory you can add a post install script to your imaging workflow calling the API to delete the computer record. Since enroll is the last step in the imaging workflow, this should work assuming the computername hasn't changed. Roughly something like this:

#!/bin/sh





machinename=`scutil --get ComputerName`

jssURL=""

apiUser=""

apiPass=""





id=`curl -sfku ${apiUser}:${apiPass} -H "Accept: application/xml" ${jssURL}/JSSResource/computers/match/${machinename} | xmllint --format - | awk -F'>|<' '/<id>/{print $3}'`





if [ -n $id ]; then

    curl -sfku ${apiUser}:${apiPass} -H "Accept: application/xml" ${jssURL}/JSSResource/computers/id/{$id} -X DELETE

    echo "$id removed"



    else

        echo "computer not removed"

fi

I wonder if there is a way to purge the existing device certificate via the API without deleting the entire machine. We need to keep the historical information on enrolled Macs if at all possible.