Everything led here. The identities are cloud-native, the devices rebuilt, the services moved, the last application decided, the plumbing relocated, the logs quiet. All that remains is to turn two machines off and mean it. This is the capstone, and it is the one stage where haste is dangerous, because a domain does not fail loudly when you power it off. It fails quietly, hours or days later, on the schedule of the thing that depended on it. So the decommission is an observation window, a deliberate order, a clear-eyed list of what fails silently, and a go decision someone is willing to sign. The build sheet that follows runs the commands. This article decides whether to run them.
The scream test
The single most valuable thing you can do before demoting a domain controller is turn it off without demoting it, and wait. This is the scream test, and it is field practice rather than anything Microsoft documents, which does not make it optional. Power down one controller for a week or two while the other stays up, so the domain still functions but its capacity is halved and any hard dependency on that specific machine surfaces. Then, if nothing screamed, take both dark for a further few weeks, deliberately spanning a month-end and a patch cycle, because the dependencies that hide from a quiet week are exactly the monthly and the scheduled ones. The controllers are off, not gone; anything that breaks is one power button from recovery. That reversibility is the entire value of the test. You are buying the right to be wrong cheaply, one last time, before you make the change that cannot be undone. Two cautions shape the window: never let it run long enough to approach the directory’s tombstone lifetime, which is a months-long clock you do not want to test, and if the controllers are virtual, shut them down from inside the guest operating system rather than deallocating them from the platform, because the latter can reset the VM-GenerationID and corrupt the very thing you are trying to retire cleanly.
A Kerberos ticket outlives the KDC that issued it by about ten hours. The outage does not arrive at power-off, it arrives at tomorrow morning’s first login.
What fails silently, and when
The delayed failures are the ones worth memorizing. A Kerberos ticket, once issued, is good for about ten hours, so a user who authenticated this morning keeps working all afternoon after the controllers are gone, and the outage surfaces tomorrow at first login rather than at the moment of power-off. Cached credentials go further, letting a laptop that has not seen a controller in weeks still log its user in locally, which masks a dead domain until a password event or a policy refresh finally needs the real thing. Services and scheduled tasks running as domain accounts keep running on their existing tokens until something restarts them, and then they fail in whatever costume the application wears, rarely with an error that says domain. Printers and appliances that looked up names in the directory simply return empty results, quietly, with no alarm. A standalone storage box keeps honoring existing access while name resolution for new principals dies. Certificate checks against directory-hosted revocation lists behave differently on different clients, some shrugging and some refusing. None of these is dramatic and all of them are delayed, which is precisely why the scream test spans weeks and a month-end rather than a long weekend. The failures you are hunting are the ones that wait.
The order, and the point of no return
The demotion itself has a shape the build sheet walks in detail. In brief: the second controller goes first, demoted as an ordinary member of the domain, and you verify the domain survives it because it should, nothing depending on that specific box. Then the last controller goes, and its demotion is different, because removing the final controller removes the domain, and with it the forest if this was the last domain. That last demotion is the point of no return for everything the directory ever did. Before it, powering a controller back on recovers the domain. After it, there is no domain to recover, only the objects that already moved to the cloud and the isolated remnants you decided to keep. The build sheet names the exact moment; this article names why it matters, which is that the reversibility you have leaned on through every prior stage ends at that command and does not come back.
The insurance nobody wants to think about
Keep one thing after it is over: a powered-off image of the last controller, exported before the final demotion, held as insurance. It is the artifact you would rebuild from if something you missed surfaces weeks later, and it is worth being clear-eyed about what it actually is, because it is dangerous. That image contains every secret the domain ever held: every password hash, the krbtgt key that signs every ticket, the DPAPI backup key. It is the most sensitive object the migration produces. So it is encrypted, it is stored offline, and it never, under any circumstances, touches the production network again once cleanup has begun, because a domain controller reintroduced to a live network is a domain trying to come back from the dead. Treat its eventual, deliberate deletion, months later, as the true final act of the migration. The domain is not gone when the controllers power off. It is gone when that image is destroyed.
The go, or the no-go
A decommission is a decision someone signs, and the signature should mean something. Go requires all of it, together: the authentication logs quiet across the full observation window including a month-end; the network plumbing moved and proven from real devices; the tenant standing on its own with sync long since cut; every device’s recovery material confirmed in the cloud; the scream test completed with nothing attributable breaking; and a written rollback statement that says, in plain words, what powering the last controller back on does and does not fix, and names the exact point after which it fixes nothing. No-go on any unexplained authentication event, any application owner who cannot confirm their thing works without the domain, any untested backup, or any device whose recovery keys are not yet confirmed safe in the cloud. The discipline is that no-go on any single item means no-go overall, because the failures this stage guards against are exactly the ones that look like acceptable exceptions right until they are the outage. A consultant signs go when there is nothing left that would make them hesitate, not when the hesitation has merely become familiar.
The gate, which is the finish line
Stage 6 is complete when both controllers are demoted, the domain is gone, the tenant runs cloud-native with nothing on-premises authenticating anyone, the insurance image is encrypted and offline with a deletion date on the calendar, and the company has gone through a full business cycle, a month-end and a patch Tuesday, without the domain and without incident. CatSnackJack ran its scream test for five weeks across a month-end and a patch cycle and surfaced exactly one straggler, a reporting job whose owner had sworn it was cloud-native and was wrong by one connection string, caught while the controllers were merely off and fixed before the demotion. The final controller came down on a Saturday, the insurance image went to encrypted cold storage with a ninety-day destruction date, and the following month closed the books with no directory in the building for the first time in the company’s history. The build sheet, decommissioning the domain, has the commands.
AD to Azure
‹ Previous: [AD 7] What Your Domain Controllers Are Still Doing
Next: [AD 8.1] Build Sheet: Decommissioning the Domain ›
