Device Signature Error Extension Attribute

[Eigger]

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)

[cainehorr]

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]

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]

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

[seann]

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]

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]

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]

@deanhager Please Please Hire this Guy! ^

[mschroder]

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.