What can go wrong when Domain Controllers have been moved out of Domain Controller OU?

I administer a network with Server 2003 domain controllers. I am planning to replace the domain controllers with new Server 2008 DC's. When running DCDIAG, I receive an error that the domain controllers failed something along the lines of "test MachineAccount". I forget the exact error message. The message appears because a previous admin moved the domain controller computer accounts out of the "Domain Controllers" OU. I knew this beforehand, but now I wonder if this may cause new issues during the ADPREP process. Some documents I have read state issues with Exchange and other aspects of the infrastructure when the objects are moved from the Domain Controllers OU. This has not been my experience to date since everything seems OK now. I am wondering if anyone else has experience in this area. I would not want to move the Domain Controller objects again before covering my bases and planning ahead.

Thanks.

Solution 1:

From http://technet.microsoft.com/en-us/library/cc728418%28WS.10%29.aspx

Domain Controller OU

When domain controllers are added to the domain, their computer objects are automatically added to the Domain Controller OU. This OU has a default set of policies applied to it. To ensure that these policies are applied uniformly to all domain controllers, it is recommended that you do not move the computer objects of the domain controllers out of this OU. Failure to apply the default policies can cause a domain controller to fail to function properly.

I think the biggest problem occurs when DCs are placed in separate OUs that do not have the default DC policy applied, though it is a good idea to keep them in the Domain Controllers OU if they're just in a differently named container anyway.

Solution 2:

In theory you can do it, but at a minimum you will also need to link your Default Domain Controller Policy GPO to the new OU, and also update anything in your configuration partition that references DCs by distinguished name to reflect the new location. There's also the issue of 3rd party software to consider - some of it may expect DCs to be in Domain Controllers, and kick and scream mightily if they ain't. Finally, if something uses config files instead of AD to store it's configuration, those config files will need to be reviewed. Finally finally, a full check through everything that currently works, including a reboot of servers to flush any cached references, would seem to be in order as some issues may only manifest during computer or service startup.

If all of this sounds a bit "huh, what?" then you shouldn't do it. BAD previous admin!

Solution 3:

Just to add my own experience for the readers:

I moved my DC accounts to a different OU when re-organizing my active directory structure, and I also linked the same policy to the new OU. Everything seemed fine, until I restarted one of my SQL Server machines.

After restart, the machine failed to boot (stuck at "Please wait..." screen during the boot). I tested my backup SQL Server to see if it works, and saw that the administrator account could not log in. It took me two days (good thing that the system was not in production yet!) to figure out it was moving DC account to another OU causing KDS service (key distribution service) to fail to start. And when it fails, none of the AD Service Accounts would work.

Moving the DC account back fixed all the issues.

My only guess is that KDS uses the full path of the DC somehow...

Note: this was in a Windows Server 2012 environment.