Howdy folks – I’ve got a discussion topic for today that I want to write about, mostly to save your sanity where I lost mine. That topic being the “Scheduled Install and restart” option in Windows Autopatch.
Outline:
- My History
- Overview on the “Scheduled Install and Restart” Feature
- What Does “Scheduled Install and Restart” Mean?
- Troubleshooting, and What Does Microsoft Have to Say?
- Conclusion
My History:
I want to be very clear right off the bat that this is a topic I have spent over a year working on with Autopatch Support, Windows Update support (Windows D&D SMEs), and have even discussed at MMS with Microsoft (Autopatch and Update) engineers. During that time, there have been MANY MANY changes, updates, GUI improvements, clarifications, and outright rejections of prior explanations with new ones taking their place etc, and I can only assume that will continue to be the case going forward, so I apologize if anything I say here proves outdated or wrong.
I also firmly believe that what I am about to explain is supposed to work… I don’t even want to say it necessarily doesn’t currently have and/or there is not a correct combination of things that will make it work today, but ultimately, Microsoft support, both on the Autopatch and Update side, with over a year to figure it out, could not get it to work as Autopatch support claimed it should.
Maybe one day it will get figured out. Again, my purpose for writing this is, assuming it should work as it sounds, to save your sanity if you are struggling to get it to work.
As a last tid-bit to this section, yes, this is a strange option to want to use, and any device needing such careful updating probably shouldn’t be running an endpoint OS in the first place. That said, it is what it is, and there was a need to be extra careful and try to ensure that certain devices update and reboot only at certain expected times/dates as best as possible, and this option certainly sounded like it did exactly that.
Overview on the “Scheduled Install and Restart” Feature:
If you use Autopatch and have ever played around in it, you’ve probably noticed the option for “Scheduled Install and Restart.”
During my time working on this, the topic gained an explanation (originally we had to contact Autopatch support to confirm this) stating that “This setting will only allow devices to install and reboot at the specified time +/- 15 minutes. If a device doesn’t finish installing in that window, it will wait to reboot until the next one.” The option then provides the means of designating a time for “Scheduled install and restart” such as a certain week(s) of the month, on a certain day or days of the week, and at a certain time, along with controls over the Windows update notification settings. See the example below of how this looks today.
What Does “Scheduled Install and Restart” Mean?
Now I don’t know about you, but the name “Scheduled install and restart“, and the above description explaining that the device “install and reboot at the specified time +/- 15 minutes”, would, well, suggest that the expected behavior is to install updates and then reboot to apply that update either then (+/- 15 minutes), or the next time that schedule window comes around. That is indeed how Autopatch support confirmed it should function before that description bubble was even present.
While the installs were reliably processed at the correct time, the reboot not happening, or happening at a completely unscheduled time, is what we spent a year working with Autopatch support, and then later Windows Update support when Autopatch support gave up, trying to make it happen, and never could. So the incredibly brief version of this article would be “if your scheduled install and restart doesn’t restart at the scheduled time, or restarts at bizarre other times, you are not alone.”
Troubleshooting, and What Does Microsoft Have to Say?
As far as troubleshooting, early on, much effort went into nuking the devices, getting clean ones, ensuring no unexpected registry keys or policies were in place, experimenting with adjustments to active hours, and playing with supported but largely not policy-based keys.
That said, the end game for this topic started with two explanations I feel the need to directly share in order, as the information is invaluable. Trust me, it’s worth the read if you are fighting this issue.
Windows Autopatch uses Windows Update for Business under the hood, which means it relies on Windows' own update orchestrator. Windows has several built-in safety mechanisms to avoid abrupt restarts, and these can override a precise reboot schedule. In short, even though you set a specific installation & restart time, Windows Update won't usually force an immediate reboot at that exact moment - it tries to ensure no users are caught off guard or working when the restart occurs. Here are the key reasons the reboot was delayed:
After installing updates, Windows typically waits before auto-restarting, even if no one is logged on. By default, the system will not restart immediately once updates are installed - it often waits on the order of a day or two as a grace period. This is meant to protect against any surprise reboots. In your case, Autopatch likely had a default "grace period" of 1 day configured. That's why after the updates installed, the device didn't restart until roughly 25 hours later - it was honoring a built-in 24-hour wait. This is normal (by design): for example, if a 1-day grace period is in effect, "the device will not restart until at least one day after the patch has installed, even if the device is left on overnight". So the 25-hour delay you observed is consistent with a 1-day grace period plus some scheduling overhead.
Even outside of Autopatch, the Windows Update service has logic to avoid restarting too quickly. If no user is signed in, Windows doesn't just instantly reboot; it will post a restart notification on the logon screen and wait a while (by default, it waits for at least 2 days) hoping a user sees it. Essentially, Windows shows "A restart is required" on the sign-in screen and gives a grace period (48 hours by default) before it forces the restart. This happens even if the PC is idle, as an extra precaution. Enabling the "Scheduled install and restart" in Autopatch did not override that default behavior. So the system installed the updates at your scheduled time, then entered a pending restart state and waited ~24+ hours before actually rebooting. I realize that's not what you expected from a feature called "install and restart," but that's how the Windows update engine behaves unless explicitly told otherwise.
Windows is very cautious about rebooting if a user might be using the device. By default, Windows will not auto-restart if a user is actively logged in. There is even a policy named "No auto-restart with logged on users for scheduled automatic updates installations," which if effective, prevents automatic restarts while someone is signed in. In practice, that means if any user session is active (or even just locked) at the scheduled install time, the system will postpone the reboot and try later when the user is gone. I know you mentioned no users were logged in, which should have allowed a restart, but I want to highlight this for completeness. It's worth double-checking that truly no session was open (for example, a user who locked the screen at day's end is still technically logged in, which counts as a "signed-in user"). If that was the case, the system would definitely wait. Windows Update is designed to respect Active Hours and logged-in users to avoid disrupting work. So if a user was logged on, the restart would not happen at the scheduled time by design.
Related to user presence, Windows has the concept of Active Hours, which is the timeframe you typically use the PC. During active hours, Windows Update will not automatically restart the device. By default, active hours on Windows 10/11 are set to 8:00 AM to 5:00 PM (and Windows can adjust this dynamically based on usage patterns). Outside of active hours (evenings or late nights), the system is allowed to reboot if needed. In Autopatch Scheduled mode, active hours become less relevant (since you define an exact install time, presumably outside work hours), but it's still good to be aware. If by chance your scheduled install time was inside active hours, the device wouldn't reboot then - it would push the restart to later at night. I suspect you chose a nighttime/off-hours schedule, so this probably wasn't the issue, but I wanted to clarify it. The key point is Windows will only auto-restart outside of active hours unless a critical deadline forces it. In your scenario, until that 25-hour mark hit, the device didn't consider itself past any deadline, so it simply waited for the next non-active-hours window (the following night) to restart.
All of the above factors are part of the "by design" behavior of Windows Update. Essentially, Microsoft prioritizes not rebooting at a bad time over strictly keeping to a scheduled moment. I absolutely understand that in your use-case - where you specifically want a strict reboot at a certain time - this default behavior is frustrating. The Autopatch interface calling it "Scheduled install and restart" is indeed misleading, and I apologize for that confusion. The label makes it sound like "yes, we'll definitely reboot at that scheduled time," but in reality it's more like "install at this time, then reboot when safe." Autopatch's Scheduled mode actually removes the usual forced-restart deadline from the equation, which gives the device flexibility to wait. This is why the reboot didn't happen immediately. Your feedback is very valid - the feature name doesn't transparently explain all these nuances. I'll gladly pass this feedback on to the Autopatch team so they're aware that this caused
confusion.
And after my response, adding more information and looking for more clarification…
Scheduled Mode vs. Deadline=0 (Standard Update Ring): The original design intent of Scheduled install and restart in Windows Autopatch was to give IT administrators a way to schedule updates during a known maintenance window (like overnight) without the typical forced reboot behavior that comes with strict deadlines. In other words, it's meant to minimize disruptions to your users' work by avoiding sudden restarts during the day or active hours. When you switch an Autopatch ring to Scheduled mode, you're essentially telling the service: "Don't enforce a reboot countdown based on a deadline. Instead, only install updates and reboot during our specified off-hours window." This is different from a regular update ring where you set deadline = 0, grace = 0. With a standard Update Ring configured that way, Windows Update for Business will download and install updates as soon as they're available and then basically force a restart as soon as possible (since a zero-day deadline means "immediately" and a zero-day grace means no waiting after installation). That can indeed result in a reboot almost right away, potentially even during the day if the update got installed then.
Scheduled mode, by contrast, tries to align both the installation and the restart to your chosen time (1 AM, in your case) which is outside your active hours of 8 AM-5 PM. The value here is that, ideally, devices won't randomly decide to restart at 1 PM or 3 PM; they'll target that 1 AM window for doing the bulk of the update work and the reboot. It's a more gentle approach that avoids the "hammer" of an immediate deadline. In theory, if a device misses that 1 AM window (maybe it was powered off at night or something), it would wait until the next available 1 AM window to try again, rather than forcing a restart during the next workday. This was supposed to reduce the chance of surprising a user with a reboot while they're working.
Why the Delay then? (why do our tests never reboot at the expected time) (Grace Period and Safety Logic): Now, the confusing part - and I completely agree this is where the feature's name doesn't match what people expect - is that Scheduled mode still isn't an absolute guarantee that the reboot happens right at 1 AM on the dot. By default, Windows Update has some built-in safety checks and delays:
If a user is logged in at the scheduled time, Windows will usually hold off rather than abruptly restarting on them (to avoid any data loss).
Also, Autopatch's default configuration (even in Scheduled mode) tends to include an automatic grace period to ensure users have a bit of time to prepare for a restart. In practice, this means if an update got installed on a device, it might not reboot immediately that same night - it could wait until the grace period passes (often about 1 day by default) before it forces a restart. This is likely why you observed the restart happening more than 24 hours later instead of at 1 AM the first night.
So, Scheduled mode by itself essentially opts out of the aggressive deadline-based reboot, but it still respects those grace period rules and the presence of any logged-in user. The result is what you saw: even though you set 1 AM as the time, the system said "well, a user might be using this machine or maybe it's too soon - let's not force it just yet" and delayed the restart until later (often the next night). I absolutely understand that this feels counterintuitive - after all, the mode is literally called "scheduled install and restart," so one would assume it will restart at the scheduled time. You're not alone in feeling that the naming and behavior are a bit at odds. I apologize for the confusion; I agree that our documentation and UI could make this clearer.
Obviously, this was not very great news. I can really summarize it as saying that Autopatch isn’t likely to, in its current state, for what it’s configuring, likely to achieve the claims it is making. However, we continued on as there was a pair of keys that it was believed could be put in place to resolve this. For context, these are NOT in the Intune CSP currently, must be manually created with a script and (according to Microsoft) they are considered “legacy”, although are still supported.
Per Microsoft…
AlwaysAutoRebootAtScheduledTime is located at HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU. It is a REG_DWORD type and accepts values 1 to enable and 0 to disable. When enabled, it forces the system to automatically
reboot at the scheduled installation time, even if a user is signed in or the device is locked.
AlwaysAutoRebootAtScheduledTimeMinutes is optional and also located at HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU. It is a REG_DWORD type and accepts an integer value representing the number of minutes past the
hour. For example, setting it to 30 would schedule the reboot at 21:30 if the scheduled install time is 21:00. This key allows more granular control over the exact reboot time.
...Windows Autopatch does not currently manage or enforce the AlwaysAutoRebootAtScheduledTime policy by default. In other words, Autopatch doesn't explicitly turn that setting off; it's simply left at the default (which is disabled unless you enable it). This means you're not working against any Autopatch-enforced configuration by enabling it. It's not enabled out of the box in Autopatch, but Autopatch isn't actively preventing it either. So your understanding is spot on - Autopatch just doesn't enable it by default....
...as of now AlwaysAutoRebootAtScheduledTime is not part of Autopatch's default policy set, so by enabling it you're not fighting against any existing Autopatch setting. You're essentially adding a new setting that Autopatch leaves alone. Many customers in similar situations have successfully layered custom
policies like this on Autopatch-managed devices. The key difference is just whether Autopatch "owns" the group or not...
We were directed to put these in place, but ultimately, no combination of them or time range plugged into the second key allowed the updates to restart as expected.
I will also say that a lot of time was spent discussing active hours and ensuring that they did not overlap with the scheduled time. To achieve this, as Autopatch doesn’t define this and instead lets machines figure it out for themselves, a custom policy had to be created and scoped to the same group as the correlating scheduled install and restart ring. Even when ensuring the scheduled install and reboot time was not at all within the defined active hours, no impact or improvement was seen.
In the end, we opted to close the case and effectively give up, and it seemed more and more based on all testing and the above explanations that the descriptions in Autopatch, and handed out by Autopatch support, were not accurate, or at least, not functioning to deliver the results expected based on the current descriptions and advertised expectations.
Microsoft’s own closing statement was…
Based on the investigation so far, the logs, and the configuration details you've shared, it appears that the behavior you are looking to achieve, strictly holding restarts until a specified scheduled time regardless of circumstances, is not consistently supported within the current Windows Update and Autopatch design. While registry configurations can influence restart timing, the Windows Update service still prioritizes security and reliability, and in certain conditions it may override to enforce earlier restarts.Conclusion:
In conclusion, if you are banging your head on this topic, trying to get it to work how it says it works, or even engaged with support and struggling to get results, I hope this article helps give you some answers, even if they are ultimately not what you want to hear.
Azure to the Max 