Phase two is the operation everybody braces for, and it does not happen in Azure. Nothing in the subscription changes: the maintenance configurations stay as written, the tags stay where they are, the schedules keep firing on the same evenings. The whole cutover takes place in Group Policy, using tools that predate the cloud by a decade, and Update Manager’s only job is to tell you afterwards whether it worked. That is not a gap I am working around. It is Microsoft’s instruction, and its consequence is that the riskiest step in this series is a change to the one technology nobody in the room treats as risky.
The half that was never Update Manager’s to move
This is where the separation of the two powers gets cashed in. Update Manager honors the update source settings on the machine and fetches updates accordingly, and it does not publish or provide updates. It holds the change window and nothing else. So when the time comes to change where content comes from, the product that has been orchestrating your patching for months has no verb for it. Microsoft says so directly: to change the patch source, use Windows settings or Group Policy, and do not use Update Manager for this configuration. That is written in the imperative, not the apologetic. It is a boundary the product defends rather than a feature it lacks, and it is the right boundary. If Update Manager could rewrite the source, the principal who decides when a domain controller reboots could also decide what it is offered.
Most migration plans get the consequence backwards. Teams book the cutover as an Azure change and put the Azure engineer on the bridge. The actual operation is a security group membership edit, made in a console with no staging, no preview, no ring concept and no undo beyond a backup somebody may or may not have taken, applying on a refresh cycle you influence rather than control, against a machine set defined by an access control list that has been drifting for a decade. That is the risk profile, and it is not a cloud one.
One policy holds the entire estate
Strip away everything else in the update GPO and one setting is doing the work. Specify intranet Microsoft update service location writes two string values, WUServer and WUStatusServer, under HKLM\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate, and the switch that makes them live, UseWUServer, as a DWORD set to 1 under the AU subkey beneath it. Nine of Cat Snack Jack’s ten servers carry those three values because one GPO reaches them. That is the whole of the pin.
The removal behaviour is documented as plainly as the setting. If the policy is Disabled or Not Configured, and Automatic Updates is not disabled by policy or user preference, the Automatic Updates client connects directly to the Windows Update site on the internet. There is no migration step and no new source to configure. The machine’s default state is to talk to Microsoft. Every WSUS estate is a set of machines held away from that default by a policy, and the cutover is nothing more than letting go.
One casualty deserves naming while we are in the key. Client side targeting, which wrote machines into WSUS computer groups from the client end using values the shipped administrative template names TargetGroupEnabled and TargetGroup, has no effect once the intranet update service location policy is disabled or not configured. Your WSUS computer groups become an inert list, and their replacement is the tag query a maintenance configuration evaluates at run time.
Policies clear, they do not tattoo
The single property that makes this operation survivable is that every value involved lives under HKLM\SOFTWARE\Policies, the true policy hive. Values written there are owned by the registry client side extension, which removes them at the next refresh once the governing policy stops applying. The machine returns to the state it would have been in had the policy never reached it, which is the state where it talks to Microsoft.
That is what distinguishes an administrative template setting from a Group Policy preference. Preferences tattoo by default, writing outside the policy hive and staying written after the object that put them there is gone. Which matters in one circumstance, worth ruling out before you start: if the pin was ever pushed as a preference item, descoping changes nothing at all.
The reason this cutover can be rolled back is that the values clear when the policy leaves. Confirm that property in your estate rather than inheriting it as an assumption.
There are two real exceptions, both field reported rather than documented, so weigh them as practitioner experience. The first is the value that will not die. You descope the machine, refresh policy, delete the key by hand, and WUServer comes back. The cause is almost never Group Policy. It is something else on the machine writing the value, classically an endpoint protection or remote management agent with its own patch distribution role, quietly pointing the local client at itself. A value that reappears with no policy in scope capable of writing it means the question is which agent, not which GPO.
The second is subtler and cuts the other way. If your estate has enabled the setting that makes registry policy processing run even when the GPOs have not changed, a common hardening choice, the extension deletes and rewrites the whole policy branch on every refresh rather than leaving it alone. For a short interval each cycle the values genuinely are not there, and a scan landing inside that interval sees no WUServer, concludes it has no intranet source, and goes to Microsoft. The machine is not misconfigured. It is correctly configured for most of every cycle and momentarily configured as something else, which produces a server that occasionally patches from the wrong place for reasons no policy report will show.
Descope, do not edit
There are two ways to stop a policy applying to a machine. You can change the policy, or you can change who the policy applies to, and only one of those gives you rings. Editing the GPO is the obvious move and it is the wrong one. Set the intranet service location setting to Not Configured and every machine the object reaches loses its pin on the next refresh, on a timetable set by the refresh interval rather than by you. The pilot ring and the domain controllers cut over in the same ninety minutes. There is no first ring to learn from because there is no second ring left to apply the lesson to, and the rollback is another edit to the same shared object, made under pressure.
Leave the GPO byte for byte as it is and change its scope instead. Whether you do that by security filtering on a group or by moving computer objects between organisational units matters less than the property both share: the change is per machine, reversible by exactly one inverse operation, and the object every remaining machine reads is untouched. My preference is the group, because membership is a directory operation with its own audit trail and its own delegation model, and because a group can be edited by someone with no rights over Group Policy at all. There is a second benefit I now rely on: the group is a live inventory. Its membership at any moment is precisely the set of machines still taking content from WSUS, and when it is empty the source cutover is finished. That is a better migration tracker than anything you would have built, and it is a side effect of choosing the reversible technique.
The discipline the GPO was also carrying
Here is the step that gets skipped, and it gets skipped because it is the only part of the operation that is not about the source. The WSUS GPO was never only a pointer. In almost every estate it also carries Configure Automatic Updates, which writes NoAutoUpdate and AUOptions into the same AU subkey, and that is the setting telling the local Windows Update agent whether it may act on its own initiative. Update Manager’s coexistence guidance wants NoAutoUpdate set to 1, because the premise of scheduled patching is that installs happen inside a window somebody owns and nowhere else.
So consider what descoping actually removes. Not only the sentence saying where to look, but the sentence saying do not act by yourself. A machine that has lost both has a direct line to Microsoft and nothing restraining it, and the local agent is perfectly capable of downloading and installing on a schedule of its own choosing. That is the phantom reboot people report weeks after a cutover, blamed on Update Manager, caused by its absence. Remember which component executes here. Update Manager orchestrates and the local agent installs, and on an Arc connected machine Update Manager writes nothing to the registry at all: Group Policy fully controls update behaviour, which is Microsoft’s own phrasing, and it holds whether or not a policy in scope is saying anything sensible.
The answer is a successor GPO, built before the first ring moves, carrying the update discipline forward without the pin. It holds the automatic update behaviour and says nothing about a source. It is scoped to the machines already cut over, so it grows as the WSUS filter group shrinks, and the two together mean every server is under exactly one update policy at every moment of the migration. Design for that symmetry deliberately, because the alternative is a window in which a machine is under neither, and that window is where the surprises live. The restart decision belongs in the same object, aligned rather than arguing: reboot behaviour is the maintenance configuration’s to state. Be honest with your change board about the ceiling on that, because Microsoft documents that a reboot can occur even when you specify never reboot. It is a strong preference expressed to a component that has the final say.
The lockdown that strands a machine
One more setting has to be found before anything moves, and it is the one most likely to be somewhere you are not looking. Do not connect to any Windows Update Internet locations, which writes DoNotConnectToWindowsUpdateInternetLocations as a DWORD set to 1, stops a machine reaching Microsoft even for the incidental traffic a WSUS pinned client would otherwise generate. Microsoft is explicit that it applies only when the device is configured to connect to an intranet update service, and equally explicit that enabling it may cause connections to public services such as the Microsoft Store and Delivery Optimization to stop working.
Put those two facts next to each other and the failure writes itself. While the pin is in place the setting is inert as far as patching goes, because the machine was going to WSUS anyway. Remove the pin and leave the lockdown, and you have a server told not to use the intranet source it no longer has and forbidden the internet source it now needs. It reaches neither, nothing errors loudly, and because Update Manager reports what the local agent found, it reports a machine with nothing pending. That looks like compliance. So the ordering rule is absolute: the lockdown goes in the same change as the pin, or before it, never after. The reason it is easy to miss is organisational. It is a hardening setting, usually living in a baseline object owned by another team and absent from the mental model of whoever runs the patching project.
Dual scan, aimed at exactly this estate
Now the trap. Since build 1607 and its server equivalents, a machine carrying both the intranet update service location policy and any Windows Update for Business deferral policy does something nobody asked for: it scans Windows Update directly for Windows content and ignores what WSUS has to say about it. The old WSUS engineering blog put it without softening, saying that anything on WSUS residing in the Windows product family is ignored by the dual scan client. The machine still reports to WSUS and still appears in the console. It is simply taking its Windows updates elsewhere.
This is not history. Windows Server 2016 at build 14393 and Windows Server 2019 at build 17763 still carry the behaviour in 2026, and 2019 never received the newer replacement, so its only defences are the legacy kill switch or never creating the condition. Windows Server 2022 and 2025 replaced dual scan with a settings family that specifies the source service for specific classes of Windows updates, which is a genuine improvement because it makes the source an explicit per class decision rather than an emergent consequence of two unrelated policies overlapping. The old kill switch, behind the policy named do not allow update deferral policies to cause scans against Windows Update, is now filed under legacy configurations, has no effect on the Windows 11 lineage, and on the Windows 10 lineage blocks Windows Update entirely if configured alongside the newer scan source settings. So the remedy carries a trap of its own.
Count the vulnerable machines here and the reason this article exists becomes obvious. Both domain controllers, the legacy application server, the SQL server and the WSUS box itself run Windows Server 2016 or 2019. Five machines, and the list includes every server whose failure would ruin an afternoon. The way it fires is not exotic. Somebody builds the successor GPO, decides that while they are in there they may as well configure the modern update settings properly, adds deferral values because every article about Windows Update for Business tells them to, and links it broadly. The rings not yet cut over now carry both the pin and a deferral policy, and five machines quietly start scanning Microsoft for Windows content, installing updates nobody approved, outside every window anybody owns, while the console goes on showing them as managed.
The settings that look most like modernising the update policy are exactly the ones that take five of these servers off WSUS before anybody decides to.
So the rule for this estate, and I would apply it to any server estate under Update Manager without hesitating: never configure Windows Update for Business deferral policies on these machines. Not in the successor GPO, not in the security baseline, not temporarily, not as a test. Update Manager does not need them. Deferral answers the question of when a machine installs what it is offered, and that question now has an owner, a resource, an RBAC boundary and a schedule, all in Azure. Configuring deferral on top is not defence in depth. It is a second answer to a question that already has one, and on the older half of this estate the two answers combine into a third thing neither intended.
What the cut actually costs
Two things get worse when a ring leaves WSUS, and both deserve deciding in advance rather than discovering afterwards. The first is third party patching, and it ends on the day of the cut for the machines in that ring. Update Manager does not patch third party software on Windows, and Microsoft’s answer to the requirement is to import and publish those applications into WSUS so that Update Manager installs what WSUS offers. That answer works only while a machine is still pointed at WSUS. Cutting the source does not relocate the capability somewhere more modern. It deletes it, per ring, permanently, in the same operation that improves everything else. If your estate publishes third party content today, the decision has to be made before the first ring moves, and there are three honest answers: keep a standalone WSUS as a publishing point, buy a dedicated third party patching product, or keep Configuration Manager if it is already there. The first changes what retirement means, because you are then demoting the box to one job rather than removing it.
The second is bandwidth, and here I want to argue against the usual anxiety rather than feed it. Update Manager cannot pre download, so every machine pulls its cumulative update inside the maintenance window instead of staging it overnight. That is real. The mitigation everyone reaches for is Delivery Optimization, and on servers it is weaker than its reputation. It requires Windows Server 2019 or later, so the four Windows Server 2016 machines here get none of it under any configuration, and where it is supported the default download mode is the peerless one rather than the client default that shares across the local network. Peering is something you deliberately enable, by setting the mode to local network or to group with a group identifier, and it needs TCP 7680 open between peers.
For an estate this size, the honest answer is that it does not matter. Ten servers, two of them in Azure pulling over Microsoft’s own network anyway, taking a cumulative update apiece once a month, is a few gigabytes across a link that carries a full working day of business traffic without anyone noticing. The rings are themselves the mitigation, because a ringed estate never has every machine downloading at once. I would not build a Delivery Optimization design for this. I would cut the source, watch the first month, and revisit only if the evidence says otherwise. Where bandwidth genuinely rules, keeping WSUS as the content source under Update Manager scheduling remains a legitimate architecture rather than a failure to migrate.
Where this goes next
All of that is why the cutover is a Group Policy operation with an Azure audience, and why the gate in front of it is evidence rather than a date. A ring moves when it has completed a full patch cycle under its maintenance configuration with the results legible in Update Manager’s installation records, and not before.
The build sheet that follows takes one ring through the whole operation: the successor policy built first, the filter group shrunk, the refresh forced, the service restarted because it reads policy at scan time, the pin verified gone at the registry rather than assumed gone, the Microsoft Update opt in applied where needed, then a full cycle against the new source. The domain joined Azure machine walks it end to end, because a server inheriting the pin across a site to site link is the most interesting case in the estate. After that, the box itself. Microsoft publishes no guidance at all for taking a WSUS server out of service, which is worth knowing before you go looking for some, and the second sheet is the practitioner method that fills the hole.
Azure Update Manager
‹ Previous: [AUM 4.1] Build Sheet: Hotpatch on APP02 and AZSRV01
Next: [AUM 5.1] Build Sheet: The Ring-by-Ring Source Cutover ›
