Attaching GPO to OU does not work, attaching to root of domain does work ?

Posted on 2010-09-17
Last Modified: 2012-05-10

I have never had to attach a GPO to an OU container, I normal have just had to create policy and link it to the domain root.

I have an OU, inside my OU in AD users and computers I have a Group, and memebrs to that group are users.

I cleared all default and other GPO that have been created on a test server(clean install),
I created a GPO policy and attached it to the OU in Group Policy Management Console.

When i log onto XP machine which has been registered to the above server, nothing is applied.
If I go and cancel linking on OU, and attach it to the Domain Root, all works?

My GPO, only has filtering set to the Group Container that is within the OU in question, it does have read and apply GPO permission.

Can anyone help ?
Question by:spiraldav
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
  • 3
  • 3
  • 2
  • +2
LVL 22

Accepted Solution

Joseph Moody earned 167 total points
ID: 33702420
If the GPO has a computer setting in it, it must be linked to the OU containing the computer.
Policies can not be linked to an OU containing just a security group.
LVL 57

Assisted Solution

by:Mike Kline
Mike Kline earned 167 total points
ID: 33702425
The GPO has to be linked where it applies to users or computers (depending on what is being set)
So if that GPO contains user settings and your OU doesn't contain any users then nothing will happen
If the GPO contains computer settings and yoru OU doesn't contain machines then nothing will happen so in your case you only have that group inside that OU so that is why nothing is happening.
When you linked it at the domain level it is applying to users/computers, but being filtered only to that group using security filtering.

Author Comment

ID: 33702752
Hey Guys,

Thanks so much for that, Id love it if that info was in my microsoft books, as I have double checked my self etc and couldn't find a resolve showing I need users in that OU and not just a Group thats linked to users from users container.

Ok Mike, so if i understand correctly the following should happen :
If I attach a policy to an OU, that OU cant have a Group as the policy will not be applied to users of that Group, but if I have users in the OU then the GPO will be applied to them.

How do I get past the computer policy application ? do I add machines to the OU as well ?
What if the users move to other machines that are not in the OU, then will the machines not get the computer policy applied ?
and by that happening then they will get whatever default computer policy you have at the root of the AD.?

And if i understand this correctly quote : "When you linked it at the domain level it is applying to users/computers, but being filtered only to that group using security filtering. "

by filtering we mean, filtering to the groups or user under the security tab, and not WMI filtering.

Thanks for the help to both who posted.
NFR key for Veeam Backup for Microsoft Office 365

Veeam is happy to provide a free NFR license (for 1 year, up to 10 users). This license allows for the non‑production use of Veeam Backup for Microsoft Office 365 in your home lab without any feature limitations.

LVL 41

Assisted Solution

by:Adam Brown
Adam Brown earned 166 total points
ID: 33703062
"If I attach a policy to an OU, that OU cant have a Group as the policy will not be applied to users of that Group, but if I have users in the OU then the GPO will be applied to them."

Just a slight technical correction here, a GPO *can* be attached to an OU with groups in them, it's just that the policies aren't processed by the groups. Only the users.

Also: "I cleared all default and other GPO that have been created on a test server(clean install),"
I'm not sure if I'm reading this correctly, but it seems to say that you removed the Default Domain Policy and Default Domain Controllers Policy. If that is the case, I should warn you that this can cause a lot of problems. Those policies are configured with some important operational settings that are necessary for AD to work properly, including default user rights and server communication settings.

But, to clarify, there are two pieces to any GPO. Computer Configuration, and User configuration. If you set a policy in the Computer Configuration section, the Policy won't do anything unless it's linked to an OU with computers in it. If you set a policy in the User Configuration setting, it won't do anything unless it's linked to an OU with users in it, with one very important exception. If you enable Loopback Policy Processing (Info here: ) you can link User Configuration policies to an OU with just Computers in it and the policy will be applied to users that log in to those computers. So if you want users that log in to specific computers (but not all the computers and users) to have a certain type of setting that exists in User Configuration, you can set Loopback Policy settings to allow that to happen.

Author Comment

ID: 33703332
Thanks for clearing all up and thanks for reminding me about loopback, just have never needed to use it, so falls out of memory if you know what i mean.

about your question to my statement ""I cleared all default and other GPO that have been created on a test server(clean install),"

I unlinked the default domain policy from the root of the domain, but I had made a copy of default domain policy and modeled my GPO setting on the copy that i renamed.
and the Default Domain Controller policy from what I can see is not linked, and from looking at what settings are applied in it are practically nothing at all ? but if I have more than one domain controller then only will that come into play ?

As a best practice should I rather do the following :
Leave Default Domain Group Policy, set security settings on that file GPO and apply it to authenticated users.

Then create whatever restrictive policies i need in a new GPO, and apply that to OU's, in the OU's have users and create groups for those users, (the reason for groups if for when applying NTFS permissions, makes applying to group rather than users much easier to maintane )

Then if I apply computer policies in a GPO but users move around the network, create a link from the GPO using a Loopback Policy to the computers container, where all authenticated machines are placed.

again thanks for all the help.
LVL 22

Expert Comment

by:Joseph Moody
ID: 33703466
Your default domain policy is best left unaltered and linked to your domain. Your default domain controller policy is very important and should be left linked to your domain controllers OU.
LVL 41

Expert Comment

by:Adam Brown
ID: 33703468
Well, you should try to use Loopback policy as sparingly as possible. It's mostly just useful if you want to have user configuration settings like desktop background and screen saver time out to be applied when users log in to certain computers, but not all the time. If you want user configurations to be applied to all users (or groups of users), create a GPO with only User configuration settings and apply that to the OU the users are in. You can save yourself from having lots of GPOs all over the place if you use Loopback policy and only attach to the Computer OUs, but it has the potential of increasing headaches during GPO troubleshooting down the road.

Generally, the best practice for Default Domain Policy and DDC Policy is to just leave them alone. If you have additional security settings that you want to use, build a new GPO and attach it to the Domain or OUs that need it applied and make sure it is set with the highest priority. That will allow the settings you have to be applied instead of the Defaults if you want. There aren't a lot of settings in the Default Domain Policy at the start, but the settings that are there are very important.
LVL 13
ID: 33716585
You CAN create a group policy object and link it via groups instead of by OU.

However, to do so you must put it at the root of the OUs where ALL of the users who may ever be members of the group will exist (Therefore it's best practice to put these GPOs at the DOMAIN level).

Then you simply change the groups it applies to in the group policy's Security tab.

To do this you

 1st you would create a new GPO at the domain level, then you would edit the GPO's Properties by right clicking on the GPO and selecting properties.

 2nd you would go to the 'Security' tab and remove the 'Apply Group Policy' setting from "Authenticated Users"

 3rd You would Add the specific groups which should have the GPO applied to them, to the policy and give them "Read" and "Apply" Permissions for the Group Policy.  (NOTE: It's best practice to create a single new group for this GPO and add this on the Security tab instead, and then add the appropriate users/groups to hat group.
LVL 41

Expert Comment

by:Adam Brown
ID: 33717159
QCubed: That still isn't linking a GPO to a group. That's linking a GPO to the Domain and *filtering* policy application with a security group. At the low level, security filtering applies an ACL to the policy, making it so only the members of that group have permission to read and apply the policy. There's a very important technical distinction there.

And it isn't really a best practice to apply filtered GPOs to the Domain. If all the users or computers (or if a small subset of users in an OU) that are filtered exist in a single OU or OU branch, linking it to the top of the branch or the OU itself serves as a visual reminder to administrators. This prevents admins from having to look through the Filter settings of all GPOs to find the one that is affecting users that have issues. In addition, each computer in the domain still has to process the policy if it's linked to the domain, meaning that you have some amount of time (however small) where the computer has to communicate with the Domain Controller to view the Policy and its attached ACL. It's not a big deal in small environments, but if you have 100 GPOs in AD and they're all attached to the Domain, it will seriously hamper logon performance and potentially bring a DC to its knees during periods of high logon traffic.

Author Comment

ID: 33717349
Thanks all for all the comments and help.

Featured Post

Office 365 Training for Admins - 7 Day Trial

Learn how to provision tenants, synchronize on-premise Active Directory, implement Single Sign-On, customize Office deployment, and protect your organization with eDiscovery and DLP policies.  Only from Platform Scholar.

Question has a verified solution.

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

A company’s centralized system that manages user data, security, and distributed resources is often a focus of criminal attention. Active Directory (AD) is no exception. In truth, it’s even more likely to be targeted due to the number of companies …
Auditing domain password hashes is a commonly overlooked but critical requirement to ensuring secure passwords practices are followed. Methods exist to extract hashes directly for a live domain however this article describes a process to extract u…
This tutorial will walk an individual through the steps necessary to join and promote the first Windows Server 2012 domain controller into an Active Directory environment running on Windows Server 2008. Determine the location of the FSMO roles by lo…
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 from a Windows Server 2008 domain controller to a Windows Server 2012 domain controlle…

724 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