How to do exceptions in Group Policy?
We're implementing Group Policy for the first time at our organization and have some questions about best practices and capabilities. We've already done some work and want to see if there is a better way.
Our Current Setup
We have Security Filtering set up as follows:
EXCEPT Firewall AllowFilePrintSharing
Group: Firewall AllowFilePrintSharing PCs
EXCEPT Firewall AllowRDP
Group: EXCEPT Firewall AllowRDP PCs
EXCEPT Firewall Unmanaged
Group: EXCEPT Firewall Unmanaged PCs
Workstations Policy
Authenticated Users
Folder Redirection
Group: Folder Redirection PCs
Authenticated Users
Proxy Disabled
Group: Proxy Disabled PCs
Authenticated Users
Loopback Policy Processing - Replace
Authenticated Users
Our Goal
Have one OU for all end-user PCs that has a default policy, then be able to have exception policies that override some of the default policies by adding PCs to a AD group elsewhere. Leave the users under their Users OU.
It would basically be above, except link all the GPs and PCs to Workstations and remove the two inner OUs.
Example
Workstations OU has 100 PCs 10 of which should have Folder Redirection enabled. Identify these 10 PCs and add them to an AD group called "Folder Redirection PCs". Any users who log on to these 10 workstations would have Folder Redirection enabled.
What We've Tried
We tried adding all the PCs to the Workstations OU and structured the groups as described in the Our Goal section. Because Folder Redirection (and the Proxy Disabled) settings are User policies we can't get them to apply to the PC. We got it to work but only if we add the user to the policy's security filter in addition to the AD group. Since we want any user who logs into these PCs to be folder redirected we would have to assign it to "Authenticated Users", which would then apply it to all PCs in this OU.
Loopback Policy Processing
We've tried this in many configurations and can't get it to function how we believe it is intended. Our understanding is that we should be able to have User settings linked to Workstations along with Computer settings. If Loopback Policy Processing is enabled then it should run through all the computer policies, all the user policies, then all the user policies that are assigned to those computers either in Replace or Merge mode.
Questions
- Is there a better a better way to do what we're trying to accomplish?
- 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)?
- 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.
- Are there any tools other than GPRESULT/RSOP that are good for troubleshooting this type of thing?
- 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.
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.