OU Design Best Practices

[kev147]

Can anyone advise on the best practices of OU design?

I am in the process of designing a Group Policy solution for my company. The problem is that the company already started migrating to the AD over 6 months ago and the OU Structure has never taken into account "how we can apply GPO's".

At the moment we have 150 OU's that are between 2-6 levels deep. There is no standard naming convention to it either, for example the second level is sometimes department, sometimes location and sometimes something that someone has made up!

I have proposed a new OU structure to the server team which consisits of 30 OU's at 2 levels deep. Top level is directorate then the 2nd level contains, users, desktops, mobile users and laptops.

The reasons I have proposed this structure is because, we do not know our definitive list of sites and we suspect it to be in excess of 300 (which I think would create too many OU's anyway). The other reason is that we do not have an upto date organisation chart, so we do not have a definitive list of departments either ( we also suspect there to be in excees of 500 departments) again I think this will create too many OU's.

I had read somewhere that it is recommended to keep your OU structure to 2-3 levels and that anything more than 250 OU's within a domain is considered excessive.

Can anyone clarify this and if possible post me any web links as I need to provide documentation to back up a presentation I have to give the server team.

[AdamV]

It sounds like you are approaching this quite well. You might also consider delegation of authority - do you need to give different people rights over different parts of AD, eg to reset user passwords only in certain locations?

It might be worth breaking down by a kind of geography first - not for every site, but maybe by country or state, or possibly "Head Office" / "Branches" or somesuch. Even if you don't need this immediately, it might give you more flexibility later when someone requests a new setting for one place or another.

As for depth, 2 to 3 may be too few for some environments, but added depth creates more complexity, so you are right to try to reduce this but don't necessarily see this as a hard limit.

One thing you don't mention is where you intend to put servers and especially DCs. It depends to what extent you have any such kit on remote sites, of course, but worth considering for the plan. Personally I would often go for OUs under the DC OU and a top-level server OU (with locations or departments under that as required). I find it easier to work with GP this way rather than putting the servers under the sites / departments etc..

[kev147]

I thought I might be you Avero that replied. I have got to say that you definately know your stuff and have been a great help to me so far.

There was a couple of things that I should of mentioned before, but forgot to. Here they are:

1. The company I work for is a local authority council.
2. We do not want to delegate administration, either now or in the forseeable future. We administer the domain centrally by support personnel only.
3. All of our users and PC's are based in the same area. As we are a council, we do not have a head office as such, just a few main sites and hundreds of satellite sites. (I was going to suggest for flexibility in the future that Global Groups are in place for Department Users/Computers and Site Users/Computers) Then use security filtering if we need to apply/dissallow any setting.

Where the servers are put isn't really in the scope of my project. However I am going to recommend that they put the domain controllers in a seperate OU at root level. It is not planned to have any GPO's applied to any of the servers. The scope of my project is domain users and domain computers with exception to ICT support staff.

[MrMMills]

I'm a one man IT shop for a small company. that being the case I don't get to run my idea by other professionals to often. That being the case, I would like to ask if anyone would comment on how I set up my OU's and if it is either the proper way or the industry standard way of doing it. If not what are your recommended changes?

The following description shows you the structure of Group Policy and domain OU’s. My naming scheme for polices is that any Group Policy that is “Computer Configuration Specific” the Policy name starts with “Computer”, and any Group Policy that is “User Configuration Specific” starts with “User”. My Computer related GP's are in one OU, and my User related GP's in another. I then break the OU's to dept level, etc

Group Policy Manangement
-------Forest: mydomain.com
------------Domains
------------------MyDomain.com
--------------------Default Domain Group Policy Object Link
----------------------Active Group Policies OU
-----------------------------Computer Policies OU
------------------------------------AccountingDept Computer OU
--------------------------------------- Computer - Remote Assistance Settings ( Group Policy Object Link 1)
--------------------------------------- Computer - Windows Security Sttings (Group Policy Object Link 2) (you get the idea..)
------------------------------------MarketingDept Computer OU
------------------------------------Programmer Computer OU (…OK you get the idea)
-----------------------------User Policies OU
---------------------------------User - My Documents Redirection (Group Policy Object Link)
------------------------------------Accounting Dept Users OU
--------------------------------------- User - IE Changes (Group Policy Object Link 1)
--------------------------------------- User - map drives (Group Policy Object Link 2) (you get the idea..)
------------------------------------MarketingDept User OU
------------------------------------Programmer Dept Users OU (…OK you get the idea)

My other question - any problems in putting all the Accounting Computers objects in a "Global Group" and nest the Global group into a "Local Group". Then instead of putting every Computer object (all teh accounting PC's) into the OU structure you would just place the Global Group Container there instead? Or would this not work? not common practice? not recommended?

The benefits would be that when you created a new pc object you would just have to add it to the correct Global Group instead of having to add it to an OU. I'm I thinking correctly here? Bare with me I haven't had too mcuh time to catch up on all this yet.....

[AdamV]

Not enough time to review your overall structure right now, I'll try to take a look in the next couple of days. At first look it seems pretty good - at least you have a structure!

In answer to your question about groups - no, that won't work. GPs are not inherited through groups, only applied to 'real' objects (users and computers) which are in the relevant places (OUs, sites, domains). A user or computer in OU "A" which is in a group stored in OU "B" will not get any policies linked to B, only those to A or above A in the hierarchy.

One point about your policies - you mention that you split policies for users and computers, which is often a good idea and easy to manage. If you do this it is a good idea to disable the unused half of the policy so it is completely ignored, and if someone else changes settings in that half it will not have unexpected results (rather their change in that half will have no effect)

[MrMMills]

You mention a good point which I have read about. I actually planned to do that after I felt I had finished all the policies I wanted to put in place. I wish MS had a way to to import "sub policies" into one larger "working Policy". I think Jeremy stated in a post that a tool like that would be a hot 3rd party tool to develop and use. I don't want to put to many features is a policy for fear I would have to alter a whole policy if the tinyest of changes had to be made. Creating several small, specific GP's seems logicial so far for ease of use and gp diversity.

[JerryC]

Group Policy Manangement
-------Forest: mydomain.com
------------Domains
------------------MyDomain.com
--------------------Default Domain Group Policy Object Link
----------------------Active Group Policies OU
-----------------------------Computer Policies OU
------------------------------------AccountingDept Computer OU
--------------------------------------- Computer - Remote Assistance Settings ( Group Policy Object Link 1)
--------------------------------------- Computer - Windows Security Sttings (Group Policy Object Link 2) (you get the idea..)
------------------------------------MarketingDept Computer OU
------------------------------------Programmer Computer OU (…OK you get the idea)
-----------------------------User Policies OU
---------------------------------User - My Documents Redirection (Group Policy Object Link)
------------------------------------Accounting Dept Users OU
--------------------------------------- User - IE Changes (Group Policy Object Link 1)
--------------------------------------- User - map drives (Group Policy Object Link 2) (you get the idea..)
------------------------------------MarketingDept User OU
------------------------------------Programmer Dept Users OU (…OK you get the idea)

Here's something to think about. I find that separating Server machine accounts from Client PC machine accounts results in a vast improvement for deploying scripts/updates.

While we have Enterprise deployment mechanisms, we also have devices that choose "not" to belong on the list (mostly the server folks). At the same time we get requests (okay, demands) from management to know "when were security updates applied and keep us updated on status every 30 minutes, okay?"

Many times, we just want to place a GPO with the requisite settings at the top of an OU tree, knowing they'll filter down...however, until we get rid of all legacy client and server machine accounts (getting all of them up from Windows 2000 and into WinXP and Win2K3), we can't use WMI filters to separate the GPOs to apply to their appropriate targets. So separation by an entire tree structure for the servers really helps. (We've upwards of 3,000 servers, 150,000+ PCs with similar numbers of users. Things take awhile to get upgraded.)

As a one man shop, you probably do not have these kinds of problems, just be careful not to target Server security patches via GPO to client workstations and vice-versa.

We also provide our OU trees (equivalent to your Marketing, Accounting, etc.) with a standard OU structure and a set of security groups (in a security group OU) for each specific OU tree. Then we pre-create a set of security groups for each necessary function within each OU tree and pre-assign the security for each group (server Admins, Workstation Admins, GPO Admins, etc. That way, the domain admin can delegate OU level authority for an entire OU tree by simply populating a single group with an Admin for that tree. Then that assigned individual is responsible for taking care of the rest of the security groups to delegate authority further.

There are as many "good" designs as their are domains. So do what is best for each customer, but at least try to do it in a standard manner.

[MrMMills]

Thanks Jerry for your input. I only run about 15 servers and so far have not put them in their own OU's - they are still in the default "Computers" OU. They are a mix of Win2k sp4 and Win2k servers and currently I don't have any special GP policy settings I need to enforce on them.

Don't get me wrong, even though I have a much smaller environment I want to get in the practive of doing things properly, as they would be done in a larger corporation.

You mentioned using GP for patch deployment. It is my understanding that GP only looks at the registry setting under Add\Remove Programs to see if a patch is installed. It does not verify the patch is working though. The problem I found is that patches may be listed as installed, but they become invalidated by other patches at times or other programs installed. For this reason I use Shavlik's HFNetChkPro for patch deployment (by OU even). It looks to see if patches are installed by checking the checksum of the patch files, the .dll version of the patch files installed, as well as the size and date of the patch files to verify they are legitimate. You can set Shavlik's HFNetChkPro to scan OU's during the off hours and push down patches at 2am and reboot the pc's either before and after the patch push, or neither.

You also go into allowing other people to have priviledges (responsibility ) of managing their own OU's. I have started using the "Delegation of Authority" to do that as well (using Global Security Groups that are nested in Local Security groups). I think for ease of use though I'm going to create executable scripts on a domain intranet page to walk these managers through things like 1) changing and disabling a users passwords, 2) adding additional printers outside their original group policy, 3) adding specific additional mapped drives outside their normail GP, etc. They would just fill in the blanks of the users or computers they wanted to work with and the settings they wanted to change. If I can create a web page to walk them through these things, then I won't have to install the adminpak.msi on their pc's and I won't have to train them how to do these tasks. Your thoughts?

By the way I haven't started researching the capabilities of the MS Office ADM template. Can you set up a group policy so that when they log into their machine for the first time, their Outlook settings 1) choose to connect via Exchange 2) point to a specific Exchange server, 3) disable Outlook Cached mode, 4) fill in the users name automatically by basing it on how they logged in? Currently after I set up a new user and mailbox I personally log into their pc and set their Outlook settings for that user (logged in as them)- I know there must be an easier way to automate Outlook settings, Any guidance? We don't have the luxury of SMS or MOM.

Thanks,
MrMMills

[AdamV]

You mentioned using GP for patch deployment.
...
reboot the pc's either before and after the patch push, or neither.

whatever your actual patching mechanism (WSUS being the preferred MS way of doing this, and Jeremy has written a very good article for Technet magazine on this topic) this is still a good reason to separate out machines by type.

As you say, you can choose whether to reboot or not when using your third-party tool (and the same applies to WSUS). I would suggest that forced reboots for clients might be acceptable, but for servers they are rarely OK unless planned and ideally attended.

Similarly you might puch updates to servers at (say) 2am, but to do that for PC's would require them to be turned on, so patching at startup might be sufficient.

On the subject of the office adms, I think that would be better addressed if you start a new thread rather than confuse this one, but the short answer is 'yes'.

[MrMMills]

Adam, thanks for all your help. Personally Shavliks program is more intuitive and works better for us than Microsofts free WSUS (wait a minute, wasn't it called WUS and then upgraded to a new name in the last few months?) But every organization is different and to each their own. I greatly appreciate your sharing your knowledge and advice. I look forward to buying Jeremy's book to see how I can further leverage AD and GP in a Win2K3 mixed mode environment. Have a great weekend!

Last note- several members have stated that they wanted to be able to share custom ADM templates. Do you know of any web sites that host the ability to download or contribute to a repositry of custom ADM's?