Help with tracking down Macs that are not communicating over MDM

[howie_isaacks]

I am working on creating a good way to track Macs that are not communicating over MDM properly. I have several Macs that are not getting profiles installed, profile changes, and are generally not working properly with MDM communications. One way I have tracked them down in the past is to create a profile, scope it to all computers and then wait to see which Macs don't get the profile. This works, but I wanted to dig a bit deeper. I have been trying to use this command to find out if Macs are reliably working with MDM:

log show --info --debug --predicate 'subsystem == "com.apple.ManagedClient"' --last 1h

The time can be changed to what ever I want. It seems that this command is only gathering activity from the Mac, not incoming MDM activity. That's what I need. Running the command above will result in a lot of information so I have used grep to make the output more focused. So far, I haven't been able to identify communication coming from APNS.  Just running the command from a Mac that is offline will show a lot of activity. It's the logging from incoming activity that I need. I just don't know how to identify what is incoming activity. I see that the output of this command does show a PID so that is likely not incoming activity. Maybe there's another subsystem I should be checking? My goal with this is to create an extension attribute that would tell me if the Mac is communicating or not. I figure if there is incoming activity being logged, it means that the Mac is communicating. No incoming activity would mean that it's not. The EA could look like this:

#!/bin/zsh

mdmCOM=$(/usr/bin/log show --info --debug --predicate 'subsystem == "com.apple.ManagedClient"' --last 30m | grep "OUTSIDE MDM ACIVITY")

if [ -n "$mdmCOM" ]; then
	echo "MDM communication is current"
	MDMComs="MDM Good"
elif [ -z "$mdmCOM" ]; then
	echo "MDM communication is NOT current"
	MDMComs="MDM Bad"
fi

echo "<result>$MDMComs</result>"

Does anyone have a better idea for tracking incoming MDM activity? 

[Andrew_R · Accepted solution]

We had a number of Macs that had broken MDM communication a while back.. The Jamf support person I was working with gave me three EAs I could use to try and track down the problem Macs.  Hopefully this is of some help :)

profileURL=$(system_profiler SPConfigurationProfileDataType | grep "ServerURL" | cut -d'"' -f2)

if [[ "$profileURL" != "" ]]
then
	echo "<result>$profileURL</result>"
else
	echo "<result>Not Found</result>"
fi

result=$(log show --style compact --predicate '(process CONTAINS "mdmclient")' --last 1d | grep "Unable to create MDM identity")
	
if [[ $result == '' ]]
then
	echo "<result>MDM communicating</result>"
else
	echo "<result>MDM broken</result>"
fi

theIDs=$(security find-identity -v | awk '{print $3}' | tr -d '"' | grep -E '^[A-Za-z0-9]{8}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{4}-[A-Za-z0-9]{12}$')

if [[ -z "$theIDs" ]]
then
	echo "<result>ERROR - There appears to be zero keychain identities matching a UUID on this system.</result>"
else
	for i in $theIDs
	do
		info=$(security find-certificate -c "$i" | grep issu | awk '{print $6, $7, $8, $9}' | tr -d '"')
	
		if [[ $info == *"BUILT-IN CERTIFICATE AUTHORITY"* ]]
		then
			expiry=$(security find-certificate -c "$i" -p | openssl x509 -noout -enddate | cut -f2 -d"=")
			echo "<result>$theIDs + $expiry</result>"
		fi
	done
fi

[howie_isaacks]

Thanks! I got these from Jamf too. They have helped a lot. I was able to use them to create two smart groups, one for "bad" communication and one for "good" communication. I also created a feature request for the criteria to be built-in to Jamf Pro.

[aparten]

This is great info! Sorry for resurrecting an old thread, but how did you end up resolving your issues? Did you just have to re-enroll those Macs with broken MDM communication? Or did you find any decent way to automate/semi-automate the fix?

Thanks!
Alex

[howie_isaacks]

There's nothing wrong with resurrecting an old thread. We don't all have the same problem at the same time! Unless someone has a better way, the only way to fix a broken MDM situation is to re-enroll the Mac. The command "sudo profiles renew -type enrollment" will work on Macs that are in Apple Business Manager and scoped to a PreStage. For user-initiated enrolled Macs that are not in ABM and scoped to a PreStage, "sudo jamf enroll -prompt" will re-enroll the Mac. The second command will prompt for a username and password of someone who is authorized to enroll Macs. Sometimes I have had to run "sudo jamf removeFramework" first to remove all of the Jamf Keychain items. Since enrollment involves the ability to communicate over MDM using a method for re-enrollment that requires MDM like the Jamf management framework command in the API may not work. Fortunately for us, we have seen only a few Macs not communicating properly over MDM. When I first started this it was a lot more. I think that there were some network issues that were causing a lot of our issues. These network problems appear to have gone away.

[aparten]

Gotcha, thanks for the insight! I pretty much assumed re-enrollment would be the solution.

From my research, it also seems that network-related issues during MDM communication are often to blame for the broken connection. Hopefully one day we'll have some sort of "self healing" in place for when this does occur.

[howie_isaacks]

I did experiment with using a script that leverages the Jamf API to run the Jamf management framework. It worked a few times. I haven't had time to focus on making it work more reliably. Others who have more experience with the API have written scripts to "heal" Jamf Pro. 

[tamirge]

Hi @aparten ,
You can look at this :
https://www.modtitan.com/2022/02/jamf-binary-self-heal-with-jamf-api.html

Maybe it can give you a direction on a self healing self service ;)

[miniberry]

Thank you guys for hashing this out! I have smart groups for macs that haven't checked in with Jamf in 30, 60 and 90 days but it's not always easy to get communication restored. 
We have used 
sudo profiles renew -type enrollment
by manually touching Macs that did not check in. The interesting thing is it looked like their MDM was not expired or anything, but they were just not checking in and getting updates. Once we ran that command, all the pop ups for updates from our policies would come up, and it was catching up to everything, and it started checking in. But we noticed one device that had this command run then still failed to check in and got stuck again in a no communication state. 
Would you guys know if the command I am using is problematic and would actually break things even more in terms of communication with MDM? 
Thanks in advance!