By the end of this you have Extended Security Updates running through Arc from eligibility to exit: coverage attested, the license resource provisioned deactivated with its two immutable choices made on purpose, the core math correct, activation timed with full awareness of the billing, the machines linked, the genuinely free machines tagged rather than assumed, and the exit planned before you need it. It is written against the current Windows Server 2012 and 2012 R2 program, whose deadline is close, with a forward note on the 2016 wave whose Arc pricing was not yet published when this was written. Verify the dates and any 2016 specifics before you act, because this is the fastest-moving corner of the platform.
Before Step 1: Arc-connected, healthy machines; active Software Assurance or a qualifying subscription to attest against; and rights to create the license resource and link machines. The whole model is a portal walk first, with the automation path named where it exists, because you provision a license resource, activate it, and link machines to it.
Step 1: Confirm eligibility and attest
ESU provisioning requires you to attest that the machines are covered by Software Assurance or a qualifying subscription, and there is no exception to that attestation. Confirm the machines are Arc-connected and reporting first, because a disconnected machine cannot carry an ESU entitlement, and confirm the coverage that entitles you to buy before you provision anything.
| Setting | Value | Why |
|---|---|---|
| Coverage attestation | Software Assurance or a qualifying subscription, attested at provisioning | Required with no exception; you are certifying the entitlement to purchase |
| Machine state | Arc-connected and reporting | The entitlement materializes on a connected machine; a dark machine cannot hold it |
| Agent | Current Connected Machine agent with the licensing prerequisites installed | Older agents cannot receive the keyless entitlement |
Step 2: Provision the license resource, deactivated
In the portal, create a Windows Server ESU License as an Azure resource, and create it deactivated. A deactivated license is inert and does not bill, which lets you get the sizing and the immutable choices right before any meter starts. Two properties cannot be changed after creation, so decide them deliberately now: the edition and the core type.
| Property | Choice | Note |
|---|---|---|
| Edition | Standard or Datacenter | Immutable after creation; must match the machines it will cover |
| Core type | Physical or virtual | Immutable after creation; drives the core math below |
| State at creation | Deactivated | No billing while deactivated; activate only when you are ready to start the meter |
To provision many of these at once, the license is the Azure resource type Microsoft.HybridCompute/licenses, which you can create through an ARM or Bicep template or the Connected Machine CLI with the same edition and core-type fields. Whatever the tool, those two fields are immutable once the resource exists, so the automation does not soften the decision, it only repeats it.
Step 3: Get the core math right
The cores you license, not the machines you link, are what you pay for, so the counting rules matter. There are minimums that apply even to small machines, and the edition interacts with the core type in a way that traps the unwary. Only three combinations are valid at all.
| Rule | Value |
|---|---|
| Minimum per virtual machine | 8 virtual cores |
| Minimum per physical machine | 16 physical cores |
| Standard edition | Covers up to two virtual machines per license |
| Datacenter edition | Unlimited virtual machines, but physical-core licensing only |
| Licensing by virtual core | Always select Standard, even on a Datacenter operating system |
| Valid combinations | Standard-virtual, Standard-physical, Datacenter-physical (Datacenter-virtual is not valid) |
Step 4: Activate, then link the machines
Activation is the moment the meter starts, and it starts whether or not you have linked a single server, so activate only when you are ready. Be aware of the back bill: if you provision after the support end date, activation back-bills to that date with no way to avoid it, and deleting and recreating the license does not escape it. Once active, link the eligible machines to the license. In the portal this is the Eligible resources tab: select the servers, choose Enable ESUs, and on the Enable Extended Security Updates pane pick the license and confirm, after which the ESUs status column reads Enabled for each. The link is not a property of the license but of the machine. It lives on the machine license profile, resource type Microsoft.HybridCompute/machines/licenseProfiles, whose esuProfile.assignedLicense holds the resource id of the license you are attaching. To automate it you PUT that license profile onto each machine with the assigned license id set. There is no first-class Connected Machine CLI verb for the link today, so the honest automation path is that license profile resource through a template or a REST call, not a one-line command that does not exist. Once linked, the updates begin flowing through whatever patching mechanism you already use.
Step 5: Tag the genuinely free machines
If you have Visual Studio dev and test machines or Software Assurance cold disaster-recovery instances, they can receive ESUs at no extra cost, but only by linking them to a license you are already paying for on production and tagging them for the exemption. You cannot create a license whose machines are all free, and the tags do not reduce the chargeable cores; they only link an eligible machine to a license whose payable cores are already provisioned. This step is correct classification, not cost avoidance.
Step 6: Plan the exit before you need it
The end of the story is as important as the start, because billing follows the license resource rather than the calendar. When the program ends, or when you retire or upgrade a machine, the charges do not stop on their own. Three exits need a deliberate hand.
| Event | Action you must take |
|---|---|
| Program reaches its end date | Deactivate and delete the license resources; billing does not stop automatically |
| Machine upgraded in place to a supported OS | Unlink the ESU license; it is not removed automatically and will keep billing |
| Machine retired | Unlink and decrement the cores; a linked-but-gone machine still counts |
The attestation the rest of the series relies on
ESU carries its own attestation at provisioning, but there is a second, broader one that earlier articles leaned on without showing: Windows Server Management enabled by Azure Arc. This is the attestation that waives the machine configuration meter in the baseline build sheet and covers Azure Update Manager in the patching one, and it is worth doing deliberately because it is a legal statement about your licensing, not a convenience toggle. In the Azure Arc service menu, open Licenses and the Azure Benefits, Windows Server page, select the eligible Arc servers, choose Activate benefits, read the terms, and check the attestation box to confirm the servers carry active Software Assurance or subscription licensing. Unlicensed servers are not eligible and must not be attested. What it unlocks is the set of management capabilities the rest of this series treats as free: Azure Update Manager, Change Tracking and Inventory, machine configuration, Windows Admin Center in Azure, and the remote support surface, at no cost beyond the networking, storage, and log ingestion they consume. The attestation is per eligible server and auditable, so give it the same care as the ESU purchase itself.
The dates that decide the urgency
Two dates set the whole timeline. The Windows Server 2012 and 2012 R2 ESU program reaches its end on October 13, 2026, the third and final year, after which no further updates are produced for that operating system by any purchasing route. That is the current planning horizon, not a distant one. Behind it, Windows Server 2016 leaves extended support on January 12, 2027, and Microsoft has confirmed its Extended Security Updates will be delivered through Arc, but at the time of writing the per-core pricing and the enrollment mechanics for the 2016 program were not yet published, so resist quoting a number for it. The visible precedent is the SQL Server 2016 program, whose subscription began on July 14, 2026 as the first ESU shipping under the new pricing model, and that model matters because, for offerings released under it since April 1, 2026, the cost is the same whether the machine runs on Azure, on-premises, or in another cloud. The old pattern where moving a workload into an Azure virtual machine made its ESUs free does not carry into this generation, so plan on paying for 2016 ESUs wherever the machine lives.
A worked example
Two machines, two different licenses. A physical two-socket host running Windows Server 2012 R2 Datacenter with twenty-four physical cores needs a Datacenter, physical-core license sized at its twenty-four cores, comfortably above the sixteen-core floor. Separately, a pair of small virtual machines on Windows Server 2012 R2 Standard, four virtual cores each, goes on a single Standard, virtual-core license, because Standard covers up to two virtual machines. Here the minimum bites: each of those four-core virtual machines is billed at the eight-virtual-core floor, so the license carries sixteen virtual cores, not eight, even though the machines only use four each. Sizing to actual cores rather than the minimum is the most common way an ESU budget comes in wrong, and the fix is to count against the floor from the start.
Naming convention
Name license resources for the edition, core type, and program they serve, for example esu-ws2012r2-std-vcore and esu-ws2012r2-dc-pcore, so a glance tells you what a license covers and what it cannot. Reserve a clear tag such as ESU-Exemption=DevTest or ESU-Exemption=DR for the machines you are linking under the free scenarios, so the exemption is auditable and no one later mistakes a free machine for an unlicensed one. The names and tags are what let a bill be reconciled against reality months later.
The end-to-end test
Confirm the entitlement actually lands before you trust it across the fleet. First, the machine should read Enabled in the Eligible resources view, which is the control-plane confirmation that the link took. Then prove it on the machine itself: install an Extended Security Update through your normal patching path and confirm it succeeds on a server that, without the entitlement, would be refused that update. For a fleet-wide signal, the built-in machine configuration policy named Extended Security Updates should be installed on Windows Server 2012 Arc machines reports which linked machines are actually current, so a machine that shows Enabled but is not patched is caught rather than assumed. An update that installs where it would otherwise be blocked is the proof that the license, the link, and the delivery are all working together.
Rolling it back
ESU enrollment is the one rollback in this series where the money keeps moving after you finish, so do it in this order and then verify the bill rather than assuming it stopped. Billing follows the license resource, not the machine and not the calendar.
- Unlink the license from each machine first, by clearing the machine’s license profile so
esuProfile.assignedLicenseno longer points at your license resource. In the portal this is the machine’s Extended Security Updates pane; through the API it is a PUT to the machine’slicenseProfiles/defaultresource with an emptyesuProfile. - Deactivate the license resource, then delete it:
Microsoft.HybridCompute/licenses, for exampleesu-ws2012r2-std-vcore. Deleting an activated license without unlinking first leaves machines pointing at something that no longer exists, which is recoverable but not tidy. - Expect a billing tail and plan around it. Decrementing cores, deactivating, or deleting a license all result in charges for up to five more calendar days from the time of the change. Reduction in billing is not immediate, and a bill that keeps arriving for a few days is not evidence the rollback failed.
- Do not expect deactivation to be a way out of back-billing. Deactivating and later reactivating bills you for the window in between, and deleting and recreating does the same, so a rollback you intend to reverse in a month is not a saving, it is a deferral with paperwork.
- Remove the free-usage tags you set for dev, test, and disaster-recovery machines if those machines are leaving the program, so a future audit does not read an exemption that no longer has a license behind it.
- Confirm billing stopped on the invoice, after the five-day tail, and confirm the machines stop receiving ESU content. Both halves matter: an unlinked machine that is still billing means a license you did not delete, and a deleted license against a machine still expecting patches means an unprotected server.
Before you scale it
- Coverage attested, machines Arc-connected, agent and licensing prerequisites current.
- License provisioned deactivated, with edition and core type chosen deliberately because they are immutable, and only a valid combination used.
- Core math correct: the 8-virtual and 16-physical minimums met, and the edition-to-core-type rule respected.
- Activation timed deliberately, with the back bill understood if provisioning after the end date.
- Free dev-test and disaster-recovery machines tagged and linked to a paid license, not left unclassified and not expected to stand alone.
- Windows Server Management benefit attested wherever you intend to rely on the free management surface, kept distinct from the ESU coverage attestation.
- Exit planned: deactivation at program end, and unlink on upgrade or retirement, are on the runbook rather than left to chance.
- End-to-end test passed: an Extended Security Update installed on a linked machine.
With licensing and updates handled, one capability remains before the series closes: the security attach. The next article covers Defender for Servers delivered through Arc, and the decision of whether to reach it through Arc at all or through direct onboarding instead.
Azure Arc
‹ Previous: [ARC 6] ESUs and Licensing: The Plane Pays for Itself
Next: [ARC 7] Defender for Servers via Arc: Enabling the Security Attach ›
