There’s never a convenient time to perform a reboot, but it’s often required after applying security updates in Windows.
For Windows desktops, automated reboots may occur when you least expect them and may cause applications to lose unsaved work. In the case of server workloads, updates can be disruptive and may result in short outages. Organizations often go to great lengths to deploy complex infrastructures to keep workloads running, even as individual servers reboot. Microsoft has taken steps to reduce reboots after a Windows Server update by introducing hotpatching to the Windows Server 2025 Standard and Datacenter editions. Windows Server hotpatching was previously only available for Windows Server 2022 Datacenter: Azure Edition VMs running in Azure or on Microsoft’s Azure Stack HCI platform.
What is the benefit of hotpatching for Windows Server?
As appealing as the thought of fewer server reboots might be, there are other potential advantages. Microsoft designed its hotpatching feature to update the code running in the server’s memory, which makes the update process less taxing on the server’s storage and CPU resources compared to the normal Windows update method.
Perhaps more importantly, patch management scheduling becomes less of an issue with hotpatching because you no longer need to schedule updates based on when it is a good time to stop a Windows Server workload and reboot the server. The other benefit is applying security updates more quickly, which reduces the time your servers are exposed to patched vulnerabilities.
How does Windows Server 2025 hotpatching work?
As previously noted, hotpatching works by updating the code running within a server’s memory instead of writing the new code to disk and then rebooting the server to bring that code into memory. Unfortunately, this method does not eliminate the need to reboot servers following the update process. Instead, it reduces the frequency of the required updates.
Microsoft bases its hotpatching process around a series of baselines, which are like cumulative updates. When configuring a server to use hotpatching, Windows Update must apply a baseline image. After a reboot, future updates for the server can be installed as hotpatches until Microsoft releases the next baseline.
Microsoft’s planned release cadence for baseline images is every three months. For example, if the company releases a new baseline image in July, then the July baseline would include the updates for that month. The August and September updates would then be released as hotpatches. The next baseline release and the next required reboot would, therefore, be in October. In other words, servers will only need to reboot once every three months. However, some situations may require a server reboot between baseline releases.
Microsoft has stated that it may occasionally release an unplanned baseline between scheduled releases, a nonsecurity update or a zero-day fix that requires a reboot.
Microsoft said hotpatching is not available for certain updates, such as nonsecurity updates, .NET patches and third-party software fixes. These third-party updates may include firmware revisions or driver upgrades.
Most admins use Azure Arc from the Azure portal to see and manage the deployment of patches for their Windows Server 2025 workloads. Microsoft offers several other patch management tools to handle hotpatches. One method is through a Windows Update scan, which offers either a hotpatch or the baseline update, depending on the release cycle. SConfig performs the same task on Server Core workloads. Azure Update Manager is another tool available to manage these hotpatch updates.
What are the requirements for Windows Server 2025 hotpatching?
Hotpatching isn’t new for Microsoft. It started offering the service for Azure VMs with Windows Server 2022: Azure Edition. Now, the company offers hotpatching in its Windows Server 2025 Standard and Datacenter editions via Azure Arc for physical servers, Hyper-V and VMware VMs on-premises and third-party cloud platforms.
Admins who want to test the hotpatch service can use it for free until June 30, 2025. After that, Microsoft will switch Windows Server 2025 hotpatching to a paid subscription service of $1.50 per CPU core — physical or virtual — per month.
The requirements for Windows Server 2025 hotpatching outside of Azure include the following:
- Azure Arc connection using the Connected Machine agent.
- Subscription to the hotpatching service as of July 1, 2025.
- Unified Extensible Firmware Interface with Secure Boot enabled.
- Virtualization-based security (VBS) on the VM or physical server.
- Hyper-V VMs must be Generation 2.
- Azure subscription.
Because the hotpatching process alters code running on the server memory, Microsoft uses VBS to protect from exploits and keep the kernel secure.
Enable VBS by running this command and rebooting the server.
Reg add "HKLMSYSTEMControlSet001ControlDeviceGuard" /v "EnableVirtualizationBasedSecurity" /t REG_DWORD /d 1 /f
Once the server has been rebooted, you can use the MSINFO32 tool to verify that VBS is enabled.
How to set up hotpatching for Windows Server 2025
To use hotpatching on Windows Server 2025 Standard or Datacenter editions not running on Azure, you must configure the server to connect to Azure Arc. This requires installing the Azure Connected Machine agent on your server.
To link your machine to Azure Arc, sign in to the Azure portal, open Azure Arc and click Add Resources. When prompted, click Add/Create, followed by Add a Machine. Now, choose the option to either Add a single server or Add multiple servers. You can add the server using either a script or the Windows installer.

After installing the Connected Machine agent, go back to the Azure portal, and open the Azure Arc service. Now, click on the Azure Arc Resources tab, and then click on the Machines tab. You should see your enrolled server.

Click on the server, and then click on Hotpatch. Finally, select the I want to license this Windows Server to receive monthly hotpatches checkbox, and click Confirm.
Brien Posey is a former 22-time Microsoft MVP and a commercial astronaut candidate. In his more than 30 years in IT, he has served as a lead network engineer for the U.S. Department of Defense and a network administrator for some of the largest insurance companies in America.