As part of the Automatic VM Guest Patching for Azure VMs preview announced at Ignite in March, Microsoft introduced Windows Server hotpatching. Hotpatching lets organizations apply security patches to Windows Server without rebooting. A feature that’s been part of other server platforms for years, hotpatching finally comes to Windows Server. But there are some caveats.
The first is that for the time being at least, hotpatching only works in Windows Server Azure Edition virtual machines (VMs). That means your server workloads must be running in the Azure cloud. Microsoft says that hotpatching brings the following benefits:
I expect that Microsoft will use hotpatching as bait to lure more organizations to move Windows Server workloads to the cloud. But time will tell.
The second caveat is that you will still need to reboot Windows Server – at least sometimes. Before you can apply hotpatches to Windows Server, it must be running the latest baseline Windows Update Latest Cumulative Update (CU). Microsoft says that planned baseline updates will be released every three months. That means, at least once in three months, you will need to reboot Windows Server. Hotpatches will be released monthly on Patch Tuesday.
Unplanned baseline updates might be released when zero-day flaws need to be patched but can’t be fixed without a reboot. The image above shows how planned, unplanned, and hotpatch releases might pan out over a year.
Now in preview in all regions, Automatic VM Guest Patching helps administrators with update management by safely patching VMs. Microsoft says Automatic VM Guest Patching brings the following benefits:
Remember that at the time of writing, Automatic VM Guest Patching is in preview and you shouldn’t enable it on Azure subscriptions that host production workloads. For more detailed information on Automatic VM Guest Patching, check out Microsoft’s website here.
The first step to enabling hotpaching for Windows Server in Azure is to opt in to the Automatic VM Guest Patching public preview. The easiest way to do that is in the Azure portal using Cloud Shell. If you’ve never used Cloud Shell before, check out Managing Azure Resources with Cloud Shell on Petri.
Register-AzProviderFeature -FeatureName InGuestHotPatchVMPreview -ProviderNamespace Microsoft.Compute Register-AzProviderFeature -FeatureName InGuestAutoPatchVMPreview -ProviderNamespace Microsoft.Compute Register-AzProviderFeature -FeatureName InGuestPatchVMPreview -ProviderNamespace Microsoft.Compute
It can take up to 15 minutes for service to be registered. You can check the status of each service using the following three commands:
Get-AzProviderFeature -FeatureName InGuestHotPatchVMPreview -ProviderNamespace Microsoft.Compute Get-AzProviderFeature -FeatureName InGuestAutoPatchVMPreview -ProviderNamespace Microsoft.Compute Get-AzProviderFeature -FeatureName InGuestPatchVMPreview -ProviderNamespace Microsoft.Compute
Once you are sure that each service status has changed to ‘Registered’, run the command below to propagate the change to the Compute resource provider:
Register-AzResourceProvider -ProviderNamespace Microsoft.Compute
Hotpatching can’t be enabled on VMs that already exist. You will need to deploy a new VM to use hotpatching in Windows Server. And during the preview, you must use a special link to access to Azure management portal when you deploy a VM for hotpatching.
For more information about how to deploy virtual machines in Azure, read Create a Virtual Machine in the Azure Cloud on Petri.
And that is it! Your new VM is now enrolled in Automatic VM Guest Patching. The VM will be assessed every few days and many times every month to make sure that it is up-to-date with the latest security patches. To check the patch status for your VM, use the Guest + host updates section for the VM in the Azure portal.
Hotpatching has been long coming to Windows Server. And even now, it’s quite limited in scope. But that seems to be a conscious decision on Microsoft’s part. Microsoft might make hotpatching available for on-premises Windows Server in the future, but I wouldn’t be surprised to see it limited to the Azure cloud.