May 19, 2008, 1:52 PM — In two previous articles (here and here) I shared some classic Active Directory mistakes people have made that got their companies into serious trouble. Here's another mistake that on the face of it sounds harmless but that can have unintended consequences if you implement it.
A company I know had half a dozen domain controllers in their domain, and by default Windows Server 2003 stores the computer account for all domain controllers in the Domain Controllers organizational unit (OU)(for example OU=Domain Controllers,DC=contoso,DC=com) to which the Group Policy Object named Default Domain Controllers Policy is linked. What the customer wanted to do was to create a child OU beneath the Domain Controllers OU and then move the computer accounts of several domain controllers into this sub-OU. Why did they want to do this? The usual vague answer: "for business reasons".
On the face of it, this doesn't sound like it would cause any problems since any policy changes made to the Default Domain Controllers Policy GPO would not only be directly applied to the objects contained in the Domain Controllers OU but would also automatically be inherited by any objects contained in the child OU. So what harm could be done by doing this? Would it break anything?
Maybe not, but after talking with some people inside Microsoft concerning this, the word I hear is that doing this (moving domain controller objects into a child OU of the Domain Controllers OU) is unsupported. Why wouldn't it be supported? Probably because Microsoft has never tested that scenario so they don't know what the consequences of doing it might be. How does that impact the customer? If the customer does something to their network that Microsoft says is unsupported, then Microsoft isn't obligated to help the customer should they decide to go ahead and do it and something goes wrong. In fact, Microsoft might simply respond by saying, "Sorry, that change is unsupported -- you'll have to flatten your network and rebuild it from scratch." I'm not saying they will respond that way, just that they might -- and that it would be perfectly fair and reasonable for them to do so.
Think about it for a moment. Support boundaries must be defined somewhere, otherwise all hell would break loose. The test matrix for enterprise networks is huge-dozens of products each with hundreds or even thousands of configuration settings. And Microsoft explicitly says "As a best practice, keep all domain controller computer accounts in the default Domain Controllers OU to ensure that domain-controller-specific Group Policy settings are consistently applied to all domain controllers in the domain" and they also say here: "Ensure that all domain controller computer accounts reside in the Domain Controllers OU." So if Microsoft says you should do it, and they say it's a best practice, then why use "business reasons" as a justification for trying to circumvent their recommendations and do something different? After all, do you really want to use your company's network as a guinea pig?
Related reading:
Migrate your active directory, don't split it
If your company wants to spin off one of its departments into a separate business, and needs to divvy up its single-domain Active Directory (AD) assets, migrate, don't split. Learning how to perform an AD migration takes time and is somewhat complicated, but it's clearly documented in many places and more importantly, it's supported by Microsoft.
Active Directory and disaster recovery
Using a "lag site", an additional domain controller on a separate subnet, and then scheduling inter-site replication to occur only once a week with the rest of your forest is not a Microsoft-supported disaster recovery scenario.
