Group Policy, Profiles, and IntelliMirror for Windows2003, WindowsXP, and Windows 2000 (Mark Minasi Windows Administrator Library)
| | ||
| | ||
| | ||
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.
| | ||
| | ||
| | ||