Enable Free Hotpatch on Azure Arc Windows Server 2025: VBS, Enrollment and Reboot Planning

Below is the full procedure, checked against Microsoft Learn, plus the points that tend to catch people out.

Why patch reboots matter​

Anyone who looks after a fleet of servers knows the monthly routine. Patch Tuesday arrives, change requests get filed, application owners argue about maintenance windows, and someone ends up rebooting a domain controller at 2 a.m.

Hotpatch changes part of that. It applies security updates directly to a running system without a restart by modifying the in‑memory code of active processes. Microsoft Learn says Hotpatch covers Windows security updates and keeps parity with the security content shipped in the regular, non-Hotpatch Windows Update channel. You get the same fixes without the restart.

Summary: Hotpatch cuts the number of restart-driven maintenance windows for eligible security updates. It does not remove restart planning altogether.

It's now free, which changes the math​

Cost is a big part of why this episode matters. When Arc-enabled Hotpatch launched, it was a paid add-on. Licensing blog Cloudy With a Chance of Licensing reported that it was free in preview but, from July 1 2025, would cost $1.50 per core per month. For a large fleet, that added up quickly.

That fee is gone. In its announcement, Microsoft said that for Windows Server 2025 Standard or Datacenter connected to Azure Arc, enabling and usage of the hotpatching service is available at no additional charge. The Azure Update Manager documentation adds billing detail: per-core meters, hourly charges and separate hotpatch invoice lines have been eliminated, and billing has stopped for servers already enrolled, with no action required.

Two caveats:

• The effective date varies by source. Microsoft's own documentation and announcement use May 19, 2026. Several third-party sources, including SCHNEIDER IT Management and Q-Advise, say effective May 15, 2026. Either way, it's months in the past, and anyone paying Hotpatch charges now should look into it.
• "Free Hotpatch" doesn't mean all of Azure is free. The episode points out that optional Azure management services may have their own pricing.

Microsoft also says that customers on Azure IaaS or Azure Local, where hotpatching is part of Windows Server Datacenter: Azure Edition, have no charges; that is included with both Windows Server 2022 and 2025 Datacenter: Azure Edition.

Step 1: Confirm eligibility​

The episode and Microsoft Learn agree on the requirements. The server must:

• Run Windows Server 2025 Standard or Datacenter, build 26100.1742 or later
• Run a generally available release. Microsoft Learn explains that preview versions or Windows Server Insiders builds aren't supported because hotpatches aren't created for prerelease operating systems
• Meet the Azure Connected Machine agent prerequisites, be connected to Azure Arc, and belong to an Azure subscription
• Support virtualization-based security (VBS), also called Virtual Secure Mode (VSM)
• Use UEFI with Secure Boot enabled
• Be a Generation 2 VM if it runs on Hyper-V

Server Core and Server with Desktop Experience are both supported.
Azure Edition is a separate case. On Windows Server 2025 Datacenter: Azure Edition, Hotpatch is on by default and doesn't need Azure Arc. Microsoft Learn notes that the other technical prerequisites still apply. Don't mix up the two enrollment paths.

A practical note for VMware users: Microsoft's documentation says that if VSM won't start, the most likely cause is that the physical or virtual hardware doesn't meet the requirements. It points readers to their hypervisor vendor's documentation, such as VMware vSphere's guide to turning on virtualization-based security for an existing VM.

Step 2: Check Virtual Secure Mode​

Hotpatch enrollment can fail on this step. Run this in an elevated PowerShell session on the server:

Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' -ClassName 'win32_deviceGuard' | Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'

• Output 2: VSM is configured and running. Move on to enrollment.
• Anything else: fix VSM before you enroll. According to Microsoft Learn, if VSM isn't running when you enable Hotpatch in the portal, enablement fails.

VSM may already be on. Microsoft Learn notes that features which depend on it, such as Credential Guard or Hypervisor-protected Code Integrity (HVCI), turn it on as well. If your security baseline already enforces those, you may be done.

If VSM is off, Microsoft Learn documents a registry method: set EnableVirtualizationBasedSecurity to 1 (DWORD) under HKLM:\System\CurrentControlSet\Control\DeviceGuard, restart, then run the check again to confirm the output is 2. Enabling VSM requires a restart, so do it in a scheduled maintenance window. At fleet scale, Group Policy or your usual configuration tool is a better fit than editing registries one server at a time.

Summary: No 2, no Hotpatch. Getting VSM running costs one restart, which you can plan ahead.

Step 3: Enroll through Azure Arc​

With the prerequisites met, the portal steps shown in the episode match Microsoft Learn:

1. Open Azure Arc, then select Machines.
2. Select the eligible server.
3. Select Hotpatch.
4. Review the confirmation and select Confirm.
5. Wait about ten minutes for the change to apply.
6. Check that enrollment completed and the status no longer shows Pending.

If it stays on Pending: Microsoft Learn says to troubleshoot the Azure Arc agent.

Another route: Azure Update Manager documents its own enrollment path: Azure Update Manager → Resources → Machines → select the server → Recommended updates → Hotpatch → Change, then Receive monthly Hotpatch updates → Enable Hotpatching → Confirm. It can also enable Hotpatch at scale through Update settings, and it can add a Hotpatch status column to the machines grid. Statuses shown there are Not enrolled, Enabled, Canceled, Disabled and Pending. For anything more than a few servers, the fleet view is the better option.

Step 4: Enrolling doesn't install updates​

This is the most common misunderstanding, and the episode addresses it directly. Enrollment makes a server eligible for Hotpatch updates. It does not install them. Microsoft Learn says that when a Hotpatch is available from Windows Update, you should get a prompt to install it. Hotpatches aren't released every month, so you may have to wait for the next one.

Microsoft lists these ways to handle updates on Arc-connected machines:

• Windows Update
• Azure Update Manager
• Group Policy (to configure Windows Update client settings)
• SConfig (on Server Core)
• Supported non-Microsoft patch management tools

Azure Update Manager adds periodic or on-demand assessments, recurring or one-time schedules, classification filters, include or exclude by KB ID, a Reboot required column in assessment results, and 30 days of update history.

Step 5: Plan for the restarts that remain​

Microsoft's release pattern goes like this:

Microsoft Learn's example: a baseline in January, Hotpatches in February and March. A typical year works out to four planned baselines and eight Hotpatches, although unplanned baselines can change that.

These updates are outside the Hotpatch program and can still need restarts in Hotpatch months:

• Nonsecurity Windows updates
• .NET updates
• Drivers, firmware and other non-Windows updates

On rollback: Microsoft Learn says Hotpatch updates don't support automatic rollback. If a Hotpatch causes a problem, you uninstall the latest update and reinstall the last working baseline, which requires a restart. Build that into your runbooks.

History worth knowing​

Hotpatch has had problems before. In October 2025, Microsoft Learn documented two issues. Some October updates, including out-of-band KB5070881, left machines incompatible with upcoming Hotpatches until the January 2026 baseline. Separately, a feature-licensing bug could stall new enrollments at "In Progress". Microsoft now lists no known issues and says all past issues are mitigated. The lesson still applies: installing an off-cycle update on a Hotpatch server can quietly put you back on monthly reboots until the next baseline. Check what you install against the Hotpatch calendar.

Our take​

This is the kind of practical content the Arc team should be producing: short, scoped, and honest about what Hotpatch doesn't do. The Arc angle deserves a critical look, though. Microsoft wants on-premises servers connected to Azure Arc, and free Hotpatch is a very good reason to connect them. That is a sound deal for most shops, but it means more Azure dependency, agent management, and outbound connectivity requirements. Security teams should review those consciously, not just accept them.

For the right servers, such as busy file servers, line-of-business application hosts, and anything where "just reboot it" requires three approvals, it's worth doing. Quarterly restarts instead of monthly ones will make a real difference to many operations teams.

Before you start, check:

1. The build is 26100.1742 or later, Standard or Datacenter
2. The server is Arc-connected and the agent is healthy
3. The VSM query returns 2 (if not, schedule a restart)
4. Enrollment shows Enabled, not Pending
5. Your update tool is configured, because enrollment alone installs nothing
6. Restart windows are still planned for quarterly baselines and out-of-scope updates