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


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 ?
Who is Participating?
Joseph MoodyConnect With a Mentor Blogger and wearer of all hats.Commented:
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.
Mike KlineConnect With a Mentor Commented:
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.
spiraldavAuthor Commented:
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.
Creating Active Directory Users from a Text File

If your organization has a need to mass-create AD user accounts, watch this video to see how its done without the need for scripting or other unnecessary complexities.

Adam BrownConnect With a Mentor Sr Solutions ArchitectCommented:
"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.
spiraldavAuthor Commented:
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.
Joseph MoodyBlogger and wearer of all hats.Commented:
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.
Adam BrownSr Solutions ArchitectCommented:
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.
Ben Personick (Previously QCubed)Lead Network EngineerCommented:
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.
Adam BrownSr Solutions ArchitectCommented:
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.
spiraldavAuthor Commented:
Thanks all for all the comments and help.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.