Windows Server Hotpatch Became Free in May 2026: Here’s the Rollout Plan Sysadmins Need

You’re the Windows administrator on the hook for uptime and compliance. In May 2026, Microsoft removed the additional Hotpatch charge for Azure Arc-enabled Windows Server 2025. The economics changed, but the operating model did not become a simple on/off switch. Quarterly baseline updates still require planned reboots, and .NET, firmware, driver, emergency, and recovery work can still interrupt services.

This guide, verified as of August 27, 2026, lays out a fleet-level rollout: eligibility checks, Virtualization-Based Security (VBS) and Unified Extensible Firmware Interface (UEFI) preparation, pilot design, patch rings, Azure Update Manager orchestration, audit evidence, failure recovery, mixed-estate handling, and a 30–60–90-day adoption plan. It includes commands, decision tables, checklists, and measurable acceptance criteria. Even teams that decide not to enroll Hotpatch can use the same artifacts to improve Windows Server patch operations. By the end, you will have a defensible policy, an auditable schedule, and a rollback plan that treats “rebootless” as a reduction target rather than a guarantee.

1. Why the May 2026 Cost Change Alters the Rollout Decision

On May 19, 2026, Microsoft Community Hub published “Simplified access to Hotpatching enabled by Azure Arc for Windows Server 2025”. The announcement removed the additional Hotpatch charge for eligible Arc-enabled Windows Server 2025 machines. What had been a separately metered feature became part of the supported Standard and Datacenter experience when the server is connected through Azure Arc. The budget gate is therefore smaller; the decision now turns mainly on operational fit, prerequisite remediation, and the value of reducing planned reboots. Windows Server 2025 Datacenter: Azure Edition remains a separate case because Hotpatch is enabled by default in its supported Azure environment.

Availability and compliance are still the core decision factors. Under the normal cadence, an eligible server can receive security updates in eight Hotpatch months without a planned operating-system restart for the Hotpatch itself, while four baseline months still require a restart. Updates outside the Hotpatch scope can also force downtime. Microsoft Community Hub’s July 13, 2026 article, “Patch the Kernel, Skip the Reboot”, frames the benefit as reboot reduction, not reboot elimination. The rollout therefore starts with eligibility, Azure Arc and VBS preparation, and a small pilot; it then moves into Azure Update Manager scheduling, evidence capture, and rollback readiness. The System Administration Roadmap, Tools, and Salary article provides broader role context, but this guide stays focused on fleet implementation.

2. How Windows Server Hotpatch Actually Works

Hotpatching on Windows Server 2025 is not magic: it fits into a fixed update cycle. Understanding this cycle is key.

Baseline Months Versus Hotpatch Months

Windows Server Hotpatch follows a quarterly cycle. Microsoft Learn’s “Hotpatch for Windows Server” documentation, accessed August 27, 2026, describes a baseline month followed by two Hotpatch months. The baseline is a full cumulative update and requires a restart. For example, January 2026 used build 26100.32230 (KB5073379) as a baseline. The next two releases apply eligible security fixes to the running system without a planned restart. In the normal annual pattern, that means four planned baselines and eight Hotpatch releases.

The practical calendar is January baseline, February and March Hotpatch, April baseline, May and June Hotpatch, and the same pattern again in July through December. A baseline combines the full cumulative update content and resets the Hotpatch starting point. A Hotpatch month carries the eligible security fixes for that baseline without scheduling an operating-system restart for the update itself.

Compared with a traditional monthly-reboot model, Hotpatch can remove eight planned security-update reboots from the normal annual calendar. The four scheduled baselines remain mandatory for machines that stay in the program. Build those months into application, clustering, backup, and business calendars, and treat the two intervening months as lower-disruption patch events rather than as maintenance-free periods.

Updates and Recovery Actions That Still Require Reboots

Hotpatch does not eliminate reboots. Nonsecurity Windows updates, .NET updates, drivers, firmware, feature upgrades, unplanned baselines, and recovery work can still require a restart. That distinction belongs in the policy and in every change record so stakeholders understand exactly what the “no reboot” label covers.

Hotpatch currently excludes: nonsecurity Windows updates, .NET updates, and non-Windows updates such as drivers and firmware.

If the environment needs a .NET fix, a network or storage driver, firmware, or another non-Hotpatch update, schedule it through the normal servicing path and expect a restart when the package requires one. Grouping that work into baseline windows can reduce disruption, but emergency updates may override the quarterly calendar. Rollback also belongs in the reboot plan because reverting a problematic update usually requires a service restart, an operating-system restart, or restoration of a known-good system state.

Treat Hotpatch as a reboot-reduction mechanism for eligible monthly security fixes. Your runbook must classify every deployment as “Hotpatch, no planned OS restart,” “baseline, restart required,” or “exception, restart determined by the package and recovery plan.” That classification is the bridge between Microsoft’s servicing model and your own server maintenance windows.

3. Inventory the Fleet and Prove Eligibility

Before enabling anything, inventory every server and prove eligibility. Microsoft Learn’s “Enable Hotpatch for Azure Arc-enabled servers” documentation, accessed August 27, 2026, lists Windows Server 2025 Standard or Datacenter, build 26100.1742 or later, Azure Arc connectivity, and the documented VBS/VSM, UEFI, and Secure Boot prerequisites. Treat these as evidence fields, not assumptions.

• OS version: Query each server’s OS edition and build. For example, Get-CimInstance Win32_OperatingSystem can show Version and BuildNumber for a machine. You want build ≥ 26100.1742. On each server:
  

     Get-CimInstance Win32_OperatingSystem |
 Select PSComputerName, Caption, Version, BuildNumber

The caption should identify Windows Server 2025. Only Standard or Datacenter editions qualify in this Arc-enabled scenario; older releases, unsupported editions, and preview or Insider builds stay on the traditional patch path.

• Azure Arc connectivity: Verify the Azure Connected Machine agent is installed and reporting. In the Azure portal’s Arc dashboard (or via azcmagent CLI / Azure CLI), ensure each candidate is listed as “Connected” and registered as Windows Server 2025. If a machine isn’t Arc-enabled yet, onboard it: install the Azure Connected Machine agent and register under your subscription. Note: Windows Server 2025 Datacenter: Azure Edition doesn’t need Arc (it’s hotpatch-enabled by default in Azure), but Standard/Datacenter on-prem or multicloud do.

• VBS (Virtualization-Based Security): From the inventory results, note whether each Windows Server has VBS enabled. You could script it, e.g.:
  
  

    Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard win32_deviceGuard |
 Select PSComputerName, VirtualizationBasedSecurityStatus

A status of 2 means VBS is running. (VBS usually comes on if you’ve enabled features like Credential Guard or HVCI.) For any machine not running VBS, you’ll need to plan enabling it (see Section 4).

Use automation, including the inventory patterns in PowerShell 7.6 Cross-Platform Automation, to gather the data at scale across heterogeneous estates. Query through WinRM, an approved management platform, or Azure Resource Graph, then produce a report with server identity, edition, build, Arc state, VBS state, Secure Boot state, owner, workload, and eligibility result.

If a server fails any check, it’s ineligible until fixed. (Show this data to auditors later as proof you checked.) This is also a chance to discover surprises: perhaps some 2025 servers were installed without enabling Hyper-V, or are stuck on a 26100.1690 build from October 2025 and must be updated to the January 2026 baseline before hotpatch works.

With the fleet status in hand, quantify how many machines are ready and why the rest are blocked. Tag or group servers as Eligible, Needs Baseline, Needs Arc, Needs VBS/Secure Boot, Unsupported Edition, or Exception. This makes the rollout queue visible and prevents older firmware, legacy virtual-machine templates, and disconnected agents from being mixed into the first production ring.

4. Prepare Azure Arc, VBS, Firmware, and Secure Boot

Now validate the technical prerequisites on every candidate. Hotpatch depends on Azure Arc connectivity and the documented platform-security configuration. A server that is healthy at the application layer can still be ineligible because its firmware mode, Secure Boot state, VBS state, operating-system build, or Arc agent is wrong.

• Azure Arc agent: Deploy the Azure Connected Machine agent on each non-Azure candidate, register it in the correct subscription and resource group, and verify that it reports Connected before adding the machine to a patch ring. For bulk onboarding, review Microsoft’s Azure Connected Machine agent deployment options. For broader hybrid-cloud context, Refonte Learning’s Become a Cloud Engineer guide explains the surrounding cloud-management model.

• UEFI and Secure Boot: Confirm UEFI firmware and Secure Boot on physical servers and virtual machines. Hyper-V candidates should use Generation 2 virtual machines; VMware and other hypervisors need EFI firmware and Secure Boot enabled in the virtual-machine settings. Validate each cloud image or template rather than assuming the provider default is sufficient. If the documented firmware prerequisites are not present, exclude the machine until it is remediated or rebuilt.

• Virtualization-Based Security (VBS): VBS must be active. Check the Device Guard namespace and record the result before enrollment:

     (Get-CimInstance -Namespace root\Microsoft\Windows\DeviceGuard win32_deviceGuard). VirtualizationBasedSecurityStatus

A value of 2 indicates that VBS is running. If it is not, enable VBS through the organization’s supported Device Guard or security-baseline method. The registry example below is only one configuration input; firmware virtualization, Secure Boot, policy, and a reboot still determine whether VBS actually starts.

New-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\DeviceGuard' `
 -Name 'EnableVirtualizationBasedSecurity' -PropertyType DWord -Value 1 -Force

Reboot after the approved VBS change, then recheck the Device Guard status. If VBS still does not run, confirm CPU virtualization support, firmware settings, Secure Boot, hypervisor launch configuration, and any conflicting security or endpoint software before proceeding.

• Hardware/Vendor firmware: Some servers need BIOS updates or BIOS settings to support VBS/secure boot. It’s wise to update firmware/UEFI on baseline months as part of maintenance. Also update virtual network and storage drivers if required. Document all firmware levels in your inventory.

Validate at scale: Use a fleet query or configuration-compliance tool to check Secure Boot and VBS consistently. Windows Admin Center, Azure Policy where applicable, PowerShell, and configuration management can all contribute, but the final artifact should be one auditable data set with the same fields for every server.

Prerequisite checklist

☐ OS build ≥ 26100.1742 and correct edition on each target server.

☐ Azure Arc connected (Connected Machine agent installed and healthy).

☐ UEFI firmware and Secure Boot enabled in BIOS/VM settings.

☐ Virtualization features on (Intel VT-x/AMD-V in BIOS).

☐ VBS Enabled (DeviceGuard status = 2).

☐ Firmware/drivers updated to current versions.

Once all checks are “Yes,” you have an Arc-enabled, VBS-secured server ready for Hotpatch. If anything is unchecked, resolve it now or exclude that machine from hotpatch until fixed. Only when all prerequisites pass should you enable Hotpatch.

Validate Hardware and Virtual-Machine Prerequisites at Scale

For large environments, test a representative subset for compatibility first. For example, run a script on a batch of 10 servers across different hardware or cloud providers to verify VBS and secure boot. Record their outputs in a table or spreadsheet. If any fail, investigate early. You might discover, say, that an older VMware template was stuck on BIOS firmware, or a compute node lacked the “NoExecute” CPU feature. These insights let you plan fixes or segment your rings (see Section 7).

Use existing management tools if possible. Azure Update Manager’s “Baseline Assessment” feature can detect Windows Update compliance; similarly, Windows Admin Center or PowerShell DSC can check VBS settings. Whatever method, the goal is an auditable list of machines meeting (or missing) prerequisites. This proof-of-readiness will be needed both for rollout planning and later audits.

5. Design a Pilot Cohort That Can Safely Fail

With eligible servers ready, define a pilot rollout group. This is your canary: it should be large enough to test, but isolated enough to contain problems. Criteria for pilot selection include: non-critical workloads, easy rollback, and variety to surface issues.

Consider these factors:

• Workload criticality: Pick servers running development or staging services first, not peak-hour production. If a patch unexpectedly impacts performance, you have leeway.

• Environment diversity: If possible, include at least a couple of different configurations (e.g. one Hyper-V VM, one VMware VM, one bare-metal) so you test cross-platform. Also mix in different roles (e.g. one file server, one application server).

• Support path: Ensure you have backups or snapshots for pilot machines. Before enabling hotpatch, snapshot or image them so you can revert quickly if needed.

• Monitoring: Assign a small team or use existing monitoring to watch these servers immediately after each patch. Enable verbose Windows Update logging or link them to Azure Monitor.

Worked example: Suppose Contoso IT selects five pilot machines: three development or test virtual machines and two on-premises servers. All five meet the prerequisites. On June 1, the team follows Microsoft Learn’s “Hotpatching on Azure Arc-enabled Machines” workflow, accessed August 27, 2026, to enroll the machines. After the June 2026 Hotpatch, build 26100.32995, the deployment history shows successful installation with no operating-system restart. One server needs a service restart because of a custom driver dependency; the team documents the exception and moves that driver work into the next baseline window. Only after 48 hours of stable workload checks does the team promote the next ring.

You might capture pilot planning in a table like:

The pilot’s success criteria must be defined upfront: e.g. “All pilot servers apply hotpatch updates for two consecutive months with no critical incidents.” Measure things like patch success rate (via AUM compliance report) and absence of new errors. A decision table can help:

Set a deadline for pilot completion (e.g. 30 days). If the pilot fails by any criteria (e.g. app breaks), stop and roll back those servers (see rollback plan in Section 9). If it succeeds, gather what you learned and refine configs (maybe exclude some updates), then move to broader rings (Section 7).

6. Update Change Control and Maintenance Windows

Hotpatch changes your maintenance calendar. You’ll still need downtime windows for baseline patches, but fewer of them. Update your change-control policies and maintenance schedule accordingly.

• Document the new patch cycle. Update your IT maintenance calendar to show the new pattern: one planned downtime in Jan/Apr/Jul/Oct per year, and “hotpatch (no downtime)” windows in the two months following each baseline. Communicate this to all stakeholders (DBAs, app owners, network) so they know reboots are scheduled only quarterly now, not monthly.

• Revise Change Requests. Any CAB (Change Advisory Board) or maintenance planning docs should explicitly note that during hotpatch months, servers will patch with no restart. If your process usually logs every patch deployment as a separate change, you may consolidate hotpatch months to a single summary change ("Security hotpatch applied to all servers in Ring X").

• Maintenance windows. Keep a monthly patch-assessment and validation cadence, but reserve routine operating-system restarts for baseline months. In Azure Update Manager, schedule the Hotpatch deployment without adding an unnecessary restart action, and keep a separate baseline schedule that permits the required reboot. Do not advertise the intervening months as “no maintenance”; monitoring, exception handling, and application validation still occur.

• Coordinate firmware and .NET updates. Since hotpatch covers security only, use baseline months to tackle other updates. For example, tie your .NET cumulative updates to the same Jan/Apr/Jul/Oct windows. This avoids breaking the “no reboot” promise in intervening months.

Checklist for change control updates:

☐ Revise maintenance calendar with new patch windows.

☐ Update CAB templates to differentiate Hotpatch vs Baseline updates.

☐ Notify all server/application owners of new schedule.

☐ Adjust any automation (scripts, policies) that assumed monthly reboots.

Finally, record approvals. If required by compliance, get sign-off on this new patch policy. Show auditors that you’ve updated your documentation: the hotpatch rollout plan (sections of this article) itself can be part of the operational binder.

7. Orchestrate Patch Rings with Azure Update Manager

Use Azure Update Manager (AUM) as your central orchestrator. It lets you schedule hotpatch deployments across any Arc-connected or Azure VM machines. Plan deployment rings (groups of servers) that progressively scale out patches.

• Define rings. Common practice is 3–4 rings: e.g. Ring 0 = pilot/dev, Ring 1 = a small production subset, Ring 2 = bulk production, Ring 3 = remaining edge servers. Each ring should have clear criteria (as we outlined for the pilot). You might tag servers in Azure or in your CMDB (e.g. add “PatchRing=1”) and let AUM target them.

• Set schedules per ring. In AUM’s portal (Azure Portal > Update Manager > Machines > Update Deployments), create a separate Deployment for each ring. For Hotpatch deployments, choose “Monthly update” and select only Security updates (so it only picks hotpatchable updates). For example, schedule Ring0 to run as soon as a hotpatch is available (e.g. 2 days after release), then Ring1 one week later, etc. For baseline months, you can similarly use AUM but include all update classifications and allow the reboot (or coordinate manual reboot outside of AUM).

• Holds and promotion rules. Use AUM’s staging features (if available) or simply manual gating. If an update in Ring0 fails or causes issues, put a hold on Ring1+ until it’s resolved. Document the criteria to promote to the next ring: e.g. "Less than 1% failures and no Sev-1 incidents in Ring0 after two weeks, then proceed." Track a decision table like:

• Automate with infrastructure as code. For large fleets, define Update Manager schedules, scopes, tags, and policy assignments through supported templates or APIs so the ring design is repeatable. The operational discipline is similar to the practices described in DevOps Engineering: Kubernetes, Jenkins, Docker, Helm, Terraform: configuration is versioned, reviewed, promoted, and rolled back like any other managed resource.

• Monitoring ring progress. In AUM, track deployment status (Success, Pending, Failed) for each ring. The Hotpatch status column (enable it in the portal by Edit Columns > Hotpatch status) shows if a machine is Enabled, Pending, or Completed. Also use the “View History” tab in AUM to export results.

In short: implement a canary-to-global rollout using AUM. For example:

Azure Update Manager becomes your single pane: you can view compliance reports, set holds, and even integrate with Change Control via tags or deployment names. With everything in AUM, you have audit logs of who triggered a rollout and when, which we’ll capture for compliance.

8. Produce Patch Compliance and Audit Evidence

Auditors will ask for proof that (a) updates were applied and (b) reboots happened only when appropriate. Prepare documentation and reports.

• Compliance reports. Azure Update Manager provides machine and deployment status that can be exported for evidence. After each patch event, save the machine list, Hotpatch enrollment state, installed KB details, reboot-required state, and deployment outcome. Use exported CSV files and retained report snapshots rather than assuming a portal view will remain unchanged for the full audit-retention period.

• Baseline vs. Hotpatch logs. Maintain a table showing for each server the last baseline CU installed and the list of hotpatch KBs applied since. For example:

This shows the patch history and proves that the machine was up-to-date. Note any skipped hotpatches or out-of-band installs.

• Change logs and tickets. Include change request records from your CMDB or ticketing system that authorized each planned baseline maintenance (with date and outcome) and noted hotpatch launches. If you required application owner approval, keep those sign-offs too.

• One-time compliance check. Run a manual or periodic assessment after each deployment and retain the result that shows installed updates and whether a reboot is required. Pair the platform result with application health checks so the evidence proves both patch state and service state.

• Aggregate metrics. Prepare a controlled summary such as: “95% of eligible Arc-enabled Windows Server 2025 machines applied the quarter’s Hotpatch releases with no patch-triggered operating-system restart; 5% were approved offline or remediation exceptions.” Tie every percentage to an exported machine list and a defined denominator.

Compile the Update Manager exports, baseline and Hotpatch history, change tickets, owner approvals, incident records, and exception register into one evidence pack. Retain it according to policy, and archive cloud-generated logs before their default retention expires. The audit question is not only whether the KB installed, but also who approved the rollout, which ring received it, whether a restart was expected, and how exceptions were closed.

9. Detect Failure, Recover, and Roll Back

Despite care, patches can fail. You need monitoring and a clear rollback strategy.

• Detect failures. Use multiple signals: Azure Update Manager deployment status, Windows Update events, Event Viewer, service health, and application monitoring. Hotpatch failures normally surface as Windows Update error codes, so capture the hexadecimal code and the relevant event or log context. Get-WindowsUpdateLog can reconstruct a readable Windows Update log, while Update Manager history and installed-update data confirm whether the target KB was applied. Do not mark a deployment successful until workload health checks also pass.

• Immediate recovery. If a Hotpatch fails to install, retry it through the same approved update channel after checking Arc connectivity, Windows Update health, free disk space, servicing state, and agent status. If the retry fails or the machine falls out of the supported Hotpatch chain, move it to the baseline recovery path: install the appropriate cumulative update during an approved reboot window. Use snapshots or backups only according to the workload’s recovery design; a hypervisor snapshot is not a universal rollback method for every server role.

• Rollback planning. Hotpatch avoids a planned reboot for installation, but rollback is different. Reverting in-memory changes, uninstalling a package, or restoring a known-good system state generally requires a service restart or operating-system reboot. Prepare supported uninstall or restore steps, validated backups, workload drain or failover procedures, and application-level recovery checks. Do not plan to install an older cumulative update over a newer one; use the supported uninstall or restore path.

• Decision rules for rollback and emergencies:

Hotpatch has no universal in-place undo path. Recovery normally means a supported uninstall, restoration of a known-good state, or installation of a full cumulative update, followed by reboot and validation. Reserve emergency restart capacity even in Hotpatch months.

• Logging for rollback. Keep track of rollback actions themselves. If you had to reboot a hotpatch-eligible server to fix a problem, log it as an incident. This will be part of your audit story too: “We applied hotpatches (no reboot). On server X, hotpatch failed, so we installed a full update with reboot as documented in ticket #12345.”

Remember: hotpatch reduces downtime risk, but doesn’t remove the risk entirely. By monitoring closely in the first patch cycle on each ring, you can catch anomalies early. For major rollbacks, follow normal OS recovery procedures (Safe Mode, WinRE, WSUS rollback scripts) because at that point you’re treating it as a standard patch failure.

Why Rollback Still Needs a Reboot Plan

Because Hotpatch changes code used by running components, recovery from a problematic update often requires a restart to return the machine to a consistent state. The rollback runbook must therefore include stakeholder notification, workload drain or failover, the supported uninstall or restore procedure, reboot, and post-start validation. Treat rollback as an emergency baseline event, not as a second rebootless workflow.

A checklist snippet:

☐ Identify need to roll back (failed patch or outage).

☐ Notify users/teams of emergency maintenance (reboot).

☐ Use the supported uninstall or recovery path for the KB, or restore the approved image.

☐ Reboot system, verify stability.

☐ Document all steps for audit, then resume normal patch schedule.

10. Operate Mixed Windows Server Estates

Most enterprises have more than just Windows Server 2025. Your rollout must coexist with other systems.

• Windows Server 2022 and earlier: These versions are not generally hotpatchable (except Azure Edition). Continue patching them with your traditional approach (WSUS, SCCM or Azure Update Manager without hotpatch). Recognize that these servers still need monthly reboots for security fixes. Document this in your policy: “Hotpatch is only for WS2025 Std/DC on Arc; other servers follow normal update cadence.”

• Azure, on-premises, and multicloud. Arc-enabled Hotpatch can apply to supported machines outside Azure as long as the server meets the operating-system, Arc, and platform-security prerequisites. Windows Server 2025 Datacenter: Azure Edition is handled differently because Hotpatch is enabled by default in its supported Azure environment. Keep the two enrollment models distinct even if Azure Update Manager is used for common reporting and scheduling.

• Linux, SQL Server, and other products. Azure Arc can manage more than Windows, but Windows Server Hotpatch does not patch Linux packages or SQL Server product updates. Coordinate those maintenance streams separately. A Windows server that hosts SQL Server may still be eligible for operating-system Hotpatch, while SQL Server cumulative updates remain their own tested and approved process.

• Tool support: If you were using System Center or WSUS for patch management, you may shift to Azure Update Manager for consistency. AUM can manage all Arc-enabled Windows and Linux alike (though hotpatch behavior only triggers for Windows 2025). You can still target non-Windows machines in your patch rings for their updates in the same UI.

By clearly separating these cases in your documentation, you avoid confusion. For sysadmins and auditors alike, state: “Our hotpatch program covers the above WS2025 Std/DC servers. All other servers follow standard patch procedures.”

11. Model Availability and Total Cost of Ownership

A key rationale for hotpatch is availability. Quantify it:

• Downtime savings. Suppose a patch reboot produces 30 minutes of service impact per server. Twelve monthly reboots equal six hours per server each year; four baseline reboots equal two hours. The modeled saving is four hours per server. For 200 servers at $500 per server-hour, that is $400,000 in aggregate modeled availability value. Use your own measured restart duration, clustering behavior, service-level impact, and business cost rather than quoting the example as a universal result.

• Patch labor reduction. Hotpatch reduces reboot coordination, not the need for monthly assessment, deployment, and validation. If each reboot window requires two person-hours of coordination, eliminating eight of twelve routine reboot events saves 16 coordination hours per server group. Keep recurring labor for release review, Update Manager monitoring, exception handling, application checks, and audit export in the model.

• License cost. The additional Azure Arc Hotpatch charge is $0. That does not make the entire operating model cost-free: Azure Monitor ingestion, Log Analytics retention, network services, or other attached Azure capabilities may still be billable. Model those separately so the business case does not confuse “no extra Hotpatch charge” with “no Azure cost.”

• Total Cost of Ownership (TCO): Sum up:

•         Pre-hotpatch: 12 reboots, tool licensing (free or SCCM license cost), admin labor, risk of missing patches if reboots delayed.

•         Hotpatch model: four planned baseline reboots under the normal cadence, no additional Hotpatch charge, lower reboot-coordination effort, and an initial implementation cost for Arc onboarding, prerequisite remediation, monitoring, evidence retention, and runbook development.

A simple table can compare:

(This is illustrative; fill with actual values from your org’s metrics.)

Run the scenario with your own numbers. For 100 servers, four avoided reboot hours per server equals 400 aggregate server-hours. At a modeled $1,000 per impacted server-hour, the availability value is $400,000. Present the result as a model with stated assumptions, not as booked savings.

Remember to factor in hidden costs: baseline updates may grow larger (more fixes at once), so baseline patch windows could take a bit longer. But usually that’s offset by no reboots in the other months.

The security benefit is also operational: monthly Hotpatch deployment can shorten the period during which eligible security fixes remain unapplied because an application owner is resisting a reboot. That improvement is real only when the assessment, deployment, and exception process remains disciplined.

12. Govern Security Exceptions and Emergency Updates

No plan is complete without rules for exceptions. Hotpatch introduces new policy decisions around unplanned baselines and zero-day fixes.

• Zero-day fixes. If a critical vulnerability cannot be deferred and the required update is not hotpatchable, treat the event as an unplanned baseline. For example, a security release on March 20 might require a full cumulative or out-of-band update and a rolling reboot on March 22. Document the reason, affected scope, approval, schedule, validation, and the point at which normal Hotpatch cadence resumes.

• Unplanned baseline decision table:

Any reboot outside the four planned annual baseline windows should be deliberate and documented. Record whether it was triggered by an emergency update, missed patch chain, application recovery, firmware work, or rollback, then reset the next ring and baseline expectations accordingly.

• Security exceptions governance: If your organization maintains a patch exception policy (e.g. for a server that can’t reboot easily), specify how long you can extend a hotpatch-eligible server without patching. For example, you might allow one skipped hotpatch if it’s urgent for the app team, but require it be remediated by the next hotpatch or baseline. Keep a log of any exceptions (who approved it, why, when remedied).

• Change the rulebook: Update your security policy documents to include hotpatch logic. For instance, your Incident Response Plan should include “Check Hotpatch status” on affected servers. Your Risk Assessment might now factor “reduced downtime risk with hotpatch”.

Auditors will want evidence that emergency decisions followed policy rather than an ad hoc choice. Codify who can suspend the Hotpatch plan, when a full cumulative update is mandatory, how quickly affected rings must move, and what evidence closes the exception. A practical policy statement is: “For an urgent or out-of-band security update that cannot be delivered through Hotpatch, the normal Hotpatch plan is suspended for the affected scope, the approved full update is installed, and the required reboot and validation are completed.”

Zero-Day and Unplanned Baseline Decision Rules

A quick decision chart summarizing the above:

By having these rules ready, you won’t be scrambling when the unexpected happens. Train your ops team to follow this decision logic, and keep it near your runbook.

13. Execute a 30–60–90-Day Rollout

Turn strategy into action with a timed plan. Below is a sample 90-day schedule from kickoff to completion.

The timeline is illustrative and must be aligned to the actual Microsoft release calendar. A 90-day project may encounter one baseline and two Hotpatch months, but the starting date determines the sequence. Advance only when the measurable exit criteria are met; do not force a production promotion merely to satisfy the day number.

A key metric: Patch compliance rate. Aim for nearly 100% of hotpatch-eligible machines to install updates each cycle. Use the Periodic Assessment in Azure Update Manager to track this; export a compliance report (CSV) and note percentages.

At day 90, make an evidence-based go, hold, split, or stop decision. Full deployment is not the only successful outcome. A documented list of ineligible machines, approved exceptions, unresolved firmware work, and a safe continuation plan is more defensible than claiming 100% enrollment without control.

14. Build a Patch-Operations Portfolio Project

Treat the rollout as a capstone project. It produces a strong portfolio of operational artifacts: eligibility queries, prerequisite evidence, patch-ring design, change records, dashboards, incident handling, cost assumptions, and acceptance criteria.

• Implementation checklist and runbooks. Publish a step-by-step enablement guide based on Sections 3 and 4. Include annotated commands, data fields, decision gates, ownership, and the rollback path rather than screenshots without context.

• Patch ring design document: Include the tables you created (e.g. ring criteria table, timeline table). Show how you grouped servers and scheduled them. Recruit a small team to review it if possible, to validate completeness.

• Compliance reports: Save sample AUM reports or logs. For instance, a screenshot or export of the Azure Update Manager compliance blade, or a CSV showing Hotpatch status by server. Those are evidence of your work.

• Failure and recovery log. If rollback or troubleshooting was required, compile a brief incident report with the date, affected server, update, symptoms, detection source, containment, reboot or restore action, validation, downtime, and corrective action. A clearly labeled hypothetical example is acceptable for a lab portfolio; do not present a fictional vendor or production incident as real experience.

• Metrics summary: Show the “before vs after” of your patch schedule. How many reboots were saved (use your downtime estimates from Section 11). If you tracked uptime, include that too.

Assemble the result as a concise case study. The guidance in Job-Ready Tech Portfolio can help structure the evidence around the problem, constraints, decisions, implementation, measured result, and lessons learned. A suitable project title is “Windows Server 2025 Hotpatch Rollout,” followed by a neutral environment description rather than a fabricated customer name.

For added polish, version-control your scripts/configs (e.g., on Git) and write concise documentation in Markdown or PDF. If you keep it all organized, it’s a great artifact for interviews or performance reviews.

Use the project to demonstrate adjacent skills as well. Azure Arc onboarding exercises cloud administration, identity and access, networking, tagging, policy, automation, monitoring, and troubleshooting. Keep the portfolio focused on what you actually configured and verified.

With the rollout done and documented, the next step is ongoing ops: monitoring and adjusting as needed. But you’ve laid the foundation.

Conclusion

The May 2026 cost change makes Azure Arc Hotpatch easier to justify, but eligibility and operating discipline still determine whether it is safe. The first three actions are clear: inventory the fleet against the Windows Server 2025, build, Arc, VBS, UEFI, and Secure Boot requirements; remediate a small, recoverable pilot; then promote through measured rings with Update Manager evidence and explicit holds.

The most important caveat is that Hotpatch is not a reboot-elimination program. Planned and unplanned baselines, .NET updates, drivers, firmware, feature work, and rollback can still require restarts. A successful rollout therefore reduces routine reboot frequency while preserving maintenance windows, workload failover, audit retention, and emergency recovery.

This change-control project summarizes modern system administration: inventory, hybrid-cloud management, patch planning, scripting, troubleshooting, backup and recovery, and evidence retention. The Refonte Learning System Administration Program covers the supporting foundations in Windows and Linux administration, networking, security, virtualization, cloud administration, and troubleshooting. Exact Azure Arc Hotpatch lab coverage and current cohort dates should be verified on the live program page. The guide on How to Choose the Best Virtual Tech Internship can help readers assess practical delivery and internship structure before enrolling.

With the rollout plan in hand, the 30-day starting point is straightforward: run the eligibility inventory, assign owners for every blocker, configure Ring 0, and record the rollback method before the first deployment. The final decision can then be based on observed fleet data rather than on the word “rebootless.”