Active Directory replicationUnderstanding Active Directory replication

Active Directory replication is key to the health and stability of an Active Directory environment. Without proper and timely replication, a domain will be unable to function effectively. Replication is the process of sending update information for data that has changed in the directory to other domain controllers. It is important to have a firm understanding of replication and how it takes place, both within the domain and in multiple-site environments.

There are three main elements or components that are replicated between domain controllers: the domain partition replica, the global catalog and the schema.

The domain partition replica is the Active Directory database of a domain. Each domain controller maintains a duplicate copy of its local domain partition replica. Domain controllers do not maintain copies of replicas from other domains. When an administrator makes a change to the domain, that change is replicated to all domain controllers immediately.

Each forest contains only a single global catalog. By default, the first domain controller installed into a forest is the global catalog server. The global catalog contains a partial replica of every object within each domain of the forest. The global catalog serves as a master index for the forest, which allows for easy and efficient searching for users, computers, resources and other objects. Any domain controller can be configured to act as a peer global catalog server. You should have at least two global catalog servers per domain and at least one per site. As changes are made to objects within the forest, the global catalog is updated. Once the global catalog is changed on one domain controller, it is replicated to all other domain controllers in the forest.

Every domain controller in a forest has a copy of the schema. Just as with changes to the Active Directory database (i.e., domain partition replica), any changes to the Active Directory schema are replicated to all other domain controllers in the forest. Fortunately, the schema is usually static so there is little replication traffic caused by schema changes.

Multi-master replication

Within Windows-based Active Directory domains, each domain controller is a peer server. Each domain controller has equal power and responsibility to support and maintain the Active Directory database. It is this database that is essential to the well-being and existence of the domain itself. This is such an important task that Microsoft elected to make it possible to deploy multi-redundant systems to support Active Directory by making each domain controller a peer.

Whenever a change occurs to any object within an Active Directory domain, that change is replicated automatically to all domain controllers within the domain. This process is calledmulti-master replication. Multi-master replication does not happen instantly across all servers

simultaneously. Rather, it is a controlled process where each domain controller peer is updated and validated in a logically controlled procedure.

As an administrator, you have some control over how multi-master replication occurs. Most of your control is obtained through the use of sites. A site is a logical designation of domain controllers in a network that are all located within a defined physical area. In most cases, sites control traffic over high-expense low-bandwidth WAN links. When a domain exists on two or more sites, normal Active Directory replication between the domain controllers in different sites is terminated. Instead, a single server within each site, labeled as a bridgehead server, performs all replication communications. You can configure this bridgehead server for when replication is allowed to occur and how much traffic it can generate when performing replication.

You can use sites to control replication even if you do not employ WAN links on your network. Sites effectively give administrators control over how and when AD multi-master replication occurs within their network.

Active Directory replication topology design

One of the secrets to an efficient and error-free Active Directory infrastructure is a well-designed replication topology. While this can be easy to design in a simple network, a large, complex network presents a challenge. Designing the AD topology efficiently is to construct it so that it takes advantage of the strengths and minimizes the weaknesses of the network. In a complex network, you are likely to have a number of different link speeds connecting remote sites.

The best practices for Active Directory replication design include:

1. Design the AD topology to take advantage of the network topology and link speeds.2. Define lower speed links with higher cost site links. The cost of the links reduces as you get

to faster areas in the topology.3. Avoid "dead spots" -- all sites must connect to each other eventually. I have seen some

topologies that left certain sites isolated because they didn't design the site links to connect them.

4. Site links should only have two sites per link. The exception to this is the Core site link which can have more. Defining more than two sites per link can result in unpredictable results when a DC failure occurs.

5. Diagram the overall flow of replication (like the figures here). You can use sophisticated features available in tools like HP OpenView (see the example in Figure 3) or Microsoft MOM, or you can simply draw it in a PowerPoint slide as I did in Figure 2. You'd be surprised at how many errors you will find by making a drawing of the topology.

6. Don't define scheduling unless you really have a good reason, and then you should test it thoroughly. Since you can schedule replication over the site link as well as the connection object itself, and since the resultant replication schedule is a merge of the two, you can end up with a schedule that prohibits replication. You also define replication frequency, which further complicates it. For instance, if you schedule the site links to replicate Monday through Friday from 8 a.m. to 6 p.m., and then have some connection objects that only replicate Tuesday and Thursday from 6 p.m. to 10 p.m., those connection objects will never replicate. Unless you have a very slow or limited network (such as VPN links), you should avoid this level of manual intervention.

7. Run the AD in Windows 2003 Forest mode. This means all DCs are at Windows Server 2003, and all domains are running in Windows 2003 mode. This takes advantage of the new spanning tree and compression algorithms available in Windows Server 2003, as well as other features that make replication much more efficient than were available in Windows 2000.

8. Monitor the AD. Once you get it in place, monitor it. One of the easiest ways to monitor it, outside of using Microsoft or third-party tools, is using the Repadmin tool and its "Replsum" option: Repadmin /replsum /bydest /bysrc /sort:delta. This will provide a nice, neat table of all DCs in all domains in the forest, telling you how long it has been for outbound and inbound replication (i.e. where each DC appears as a source and destination). Watching this over several days will give you a chance to find any holes in the topology.

Troubleshooting Active Directory replication

Replication should occur automatically. When it doesn't, the best solution isn't just to force Active Directory replication, but to check out the topology. If the replication topology has become unstable or misconfigured, it needs to be corrected before initiating a manual replication procedure.

The Knowledge Consistency Checker (KCC) creates the replication topology used for intra-site replication automatically. Rather than creating a full mesh for replication, the KCC designs a topology where every DC has at least two replication partners and is no more than three hops away from any other DC. With such a topology, every DC can be fully updated with as little as three replication cycles.

The REPAdmin tool from the Windows Support Tools and Resource Kit can be used to check the topology. The command "repadmin /showreps" runs on a domain controller and produces a list of replication partners as designated by the KCC. To check the topology, verify that every DC lists at least two replication partners and that all named partners see each other as partners. For example, if Server A lists Server B and C as partners, then both Server B and C should list

Server A in return as a partner. If you discover a problem or inconsistency in the topology, use the KCC to regenerate the topology.

Once you are sure the topology is correct, then and only then should you force Active Directory replication.

Debugging replication errors

The lion's share of Active Directory problems are to some degree caused by replication failures, and one of the most notorious replication errors is the Event ID 1311.

The first step in resolving this replication error is to determine the scope of the error. The easiest way to do this is with the Repadmin/Replsum command. This will give you a complete summary of all the DCs in the forest, including the relevant event ID if it is in an error state. The general form of the command is this:

Repadmin /Replsum /bysrc /bydest /sort:delta

Here is a sample output of this command. Note that there are four domain controllers failing replication. While the 1311 may not show up in the output of this command, it is common for it to be paired up with the 1722 event (which basically means no physical connectivity). Obviously, if there is no physical connectivity (which would mean there was a network failure), replication isn't going to happen. The first thing to do is to check the general health of the domain using the Repadmin /replsum command just described. You can also ping broken DCs by address and FQDN, and you can run NetDiag and DCDiag commands from the command line (with the /v switch on each). This will give you more details about the errors and perhaps related ones.

Note: The network connecting all the sites should be fully routed. Don't create a site link if there is no underlying network link to get between the sites in the site link.

Logical connectivity is a bit more difficult to diagnose. It means, bottom line, that something in the AD site topology configuration is wrong, creating a hole in the topology. This could be solved by one of the following actions: configuring a preferred bridgehead server, making sure all sites are defined in site links and making sure there is a complete mesh of sites in site links.

DNS also must be taken into account. Since Active Directory replication relies on DNS name resolution to find DCs to replicate with, if DNS is broken, it could cause the 1311 events to occur. The helpful thing here is that if DNS is the culprit, the 1311 event will have the phrase "DNS Lookup Failure" included in the description. If you see this phrase, then you absolutely, positively have a DNS problem that must be fixed.

When debugging 1311 events, you should get a scope of the entire forest to see which DCs are not replicating. You can do this easily using the Repadmin /Replsum command. Note that the

loss of physical connectivity, an incomplete AD site topology or DNS failure usually cause these events, with an outside chance it will be an orphaned object (an object that connot be found in the directory tree). Usually, other events will accompany them, such as the 1722 (RPC Server Unavailable), or the event will contain a descriptive statement such as "DNS Lookup Failure." This is a critical event that must be resolved in order for Active Directory replication to function properly to all DCs.

Understanding Active Directory replication

If you’ve worked much with Windows 2000, you know just how important Active Directory can be. Active Directory stores everything from network security information to basic contact information for network users. As with any database of such importance, Active Directory is subject to constant updates. Normally, rapid database updates aren’t a problem. What makes Active Directory updates so special is that unlike a conventional database, Active Directory isn’t stored in a single location. Instead, it’s distributed across all of your domain controllers. Therefore, Windows 2000 must be able to keep track of any database changes, regardless of which server the change was made on. The process by which Windows keeps track of these changes is called replication. In this Daily Drill Down, I’ll discuss the concepts involved in Active Directory replication.

The multimaster modelIf you’ve done much networking with Windows NT, you’re probably at least vaguely familiar with the concept of replication. As with Windows 2000, Windows NT offers the possibility of having multiple domain controllers in each domain. However, Windows NT uses a much simpler replication model than Windows 2000 uses. In Windows NT, any changes to the Security Accounts Manager (SAM) database can occur only on the primary domain controller. Therefore, when an administrator makes a change to an account, the change is always applied directly to the primary domain controller, regardless of how many domain controllers actually exist on the system.

Keep in mind that in Windows NT, each domain controller maintains a copy of the SAM database. This copy allows any domain controller to authenticate users. Because each domain controller contains an independent copy of the SAM database, the copy must be updated to match changes that occur to the primary domain controller’s copy.

To avoid overwhelming the backup domain controllers, which may already be busy with other tasks, the primary domain controller doesn’t automatically push the database modifications onto the backup domain controllers. Instead, the primary domain controller simply alerts each backup domain controller to the fact that a change has occurred. When the backup domain controllers have some idle time, they each contact the primary domain controller and request that the changes be

replicated to them.

Windows 2000, on the other hand, uses a much more complicated replication model calledmultimaster replication. In multimaster replication, any time an administrator makes a change to Active Directory, the change can be applied directly to any domain controller. Remember that in Windows 2000, there’s no such thing as a primary domain controller or a backup domain controller. Instead, a server is either a domain controller or a non-domain controller. As such, all domain controllers in Windows 2000 are treated equally.

Given the variety of types of information that Active Directory can store, it’s easy to see just how fast changes to Active Directory can accumulate across multiple domain controllers in a large organization. It’s therefore necessary for Windows to frequently synchronize the domain controllers through the replication process.

Windows 2000 accomplishes this task in a method similar to the one used by Windows NT, with the obvious exceptions I’ve already discussed. When an administrator makes a change that affects a domain controller’s copy of Active Directory, the domain controller sends a notice to the other domain controllers about the change. The other domain controllers may then request a copy of the changes when they have idle time. Because several domain controllers may be replicating changes at any given time, each Active Directory change is time-stamped. This allows Windows 2000 to know which change should take precedence in the event that contradictory changes are made within a replication cycle.

As you can imagine, the Active Directory replication process can cause considerable network traffic when large numbers of domain controllers exist within an organization. In a large organization, dozens of domain controllers could potentially be replicating hundreds of Active Directory changes at any given time. This can cause some serious congestion problems, especially on networks that are already bogged down with excessive traffic. Replication-related network traffic can also cause problems by bogging down wide area network (WAN) links. Fortunately, Windows 2000 provides an Active Directory structure that you can use to reduce the replication-related network traffic. This structure is called a site.

Intersite Active Directory replicationIf your background consists primarily of working on Windows NT Servers, the concept of sites may be new to you. You’re probably familiar with sites only if you’ve used Exchange Server. Even so, sites created by Exchange Server are somewhat different from sites created by Windows 2000.

So what’s a site? To put it simply, a site is a collection of domain controllers. Typically, these domain controllers service a common group of users. To understand why dividing a network into sites is effective, you must first understand something about the nature of Active Directory.

As you probably already know, Active Directory is divided into all sorts of structures, such as domains, trees, and forests. All of these structures fall under the organization’s root level. This means that every domain controller in every level of the organization must share Active Directory information to some extent.

For example, consider an organization that contains two domains. Even if those two domains have almost nothing to do with each other, they share a common Active Directory and must therefore replicate Active Directory updates between themselves on a regular basis.

Earlier I explained how the Active Directory replication process works. In that explanation, any Active Directory changes were replicated across the entire organization on an as-needed basis. If a change was made to a domain controller, the domain controller saw the need to replicate the change to every other domain controller in the entire organization just as soon as the other domain controllers became available.

Given the examples and explanations I’ve presented so far, you might assume that if two domains or other organizational structures don’t have anything to do with each other, then there’s really no need to replicate updates between them. Nothing could be further from the truth. Your domain controllers must replicate changes with one another to maintain Active Directory’s consistency and integrity. However, just because you have to replicate Active Directory updates between unrelated organizational structures, it doesn’t mean that the replication has to occur immediately. The advantage to creating sites is that you can replicate Active Directory changes between the sites on a scheduled basis rather than on an as-needed basis.

Scheduling replication can greatly reduce network traffic and can relieve a tremendous burden from WAN links. I mentioned earlier that sites were nothing more than a collection of domain controllers that serve a common group of users. The idea is that users within these groups need to know about Active Directory updates that are directly related to them more quickly than they would need to know about Active Directory updates that relate to a different office, department, or company.

Sites are very flexible. I mentioned that a site is a collection of domain controllers that serve a common group of users, so you may have assumed that a site exists at the same level as a domain. However, this simply isn’t true. You can have multiple sites within a single domain, or you can make each domain an individual site. Other than some general guidelines, no firm rules exist governing how sites should be implemented.

When should I implement sites?In spite of Windows 2000’s loose control over how you implement sites, some situations are much more appropriate for implementing sites than others. One situation in which you’d almost always want to implement a site would be the case of a domain spread across a WAN link. Suppose for a moment that you work for a company that has two local offices connected by a WAN link. Now imagine that the idiot who you inherited the network from got the bright idea to use a single domain to cover both buildings. You could greatly improve the network’s efficiency by setting up each building as an individual site.

The first step you’d take in such an arrangement would be to make sure that each building has at least one domain controller. Remember that sites require domain controllers. Even if you weren’t dividing the network into sites, it would still be a good idea to have at least one domain controller in each building so that users in each building could authenticate locally. After all, you don’t want to congest your WAN link with authentication traffic.

Now, consider the reason for and the results of separating the two buildings into individual sites. There’s a good chance that the users in each building work more closely with one another than they do with users in the other office. Therefore, an Active Directory change in building A would more likely affect the users in building A than the users in building B. Because of this, you’d want to make sure that Active Directory updates within each building continue to be replicated on an as-needed basis. You still have to replicate the changes over to the other building but doing so isn’t as time sensitive as replicating the update within the original building. Therefore, you can update the other building on a scheduled basis.

You can allow Active Directory updates to accumulate for several hours before replicating them to the other building. This means your WAN link will receive only the occasional burst of strategically timed replication traffic rather than the constant bombardment of traffic it would otherwise be subjected to.

I recommend timing the intersite replications to correspond with low periods of network traffic, such as during lunch or after people start going home for the day. Of course, if an important update is made to Active Directory, the administrator can always force an immediate replication.

Now, suppose your entire company shares a single building. It’s still possible (and often a good idea) to implement sites, even though no WAN link is present. You can create a separate site for each department. Doing so can drastically cut down on the replication-related network traffic in your organization.

How do sites work?Now that you know what a site is, let’s take a brief look at how sites work. As you’ve probably already figured out, the domain controllers that exist within a site continue to replicate with one another on an as-needed basis. Only one domain controller in each site is responsible for replicating changes with other sites, however. This domain controller is known as the bridgehead server.

Replication occurs on an as-needed basis among the domain controllers within each site. When it comes time for sites to replicate with one another, each site's bridgehead server forwards all of the changes that have occurred since the last replication cycle to the remote site's bridgehead server. When the bridgehead server in the remote site receives the changes, it replicates those changes to the other domain controllers within the site.

ConclusionIn this Daily Drill Down, I explained the process by which Active Directory changes are replicated between domain controllers. I also discussed why it’s sometimes necessary to reduce replication-related network traffic by dividing Active Directory into multiple sites.The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

What Is Group Policy Management Console?

2 out of 5 rated this helpful - Rate this topic

Updated: March 28, 2003

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

What Is Group Policy Management Console?

In this section

Group Policy Management Console Core Scenarios  

Group Policy Management Console Dependencies  

Related Topics  

The Group Policy Management Console (GPMC) is a new and comprehensive administrative tool for Group Policy management.

Prior to GPMC, administrators used property pages in various Active Directory administrative tools to manage Group Policy. For example, an administrator who wanted to implement policy for users might open the Active Directory Users and Computers snap-in, find an appropriate Organizational Unit (OU) and open its property page to access the Group Policy tab. On the Group Policy tab, the administrator might do any of a dozen or so administrative tasks, like creating Group Policy object links or manipulating their order to achieve the desired results. Whatever the tasks, when the administrator leaves the Group Policy tab, access to a visual representation of Group Policy ends and a view that focuses on Active Directory’s user and computer objects appears.

GPMC integrates the existing Group Policy functionality of the property pages on the Active Directory administrative tools into a single, unified console dedicated to Group Policy management tasks; GPMC also expands management capabilities with new features. Administrators still use Active Directory administrative tools to manage Active Directory, but GPMC replaces the Group Policy management functionality of those tools with its own.

Group Policy Management Console Core Scenarios

There are many core scenarios for GPMC. Administrators use GPMC to perform all Group Policy management tasks, with the exception of configuring individual policy settings in Group Policy Objects themselves, which is done with Group Policy Object Editor. The scenarios below describe how an administrator uses GPMC to manage Group Policy.

Creating and Editing GPOs

Administrators use GPMC to create a GPO with no initial settings. An administrator can also create a GPO and linking it to an Active Directory container at the same time. To configure individual settings within a GPO, an administrator edits the GPO from within GPMC and Group Policy Object Editor appears with the GPO loaded. An administrator can use either GPMC or Group Policy Object Editor to disable or enable computer, user, or both computer and user nodes within a GPO.

Scoping GPOs

An administrator can use GPMC to link GPOs to sites, domains, or OUs in the Active Directory. Administrators must link GPOs to apply settings to users and computers in Active Directory Containers. Linking GPOs is the primary mechanism by which administrators apply Group Policy settings.

In addition to linking, an administrator can manipulate permissions on GPOs to manage how Group Policy applies. Prior to GPMC, an administrator would have to manually manipulate access control entries (ACE) to modify the scope of the GPO. For example, the administrator might remove Read and Apply Group Policy from the Authenticated Users group for GPO1. This effectively disables GPO1, since users in the Authenticated Users group require both Read and Apply Group Policypermissions to process Group Policy. To apply the settings in GPO1 to select network users or computers, the administrator would add a new security principal (typically a security group containing the target users or computers) to the ACL on the GPO and set Read and Apply Group Policy permissions. This is known as security filtering.

With GPMC, security filtering has been simplified. The administrator adds the security principal to the GPO, and GPMC automatically sets the Read and Apply Group Policy permissions.

Administrators can also use GPMC to link WMI Filters to GPOs. WMI Filters allow an administrator to dynamically determine the scope of GPOs based on attributes (available through WMI) of the target computer. A WMI filter consists of one or more queries that are evaluated to be either true or false against the WMI repository of the target computer. The WMI filter is a separate object from the GPO in the directory.

Manipulating Inheritance

Group Policy can be applied to users and computers at the site, domain, or OU level. GPOs from parent containers are inherited by default. When multiple GPOs apply to these users and computers, the settings in the GPOs are aggregated. For most policy settings, the final value of a given policy setting is set only by the highest precedent GPO that contains that setting. (However, the final value for a few settings will actually be the combination of values across GPOs.)

Group Policy determines precedence of GPOs by the order of processing for the GPOs. GPOs processed last have highest precedence. GPOs follow the SDOU rule for processing; site first, then domain, and then followed by OU, including nested OUs. A nested OU is one that has another OU as its parent. In the case of nested OUs, GPOs associated with parent OUs are processed prior to GPOs associated with child OUs. In this processing order, sites are applied first but have the least precedence. OUs are processed last and have the highest precedence.

When a container has multiple GPO links, administrators can use GPMC to manipulate the link order for every container. GPMC assigns each link a Link Order number; the GPO link with Link Order of 1 has highest precedence on that container.

Administrators can use GPMC to Block Inheritance. This is the ability to prevent an OU or domain from inheriting GPOs from any of its parent container. Note that Enforced GPO links (see below) will always be inherited.

Administrators can use GPMC to set GPO links to Enforced (previously known as No Override). This is the ability to specify that a GPO should take precedence over any GPOs that are linked to child containers. Enforcing a GPO link works by moving that GPO to the end of the processing order.

An administrator can also use GPMC to enable or disable a GPO link. If an administrator enables a GPO link, Group Policy processes the linked GPO. If the link is not enabled, Group Policy does not process the linked GPO.

GPO Operations

GPO operations refer to the ability to backup (export), restore, import, and copy GPOs. Backing up a GPO consists of making a copy of GPO data to the file system. Note that the Backup function also serves as the export function for GPOs. Backed up GPOs can be used either in conjunction with Restore or Import operations.

Restoring a GPO takes an existing GPO backup and re-instantiates it back in the domain. The purpose of a restore is to reset a specific GPO back to the identical state it was in when it was backed up. This restoration does not include GPO links. This is because the links are a property of the container the GPO is linked to, not the GPO itself. Since a restore operation is specific to a particular GPO, it is based on the GUID and domain of the GPO. Therefore, a restore operation cannot be used to transfer GPOs across domains.

Importing a GPO allows you to transfer settings from a backed up GPO to an existing GPO. You can perform this operation within the same domain, across domains, or across forests. This allows for many interesting capabilities such as staging of a test GPO environment in a lab before importing into a production environment.

Restoring and Importing a GPO will remove any existing settings already in the target GPO. Only the settings in the backup will be in the GPO when these operations are complete.

Copying a GPO is similar to an export/import operation only the GPO is not saved to a file system location first. In addition, a copy operation creates a new GPO as part of the operation, whereas an import uses an existing GPO as its destination.

Reporting of GPO Settings

GPMC can display a report of the defined settings in a given GPO. This report can be generated by any user with read access to the GPO. Without GPMC, users that did not have write access to a GPO could not read and view the settings in that GPO. This is because the Group Policy Object Editor requires the user to have read and write permissions to the GPO to open it. Some examples of users that might need to read and view but not edit a GPO include security audit teams that need to read but not edit GPO settings, helpdesk personnel that are troubleshooting a Group Policy issue, and OU administrators that may need to read

and view the settings from inherited GPOs. With GPMC these users now have read access to the settings.

The HTML reports also make it easy for the administrator to view settings that are contained in a GPO at a glance. Alternatively, administrators can expand and contract individual sections within the report by clicking the heading for each section.

GPMC also solves some common reporting requirements including the ability to document all the settings in a GPO to a file for printing or viewing. Using a context menu, users can either print the reports, or save them to a file in either HTML or XML format.

Search for GPO

GPMC provides extensive capabilities to search for GPOs within a domain or across all domains in a forest. This search feature allows an administrator to search for GPOs based on the following criteria:

Display name of the GPO.

Whether or not a specific domain has containers that link to the GPO.

The permissions set on the GPO.

The WMI filter that is linked to the GPO.

The type of policy settings that have been set in the User Configuration or Computer Configuration in the GPO, such as folder redirection or security settings. Note that you cannot search based on the individual settings configured in a GPO.

GUID of the GPO.

Group Policy Modeling

Windows Server 2003 has a powerful new Group Policy management feature that allows the user to simulate a policy deployment that would be applied to users and computers before actually applying the policies. This feature, known in Windows Server 2003 as Resultant Set of Policy (RSoP) Planning Mode, is integrated into GPMC as Group Policy Modeling. This feature requires a domain controller that is running Windows Server 2003 in the forest, because the simulation is performed by a service that is only present on Windows Server 2003 domain controllers. However, with this feature, you can simulate the resultant set of policy for any computer in the forest, including those running Windows 2000.

Group Policy Results

This feature allows administrators to determine the resultant set of policy that was applied to a given computer and (optionally) the user that logged on to that computer. The data that is presented is similar to Group Policy Modeling data, however, unlike Group Policy Modeling, this data is not a simulation. It is the actual resultant set of policy data obtained from the target computer. Unlike Group Policy Modeling, the data from Group Policy Results is obtained from the client, and is not simulated on the DC. The client must be running Windows XP, Windows Server 2003 or later. It is not possible to get Group Policy Results data for a Windows 2000 computer. (However, with Group Policy Modeling, you can simulate the RSoP data).

GPMC Scripting

The GPMC user interface is based on a set of COM interfaces that accomplish all of the operations performed by GPMC. These interfaces are available to Windows scripting technologies like JScript and VBScript, as well as programming languages such as Visual Basic and VC++. An administrator can use these interfaces to automate many Group Policy management tasks.

These interfaces are discussed in detail in the GPMC software development kit (SDK) located in the %programfiles%\gpmc\scripts\gpmc.chm Help file on systems where GPMC has been installed. The contents of the GPMC SDK are also available in the Platform SDK.

For more information about GPMC interfaces, see MSDN.

Group Policy Management Console Dependencies

Group Policy Management Console requires the MMC infrastructure to function. In addition, GPMC has its own set of system installation requirements, as well as requirements for certain GPMC features to function.

GPMC System Installation Requirements

Although GPMC can manage both Windows 2000 and Windows Server 2003 domains with Active Directory, the tool itself must be installed on a computer running Windows Server 2003 or Windows XP Professional (with Windows XP Service Pack 1 (or later) and the Microsoft .NET Framework). Note that when installing GPMC on Windows XP Professional SP1, a hotfix is required. This hotfix (Q326469) is included with GPMC. GPMC Setup prompts you to install Windows XP QFE Q326469 if it is not already present.

GPMC Feature Requirements

GPMC exposes features that are available in the underlying operating system. Because new features have been added to Group Policy since Windows 2000, certain features will only be available in GPMC depending on the operating system that has been deployed on the domain controllers and clients. This section describes these dependencies. In general, there are four key issues that determine whether a feature is available in GPMC:

Windows Server 2003 Active Directory schema must be available to delegate Group Policy Modeling or Group Policy Results.

Windows Server 2003 domain controller must be available to run Group Policy Modeling.

Windows Server 2003 domain configuration (ADPrep /DomainPrep) must be available to use WMI Filters.

Clients must be running Windows XP or Windows Server 2003 in order to generate Group Policy Results data.

GPMC dependencies upon Windows and Active Directory platform appear below:

GPMC Dependencies on Windows and Active Directory

 

Dependency Feature Reason

Windows Server 2003 Active Directory Schema

Delegation of Group Policy Modeling and Group Policy Results

The Generate Resultant Set of Policy (Logging) and Generate Resultant Set of Policy (Planning) permissions needed for this operation are only available with the Windows Server 2003 Active Directory schema.

Windows Server 2003 Domain Controller in the forest

Group Policy Modeling The simulation is performed by the Resultant Set of Policy Service which is only available on domain controllers running Windows Server

Windows Server 2003 domain configuration (DomainPrep)

WMI Filters ADPREP /DomainPrep configures the domain for Windows 2003 Active Directory including configuration for WMI Filters.

Clients must be running Windows XP or Windows Server 2003

Group Policy Results Clients must be instrumented to log Group Policy Results data when policy is processed. This capability is only available on the listed systems.

There is no dependency from the Group Policy perspective on whether a domain is in native mode or mixed mode.

Best Practice: Group Policy Design Guidelines – Part 227/07/2010, 7:00 pm | by Alan Burchill 33,392 views

In my previous article In this article Best Practice:Active Directory Structure Guidelines – Part 1 I spoke

about some of the guidelines I personally use when developing an Active Directory OU structure. In

this next part I will discuss some guidelines I use when designing a Group Policy Object infrastructure.

Ideally you should make the the Active Directory OU and GPO design decision together to best ensure

that you have the most efficient design possible. However if you have an existing OU structure

designed a lot of these guidelines can still be applied to most existing environments.

As in Part 1 these are simply guidelines that I use and should not be taken as hard an fast rules. I quite

often finding myself having to break these rules due to real world conflicts or just because one rule

might conflict with the other rule. If you do find your self in a situation where you are not sure which

path to take try to chose the option that will result in the least administrative effort in the long term.

Active Directory Group Policy Design Guidelines

Keep the GPO’s name consistent with the OU names

When naming the GPO try to keep the name of the policy the same as the concatenated name of all

the OU’s to where the group policy object is applied. Having the fully concatenated name will make it

intently know what that policy is applied when just looking at the GPO name. This is very handy to

know when looking at a Group Policy Results report which only gives you the name of the GPO without

the linked OU details.

Bad Example “Workstations” Good Example “Sydney Workstations”

 

In keeping with having names consistent this also means you should adhere to the same naming

conventions as mentioned in Part 1 with the OU’s (i.e. “Keep it short”, “Be Intuitive” & “Most to least

signification from left to right”… So in saying that please read the next guideline…

References

TechNet: Establishing Group Policy Operational Guidelines

Define a meaningful naming convention for GPOs that clearly identifies the purpose of each GPO

Don’t use the work “POLICY”  or “GPO” in the GPO name

Nothing annoys me more to see a group policy called “Workstations Policy” or “Workstation GPO”…. I

KNOW ITS A POLICY!!!! I AM LOOKING AT IT IN THE GROUP POLICY MANAGEMENT CONSOLE. Please

drop the work “policy” or “GPO” from the name of the Group Policy object as you are simple adding

more characters to what might already be a long name only for the sake of pointing out the obvious.

I also realise that the two GPO’s that come with AD are called “Default Domain Policy” and “Default

Domain Controller Policy” which goes against this rule…

Remember at the start of part 1 how rules were meant to be broken…  So I do NOT recommend that

you rename these polices there is just to much risk and confusion that doing this might cause. But this

would have to be the only exception to this rule that I would be happy to let though…

Treat your terminal servers like workstations

Terminal Servers (now known as Remote Desktop Services) are essentially a multi-user workstation

and as such should be treated more as a workstation than a server. Ideally you should configure you

Terminal Server to be as close as possible as your workstations to provide your users with a consistent

experience. The best way to make sure the configuration is consistent is to apply the same policy

settings to the Terminal Serves as your workstations.

That being said don’t apply the same computer Group Policy Object to the Terminal Servers if for no

other reason than it helps reduce the risk of making a change to a workstation that could affect the

stability of the servers (e.g. Automatic Update reboot schedule). Therefore you will need to maintain

some level of manually synchronisation between you default workstation and terminal server policy.

Unlike computer GPO’s it far more acceptable to apply the same user GPO’s to your users when

logging on to the Terminal Server as the GPO are applied to the User Object rather than the computer

account. Using the same policy means that any changes made to the user policies will automatically

apply to terminal servers without the administrative overhead of making duplicate updates when there

are policy changes. If you have any user configuration that you want to configure that is specific to the

terminal servers (e.g. disable adding PST file) then you can override this policy using the Group Policy

Loopback option on the computer GPO you apply to the Terminal Server. This is another  reason why

you would want to have a separate computer GPO as it allow you to apply specific Terminal Server

user settings via a loopback policy.

For more information on troubleshooting Loop back policies check out Loopback Policy Processing

Debug Series   | CB5 Blog  and Aaron Parker’s StealthPuppy blog.

Reference

TechNet: Using Loopback Processing to Configure User Settings

The User Group Policyloopback processing mode policy setting is an advanced option that is intended

to keep the configuration of the computer the same regardless of who logs on. This option is appropriate in

certain closely managed environments, such as servers, terminal servers, classrooms, public kiosks, and

reception areas.

New GPO’s only when scope is different

I have seen some organisations apply many Group Policy Objects (GPO’s) to the same OU. There are a

number of reason why you might want to do this however you should really consider why you want

spawn another GPO as each one will add about 5mb to you Active Directory SYSVOL. But if you start

creating lots of GPO objects then you can quickly blow out your the size and performance of your

SYSVOL. This is not such a problem if you have upgraded to a DFS-R SYSVOL replication or you have

configured a Group Policy Central Store for your Windows Vista and later computers but its still good

practice to keep the number of GPO’s as low as possible.

Monolithic vs. Functional GPOs

Now that I have just told you that you should load up your GPO’s with lots of setting rather than having

lots and lots of separate GPO’s Mike Kline has referred  me to the this great article Best Practice for

Optimizing Group Policy Performance by Darren Mar-Elia that talks about Monolithic vs. Functional

GPOs.

The terms “monolithic” and “functional” refer to how you design them. Monolithic GPOs contain settings

from many different areas. For example, a monolithic GPO might contain settings from Administrative

Templates, Internet Explorer Maintenance, and Software Installation policies—all within a single GPO. By

contrast, functional GPOs typically do one thing. For example, a functional GPO may do only Software

Installation or enforce Security settings.

I totally agree with this and my advice to you when trying to decide which to use that your should pick

the type of policy configuration that suites your needs.

This also maps very nicely to the 80/20 examples you will see below where you take a more Monolithic

approach to the 80% GPO’s and more Functional to the 20%. The 80% policies are going to have more

setting in them but they will be relatively static where the 20% policies will have fewer settings but

probably need to be updated more frequently. This way you should be able to balance the pro’s and

con’s of each policy type in your environment.

References

TechNet: Complying with Service Level Agreements

If you have large or complex GPOs that require frequent changes, consider creating a new GPO that contains

only the sections that you update regularly.

Setting (not policies) = Slower SOE

It is often a misconception that splitting up your group policy setting into a lot of Group Policy Objects

(GPO’s) will slow down Group Policy on your computers. While this might be true if you have many

100’s (or thousands) of GPO’s applied to your computer this is not normally the reason why computer

may slow down processing Group Policies. Normally you will find that its the number of settings you

have applied that will cause performance issues and even then you will find that particular setting that

will cause more of a performance hit than other. In my experience the policy setting that cause the

most likely affect performance are:

1. Printer Mappings (100+)

2. Folder Redirection (Especially with Windows XP and AppData Redirection)

You should also expect that the first time a users logs on with a new account that they should expect a

slow logon as the computer will need to apply all policy setting. However subsequent logon’s should be

much faster as the computer is then only checking the policy is still applied. This is similar to the

difference between running a “GPUPDATE” and a “GPUPDATE /FORCE” .

You should also check out the Best Practice for Optimizing Group Policy Performance post by Darren

Mar-Elia as this post explains in detail how GPO are applied and what you can do to tweak

performance.

While it would be fairly rare to have an environment that has more than a 999 GPO’s applied to a

single computer still be aware there is a hard limit on the number of GPO’s you can apply to any user

or computer. Thus trying to keep the number GPO’s to a as few as possible is a good idea especially in

very large organisations that may uses separate GPO’s for installing software packages.

Reference

TechNet: Determining the Number of Group Policy Objects

Note that a maximum of 999 GPOs is supported for processing GPOs on any one user or computer. If you

exceed the maximum, no GPOs will be processed.

Disable User/Computer settings if not in use

If you are creating a GPO that is only meant to be applied to computers (and vice versa for users) then

you should disable the unused portion of the GPO. This not only helps guards against accidental

change to the section of the GPO that should not be applied it should also give you a small

performance boost processing policies on your computers as the GPO does not un-necessarily evaluate

parts of the policy that are not configured with any settings.

While I have never seen a performance benefit in disabling the unused portion of a GPO or based on

the number of GPO’s applied to a computers (see “Settings (not polices) = Slower SOE)” section

above) I do encourage that you adhere to these principals to avoid Death of a thousand cuts when it

comes to the performance of your systems.

TechNet: Complying with Service Level Agreements

If a GPO contains only computer or user settings, disable the portion of the policy that does not apply. The

destination computer does not scan the portions of a GPO that you disable, which reduces processing time

Avoid using Enforced

In all my time as an Group Policy Administrator I cannot real once a scenario that I required the use of

the Enforced feature of Group Policy. At all cost you should avoid this setting as doing so is like using

big hammer to a problem that you can probably avoid if designed right.

(RESIST THE URGE)

References

TechNet: Designing Your Group Policy Model

Use the Enforced and Block Policy Inheritance features sparingly. Routine use of these features can

make it difficult to troubleshoot policy because it is not immediately clear to administrators of other GPOs

why certain settings do or do not apply

Reuse GPO’s where possible

If you are in a situation that you want have the same settings you want to apply to all the users or

computers in specific OU’s your organisation then consider linking the same GPO to these OU’s. When

naming the GPO chose a name that represents what is common  to what you are applying. This is

shown in the image below (and in “80/16/4 Example 2”) where the policy is named “People

Manufacturing” as this is the common two values to where to policy is being applied.

The means the “Sydney” and “Coolangatta” is ignored as that would result in a long policy

name of “People Sydney and Coolangatta” Manufacturing”. It would be obviously longer

again if you had the policy linked to many more sites.

If you have Software Assurance use the Advance Group Policy Management (AGPM) tool

Advanced Group Policy Management (a.k.a. AGPM) is a tool that is available to anyone who is licensed

to have Software Assurance. This programs is a change management tool that allows you to check-in

and check-out GPO as well as create a list of changes and an audit trail of change to GPO’s. You can

check out my AGPM install and configuration series at AGPM   Part 1: Introduction to Advanced Group

Policy Management (a.k.a AGPM) v4. If you have a Group Policy infrastructure of any size or if you have

more than one person who is responsible for making changes to GPO’s then this is definitely

something you should consider.

AGPM is also very good at avoiding GPO editing conflicts as you will find that the “last writer will win”

when making policy changes. This means that in an environment that has multiple GPO admins you

might find that you could be overwriting each other changes with un-expected results. AGPM gets

around this issues as it support the method of checking in and out GPO’s for editing meaning that now

two GPO administrators can edit a GPO at the same time thus eliminating the possibility of overwriting

each other changes.

For even more information on AGPM check out the following links:

Microsoft MDOP Blog

TechNet: Overview of Advanced Group Policy Management

TechNet: A Video tour of Advanced Group Policy Management

TechNet: Technical Overview of AGPM

TechNet: What’s New in AGPM

TechNet: Choosing Which Version of AGPM to Install

TechNet: Step-by-Step Guide for Microsoft Advanced Group Policy Management 4.0

TechNet: Operation Guide for Microsoft Advanced Group Policy Management 4.0

Group Policy Blog: Importing and Exporting with AGPM

Create a Test Group Policy Structure

Implement something like AGPM is an excellent way to make sure you have a proper rollback strategy

for making changes to Group Policy but sometimes you just want somewhere to test the policy

functionality before you put it into production. I would definitely recommend having an isolated replica

of the AD structure in for making test however the problem with these environment is that they are

normally not a 100% representation of the production environment.

Therefore as a second step in your testing of policy changes before being applied to productions

systems you should create a test GP structure that will allow have a selection of users and computers

that are in production but are not mission critical. Best to select users that you know are easy to get

along with and wont scream to loud when you break something. You can even apply your own

computer and users account to this test GP structure but make sure that this is not your only account

as you want your computer to still be able to work so you can undo your changes in case you royally

stuff something up.

OU Method

The image below shows how you could implement a Test OU/GP structure however by creating a

separate OU structure to test your group policy. This method provides excellent isolation of your test

computers and users to production which may be desired if you want to lessen the impact of any bad

configuration changes. However this would mean that you would have the overhead of needing to

ensure that all configuration changes to the production GPO’s are also replicated to these. Otherwise

you may end up with your test environment being configured differently to your production GPO.

Security Group Filtered Method

The Security Group Filtered method applies the test GPO’s to the existing OU structure but they are

security filtered so they will only apply to the users or computers you want to test. The test GPO will

only have the delta configuration changes applied to it for the policy setting that you are testing

therefore all other production policies will be implicitly applied to the test objects. Therefore you test

computers and users are as close as possible representation of production because they are subject to

the production policies. This also mean you do not need to make duplication configuration changes to

the GPO’s when you do make production changes as the test computers will automatically have the

production policies applied. The down side to this method is that unless you are carful in how you

apply your security filtering you may inadvertently apply the test changes to your computers users

and computers as they are all under the same scope of the test GPO. Another disadvantage of this

method is that as you are relying upon security groups to apply the users or computer to the test

policy it is possible that you could be a member of multiple test groups and thus be subject to multiple

conflicting test GPO’s which may make the results somewhat unpredictable.

When not testing GPO changes the Test GPO’s should remain configured without any settings and/or

the link to the OU should be disable to avoided any extra policy processing overhead to the production

users and computers.

Hybrid Method

This method combines both a separate OU structure and separate GPO’s but avoids having to use

security group filtering. The advantage of this method is that you test environment is still subject to

the production GPO’s however the test policies are only applied to the users and computers that are

located in the Test OU structure. This method totally mitigates accidently applying a test configuration

to your production computers and it also eliminates the need to duplicate configuration changes to

your production environment.

Reference

TechNet: Establishing Group Policy Operational Guidelines

Always stage Group Policy deployments using the following pre-deployment process

TechNet: Designing Your Group Policy Model

Prepare a staging environment to test your Group Policy-based management strategy before deploying GPOs

into your production environment.

TechNet: Deploying Group Policy

Always fully test your GPOs in safe (nonproduction) environments prior to production deployment

Backup Often

Especially if you don’t have something like AGPM installed in your environment you should seriously

consider making a PowerShell script that simple backs up all your new GPO’s in your Active Directory

every night. Having back up copies of you GPO is very handy especially if you have miss-configured

something and you quickly want to rollback to last known good policy setting. For more information on

how to do this with PowerShell visit PowerShell Script: Backup all GPOs that have been modified this

month from the Group Policy Team Blog.

References

TechNet: Defining Group Policy Operational Procedures

You should also create regular backups of your GPOs

Edit Default Domain Policies Sparingly

Unless you are changing the default domain password policy then it is strongly recommended that you

do not modify the Default Domain or Default Domain Controller group policy objects as making a

mistake in these two policies up can really mess up your Active Directory. If you want to make a

change to all your DC or your entire domain then consider making a separate new group policy at the

same level as the default policies. This will at least allow you to un-do any change selectively disabling

the offending policies if something does go wrong.

Reference

TechNet: Linking GPOs

If you need to modify some of the settings contained in the Default Domain Policy GPO, it is

recommended that you create a new GPO for this purpose, link it to the domain, and set the Enforceoption.

In general, do not modify this or the Default Domain Controller Policy GPO. If you do, be sure to back up

these and any other GPOs in your network by using GPMC to ensure you can restore them.

TechNet: Establishing Group Policy Operational Guidelines

Do not modify the default domain policy or default domain controller policy unless necessary. Instead, create

a new GPO at the domain level and set it to override the default settings in the default policies.

Update: Here is another post I have found that confirms

thishttp://jorgequestforknowledge.wordpress.com/2011/10/23/best-practices-for-the-default-domain-

policy-and-the-default-domain-controllers-policy-gpos/

Avoid using Group Policy Software Assignment

I know it sounds strange for a Group Policy expert to say avoid using Group Policy but this is definite

one case where you should consider using other software deployment products due to their vastly

superior features.

Group Policy Software Installations (a.k.a. GPSI) is a way you can deploy an MSI based application to

your computers using Group Policy. This can be very useful way of deploying a standard set of

applications to your computers however when compared to the advanced targeting features of SCCM

software deployment or App-V this limitations of this method of software deployment quickly becomes

evident.

One common problem I see when deploying software this way is the “Un-install when falls out of

scope” options. This can be very handy when you want to move a computer to another OU and you

want all the software packages that are not needed any more to un-install. This is even worse when

you try to move an computer between domains as the computer will then un-install and re-install all

the applications assigned to it which can take a VERY LONG time. Even when you have the “Un-install

when falls out of scope” not ticked on the source domain and you move the computer to a new domain

you will find that the installer service will still need to do a repair/check install of all the applications of

the new domain even if the applications are already installed. However this also means that when the

computer is removed from a domain then you have to wait for all the application’s to un-install during

the next reboot. The un-installing of application can obviously take a long time if you have many

applications install via this method. If you don’t select this options then you will find that your

computer will over time build up the a number of installed applications installed on your computers

that will affect performance, stability and licensing costs. The other inflexibility of doing software

assignment to the computers via GPSI is that they will only install on the next reboot of the computer.

Meaning that a user will need to do a full reboot of their computer before they will be able to start

using the new applications.

The other restriction of GPSI is that you are limited to deploying only Microsoft Software Install (a.k.a.

MSI) packages. Where tools like SCCM and App-V will allow you to deploy application via a silent

command line option or via a sequenced application.

So due to all these targeting issues with GPSI software then I strongly recommend that you consider

using either Microsoft SCCM package deployment or Microsoft App-V due to the superior targeting and

features these products offer. For more information on the advantages of Microsoft App-V then i

strongly recommend that you checkout the series of App-V FAQ

at http://blog.stealthpuppy.com/tag/appvfaq .

References

Office 2007 Deployment via Group Policy

Office 2007 is no longer deployed using transform files

Below are the only scenarios that should be used when deploying Office 2007 via GPSI. While this

article is specific to Office 2007 I would also say that the same limitations should be used when

considering GPSI for other applications as well.

TechNet: Use Group Policy Software Installation to deploy the 2007 Office system

You can use the Software Installation extension of Group Policy to deploy the 2007 Office system

tocomputers if the following conditions exist:

Small organizations that have already deployed and configured Active Directory

Organizations or departments that comprise a single geographic area

Organizations with consistent hardware and software configurations on both clients and servers

Never edit Group Policy Objects from the Domain Controller

To often I see people editing their GPO’s directly from a Domain Controller in their organisation as they

are not aware they can do this remotely. The Remote Server Admins Tools (a.k.a. RSAT) have will give

you the option to install (See instructions here) the Group Policy Management Console on any

workstation or server running Vista/2008 or greater. I strongly encourage you to do this as if you are

performance day to day management of your active directory (e.g. Creating users, editing Group

Policy and adding/removing users from groups) then sooner or later you will find that you might affect

the stability of your DC (which would be BAD).

Apply policies as high as possible

When given the choice of applying the same policy at multiple lower locations or just one locations

higher always try to link the policy as high up as possible in the OU tree. If there are cases where you

want to apply the policy setting at all levels except for a minority of the lower sub-OU’s then simple

apply a different policy on the fewer OU’s to make the exception.

Bad Example Good Example

Linking GPO’s

Essentially there are three ways ways you can link a GPO to an AD structure firstly is to apply it to a

OU secondly is to apply it to an AD Site and finally is to link it to a domain.

Linking to AD Site

I have to say that you should NEVER consider applying a Group Policy to an AD site EVER!!!. Not only

does applying a GPO to an AD site make troubleshooting an absolute pain you frequently finding

yourself inadvertently applying a user or workstation GPO to your servers (This can be VERY BAD). AD

Sites are based on IP subnets and I agree it can be very handy to apply settings based on the IP

address of the computer (seeHow to use Group Policy Preferences to dynamically map printers with

Roaming Profiles ) and thankfully there is a way to now do this with Group Policy Preferences. Any of

the new preference settings can be targeted usingPreference Item-Level Targeting which gives you 27

different ways you can target your setting. The IP Address Range Targeting and Site Targeting target

options will allow you to achieve the same targeting as applying the GPO to an AD Site however you

are far less likely to make a mistake using this method as the GPO should be linked to resource OU

that limits the scope of the policy to only a particular type of AD Objects (e.g. just workstations not

servers).

Linking to OU

Linking a GPO to an OU is by far and away the most popular method of linking a GPO. This method

allows for easily change the users configuration my moving them into the appropriate OU structure to

have them configured. This method also fits well with the resource OU structure (see Part 1) so that

you can disable parts of the GPO that don’t apply to the object that you are apply the policy.

Linking to a Domain

Technically you can apply a GPO to the Domain however this is more or less like linking it to the Root

Organisational Unit. Linking it here will apply the policy to the entire domain so make sure that you are

very careful when link a policy to this location. Policies should only be linked to the domain if you have

a setting that you want to be applied to all users and/or computer in your entire domain. (See “Edit

Default Domain Policies Sparingly” section above). The other scenario that you might want to link a

policy here is if you want to make sure that you have at least your core policy setting applied to your

“Users” or “Computers” container. But I would also recommend that you redirect these default

locations for new objects so that you don’t have to setup GPO’s at the domain to cover these objects.

References

TechNet: Linking GPOs

If, however, the settings do not clearly correspond to computers in a single site, it is better to assign the GPO

to the domain or OU structure rather than to the site.

TechNet: Linking GPOs

Most GPOs are normally linked to the OU structure because this provides the most flexibility and

manageability

When to filter

There are two ways you can filter your GPO when you apply then to your AD structure. Predominantly I

find that Security Filtered Group Policy Objects is the most common way you can filter. Either way you

should be filtering a GPO only when you want to exclude or include exceptions to the scope of the

policy.

Security Filtered

This method allow you to apply Group Policy Objects to a cross section of users or computers in your

organisation. I quite often have a security filtered policy that has my pilot users computers as

members so that I can selectively apply settings to their computers first for testing (see “Create a Test

Group Policy Structure” section above). As computers and users can also be a member of multiple GPO

this also allows you to configure a users environment without having to spawn many number of levels

of OU’s that would other wise be necessary for every combination of  GPO assignment (see “80/16/4

Example 3 & 4”). You can in theory apply a single user or computer to a GPO by adding them explicitly

to the GPO under Advanced security (see image below).

However this is extremely poor practice and I would strongly recommend that you should always

create a security group that has the “Apply Group Policy” permission assigned to it so that at a later

stage you can assign users or computer to the GPO without modify the permission on the GPO itself

(see image below).

I know the name “Workstation GPO” might seem to conflicting with the “Don’t use the work “POLICY” 

or “GPO” in the GPO name” rule that however in this case “GPO” is justified as this is the name of a

security group and so it is not obvious that a the security group is used as part of a Group Policy

Object.

Recommendation: When removing “Authenticated Users” from the security filtering of a GPO ensure

that you only remove the “Apply Group Policy” permission and not the “Read” permission as this will

cause “Inaccessible GPO” error when any non domain admin tries to look a the GPO’s via GPMC. See

my previous post How to apply a Group Policy Object to individual users or computer for detail

instructions on how to do this correctly.

Reference

TechNet: Defining the Scope of Application of Group Policy

If you have Read access to the domain, site, or OU, but not on one of the GPOs linked there, it will appear

as Inaccessible GPO, and you will not be able to read the name or other information for that GPO

The exception to where you want to do this is if you have many GPO’s that are security filtered and

you want to ensure as fast a possible security processing then removing the read permission will

“slightly” improve performance. So unless GPO processing time is an issues this doing removing the

read is still not recommended.

TechNet: Determining the Number of Group Policy Objects

If the Apply Group Policy permission is not set, but the Read permission is, the GPO is still inspected

(although not applied) by any user or computer that is in the OU hierarchy where the GPO is linked. This

inspection process increases logon time slightly.

Recommendation: You should only security filter GPO when the setting in the policy are mutually

exclusive with all the other GPO in your organisation. If you have two GPO’s that are security filtered

that configure the same setting and the user or computer are in both the group for that policy then

only one policy will win out and you could end up with some fairly un-predictable results.

WMI Filters

WMI Filters have been around since Windows XP/2003 and are a great way to filter your Group Policy

Objects based on the hardware of the computer that the policy is applied. However performing a WMI

queries can take a substantial amount of time and if you have multiple WMI filters applying to your

computers you have a significant performance decrease. Once again you can get around having to

resort to using WMI Filters as Group Policy Preference Item-Level Targeting also have a number of

options you can target hardware. Unlike WMI the Preference targeting engine has the performance

advantage of being written in native code so it is much faster at determining what setting to apply.

They hardware targeting options are:

Battery Present Targeting

CPU Speed Targeting

Disk Space Targeting

MAC Address Range Targeting

Operating System Targeting

PCMCIA Present Targeting

Portable Computer Targeting

RAM Targeting

As a legacy option you can even do WMI Query Targeting which allows you to easily port your

pre-existing WMI queries into preferences. But be warned the WMI Query Targeting still suffers

from the same performance issues.

So as you can see WMI Filters applied to the GPO object itself however just as in the “Where to Link”

section above you will see Group Policy Preference will help you avoided having to rely upon WMI to

often.

Reference

TechNet: Applying WMI Filters

WMI filters can take significant time to evaluate, so they can slow down logon and startup time.

Always create a deny “Apply group policy” security group

When creating a GPO always consider creating a security group and assigning it the Deny “Apply

group policy” permissions (see image below) so that you have a simply way to exclude a particular

user or computer from the policy in the future. Having this deny group applied to the GPO in advanced

can save you a lot of time as it is often much easier and quicker to added a users to a security group

than it is to modify the security on a GPO.

(Same as above) I know the name “Workstation GPO Deny” might seem to conflicting with the “Don’t

use the work “POLICY”  or “GPO” in the GPO name” rule that however in this case “GPO” is justified as

this is the name of a security group and so it is not obvious that a the security group is used as part of

a Group Policy Object.

Apply GPO to New Users and Computers OU

In part 1 I recommended about setting up a new OU structure for any new user and computer that is

created in your AD under the “Redirect New User and Computer Accounts” section. The reason why

this was recommended was to enable you to easily apply a GPO to the default locations for these

objects without having to resort to modifying the Default Domain Policy or by linking a new GPO to the

entire domain.

It the example below I have created a simple GPO for each Users and Computers OU. Using this

method your default user and computers will still receive the “Default Domain Policy” GPO and any

additions settings in the two “New” GPO’s.

I don’t recommending linking the “People” or “Workstations” GPO’s (See “Example Group Policy

Designs” section below) as the New\Users and New\Computers OU as they could contain objects other

than People and Workstations (e.g. Service Accounts or Servers). Instead I recommend that you only

configured some basic security setting for the “New Computers” such as a default WSUS and patch

install schedule so that any computers that are left in these OU’s are at least kept up to date with

security patches. Then for the “New Users” GPO you may want to configure a delayed logon script

(see How to schedule a delayed start logon script with Group Policy) that notifies the users that they

are not properly configured and they need to contact the help desk.

In any case even though you have configured these locations it is still very important that you

establish some sort of regular process by which someone reviews the objects in these OU’s and

ensures they are moved into the appropriate locations so the proper policies are applied.

References

Designing an OU Structure that Supports Group Policy

…change the default location where new user and computer accounts are created so you can more easily

scope GPOs directly to newly created user and computer objects

Use the 80/20 rule

Ok… this is the a rule in name only as it should also be considered as a guideline. Essentially you

should try to put the vast majority of setting in a policy that applied to all your computer or users.

Then you should apply the exception to the default policy to the subset only to the computers you

want to apply these settings (see 80/20 Conceptual Design). If two scopes/levels of applying policies is

not flexible for your organisation then you can even consider the 80/16/4 to give you more flexibility

(4% equals 20% of 20%). Also note the smaller 4% scope does not necessarily need to be a complete

subset of the 16% as it is possible that you want to apply location specific settings that have nothing to

do with the organisational structure (see 80/16/4 Conceptual Design below).

When deciding what policy settings to put in the 80% of 20% GPO’s make sure that you take another

look at the “Monolithic vs. Functional GPOs” section above that talks about the different approaches

you can take when configuration settings. As I said before the 80% policies are going lend them self to

have more setting in them but they will probably be relatively static (i.e. Monolithic) where the 20%

policies will have fewer settings but probably need to be updated more frequently (i.e. Functional).

80/20 Conceptual Design 80/16/4 Conceptual Design

The conceptual designs above shows that there is only one level 2 and level 3 scopes to apply GPO but

in reality there could be many different lower level policies that can be applied to your environment as

seen in “80/16/4 Example 4”.

Example Group Policy Designs

The organisation below that I use in the examples conveniently has 100 setting that they need to

apply. Therefore they number of setting equals the percentage break down of the number of settings

that are applied. In real world the number of setting are obviously going to vary greatly from single

digits perhaps many thousands of settings.

“80/20 Example” is a simple representation of how you would actually apply this in the real world. As

you can see 80 setting are applied at the top level to all “People” OU and there then there are 20

settings site specific user settings. These location setting are typically drive and printer mapping

setting that are specific to the site. While the “People”  Group Policy Object will have setting that need

to be applied to all users universally (e.g. screensaver time out value.)

80/20 Example 1

 

“80/20 Example 2” is the same as Example 1 except in this scenario the business has decided to have

a top level organisational OU structure so that it will be easy in the future to separate parts of the

organisation from the AD in the future. This illustrates that you do not need to have the same number

of levels of OU’s in your AD as the number of level of scope that you apply GPO’s.

80/20 Example 2

 

“80/16/4 Example 1” shows you how you would apply this to a “Three Tier OU Structure” (see part 1).

The advantage of this model is that all setting are applied base on the OU structure and which means

all policies are applied simple based on the location of the AD object in the OU structure. This is useful

as you don’t that you don’t need to add and users (or computers) to security group.

80/16/4 Example 1

 

“80/16/4 Example 2” shows you what you can do when you only want to apply the same

“Manufacturing” setting to all the users across all the sites. This takes into consideration the “Reuse

GPO’s where possible” rule (see above) and link a single manufacturing GPO

80/16/4 Example 2

 

“80/16/4 Example 3” shows you how you could apply the policy differently using a single security

group filtered policy at the top level but still have the same affect as the “80/16/4 Example 1”. This is

an example of applying a 3 level GPO structure to a 2 level OU structure as the “Manufacturing” simple

by applying it at the top level but then applying a security group filter. The advantage of doing it this

way is that you don’t need to have as many OU deep (see “Go Wide not Deep” in  part 1) and it avoids

having to create a new Group Policy for the manufacturing users at each site (especially when they

might be the same settings).

80/16/4 Example 3

 

“80/16/4 Example 4” shows a combination of “80/16/4 Example 1” and “80/16/4 Example 2” where the

organisation has generally the same requirements of “Example 1” however they need to apply 1 high

security setting (e.g. shorter screensaver timeout) that need to be applied to the managers computer

because they normally deal with sensitive corporate information. This also illustrates that you can

have multiple level 2 and level 3 GPO in the same environment and that level 3 GPO policies do not

necessarily need to be a subset of level 2 policies (see conceptual circles above).

80/16/4 Example 4

 

Apply default settings on your 80% level one policy just in case

I know I have just gone though above that you should apply 80% of your settings in the highest policy

however there is one problem with this. If for some reason a computer or users is placed in a top

level OU or a second level OU is created without a policy applied to it or a user or computer has not

been added to the correct security group this could leave gaps with the coverage of settings. So to get

around this issue be sure that your level one 80% policies are configured with a default setting to

cover your more essential configurations such as  Screensaver timeout or WSUS servers.

In the example below we have 95 settings (or 95%) of the setting being applied to the users with the

20% being applied at the second level policy. Effectively only 80 settings (or 80%) will be actually be

applied to the users from the top level policy as there is a 15% overlap of settings the settings.

However a user in the “People” or the miss configured “Brisbane” OU will at least get 95 setting (or

95%) of the settings applied. This might not be a perfect configuration for them however it will at least

mean they are compliant to the mandatory corporate configuration settings (e.g. Screensaver on and

WSUS server configured).

 

In closing I hope this documents has helped you design your Group Policy infrastructure in your

environment. If you have any other questions you want covered or you simply have a question about

what I talked about above please feel free to post a comment…

Introduction to Group Policy

Group Policy is an extremely powerful Microsoft technology which allows network administrators in charge of an Active Directory domain to impose configuration options on computers and users on that domain. Amongst the capabilities of Group Policy are:

The ability to deploy software to computers or users automatically Apply startup and shutdown scripts to computers, and logon/logoff scripts to users. Deploy printers to users or computers Redirect system folders (such as My Documents) to a network location Apply password and security policies to machines or users Enforce any of thousands of different configuration options relating to Windows, Explorer, the

Start Menu, the Desktop, as well as specific software packages such as Microsoft Office.

Group Policy is a fully heirarchical system, with policies implemented at lower levels inheriting settings from those defined above. Administrators can apply policies to Active Directory sites, domains and organizational units, and configure filtering by security group or WMI query to specifically target users or computers to apply policies to.

Setting it up

The following figure shows the Group Policy Management tool which comes as part of Windows Server 2008 R2

Group Policy Management Console

Group Policies are applied in the following order, with policies applied later taking precedence over policies applied earlier.

Local policies (defined only on a particular PC) Site policies (defined on an Active Directory Site) Domain policies (defined on an Active Directory Domain) Organizational Unit policies (defined on Active Directory OUs)

The same rules apply if several organizational units define policies. The policies defined higher in the OU tree are applied first but are superseded by those defined deeper in the tree.

Generally speaking, you should apply a policy so that it only affects necessary users or computers. This usually means applying a policy as deep into an organizational unit structure as you can in order to cover all needed users or computers. Consider the following figure, which shows the organizational unit structure of our test domain.

OU Structure

As you can see, we have an OU called Development, with sub-OUs named Computers and Users, to contain computer accounts and user accounts for the development team, respectively. We have done the same thing for Support. In order to target a policy at all users in the Development team, we could apply the policy to the Development\Users OU. If we have a policy we want to target at Development users and their computers, we could apply to the policy to the Development OU.

To give you an idea of how to do this, we'll create a simple Group Policy Object (GPO) which applies to the entire development team.

Creating and Linking a GPO

In the Group Policy Management Console, drill down to the Development OU, and right click on it. Choose the option 'Create a GPO in this domain, and Link it here'. You will be asked to name the GPO - for the purposes of this example, I have called the policy'Development Team'

GPO Properties

Once your new Development Team GPO is created, it will appear under the Development OU in the tree at the left of the Group Policy Management window. If you select this, you will see various properties relating to the GPO.

GPO Scope Options

Links

The Links section of the properties, above, shows all organizational units this GPO is applied (linked) to. GPOs can be linked to any number of OUs, so the policies contained within can apply to different parts of your Active Directory.

Security Filtering

The Security Filtering section allows you to define users or groups who are allowed to read the policy for the purposes of applying it to their computers. The default option allows the Authenticated Users group the ability to apply the policy, meaning that, in effect, everyone who has authenticated on the domain can apply the policy.

Imagine for a moment that you have a permanent development team, as well as a number of temporary contractors working in your development team. You have created both the permanent staff and the contractors in the Development\Users for simplicity, but you now find that you want to apply a policy to only the development contractors. There are two ways of doing this.

First, you could just create a new OU for the development contractors, and apply a new GPO to this OU. Alternatively, you could apply a GPO to your Development\Users OU, and alter the Security Filtering so that only users in a Development Contractorssecurity group can apply the policy.

WMI Filtering

WMI Filtering allows you to apply policies depending on the result of WMI queries. For example, you could apply policies only to computers which have over a certain amount of memory, or which have a certain brand of processor.

Configuring Policies

To configure a policy, right click on it in Group Policy Management and choose 'Edit'. The image below shows the Group Policy editor, and a number of policy areas you can edit.

Group Policy Editor

As you can see, the policy editor is split into two main parts - Computer Configuration and User Configuration. If your policy is linked to an OU which contains (either directly, or in sub-OUs) computers, then the options you specify under Computer Configuration will take effect. If your policy is linked to an OU which contains users, then the options you specify under User Configuration will apply. If the linked OU contains both users and computers, both sections of the policy will apply.

Computer policies apply to everyone who logs on to a particular computer, whereas User policies apply to users whatever computer they log on to.

Policies are fairly logically organized, but we will take a broad look at what the policy sections do.

Computer Configurationo Software Settings

Software Installation - define Windows Installer packages to install on computerso Windows Settings

Scripts (Startup/Shutdown) - defines scripts which will run when a computer starts up or shuts down.

Security Settings - Account policies (password length, lockout policy), registry secuirity, filesystem security and more

o Administrative Templates - the bulk of the computer related policy elements are here. You can control network settings, printer settings, system settings, as well as settings for various built in Windows components such as Internet Explorer, Task Scheduler, Windows Update and many more.

o Preferences - set environment variables, create and remove files, shortcuts, directories, ini files and registry entries

User Configurationo Software Settings

Software Installation - define Windows Installer packages to make available to users

o Windows Settings Scripts (Logon/Logoff) - defines scripts which will run when a user logs on or off. Folder Redirection  - redirect Windows special folders (such as My Documents,

Downloads and My Music) to administrator specified locations, usually on the network.

Internet Explorer Maintenance - configure Internet Explorer options.o Administrative Templates - the bulk of the user related policy elements are here. You

can control network settings, printer settings, system settings, as well as settings for various built in Windows components such as Internet Explorer, Task Scheduler, Windows Update and many more.

o Preferences - set control panel settings, as well as create and remove files, shortcuts, directories, ini files and registry entries

How it works

Policies are stored in the Active Directory, and computer policies are evaluated and applied when a computer starts up. User policies are applied when a user logs on.

Policies are also refreshed every 90 minutes (give or take 30) by default, so any changes made by an administrator while a user is logged on, or while a computer is turned on, will still be applied within a reasonable amount of time. This refresh interval can be changed using Group Policy.