Active Directory mistake: Moving domain controller objects into a child OU of the domain controller is unsupported
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.
ITworld.com
Symantec Backup Exec 12 and Backup Exec System Recovery 8 deliver industry leading Windows data protection and system recovery. Download this whitepaper to find out the top reasons to upgrade and how to get continuous data protection and complete system recovery.
Data and system loss — from a hard drive failure, malicious attack, natural disaster, or simple human error — can happen anytime. Don’t leave your business vulnerable. Make sure you have a secure recovery strategy in place. Symantec's latest backup and system recovery technology can efficiently restore critical applications, individual emails and documents and even restore your entire system in minutes in the event of a loss.
Businesses face a growing challenge to ensure that the IT environment is properly protected. Backup Exec 12 integrates with other applications in the Symantec family of products, to complement your current data protection strategy, keep your data securely backed up and make it recoverable when you need it most.
Enterprise 2.0 Implementation
By Aaron C. Newman, Jeremy Thomas
Published by McGraw-Hill
Learn more!
Deploying Cisco Wide Area Application Services
By Zach Seils, Joel Christner
Published by Cisco Press
Learn more!
Hello there. First of all
Hello there.First of all thanks for your article, it is very good and clear. I, however, have a good reason for putting the domain controllers inside child OUs, and I have done so and incurred into problems, so I had to move them back to the default Domain Controllers OU.
My reason is that I have 5 domain controllers in 3 different and distant sites, and each site has its own WSUS server, so I would like to have the domain controllers getting their updates from their local WSUS server, but to do that I need to apply different group policies to the servers in different locations, therefore they need to be in different OUs.
So, I couldn't find any solution to that because I can't move my domain controllers, and I believe Microsoft should have thought of that... Anyway, would you have any ideas to solve my problem without moving the domain controllers to different OUs?
Thank you again!
Hey Felipe, your solution:
Hey Felipe,your solution: make 3 different GPOs that have 3 different WSUS paths. konfigure the CAL of every GPO in that way, that only the right DCs have the permission to read und apply their corresponding policy. then link EACH of the GPO with the OU domain controllers. thats all...
GPOs using WMI Filters
this is a common issue to solve in large global deployments of domains and the biggest issue people face is not updating the GPO's if they explicitly assign the DC computer object against on the security filter and they then decommission the DC and add a new one.the easiest way around this does of course depend on your global naming standard.
Using WMI filters in GPMC you can create a WMI filter that will only ensure that the GPO you assign will only apply to computers that start with a specific WMI filter.
ie root\CIMv2 Select * from Win32_ComputerSystem WHRE Name like 'SITE-A%'
assign this to the GPO on the domain controllers OU that specifies SITE A's wsus server. hence you keep them all in one OU.