There are certain times when the device is not able to do what the server requests. For example, databases cannot be modified while the device is locked with Data Protection. When a device cannot perform a command due to situations like this, it will send the NotNow status without performing the command. The server may send another command immediately after receiving this status, but chances are the following command will be refused as well. After sending a NotNow status, the device will poll the server at some future time. The device will continue to poll the server until a successful transaction is completed. The device does not cache the command that was refused. If the server wants the device to retry the command, it must send the same command again later, when the device polls the server. The server does not need to send another push notification in response to this status. However, the server may send another push notification to the device to have it poll the server immediately.
 

• The NotNow response is caused when a policy is deployed from the XMS to an iOS device that is locked that requires user interaction.
• The NotNow is reproducible in 10.4 and 10.5.
• The difference between 10.4 and 10.5 is that on 10.4 the exception can be seen in the server logs, but they can't be seen on the console, whereas on 10.5, this exception can be seen not only in the server logs, but also in the console. 
• This has caused some confusion on the customer side, but is not an issue.