Device Signature Error Extension Attribute

Eigger
Contributor III

Is it possible to create an Extension Attribute to list all Clients that have "Device Signature Error" and then run script to re enroll if possible.

JamfPro Ver. 1010.1
Clients: MacBook Air (13-inch Early 2015)

8 REPLIES 8

cainehorr
Contributor III

We've been seeing a TON of Device Signature Error issues recently on both macOS 10.13.x and 10.14.x since upgrading to Jamf 10.10.1.x

Re-Enrolling doesn't always resolve the issue for us.

We even see the issue on new-OOB devices.

We have an open-ticket with Jamf but to date, not fix or workaround has been provided.

Our current internal workaround has been to wipe hd, re-install macOS, and hope for the best.

Any suggestions are greatly appreciated!

zachary_fisher
New Contributor III

I’ve seen some success doing sudo jamf removemdmprofile —- sudo jamf trustjss — sudo jamf mdm. Other times it still errors out so using a quick add (with the enrollmentcomplete part removed) solves this issue as well. Since computer isn’t talking to jamf it’s hard to write an extension that reports this. I guess it’s possible to install a local script that does a check and uploads a value to jamf via api?

russeller
Contributor III

Maybe something that uses the logic that Rich made for this: https://github.com/rtrouton/CasperCheck

seann
Contributor

I don't think an extension attribute would be useful if the jamf framework is busted on the machine.

As mentioned CasperCheck may point you in the right direction.

Another idea is to use osquery, elk, or custom log collection to find machines showing that error in /var/log/jamf.log. Of course you'd need to have all of this in place first.

A list of bad devices could then be fed into jamf recon or ARD, but a potential complication with 10.14 is manually approved MDM.

Self healing is a feature sorely needed by Jamf as we've also been bitten by devices being unmanaged after an upgrade.

Eigger
Contributor III

Thank you for all your Ideas. I wish Jamf can go ahead and implement something like a persistent notification system that will tell the user to contact IT when the client stops communicating with JamfPro after a set amount of time.

mm2270
Legendary Contributor II

A notification system like described above sure does sound like a good idea. An end user isn't going to know when things are broken unless they tend to use Self Service a lot and they see that they can't run Self Service policies. Other than that, there really isn't a visible way to know when a Mac isn't checking in and something may be broken.

Back when I was playing around with BitBar to create a custom menu bar item, that was actually something I was working in to my script/custom menu. Basically a way to see when your Mac last checked into Jamf Pro, more or less by scanning the jamf.log and some other things. If the last time of check-in went beyond a set threshold, it would turn the text in the menubar a different color, and if it was really far out of date would do something like flash the icon to get the user's attention. As our Jamf instance was reachable externally, even if a Mac was off the network, it should be checking in if in use and on an internet connection. So it was a decent way to highlight a potential problem.

Eigger
Contributor III

@deanhager Please Please Hire this Guy! ^

mschroder
Valued Contributor

It is a shame that the information about underlying issues is often clearly written to the log files, but not shown to the user. Why not? If the SelfService app or the framework can write it to a logfile it can also show it in clear text to the user instead of just whining "can not connect to the server". Jamf, there is room for progress, please profit from this opportunity.