[Last Call] Learn how to a build a cloud-first strategyRegister Now

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 600
  • Last Modified:

Child OU Users Group

I would like to ask a follow up question about group policy. I got a book on it, but I'm still trying to work out one thing.

On our domain, we have two folders that contain all the users. One is "Students" the other is "Staff."

I have a child-ou that controls a computer lab on campus. The child OU Looks like


I have populated the computers container with all the computers in the lab, but I would like to apply user specific group policies as well.

My users folder is empty.

My question: Is there any way to populate the users folder of the Child OU with the contents of the enterprise level user folders that has every person's account in it.

If not, it seems we will be limited to computer polices only.
1 Solution
You can apply the policy anywhere you like and choose who it will affect within that container by limiting the scope in the policy's Scope tab. There you can simply place a normal AD group that includes your targeted users.
Mike KlineCommented:
Is there any way to populate the users folder of the Child OU with the contents of the enterprise level user folders that has every person's account in it.

No, you would have to move the users to that OU if you want the users there.  Users can only be in one location in the directory structure.


It sounds like what you want is Group Policy loopback processing.

This causes policy to apply to a user based on the location of the computer object alone. It is very useful for cases such as this where users aren't in the same OU ass the computers - lab or student machines, public/kiosk machines, Terminal Servers, etc. are typical candidates.

Loopback Processing is enabled in the Computer section of group policy; navigate to Administrative Templates / Group Policy, and there you will find an item named "User Group Policy loopback processing mode".

When you enable it, there's 2 settings: merge and replace. "Merge" means that user settings defined at the Computer location are applied on top of (and take precedence over in case of conflict) the user settings defined at the User location like normally is the case. "Replace" means that only user settings defined at the Computer location are applied.

This Microsoft article explains it fairly well: http://support.microsoft.com/kb/231287

Also the built-in explanations in Group Policy editor tend to be pretty decent.
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

Mike KlineCommented:
Darren also has a great blog on loopback   http://sdmsoftware.com/blog/2009/01/06/please-explain-loopback-processing/

...be careful though.  Loopback is generally used for kiosk/terminal server boxes, not on normal user machines.


TowsonStaffAuthor Commented:
Yes, loop back sounds exactly like what I need. I will def check it out tomorrow but I think it's what I need.

Now should I put the GP in the Lab OU or the computer OU?

Mike KlineCommented:
Or just link the user GPOs to where your users currently are.
I'm a little confused by your question "should I put the GP in the Lab OU or the computer OU?" - I thought that you had a lab OU (named "VB100" looking at the original question), containing 2 child OUs, "computers" and "users".

The policy will work as long as it applies to the computers in question. This means it would work if it is applied at the level of the OU named "computers" (within "VB100") in your example, but also if applied at the OU named "VB100". Unless inheritance is blocked, Group Policy objects apply at the OU they're linked, and all its child OUs below. If a child OU has a policy that conflicts with a policy at its parent OU, the policy at the child OU normally "wins" because it is "closer" to the users and/or computers within it.

I would probably choose to apply this policy at the "VB100" OU, because it seems a bit more intuitive in my mind, but either place will work fine. This assumes of course that there aren't any computers outside the "computers" child OU that should NOT receive this policy.

Some general notes on Group Policy that may be helpful:

- At the OUs, Group Policy Objects (GPOs) are linked - kind of like a shortcut pointing to a file. You can have the same GPO linked in several places, and when you edit that policy, the change applies everywhere it is linked. You can remove a link, or even all, but still have the GPO (so you can link it again later with the option "Link an existing GPO..."). There is a container called "Group Policy Objects" where the actual GPOs are stored (you can delete them from there if you want to really get rid of them). A GPO that isn't linked anywhere is not in effect anywhere of course.

- GPOs by default apply to "Authenticated Users" (and "users" in this context also means computers - this group basically covers every user and machine that is known or authenticated - it is almost but not quite the same as "everyone"). You can restrict the GPO to a specific group of users and/or machines by replacing "Authenticated Users" by something else, such as say a domain group named "Accountants". This is done in the section named "Security Filtering" on the Scope tab.

This technique is very handy for things like creating drive mappings to network shares (using logon scripts) for specific groups of people. At the same time you can use the same group to control permissions on that share (and underlying directory) - you can drop someone in that group, and they will automatically get the proper access and drive mapping. Remove them, and the access is gone. This can be worthwhile for even one person - if that person leaves or is replaced, all you have to do is replace the user in the group, and you're done. A person can also very easily be put in multiple groups this way, without having to be in multiple OUs which would of course not be possible. Note that computers can be put in groups just like users (computers in AD are internally really a special kind of user account, and treated similarly in many ways).

Keep in mind that in order to receive the policy, the user or computer must both fall within the scope of the OU(s) it is applied, and the entities (a group a lot of the time) in the "Security Filtering" section of the GPO. Sometimes this means having to apply the policy at a high level (top OU, or even site or entire domain), and relying on the group(s) to target the policy where it needs to be.

Group Policy is seen as a complex subject a lot of the time, and it can be. The building blocks it is made up of are really pretty straightforward however, and properly understanding these basics really makes it a lot more transparent I think. It can be quite powerful and useful.

Well I didn't mean to write such a lengthy post, but there you have it. Hope it's of some use to someone..
I believe I answered the question by suggesting loopback processing in post #35445511.


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.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now