Examining the Resultant Set of Policy

As stated earlier, the effect of Group Policy is cumulative as GPOs are successively appliedstarting at the local computer, the site, the domain, and each nested OU. The end result of what affects a specific user or computerafter all Group Policy at all levels has been appliedis called the Resultant Set of Policy , or 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.

Tip 

Much of our dealings with Group Policy will be trying to understand and troubleshoot the RSoP of a particular configuration. Getting a good understanding early of how to perform manual RSoP Calculations on paper will be a useful troubleshooting skill. In Chapter 3 and Chapter 4, we'll also explore additional RSoP skillswith 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 stratalocal 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.2, the GPOs in effect at the site level are as follows :

Site	Computers Affected
California	SallysPC, CORPDC1, and FredsPC
Phoenix	CORPDC2, JoesPC, and WIDDC1
New York	MarksPC
Delaware	AdamsPC and BrettsPC

Note 

Users are affected by site GPOs only when they log on to computers that are at a specific site. In Figure 1.2, we have users Dave in California (on a California PC) and Jane in Delaware (on a Delaware PC).

At the Domain Level

Here's what we have working at the domain level:

Domain	Computers/Users Affected
Corp.com Computers	SallysPC, FredsPC, AdamsPC, BrettsPC, JoesPC, CORPDC1, and CORPDC2
Corp.com Users	Dave and Jane
Widgets.corp.com Computers	WIDDC1 and MarksPC

At the OU Level

At the organizational unit level, we have the following:

Organizational Unit	Computers/Users Affected
Human Resources OU Computers	FredsPC is in the Human Resources OU; therefore it is affected when the Human Resources OU gets GPOs applied. Additionally, the High Security OU is contained inside the Human Resources OU. Therefore, AdamsPC, which is in the High Security OU, is also affected whenever the Human Resources OU is affected.
Human Resources OU Users	The accounts of Dave and Jane are affected when the Human Resources OU has GPOs applied.

Bringing it All Together

Now that you've broken out all the levels and seen what is being applied to them, you can start to calculate what the devil is happening on any specific user and computer combination. Looking at Figure 1.2 and analyzing what's happening at each level makes adding things together between the local, site, domain, and organizational unit GPOs a lot easier.

Here are some examples of RSoP for specific Users and Computers in our fictitious environment:

FredsPC	FredsPC inherits the RSoP of the GPOs from the California site, then the Corp.com domain, and then, last, the Human Resources OU.
MarksPC	MarksPC first accepts the GPOs from the New York site and then the Widgets.corp.com domain. MarksPC is not in any OU; therefore, no organizational unit GPOs apply to his computer.
AdamsPC	AdamsPC is subject to the GPOs at the Delaware site, the Corp.Com domain, the Human Resources OU, and the High Security OU.
Dave using AdamsPC	AdamsPC is subject to the computer policies in the GPOs for the Delaware site, the Corp.com domain, the Human Resources OU, and finally the High Security OU. When Dave travels from California to Delaware to use Adam's workstation, his user GPOs are dictated from the Delaware site, the Corp.com domain, and the Human Resources OU.

Note 

At no time are any domain GPOs from the Corp.com parent domain automatically inherited by the Widget.corp.com child domain. Inheritance for GPOs only flows downward to OUs within a single domain not between any two domains parent to child or otherwise .

If you want one GPO to affect the users in more than one domain, you have four choices:

• Precisely re-create the GPOs in each domain with their own GPO.

• Copy the GPO from one domain to another domain (using the GPMC, as explained in the Appendix).

• Use a third-party tool that can perform some magic and automatically perform the copying between domains for you. (Check out www.GPanswers.com for a list of tools.)

• Do a generally recognized no-no called cross-domain policy linking . (I'll describe this no-no in detail in Chapter 3.)

Also, don't assume that linking a GPO at a site level necessarily guarantees the results to just one domain. In this example, as in real life, there is not necessarily a 1:1 correlation between sites and domains.