?
Solved

Group Policy and OU structures

Posted on 2005-02-26
11
Medium Priority
?
1,305 Views
Last Modified: 2008-06-30
Hi all,

I need some input and thoughts on properly designing an OU structure that is practical and scalable. I will also need some links and articles when possible to back up these ideas. I am under the impression that an OU structure should be designed to minimize the use of filtering. I think that you OU structure should be designed in a manner where you can apply your GPO's to the specific OU that you want it to affect and kind of design your domain structure that way.

But I have come across a source that introducing a new concept to me. This is applying all of your GPO's at a top level and using security groups to control who the GPO affects. I would like to know if anyone has used this method and if so how has it worked?
I also would like to know if GPMC's RSoP will be properly diagnosed against a user and computer if this concept is applied.

If my OU is broken into depts and have some settings that I only want to apply to a portion of the dept. What have been some practices that are proven to work well. Your thoughts? Thanks.
0
Comment
Question by:danhilaire
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
  • 4
  • 3
  • 2
  • +2
11 Comments
 
LVL 96

Expert Comment

by:Lee W, MVP
ID: 13411790
Because you can't put objects into more than one OU (but you can "accumulate" OUs), I've always done and been told to create OUs like this:

Accounting
    -SupportStaff
    -CPAs
        -Management
    -Management

Now you put everyone into "Accounting".  Then you put the Support Staff into Accounting\SupportStaff, and your CPAs into Accounting\CPAs.  And CPAs that are management into Accounting\CPAs\Management.  And non-CPA Management into Accounting\Management.  Etc.
0
 
LVL 85

Expert Comment

by:oBdA
ID: 13412204
I can recommend the approach with security group filtering. The advantages:
* Your GPOs are all in one place, which makes for easy editing.
* You can easily control which user gets which policies applied, simply by adding/removing the user from groups. That way, you can basically determine the RSoP by yourself. Not to mention that it makes it pretty hard to lockout an Admin account ny accident.
* It eliminates the need to configure the same policy settings multiple times (for the different OUs). You group together settings that are related to each other (for example Office), and pack them into a single GPO.
An example for this:
Say you want to have the following:
* A locked down desktop for most users
* A locked down Office for some users too
* Some common general Office settings for all users
You create three groups, for example GPol-DesktopLockdown, GPol-OfficeGeneral, GPolOfficeLockdown.
You create three GPOs, for example DesktopLockdown, OfficeGeneral, OfficeLockdown.
In the Desktop Lockdown, you obviously set the policies for a tightened desktop.
In OfficeGeneral, you set the common Office settings (save paths, whatever).
In OfficeLockdown, you disable macros.
In the GPOs, you remove the Authenticated Users group from the Read and Apply permissions, and set it for the group instead.
Join the users to the respective groups, and you're done.

The "apply to only a portion of a department" is a breeze with this construction. You don't have to think in terms of OUs or departments when you're working with this type of policy configuration; instead, all you have to do is look at the user's needs and put him into the respective groups. A secretary is likely to have th same type of desktop, whether she works for department A or department B; so why configure the same policies twice in two different OUs?
All you have to do is some careful planning of how to break down and/or combine the necessary policies.

Oh, and, yes, the RSoP will of course be determined correctly. And leave the default domain policy alone, if possible.
0
 

Author Comment

by:danhilaire
ID: 13412263
oBdA,

Thank for that comment, that really enlightens me on this concept.
-Would you happen to know any disadvantages?
-Does Microsoft document this method or are there any articles that you might know of?

I would like to get as much info on these different concepts as possible in order to make the correct decisions.
0
Complete VMware vSphere® ESX(i) & Hyper-V Backup

Capture your entire system, including the host, with patented disk imaging integrated with VMware VADP / Microsoft VSS and RCT. RTOs is as low as 15 seconds with Acronis Active Restore™. You can enjoy unlimited P2V/V2V migrations from any source (even from a different hypervisor)

 
LVL 16

Expert Comment

by:samccarthy
ID: 13412325
I have to go with leew on this one.  Group policy is designed to go with OU's and only indirectly can you have a security group affected by group policy.  You cannot assign group policy directy to a security group.  Create your OU structure and apply top level GPO's where you need them and lower level GPO's for specifics.  This will keep your GPO processing to a minimum and by using the new GMPC or Rsop, you can see what is affecting what.

I learned both types for doing Group policy and I prefer this method.  I belive the other just overcomplicates things.  Just my humble opinion.

0
 
LVL 57

Expert Comment

by:Mike Kline
ID: 13412968
How many people are in your organization?

If you apply the GPO only at the top level then use GP filtering the rest of the way then that will work but you can imagine that over time the GPO filtering could easily get out of hand and become very confusing.


I do agree that you place your broad GPO's at the top level and but then I would create a new OU for sub groups that may need changes and link those GPOs to the child OU's.  

I've always liked Standford's OU design page

http://windows.stanford.edu/docs/OUDesign.htm

Thanks
Mike
0
 
LVL 85

Assisted Solution

by:oBdA
oBdA earned 1600 total points
ID: 13414358
There aren't any disadvantages I can think of; and you can use a single top level OU to apply policies for a domain of several hundred users this way.
Using security group filtering to apply GPOs is fully documented and supported by Microsoft; after all, they designed it that way. Have a look especially at the first two articles, KB322176 and KB315418. So basically (and I have to disagree with samccarty here), you can indeed assign a group policy directly to a security group, as you could in an NT4 system policy (if you've ever used those); just the means to do it have changed a bit.
And I don't want to turn this into a religious war, but I'm afraid I disagree with samccarthy again on the topics of "GPO processing" and "overcomplicating things".
Once you start setting GPOs at different OU levels, you will face two problems:
* You will *have* to use tools like the GPMC or RSoP to find out which user gets which policy applied why and from where. If you're looking for something specific, you'll have to find the user's OU, check the GPOs for that OU, check the GPOs in any OUs above that, and so on. It gets even more confusing if the same policy is set differently in different GPOs at different OU levels. In my humble opinion, that makes this approach a lot more complicated than to simply look at the groups the user is in. If you use a smart naming scheme (like letting your "policy control" groups start with "GPol", and using names you can identify easily), it's really easy to find out which policies are applied to which user; the why and from where is obvious.
* Applying policies from OUs only doesn't really keep GPO processing to a minimum; the contrary is true. When a user logs on in a down-level OU, all GPOs from all up-level OUs are applied and have to be processed as well. Basically the only way to avoid this is--you've probably already guessed it--security group filtering. So if you have to use filtering anyway, you might as well keep your GPOs together instead of spreading them out over different OUs.

As for the part about "Group policy is designed to go with OU's": yes, group policies are applied to OUs, but that's about all the connection there is. OUs are Organizational Units; as such, they're in no way meant to manage and diversify your users in such a way as to best fit your group policy application. Group policies only have something to do with your organizational structure if you start delegating control over OUs to other departments, and they want to apply their own policies; but then again, the OU that is delegated can be considered "Start of Authority", and the same procedure followed by the admins there.
In other words, you can see group policies as network resources as well as files and folders--and when accessing shares, files, folders, printers, whatever, you use groups to control the access, so you should use them as well when accessing policies.
If you have the need for completely different settings for different OUs, you can easily create some second-level OUs, and apply the policies starting from down there instead of top-level, again with security filtering.

Just combine and group the policy settings to your needs. And don't forget that, similar to applying policies to OUs at different levels, you have a GPO priority when you apply several GPOs to the same OU. Make smart use of it, and you can keep the necessary GPOs to a minimum.
Another wise thing to do (in my humble opinion again) is to keep the "Computer Configuration" and the "User Configuration" settings strictly apart. There's no reason at all to create a GPO in which policies in both categories are applied; one is "Per Machine", the other is "Per User", and there's no connection that I'm aware of that would justify combining the two in a single GPO. That will give you the possibility to disable the respective other part in a GPO; in a "Per User" GPO, you can disable the Computer configuration, and vice versa.

Here are some links that might be useful:

HOW TO: Administer GPO Properties in Windows 2000
http://support.microsoft.com/?kbid=322176

HOW TO: Optimize Group Policy for Logon Performance in Windows 2000
http://support.microsoft.com/?kbid=315418

Group Policy Objects Applied to Organizational Units Containing Only Groups Are Not Applied to Members of Those Groups
http://support.microsoft.com/?kbid=220822

Group Policy Should Not Be Filtered By Domain Local Groups
http://support.microsoft.com/?kbid=309172

Troubleshooting Group Policy Application Problems
http://support.microsoft.com/?kbid=250842

Step-by-Step Guide to Understanding the Group Policy Feature Set
http://www.microsoft.com/windows2000/techinfo/planning/management/groupsteps.asp

White Paper: Introduction to Windows 2000 Group Policy
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolicyintro.asp

White Paper: Windows 2000 Group Policy
http://www.microsoft.com/windows2000/techinfo/howitworks/management/grouppolwp.asp

Windows Server 2000 Resource Kit: Chapter 4 - How Group Policy Works
http://www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/deploy/ccmdepl/ccmch04.mspx

Windows Server 2000 Resource Kit: Chapter 22 - Group Policy
http://www.microsoft.com/resources/documentation/windows/2000/server/reskit/en-us/distsys/part4/dsgch22.mspx
0
 
LVL 16

Expert Comment

by:samccarthy
ID: 13414740
As with many things, each administrator will have their own opinion.  I respect others with differences, however on this one, I'm going with what I was taught and know works for the networks I set up.  While Microsoft might support Group policy as suggested by odba, and I was taught that too, it is not the recommended method.  

Here is a link for Deploying Group policy in a 2003 environment.  It uses the traditional method.  http://www.microsoft.com/downloads/details.aspx?familyid=b671967b-ef65-4ccf-9d00-89d6ae428edc&displaylang=en
Designing the structure properly in the first place does minimize processing.  If not designed properly, there can be issues.

Group policy is applied to OU's.  You are Filtering or modifying an OU policy when you are applying it to Security groups.  While small in the grand scheme of life, it is an important difference.  In my opinion, it is also asking for more complications and problems for the average user trying to setup Group Policy for the first time or for someone not very familiar with it.   As mkline71 said, and I agree, "over time the GPO filtering could easily get out of hand and become very confusing."  For an advanced user such as yourself this may not be an issue, but I have cleaned up too many networks where the worse enemy was the engineer themselves overcomplicating things.

The poster asked for an opinion, this is mine.  They can make their own conclusions from the posts.
0
 

Author Comment

by:danhilaire
ID: 13417342
Mike,
There are about 1700-2000 users and growing,

samccarthy,
Thanks for that link. It has some very useful information.

oBdA,
Hmmm, that is some great information and well...a new concept to me that looks like it can work, although it doesn't seem to be the way Microsoft is teaching it (I mean in MOC classes, they usually say to keep filtering to a minimum). But, it sounds like if you understand the concept of assigning permissions, then you should be able to assign all of your Group Policies by just assigning user to groups instead of applying the policy to the OU where the users are.
Some questions:
1. If you apply your policies at the top level, won't the computer settings affect DC's where the setttings are not configured in the Default Domain Controller Policy. And if so, how do you stop that?
2. you said, "Group policies only have something to do with your organizational structure if you start delegating control over OUs to other departments, and they want to apply their own policies..." Are you sure thats the only time, or can you think of any another?

All,
It either case, it seems like just 2 different ways of doing the same thing. At the end of the day, we all have the same goal when it comes to Group Policy, to give a group of users the same settings. It seems like what you guys have a difference of opinion of is, how to GROUP your users. We can either group them by, OU's, which seem to be the tradional way), or we CAN group them by groups - which is what groups Are for anyway. I was only taught OU's which is why I kind of phreaked out when I heard about putting all of your GPO's on one level and just use filtering. But now, understanding the concept, it seems like a viable way of applying Group Policy. It's just applying permissions and the rules are that everyone under the Policy sees the Group Policy unless the administrator takes them out.
In the tradional method, you have to get creative with OU's. With filtering you have to get creative with Groups.
In either case, you should still be disabling the computer or user configuration where applicable to minimize logon processing. And eventually, using either method, you will eventually come across a situation where you have to create a sub OU, or you have to use Filtering.

Would you all agree to that?
0
 
LVL 85

Expert Comment

by:oBdA
ID: 13418205
With "top level OU", I'm simply referring to an OU that's above the others where you want to apply the settings; this doesn't have to be on the domain level.
So you can easily create, for example, an OU "Acme Users" and an OU "Acme Computers" under a domain acme.local and go from there.
As for applying policies to computer, you can do that the exact same way as with users; in an AD domain, you can make computer accounts members of groups, too.
As I said, OUs are a way to reflect your organizational structure in a way that suits best your needs. If that happens to fit the way you want to apply group policies, all the better.
But creating some "creative" OU structure, for the only reason to apply some combination of policies, is, in my opinion, incorrect usage of OUs. I see policies just as resources, just that they're applied to OUs.
You simply have a lot more flexibility when you work with group filtering.
Small example, nothing too fancy: Let's say you have a locked down desktop for your users. Every now and then, you need to unlock the desktop to check for some errors in an application; for this, you still need to apply most of the policies to the user because of other necessary settings that are defined via policies.
With filtering, you just remove the user from the "GPol-DesktopLockdown" group and you're done.
With OUs, it's more complicated. You'd have to create a separate OU, with all the settings except the desktop lockdown defined, and move the user into this OU.
The point is, you usually have a wide variety of different policies that are applied to different user configurations, and the simple combinatorics involved will reliably prevent the use of OUs only. Imagine, nothing too fancy again, three possible Office configurations, three possible IE configurations, three possible desktop configurations, and users may need any combination. To sort that out with OUs only, you'd need 27 of them. With filtering, you're down to 9 groups controlling 9 GPOs.
Only if you have a few, really well-defined static configurations it might make sense to create OUs just for the policies.
If you're using terminal servers and have the need for different policies, depending on whether the users log on to their desktops or the TS, then there's no way around filtering anyway.
So given your user number, you'll probably end up with a combination. Some top-level OUs for "rough" sorting, and then some GPOs that are applied with filtering for fine-tuning.
Do a thorough research about what you want and need to achieve and configure with policies, then develop a configuration that suits your needs best. Pick the best of both worlds.
0
 
LVL 16

Accepted Solution

by:
samccarthy earned 400 total points
ID: 13419113
Dan, I do believe you have a good understanding of the methods..  I would like to say, you need not create "27" OU's as many users are affected by the same ones and you just link them to whatever OU's you want them applied to.  As for having to "Unlock" the desktop to check, I either log on as a user with more rights to get around this OR I temporarly put the user in a group that can do what I want.  Same thing.  We have 2 different ways of doing the same thing, all with their own pros and cons.  Dan, it's whatevery you feel comfortable with.  If you are used to traditional, set it up that way and in a non production environment test the filtering.  If that works better and you are more comfortable, then go with that.
0
 
LVL 16

Expert Comment

by:samccarthy
ID: 13424125
Thanks and good luck!
0

Featured Post

Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

NTFS file system has been developed by Microsoft that is widely used by Windows NT operating system and its advanced versions. It is the mostly used over FAT file system as it provides superior features like reliability, security, storage, efficienc…
Active Directory can easily get cluttered with unused service, user and computer accounts. In this article, I will show you the way I like to implement ADCleanup..
NetCrunch network monitor is a highly extensive platform for network monitoring and alert generation. In this video you'll see a live demo of NetCrunch with most notable features explained in a walk-through manner. You'll also get to know the philos…
In this video you will find out how to export Office 365 mailboxes using the built in eDiscovery tool. Bear in mind that although this method might be useful in some cases, using PST files as Office 365 backup is troublesome in a long run (more on t…
Suggested Courses

770 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question