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

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.
Dav

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.
Davin

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.

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.

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.

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.

Thanks all for all the comments and help.