Windows Server Automatically rebooted - Azure Update Manager

Question

Windows Server Automatically rebooted - Azure Update Manager

Ariel Arivara 26

Hi,

I have a problem with one of our server.
It restarted automatically even it have maintenance configurations.
Found some event logs 1074, shutdown type: restart but it has no GPO applied for Windows Update and only managed by Arc and Azure Update Manager.

May I know why is this the case?

Kind regards,

Ariel

Ariel Arivara 26 Reputation points

2026-04-16T23:02:51.3733333+00:00

Bharath Y P - the server is hosted in VMWare and HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate is not existing in the registry. It is also not existing in WOW64.
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-17T02:24:23.8066667+00:00
Thank for the update. Because the server is hosted on VMware and managed via Azure Arc, the absence of "HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate" is expected and does NOT rule out Windows‑initiated restarts. These registry paths only exist when Windows Update is being controlled by policy (GPO or local policy).

For Azure Arc‑enabled servers:

Azure Update Manager does not configure or enforce Windows Update registry settings

The OS remains 100% in control of update install + reboot decisions

If no policy exists > no WindowsUpdate registry tree exists

This is explicitly documented by Microsoft "Arc‑enabled machines are OS‑orchestrated only. Update Manager does not modify registry settings."

https://learn.microsoft.com/en-us/azure/update-manager/configure-wu-agent

Confirm what triggered the restart from the Event ID 1074 detail:

In Event Viewer > Windows Logs > System, get the full 1074 entry and note:

Process name: is it svchost.exe (Windows Update client) or shutdown.exe (external command)?

Reason Code: 0x80020010 = Windows Update planned restart

User: NT AUTHORITY\SYSTEM points to WU client or UpdateOrchestrator

Also check Event ID 19 (WindowsUpdateClient) in the System log around the same timestamp to see if a KB was installed just before the restart.

Check the AUM Maintenance Configuration reboot setting:

In Azure Portal > Azure Update Manager > your Maintenance Configuration > verify the Reboot behavior field. If Reboot behavior is set to If required or Always, Azure Update Manager may explicitly request a reboot during patching. For Arc‑enabled servers, changing this to Never reboot prevents Update Manager from requesting a reboot, but does not stop OS‑initiated reboots.

Check the non-policy Windows Update default registry hive:

This is separate from the policy hive you already checked. Run:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update"

Check the AUState and AUOptions values here — this is the OS's own runtime state, not policy-controlled.

Inspect UpdateOrchestrator scheduled tasks:

Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator\" | Select-Object TaskName, State

Look specifically for Reboot, Reboot_AC, or Schedule Scan tasks in Ready/Running state. These can fire a reboot independently of both AUM and GPO.

Check the Automatic Maintenance schedule

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Maintenance"

If this key is absent or at default, Windows Automatic Maintenance runs at 2:00 AM local time and can install and restart autonomously. You can verify if the restart timestamp aligns with this window.
Ariel Arivara 26 Reputation points

2026-04-17T04:23:35.7266667+00:00

**Bharath Y P:

This is the event 1074:
**The process C:\Windows\system32\svchost.exe (servername) has initiated the restart of computer servername on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Service pack (Planned)

Reason Code: 0x80020010

Shutdown Type: restart

Comment: **

These returns empty:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update"
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Maintenance"

This is the result for UpdateOrchestrator:
**PS C:\Windows\system32> Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator" | Select-Object TaskName, State

TaskName State

Backup Scan Ready

Maintenance Install Disabled

MusUx_UpdateInterval Ready

Reboot Disabled

Schedule Scan Ready

Schedule Scan Static Task Ready

USO_UxBroker Ready**

**These are the patches installed before the server rebooted: KB2267602, KB890830 and KB5084066

There are two assigned maintenance configurations. First is installed no reboot and the second one is once per month. Does it have a conflict if server have two maintenance configurations tagged on it?****
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-23T00:58:38.68+00:00
Yes, based on what you shared, the restart looks like a planned OS restart initiated by the Windows update stack, and having two maintenance configurations on the same machine can create schedule conflict behavior. Here is the clean RCA in your preferred format.

The empty registry results do not prove that Windows Update was not involved. Microsoft explicitly documents that on Arc-enabled machines, Update Manager does not write those registry values. So those keys being absent is expected for Arc scenarios.

Configure Windows Update Settings in Azure Update Manager | Microsoft Learn

The disabled UpdateOrchestrator\Reboot scheduled task also does not by itself prove that no update-triggered restart happened, because Microsoft documents that Update Manager performs update operations through its Arc/patch extensions and the Windows Update client, not through that single task alone.

Azure Update Manager Operations | Microsoft Learn

The strongest clue is your Event 1074 text:

svchost.exe under NT AUTHORITY\SYSTEM

reason: Operating System: Service pack (Planned)

shutdown type: restart

That points to a planned operating system restart initiated by a Windows service, not a crash. While Event 1074 by itself does not name Azure Update Manager, Microsoft documents that Update Manager uses the native Windows Update client on Arc servers.

Why the missing registry keys do not rule this out Because Microsoft explicitly states:

Arc-enabled machines are OS orchestrated only

Update Manager doesn’t modify the registry on Arc-enabled machines

So seeing those registry paths empty is consistent with Arc behavior, not evidence against Update Manager.

About the two maintenance configurations

Yes, two maintenance configurations can conflict if their schedules overlap or otherwise contend. Microsoft’s troubleshooting document says that in a concurrent or conflicting schedule, only one schedule is triggered, and the other runs after the first finishes.

What the documentation does not explicitly say is that this conflict by itself causes an unexpected reboot. So I would phrase it accurately like this:

Yes, multiple maintenance configurations can conflict in scheduling behavior.

The documentation does not explicitly say that the conflict itself causes the reboot.

The reboot is still more directly supported by the planned OS restart evidence in Event 1074 plus the fact that Update Manager on Arc relies on the Windows Update client / OS-side orchestration.

Verify which maintenance configuration actually ran: Microsoft’s own troubleshooting guidance says to confirm the maintenance configuration settings and specifically confirm the reboot status in the Maintenance Configuration settings assigned to the target machine.

So for this machine, check:

Which of the two maintenance configurations actually targeted the server at the reboot time

The reboot setting on each one (Never reboot, If required, or Always)

Whether the two schedules overlapped or were close enough to be treated as conflicting. Microsoft says conflicting schedules do not run together; one runs after the other.

Review Update Manager / extension logs on the server: Microsoft documents that Update Manager uses extensions on Arc servers for assessment and scheduled patching. For Arc-enabled servers, Update Manager installs the update extensions automatically when operations are triggered.

Review the Update Manager/extension logs around the reboot timestamp, because that is the best way to tie the restart to an actual install operation. Microsoft’s Update Manager troubleshooting content also points to extension logs for diagnosing operations.

Correlate the reboot timestamp with the patch installation job: Microsoft’s internal support TSG for “machine restarted unexpectedly after patching” lists:

possible causes including Update Manager scheduled update + reboot,

and recommends gathering logs and confirming maintenance configuration settings.
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-23T08:35:46.4566667+00:00

I just wanted to kindly follow up to check, If the provided answer is helpful, it would be great if you could accept the answer and up-vote. This helps other community members who might face the same issue. Thanks
Ariel Arivara 26 Reputation points

2026-04-23T22:13:31.7733333+00:00

thanks Bharath Y P. This question can be tagged as resolved.

Answer accepted by question author

1 additional answer

Your answer

Ariel Arivara 26 Reputation points

2026-04-16T23:02:51.3733333+00:00

Bharath Y P - the server is hosted in VMWare and HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate is not existing in the registry. It is also not existing in WOW64.
Ariel Arivara 26 Reputation points

2026-04-17T04:23:35.7266667+00:00

**Bharath Y P:

This is the event 1074:
**The process C:\Windows\system32\svchost.exe (servername) has initiated the restart of computer servername on behalf of user NT AUTHORITY\SYSTEM for the following reason: Operating System: Service pack (Planned)

Reason Code: 0x80020010

Shutdown Type: restart

Comment: **

These returns empty:
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update"
Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\Maintenance"

This is the result for UpdateOrchestrator:
**PS C:\Windows\system32> Get-ScheduledTask -TaskPath "\Microsoft\Windows\UpdateOrchestrator" | Select-Object TaskName, State

TaskName State

Backup Scan Ready

Maintenance Install Disabled

MusUx_UpdateInterval Ready

Reboot Disabled

Schedule Scan Ready

Schedule Scan Static Task Ready

USO_UxBroker Ready**

**These are the patches installed before the server rebooted: KB2267602, KB890830 and KB5084066

There are two assigned maintenance configurations. First is installed no reboot and the second one is once per month. Does it have a conflict if server have two maintenance configurations tagged on it?****
Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-23T08:35:46.4566667+00:00

I just wanted to kindly follow up to check, If the provided answer is helpful, it would be great if you could accept the answer and up-vote. This helps other community members who might face the same issue. Thanks
Ariel Arivara 26 Reputation points

2026-04-23T22:13:31.7733333+00:00

thanks Bharath Y P. This question can be tagged as resolved.

Answer 1

Hello Ariel, it sounds like your server rebooted because the Windows Update client or the VM’s patch settings overrode your maintenance window—even without a GPO in place, certain registry keys or Azure Update Manager defaults can force a restart. Here’s what to check and adjust:

Review your Maintenance Configuration in Azure Update Manager
- In the Azure portal, go to your maintenance configuration and verify the “Reboot behavior” setting. If it’s set to “Always” or “IfRequired,” the platform may restart the VM once patches are applied, regardless of active hours.
Inspect Windows Update registry settings on the server Under HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate\AU • AlwaysAutoRebootAtScheduledTime = 0 (disable auto reboot) • NoAutoRebootWithLoggedOnUsers = 1 (don’t reboot if someone’s logged in) • AUOptions = 4 (automatic download + schedule install) • ScheduledInstallTime = <hour you want> And under HKLM\Software\Policies\Microsoft\Windows\WindowsUpdate • ActiveHoursStart/End & SetActiveHours = 1 These keys control Windows-level restart behavior and can override your Update Manager schedule.
Check the VM’s patchSettings JSON In the portal, open your VM’s JSON view and look for: "patchSettings": { "patchMode": "AutomaticByPlatform", "bypassPlatformSafetyChecksOnUserSchedule": false } If patchMode is AutomaticByPlatform (and no user schedule or bypass flag), the VM is eligible for platform‐initiated patching and reboots.
Review the patch extension logs On the VM: C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>\ • WindowsUpdateExtension.log – shows which updates were installed • CommandExecution.log – shows when the reboot was triggered
Confirm no other patching tools applied updates If you have WSUS, SCCM, Intune or any other service enabled, they might have pulled and installed updates outside of your Azure Update Manager window.

the restart looks like a planned OS restart initiated by the Windows update stack, and having two maintenance configurations on the same machine can create schedule conflict behavior. Here is the clean RCA in your preferred format.

The empty registry results do not prove that Windows Update was not involved. Microsoft explicitly documents that on Arc-enabled machines, Update Manager does not write those registry values. So those keys being absent is expected for Arc scenarios.

Configure Windows Update Settings in Azure Update Manager | Microsoft Learn

The disabled UpdateOrchestrator\Reboot scheduled task also does not by itself prove that no update-triggered restart happened, because Microsoft documents that Update Manager performs update operations through its Arc/patch extensions and the Windows Update client, not through that single task alone.

Azure Update Manager Operations | Microsoft Learn

The strongest clue is your Event 1074 text:

svchost.exe under NT AUTHORITY\SYSTEM
reason: Operating System: Service pack (Planned)
shutdown type: restart

That points to a planned operating system restart initiated by a Windows service, not a crash. While Event 1074 by itself does not name Azure Update Manager, Microsoft documents that Update Manager uses the native Windows Update client on Arc servers.

Why the missing registry keys do not rule this out Because Microsoft explicitly states:

Arc-enabled machines are OS orchestrated only
Update Manager doesn’t modify the registry on Arc-enabled machines

So seeing those registry paths empty is consistent with Arc behavior, not evidence against Update Manager.

About the two maintenance configurations

Yes, two maintenance configurations can conflict if their schedules overlap or otherwise contend. Microsoft’s troubleshooting document says that in a concurrent or conflicting schedule, only one schedule is triggered, and the other runs after the first finishes.

What the documentation does not explicitly say is that this conflict by itself causes an unexpected reboot. So I would phrase it accurately like this:

Yes, multiple maintenance configurations can conflict in scheduling behavior.
The documentation does not explicitly say that the conflict itself causes the reboot.
The reboot is still more directly supported by the planned OS restart evidence in Event 1074 plus the fact that Update Manager on Arc relies on the Windows Update client / OS-side orchestration.

Verify which maintenance configuration actually ran: Microsoft’s own troubleshooting guidance says to confirm the maintenance configuration settings and specifically confirm the reboot status in the Maintenance Configuration settings assigned to the target machine.

So for this machine, check:

Which of the two maintenance configurations actually targeted the server at the reboot time
The reboot setting on each one (Never reboot, If required, or Always)
Whether the two schedules overlapped or were close enough to be treated as conflicting. Microsoft says conflicting schedules do not run together; one runs after the other.

Review Update Manager / extension logs on the server: Microsoft documents that Update Manager uses extensions on Arc servers for assessment and scheduled patching. For Arc-enabled servers, Update Manager installs the update extensions automatically when operations are triggered.

Review the Update Manager/extension logs around the reboot timestamp, because that is the best way to tie the restart to an actual install operation. Microsoft’s Update Manager troubleshooting content also points to extension logs for diagnosing operations.

Correlate the reboot timestamp with the patch installation job: Microsoft’s internal support TSG for “machine restarted unexpectedly after patching” lists:

possible causes including Update Manager scheduled update + reboot,
and recommends gathering logs and confirming maintenance configuration settings.

Once you align your maintenance configuration, VM patchSettings, and registry keys, your server should stay up until your defined maintenance window. Let me know what you find!

Reference list:

Configure reboot settings
Deploy updates now and track results with Azure Update Manager
What is Azure Update Manager Hope this helps! If the provided answer was helpful, please click Accept the Answer and upvote if the above was helpful. Thanks

Bharath Y P 8,495 Reputation points Microsoft External Staff Moderator

2026-04-24T00:33:06.1666667+00:00

Hello Ariel, Thanks for the update, If the information helped address your question, please Accept the answer. This will help us and also helps others in the community who might be researching similar information.

Answer 2

The reboot can still occur even when the server is managed only by Azure Arc and Azure Update Manager and appears to have “no GPO” for Windows Update, because reboot behavior is also controlled locally on the OS and by how updates are applied, not only by GPO.

Key points for this scenario:

Event ID 1074 explains what initiated the restart
- Event ID 1074 (source: User32) indicates a planned restart and shows the process and account that requested it, plus a reason code and shutdown type.
- On Azure / Arc-managed machines, this process might be the Windows Update client, Azure guest/management agents, or another update-related component, even if no domain GPO is configured.
- To understand the cause, review the full text of the 1074 event: process name, user (for example, NT AUTHORITY\SYSTEM), and reason code. This usually points to an update or management component.
Local Windows Update / restart settings can override “Never reboot” in Update Manager
- Azure Update Manager allows configuration of schedules and a Never Reboot option in the maintenance configuration.
- However, Windows itself has registry-based policies that control automatic updates and restarts. These can cause a reboot even if the maintenance configuration is set to never reboot.
- The documentation explicitly notes that the registry keys described in:
  - “Configure Automatic Updates by editing the registry”, and
  - “Registry keys used to manage restart” can trigger reboots regardless of the Never Reboot setting.
- If those keys are configured (for example by local policy, image baseline, or manual registry edits), Windows may restart after installing updates initiated by Azure Update Manager.
How to investigate and prevent this going forward
- In Event Viewer on the server, filter the System log for:
  - Event ID 1074 (User32) to see who/what initiated the restart and why.
  - Event ID 19 (WindowsUpdateClient) around the same time to confirm if a Windows update was installed just before the reboot.
- If the 1074 event shows an update-related process and reason, then:
  1. Review the machine’s local Windows Update / restart registry settings as described in the Windows Update registry documentation referenced by Azure Update Manager.
  2. Adjust those registry keys so they align with the desired behavior (for example, to avoid automatic restarts outside the intended maintenance window).
- Continue to use Azure Update Manager maintenance configurations for scheduling, but ensure the local OS restart policies do not conflict with the “Never Reboot” or other schedule settings.

In summary, the automatic reboot is most likely caused by Windows update/restart policies configured via registry or local settings on the server, which can still trigger a restart even when the machine is managed only by Azure Arc and Azure Update Manager and no domain GPO is applied. Event ID 1074 plus the related update events and registry configuration will show the exact cause.

References:

Share via

Windows Server Automatically rebooted - Azure Update Manager

1 additional answer

Your answer