Читать книгу Group Policy - Jeremy Moskowitz - Страница 14

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 Resources OU. And that’s great. But they’re only affected by California site-level GPOs if they travel to California. It doesn’t matter where they usually reside; again, they’re only affected by the site-level GPOs when they’re physically present in that site. So if they travel to California, they will get the GPOs related to California first; then other GPOs (described later) will apply.

So, don’t think that user accounts reside at the site level. Rather, they reside in the OU level but are using computers in the site and, hence, get the properties assigned to all users at that site.

Sites are defined using the Active Directory Sites and Services tool. IP subnets that constitute a site are assigned using this tool. That way, if a new computer turns on in Delaware, Active Directory knows what site the computer is in.

At the Domain Level

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

At the OU Level

At the organizational unit level, we have the following:

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-6 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:

At no time are any domain GPOs from the Example.com parent domain automatically inherited by the Widget.example.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, unless you explicitly link one of those parent GPOs to a child Domain Container.

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 Chapter 2 in the section “Basic Interdomain Copy and Import”).

● Use a third-party tool that can perform some magic and automatically perform the copying between domains for you.

● Do a generally recognized no-no called cross-domain policy linking. (I’ll describe this no-no in detail in Chapter 7 in the section “Group Policy Objects from a Domain Perspective.”)

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. Indeed, without getting too geeky here, sites technically belong to the forest and not any particular domain.

At this point, we’ll put our example Example.com behind us. That was an on-paper exercise to allow you to get a feel for what’s possible in Group Policy–land. From this point forward, you’ll be doing most items in your test lab and following along.