Group Policy. Jeremy Moskowitz

the Group Policy Object Exists column in the Users tab, you can also tell whether or not a local GPO layer is being used.

      6. At the “Select Group Policy Object” dialog box, click Finish.

      7. At the “Add or Remove Snap-ins” dialog box, click OK.

You should now be able to edit that layer of the local GPO. For instance, Figure 1-5 shows that I’ve chosen to edit the Non-Administrators portion of the GPO (which is on level 2).

Figure 1-5: Below the words Console Root, you can see which layer of the local GPO you’re specifically editing.

      To edit additional or other layers of the local GPO, repeat the previous steps.

      Here’s an important point that bears repeating: Layers 2 and 3 of the MLGPO cannot contain overriding computer settings from Layer 1. That’s why in Figure 1-5 you simply don’t see them – they’re not there. If you want to introduce a Computer-side setting that affects everyone on the machine, just fire up GPEDIT.MSC and you’ll be off and running. That’s Layer 1, and it affects everyone.

      Final Thoughts on Local GPOs

      You can think of Local Group Policy as a way to perform desktop management in a decentralized way. That is, you’re still running around, more or less, from machine to machine where you want to set the Local Group Policy.

      The other strategy is a centralized approach. Centralized Group Policy administration works only in conjunction with Active Directory and is the main focus of this book.

      For more information, check out the article “Step-by-Step Guide to Managing Multiple Local Group Policy” from Microsoft. At last check, the URL was http://tinyurl.com/oqgl8at. The steps should work for all versions of Windows starting with Vista.

      In case you’re curious, Local Group Policy is stored in the %windir%\system32\grouppolicy directory (usually C:\windows\system32\grouppolicy). The structure found here mirrors what you’ll see later in Chapter 7 when we inspect the ins and outs of how Group Policy applies from Active Directory. Windows Vista and later store Level 2 (Admin/Non-Admin Local Policies) and specific Local User Policies (Level 3) inside %windir%\system32\grouppolicyusers.

      You will notice one folder per user policy you have created, each named with the Security ID (SID) of the relevant user object.

      An Example of Group Policy Application

      At this point, it’s best not to jump directly into adding, deleting, or modifying our own GPOs. Right now, it’s better to understand how Group Policy works “on paper.” This is especially true if you’re new to the concept of Group Policy, but perhaps also if Group Policy has been deployed by other administrators in your Active Directory.

      By walking through a fictitious organization that has deployed GPOs at multiple levels, you’ll be able to better understand how and why policy settings are applied by the deployment of GPOs.

Let’s start by taking a look at Figure 1-6, the organization for our fictitious example company, Example.com.

      This picture could easily tell a thousand words. For the sake of brevity, I’ve kept it down to around 200. There are two domains: Example.com and Widgets.example.com. Let’s talk about Example.com:

      ● The domain Example.com has two Domain Controllers. One DC, named EXAMPLEDC1, is physically located in the California site. Example.com’s other Domain Controller, EXAMPLEDC2, is physically located in the Phoenix site.

      ● As for PCs, they need to physically reside somewhere. SallysPC is in the California site; BrettsPC and AdamsPC are in the Delaware site. JoesPC is in the Phoenix site. FredsPC is in the California site, and MarksPC is in the New York site.

      ● User accounts may or may not be in OUs. Dave’s and Jane’s account are in the Human Resources OU.

      ● Computer accounts may or may not be in OUs. FredsPC is in the Human Resources OU. AdamsPC is specifically placed within the High Security OU. And that High Security OU is actually within the Human Resources OU (also known as a sub-OU.). JoesPC, SallysPC, BrettsPC, and MarksPC are hanging out in a container and aren’t in any OUs.

      Using Active Directory Sites and Services, you can put in place a schedule to regulate communication between EXAMPLEDC1 located in California and EXAMPLEDC2 located in Phoenix. That way, the administrator controls the chatter between the two Example.com Domain Controllers, and it is not at the whim of the operating system.

Figure 1-6: This fictitious Example.com is relatively simple. Your environment may be more complex.

      Another domain, called Widgets.example.com, has an implicit transitive two-way trust to Example.com. There is only one Domain Controller in the Widgets.example.com domain, named WIDDC1, and it physically resides at the Phoenix site. Last, there is MarksPC, a member of the Widgets.example.com domain, and it physically resides in the New York site and isn’t in any OU.

      Understanding where your users and machines are is half the battle. The other half is understanding which policy settings are expected to appear when they start logging onto Active Directory.

      Examining the Resultant Set of Policy

      As stated earlier, the effect of Group Policy is cumulative as GPOs are successively applied – starting at the local computer, then the site, the domain, and each nested OU. The end result of what affects a specific user or computer – after all Group Policy at all levels has been applied – is called the Resultant Set of Policy (RSoP). This is sometimes referred to as the RSoP calculation.

      Throughout your lifetime working with Group Policy, you will be asked to troubleshoot the RSoP of client machines.

      Many of our dealings with Group Policy will consist of trying to understand and troubleshoot the RSoP of a particular configuration. Getting a good, early understanding of how to perform manual RSoP calculations on paper is important because it’s a useful troubleshooting skill. In Chapters 3 and 7, we’ll also explore additional RSoP skills – with tools and additional manual troubleshooting.

      Before we jump in to try to discover what the RSoP might be for any specific machine, it’s often helpful to break out each of the strata – local computer, site, domain, and OU – and examine, at each level, what happens to the entities contained in them. I’ll then bring it all together to see how a specific computer or user reacts to the accumulation of GPOs. For these examples, assume that no local policy is set on any of the computers; the goal is to get a better feeling of how Group Policy flows, not necessarily what the specific end state will be.

      At the Site Level

      Based on what we know from Figure 1-6, the GPOs in effect at the site level are shown here:

      If we look at the graphic again, it looks like Dave, for instance, resides in California and Jane, for instance, resides in Delaware. But I don’t like to think about it like that. I prefer to say that their accounts reside in OUs.

      But users are affected by site GPOs only when they log onto computers that are at a specific site.

      In Figure 1-6, we have Dave’s and Jane’s accounts in the Human