Group policies are stored as a number of components that collectively enable the Group Policy functionality both at the client side and for the administrator. This data is replicated using a number of methods, depending on the component and platform. Throughout this section, we’ll discuss the key components of group policies as well as the replication engines available and how to work with them.

How GPOs are stored in Active Directory

GPOs themselves are stored in two places: group policy configuration (GPC) data is stored in Active Directory, and certain key group policy template (GPT) data is stored as files and directories in the system volume. They are split because while there is definitely a need to store GPOs in Active Directory if the system is to associate them with locations in the tree, you do not want to store all the registry changes, logon scripts, and so on in Active Directory itself. Doing so could greatly increase the size of your DIT file.

To that end, each GPO consists of the object holding GPC data, which itself is linked to a companion directory in the system volume that may or may not have GPTs stored within it. The GPT data is essentially a folder structure that stores administrative template–based policies, security settings, applications available for software installation, and script files. GPT data is stored in the DC’s system volume (SYSVOL), in the policies subfolder.

Note

Third-party developers can extend GPOs by incorporating options that do not reside in the normal GPT location.

The GPO objects themselves are held as instances of the groupPolicyContainer class within a single container in Active Directory at this location: CN=Policies,CN=System,dc=mycorp,dc=com.

Through a process known as linking, the GPOs are associated with the locations in the tree that are to apply the group policy. In other words, one object can be linked to multiple locations in the tree, which explains how one GPO can be applied to as many organizational units, sites, or domains as required.

Let’s consider the groupPolicyContainer class objects themselves. Take a look at Figure 11-1; we are using ADSI Edit to show the view of the Policies container and its children. Here you can see a number of groupPolicyContainer objects shown with a GUID as the cn field. The displayName attribute of these objects holds the name that administrators of Active Directory would see when using one of the normal tools to view these objects. Each GPO also has a gPCFileSysPath attribute that holds the full path to the corresponding directory in the system volume.

If you were to look under the Policies container on a default installation, you would find only two children. These children would correspond to the Default Domain Policy and the Default Domain Controllers Policy, the only GPOs created automatically by the system on installation. These GPOs have fixed names across all domains:

• {31B2F340-016D-11D2-945F-00C04FB984F9} is always the Default Domain Policy.

• {6AC1786C-016F-11D2-945F-00C04fB984F9} is always the Default Domain Controllers Policy.

Figure 11-1. GPOs in the Policies container

Any GPO is initially created as a standalone object in Active Directory. Each object can then be linked one or more times to three different types of locations: sites, domains, and organizational units. GPOs for domains and organizational units are held in the domain relating to their application, but creating a GPO for a site stores that GPO in the forest root domain by default; administrators can change this if they wish.

In the normal state of affairs, an administrator would customarily browse to a site, domain, or organizational unit in the GPMC, and then create a GPO and link it to that object. At this point, it appears that you have created a GPO at that location in the tree rather than what really happened, which was that the system created the GPO as a standalone object in the Policies container and then immediately linked it to that container.

To apply a GPO to a set of users or computers, you simply create a GPO and link it to a site, domain, or organizational unit. Then, by default, the user portion of the GPO will apply to all users in the tree, and the computer portion of the GPO will apply to all computers in the tree.

Thus, if we were to create a policy and link it to a domain, all computers and users of that domain would process the policy. If we were to create a policy and link it to an OU, all users and computers in that OU, and all users and computers within OUs beneath that OU (and so on down the tree), would process the policy.

To identify the links on a GPO, you simply look at the Scope tab of the GPO’s properties in the Group Policy Management Console. Figure 11-2 shows the results of a scan for the locations in the domain where the Desktop Policy GPO has been linked. In this case, the Desktop Policy has been linked only to the Desktops OU.

Figure 11-2. Identifying GPO links

We want to make three major points here:

This generates further questions. If multiple policies apply to different locations in a tree, can multiple GPOs apply to the same location, and if so, what takes precedence? Why would you want to apply one GPO to different parts of the tree? In addition, how can we stop the GPO from applying to the entire set of users and computers in the tree? Let’s consider each of these questions to understand policies better.

Let’s say that we create and link a GPO for all users in a site to run a logon script that loads an Intranet home page local to that site. Let’s also say that we create and link a domain GPO to set the My Documents folder location for each user in the domain. Finally, we have two user logon scripts that we need to run in a specific order for specific organizational units in that domain. GPOs are applied in a specific order, commonly called LSDOU. Local policies are applied first, and then site policies, then domain policies, and then finally OU policies are applied in the order of the OU hierarchy. This order of application is illustrated in Figure 11-3.

Figure 11-3. Order of policy application

If multiple GPOs are linked to a single site, domain, or organizational unit, the administrator can prioritize the order in which the GPOs from that level are processed. To account for this, the GPOs for the site that the user resides in are applied first, in prioritized order from lowest to highest. No other sites have any influence over this. Then the GPOs for the domain that the user resides in are applied in prioritized order. GPOs applied to parent domains in the domain tree have no influence on objects in domains lower down the tree. Domain trees do not impact GPO application at all.

The OU structure, however, has a significant bearing on what happens with GPOs. GPO links are inherited down an OU tree. So, while a child organizational unit can have its own GPOs linked to it, it also will inherit all of its parent’s GPO links. These organizational unit GPOs are applied in order according to the OU hierarchy once the site and domain GPOs have been processed.

For example, Paul Burke’s user account has the following distinguished name (see Figure 11-4):

cn=PaulBurke,ou=Databases,ou=Gurus,ou=Financial Sector,dc=mycorp,dc=com

When Paul logs onto his machine, the site GPOs are applied first, and then the mycorp.com domain GPOs. Next come the GPOs on the Financial Sector organizational unit, then the GPOs on the Gurus organizational unit, and finally the GPOs on the Databases organizational unit. From this, it’s fairly easy to see how organizational unit hierarchy design has a significant effect on GPO precedence.

Figure 11-4. Graphical representation of the location of the PaulBurke user

Remember that GPOs have a computer part as well as a user part. When a computer starts up, any site GPOs that have computer settings are applied in prioritized order. These are followed by any domain GPOs with computer settings, and so on down the organizational unit hierarchy until any GPOs on the organizational unit that the computer resides in are applied. During boot up, the user portions of these GPOs are ignored. Later, when a user logs on, the same process applies, this time with the user settings. The computer settings are ignored during user logon.^[2]

Any unconfigured settings anywhere in a GPO are ignored, and only configured settings are inherited. There are three possible scenarios:

If a GPO has settings configured for a parent organizational unit and the same policy settings are unconfigured for a child organizational unit, the child inherits the parent’s GPO settings. That makes sense.

If a GPO has settings configured for a parent organizational unit that do not conflict with the settings in a GPO configured for a child organizational unit, the child organizational unit inherits the parent GPO settings and applies its own GPOs as well. A good example of this is two logon scripts; these scripts don’t conflict, so both are run.

If a GPO has settings configured for a parent organizational unit that conflict with the same settings in another GPO configured for a child organizational unit, the child organizational unit does not inherit those specific GPO settings from the parent organizational unit. The settings in the GPO child policy take priority.

It is possible to force the settings of a GPO linked to an OU in the tree to be applied as the final settings for a child.

Blocking inheritance is a fairly simple concept. If you block inheritance to a specific organizational unit, GPOs linked to parent organizational units up the tree are not applied to objects in this specific organizational unit or its children.

Refer back to Figure 11-4. If we decide to block inheritance at the Databases organizational unit, user PaulBurke will receive only GPOs directly defined on the Databases organizational unit. If we decide to block inheritance at the Gurus organizational unit, PaulBurke will receive only GPOs on the Databases organizational unit and those inherited from the Gurus organizational unit. The organizational unit that you block inheritance at stops any higher-level GPOs from applying to the branch starting at the blocked organizational unit. In fact, we can block inheritance on any of the organizational units within the mycorp.com domain. For example, blocking inheritance on the Financial Sector organizational unit makes sense if we want to block domain and site-level GPOs from applying.

This can cause problems if not carefully managed. For example, let’s say that you have delegated control over an organizational unit branch to a group of administrators and allowed them access to manipulate GPOs on that branch. You may be applying GPOs to organizational units farther up the hierarchy that you wish this delegated branch to receive. However, your branch administrators have the ability to block inheritance of these parent organizational unit policies of yours. The branch administrators also have the ability to configure a setting that conflicts with one you set in a parent GPO; the branch administrator’s child setting will take precedence in conflicts.

You can block inheritance by right-clicking a domain or organizational unit in the GPMC and selecting Block Inheritance, as shown in Figure 11-5.

Figure 11-5. Blocking inheritance with the GPMC

To prevent this, you can check the Enforced option on an individual GPO link. This allows administrators to force GPOs to be inherited by all children of an organizational unit. However, it has one further effect: it prevents GPO settings in child organizational units from overriding conflicting settings in a parent OU. The Enforced option is available by right-clicking on a group policy link in the GPMC and selecting Enforced, as shown in Figure 11-6.

Figure 11-6. Group policy link context menu

Let’s say that we change a registry setting using a GPO on the Financial Sector organizational unit. Unfortunately, another administrator then sets the same registry setting (among many others) to a conflicting value on the Gurus organizational unit and also blocks inheritance at the Databases organizational unit. By default, the registry setting will be correctly applied only to the Financial Sector organizational unit, as the Gurus organizational unit receives the different setting (child overrides parent on conflicts due to inheritance rules), and the Databases organizational unit doesn’t inherit either policy. To fix both problems, we could set the original Financial Sector organizational unit GPO link to Enforced. This would prevent the specific setting on the GPO on the Gurus organizational unit from modifying it without affecting any of the other GPO settings. Our GPO would also be forced down past the Block Inheritance set up at the Databases organizational unit.

While it’s important to be aware of the Block Inheritance and Enforced settings, we generally don’t recommend that you make use of them in your Group Policy deployment unless you absolutely have to. Both of these settings modify the default expected behavior, and as a result they make troubleshooting more complicated. If you do take advantage of either setting, be sure to document your reasons so that administrators aren’t left guessing in the future.

We’ve already said that the computer portion of a GPO applies during boot up and the user portion of a GPO applies during logon. However, that isn’t the only time that a policy can apply. The policies also can be set to refresh periodically after a certain time interval. How often this occurs and what conditions are attached to this refresh operation are specified under the SystemGroup Policy key under the Administrative Templates section of the Computer section of a GPO.

Set the refresh value to 0 to have the policy continually apply every seven seconds. This could be very useful for a test environment, but obviously not for a production environment.

Refreshing is very useful for users who do not shut down their computers or log off from the system for days. In that case, GPOs apply in the normal way, but at very irregular intervals over long periods at a time. Setting up policy refresh means that you can apply those settings to such users at whatever interval you decide.

Introducing Group Policy into your environment will affect computer startup and user logon times to a degree. Exactly what degree varies from environment to environment, and you will need to test in yours to come up with a representative figure. We do not recommend foregoing Group Policy in an effort to speed up your startup and logon times, but we do recommend being frugal when planning the number of policies that will apply to a given user or computer. There are some things you can take into consideration with regard to speed when planning your Group Policy deployment.

Ping server with 0KB of data :
   Receive response#1 as a time in milliseconds (ms)
If response#1 < 10ms Then
   Exit as this is a fast link
Else
   Ping server with 2KB of data :
      Receive response#2 as a time in milliseconds
   Calculate Total-speed as response#2-response#1
End If
Ping server with 0KB of data :
   Receive response#1 as a time in milliseconds
If response#1 < 10ms Then
   Exit as this is a fast link
Else
   Ping server with 2KB of data :
      Receive response#2 as a time in milliseconds
   Calculate Total-speed as Total-speed + (response#2-response#1)
End If
Ping server with 0KB of data :
   Receive response#1 as a time in milliseconds
If response#1 < 10ms Then
   Exit as this is a fast link
Else
   Ping server with 2KB of data :
      Receive response#2 as a time in milliseconds
   Calculate Total-speed as Total-speed + (response#2-response#1)
End If
 'Average the total speed of (response#2-response#1)
Difference-in-milliseconds = Total-Speed/3
'If we know 2KB (16,384 bits) was moved in a certain number
'of milliseconds, then we need to calculate the number
'of bits moved per second (not per ms)
Bits-per-second-value = (16384 * 1000/Difference-in-milliseconds)
'Eight bits is a byte, so calculate bytes/second
bps-value = (Bits-per-second-value * 8)
'Calculate kilobytes/second to compare against GPO value
Kbps-value = bps-value / 1024

As each GPO is an object in Active Directory and all objects have access control lists (ACLs) associated with them, it follows that it must be possible to allow and deny access to a GPO using that ACL. With ACLs, it is possible to allow and deny access to apply GPOs based on security group membership. It is also possible to go to an even finer-grained level of detail and set access controls for an individual computer or user. Figure 11-7 shows that only one computer, XPCLNT01, can apply the policy pictured.

Figure 11-7. Security filtering with the GPMC

This is a significant feature of GPOs, and one that you can use heavily to your advantage. Let’s take a simple example, in which we need to ensure that users in the Finance Department receive a more restrictive screensaver timeout. The users in the Finance Department are in the People OU, along with all of the other company employees. In order to ensure that the screensaver timeout policy only applies to users in the Finance Department, we take the following steps:

Once this is complete, only users who are members of the Finance Users group will be able to apply the Screensaver Timeout GPO. All other users in the People OU will ignore the policy.

Up until now, we’ve only been able to apply the User Configuration section of a GPO when users were located somewhere under where the GPO was linked. From time to time, scenarios arise where you will want to apply User Configuration policies based on what machine the user is logging into rather than where the user is located in the domain’s OU structure. The solution to this is a Group Policy feature known as loopback mode.

There are two scenarios where loopback mode is very commonly used. The first is in the case of kiosk machines. If your company has computers available for employee use in common areas, such as building lobbies, you may only want to allow users to access Internet Explorer from the kiosk machine and prevent access to other programs. Another scenario is the case of remote desktop servers (RDSs) and Citrix deployments. In these cases, you will generally want users of the RDS server to receive a controlled desktop environment when they connect, but you will not want to apply that level of control to the users’ desktop computers.

Loopback mode is a computer policy that you must enable. You can find the settings under Computer Configuration→Policies→System→Group Policy→User Group Policy loopback processing mode. If you open that setting, you get the dialog box shown in Figure 11-8, which allows you to switch between the two modes of loopback operation: merge mode and replace mode.

Figure 11-8. Setting loopback mode

At this point, you are probably wondering what the difference is between the merge and replace modes. In merge mode, when a user logs onto a machine, his user policies are first applied in the normal manner, as shown in Figure 11-3. Once the user policies have been applied, the User Configuration sections of any GPOs that apply to the computer are then applied. Any settings that conflict (that is, they are defined in both the normal user policies and the policies applying to the computer) are overridden by the settings in the policies applying to the computer. In replace mode, by contrast, the GPOs that would normally apply to the user are ignored during logon. Instead, the User Configuration sections of any GPOs that apply to the computer are applied.

When you are planning to take advantage of loopback mode, it is critical to remember that loopback mode is a global setting for a computer, not a per-GPO setting. This means that if loopback mode is enabled in any GPO that applies to a computer, loopback processing will be enabled for all users that log onto that computer, and further, the User Configuration settings in all of the GPOs that apply to that computer will be applied.

Consider the organization in Figure 11-9. The organization uses a domain called mycorp.com that spans two sites, Main-Site and Second-Site. Marketing computers exist in Main-Site, and finance computers in Second-Site. Policy A applies to Main-Site only, policy B applies to the entire domain, and policies C, D, E, and F apply to the organizational units as indicated. Policy G applies to Second-Site.

Figure 11-9. Sample Group Policy implementation

Table 11-3 summarizes the application of policies with and without loopback mode processing. When loopback is not turned on, the only real difference comes from the site policies (A or G) that are applied. When you turn merge mode on for all the GPOs, it becomes more obvious what will happen. In each case, the policies relating to the user are applied first, in order, followed by the entire set of policy items that would apply to a user residing in the computer location. Take the example of a finance user logging on at a marketing computer in the main site:

Remember that policies applied later can override the policies that were applied earlier, so the user portions of the policies applying to the location of the computer will always override previous policies if there is a conflict. With policy order ABEFABCD, D can override C, which can override B, which can override A, which can override F, and so on. Also, in all these cases, if any of the computer GPOs do not have any defined settings in the user portion, those policies are ignored.

Loopback replace mode is used when the user portions of the GPOs that apply to a computer are to be the only ones set. For the finance user logging onto a marketing computer in the main site, the only policies that get applied to that user are ABCD, the user portions of the GPOs that apply to the marketing computer.

Windows Management Interface filtering enables you to associate a WMI query with a GPO, which will run for each user and computer to which the GPO applies. A WMI filter can utilize any WMI-based information that is accessible from the client’s machine, including computer hardware and configuration, user profile, and environment settings. This presents a lot of options for targeting GPOs to clients that have certain properties.

For example, let’s say you want to apply a certain GPO if a client is accessing your network over a virtual private network (VPN) connection. Depending on which VPN software the client is running, your WMI query could check for the existence of a process or service, or even an IP address range. If the query returns true, the GPO will be applied; if it returns false, it will not be applied.

That’s a lot of information on GPOs. Let’s summarize what we’ve covered about the workings of GPOs so far:

The GPMC is a one-stop shop for all your GPO management needs. You can browse a forest and see where GPOs are applied, you can create and link GPOs, and you can import and export, back up and restore, delegate control, and view RSoP reports, all from the GPMC.

When you open the GPMC, it will default to showing the domain in which your user account is located. If you need to edit GPOs in another forest, right-click the Group Policy Management node in the tree and click Add Forest. If you need to edit GPOs in another domain in the forest, right-click the Domains node and click Show Domains.

When you are editing GPOs, the Group Policy tools connect to and use the PDC emulator FSMO role owner by default. This ensures that multiple copies of the GPME on different machines are all focused on the same DC. This behavior may be overridden if the PDC is unavailable. If this happens, the GPMC will display an error dialog and the administrator may select an alternate DC to use. An administrator can also manually target a different domain controller in the GPMC.

If GPOs are edited on multiple DCs, this can lead to inconsistencies because the last person to write to the GPO wins. For this reason, you should avoid editing GPOs on multiple DCs.

Refer back to Figure 11-7 to see what the GPMC looks like when viewing a GPO. As you can see in the left pane, you can browse through the domains in a forest down to specific organizational units. If you right-click on an organizational unit, you’ll get many of the same options as shown in Figure 11-6.

In Figure 11-7, the Desktops organizational unit has been expanded to show that the Desktop Policy GPO has been linked to it (i.e., icon with a shortcut/arrow symbol). A virtual Group Policy Objects container is expanded, which shows all of the GPOs that have been created in the domain. There is also a virtual WMI Filters container that holds any WMI filter objects that have been created. Note that the Group Policy Objects, WMI Filters, and Starter GPOs containers are virtual. By virtual, we mean that the GPMC is simply displaying these objects in dedicated containers to make the GPMC more useable. In reality, these objects are not stored in dedicated containers in Active Directory.

If we take a look at Figure 11-7 again, we can see that Desktop Policy was selected in the left pane, and several options and settings are displayed in the right pane. The following list is a summary of what’s available on each tab:

While the GPMC is used for creating and managing the application of GPOs, actually editing the contents of a GPO requires another tool, known as the Group Policy Management Editor (GPME). The GPME can be launched from the GPMC for any GPO by right-clicking and selecting Edit, as shown in Figure 11-10. Inside the GPME, settings are divided under Computer Configuration and User Configuration, and then again under Policies and Preferences. Policies are the settings you’re used to if you’ve worked with Group Policy before. Preferences might be new to you—we’ll take a look at the group policy preferences functionality that Microsoft acquired in 2006 in the next section.

Figure 11-10. Group Policy Management Editor

We won’t spend too much time on the Policies section of the GPME, as each setting is a bit different in terms of how it is configured, but you should take some time to click through and become familiar with the interface.

You’ll find that the bulk of the policies you might want to apply are located under the Administrative Templates section of the interface. If you’re not sure where to find what you’re looking for, there are a couple of resources at your disposal. First, you can right-click Administrative Templates and select Filter Options. From here you can configure a keyword search of all the settings available, as well as filter based on what products or versions of Windows they apply to. In Figure 11-11, we’re looking for settings that contain the word “screensaver” that have been configured in the policy. Once you’re done searching, right-click again and uncheck Filter On, or click the filter button in the GPME toolbar to remove the filter.

Figure 11-11. Administrative Templates filtering options

If you’re simply looking for a specific setting in order to configure it or understand what it does, you might find the free web-based Group Policy Search tool at http://gps.cloudapp.net useful. This tool allows you to filter, do more complex keyword searches, and review all of the data from the ADMX files that is also displayed in the GPME.

One of the relatively new features of the GPME is the ability to attach comments to Administrative Template settings, as shown in Figure 11-12. Previously you had to document your group policy choices in a separate tool (or, as is the case at many companies, not at all). With the comment functionality, your group policies can become self-documenting. You can leave a reminder for yourself about why a setting is in place, and ensure that future administrators aren’t left guessing.

Figure 11-12. Adding comments in the GPME

Microsoft acquired a company called DesktopStandard in 2006, and as part of that deal it acquired a product called PolicyMaker. PolicyMaker morphed into group policy preferences and started shipping with Windows with Windows Server 2008. With group policy preferences, you can graphically configure many components of the desktop experience that previously required complex startup and logon scripts. Some of the highlights of group policy preferences functionality include:

Take a look under Preferences in the GPME to explore all of the different options you can configure with group policy preferences. Microsoft has also published a whitepaper about group policy preferences that you can download from http://bit.ly/14lRcbp.

Group policy preferences work a bit differently than normal group policyies in terms of their application. Namely, the settings are only applied during startup and logon. Background refreshes of GPOs will not apply the preferences settings. Because of this, preference settings are not enforced in the same way as normal policies. Users can often work around or undo the changes that are made by group policy preferences.

With most Group Policy settings, when you remove a setting from a policy or a machine from the scope of a policy, those settings will be removed. Group policy preferences, on the other hand, do not behave this way. If, for example, you map a drive with group policy preferences, you will need to create a preference item to un-map that drive rather than simply deleting the drive mapping preference. This behavior is controlled with the Action option in the properties of each preference item, as shown in Figure 11-13.

Figure 11-13. Preference action options

You have four options when configuring the behavior of a preference item:

Item-Level Targeting

One of the really powerful features of group policy preferences is known as item-level targeting (ILT). ILT allows you to control the application of settings on a per-item basis based on granular expressions that rely on dozens of properties of the user and computer to which the policy applies. Normally, to filter what settings apply to different sets of users or computers, you need to create separate GPOs and then apply security filtering or a WMI filter. With ILT, you can filter individual preferences within a GPO.

To configure ILT for a preference, open Properties, then select the Common tab. On the Common tab, check “Item-level targeting” as shown in Figure 11-14, and click Targeting.

Figure 11-14. Mapped drive preference settings

Figure 11-15 shows a sample usage of ILT. In this example, users who are in the Executives group, and users who are both in the Finance Department and are Headquarters Employees will receive the preference. Other users will not.

Figure 11-15. Sample item-level targeting

Logon scripts have been a facet of Windows domains since Windows NT. You can still define a single logon script to be run on the properties of a user account in Active Directory, and Windows clients will run the script at logon; however, Group Policy offers a much richer experience for logon scripts. You can run multiple scripts at logon, and in addition you can define scripts that run during logoff, computer startup, and computer shutdown. While this functionality is generically referred to as “scripts,” you can run batch files, Visual Basic (VB) scripts, executables, or Windows PowerShell scripts.

You can specify one or more logon or logoff scripts in a Group Policy with the GPME. The logon and logoff script settings are located under User ConfigurationPoliciesWindows SettingsScripts (Logon/Logoff). Double-click the Logon node to configure logon scripts. On the Scripts node you can specify any type of script or executable except Windows PowerShell scripts. PowerShell scripts are specified on the PowerShell Scripts node. The only difference in configuring PowerShell scripts versus standard scripts is that Group Policy allows you to define whether PowerShell scripts are run before or after the scripts/items specified on the Scripts tab.

Figure 11-16 shows a single VB script configured to run at logon. When you configure any type of script (logon/logoff or startup/shutdown), you will need to store the file (and any dependencies) in a location that is accessible to all of the users or computers that will be executing the script. Generally speaking, the easiest place to store these files is inside the Group Policy template (GPT) folder in Sysvol. By placing the files inside Sysvol, you ensure that all of the domain controllers in the domain will be able to replicate the files alongside the GPOs they are associated with.

Figure 11-16. Logon script configuration

If you click the Show Files button in Figure 11-16, Windows Explorer will open to the scripts folder specific to the GPO you are editing and the type of script. You can use this handy shortcut to drag and drop files into the GPT location in Sysvol.

Logon (and startup) scripts are extremely common in organizations that have adopted Group Policy. These scripts are often used to configure common user experience settings such as drive mappings or printers, or perhaps to update the configuration of computers in the domain. The downside of running scripts at logon or computer startup is that they can cause noticeable performance issues.

Even the best-written scripts can encounter a scenario that the script writer didn’t think of, and when that scenario comes about, computer performance can be adversely affected. For this reason, we have placed the section on scripts and Group Policy after the section on group policy preferences. In our experience, the vast majority of tasks administrators are performing with a logon or startup script can be completed with group policy preferences. With this in mind, wherever possible, we recommend the use of group policy preferences over logon scripts and startup scripts.

While the Group Policy Results Wizard allows you to see the effective settings for a user and/or computer, it is dependent on that user having logged into the computer in question before. The GPMC includes a second wizard that is helpful for generating “what-if” reports for various scenarios. You can specify a specific user and computer to model or specific locations in the OU hierarchy, as shown in Figure 11-17.

Figure 11-17. Group Policy Modeling Wizard

The wizard will allow you to simulate conditions such as slow links, loopback processing, or site affinity, as shown in Figure 11-18. You can also simulate a change to the user or computer’s security group membership if, for example, you are testing changes to security filtering for a policy. Figure 11-19 shows the report that is created by the GPMC. The Summary and Settings tabs are similar to the results reports, and the Query tab displays a summary of the parameters you specified in the modeling wizard.

Figure 11-18. Simulating network conditions and loopback processing

Figure 11-19. The Group Policy modeling report

Like with the Group Policy results reports, you can rerun and export modeling reports as well as view the RSoP MMC by using the “Advanced View” right-click option.

When planning your group policy deployment, you have to work out how you will maintain firm control over GPOs once you start deploying them. Specifically, you need to consider who will be managing your GPOs and how you will keep control over the wide-ranging changes they can make.

One of the new features for Group Policy beginning with the Windows Server 2008 toolset is Starter GPOs. Starter GPOs allow you to define a template GPO that can then be duplicated in the GPMC. Starter GPOs are stored and replicated alongside normal group policies in the Sysvol container, in a new folder called StarterGPOs.

The first time you access the Starter GPOs node in the GPMC, you will be prompted to create the StarterGPOs folder in Sysvol. Starting with Windows Server 2008 R2, a series of read-only Starter GPOs are automatically created. These Starter GPOs include the settings necessary to implement the Windows XP SP2 and Windows Vista Security Guides from Microsoft. At the time of writing, there were no comparable Starter GPOs for Windows 7 or Windows 8. In addition, read-only Starter GPOs to enable the necessary ports for Group Policy remote management through the Windows Firewall are included.

Creating a Starter GPO is nearly identical to creating a normal GPO. Simply right-click the Starter GPOs virtual container in the GPMC and click New.

You may have noticed that the New GPO dialog has an additional selection for the Starter GPO, as shown in Figure 11-21. If you select a Starter GPO at this time, the settings from that Starter GPO will be imported into your new GPO, providing a baseline to start with.

Figure 11-21. New GPO with Starter GPO

Restoring the Sysvol container from a system-state backup of a domain controller is an involved and somewhat painful process. Fortunately, with the introduction of the GPMC, there is an easy GUI and script-based mechanism for backing up and restoring some or all of your group policies. To back up all of the group policies in the domain with the GPMC, right-click on the Group Policy Objects virtual container and select the Back Up All option. You will be presented with a dialog similar to Figure 11-22. You must provide the GPMC with a path to an empty folder to back up all of the GPOs to, and optionally a comment to include in the backup. Once the wizard completes, you can zip the target folder and have a portable and easy-to-work-with backup.

Figure 11-22. Group Policy backup

If you want to back up an individual policy, simply right-click it under the Group Policy Objects container and select Back Up. The GPMC only supports restoring policies on a per-policy basis. To restore a policy, right-click it under the Group Policy Objects container and select “Restore from Backup.” The wizard will prompt you for the path to the backup. You must point the wizard to the parent folder of the backup. Thus, if you were restoring from the backup created in Figure 11-22, you would point the restore wizard to C:GPOBackup.

If you need to restore all of the GPOs in a backup at once, you can use the RestoreAllGPOs.wsf script that is included in the GPMC sample scripts discussed in the Scripting Group Policy section of this chapter. Similarly, you can use the BackupAllGPOs.wsf script to back up all of the GPOs in a domain. There are also individual group policy backup and restore scripts called BackupGPO.wsf and RestoreGPO.wsf, respectively. In addition to these scripts, you can take advantage of the Backup-GPO and Restore-GPO cmdlets included with Windows Server 2008 R2 and newer.

You can also use the GPMC backup and restore functionality to copy group polices between domains, or perhaps between a test environment and production. The GPMC includes a Migration Table Editor tool that will be invoked when you need to modify references to security principals in the source domain so that the policy will continue to function in the target domain. For more information on migrating group policies, see the whitepaper Migrating GPOs Across Domains with GPMC.

Historically, one of the hurdles to efficiently managing GPOs with Active Directory has been the lack of scripting support. The GPMC provides a number of scripting capabilities via COM-based objects that can be accessed from VB scripts, PowerShell, and so forth. Windows Server 2008 R2 introduced a number of PowerShell cmdlets for use with Group Policy, and Windows Server 2012 expanded on this selection.

There are a number of useful sample scripts (over 30) for working with the GPMC that Microsoft distributes freely on its website. Once you download and run the installer, the scripts will be stored in %ProgramFiles%Microsoft Group PolicyGPMC Sample Scripts.

The following is a partial list of some of the tasks you can perform via scripts with the GPMC objects:

The PowerShell cmdlets that come with Windows Server 2008 R2 and Windows Server 2012 enable you to script the creation and management of GPOs as well as report on and script settings that are set via administrative templates. You cannot script settings that are set with client-side extensions, such as for the Windows Firewall or Restricted Groups. Table 11-5 provides a listing of the PowerShell cmdlets for Group Policy as well as their purposes.

In addition to the cmdlets included with Windows, there are a number of third-party management extensions for Group Policy that deliver a great deal of value. One company that offers a number of PowerShell-based solutions is SDM Software at http://www.sdmsoftware.com.

The Windows Server 2012 GPMC includes a new health report for Group Policy that focuses on Active Directory and Sysvol replication status. The health report checks the status of each group policy in the domain and ensures that the policy and its associated metadata are consistent across all of the domain controllers in the domain. In order to do this, the GPMC selects one domain controller as the baseline and then compares each domain controller against that baseline.

You can access the infrastructure status by clicking on a domain in the GPMC and then opening the Status tab. Figure 11-23 shows the status for a domain that is in good health.

Figure 11-23. Group policy infrastructure status

The Group Policy Results Wizard is a frontend for the Resultant Set of Policy tool. RSoP is a very powerful tool that will identify what GPO settings have been applied to a user or computer. Before RSoP, administrators were left to do their own estimates as to what GPOs took precedence and what settings were actually applied to users and computers. RSoP removes much of the guesswork with an easy-to-use wizard interface.

Windows Server 2012 improves the RSoP reporting to include a number of additional data points. These include the processing time for each CSE in the policy, the policy that contributed each setting, loopback processing and link speed data, and whether inheritance blocking was a factor in the resultant policy set.

To start the Group Policy Results Wizard, open the GPMC, right-click the Group Policy Results folder, and launch the wizard. Figure 11-24 shows the initial screen, where you will be prompted to select a target machine to run the RSoP session on.

Figure 11-24. Group Policy Results Wizard—target computer selection

The next screen, as shown in Figure 11-25, allows you to optionally specify a particular user for whom to display the policy settings. If you only need computer settings, you can skip this step. The wizard will only display users who have logged onto the target machine successfully in the past.

Figure 11-25. Group Policy Results Wizard—target user selection

Once you finish the wizard, the GPMC will create a report similar to the one shown in Figure 11-26. This report is divided into three sections:

Figure 11-26. Group Policy Results report

One of the nice features of the Group Policy Results tool is that the reports are saved, so you can reference them later. You can also right-click the report in the tree at the left and rerun the query or export the report.

You can also run an RSoP session from the command line; see the sidebar Using the GPResult Tool.

 gpresult /v

 gpresult /v /USER otherusername

 gpresult /v /S othercomputer

Sometimes when troubleshooting an issue, you may not want to wait for a policy to refresh in the normal time period. Fortunately, there is a command-line tool to force an update called gpupdate. You can simply run gpupdate to update the group policy settings; however, there are other options available that are documented if you run gpupdate /?. Windows 8 and Windows Server 2012 clients also include the Invoke-GPUpdate PowerShell cmdlet that offers the same functionality as gpupdate.

The version of GPMC included with Windows Server 2012 (and the accompanying PowerShell cmdlets) introduces the ability to remotely refresh group policies on one or more machines. This feature works by remotely creating a scheduled task on the target machine(s) that refreshes the group policies locally. You can use this feature with clients running Windows Vista or newer and servers running Windows Server 2008 or newer. In order to schedule the task, the machine you are running GPMC from must have access over the network (e.g., through firewalls) to run remote procedure calls (RPCs) to the target machines. If you are using the Windows Firewall, you will need to either deploy the Group Policy Remote Update Firewall Ports Starter GPO in advance or open the ports and services listed in the Starter GPO on each client.

To remotely refresh group policies for all of the machines in a specific organizational unit, you can right-click the OU in the GPMC and click Group Policy Update. You will receive a confirmation prompt similar to Figure 11-27 that tells you how many machines will be affected by the request. After the request begins, the GPMC will provide you with a live status report, as shown in Figure 11-28. The status report confirms that the group policy refresh has been scheduled on the remote machine but not whether or not the refresh has succeeded. You can export the results to a CSV file for manipulation with a script or Microsoft Excel by clicking the Save button.

Figure 11-27. Remote group policy update confirmation

Figure 11-28. Remote group policy refresh status report

When Group Policy works, it is an extremely valuable tool to administrators. But as with any technology, from time to time you may need to dig into what’s going on behind the scenes in order to troubleshoot an issue with Group Policy. Fortunately, Group Policy comes with a large amount of diagnostic logging that can be enabled when you need to troubleshoot a problem. The format of the logging and how you enable it varies depending on the version of Windows.

Microsoft has a free tool available from its website called the Group Policy Diagnostic BPA. BPA stands for Best Practices Analyzer, and it’s a breed of tool Microsoft has been releasing for various tools and products over the past several years. The Group Policy Diagnostic BPA can help with troubleshooting. To get the most appropriate version of the tool for your environment, go to http://support.microsoft.com/kb/940122.

Independent software vendor SDM Software has developed a Group Policy troubleshooting toolset that can visually report on Group Policy processing health on clients, and visually analyze many of the logging options discussed earlier in this chapter. For more information, visit http://www.sdmsoftware.com/products/freeware/.

The GPO Guy community website is also an excellent resource for Group Policy information. The site provides free tools, and hosts an email discussion list for Group Policy topics.