Azure Update Manager: Machine is Required to reboot. However, the customer-specified reboot setting doesn't allow reboots.

Question

Azure Update Manager: Machine is Required to reboot. However, the customer-specified reboot setting doesn't allow reboots.

AGlezB-7121 26

I'm having an issue with AUM where some Windows VMs aren't rebooting after an update:

"0 errors reported. The latest 3 errors are shared in details. To view all errors, review this log file on the machine:[C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension\1.5.75] "["Machine is Required to reboot. However, the customer-specified reboot setting doesn't allow reboots.]."

The Maintenance Configuration has "rebootSetting": "AlwaysReboot" and "duration": "03:55" so I expected the VMs to reboot no matter what but something is preventing the reboot despite the updates using only a small fraction of the maintenance window. I followed the steps provided by the troubleshooter and checked the update policies but nothing seems out of place.

This might be related to Azure Update does not reboot.

I need help finding what is preventing the reboot. Thanks in advance.

Jerald Felix 18,680 Reputation points Volunteer Moderator

2025-10-15T16:15:41.1966667+00:00

Hello AGlezB,

Thank you for sharing the details of your Azure Update Manager situation. When a maintenance configuration specifies rebootSetting: "AlwaysReboot", VMs should reboot after updates within the maintenance window. If your VMs aren't rebooting and you're seeing the message "Machine is Required to reboot. However, the customer-specified reboot setting doesn't allow reboots," here are possible causes and suggestions:

Conflicting Policies: Other settings—like Group Policy or local update management tools—may block or defer system reboots. Review the VM’s local policies under gpedit.msc at Computer Configuration > Administrative Templates > Windows Components > Windows Update > No auto-restart with logged on users... and look for settings that prevent restarts.

About Maintenance Window Usage: Even if updates consume only a small duration of the maintenance window, a restrictive reboot policy or script (e.g., custom scripts, logon policies) in the VM may prevent reboots until the user logs off.

Azure Extensions or Scripts: Double-check for custom scripts/extensions running on your VM that might override Azure Update Manager’s reboot instructions.

Update Manager Profile: Validate that no additional configuration profiles (like Patch Orchestration or older Azure Automation runbooks) are also applied to the VM, as these may interfere with AUM’s reboot control.

Local Security Policy: Confirm via secpol.msc that local security policies do not restrict restart actions for update operations.

If possible, inspect the relevant log file at C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension\1.5.75\ for more detailed error information.

You can find related troubleshooting guidance in these articles:

Azure Update Manager Operations

Troubleshoot OS startup – Windows Update installation capacity

Understand a system reboot for an Azure VM

If none of these steps resolve the issue, please share a summary of the policies applied to the VM and any custom configuration details for deeper analysis.

Best regards,

Jerald Felix
Suchitra Suregaunkar 16,620 Reputation points Microsoft External Staff Moderator

2025-10-16T18:51:30.7366667+00:00

Hello AGlezB-7121

Could you please look into details asked via private messages and share it.

Thanks,

Suchitra.
AGlezB-7121 26 Reputation points

2025-10-22T15:36:42.01+00:00
Hi @Jerald Felix ,

Thanks you for you answer.

I just finished checking everything you mentioned, including the Event Log and a run of RSOP to see if there was some issue with the policies and I couldn't find anything out of place.

All Windows Update policies, including No auto-restart with logged on users, are set to Not configured.

I also checked if there were open sessions in the servers at the time and there wasn't any.

Updates are configured to Customer Managed Schedules with Hotpatch disabled (required for AUM).

No errors or warnings in Windows Events.

Active hours are set at the default values (08:00-21:00) with the auto adjust set to off. I read somewhere this might cause issues with reboots within the active period.

Update ETL logs have no messages regarding reboot issues. The only non-info entries at the time are these:

2025-10-15T05:05:30.0699091Z - Error - *FAILED* [8007007E] file = onecore\enduser\windowsupdate\client\engine\agent\deploycall.cpp, line = 917 2025-10-15T05:05:31.5186455Z - Warning - *FAILED* [80240037] EventId=181l [GetEventNameAndScenarioFromEventID:292] 2025-10-15T05:36:35.9623456Z - Warning - Skipping printer driver 2 due to incomplete info or mismatched environment - HWID[(null)] Provider[Microsoft] MfgName[Microsoft] Name[Remote Desktop Easy Print] pEnvironment[Windows x64] LocalPrintServerEnv[Windows x64] 2025-10-15T05:36:35.9674031Z - Warning - Skipping printer driver 4 due to incomplete info or mismatched environment - HWID[microsoftmicrosoft_musd] Provider[Microsoft] MfgName[Microsoft] Name[Microsoft enhanced Point and Print compatibility driver] pEnvironment[Windows NT x86] LocalPrintServerEnv[Windows x64] 2025-10-15T05:36:37.6389192Z - Error - *FAILED* [80070057] file = onecore\enduser\windowsupdate\client\engine\agent\protocoltalker.cpp, line = 1260 2025-10-15T05:36:37.6389363Z - Error - *FAILED* [80070057] file = onecore\enduser\windowsupdate\client\engine\agent\protocoltalker.cpp, line = 1260

Those are from one of the servers, the other one has no errors or warnings. I also checked the error codes (80070057, 8007007E, 80240037) and they don't seem to be related to the reboot issue, plus all the updates completed correctly after an scheduled reboot the next day.

I'll point out I'd already checked most of those before I asked here, but I wanted to go over it again just to be sure. Please let me know if I missed something or if you want me to look for something more specific.

Regards,

A.
AGlezB-7121 26 Reputation points

2025-10-27T14:06:45.5566667+00:00
Hi @Suchitra Suregaunkar ,

That's it:

"windowsConfiguration": { "provisionVMAgent": true, "enableAutomaticUpdates": true, "patchSettings": { "patchMode": "AutomaticByPlatform", "automaticByPlatformSettings": { "rebootSetting": "Never", "bypassPlatformSafetyChecksOnUserSchedule": true }, "assessmentMode": "AutomaticByPlatform", "enableHotpatching": false } }

Makes sense for the VM property to take precedence over AUM but not having some kind of indication in the UI makes this a bastard of an issue that could have been easily avoided.

In any case, I expect the steps you provided will fix it. We'll know for sure in a couple of weeks so I'll let you know then.

Thank you.

Best regards,

A.
Anonymous

2025-11-06T13:46:40.2266667+00:00

Hello AGlezB-7121 Kindly could you please let us know if this issue has been resolved for you? if not could you please look into details asked and share them.
AGlezB-7121 26 Reputation points

2025-11-12T15:12:01.35+00:00

Hello everyone,

Last night AUM updated and rebooted the affected servers without any issues. Thanks to @Jerald Felix for your help and to @Suchitra Suregaunkar for providing both the explanation of the cause and the fix for the issue.

Best regards,

A.
Jerald Felix 18,680 Reputation points Volunteer Moderator

2025-11-12T15:49:11.4133333+00:00

Glad to help you AGlezB-7121

I request you to kindly accept the answer

Answer accepted by question author

0 additional answers

Your answer

Suchitra Suregaunkar 16,620 Reputation points Microsoft External Staff Moderator

2025-10-16T18:51:30.7366667+00:00

Hello AGlezB-7121

Could you please look into details asked via private messages and share it.

Thanks,

Suchitra.
AGlezB-7121 26 Reputation points

2025-10-27T14:06:45.5566667+00:00

Hi @Suchitra Suregaunkar ,

That's it:

"windowsConfiguration": { "provisionVMAgent": true, "enableAutomaticUpdates": true, "patchSettings": { "patchMode": "AutomaticByPlatform", "automaticByPlatformSettings": { "rebootSetting": "Never", "bypassPlatformSafetyChecksOnUserSchedule": true }, "assessmentMode": "AutomaticByPlatform", "enableHotpatching": false } }

Makes sense for the VM property to take precedence over AUM but not having some kind of indication in the UI makes this a bastard of an issue that could have been easily avoided.

In any case, I expect the steps you provided will fix it. We'll know for sure in a couple of weeks so I'll let you know then.

Thank you.

Best regards,

A.
Anonymous

2025-11-06T13:46:40.2266667+00:00

Hello AGlezB-7121 Kindly could you please let us know if this issue has been resolved for you? if not could you please look into details asked and share them.
AGlezB-7121 26 Reputation points

2025-11-12T15:12:01.35+00:00

Hello everyone,

Last night AUM updated and rebooted the affected servers without any issues. Thanks to @Jerald Felix for your help and to @Suchitra Suregaunkar for providing both the explanation of the cause and the fix for the issue.

Best regards,

A.
Jerald Felix 18,680 Reputation points Volunteer Moderator

2025-11-12T15:49:11.4133333+00:00

Glad to help you AGlezB-7121

I request you to kindly accept the answer

Answer 1

Hello AGlezB-7121 Following up on this thread because the earlier resolution didn’t resolve the behavior.

VMs didn’t reboot even with AlwaysReboot: When Azure Update Manager (AUM) shows: Machine is Required to reboot. However, the customer-specified reboot setting doesn't allow reboots.

The “customer‑specified reboot setting” typically isn’t your Maintenance Configuration. It’s the per‑VM setting on the VM model:

osProfile.windowsConfiguration.patchSettings.automaticByPlatformSettings.rebootSetting

On Azure VMs using Azure‑orchestrated patching (Customer Managed Schedules), this VM‑level rebootSetting takes precedence over the Maintenance Configuration’s rebootSetting. If the VM’s value is Never (or unset in a way that forbids reboots), AUM will not reboot even if the schedule says AlwaysReboot.

As a workaround please try below checks:

Check the VM’s rebootSetting : If it returns Never or is blank/unknown, that is the blocker.

Azure CLI:


az vm show -g <resourceGroup> -n <vmName> \
  --query "osProfile.windowsConfiguration.patchSettings.automaticByPlatformSettings.rebootSetting" -o tsv

Go to Azure Portal: VM ➜ JSON view ➜ find osProfile.windowsConfiguration.patchSettings.automaticByPlatformSettings.rebootSetting.

Set patch mode + reboot policy correctly:

Ensure patch mode is AutomaticByPlatform (Azure‑orchestrated).
Set rebootSetting to IfRequired (reboot only when needed) or Always (unconditional).
Enable BypassPlatformSafetyChecksOnUserSchedule = true (prereq used by AUM schedules & supported by Azure Policy).

$vm = Get-AzVM -ResourceGroupName "<rg>" -Name "<vm>"

# Use Azure-orchestrated patching for Customer Managed Schedules
$vm.OSProfile.WindowsConfiguration.PatchSettings.PatchMode = "AutomaticByPlatform"

# Configure reboot behavior and bypass safety checks for user schedules
$vm.OSProfile.WindowsConfiguration.PatchSettings.AutomaticByPlatformSettings = `
  New-Object Microsoft.Azure.Management.Compute.Models.WindowsVMGuestPatchAutomaticByPlatformSettings -Property @{
    RebootSetting = "IfRequired"   # or "Always"
    BypassPlatformSafetyChecksOnUserSchedule = $true
  }

Update-AzVM -ResourceGroupName "<rg>" -VM $vm

Reference: https://learn.microsoft.com/en-us/javascript/api/@azure/arm-compute/patchsettings?view=azure-node-latest

When the VM model allows reboots, AUM can honor your schedule’s AlwaysReboot or IfRequired intent. The platform‑documented precedence is the reason the schedule alone couldn’t force the reboot earlier.

Re‑run the AUM schedule and confirm in logs: After updating the VM property, run the schedule again (or trigger an on‑demand update), then verify in the Windows patch extension logs: *C:\WindowsAzure\Logs\Plugins\Microsoft.CPlat.Core.WindowsPatchExtension<version>*

These logs record the patch operation and reboot decision paths.

If needed you can try below additional checks as well:

Active Hours suppression: If Windows Active Hours overlap your maintenance window, Windows Update may suppress restarts. Align the schedule or adjust Active Hours to avoid overlap.

Maintenance window time left: AUM reserves time for reboot. If insufficient time remains in the window near the end, the reboot can be skipped (commonly ~10 minutes reserved for reboot)

Reference: https://learn.microsoft.com/en-us/azure/virtual-machines/automatic-vm-guest-patching
Thanks,

Suchitra.