"Central Management of All Servers" as an Audit Requirement: Meeting an Acquirer's or Insurer's Checklist with Azure Arc, Azure Update Manager and a Change Record They Can Audit

A row that reads "central management of all servers" unpacks into four questions: is every server on a list someone maintains, is each one patched within a stated number of days, is administrative access limited to named people, and is there a record of what changed and when. The acquirer wants the same evidence for your servers that it has for its own.

For an on-premises estate the answer has three parts. Azure Arc makes each server an Azure resource, the inventory and the control plane: one list with operating system, tags, owner and a Connected status, plus role assignments that decide who can act on the servers from Azure. Azure Update Manager, with maintenance windows matching your after-hours schedule, is the patch evidence: an assessment per machine and a history of every run. A change record per server, kept where the acquirer can open it, is the audit trail.

The row does not require Defender for Cloud, Log Analytics ingestion, Change Tracking and Inventory or Sentinel; each is a separate Microsoft meter that stays off unless another row asks for it by name.

The mapping document keeps the reviewer's wording in the left column.

Who signs in as an administrator is still decided in Active Directory, not in Azure, so the access row needs both exports.

Four weeks is a workable window for a dozen to twenty-five servers on, or being rebuilt to, a supported operating system.

Week 1: inventory and decisions. List every server with operating system, role, owner and whether it is being rebuilt, upgraded or retired. Decide the subscription, the resource group, the region and the tags. Submit the firewall change: outbound HTTPS on port 443 to the Connected Machine agent endpoints Microsoft lists, or the Azure Arc gateway, which shortens that list.

Week 2: onboarding and schedules. Connect each server as it reaches Windows Server 2022 or 2025, by onboarding script or Group Policy, and attest the license where it qualifies. Turn on periodic assessment, create maintenance configurations matching the after-hours schedule, and let the first run write its history. Servers still on Windows Server 2016 go through the 2016-to-2025 upgrade or a rebuild first; connected as they are, they leave support on 12 January 2027 and belong on the exceptions list.

Week 3: access, record, exceptions. Grant the acquirer's named reviewers Reader on the resource group. Agree the change record format and back-fill it from week 1. List every server not onboarded, why, the compensating control and the closing date.

Week 4: the mapping document and a dry run. Let the reviewer sign in and find each item, and fix what they could not find.

If the servers are going onto Arc anyway, yes. Microsoft's list of features removed or no longer developed in Windows Server marks WSUS as no longer actively developed: the role remains in Windows Server 2025 and its existing capabilities and content continue to be available, but nothing new is built, and the deprecation announcement points server customers to Azure Update Manager.

WSUS Replacement with Azure Update Manager does the swap, with a period where both run side by side.

Ask once, in week 1, and accept either answer. The practice's own subscription sits in the practice's tenant, which passes to the acquirer with the company, so Arc resources created there arrive with the acquisition, invoice included. The acquirer's subscription puts the servers beside its other estates from day one and lets its reviewers use access they already have.

Either works because re-pointing an agent is small work: disconnect, reconnect with a new onboarding script, re-apply the tags so the dynamic scope picks the server up, and it is back under a new resource ID with one line in the change record. Waiting is the expensive part: two weeks of deciding is half the window, and a server connected to nothing is a row the reviewer cannot tick.

Mail, files, identity and what the acquirer retires later are the subject of the tenant-to-tenant migration guide; this article covers only the servers.

A change record has one line per change per server, holding seven things: the server (its Arc resource name, matching the inventory), the change in one sentence, the state before, the state after, the timestamp, who made it, and how it was verified. "DC02 | Connected Machine agent installed | not connected | Connected in rg-servers | YYYY-MM-DD HH:MM | the signed-in account | Arc shows Connected, heartbeat current" is a complete line. Without the verification column a line is a claim.

A SharePoint list or workbook in the practice's tenant is the usual home, because the tenant passes to the acquirer and the record with it; versioning stays on, and a dated PDF goes over at hand-over. Azure's Activity Log corroborates the portal-side actions but is not the record: it knows nothing about the Group Policy change or the firewall rule.

The acquirer reads it by filtering to one server and walking the lines against the inventory and the Update Manager history: a window set on a date should match the configuration's creation entry, and a retired server should be gone from the inventory.

A medical practice of about 200 users and about 250 Windows devices is being acquired by a hospital group. The acquirer has set a possession date about four weeks out and sent a security checklist with a row requiring central management of all servers; it will not migrate mail or files and will retire the tenant later.

The plan in progress: about a dozen servers, new domain controllers, Hyper-V hosts, file and print, the Entra Connect server and application servers, are being rebuilt on Windows Server 2022 and connected to Azure Arc as each reaches the supported build. Azure Update Manager gets maintenance windows matching the after-hours schedule, which also settles an open WSUS question. The acquirer's team receives read-only access. Log collection and Defender for Cloud stay off; a third-party EDR and SOC are already in place. A change record is kept from the first change because the acquirer may audit it.

Two side decisions. Servers that retire after conversion carry a one-year Windows Server subscription rather than a perpetual license, which also qualifies them for Update Manager under the attestation rule. And a legacy digital-signage system on a Windows Server 2016 virtual machine, which its vendor will not move, is kept supported with a Windows 10 IoT Enterprise LTSC license instead of ESU; the one server you cannot replace walks through that decision.

Microsoft's charges are the customer's, on the Azure subscription the servers sit in; our fees are quoted in writing before work starts.

Microsoft. The Arc control plane is offered at no extra cost from Microsoft. Azure Update Manager is included at no extra charge from Microsoft for an Arc-enabled server that is attested under Windows Server Management enabled by Azure Arc (active Software Assurance or Windows Server subscription licenses, or Windows Server pay-as-you-go through Arc), enrolled in Extended Security Updates through Arc, or in a subscription with Microsoft Defender for Servers Plan 2 enabled; any other Arc-enabled server is charged per server per month, prorated for the days it is Connected and managed, and Microsoft states that eligibility is not inferred from the Arc connection itself. Every add-on kept off is charged at its own price if a later row turns it on; Azure Arc for the servers you are keeping lists every meter, and Defender for Servers deployment covers that day. On Windows Server 2025, hotpatching domain controllers covers the hotpatch charge, removed on 19 May 2026, and what enrollment needs.

Ours. Azure Arc Hybrid Server Management Implementation is $25 per server plus a $1,950 tenant fee over two weeks: design, rollout, tagging, attestation and policy. WSUS Replacement with Azure Update Manager is $15 per server plus a $1,950 tenant fee, two weeks, including the WSUS decommission. For the audited estate, Azure Arc Onboarding with Azure Update Manager for an Audited Estate is $25 per server plus a $1,950 tenant fee, one week, up to 25 servers in one subscription, maintenance windows, change record format and mapping document included.

Our acquirer requires central management of all servers. Is Azure Arc enough, and how do we show it in an audit?

Arc covers inventory and access; patching needs Azure Update Manager, and changes need a record you keep. Hand over a one-page mapping document and let the reviewer open each screen.

Should we replace WSUS with Azure Update Manager for on-premises servers?

If the servers are going onto Arc, yes: WSUS is deprecated, and Update Manager gives the estate-wide view a reviewer asks for; it is included under the attestation, ESU or Defender for Servers Plan 2 rules, otherwise charged per server per month.

We are being acquired in four weeks and have to finish a server checklist. What can realistically be done?

Inventory, Arc onboarding of every server on a supported operating system, Update Manager schedules, read-only access, a change record, an exceptions list and a dry run; rebuilding every server is not, and the exceptions list answers those rows.

Which Azure subscription should the servers go in when the tenant passes to the acquirer?

Either; the practice's passes with the tenant, the acquirer's puts the servers beside its own. Decide in week 1, since re-pointing agents later is an evening's work.

Does the row require Defender for Cloud or log collection?

No. Both are separate Microsoft meters that stay off unless another row asks for them by name; an existing third-party EDR and SOC answer the endpoint rows.