Windows Server 2025 hotpatch via Azure Arc skips most monthly reboots

If you manage Windows Server 2025 Standard or Datacenter, you've probably heard people talking about it by now: Windows Server 2025 hotpatch Arc is here, and it brings no-reboot patching to machines outside Azure. Hotpatching used to be limited to Azure Edition VMs. With 2025, Microsoft has opened this premium feature up to on-premises and hosted servers, provided you connect them to Azure Arc and subscribe to the add-on. In most environments I work in, the conversation turns practical very quickly. People want to know how to enable it, what it actually changes for maintenance, and which workloads really benefit.

Every hotpatch server needs Arc onboarding and VBS before the portal enrollment

A few prerequisites have to be in place before hotpatching does anything for you. First, the Windows Server 2025 machine (Standard or Datacenter, not Azure Edition) must be onboarded to Azure Arc, either through the Azure portal or with the "azcmagent" tool. Second, and just as important, Virtualization-Based Security (VBS) has to be enabled on the server. Without VBS, hotpatching simply won't run. My quickest check happens directly on the server (PowerShell 5.1 or higher):

Get-CimInstance -ClassName Win32_DeviceGuard

In the "SecurityServicesConfigured" property, you're looking for a value of "1" (VBS enabled). If it's missing, VBS needs to be turned on in both the firmware (UEFI/BIOS) and Windows. Most organizations should have VBS on anyway as a security best practice.

After that, onboarding is simple. Go to Azure portal → Azure Arc → Machines → (select server) → Hotpatch, and you'll see the new enrollment option. Registration itself takes little effort, but for day-to-day operations you'll want the machine connected to Azure Update Manager. I walk through that in my hands-on intro Azure Update Manager: Patch management made modern. Once it's connected, hotpatches are orchestrated in your maintenance schedules like any other update.

Baseline months and hotpatch months alternate on a fixed cycle

Hotpatching works differently from a normal Windows Update. It follows a set cycle: a "baseline" month every quarter, with "hotpatch" months in between. In a baseline month (typically every three months), the server installs a full cumulative update, and that one needs a reboot. In the hotpatch months, security updates arrive as hotpatches and are applied live, with no restart. Under the hood, Windows uses memory patching to swap out code in running processes, so the server and its services stay up.

This is roughly how the process looks for a Windows Server 2025 hotpatch Arc setup:

flowchart TD
    Start["Arc onboarding"] --> VBS["VBS enabled"]
    VBS --> Enrollment["Hotpatch enrollment portal"]
    Enrollment --> Baseline["Baseline month: CU + restart"]
    Baseline --> Hotpatch["Hotpatch months: patch, no restart"]
    Hotpatch --> Baseline

Figure: Hotpatch lifecycle for Windows Server 2025 via Arc

So you still plan a reboot every few months, but most critical patches land without any downtime. On high-availability systems, that makes a real difference.

Azure Update Manager orchestrates the hotpatch cadence

For both Azure VMs and Arc-connected servers, Azure Update Manager is now the standard tool for update orchestration. You can drive it from the Azure portal, Policy, the REST API or PowerShell (Az modules, version 10+). As soon as a server is enrolled for hotpatching, Update Manager takes care of the patch cadence on its own. Maintenance windows, server groups and reporting behave the same as before. The details are documented at https://learn.microsoft.com/en-us/azure/update-manager/overview.

One thing I've learned in real projects:

If you're relying on hotpatch, announce the baseline months early and put them in your patching plan. I've watched teams forget to schedule that quarterly reboot and then get caught off guard by unplanned downtime.

Some workloads gain far more than others, and the limits are real

The benefit varies a lot from server to server. Classic file/print servers, IIS web servers, AD domain controllers, RDS hosts and anything with tight uptime SLAs profit the most. I've seen SQL Server hosts go months longer without a patch reboot. Legacy apps, custom drivers or tightly integrated third-party software can make things messier, though, so test those first.

Hotpatching is not a substitute for regular patch management or basic security hygiene. Only some updates can be hotpatched (kernel, driver and some core system updates will always need a reboot), and the quarterly restart doesn't go away. Keep your monitoring and reporting habits as they are. To confirm hotpatches are actually being applied, look at the update status in the Azure portal or run Azure Update Manager queries. The technical background is at https://learn.microsoft.com/en-us/windows-server/get-started/hotpatch.

I see hotpatch with Arc as real progress, with caveats

With Windows Server 2025 hotpatch Arc, Microsoft brings Windows patching much closer to what admins have been asking for over the years, which is patching without reboots outside Azure. You pay for it, and it doesn't solve everything, but for a lot of critical hosts it noticeably improves uptime. If you haven't adopted Arc yet, this could be the reason to start. Test on non-production servers first, as always, and keep those baseline reboot months on your radar.