Skip to content

Field note

Windows Server Hotpatch: Plan Baseline Reboots

A server can be enrolled in Hotpatch and still be waiting for updates or a restart.

Published17 Oct 2026

Updatedyesterday

Read time4 min. 795 words.

Microsoft’s 30 September Azure Arc episode explains the operational setup for Windows Server 2025 Hotpatch. It is a useful prompt to review maintenance plans, rather than a reason to remove restart windows from the calendar.

Hotpatch reduces the restarts associated with supported operating system security updates. The surrounding application, drivers, firmware and recovery arrangements still need attention.

Put the baseline restart in the calendar first

Microsoft describes a normal Hotpatch cycle with a baseline update requiring a restart, followed by Hotpatch updates. Unplanned baselines can also require a restart. Updates outside the Hotpatch scope, including drivers and .NET updates, need their own handling.

Build the maintenance calendar around that distinction. Mark which windows are expected to include a baseline, who can authorise an additional restart, and how the application owner will confirm recovery.

Avoid a calendar entry that says only “Windows patching”. A useful entry identifies the service, its dependencies, the person who can stop and start it, and the evidence needed before users return.

For a clustered or redundant service, the runbook should explain the supported order for moving work and updating members. For a single server, it should explain the interruption the business has accepted. Hotpatch does not supply application redundancy.

Check the exact server path

The Arc-enabled deployment guidance sets prerequisites for Windows Server 2025 Standard and Datacenter, including a supported build, Azure Arc connectivity and running Virtualization-based Security. Azure Edition uses a different deployment path.

Inventory the actual machines before building one universal script. Record edition, build, hosting platform, Arc status and the relevant security state. Include template and image ownership: a corrected server today is not enough if next month’s deployment recreates the missing prerequisite.

Microsoft documents this read-only check for Virtualization-based Security:

Get-CimInstance -Namespace 'root/Microsoft/Windows/DeviceGuard' -ClassName 'win32_deviceGuard' |
    Select-Object -ExpandProperty 'VirtualizationBasedSecurityStatus'

A result of 2 means the feature is running. This is a documentation-based diagnostic, not a command tested against your servers. Run it with the appropriate access and retain the result with the inventory.

If a prerequisite needs a restart to enable it, include that restart in onboarding. Do not promise that adopting a restart-reduction feature can always begin without an interruption.

Verify installation separately from enrolment

Azure Update Manager’s Hotpatch view separates enablement, assessment and update status. An enabled machine still needs an update installation process.

Use a small operational record for each maintenance cycle:

Assessment timeIs the update view recent enough to use?
Installed update and resultDid the intended update reach this machine?
Restart requirementIs the machine waiting for a remaining step?
Application checkCan the business service perform its agreed task?

Keep the application check specific. A successful service start is useful, but a scheduled import, queue consumer or database connection may still be broken. Choose a small transaction that exercises the service’s important dependency without changing production data unnecessarily.

Record who reviews a failed installation and how long it can remain unresolved. Otherwise, a fleet can appear modern because Hotpatch is enabled while individual machines repeatedly miss the actual update.

Prepare for a failed update

Microsoft does not describe Hotpatch as providing an automatic rollback. Its guidance includes uninstalling the affected update and returning to an appropriate baseline, with a restart.

Build the response around the service’s recovery method. Confirm the available backup or image, the data recovery implications, and the time needed to restore normal work. Decide in advance who chooses between repairing the update and recovering the server.

Use a representative non-production machine to practise the documented maintenance path. Do not experiment with uninstall commands on a production server simply because a portal result looks unusual.

Report what improved

Track planned restarts avoided, baseline restarts completed, overdue updates and failed application checks separately. These measures answer different questions.

The useful result is a service that receives updates with fewer avoidable interruptions, while retaining a credible route through the interruptions that remain. Keep that route staffed, documented and exercised.

References

Related notes

Need help mapping this to your own tenant, controls, or assessment timeline?