Active Directory delegation best practices

The term "best-practices" when referring to the structure of your Active Directory is very open ended. There are a variety of factors that will determine what will make the most sense for you in your environment, and Microsoft identifies that what works for one enterprise will not necessarily work for another one.

That said, Microsoft recommends that you organize your AD structure in a logical manner, grouping objects together that have similar properties and that should share similar administrative properties.

These items that you may want to group together can include (but is certainly not limited to) the following

• Physical Location of the Object
• Desired effect of Group Policy of those objects (all objects are subject to same group policy unless otherwise stated)
• Operating System of the computers
• Object Type (computers, users, groups, general e-mail addresses, etc)
• Department the object belongs to
• Permission structures
• Scripts that should run on the objects during logon/logoff or startup/shutdown
• etc

It will be up to you to decide what structure works best for you. The 70-640 exam is exclusively for Active Directory administration and may prove to be a valuable asset to you in the structuring of your organization

EDIT : To reflect what Zoredache has pointed out, but flexibility is an important part of the AD structure. Companies are dynamic and you should plan your AD to be flexible. The key is the find a nice balance between functionality and flexibility.

I've dealt with similar problems in the past.

That being said your organization doesn't look too far from ordinary. A lot of small business are built just like you outline.

If you really want to restructure the best solution I have found is setting up an OU with block group policy inheritance at the root of your domain. Build your new structure under this OU and apply your group policies there as well. You can then move your computer and user objects in a controlled fashion.

As far as design - use whatever works. Don't try to emulate the physical arrangement of the business too closely. Group your systems to make them easy to administer.

Edits for clarification:

'Block Inheritance' is an option that allows you to set up an OU that won't accept any policies which are defined above it. This allows for a totally blank slate. Any objects which are later moved here will have none of the existing policies applied, even if they otherwise would be. Any objects left in their original homes will still have their current policies applied.

Although a bit dated the logical modeling here provides some excellent guidance on overall AD structure.

One additional point, which is extremely important - document everything you are doing. Include why it is done this way as well as how it is configured. The exact method you chose for this doesn't matter, but I personally really prefer one of the various Wikis out there. Building detailed history for your environment is a godsend.

Additional edit in response to Joe Qwerty

I don't necessary advocate a restructure. Doing so can be time intensive and serious pain in the ***. I am just advising how to do so if that is the route the OP chooses. Personally that'd be a last resort. I've contracted places that everyone was a domain admin and the accounts / group policies were total mess and a restructure is the most viable option.

Given the choice I would opt to work within the existing AD structure. If the naming conventions, etc bother you they can always be changed. The OUs, group names, etc all have GUIDs that won't be broken by a rename. The SBS entries were likely not copied from the old SBS server. SBS includes Active Directory. A common migration path as organizations expand is is adding a 2008 R2 / 2012 server, promoting it to domain controller, moving the FSMO roles and then demoting the original SBS server. If the old admin had spent a lot of time in the original SBS AD console I could see why you wouldn't want to change the naming convention.