I'm trying to fix a completely unplanned and unstructured Active Directory hierarchy. When the domain was first created on Windows Server 2000, no containers or OUs whatsoever were created for users or computers. All users were lumped up together under the default "Users" container and all the computers got lumped together in the default "Computers" container.

The domain eventually got upgraded and I have two Windows Server 2008 x64 DCs now. But of course the current structure or lack there of is a nightmare for assigning permissions and applying Group Policy so i need to restructure the whole thing.

My question is about what kind of interruption to business should I expect when moving users and computers to into OUs and Groups, if any?

Any advice on how to do this? any pointers to best practices?

Just in case it's needed, the rest of the environment is a Windows Server 2008 file server, a Windows Server 2003 R2 print server, Windows Server 2003 R2 Exchange 2003 Server and a Windows 2003 R2 x64 Server running SQL Server 2005 SP2.


If the services interacting with Active Directory are all (or primarily) from Microsoft you shouldn't have any interruption. Microsoft products will know how to find accounts dynamically just fine so your restructuring will be transparent to your operating environment. Other products which bind (via LDAP, for example) to a high level of your directory and do subtree searches should also be unaffected, depending on how of a level they're binding.

What you should look around for are other services that might use Active Directory (again, via LDAP or similar) and have hard-coded bindings to lower level container objects (OU's) or leaf-level objects (accounts, groups, etc) when looking for objects in the directory. Your restructuring will cause these lookups to fail.

For example, we use a non-MS database platform that, yes, does tie into AD for user authentication. However, it maintains its own internal database of users and we have to associate the absolute ADsPath with each user account when creating logins for this system. When a user account moves to a different OU, authentication for that user breaks until we update the account with the new ADsPath.

Automatically searching for these services is not trivial so if you do have them I highly recommend maintaining an inventory of applications / services that connect to AD.

| improve this answer | |

You shouldn't expect any interruption whatsoever. Moving objects to different containers doesn't cause any interruption. Since you can't apply policy directly to the default OUs, you don't even have to worry about making sure the right policy is applied on the new ones either.

Pretty much, you're good to go for it.

As far as best-practices go, I tend to make three top-level OUs in a new environment. UserAccounts, Groups, and Machines (or something analogous to computers). From there, I make child OUs for specific types of machines (like servers/workstations), administrative groups/distribution groups/resource groups, etc. That way it's easy to target all users/computers with broad policies and still link more specific policies to more specific OUs.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.