One of the more common scenarios we encounter here in product support is that Windows desktop agent-managed computers are being forced to reboot with no option to postpone. There are several possible causes for this behavior but before we talk about mitigation, I’d like to cover some Windows Update concepts and how Microsoft Intune implements this feature.
First, it’s very important to understand that for some type of updates, if the PC is not rebooted then the patch is not yet properly applied, possibly leaving the machine open to security vulnerabilities. Because of this, the Intune team decided to take the approach of “it’s not if your machines will be forced to reboot but when”. If your environment is very sensitive to “forced reboots” then you may want to consider picking the ‘available” option instead of “required”. The PC’s will still prompt to install the updates but users could decline the installation until a later time.
Next, I encourage you to peruse this post from the Intune team regarding updates settings in the Admin Console:
My general recommendation for customers is to not accept the default scheduled maintenance time of 2:00am. Instead, I recommend choosing a time that is three hours before most users would be leaving for the day. One primary reason for this is because the maintenance window is three hours long and has some delays built in so as to not saturate customers who have limited bandwidth.
Controlling the Reboot
So if you have configured everything correctly and you are allowing the user to control the reboot behavior in your update policy, why can’t they postpone the reboot? Most likely it’s because y ou set a deadline when you approved the update. Many customers try to use the deadline setting to control scheduling behavior, however unlike in a regular WSUS scenario, we do not have an option to schedule when a particular update is installed. Instead, we allow the IT admin to schedule an update window via the Update policy workload.
Therefore, if you pick “As soon as possible”, or if the deadline time has passed, the machine will interpret this as “get it done yesterday” and ignore the update policy specified in the admin console and immediately force a reboot with no option to postpone.
Workaround: If you set a deadline, remove it
To see if a deadline has been set for an update, complete the following:
Login to Admin console.
Scroll down to Automatic Approval Rules.
Select the rule and click Edit.
Confirm if Enforce an installation deadline is checked.
To remove a deadline, complete the following:
Login to the Admin console.
Click All Updates.
Click on an update and press Ctrl-A to select all updates.
Click Decline to take all updates out of production (existing installed updates will not be removed).
Change filter to declined updates.
Repeat Step 4.
Select All Devices and click Add.
Leave Approval as Do Not Install and Deadline as NA.
This will make all updates available to machines again. Any machines that need the updates will request approvals as normal.
If you did not set a deadline
So let’s say that you did not set a deadline when you approved the update, however your users are still reporting they had no option to postpone a mandatory update. Why is that? As mentioned above, it’s not a matter of “if” but “when” the reboot occurs. The Intune service will normally only allow the user to postpone the restart a maximum of 24 hours (we’ve heard your feedback that you would like a longer time period and are investigating) so most likely the user already postponed 24 hours ago and forgot about that occurrence. Once postponed, at the next maintenance window the Update Service will notice that they missed the previously scheduled reboot and therefore can’t install any more updates until a reboot occurs. We’ve also seen instances where the device was hibernating or asleep so it was allowed to not restart for far past the normal 24-hour time window.
In conclusion, if you are still experiencing forced reboots in your environment and you would like Intune Support to take a closer look then I’d suggest making a log of the timeframe these reboots occur: Application and System Event logs, c:\windows\windowsupdate.log, and the contents of %programfiles%\Microsoft\OnlineManagement\Logs. With those, the support team can review the specific cause further.
Joel Stevens , Support Escalation Engineer Microsoft Enterprise Cloud Group