Windows Rebootless Hotpatching coming to on-premises environments
It has often felt like the bane of an IT administrator’s existence – Windows Updates. Patching Windows servers is especially challenging in many ways and can lead to long hours of patching and maintenance periods due to the downtime that is often needed. However, Microsoft has introduced a solution for rebootless Windows Updates called hotpatching. Now, this was all well and good. However, it didn’t seem as exciting for administrators since this was an “Azure-only” feature. However, at the recent Microsoft Ignite virtual event, Microsoft detailed Windows rebootless hotpatching coming to on-premises environments. How? Let’s take a little deeper look into this news, what it means, and how you can take advantage of it.
What is rebootless hotpatching and how does it work?
A while back, I wrote up a post that covered a new version of the Microsoft Windows operating system, only released in Azure, called Windows Server 2019 Azure Edition. Microsoft, as expected is following suit with Windows Server 2022 Azure Edition. What are these special-purpose operating systems?
The hotpatching feature is a new feature found in the new “Azure Edition” operating systems and allows “rebootless” patching of Windows Servers. What???? Yes, rebootless patching, in case you have not heard of this feature as of yet. How does the rebootless hotpatching feature work?
Hotpatching works by patching the in-memory code that runs inside of Windows Server Azure Edition. With the hotpatching feature, patches can be applied without the need for a reboot on your Windows Server. The new hotpatching feature works off the premise of “baselines.”
- Planned Baseline – The planned baseline is released every three months and installs the quarterly Cumulative Updates released from Microsoft. The Cumulative Update requires a reboot. This creates the baseline that the interim hotpatching process works from during the rest of the months, such as the Patch Tuesday releases from Microsoft. The hotpatching builds on the Cumulative Update currently applied to the server and do not require reboots.
- Unplanned Baseline – Unplanned Baselines are out-of-band critical or zero-day patches released by Microsoft that are out of the normally scheduled patching. With unplanned baselines, Microsoft basically notes they will release a new Cumulative update containing the current Cumulative Update code along with the zero-day patch. Like the planned baselines, the unplanned baselines with the out-of-band Cumulative Update will require a reboot.
Windows Rebootless Hotpatching coming to on-premises environments
As I detailed in the last post covering the announcement and release of Azure Stack HCI 21H2, Microsoft is releasing the hotpatching feature for the on-premises Azure Stack HCI platform. See that post here:
It means that you can now have the ability to use the hotpatching feature in your on-premises environments for keeping your Windows Servers patched. How does the Windows Server operating system “know” it is running on Azure Stack so it will unlock these features? In the latest version, Azure Stack HCI 21H2, Microsoft has included a built-in attestation capability that allows every node in the Azure Stack HCI cluster to exchange certificates for verification and then expose a secure REST endpoint accessible only to the VMs running in the Azure Stack HCI cluster.
The endpoint can only be reached by the VM and the Windows Server guest operating system so it knows it is a guest operating system running on top of the Azure Stack HCI platform. The HCI SVC service signs the response using an Azure certificate so the VM “thinks” it is running in Azure.
This attestation process allows the VM to know if it can unlock the rebootless hotpatching feature and other Azure Stack-only features like extended security updates.
Downsides and limitations to the rebootless hotpatching on-premises
As you are probably already thinking, there are downsides and limitations to this new rebootless hotpatching feature for virtual machines running on top of the Azure Stack platform. A couple that I have thought about regarding the new capabilities for Azure Stack HCI VMs are the following:
- You have to be running the specialized version of the Windows Server operating system (Azure Edition) to be able to receive the rebootless hotpatch benefits – This means you would have to migrate your data, services, workloads, etc over to the new version of the Windows operating system, a process that seems more daunting than actually dealing with the traditional installation of Windows Updates.
- Your VMs would have to be running on top of Azure Stack HCI – This seems like an obvious one. However, this will be extremely limiting to the workloads that are running in other platforms such as VMware vSphere, Hyper-V, Nutanix, and others
Wrapping Up
While this is a great step in the right direction, I think there are still many hurdles and challenges on the Windows Updates front and keeping Windows Servers patched. As is the challenge with many nice new solutions and releases, there is the challenge of trying to make older legacy solutions and technologies work. Most organizations can’t perform a lift and shift of everything in their environment to new technologies.
It will be great to see if Microsoft continues to integrate the new capabilities of rebootless hotpatching and other capabilities integrated into the standard Windows on-premises versions if this is even possible. Microsoft has not specifically detailed the exact differences of Azure Edition compared to the regular editions of Windows Server 2019 and Windows Server 2022. It would be great if this functionality could be ported to the standard Windows Server versions.
It will be interesting to see how Microsoft approaches this moving forward with the disparity growing between the Azure editions of Windows Server and what can be done on-premises. However, it is the direction that is being taken. The writing is on the wall that all Windows installations will most likely be a subscription-based solution linked to Azure.
