Hotpatch is the one part of this subject where the answer genuinely got better. Windows Server 2025 can take its monthly security content into the memory of running processes and carry on, and the machine does not restart. What makes it an article rather than a footnote is that the same capability arrives by two entirely unrelated routes, with opposite acquisition models, and Cat Snack Jack has one machine on each. Confuse the routes and you will promise a change board something one of your servers can never deliver.
Two routes that look like one feature
On an Azure virtual machine, hotpatch is a property of the image. Microsoft publishes the qualifying combinations as an exact table: publisher MicrosoftWindowsServer, offer WindowsServer, and eight SKUs, which are the Azure Edition variants of Windows Server 2022 and Windows Server 2025 in their full, core and small-disk forms. The exclusion is written in the same breath and leaves no interpretive room. Windows Server container base images, custom images, or any other combination of publisher, offer, and SKU aren’t supported. Not discouraged. Not unsupported for production but technically working. Not supported.
Off Azure, hotpatch is a property of the connection. Any machine running Windows Server 2025 Standard or Datacenter that is connected to Azure Arc can be enrolled, and since 19 May 2026 it costs nothing to do so. Microsoft’s wording is unusually free of qualifiers: no per-core meter, no hourly charge, and no separate Hotpatch line item on your invoice, and new enrolments incur no hotpatch charges regardless of the underlying environment, which the same sentence lists as VMware, Hyper-V, AWS, GCP, or other on-premises and multicloud environments. A Windows Server 2025 machine on a Hyper-V host in a comms room in Leeds and one on an EC2 instance are the same case.
The in-guest mechanism is identical. The acquisition could not be more different. AZSRV01 has hotpatch because somebody selected the right image on the day it was created. APP02 has it because somebody connected it to Arc. Neither route is available to the other machine. Hold onto that, because almost every mistake in this area is a reader assuming that what worked on one side is a setting they have failed to find on the other.
On Azure, you buy it at create time
AZSRV01 runs Windows Server 2025 Datacenter: Azure Edition, and its whole patching posture follows from that one line. Microsoft says so on the Arc prerequisites page, where Azure Edition appears as the edition that does not need to be Arc-enabled because hotpatch is already enabled by default. No enrolment step, no licence to attach, no agent to satisfy. The machine arrived hotpatch-capable and, because virtual machines built from a supported Windows Server image have Automatic VM Guest Patching enabled by default, it also arrived with an orchestration model nobody in the business chose.
Sit with that, because it is the architectural point rather than product trivia. The most consequential patching decision on that machine was made on a create blade, in the first ten minutes of its existence, almost certainly without the words patching or change window being spoken. Image selection is treated as a build detail, resolved by whichever image the last template used. Yet it is the only moment at which the decision is free.
Afterwards it is not a decision at all. There is no property to flip, no extension to install and no support case that will help. The remedy for an Azure virtual machine on the wrong image is to redeploy it from a qualifying one, or to accept a monthly restart for the rest of its life. Which is why this belongs in the design conversation rather than the operations one, and why it appears in a series about Update Manager, a product that does not own the outcome and cannot repair it.
On Azure, hotpatch is not something you enable. It is something you chose, on a create blade, possibly by somebody who has since left.
The counterfactual, which is where most estates actually live
Cat Snack Jack does not contain the machine that demonstrates the trap, because AZSRV01 was specced as Azure Edition deliberately and for this reason. So I will build the trap out of the machine I have, hypothetically, and be clear that this is a thing that did not happen here.
Had AZSRV01 been created from the ordinary Windows Server 2025 Datacenter marketplace image, which is the default any sane person reaches for and which is functionally identical for every workload it runs, it would have no hotpatch and no route to it. The Azure route is closed, because that SKU is not one of the eight and the exclusion covers any other combination of publisher, offer and SKU. The Arc route is closed too, because Arc on an Azure virtual machine is not a supported production configuration: you’ll receive an error message stating that it’s unsupported, and the scenario is documented for evaluation and testing only.
So the hypothetical AZSRV01 gets hotpatch by neither route, while APP02, running an identical operating system on a Hyper-V host in the office, gets it for nothing. The machine in the cloud is the one that cannot have the cloud-era feature. People meeting this for the first time assume they have misread something, then go looking for the setting, then open a support case. There is no setting. Both remedies are cheaper to think about before the machine exists than after it has a production workload on it.
The pricing reversal changes the on-premises recommendation completely
The Arc route has a short and instructive commercial history. It reached general availability with billing from 1 July 2025 at one dollar fifty per core per month. On 19 May 2026 that was reversed, and the current wording is that hotpatch on Azure Arc-enabled machines running Windows Server 2025 Standard or Datacenter is available at no additional cost. Billing was stopped for servers already enrolled, with no action required from their owners, and those machines stayed enrolled.
Under the meter, hotpatch on premises was an arithmetic problem with an unhappy answer. A sixteen core application server was a couple of hundred dollars a year to avoid roughly eight restarts, and the honest advice was usually to decline it and spend the money on something that removed a risk rather than an inconvenience. Estates that said no to hotpatch in 2025 were not being short-sighted. They were costing it correctly.
That answer is now wrong, and it is worth saying so plainly rather than letting a stale spreadsheet carry the decision. The remaining cost of hotpatch on an on-premises Windows Server 2025 machine is the Arc connection you have already made in order to use Update Manager at all, plus prerequisites the machine either meets or does not. The question has moved from whether it is worth paying for to why you would not. None of this changes the Azure side, where the capability was always bundled into the image and still is.
Prerequisites that are really design constraints
Three of the Arc prerequisites are ordinary and one is not. The ordinary three are the edition, which must be Windows Server 2025 Standard or Datacenter, the build floor, which is 26100.1742 or later with preview and Insider builds excluded because hotpatches are not produced for prerelease operating systems, and the installation option, where both Server with Desktop Experience and Server Core qualify. Those get satisfied by keeping a machine patched, which you are presumably already doing.
The fourth is virtualization-based security, also called Virtual Secure Mode, and it is a hardware and firmware decision wearing a patching hat. Microsoft states the floor as unified extensible firmware interface with Secure Boot enabled, and then draws the conclusion for you: therefore, for a virtual machine on Hyper-V, it needs to be a Generation 2 virtual machine. Generation is fixed when a virtual machine is created. It is not a property you edit on a Tuesday afternoon. So whether a given on-premises server can ever hotpatch was settled by a virtualisation decision taken years before the feature existed, by somebody who was thinking about boot devices rather than restart windows. APP02 qualifies because it was built as a Generation 2 machine. That is design, not luck, and it is the sort of design that pays out much later than it is made.
The enablement path is honest about this in a way I wish more features were. When you enable hotpatch through the portal it checks whether Virtual Secure Mode is running on the machine, and if it is not, enabling hotpatch fails and you have to go and enable it. The check happens at the gate rather than three months later in the form of a restart nobody expected. That is the correct place for it.
Which brings the small, slightly comic cost that belongs in the change request rather than the retrospective. Virtualization-based security is not documented as on by default in Windows Server 2025, so where it is off, enabling it is a registry change followed by a restart. You reboot the server once in order to stop rebooting the server. Nobody minds this if you say it first. Everybody minds it if the first they hear is an outage notice for a feature sold as removing outage notices.
The honest cadence, with 2026 as the evidence
The design is simple enough to state in one sentence. A baseline establishes the machine on the current cumulative update and requires a restart; the baseline refreshes every three months; the two months in between carry hotpatch releases that do not. Microsoft’s own illustration of a planned year is four baseline releases and eight hotpatch releases, which is where the quarterly language in every summary of this feature comes from.
Now the actual year, because the actual year is the argument. January 2026 was a planned baseline. February and March were hotpatches. April was a planned baseline. May was a hotpatch. June was a baseline, and it was unplanned. July was the next planned baseline. Count the restarts: four elapsed restart months by the end of July, against a design that budgets four planned restarts for the whole of 2026. The remaining months are scheduled as hotpatch releases with one further planned baseline in October, which projects to five for the full year if nothing else intervenes, and the whole point of the June entry is that things intervene.
June is what makes this real rather than pessimistic. Microsoft defines an unplanned baseline as one released during an unplanned important update, such as a zero-day fix, when that particular update cannot be released as a hotpatch, and then adds the sentence that matters operationally: developers cannot predict unplanned baselines in advance. So the exception clause is not a lawyer’s hedge. It fired in June, it landed immediately before a planned baseline in July, and enrolled machines took two restart months back to back. Windows Server 2022 shows the identical pattern across 2026, so this was a cross-product event rather than something peculiar to the newer operating system.
One counting trap, because I fell into it myself before checking the calendar row by row. April also carried an out-of-band release, on 19 April, and it shipped as a hotpatch. It adds no restart month. A count that treats every out-of-band event as a baseline arrives at five through July and overstates a case that is strong enough without help. August was scheduled as a hotpatch month, and I am not going to tell you how it turned out. The shape of the year is the argument, not the score.
Four restart months by July, against a design that budgets four for the year. That is still a good deal. It is not the deal that gets sold.
What is outside the programme
Hotpatch covers Windows security updates and maintains parity with the content of the security updates issued through the ordinary channel. It does not cover everything a Windows Server takes in a month. Nonsecurity updates for Windows are outside it. So are .NET updates. So is everything that is not Windows at all, meaning drivers and firmware. Those install the way they always did, and when they need a restart they get one, in hotpatch months as readily as in baseline months. A server that takes its .NET updates promptly restarts more often than the calendar suggests. That is not a fault, it is the scope of the programme.
There is also no automatic rollback. If a hotpatch causes a problem, the documented path is to uninstall the latest update and install the last functional baseline, and that requires a restart. The recovery route costs the thing the feature exists to avoid. It is a reasonable trade and it is not a secret, but it belongs in whatever document your change board approves, because the first time a hotpatch needs backing out is a bad moment to discover the shape of the remedy.
Sell fewer reboots with exceptions, never zero
The number you give the business is not zero, and the discipline of refusing to say zero is the difference between this feature building your credibility and spending it. What you are offering is quarterly planned restart windows instead of monthly ones, on the security content that makes up the bulk of what a server takes, with an exception clause the vendor exercises when a fix cannot ship as a hotpatch, and several update categories that were never in scope. Framed that way it is an easy sell and it survives June. Framed as no more reboots, it survives until the first unplanned baseline and then poisons every patching conversation you have with that room afterwards.
The failure modes are asymmetric in a way that shapes how you operate this, and both directions belong in the same paragraph. Enablement fails loudly: no Virtual Secure Mode, no enrolment, an error at the moment you asked for it. Falling out of eligibility afterwards does not fail loudly at all. Nothing errors, nothing alerts. The next update simply arrives as one that requires a restart, and if you were not watching the calendar you will read that as a normal month. So the operational posture for hotpatch is not waiting for an alarm. It is comparing what the release calendar said the month should be against what your own installation records say the machine did. The build sheet does exactly that, with a query.
The page that will tell you this is impossible
One service before the practical work. Update Manager’s own documentation on maintenance schedules still carries a sentence saying hotpatching is not supported for Arc-enabled servers. It is stale, contradicted by the dedicated pages on enabling hotpatch for Arc-enabled servers and on managing hotpatches on Arc machines, and by the billing section describing the May 2026 change. You will find it at the worst moment, halfway through explaining the plan to somebody whose approval you need. The answer is that the dedicated hotpatch pages are authoritative and the maintenance schedules page has not been revised. I would rather you heard that here than reversed a decision because of it.
Where this goes
The Arc route assumes the connection is already made, and this series does not re-teach it. What connecting the agent commits you to is argued in [ARC 2], and if APP02 is not connected yet then hotpatch is the second job rather than the first.
The build sheet takes both machines through in the order the work happens. APP02 goes the Arc way, with the Virtual Secure Mode check placed in front of the enrolment rather than behind it. AZSRV01 goes the short way, confirming that the image is genuinely one of the eight and that the state on the resource says what the marketing said it would. Both end in an installation record rather than a status field, because a status field tells you the machine is enrolled and only a record tells you a hotpatch arrived and nothing restarted.
After that the series returns to the harder half. Hotpatch changes when a machine restarts. It changes nothing about where the machine gets its updates, and every one of these ten servers except the unjoined one in Azure is still pointed at a WSUS box in a comms room. That is the cutover, and it is the longest piece of work in this subject.
Azure Update Manager
‹ Previous: [AUM 3.1] Build Sheet: Standing Up Update Manager Across the Estate
Next: [AUM 4.1] Build Sheet: Hotpatch on APP02 and AZSRV01 ›
