Is it possible to apply a group policy only to certain computers / groups of computers

Use an OU - there is no such thing as a network too small to use an OU. Apply the policies to the OU as you can't apply Group Policies to the default users and computers container.

If you want to use this setup, I would create a "Computer" OU, move all the regular computer accounts to that OU and apply the default comptuer OU there. Create a child OU "MgmtComputers" OU off the Computer OU and apply just the Management computer OU there.

Edit: BTW - if you are setting "domain users" as local administrators in your default computer policy and allowing "Log On Locally" to include the administrator group, since every domain user is a local admin, it would still allow every user to login to every computer.

Is there a better a better way to do what we're trying to accomplish?

Using security group filtering to exempt computers from various computer policies makes sense and I think you're going about it the right way.

I'm not sure that I'm 100% clear on what you're actually trying to accomplish when it comes to the Folder Redirection settings. What's the end business goal? Are these special Folder Redirection computers configured such that users can freely move between them? What is the expected user experience when using a to a computer w/o Folder Redirection applied after they've used one that does (and they can't find their files)? I'm not sure you've completely thought that part through.

It seems like you have an aversion to applying Group Policy to user objects. I'd be curious to know the reason. "Folder Redirection" being applied only when users logon to certain computers is a bit unconventional. Speaking more generally, Loopback Processing of Group Policy isn't the norm, though I'll admit that I use it pretty frequently. Diving in w/ Loopback Processing right out of the gate is a bold move, from a learning perspective.

To speak about Folder Redirection in particular, I generally find that Folder Redirection works best when it's applied as the default across the organization. Along with Roaming User Profiles it can make client computers virtually "stateless" when it comes to user data. I usually want nearly every user to be able to go to nearly any computer, logon, and have access to their files and user settings.

That's not to say that there aren't computers that I might use Loopback Processing to "exempt" from Folder Redirection (and that I might force local profiles only on), but these would be the minority and the exception, not the default. (Kiosk computers and dedicated single-task computers, for example.)

I also have scenarios where I need to exempt users from Folder Redirection (contractors, task-oriented users, etc) and, since I apply Folder Redirection policy to users almost exclusively, this just ends up being either an OU hierarchy where the "No Folder Redirection" users are located, or a security group filtering to exempt users from Folder Redirection.

Do most organizations keep all workstations in a single OU (like we're trying to do), or do they split it out (like we have implemented)?

I've seen both, in practice, but I find the "let's pile all the computers in a single OU" to be unwieldy, often resulting in excessive use of filtering of Group Policy application by security group membership. I've never done that, personally. If nothing else, I'll still break out client computers into OUs that describe their physical location just to make things easier to find.

Your OU hierarchy should be designed, first, for delegation of administrative control of the Active Directory objects. It is often the case that companies will have no delineation of administrative control of client computer objects. Remember, I'm not talking about "local Admin rights" on the computers, rather just administrative control to manage the computer objects in the AD.

After satisfying your delegation of control needs, the second design decision for an OU hierarchy should relate to application of Group Policy. I prefer to use OUs, whenever possible, to control application of Group Policy because it eliminates the need for security group filtering (and, in so doing, eliminates the possibility of forgetting to populate a computer's security group membership). There may be GPOs that need to apply to a "scattershot" distribution of computers in an OU hierarchy, and that is the best place to use security group filtering.

Do the type of exceptions we want to make even make sense? The Firewall ones work fine since they're Computer policies, but that system breaks down when we want to apply user policies to all users who log on to these PCs.

Your understanding of Loopback Processing seems to be correct, based on the articulation in the last sentence of your paragraph on the subject. To be clear about it: Loopback Processing can work just fine. I use it fairly extensively at a couple of Customer sites for nearly all their computers.

What you're trying to do w/ selectively applying Folder Redirection can be done, but I'll caution that Folder Redirection doesn't necessarily act the same as a setting applied to the user's registry from an Administrative Template. Without seeing all the particulars of your AD it's difficult for me to say why you're not seeing the results you expect. As an example: If a user had a Roaming User Profile configured and logged-on to a computer with Loopback Processing such that Folder Redirection applied to that user's profile the Folder Redirection settings would "stick" to their profile and "follow" them even to a computer that did not have Folder Redirection being applied via Loopback Processing.

Are there any tools other than GPRESULT/RSOP that are good for troubleshooting this type of thing?

I find those tools useful, to be sure. Occasionally, if I feel I'm having trouble with an individual Group Policy Client Side Extension (CSE) I might enable debugging output (either using the GPSvcDebugLevel setting in Windows 7, or the UserEnvDebugLevel or RunDiagnosticLoggingGlobal settings on Windows XP).

Mainly, I think it's important to be able to conceptualize the Group Policy application process in your mind. I think that the "modeling" and planning functionality in Group Policy Management Console is a crutch to prop-up sysadmins who are too lazy to just learn how the product makes policy application decisions.

The algorithm for determining Group Policy application for a given Computer or User object (which I'm calling the "subject") is as follows:

• Start at the top of the domain and look for any linked Group Policy objects. Don't worry about Security Group or WMI filtering yet-- just locate all the GPOs linked at the top of the domain. Annotate them, in the order they're linked, at the bottom of a list titled "Non-Enforced GPOs". If you find a GPO linked with the "Enforced" (or, in olden days, "No Override") option set, add it to the bottom of a second list titled "Enforced GPOs" rather than the "Non-Enforced GPOs" list. Always add the GPOs to the lists in the order they are linked at each OU (the order they're linked matters).

• Move down the OU hierarchy toward the OU where subject resides. At each OU, find any linked GPOs and add them to one of your lists (either "Non-Enforced GPOs" or "Enforced GPOs") just like you did at the top of the domain. If you find an OU with the "Block Inheritance" option set erase everything on your "Non-Enforced" list before adding the GPOs linked at that OU to your lists. "Block Inheritance" doesn't effect the "Enforced" list, though.

• As you move down through the OUs you could, potentially, find the same GPO linked multiple times. That's fine. Add it to the bottom of the appropriate list in the order you find it, even if it's already on the list.

Here's where it's important to understand the mechanics behind Loopback Processing. All Loopback Processing being enabled does is cause a change to the algorithm that builds the lists of GPOs to apply.

When Loopback Processing is enabled in "Replace" mode you just treat the OU where the computer being logged-on to resides as though it was the location of user logging-on and build the lists of GPOs accordingly. When it's in "Merge" mode you build the lists for the user in their own OU first, then start again at the top of the domain and, adding to the already-built lists, add GPOs that are linked at the top of the domain and moving down each OU in the hierarchy toward the computer object.

The lists you've made, after you reach the OU where the subject is located, are the lists of GPOs that can apply to the subject. The order they are applied is top-to-bottom of the "Non-Enforced GPOs" list first, followed by the "Enforced GPOs" list, as detailed below.

You can calculate the Resultant Set of Policy from those lists using this procedure:

• Staring with the with the first GPO in the "Non-Enforced GPOs" list examine its permissions and WMI filtering settings to determine if it can be applied to the subject. When you're calculating RSoP for a computer consider the computer's group memberships to determine security filtering eligibility. When you're calculating RSoP for a user consider the user's group memberships. When calculating user RSoP in Loopback Processing mode only the user's group memberships apply to security filter (that is, computer group membership has NO effect on the RSoP for users logging-on when Loopback Processing is enabled).

• If the GPO can be applied, based on security group filtering and WMI filtering, annotate the settings it applies in a new list titled "Resultant Set of Policy". (Obviously, if you're building RSoP for a computer only look at the computer portions of the GPOs for settings, and the user sections for users.)

• As you move down your lists of GPOs if a lower-down GPO alters a setting that's already been placed on your "Resultant Set of Policy" list, scratch out the setting that's already there and replace it with the setting from the GPO lower in the list. This is how GPOs "overide" each other-- the settings simply apply over the already-applied settings. It's nothing special.

• Don't do anything special if you find the same GPO linked multiple times in your lists. Just apply the same logic to it. The fact that it's linked multiple is irrelevant when it comes to this algorithm.

• After you've moved through all the "Non-Enforced GPOs" entries do the same thing with the "Enforced GPOs" list, starting at the top of the list and applying the settings from each GPO in the list to the same "Resultant Set of Policy" list that you already applied the "Non-Enforced GPOs" settings to. By doing the "Enforced GPOs" list last you're making their settings carry more "weight" than the "Non-Enforced GPOs". There's nothing really special about "Enforced", behind the scenes. The setting just makes the "Enforced" GPO apply later in the process.

There is one special exception to the algorithm above: Domain Controller computers only recognize the "Computer Configuration / Windows Settings / Security Settings / Account Policies" settings that come from OUs linked at the top level of the domain. These GPOs create the Password and Account Policy for the domain. (These settings can be further overridden with Fine Grained Password Policies, but that's beyond the scope of this discussion.) Any settings in the "Computer Configuration / Windows Settings / Security Settings / Account Policies" section of GPOs linked to OUs lower than the top level of the domain are ignored by Domain Controller computers.

That's it. That's the Group Policy application algorithm. (It's implemented slightly differently in the product but this method is functionally equivalent.) There's nothing much to it, really.

I taught certification classes from the "Microsoft Official Curriculum" at a community college for a number of years. I found that once students understood this algorithm the "light would turn on" and the number of questions I got about "Why is this policy not applying?" dropped-off to nearly nil.

Can anyone recommend any videos/blogs/experts to look up to learn more about GP best practices? Does Microsoft have this documentation somewhere? It seems to be hard to find.

In terms of Active Directory design, documentation targeted at Windows 2000 Server and Windows Server 2003 is still perfectly valid. The basic functionality and factors that impact design decisions for an Active Directory structure are the same today as they were when AD was released.

Likewise, Group Policy hasn't changed dramatically. Yes, the specific settings that Group Policy can influence have changed, but the rules that govern the application process are the same, though some things had their names changed ("No Override" became "Enforced", for example) and and features were added (like WMI filtering). All the basic concepts are still valid.

Most Group Policy documentation and reference websites I've seen seem to get mired down in "Oh, gee-whiz look at all these exciting settings you can apply" goggling and treats learning about the application process as some afterthought that you just use GPMC modeling to handle. That's backwards thinking, to me. Once you understand how the GPOs are actually applied you can dig into the settings. (Learn how to start the car first before figuring out how the sound system and power windows work. Sure-- the convertible top is flashy, but it won't work if you can't start the car.)

Here are some Microsoft resources relating to Active Directory design that I think are reasonable:

• Group Policy Planning and Deployment Guide

• Designing a Group Policy Infrastructure

• Designing the Active Directory Logical Structure - Not directly related to Group Policy but a nice discussion of Active Directory design

• Designing OU Structures that Work

Reference material aside, I think it's very important to do experimentation and testing, both to get familiar with the feature-set of the product and to validate your design.

Provided that you're working with a set of isolated OUs and "throwaway" user and computer objects you can "play" with Group Policy in your production domains with impunity (at least for client computers-- for servers and, especially Domain Controllers, you might be better off playing in a test environment). You can simulate the top of the domain w/ a "Block Inheritance" OU, if need be, and build up an entire simulated environment under it. (You would have to make a simulation Site object, too, if you needed to simulate Site-level Group Policy... hardly anybody, other than me it seems, appears to use that, though.)

Aside: Zow-- after nearly 5 years of using Server Fault I finally have time and the occasion to write down my GPO processing lecture from my old community college class. So, let's see here-- I've written the IPv4 subnetting article from my old lecture notes, I've hit 100K, and I'm closing-in on that "Legendary" badge.

My mission here is nearly complete.