Solved

How to filter Group Policy objects based on certain users and certain PCs

Posted on 2010-08-23
44
1,235 Views
Last Modified: 2012-05-10
In a GPO on Server 2008, there's a scope\Security Filtering list and the Delegation tab. Scope is where you say who the GPO applies to and in Delegation you can set who to NOT apply the GPO.

I have an OU with a bunch of PCs and an OU with a bunch of users.

I want to create a GPO that says If you are user1 AND you are logging into pc1, then the following GPO applies.

It seems as though scope says If you are either a user, PC in the list (or a member of a group that's in the list), then the GPO applies, rather than making both a requirement. I'd prefer not to use WMI filtering and I'd prefer not to have to add new PCs and Users to a group just to make sure they don't get a GPO applied. Instead I'd much prefer to have group(s) that I can add users or PCs to that basically says "if you're a member of this group and the pc you're logging into is a member of this other group, then this GPO applies."
0
Comment
Question by:MrSampsonite
  • 25
  • 11
  • 6
  • +2
44 Comments
 
LVL 57

Expert Comment

by:Mike Kline
ID: 33501340
You an filter on users and machines like you noted but no way that I know of to make a group policy filter that says if you log into this machine the policy applies or another machine  

You can use loopback processing to say apply user settings to a computer.  Darren has a good overview here

http://sdmsoftware.com/blog/2009/01/06/please-explain-loopback-processing/

However say you have hundreds of machines or more in that OU and you want different policies for groups of machines based on who logs in...that could bet complicated but possible (you can also filter on loopback)

Thanks

Mike
0
 

Author Comment

by:MrSampsonite
ID: 33501382
I'm confused, how will loopback have a part in this since this setting is a computer setting, not a user setting in the GPO/
0
 
LVL 2

Expert Comment

by:herald_thomas
ID: 33501388
Creating an Administrative Template would serve the purpose

This involves three steps:

A) Create a Group Policy Object

To create a Group Policy object (GPO) in which to import a custom Administrative Template:

   1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
   2. In the console tree, right-click the domain or the organizational unit in which you want to create the Group Policy setting, and then click Properties.
   3. Click the Group Policy tab, and then click New.
   4. Type a name for this Group Policy setting (for example, custom registry policy), and then press ENTER.
   5. Click Close.

b) Create an Administrative Template

   1. Start Notepad or another text editor, and then type the Administrative Template information.
   2. Save the file in the Windows_folder\Inf folder, and then give it an .adm file name extension.
   3. Quit the text editor program.

c) Load the Administrative Template

   1. Click Start, point to Programs, point to Administrative Tools, and then click Active Directory Users and Computers.
   2. Right-click the domain or the organizational unit that you want to configure, and then click Properties.
   3. Click the Group Policy tab, click the Group Policy setting that you want to edit, and then click Edit.
   4. Under either Computer Configuration or User Configuration, right-click Administrative Templates, and then click Add/Remove Templates.
   5. Click Add, click the template that you want to add, and then click Open.
   6. Click Close.
0
 

Author Comment

by:MrSampsonite
ID: 33501446
Aren't you just describing how to import a setting? how does that affect the group filtering I want to do?
0
 

Author Comment

by:MrSampsonite
ID: 33501459
Oh, and as mentioned in the first post, this is Server 2008, so the method of getting to the GPMC is much easier than you're describing. Just go to administrative tools.
0
 
LVL 57

Expert Comment

by:Mike Kline
ID: 33501488
you are right if it is a computer setting then loopback won't help; computer settings won't be filtered out based on users.  
0
 
LVL 8

Expert Comment

by:ZombieAutopsy
ID: 33501490
All i did to seperate users was use the basic setting on the default Policy, create, a new OU, and create a new GPO based on that folder. This way I would only have select people to be able to, lets say cahnge there backgorund.
0
 

Author Comment

by:MrSampsonite
ID: 33501591
Zombie, are you saying you put the users or the computers in a new OU instead of another one?

I moved there are a bunch of service accounts that in a specific OU in my domain. And this PC is in an OU for XP machines.

But if I were to create a sub OU for the PC or the User and just apply this GPO to that(those) OU's, then this only works if I only have a GPO for that OU. If I want to apply certain GPOs to certain PCs when certain users log into those PCs, then the OU breakup messes it up since a user and PC can only be in one OU each at a time.

I'm beginning to think it's near impossible to create a GPO and say "if the logged in user is a member of X group and the PC being logged into is a member of Y group, then apply this GPO". It seems like a basic requirement for AD GPO management.
0
 

Author Comment

by:MrSampsonite
ID: 33501615
mkline, computer settings can be filtered for only certain users, within the setting itself (if it pertains to it). For example, connecting over RDP is a setting that you specify users or groups of users.
0
 

Author Comment

by:MrSampsonite
ID: 33501678
I think I may have figured it out on my own.

The Scope\Security Filtering section for the GPO can be used to apply to certain PCs or groups of PCs.

Then under Computer settings, in the User Rights section, only add the users or groups of users you wish to have the right.

So a GPO will apply to GroupOfPCs and then for example RDP will only apply to the GroupOfUsers. I can link it to the OU and know that only PCs in the GroupOfPCs will get the setting and the setting will only allow GroupOfUsers. If another user logs into that PC who is not a member of that group, they will be denied that right. If an allowed user logs into a PC in that OU that's not a member of that GroupOfPCs, then they won't have that GPO applied to them.

Not sure who to give the points to since I didn't create a new OU nor use loopback processing.
0
 

Author Comment

by:MrSampsonite
ID: 33501724
Here's a follow up question:


What is the GPO effect in scope and in computer setting if it applies to a group that has both a PC and a user account? Here are the options I think:

A. Setting applies to every PC that the user logs into and to every user who logs into that PC. Essentially way too much access.

B. Setting only applies to the computers in that group when the users in that group are logged in, assuming the scope just has that group and the setting only allows that group.

C. ???
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33501764
First off: any policy under *user* configuration will only apply to *user* objects in or below the OU to which the GPO is applied; accordingly, any policy under *computer* configuration will only apply to *computer* objects in or below the OU to which the GPO is applied. This behavior can not be changed.
This means, in turn, that even though it's technically possible to configure both user and computer settings in the same GPO, do NOT do it. Never. Ever. Keep user and computer GPOs strictly separated. It seems that you may be able filter out computer policies based on the user logging on or vice versa, but this is NOT the case.
Loopback processing is a single "on or off" setting set per machine; it does NOT have to be done in the same GPO as the user settings you want to apply when a user logs on to this machine. The easiest way to understand loopback processing: it basically tells the GPO processing unit to pretend that the user object currently logging on is not only in its own OU, but in the same OU as the computer object as well (with the computer OU having a higher priority).

In other words: it would be very useful if you would tell us which kind of policies you're trying to apply here or which result exactly you want to achieve.
Applying *user* configuration based on the *machine* the user is logging on to is possible.
Applying *computer* configuration based on the *user* logging on is impossible.
0
 

Author Comment

by:MrSampsonite
ID: 33501901
oBdA, thanks for the input.

I told mkline that this is a "computer" setting, not a user config setting.

Also, you can filter based on user logging in by changing the computer setting to only allow a group/user.

I'm not privy to say which setting exactly I'm trying to set (per company policy), but let's discuss an example: "Shutdown a system".

If I want to allow any user in groupA to shutdown any PC in groupB, then I have to create a GPO and link it to the OU(s) that contain all the PCs this would affect. If I use scope filtering, I could apply it only to groupB and then apply at the domain level, but that's a bit dramatic and unncessary since my PCs are all in one subOU or another of a big custom OU. Then I could change the computer setting for who is allowed to shutdown the system and add groupA.

So if the PC is not in groupB, then some other GPO will apply and take precedence. Likewise if the PC is in groupB but the user is not in groupA, some other GPO will take precedence. But if the PC is in groupB and the user is in groupA then that setting will look different that other GPOs and it will allow/disallow depending on the setting.
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33502297
I don't need specifics; do I understand you correctly that you want to delegate a User Right for a certain group of machines to a group of users?
That's relatively easy to do, and you only need one group and one GPO (per server group to delegate):
Create a domain local group "UserRight_ShutDownSystem_ServerGroupB" or whatever.
Create a GPO "Delegation_ServerGroupB" or whatever, and in Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights, add this group to the user right "Shut down the system" (don't forget to add the default accounts as well, applying a User Right is "destructive").
Apply the GPO to the "GroupB" computer objects in question (either by adding them to a security group and using security filtering, or by grouping them in OUs).
Then add the user GroupA (probably a global group) to the domain local group you created.
For other User Rights you want to delegate, create other domain local groups and add them in the same GPO for the GroupB computers.
That way, a short look at the "member of" attrribute of GroupA will allow you to see which user rights are delegated to this group.
0
 

Author Comment

by:MrSampsonite
ID: 33502338
Yep, you just described what I found out and posted about. My only difference is the process of using domain local and domain global groups that you describe, why the suggested action regarding those types of groups?

Also, any idea on the ABC question?
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33502926
What you've described in http:#a33501678 is not the same, especially not "If an allowed user logs into a PC in that OU that's not a member of that GroupOfPCs, then they won't have that GPO applied to them."
The delegation of a User Right has nothing at all to do with the policies applying to a *user* account when logging on.
You give a group permission to a User Right, and the rest depends on whether a user is a member of this group or not, exactly the same way it works with NTFS permissions. These rights apply whether the user is logged on to the target machine or not. Again: *user* policies do NOT come into play here at all.

The way I described the delegation above is the way permissions (any permission: User Rights, NTFS, printers, ...) for resources should be given in an AD domain, "AG(D)LP": Accounts are members Global groups, global groups are members of (Domain) Local groups, and (domain) local groups are assigned Permissions (you can use local groups on the server hosting the resource instead of using domain local groups; depends on the situation).
More here: http://en.wikipedia.org/wiki/AGLP
Unlike global groups, (domain) local groups can contain members of trusted domains, so if you ever migrate into another domain, there will be way less problems assigning cross-domain permissions.

To your "ABC" question: please read my comment in http:#a33501764 again. Despite the name, GPOs are only ever *applied* to user or computer objects, never to groups (you wouldn't be able to get a well-defined RSOP if you could apply GPOs to groups). The groups in security filtering control access to the *complete* GPO, not to the policies contained in the GPO. 
Think of an Excel document with two sheets "Computer" and "User"; you can control access to the complete document with NTFS (in this case the Security Filtering). You can not use NTFS/security filtering to control access to the individual sheets inside the document.
That's why you should never combine User and Computer configuration in the same GPO; they have nothing at all in common, and it will only develop into an administrative nightmare.

0
 

Author Comment

by:MrSampsonite
ID: 33503412
I'll reply in reverse order in case I answer my own question.

In response to your last paragraph about ABC, let me make sure I'm clear: I'm not setting any User configuration settings in the GPO. I'm setting User Rights settings (which are under Computer Configuration\Security Settings\Local Settings\User Rights.

When you say GPO's are never applied to groups, I'm not sure if we're in disagreement or not. The Scope Tab > Security Filtering section gives you the ability to add users, groups, or PCs that can only apply to. When I add a group that has users, the GPO only appears to take affect if the user logging in is in that group. Likewise if I add a group that contains computer objects, it appears to only apply to computers that are in that group AND in the OU the GPO is linked to. So while GPOs cannot "apply" to groups, it appears you can choose which computers or users the GPO takes effect on by using the scope and/or delegation tab sections (delegation allows you to say "don't apply to this group of users/computers or individual user/computer)."

Thanks for the link on AGDLP. Hadn't heard of that before. I'll study it some more.

Regarding your first paragraph, I see what you're saying, but if putting a computer or group of computers in the Security Filtering section of Scope tab effectively limits when the GPO takes effect, why am I mistaken? Are you assuming I leave the "Authenticated Users" group in that section? I'm not. I'm usually removing it so that the GPO doesn't take effect for everyone.

Forgive me if I'm sounding "certain". I did some test and thought I saw the results I'm describing. Maybe I'm mistaken.


0
 
LVL 83

Expert Comment

by:oBdA
ID: 33504523
The "Security Filtering" field, btw., is just a filtered view of the delegation tab listing all objects with Read and Apply permissions.
Well, I'll continue with my comparison from http:#a33502926, the Excel document with two sheets "Computer" and "User" in it; I'll ignore features like priority, no override, breaking inheritance, loopback processing, or WMI filtering, they're not important for this.

The Security Filtering only controls access to the Excel document, that is, the Group Policy Object as such. It can not control whether any cell (an actual policy) in any sheet inside the document is accessed or not, it's all or nothing.
When a computer boots, it first queries for a list of GPOs (the Excel documents) linked to the OU in (or under) which the computer object resides.
For each GPO (document) the computer object has the "Apply" permission, it will look at the Computer Configuration tree (the Computer sheet) and apply all policies (cells) found there.
It will not care the least bit about the User Configuration tree (the User sheet).
Likewise, when a user logs on, he first queries for a list of GPOs (the Excel documents) linked to the OU in (or under) which the user object resides. 
For each GPO (document) the user object has the "Apply" permission, it will look at the User Configuration tree (the User sheet) and apply all policies (cells) found there.
It will not care the least bit about the Computer Configuration tree (the Computer sheet).
These processes are completely independent of each other.
That's why there is no way that any GPO permission given to a user will ever influence a computer policy or vice versa (as you indicate in your "ABC" question). And that's why mixing User and Computer configuration policies in the same GPO will result in an administrative nightmare.
0
 

Author Comment

by:MrSampsonite
ID: 33504786
oBdA, are we debating the same thing? You keep reminding me that mixing User and Computer configuration policies in the same GPO will result in an administrative nightmare. However, not once have I said that I am mixing them.

I have several GPOs with only one setting in the computer configuration section. that setting is under the User Rights section of Computer Configuration (not to be confused with the User configuration section settings).

If I only list a group of PCs that the GPO will apply to (and not authenticated users as well), then only the PCs in that group and in that OU will get the User Rights setting that I listed. Now if one GPO gives that User Rights setting one particular setting and this new GPO gives it a different setting, the new setting will take over (assuming higher precedence). That's why I can then use a group of users to affect what users will have access to. The "all or nothing" really just means that one setting because it's the only setting that conflict.

Assume the following:
gpo1 has higher precedence than gpo2
gpo1 allows Administrators and grp1 groups to have "shutdown system" permission
gpo2 allows just Administrators to have "shutdown system" permission.

gpo1's version of "shutdown system" will be the setting that's applied no matter who logs in. but because a custom group was specified in addition to administrators, only the users in that grp1 group who are not also admins will be able to shut the system down, plus the admins.

now that permission will exist in the settings regardless of who logs in, right? if joe logs in but isn't a member of that grp1 group, then the gpo will still apply and you can see via RSOP that the grp1 group has that ability.

my goal was to find out if there's a way so that only the members of grp1 will see Administrators and grp1 as having access to shutdown the system and then if other non-members log in, their security permission will just show Administrators. Is it possible for the setting shown to be dependent on whoever logs in? Clearly because of precedence rights, the effective setting is the same, but I don't want users who are not in grp1 to see that grp1 members do have this right. Does that make sense?
0
 

Author Comment

by:MrSampsonite
ID: 33504874
follow up question that's related:

If I create a new GPO and set any setting under Computer Configuration, and then in the Delegation tab add a user and say "deny apply group policy" against that user, what will the effect be?

A. Since it's a computer configuration that setting will apply regardless whoever logs in
B. That setting will not be pushed down when that user logs in because of the deny ACL.

And does the answer get affected if you remove Authenticated users from the delegation/scope list?
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33505703
Giving user accounts as well as computer accounts access in the same GPO security filtering would only make sense if you'd be mixing user and computer configuration settings (yes, administrative nightmare and so on); see the GPO processing description in http:#a33504523
I repeat (minus the Excel now), and this should answer your questions in http:#a33504874:
"When a computer boots, it first queries for a list of GPOs linked to the OU in (or under) which the computer object resides.
For each GPO the computer object has the "Apply" permission, it will look at the Computer Configuration tree and apply all policies found there."
This is what happens; nothing more, nothing less.
In short: the answer is obviously A (and note that domain computers are Authenticated Users as well!); that setting will be applied regardless of any users logging on or not.
If you remove Authenticated Users, the setting won't processed, because now the computer object doesn't have Apply permissions anymore.

You can disable the possibility to create an RSOP with a (user) group policy (users don't have it on W2k8 by default), but it shouldn't be a problem if somebody sees that a group "UserRight_ShutDownSystem_ServerGroupB" has the User Right "Shut Down the System".
Listing the members of a group could be controlled by AD permissions, if really necessary.
0
 

Author Comment

by:MrSampsonite
ID: 33511195
here's a real world example that I can share:

we have some computer configuration settings that need to apply to certain domain controllers and certain ones that need to apply to other domain controllers. some conflict.

per microsoft best practices we are not creating sub-OUs for different domain controllers. thus we need to figure out how to apply certain GPOs to certain domain controllers. The thought of using WMi filtering came up, but was rejected for two reasons. the first is performance. from what I've read, WMI filtering can cause performance issues. the second is that it is difficult to find a property that is consistent across all DCs of a particular group. Some are win2k8, some are win2k3.

the issue is, without using sub-OUs, how do we apply a GPO only to a certain group of PCs and only when a certain group of users log in (or at a minimum only to a certain group of PCs)?
0
 
LVL 57

Expert Comment

by:Mike Kline
ID: 33511264
You can apply to certain groups of PCs by using normal security filtering.   Create a domain controllers 1 group and a domain controllers 2 group for example and filter off those.

Thanks

Mike
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33511339
Again the question: are the *policies* you want to apply under Computer configuration or under User configuration?
0
 

Author Comment

by:MrSampsonite
ID: 33511414
As I've always said, the policies are under Computer Configuration > ... User Rights. Not User Configuration.

mkline, I created a group of PCs to NOT apply certain settings to. I then added it to the list in the delegation tab and clicked "deny apply policy". In the Scope tab (a subset, yes), it had Authenticated users that are allowed to apply the policy. It seems as though when an authenticated user logs in and checks RSOP, policies under Computer Configuration from that GPO are applied even though the group of PCs is set to deny. I must be wrong in my understanding of how these take effect. To me, the scope security filtering section lists all the users/groups that can apply the setting. and even if a PC or group of PCs is denied appying the policy in the delegation section, if an authenticated user logs in, it still shows those policies applying. the deny based on PC piece is not take precedence over the allow based on user piece.
0
 
LVL 57

Expert Comment

by:Mike Kline
ID: 33511556
What you did sounds right and exactly what Alan shows here:  

http://www.grouppolicy.biz/2010/05/how-to-exclude-individual-users-or-computers-from-a-group-policy-object/

**full disclosure ** I have not tried your exact test (security filtering on DCs with user rights assignment)
0
 

Author Comment

by:MrSampsonite
ID: 33511609
That's the blog I found and followed. It's very odd that it's not working. i disabled the link, refreshed the gp policies on the PC and the settings went away as expected. but if I add a group of pcs and deny apply policy, then reenable the link, run a gpudpate, the policies are now applying again. very odd. this is for computer configuration settings.
0
 
LVL 83

Accepted Solution

by:
oBdA earned 300 total points
ID: 33511746
First off: if you add computers to a group and want to use this group in security permissions, the computers in question need to be rebooted in order for the change in group membership to be reflected in the computer's security token (the same way a user needs to log off and back on if he's added to a group.)
Then about "how do we apply a GPO only to a certain group of PCs and only when a certain group of users log in": a user logon, a user policy, or GPO permissions assigned to a user will have absolutely no impact on any computer configuration policy, full stop. I repeat: "there is no way that any GPO permission given to a user will ever influence a computer policy or vice versa."
About "To me, the scope security filtering section lists all the users/groups that can apply the setting.": Wrong. Please read http:#a33504523 again. Security Filtering decides whether the computer (during boot) or the user (during logon) gets the GPO(!) listed as applicable or not. It does not control the application of the policies in the GPO. Computer configuration settings are only applied to computer objectsuser configuration settings are only applied to user objects, regardless of the GPO permissions.

Sorry, but you're over-complicating things here.
What you're trying to do is a simple delegation task as I've described in http:#a33502297.
You can control the delegation using security filtering either by adding the DCs to a group, or by adding the *computer* objects directly to security filtering.
The permission to make use of that delegation is given by adding the user (directly or nested) to the group you've delegated the User Right to.
Neither user logons nor user policies configuration policies are involved here, and user permissions assigned to the GPO are completely useless.
0
 

Author Comment

by:MrSampsonite
ID: 33511867
Now I think we're getting somewhere.

1. I think the rebooting of the PC may have been a factor. I don't know if I did that so I will go back and run some tests.

2. It is unfortunate that you cannot affect computer settings based on who is logging in. I realize it "kind of" makes sense, but why is it so crazy to say that some of the computer configuration settings should be set when certain users log in? Maybe that's a beef to take up with Microsoft.

3. Just to make sure I'm understanding this, if we add a user, computer, or group of users or group of computers to the security filtering, then for users and groups of users we're saying whether or not to apply the GPO User Configuration settings for those users and for computers and groups of computers we're saying whether to apply Computer Configuration settings for those computers, right? So if a GPO only contains Computer Configuration options and we deny application of that policy to a user or group of users, that has no actual affect. Not at least until there's a user configuration setting in the GPO.
0
 
LVL 57

Assisted Solution

by:Mike Kline
Mike Kline earned 200 total points
ID: 33511937
I agree about the reboot, good pick up.  In 2008 you can pick up memberships using a nice trick Darren describes here:

http://sdmsoftware.com/blog/2008/08/22/picking-up-computer-group-membership-changes-without-a-reboot/

Thanks

Mike
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33512008
2. Because you'd never get a well-defined Resultant Set Of Policies (the same reason why GPOs can't be applied to groups).
3. Yes, that basically correct now; it's not how it's actually implemented, but that's the result it has.
0
 

Author Comment

by:MrSampsonite
ID: 33512049
3. can you explain? I need to implement it, so understanding that part is important.
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33512136
It's implemented exactly as I described it in http:#a33504523: the security filtering controls whether the user (at logon) or computer (at boot) can access the GPO(!) ("Excel document") at all; it does NOT control the user's/computer's access to the policy settings ("sheets" and "cells").
0
 

Author Comment

by:MrSampsonite
ID: 33512219
when you say it controls whether the user can access the gpo and not whether they can access the policy settings, what is the distinction? accessing the gpo, if it fails would mean the settings of the gpo are not applied, right? what if they are not applied, what does it mean now to say the user can still access the policy settings (excel sheets)?
0
 

Author Comment

by:MrSampsonite
ID: 33512223
key words being "access"
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33512488
The exact same distinction as between accessing an NTFS protected document and then accessing elements inside this document in the application.
If a user doesn't have access to the document, he won't be able to open it at all.
If he has access to the document itself, then access to the sheets, cells, or tables (in case of an Access database, for example) *could* be controlled by the application. But the GPO processing dlls as such implement no policy setting (cell/sheet/table) based access control.
0
 

Author Comment

by:MrSampsonite
ID: 33512530
I think we're getting somewhere. I will try and test this later today or tomorrow. Fighting fires today.
0
 

Author Comment

by:MrSampsonite
ID: 33512558
thanks mike for that tip/trick. good to know. I do wonder if it's resource intensive to purge all of them at once though.
0
 

Author Comment

by:MrSampsonite
ID: 33524017
Been thinking about something.

Is it pointless to create a GPO with only user configuration settings and then only link it to an OU that only contains computer objects? And likewise to create a gpo with only computer configuration settings and then only link it to an OU that contains only user objects?

Will that essentially have no effect when someone logs in or the PC reboots?
0
 
LVL 83

Expert Comment

by:oBdA
ID: 33524645
The latter is totally useless; the former will work if Group Policy Loopback Processing is enabled for the machines. With LB, when a user logs on, the GPO unit basically pretends that the user is in the OU of the machine and will process user policies.  See http://support.microsoft.com/kb/231287
0
 

Author Comment

by:MrSampsonite
ID: 33524800
thanks, and does LB overwrite any user configuration GPOs from the OU the user actually resides in?
0
 
LVL 57

Expert Comment

by:Mike Kline
ID: 33524857
Loopback can be used in merge or replace mode; replace will just apply the new user settings.

Another helpful loopback reference is from GP MVP Darren  http://sdmsoftware.com/blog/2009/01/06/please-explain-loopback-processing/

thanks

Mike
0
 

Author Comment

by:MrSampsonite
ID: 33525806
Thanks Mike.
0
 

Author Comment

by:MrSampsonite
ID: 33568760
Hi everyone.

1. Tested GPO filtering using group membership and the delegation tab, and once it was rebooted the filtering took effect. Great call on that piece.

2. Now debating what the best practice or wise method of filtering is for our environment. Here's a basic rundown:

Because of different policies, our computer OU structure is this:

Domain
child-ou-A : HQ
   --> : Computers
        --> Servers
            --> 2000
             --> 2003
             --> 2008
        --> Workstations
            --> XP
             --> Vista
             --> Windows7

Now it turns out workstations and servers are in 1 of several growing categories. This may be based on programs, departments, etc. These programs share common policies across the domain but also have separate policies for certain setups.

The question I have is How should I organize to apply different policies. Options are:

a) create top level OU's and recreate the Server/Workstation child OU structures under each one.
b) create sub-OU's for each of the lowest level OU's. For example Program1 and Program2 might be child OUs of 2000, 2003, 2008, XP, Vista, and WIndows7
c) apply those separate policies at the same level as the rest (under Computers) but then create a domain group that contains all the PCs for Program1 and apply that GPO only to that policy and do the same for any other program.

I'm leaning towards C just for simplicity of the OU structure, but to the passer by it may look like the GPOs for each program apply to every computer object under the OU and it requires managing group memberships. Option B might work, but again tons of sub OUs need to be added each time a program comes along with different policies. Option A seems the simplest, but it requires recreating the OU structure every time a new program comes online and then linking policies to multiple OUs each time.

Thoughts?
0

Join & Write a Comment

I know all systems administrator at some time or another has had to create a script to copy file from a server share to a desktop. Well now there is an easy way to do this in Group Policy. Using Group policy preferences is not hard. The first thing …
Synchronize a new Active Directory domain with an existing Office 365 tenant
This tutorial will walk an individual through the process of transferring the five major, necessary Active Directory Roles, commonly referred to as the FSMO roles to another domain controller. Log onto the new domain controller with a user account t…
This tutorial will walk an individual through the process of configuring their Windows Server 2012 domain controller to synchronize its time with a trusted, external resource. Use Google, Bing, or other preferred search engine to locate trusted NTP …

746 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

Need Help in Real-Time?

Connect with top rated Experts

9 Experts available now in Live!

Get 1:1 Help Now