Understanding and Resolving NotNow Responses on MDM-Enrolled Devices

Overview

When managing Apple devices through MDM, you will inevitably encounter the NotNow status response. This response is a built-in part of Apple's MDM protocol and indicates that a device has received a command but is unable to execute it at that moment. While a NotNow response is often benign and self-resolving, it can sometimes signal a deeper issue that requires intervention. This article explains what triggers a NotNow response, which commands are exempt from it, how to distinguish between a temporary deferral and a genuinely stuck device, and what steps to take when devices remain in a NotNow state.

A NotNow response is the device's way of telling the MDM server that it acknowledges the incoming command but cannot execute it at this time. After returning a NotNow status, the device will independently contact the MDM server again at a future point. It continues polling until a successful transaction completes. The device itself will handle follow-ups to Addigy on its own.

Identifying Devices in NotNow state

You can identify devices in Dashboard > Events, or via GoLive > Events. Here is an example of what that event will look like:

As you can see in the 'Details', it will report a reason for the NotNow if one is available.

Common Conditions That Trigger NotNow

Several device states can cause a NotNow response. These vary slightly between iOS/iPadOS and macOS, but the most frequent causes include:

• Device is locked or at the login screen
  Many MDM commands require the device to be unlocked. If the device is locked, some MDM commands will always return a NotNow until the device is unlocked.
• Device is asleep or in a low-power state
  macOS devices in sleep mode or Power Nap may accept push notifications but defer full command execution until the system is fully awake. Power Nap permits limited background activity, but the MDM client may still return NotNow for commands that require deeper system access. This is often logged on the device as occurring during a "DarkWake" state. This is an example of a message that will be logged in the macOS unified logging system:
  2023-03-03 09:08:29.810 Df mdmclient[30513:2fbdb] [com.apple.ManagedClient:MDMDaemon] [0:MDMDaemon:<0x2fbdb>] Responding 'NotNow' to server request: ProfileList for: <Device> reason: Not supported during DarkWake
• Device is mid-boot or freshly restarted
  After a restart, certain commands will not execute until the device has been unlocked for the first time. During this window, the operating system has not yet loaded all protected services, and the device will respond NotNow to commands it cannot yet fulfill.

Commands That Should Never Return NotNow

• Security Information - Queries various security-related info
• Install Profile - Handles the installation of Profiles and Declaration Settings

Apple designates a set of MDM commands on iOS that are guaranteed to execute regardless of device state. These commands will never return a NotNow response, even if the device is locked. They are:

• Device Information - Queries basic device attributes
• Profile List - Returns the list of installed configuration profiles
• Device Lock - Locks the device immediately
• Erase Device - Initiates a remote wipe
• Clear Passcode - Removes the device passcode
• Certificate List - Lists installed certificates
• Provisioning Profile List - Lists installed provisioning profiles
• Installed Application List - Returns all installed applications
• Restrictions - Queries active restriction settings

These commands are considered critical management and security operations. Apple guarantees their execution so that administrators always retain the ability to query essential device information and perform emergency actions like locking or wiping a device, regardless of whether the device is currently locked, asleep, or otherwise occupied.

If you observe NotNow responses for any of the above commands, this is abnormal behavior and may indicate a more serious issue. If you are seeing this, please review this section: Devices Stuck in a NotNow State: Causes and Remediation.

NotNow Doesn't Always Mean the Device Has Lost MDM Communication

One of the most common misconceptions about the NotNow status is that it indicates the device has gone offline or stopped communicating with the MDM server entirely. This is not the case. A device that returns NotNows is, by definition, actively communicating. It received the command, connected to the MDM server, and responded with a status. The communication channel is working; the device is simply unable to fulfill that particular request at that moment.

This distinction matters for two reasons:

First, a NotNow response is itself proof of connectivity. If a device were truly offline or unreachable, the MDM server would see no response at all, not a NotNow. Administrators should be careful not to conflate a pending or deferred command with a lost device. The MDM console may show commands in a "pending" or "failed" state that are actually just waiting for the device to reach a state where it can process them.

Second, a device can be stuck in a NotNow loop while still being reachable. This is a more subtle problem. The device may be responding to the server, even polling regularly, but every command it receives triggers a NotNow because the underlying condition preventing execution has not changed. If a device is responding NotNow to every single MDM command you attempt to queue, or responding NotNow to commands that should never return this status, please consult the next section.

Understanding this distinction can help avoid unnecessary troubleshooting steps (like re-enrolling devices that are actually communicating fine) and instead focus on resolving the root condition causing the persistent NotNow.

Devices Stuck in a NotNow State: Causes and Remediation

While most NotNow responses resolve on their own once a device is unlocked, woken up, or reconnected to a network, some devices can become persistently stuck. The following sections cover the most common causes and the corresponding remediation steps.

1. Is the device locked? If the device is locked, the commands returning NotNow may require the device to be unlocked. Verify with the user whether the device is online and unlocked.
2. Restart the Device. A restart is often the simplest and most effective remediation for a device stuck in a NotNow state. Rebooting forces the mdmclient process and all associated system services to reinitialize. After the restart, have the user log in, then check in Addigy if the commands are still returning NotNow.
3. Disable Advanced Data Protection. For iOS/iPadOS devices, when Advanced Data Protection iCloud is enabled, it can sometimes cause NotNow events to occur.

Unfortunately, remediation steps are somewhat limited when a device is consistently responding NotNow to all commands. If the steps above do not help, please do not hesitate to reach out to our support team. Depending on the situation, we may be able to review device logs and get more info on why this is happening.

Summary

The NotNow response is a normal and expected part of the Apple MDM protocol. In most cases, it resolves without intervention. When it persists, the key is to identify the root condition, whether that is a physical device state, a hung system process, or a deeper enrollment issue, and address it directly rather than assuming the device has lost contact with MDM.