By the end of this you have run the pre-flight checks and confirmed their silence, demoted the second controller and verified the domain survived, taken the insurance image, demoted the last controller past the point of no return, cleaned up the tenant side in the right order, and swept the stale device records without throwing away anyone’s recovery keys. This is the one build sheet in the series with no undo after a certain command, and that command is flagged where it happens. Do not run any of this until the doctrine article’s go criteria are all met; the commands are easy and the judgment is the hard part, which is why it lives next door.
Before Step 1: the scream test complete, Enterprise Admin and Domain Admin credentials, console or reliable remote access to both controllers, and a confirmed backup destination for the insurance image. Keep the go or no-go checklist from the doctrine article open; every no-go item is a stop.
Step 1: Pre-flight, and the silence you expect
Confirm each source is quiet before you touch anything. These are reads; none of them changes the estate. The point is that every one comes back empty or expected.
| Check | How | Expected |
|---|---|---|
| No real logons on the DCs | Security log, event 4624, both DCs | Only DC computer accounts and your own admin session |
| NTLM silent | NTLM Operational log, event 8004 | Empty across the window |
| Legacy binds silent | Directory Service log, event 2889 | Empty; nightly appliance binds gone |
| Sync already off | (Get-MgOrganization).OnPremisesSyncEnabled | False |
| SSO artifact gone | AD for the AZUREADSSOACC account | Absent (removed in Stage 1) |
| Plumbing moved | DHCP option 6, client DNS | Points at the new resolver, not the DCs |
Step 2: Transfer roles off the second controller, if needed
The directory’s special roles only matter between the two controllers; on the last one they die with the domain. Make sure the controller you are keeping until the end holds them, so demoting the second is clean.
netdom query fsmo
# if any role sits on DC02 (the one going first), move it to DC01:
Move-ADDirectoryServerOperationMasterRole -Identity "DC01" `
-OperationMasterRole SchemaMaster,DomainNamingMaster,PDCEmulator,RIDMaster,InfrastructureMasterStep 3: Demote the second controller
This is still reversible in the sense that matters: the domain continues, because the last controller stands. Demote the second as an ordinary member.
# on DC02, which now holds no operations master roles
Uninstall-ADDSDomainController -ForceAfter it reboots, remove the role so the box is a plain server, then leave it powered off but intact for a few days as a fast fallback.
Uninstall-WindowsFeature AD-Domain-ServicesStep 4: Verify the domain survived one controller
Before you touch the last controller, confirm the domain is healthy on it alone. A real user signs in, reaches what they need, and the directory reports no errors.
dcdiag /s:DC01 /v
# and a human check: a real user signs in and reaches mail, files, and the LOB appStep 5: Take the insurance image
Before the final demotion, export a full image of the last controller. This is the artifact you rebuild from if something surfaces later, and it is the most sensitive object the migration produces, because it holds every secret the domain ever had. If the controller is virtual, shut it down from inside the guest first, never from the platform, then export. Encrypt the image and move it to offline storage. It must not touch the production network again.
| Setting | Value | Why |
|---|---|---|
| Shutdown method | From inside the guest OS | Deallocating a VM from the platform can reset the VM-GenerationID and corrupt the directory state |
| Image scope | Full system, not just system state | System-state restore to new hardware is unsupported; the whole VM is the useful artifact |
| Encryption | Required | The image contains every password hash, the krbtgt key and the DPAPI backup key |
| Location | Offline, off the production network | A DC reintroduced to a live network is a domain coming back from the dead |
| Deletion | Destruction calendared, 90 days or per policy | Destroying the image is the true end of the domain |
Step 6: Demote the last controller. No undo past this command.
This removes the domain, and the forest with it if this is the last domain. Everything before this recovered by powering a controller back on. Nothing after it does. The flags matter: you are declaring this the last controller and removing the directory partitions, and clearing the DNS role it held.
# on DC01, the final controller. Enterprise Admin.
Uninstall-ADDSDomainController -LastDomainControllerInDomain `
-RemoveApplicationPartitions `
-IgnoreLastDNSServerForZone `
-RemoveDNSDelegation -ForceAfter the reboot, remove the role and, if this box is not being wiped, its DNS and DHCP features too, since they were moved off in Stage 5.
Uninstall-WindowsFeature AD-Domain-Services, DNS, DHCPStep 7: Metadata cleanup, only if a demotion was forced
A graceful demotion cleans up after itself. If either controller had to be removed by force because it would not demote cleanly, its leftover records linger and must be removed by hand. Skip this step entirely if both demotions succeeded normally.
# only for a forced removal; modern AD Users and Computers does metadata cleanup on delete
ntdsutil "metadata cleanup" "remove selected server DC02" quit quitStep 8: Tenant-side cleanup, in order
Most of the tenant cleanup happened in Stage 1 when sync was cut. Two items remain and one carries a warning that can cost a machine its recovery keys.
First, retire the sync health reporting entry, which keeps alerting that its data is stale until you remove it. Then, and carefully, the stale device records: the rebuild in Stage 2 left a stale hybrid object behind for every laptop it replaced, roughly one hundred and forty of them, and they should go. But deleting a device object destroys that device’s escrowed local administrator password and its BitLocker recovery key, permanently. Confirm that material is retrieved or no longer needed for a given device before deleting its object, never after.
# find the stale hybrid device records left by the migration
Get-MgDevice -All -Filter "trustType eq 'ServerAd'" |
Select-Object DisplayName, Id, ApproximateLastSignInDateTime
# for each: confirm LAPS and BitLocker material is safe in the cloud, THEN deleteStep 9: The end-to-end test
The test for the whole series is a full business cycle with no domain. In the immediate term, prove the estate stands the day after: a real user on a rebuilt device signs in, reaches mail and files, prints, connects to the Wi-Fi, and opens the line-of-business application, none of which now has a domain behind it. Confirm no directory-dependent errors are accruing anywhere you can see. Then let a month-end and a patch cycle pass, because the failures this stage guards against are the delayed ones, and only a full cycle without incident closes the migration.
| Check | Expected |
|---|---|
| User sign-in, rebuilt device | Works, no domain in the path |
| Mail, files, print, Wi-Fi | All reachable |
| The last application | Works on its decided rung |
| Directory errors | None accruing |
| One month-end and one patch cycle | Passed without a domain-shaped incident |
The last gate
The series closes when both controllers are demoted, the domain is gone, the insurance image is encrypted and offline with a deletion date, and a full business cycle has passed without the directory. There is nothing after this to migrate. CatSnackJack ran its final demotion on a Saturday, spent the following week clearing the hundred and forty stale hybrid records in batches, each batch checked against the recovery keys first, and closed the next month clean. One item remains in the project plan: the ninety-day calendar entry that destroys the insurance image. When it fires, close the project.
AD to Azure
‹ Previous: [AD 8] The Decommission
