You probably have heard that, since Windows Server 2008, Active Directory Users and Computers has additional logic built-in that allows you to browse to the “Domain Controllers”-OU, select a DC and hit either the DEL button on your keyboard or choose “Delete” from the right-click context menu. It would then, prior to deletion, do some checks and “cleanly” delete the Domain Controller off the forest.
It doesn’t simply wipe the machine account of the DC but cleans up metadata as FRS references, moves FSMO roles, does Global Catalog coverage checking and then – finally, if everything is good, removes the machine account. The things done here are the same that ntdsutil does for you in the “metadata cleanup” menu as described here:Â http://technet.microsoft.com/en-us/library/cc736378(WS.10).aspx andÂ http://support.microsoft.com/kb/216498/en-us.
Still, you really only want to delete/clean up the DC in a couple of situations:
- the DC has failed and won’t come back to life
- you intend to flatten the machine and re-install the operating system
Of course, you can’t bring back the machine to work again once the deletion is complete.
I mentioned ADUC would check a couple of things before wiping the machine account. One of the things is FSMO coverage. If the DC-to-be-deleted ownsÂ one or moreÂ of theÂ FSMO roles, ADUC is eager to move them off the machine and assign them to another DC.
To my asthonishment, a well-known user in the Newsgroups came to ask the question what the algorithm looks like when the FSMO roles are moved. It appeared that, once he deleted a DC in the root domain, the forest-wide FSMO roles were moved to a DC in the child domain. That surprised me a little. I knew it was possible to move the forest-wide FSMO roles (let’s name them for once: the Schema Master and the Domain Naming Master) to some child domain in the forest — they don’t have to be owned by a forest-root-DC. I asked around and my knowledgable friends haven’t come across this situation yet, too.
So I did some digging and this is what I came up with:
- When looking for a new forest-wide-FSMO-owner candidate, ADUC looks for any domain controller in the forest. It does not look for a DC in the same domain.
- It seems that (I wasn’t able to prove this theory), that it tries to move the FSMO roles to the DC added most recently to the forest. That may be due to the fact that the newest DC appears at last on the results list from ADUC’s query. It seems to always pick the last
- For a domain-wide-FSMO-owner candidate, it obviously has to look for a DC in the same domain.
- If it moves both forest-wide FSMO roles, it prefers to move them together.
- If it is tasked to move PDC and RID emulator role, it tries to move them together.
- It tries to move the Infrastructure Master to a DC that isn’t GC – if possible.
If you encounter a “strange” move like this, let me know if you care. I’d like to dig a littler further on this.
As a side note, I don’t think that this algorithm (if it behaves like that) isn’t necessarily a bad thing. It shouldn’t pose a serious security thread on an infrastructure (at least it shouldn’t!) but need some special care for some kinds of environments.