When you use the Group Policy Object Editor or the GPMC to work with GPOs, by default the corresponding changes are made on the domain controller that is acting as the primary domain controller (PDC) emulator. In this way, the PDC emulator is the central point of contact for GPO creation, modification, and deletion. Active Directory manages policy settings in this way to ensure that changes to the GPO structure can be implemented only on a single authoritative domain controller and that only one administrator at a time is granted access to a particular GPO. Because the PDC emulator role is specified at the domain level, there is only one PDC emulator in a domain and therefore only one place where policy settings are changed by default. If the PDC emulator is unavailable when you are trying to work with policy settings, you get a prompt that enables you to work with policy settings on the domain controller to which you are connected or on any available domain controller.

Any user who is a member of the Domain Admins or Enterprise Admins group can view and work with Active Directory–based Group Policy. Unlike Local Group Policy, which uses one LGPO per machine, Active Directory–based Group Policy can use multiple GPOs per site, domain, or organizational unit (OU). With Active Directory–based Group Policy, GPO creation and linking are separate operations. First you create a GPO and define a group of policy settings to achieve desired results. Then you apply your GPO and make it "live" by linking it to the container or containers within Active Directory where it will be applied.

Although creating and linking GPOs are two distinct operations, the Group Policy management tools do allow you to create GPOs and simultaneously link them to a level within the directory. This means you have two options for creating and linking GPOs:

Remember that it is the link that tells Active Directory to apply the settings specified by the GPO. For example, you can create a GPO called Main ADATUM.COM Domain Policy and then link it to the domain container for cpandl.com. To understand what settings will be applied when and to which users and computers throughout a domain, you need a strong understanding of inheritance and policy processing. According to the default (standard) inheritance and policy processing rules, once you link a GPO to a container, the related policy settings are applied to that container, and lower-level containers within the directory can also inherit the settings. This means that a linked GPO can affect every user and computer throughout the enterprise—or some subset of users and computers throughout the enterprise.

When GPOs are applied to users and computers, their effects are cumulative. These cumulative effects (the end result of inheritance and processing) on an individual computer or user are referred to as the Resultant Set of Policy (RSoP). When you work with Group Policy, you often must determine the RSoP for a particular user or group in order to troubleshoot and resolve problems. The GPMC also lets you be proactive by modeling the effects of GPOs before you deploy them. You can then determine the RSoP on a particular computer or user before deciding whether to deploy a specific GPO. For more information on modeling GPOs, see the section in Chapter 3 titled "Modeling and Maintaining Group Policy."

Within Active Directory, objects are organized using a hierarchical tree structure called a directory tree. The structure of the tree is derived from the schema and is used to define the parent-child relationships of objects stored in the directory. Figure 2-1 shows a representation of a directory tree for a domain. The domain object is the parent object of all objects in a domain; as such, it is at the root of the directory tree. The domain object in turn contains other objects, including other container objects such as subdomains or OUs and standard objects such as users, computers, and printers. In the figure, us.adatum.com is a subdomain of adatum.com, and this subdomain has two top-level OUs: Sales and Services.

Figure 2-1. The adatum.com domain and its related directory tree

Active Directory uses Lightweight Directory Access Protocol (LDAP) for querying and managing objects in the directory. You can locate any object in the directory according to its LDAP path. The LDAP path to the Sales OU in the us.adatum.com domain is LDAP://OU=Sales,DC=us,DC=Adatum,DC=COM. Here LDAP:// specifies that you are using LDAP, and OU=Sales,DC=us,DC=Adatum,DC=COM is the exact location of the Sales OU in the directory. Each component of the object’s name is broken down into its component parts. (OU stands for organizational unit, and DC stands for domain component.) The exact path to an object, excluding the protocol designator, is the object’s Distinguished Name (DN).

Objects in the directory also have a relative name, referred to as the Relative Distinguished Name (RDN). The RDN includes only the name component of the object. For example, the RDN of the Sales OU is OU=Sales. Within the Sales OU, you might have a user, John, and a computer, JohnsPC. The RDN of these objects would be CN=John and CN=JohnsPC, respectively. (Here, CN stands for Common Name, and the DNs of these objects would be CN=John, OU=Sales,DC=us,DC=Adatum,DC=COM, and CN=JohnsPC,OU=Sales,DC=us,DC=Adatum,DC=COM, respectively.)

As you can see, the DN indicates an object’s place within the directory. Not only does the DN tell you the exact containers in which the object is stored, but it also tells you the relationship of those containers to each other. The relationship of container objects is extremely important when it comes to applying Group Policy. When you know where an object is in the directory tree and in which container object it resides, you can determine most of the GPOs that would be applied to the object (in most instances). For example, JohnsPC would be affected by the following GPOs (and in the following order):

Note

When you work with domains and OUs, it is important to remember that inheritance works differently within and between domains. Within a domain, top-level GPOs are inherited automatically by lower-level GPOs. The domain GPO is automatically inherited by OUs. The domain GPO and the GPO of a top-level OU are inherited by a second-level OU, and so on. Between domains, inheritance is not automatic, even for parent-to-child relationships. This means a child domain does not automatically inherit the GPO of the parent domain.

Caution

Microsoft recommends that you avoid assigning Group Policy objects across domains. If Group Policy is obtained from another domain, the processing of Group Policy objects slows the startup and logon processes. Inheritance to child domains is rarely enforced.

The directory path tells you about most of the containers that might have GPOs that will affect a user or computer, but not all of them. One important piece is missing, and it has to do with sites. Figure 2-2 shows a deeper view of the us.adatum.com domain and the objects within it. As you can see, this domain has two sites associated with it:

Figure 2-2. An example of objects within the us.adatum.com domain

Based on this diagram, you know exactly which objects are stored in the directory and in which containers. You also know which sites are associated with which objects, and this gives you the complete picture of which GPOs will be applied to which objects. Additionally, for this example and the examples that follow, there is no forced inheritance from the parent domain adatum.com to the child domain us.adatum.com. Since you know that computers and users are also affected by a local machine GPO (the LGPO), you now know that JohnsPC would be affected by the following GPOs (and in the following order):

The user, John, would also be affected by the same GPOs, which would be applied in the same order to set permitted actions and limitations on his account.

As you’ve seen, you can determine the complete picture for the accumulated set of GPOs that would be applied to any user or computer object in a domain by following the directory tree to see which domains, OUs, and sites (if any) would be applied and thereby determine the RSoP for a user or computer. Going back to the previous example and excluding the LGPO, you can determine that the GPOs have the following effects on computers and users:

Another way to express this is to say that the RSoP for these objects is as follows (excluding LGPOs):

When you look at RSoP, it’s also important to consider what will happen if you move the furniture around a bit—for example, if Beth visits the Seattle office and logs on to JohnsPC or if Ed from Support goes to New York and logs on to MikesPC. Here is what happens with regard to Group Policy: