I recently needed to determine whether communication between an MDM server and a managed Mac was working, entirely from the Mac’s side. I’ll skip to the end of the story for this particular quest for truth and knowledge:

I couldn’t. If someone else knows of a way, please let me know in the comments.

What I did figure out was that you could check to see if the Mac in question is communicating properly with APNS. That is possible and you can use the information logged to the unified system log to do so. For more details, please see below the jump.

First, let’s talk about how macOS gets MDM commands from an MDM server. It receives them through a push-notification mechanism rather than by polling the MDM server directly. The sequence looks like this:

1. The MDM server asks Apple’s Push Notification Service (APNS) to send the target Mac a silent, background notification of push type mdm – a type reserved specifically for telling managed devices to contact their MDM server.

2. apsd (the Apple Push Notification Service daemon for macOS) receives that push notification over its persistent connection to Apple’s APNS infrastructure, then routes it to whichever process is registered for that push’s topic. For MDM, this is mdmclient (the MDM client for macOS), which is registered to receive push notifications which use one of the two following push notification topics:

• com.apple.aps.mdmclient.agent.push.production: This topic is for the MDM user channel
• com.apple.aps.mdmclient.daemon.push.production: This topic is for the MDM device channel.

3. The mdmclient process, having received the notification, contacts the MDM server directly over HTTPS to retrieve and process the relevant MDM command from the MDM server.

Note: The push notification itself does not carry any commands. The notification is only a signal telling the Mac that something is waiting to be fetched from the MDM server.

If step 1 or 2 fails, the Mac never learns an MDM command is waiting for it on the MDM server, even if the MDM server itself and the Mac’s MDM enrollment are otherwise working correctly. Because receiving an MDM command is a two-party event, this is why my original quest hit a dead end. A check run entirely from the device’s end cannot fully prove end-to-end command delivery works. The only way to prove it is for the MDM server to send an MDM command and the Mac then receive the command.

However, what can be verified entirely from the device’s end is whether the prerequisites for receiving an MDM command are in place:

1. The Mac has a connection to APNS which is working correctly.
2. Verifiable evidence that MDM push traffic specifically has been getting through to the Mac.

So while I can’t check if communication between an MDM server and a managed Mac is working, I can check that communication between the APNS service and a Mac is working. If APNS communication is not working, then I know for certain that communication between an MDM server and a managed Mac is also not working. Not exactly the result I wanted, but an acceptable substitute for most use cases.

How can I check whether APNS communication is working or not? As mentioned earlier, by using the Mac’s unified logging system. In this case, you can use the log command line tool with a predicate that looks for the logging produced by the Apple Push Notification service daemon’s apsd process or the macOS MDM agent’s mdmclient process. For example, if I wanted to check the logging for the past 24 hours, I would use the following command:

Log patterns to watch for:

1. Connected to courier entries:

These log entries are written when the apsd process successfully establishes its persistent connection to one of Apple’s APNS courier servers.

These log entries appearing means that the Mac has a live channel to Apple’s push infrastructure. This is not MDM-specific, as push notifications are used by a variety of tools (like Messages, FaceTime or any other Apple or third party app which uses push notifications.)

Conversely, these log entries not appearing means that the Mac can’t receive any push notifications. In a case like this, MDM communication is definitely not working because APNS isn’t.

2. com.apple.aps.mdmclient.agent.push.production or com.apple.aps.mdmclient.daemon.push.production entries which reference acknowledges incoming message with guid:

These log entries appearing means a push notification meant for MDM was delivered to and accepted by the mdmclient process. This is MDM-specific because it means that APNS is working and delivering notifications to the MDM device channel or MDM user channel.

3. Disconnecting in response to connection failure entries:

These log entries appearing means the persistent connection to Apple’s push infrastructure has dropped. Occasional drops are normal, so these entries will appear even on Macs where connecting to APNS is functioning correctly. However, frequent occurrences being logged suggest an unstable network path to Apple’s push infrastructure.

4. -25304 keychain error code:

These log entries appearing are not actually APNS-related, but they do assist with my overall goal of determining if MDM communication is working. When these entries appear, it means the certificate identity which the mdmclient process uses to authenticate itself to the MDM server has either gone missing or corrupted in the keychain. In a case like this, MDM communication is definitely not working because the mdmclient process can’t authenticate itself when attempting to connect with the MDM server.