# Windows Server 2025 Hotpatch adoption toolkit

Version 1.0.0 · 2 November 2026 · Palanikumar Annamalai

Article: https://www.palanikumar.net/articles/windows-server-2025-hotpatch-readiness
Collector source: https://www.palanikumar.net/downloads/hotpatch/Test-HotpatchReadiness.ps1

## What you get

- Test-HotpatchReadiness.ps1: local Windows collector; outputs JSON, checks CSV and standalone HTML.
- Hotpatch.Readiness.psm1: pure decision and HTML rendering functions used by the scripts.
- Merge-HotpatchReports.ps1: reads existing JSON reports and creates fleet HTML/CSV.
- Compare-HotpatchEvidence.ps1: compares ordered before/after reports for one server and an approved KB.
- Three .kql files: read-only queries for Azure Resource Graph Explorer, not Log Analytics.
- adoption-register.csv: blank operating record with a clearly marked example row.
- sample-readiness.json and sample-readiness.html: SYNTHETIC examples, not machine or tenant evidence.
- SHA256SUMS.txt: file integrity manifest for the extracted toolkit.
- LICENSE.txt: MIT licence for community toolkit code; no Microsoft affiliation or certification.

## Scope and evidence boundary

This version covers the Arc path for non-evaluation Windows Server 2025 Standard and Datacenter.
Native Azure VM, Azure Edition, client Windows, evaluation editions and future build branches
need separate support-route review.

Local success means "Ready for Azure validation". It NEVER means enrolled, current baseline,
patched, compliant, or application healthy. The minimum build is not the current baseline.
Azure enrolment, heartbeat, update applicability, update source, licences, restart policy,
hypervisor compatibility and workload acceptance remain operator checks.

No Windows Server 2025 or Azure integration execution is claimed. See the article for the
actual validation scope. Offline fixtures are not real-world qualification.

## Requirements

Windows; 64-bit PowerShell process; Windows PowerShell 5.1 or PowerShell 7.
Read access to OS/CIM, Device Guard, Secure Boot and relevant registry locations.
Use an elevated shell where policy allows it for complete collection.
The Arc executable is only read if present at its normal Program Files installation location.
Keep all .ps1 and .psm1 files together.

Review source and use your approved code-signing process. Do not disable execution policy
to make downloaded code run. These community scripts are unsigned.
Do not dot-source the collector; execute it as a script.

## Verify the extracted files

From the extracted directory:

    Get-FileHash -Algorithm SHA256 -LiteralPath .\Test-HotpatchReadiness.ps1

Compare its digest to SHA256SUMS.txt. Repeat for the other files before running them.
The manifest is not an Authenticode signature and cannot establish independent publisher trust.

## Local collection

    .\Test-HotpatchReadiness.ps1 -OutputDirectory C:\Evidence\Hotpatch-Before -PassThru

The output directory must not already exist. This prevents accidental overwrites.
The collector writes readiness.json, checks.csv and readiness.html.
Open readiness.html locally. No server, external image, JS or internet dependency is required.

System reads: Win32_OperatingSystem, Windows CurrentVersion, Win32_DeviceGuard,
Confirm-SecureBootUEFI, azcmagent show status --json, three reboot indicators and Get-HotFix.
The script never calls azcmagent connect/check/disconnect, Windows Update scans, policy
writes, service changes or reboot commands.

## Results

- Ready for Azure validation: seven local checks passed; continue with cloud and workload proof.
- Needs review: failed or unknown check; inspect CollectionIssues in readiness.json.
- Unsupported for this path: OS, build branch/minimum revision, or architecture outside this route.

OS minimum: 10.0.26100.1742, on build branch 26100. This does not validate the monthly baseline.
VBS must have Win32_DeviceGuard.VirtualizationBasedSecurityStatus=2.
Secure Boot must be positively read as true; an exception is unknown.
A local Arc Connected status is not a verified Azure heartbeat or Hotpatch enrolment.
Pending-reboot checks cover CBS, Windows Update and PendingFileRenameOperations only.
Other products may have additional restart indicators.

## Fleet reporting

Run the collector locally on each server using your existing approved operations tooling.
This toolkit does not enable WinRM, configure remoting or save credentials.
Copy JSON reports to an access-controlled evidence folder.

    $reports=Get-ChildItem C:\Evidence\Servers -Filter readiness.json -Recurse
    .\Merge-HotpatchReports.ps1 -InputPath $reports.FullName -OutputDirectory C:\Evidence\Fleet

The merger recomputes decisions, produces fleet.html and fleet.csv, escapes HTML metadata,
and prefixes CSV formula-leading metadata. It does not prove that input files are authentic;
use your own protected collection and integrity process. Capture times remain visible.

## Before/after evidence

    .\Test-HotpatchReadiness.ps1 -OutputDirectory C:\Evidence\Hotpatch-After
    .\Compare-HotpatchEvidence.ps1 -BeforePath C:\Evidence\Hotpatch-Before\readiness.json -AfterPath C:\Evidence\Hotpatch-After\readiness.json -ExpectedKb KB1234567

KB1234567 is illustrative; substitute the approved current update.
The comparison checks server names, capture ordering and boot-time chronology.
It reports KB presence, boot-time changes and the after-snapshot reboot indicators.
It does not install/uninstall anything. Get-HotFix inventory is not exhaustive: confirm
the actual KB installation record in Update Manager and the servicing evidence.
Run the application's acceptance transaction separately.

## Azure Resource Graph

In the portal, open Resource Graph Explorer and scope the authorised subscriptions.
Run the supplied queries individually and export only to approved storage.
The reports contain Azure resource identifiers and operating data.
Summary queries are NOT a Hotpatch-specific compliance detector.
Use the current release calendar and selected KB details to establish update applicability.
Read permissions, on-demand assessments and installations require distinct Azure permissions.
Assessment retention is 7 days and installation-result retention 30 days; export if needed longer.

## Operational adoption

1. Fill in the adoption register and establish platform/application owners.
2. Confirm the Windows/hypervisor/firmware support route.
3. Collect local prerequisites, resolve unknowns, and retain reports.
4. Verify Azure heartbeat, Hotpatch enrolment, baseline and update source.
5. Use representative lab and pilot rings with a recovery exercise.
6. Agree schedule, time zone, restart policy, KB and promotion/stop conditions.
7. Compare before/after evidence and execute the workload acceptance test.
8. Stop promotion on unexpected failures; use the update-specific recovery procedure.
9. Keep maintenance capability for baselines, other updates and unplanned restarts.

There is no universal rollback script in this toolkit. Do not uninstall a KB based only on
the newest date in Get-HotFix. Read the affected update's supported recovery instructions.

## Privacy

No telemetry is sent. Local reports contain hostnames, OS/build, hotfix inventory, boot time
and diagnostic error messages, which can include infrastructure information.
Keep real reports internal and apply your normal retention/access controls.
Never submit real report files to a public issue without reviewing and sanitising them.
The supplied examples use fabricated inputs only.

## Validation

Repository test command (PowerShell 7):

    pwsh -NoProfile -File scripts/Test-HotpatchToolkit.ps1

Tests exercise decision branches, null/unknown values, HTML escaping, parsing and offline
file workflows. They do not qualify Windows Server Hotpatch, Azure, a hypervisor or application.
The toolkit is not a Microsoft-supported eligibility or compliance scanner.