The Birth, Life, and Death of a GPO

Now that you understand where GPOs actually live, we can take the next step: understanding the "journey" of a GPO. Specifically , a GPO is born and must stay healthy if it's going to stay alive . If its usefulness becomes depleted, you can call in the Sopranos boys to whack itnever to be seen again.

How Group Policy Objects Are "Born"

Before you can give birth to GPOs, you need rights to do so, and you can get these rights in two ways. First, you can be a member of the Group Policy Creator Owners Security group. You can also be granted explicit rights via the Delegation tab in the Group Policy Objects container via the GPMC (as you saw in Chapter 2).

A new Group Policy Object is born when you right-click the Group Policy Objects container and choose "New." Now you're setting into motion a specific chain of events.

First, the PDC Emulator is contacted to see if it's available for writing. If not, the user is prompted about how to proceed, as shown in Figure 4.1.

Figure 4.1: If the PDC Emulator is not available for writing, the user is prompted for an alternate location.

GPOs are initially born in the PDC Emulator, and then, a bit later, they are replicated to the other Domain Controllers within the site and then between sites. Assuming the PDC Emulator is available, you can give your GPO a friendly name , say "Hide Settings Tab / Restore Screen Saver Tab," as we did in Chapter 1.

Once that happens, your GPO is officially "born." The PDC Emulator has already performed certain functions on your behalf :

• It created a Group Policy Container (GPC) in the "Policies" folder of the Configuration container in the Active Directory database. Think of this as a reference in Active Directory for your new GPO.

• It created a Group Policy Template (GPT) in the SYSVOL directory of the PDC Emulator. This is where the real files that make up your GPO live. They're replicated to every Domain Controller for quicker retrieval.

• Additionally, if "Create and link a GPO here " is used when focused on the domain or OU level (or the old-school interface is used), the new GPO you just created is automatically linked to the current level you were focused atsite, domain, or OU.

• The GPO is given a unique ID that takes its form as a globally Unique Identifier (GUID).

When you inspect the properties of any new GPO, you'll see the unique ID it is automatically given, as shown in Figure 4.2.

Figure 4.2: Every GPO gets a unique name.

So, every GPO is made up of two components (the GPC and GPT), and those components are split between two places inside that Domain Controller. The good news, though, is it all ties back to the GPO's GUID. We'll explore each of these components in the next two sections.

How a GPO "Lives"

A GPO in Active Directory is made up of two constituent parts. One part isn't enough, and the GPO cannot live without both parts. Both parts are required in order to communicate the GPO message.

As we'll see in a bit, and the GPO derives its life from these two parts.

Group Policy Containers (GPCs)

The Active Directory holds GPCs, which hold multiple properties of the Group Policyfor instance, version and status information and some policy settings. A GPC has a name that takes the format of a globally unique identifier (GUID)see the sidebar that follows . The underlying name is not the friendly name we use when administrating the GPO.

You can see the GPCs for every Group Policy you create by diving into the Active Directory Users And Computers console.

To view the GPCs and their GUIDs, follow these steps:

1. Log on to the server WINDC01 as Administrator of the domain.

2. Choose Start ˜ Programs ˜ Administrative Tools ˜ Active Directory Users And Computers.

3. Choose View ˜ Advanced Features, as shown in Figure 4.3, to display the Policies folder.

4. Expand the System folder to display the Policies folder along with the GPCs, as shown in Figure 4.4.

Figure 4.3: Turn on the "Advanced Features" setting to see the Policies folder (and a whole lot more).

Figure 4.4: Expand the Policies folder to expose the underlying GPC objects.

GPC Attributes

When a GPC object is created, it is given several attributes:

• Common Name (CN) In Active Directory, you'll see attribute is really called cn. An LDAP (Lightweight Directory Access Protocol) designation for the name assigned to an object. GPC names use the GUID format to ensure uniqueness throughout a forest. For example, CN=2C53BFD6-A2DB-44AF-9476-130492934271 .

• Distinguished Name (DN) In Active Directory, you'll see attribute is really called distinguishedName. The object's common name plus the path to the object from the root of the LDAP tree. For example, CN=2C53BFD6-A2DB-44AF-9476-130492934271, CN=Policies, CN=System, DC=corp, DC=com .

• Display Name In Active Directory, you'll see attribute is really called displayName.The friendly name assigned to the Group Policy in the user interface, for example, the Hide Screen Saver Tab GPO.

• Version In Active Directory, you'll see attribute is really called versionNumber . A counter that keeps track of updates to a GPC object (more on this topic a little later).

• GUID In Active Directory, you'll see attribute is really called objectGUID .The GUID assigned to the object itself. Active Directory uses the object's GUID as a reference for handling table moves, building indexes, and doing other database activities.

You might find it a little confusing for the GPC object to have a GUID that refers to the object itself and a name that uses a GUID format. For an important reason, Microsoft needed a way to make the underlying, real name of GPOs unique, independent of their friendly names. Suppose two administrators create two (or more) GPOs with the same friendly name on their own Domain Controllers. When these GPC objects replicate, one of them would have to be discarded, overwritten, or renamed , depending on the exact circumstances of the replication collision. That could be a bad thing. Therefore, Microsoft solves this problem by using underlying unique names formatted with the GUID format. There is a negligible chance of identical GUIDs being created, not only within one Active Directory but also across the entire world, should the need arise to coexist with GPOs in other forests (such as with cross-forest trusts).

To see the major attributes for the GPC objects in your domain, take a look at Chapter 7. You'll find a Visual Basic (.vbs) script that lets you see (and document) these objects.

 

Up until this point, we've been using the GPMC interface to create GPOs. When we use the GPMC to create GPOs, we've made reference to the Group Policy Objects container within the GPMC as representation of the swimming pool. But the GPMC isn't showing you the real swimming poolit's showing you a representation of the swimming pool. Here is the GPC part of the swimming pool. The other "half" of the swimming pool is the GPT, the files that live in the SYSVOL in Active Directory.

Again, this Policies folder equates to the Group Policy Objects container when viewing GPOs from the GPMC. You should see one folder for every GPO you have created, plus two more for the two default GPOs (which we'll explore in Chapter 6). In this example, I have lots of GPOs already created; therefore, I have lots of folders. You might have fewer.

When you try to drill down into the subfolders , some will and some will not expand past the { GUID }\Machine and { GUID }\User levels. Those that do expand do so because you have set up features in that specific GPO that Active Directory needs to maintain information on, such as when you Publish or Assign applications. We'll explore Publishing and Assigning applications in great detail in Chapter 10.

Don't be surprised if, at this stage in working through the book, you do not have any fully expandable subfolders as shown in Figure 4.4. The subfolders that don't expand do not require additional Active Directory references. Everything else the GPO needs to be useful is stored in the GPT, which is explored in the next section.

Who Really Has Permissions to Do What?

In Chapter 2, we applied various permissions on the GPO, including who had "Read" and "Apply Group Policy" permissions, as well as who could see the settings or edit the stuff inside the GPO. The locking mechanism for "Who really has what permissions" on a specific GPO is found right here, at the Policies folder:

• On the one hand, the locking mechanism on the Policies folder itself dictates who can and cannot create GPOs.

• On the other hand, the locking mechanism on the GPC folders underneath the Policies folder (with names of GUIDs) dictates which users have access to "Read" and "Apply Group Policy", or change the GPO itself.

Who Can Create New Group Policy Objects?

Right-click the Policies folder, and select Properties, then click the Security tab to display several names, some of which should be familiar, including the Group Policy Creator Owners and the Domain Administrators group. Additionally present will be anyone you explicitly added via the Delegation tab upon the Group Policy Objects container in GPMC. You saw how to do this in Chapter 2. At that time, we added a user named Joe User from our domain.

If you examine the properties of the Policies folder (as shown in Figure 4.5), you'll see the Group Policy Creator Owners group. Joe is also listed (because he was expressly granted permission via the GPMC). Note also that the Domain Admins and Enterprise Admins groups are also present, but those names are at the top of the list, so you can't see it in Figure 4.5.

Figure 4.5: Expand the Policies folder to expose the underlying GPC objects.

You can click the Advanced button to display Joe's precise "Special Permissions." Indeed, Joe has only one permission, and it's called " Create groupPolicyContainer Objects ." Once he has this right, the system permits him to create GPC folders and populate them with Group Policy information when he creates a new GPO.

The Group Policy Creator Owners group has many, many more unnecessary permissions on the Policies folder, including "Create all child objects," "Create User Objects," and a whole lot of stuff that, really, doesn't have anything to do with Group Policy. Indeed, if you log on as someone in the Group Policy Creator Owners group and right-click the Policies folder, you can do some things you really shouldn't do, as you can see in Figure 4.6.

Figure 4.6: For the love of Pete, please don't do this.

Note 

The system (thankfully) won't let you do all the functions listed here, but it does let you do someof them. And, again, you really shouldn't be poking around like this. However, I show you these things for demonstration purposes so you can get a better feeling for what is different between someone in the Group Policy Creator Owners Group versus someone who has been explicitly delegated rights via the Delegation tab upon the Group Policy Objects container in GPMC.

The Domain Administrators group and the Enterprise Administrators group also have explicit permissions here. When they create new GPOs, they do so because of their explicit permissions, not because they are members of the Group Policy Creator Owners group.

Who Can Manipulate and Edit Existing Group Policy Objects?

Right-click a GPO folder (with the name of a GUID) under the Policies folder and choose Properties to display the Security tab (see Figure 4.7), which will show the same information as when, in Chapter 2, you used the Deny attribute to pass over certain security groups. That is, the same information is shown here as when we clicked the "Advanced" button in the Delegation tab when focused on the GPO (or GPO link, because it's using the same information taken from the actual GPO).

Figure 4.7: Each GPC can display the underlying permissions of the GPO.

Unless otherwise delegated, the person or group who created the GPO is the only one who can modify or delete the GPO. However, this may be a particularly sensitive issue if you have many Domain Administratorsas they all have "joint ownership" of the GPOs they create. There is a serious potential risk in one administrator taking the reins and modifying another administrator's GPOs.

However, as you saw in Chapter 2, you can also grant someone explicit rights via the Delegation tab upon the GPOs container via the GPMC. In this example, I have done this for Joe. Figure 4.8 shows the properties of a GPO that Joe has created.

Figure 4.8: If Joe creates a GPO, he owns the GPO. No one else (other than Domain Admins or Enterprise Admins) can edit it.

Since Joe has explicit permissions to create GPOs, he becomes the owner of the GPOs he creates. You can clearly see that Joe created it, and now he owns it. Hence, Joe doesn't have to worry about other explicitly anointed users or groups changing the GPOs he creates and owns. Note, however, that the Domain Administrators and Enterprise Administrators group will, in fact, be able to change any GPOs that Joe creates. Additionally, note that other users of Group Policy Creator Owners cannot dive in and edit Joe's GPOs. AgainJoe owns it; it's his.

Using LDP to see the Guts of a GPC

The GPC object itself holds even more critical attributes for GPOs:

gPCFileSysPath The physical path to the associated Policies folder, or GPT, stored in SYSVOL. The Policies folder has the same name as the GPC, which is another reason that uniqueness is so important. The GPT is discussed in the next section.

gPCMachineExtensionNames This is a list of GUIDs of the CSEs (client-side extensions) that will be called for this particular GPO. For instance, if a GPO involves the Administrative Templates node in the Group Policy Object Editor, the gPCMachineExtensionNames list includes the QUID of the Registry processor client-side extension. CSEs are discussed later in this chapter in the "How Client Systems Get Group Policy Objects" section.

gPCUserExtensionNames This is a list of the GUIDs of the CSEs called by a user- related Group Policy. Again, I'll discuss CSEs a bit later in this chapter.

When you try to dive in and view these attributes using Active Directory Users And Computers, you cannot see them. The only way to see them is to use the LDP tool, which is an LDAP browser tool. This tool is found by loading the support tools from the SUPPORT\TOOLS folder on the Windows Server 2003 CD.

LDP lets you perform LDAP queries right into the actual guts of Active Directory. Using LDP, you can see these attributes. Normally, you wouldn't want or need to go poking around in here, but taking the time to learn just where attributes are can help in your understanding of what constitutes a GPO.

To query a specific GPO to see its underlying attributes, follow these steps:

1. After loading the Support tools on the Domain Controller, choose Start ˜ Run to open the Run dialog box, and in the Open field, type LDP and press Enter to select the domain of your choice.

2. Choose Connection ˜ Bind and in the dialog box type the administrative credentials to the domain. In the Domain field, you'll need to type the DNS name of the domain, for example, corp.com. If you successfully connect, you'll see your first query results in the right pane of the LDP window.

3. Choose View ˜ Tree to open up a dialog that lets you specify the distinguished name of the domain. If your domain is corp.com, enter dc=corp, dc=com. If you do that correctly, your left pane will show the domain name with a plus (+) sign. You should be able to double-click the plus sign and expand the contents within the domain.

4. Find the System container and double-click it to expand it.

5. Find the Policies container and double-click it to expand it.

6. Find the unique name of the GPO you want to inspect and double-click it to expand it. (For information about how to find a specific unique name of a GPO, see the earlier section "How Group Policy Objects Are 'Born'.") In the following illustration, the attributes are highlighted.

Once you find the unique name, the resultant LDP query will show you the properties on that GPO.

There is one more important attribute to inspect by using LDP: gPLink. Recall that a GPO can be linked by one level, multiple levels, or no levels. If a GPO is to be linked to a site, a domain, or an OU, that level needs to have a pointer or linkto the GPO. When clients log on (computer and user), they use LDAP to query to each level they are a part of (site, domain, OUs) to find out if the level has any gPLink attributes. If so, the client makes an LDAP query to find out what GPOs are meant for it. With the information in hand, it determines what files to download from the SYSVOL share on its logon server. (You can see these queries happening for yourself, when you inspect Userenv.log, explored later in the section "Turning On Verbose Logging.")

To see the gPLink attribute, you can simply click the level you want to inspect. In this case, click the Human Resources Users OU you created in Chapter 1.

In the right pane, find LDP's query results. The gPLink attribute has LDAP pointers to the unique names of the GPOs. In this case, the Human Resources Users OU has links to both the "Hide Settings Tab/Restore Screen Saver Tab" GPO, in my case, {9A3B670A-3280-4687-A80A-4C8196262B7D}. If you clicked the Human Resources Computers OU, you should see the "Disable Task Scheduler" GPO, again, in my case {965BAA1A-C60B-4C55-ADA0D79598D668B6}.

 

Group Policy Templates

As we just learned, GPCs are stored in the Active Directory database and replicated via normal Active Directory replication. A Group Policy Template (GPT) on the other hand, is stored as a set of files in the SYSVOL share of each Domain Controller. Each GPT is replicated to each Domain Controller through FRS (File Replication Service).

When we used the Properties tab of the GPO, we were able to find its unique name (as we did earlier in Figure 4.2). We can use the same unique name to locate the GPC in Active Directory, and it's the same unique name we can use to locate the GPT in the SYSVOL.

To see the GPTs in SYSVOL, follow these steps:

1. Open Windows Explorer.

2. Change the directory to the SYSVOL container. Its usual location is C:\Windows\ SYSVOL \SYSVOL\{ domain name} (in this case, C:\Windows\SYSVOL\SYSVOL\ corp.com).

3. Change into the Policies folder. You'll see a list of folders. The folder names match the GPC names stored in Active Directory (seen in the previous exercise). Figure 4.9 shows a Policies folder containing many GPOs.

Figure 4.9: The unique names of the GPOs are found as folder names in SYSVOL. This is the unique name for the "Hide Settings Tab/Restore Screen Saver Tab" you saw in Figure 4.2 earlier.

Double-clicking a Policies folder inside SYSVOL displays the contents of the GPT. Inside, you'll see several subfolders and a file:

• \Adm As you'll learn in Chapter 5, the Administrative Templates policy settings are really generated from listings inside plain-old text files with a .adm extension. When an Administrative Templates policy is created or modified, the Group Policy Object Editor copies these .adm files from the \Windows\INF folder. By default, those .adm files are Conf.adm, Inetres.adm , and System.adm . Hang tight. You'll find more info about this as you hit Chapter 5. Double-clicking the \Adm folder displays the templates. Note that the \Adm folder will not exist until the GPO is opened for the first time and you click either the Computer or the User node.

• \Machine This folder contains the settings for the computer side of the GPO, including startup and shutdown scripts, pointers to applications that are assigned, and Registry settings (among other settings). The actual contents of the \Machine folder depend on the computer options specified in the GPO. The potential contents include the following:

  • The Registry.pol File Holds the Registry settings set in Computer Configuration ˜ Administrative Templates.

  • The \Applications Folder Stores pointer files called Application Assignment Scripts, or AAS files. These files are used in conjunction with Group Policy Software Deployment. These are the instructions that the client computers use to process Software Installation. Software Installation is further discussed in its own chapter, Chapter 10.

  • The \Microsoft\Windows NT\Secedit Folder Stores a file called Gpttmpl .inf. This file holds various computer security settings, defined under the Computer Configuration ˜ Windows Settings ˜ Security Settings portion of the GPO. You can also set up these settings in advance and deploy them en masse using the techniques described in Chapter 6.

  • The \Scripts\Shutdown Folder Contains the actual files used for computer shutdown scripts. Can be of any scripting file type, including . bat, .cmd, .vbs, .js, and others. You'll see how to use this in Chapter 6.

  • The \Scripts\Startup Folder Contains the actual files used for computer startup scripts. Can be of any scripting file type, including . bat, .cmd, .vbs, .js, and others. You'll see how to use this in Chapter 6.

• \User This folder contains the settings for the user side of the Group Policy coin, including logon and logoff scripts, pointers to applications that are published or assigned, and Registry settings. Depending on the options used on each GPO, it represents what is in the \User folder under the computer side of the GPT.

  • The Registry.pol File Holds the Registry settings set in User Configuration ˜ Administrative Templates.

  • The \Applications Folder Stores pointer files called AAS files for files deployed with Group Policy Software Deployment.

  • The \Documents and Settings Folder Contains a file called Fdeploy.ini, which stores applicable Folder Redirection settings. Set up Folder Redirection as described in Chapter 9.

  • The \Microsoft\IEAK Folder Stores files to represent the changes made in User Configuration ˜ Windows Settings ˜ Internet Explorer Maintenance.

  • The \Microsoft\RemoteInstall Folder Stores Oscfilter.ini, which specifies Group Policy Remote Installation Services settings. See Chapter 11 for how to set up Remote Installation Services and manage it with Group Policy.

  • The \Scripts\Logon Folder Contains the actual files used for user logon scripts. Can be of any acceptable file type, including . bat, .vbs, .jS, and others. You'll see how to use this in Chapter 6.

  • The \Scripts\Logoff Folder Contains the actual files used for user logoff scripts. Can be of any acceptable file type, including . bat, .vbs, .js, and others. You'll see how to use this in Chapter 6.

  • GPT.INI The one file you will always find under the GUID folder. It holds the Version Number of the GPT. (You'll read about version numbers in the next section.)

Verifying that GPCs and GPTs are in Sync

The two pieces of information that make up a GPO are GPCs and GPTs:

• GPCs are stored in the Active Directory database and are replicated via normal Active Directory replication.

• GPTs are stored in the SYSVOL folders of every Domain Controller and are replicated using FRS replication.

Here's the trick: In most cases, for Group Policy to be applied on workstations, both the GPC and the corresponding GPT need to be synchronized. Synchronization simply means that the Domain Controller in which a user authenticates has a copy of both the GPC object in Active Directory and the GPT files in SYSVOL.

Recall that both the GPC and GPT are originally written to the PDC Emulator by default. Once they're written, the goal is to replicate the GPC and GPT to other Domain Controllers. With just one Domain Controller in a domain, there are no replication issues, because there are no other Domain Controllers to replicate to; it's all happening on one system. But when multiple Domain Controllers in a domain enter the picture, things get a little hairier. This is because normal Active Directory replication and FRS replication are on completely independent schedules (though under normal circumstances, they take the same path).

An administrator can create or modify a GPO, and the GPC might not replicate in lockstep with the files in the GPT. This isn't normally a problem because, over time, all Domain Controllers end up with exactly the same information in their replicas of the Active Directory database and in their SYSVOL folders. But during a given replication cycle, there may be intervals when the GPC and GPT don't match on a particular Domain Controller.

Additionally, the GPC and GPT share a version number for each half of the GPOcomputer and user. The version numbers are incremented each time the GPO is modified and are included in the list of attributes that are replicated to other Domain Controllers. Remember in Chapter 1 I stated that if a specific GPO doesn't change, the default for the client is to not redownload the GPO. After all, if nothing's changed, why should the client bother? The client uses these version numbers to figure out if something has changed. The client keeps a cache of the GPOs it last applied along with the version number. Then, if the GPO has been touched, say, by the modification of a particular policy setting or the addition of a policy setting, the version number of the GPO in Active Directory changes. The next time the client tries to process GPOs, it will see the change, and the client will download the entire GPO again and embrace the revised instruction set! So, version numbers are important for clients to recognize that new instructions are waiting for them.

So far, so good. Now, there's a bit more to fully understanding version numbers. According to Microsoft, here's the secret to figuring out whether a GPO is going to process on a workstation:

• Both the GPC and GPT parts of the GPO must be present on the Domain Controller the workstation uses to log on.

• The GPC and GPT must have the same version number.

Microsoft says that if either of these is not true, the workstation cannot process the GPO.

Note 

In my testing, I have not found the latter statement to be required. That is, even when the version numbers of the GPC and GPT are different, the GPO seems to be processed just fine on the client. However, just because I haven't encountered difficulty with version numbers doesn't mean you won't. Use the following tips to ensure that version numbers are in sync if problems start to occur.

Changing the Default Location for the Initial Write of Group Policy Objects

GPOs are, by default, written to the Domain Controller that houses the PDC Emulator. Sometimes in large Active Directories, this behavior is not desired, as in the following example.

There is one domain but two sitesthe United States and China. The U.S. site holds the Domain Controller designated as the PDC Emulator. Therefore, whenever an administrator in China writes a GPO, they must connect across the WAN to write the GPO and then wait for the entire GPO (both the GPC half and the GPT half) to replicate to their local Domain Controllers.

You can, however, specify which Domain Controller to write the GPO to, which is a two-step process:

1. Select a Domain Controller to be active. Open the GPMC, right-click the domain name, select "Change Domain Controller," and select the Domain Controller you to which you want the Group Policy to apply.

2. Create your GPO and edit it. At the root node of the Group Policy snap-in, choose View ˜ DC Options. Now you have the following three choices:

   • "The one with the Operations Master token for the PDC Emulator." The default behavior, this option finds the PDC Emulator in the domain and writes the GPO there. Replication then occurs, starting from the PDC Emulator.

   • "The one used by the Active Directory snap-ins." Since you just selected the active Domain Controller, this is your best bet, as you know exactly which Domain Controller you selected in the first step.

   • "Any available Domain Controller." The odds are good that you will get a local Domain Controller to write to (based on Active Directory site information), but not always.

Therefore, the best course of action is to select the Domain Controller you want to initially write to and then select "The one used by the Active Directory snap-in" to guarantee it.

Sound like too much work for each GPO? Alternatively, you can create a GPO that affects those accounts that can create GPOs. Use the policy setting located at User Configuration ˜ Administrative Templates ˜ System ˜ Group Policy named "Group Policy Domain Controller Selection." You'll get the same three choices listed earlier. Set it, and forget it.

Here's one more parting tip for this sidebar. Often, GPOs are created with the additional intent to use Security groups to filter them. After creating a GPO with the GPMC, an administrator will also create some security groups using Active Directory Users And Computers to filter them. However, after creating the GPO and the security groups, many admins are surprised that the security groups they want to add "now" are not immediately available. This is because the GPMC is using one Domain Controller, and the Active Directory Users And Computers is using another Domain Controller. Therefore, replication of the group has not yet reached the Domain Controller the GPMC is using So the tip is to manually focus both the Active Directory Users And Computers and/or GPMCs explicitly on the same Domain Controller (or just the PDC Emulator) before creating GPOs where you'll also want to filter using groups.

 

Using Gpotool.exe

If you suspect you're having problems with keeping your GPTs and GPCs in sync, you can use Gpotool.exe , a tool included with the Windows 2000 and Windows 2003 Resource Kits. You can run Gpotool.exe on any Domain Controller to verify that both the GPCs and GPTs are in sync and have consistent data among all Domain Controllers in the domain.

Running Gpotool without any parameters verifies that all GPCs and GPTs are synchronized across all Domain Controllers in the domain. If you are having trouble with only one GPO, however, you might not want to go through the intense process required to check every GPO's GPC and GPT on every Domain Controller. Instead, however, you can use the /gpo : switch, which allows you to specify a friendly name or GUID of a GPO you are having problems with. For instance, if you suspect that you are having problems with any of the "Hide Screen Saver Tab," "Hide Appearance Tab," or "Hide Settings Tab / Restore Screen Saver Tab" GPOs we created in Chapter 1, you can run Gpotool /gpo:Hide to search for all GPOs starting with the word Hide, as shown in Figure 4.10.

Figure 4.10: Use Gpotool to see if your GPCs and GPTs are synchronized across your Domain Controllers.

Tip 

To specifically verify the "Hide Settings Tab / Restore Screen Saver Tab" setting, you can also run Gpotool /gpo:"Hide Settings Tab / Restore Screen Saver Tab" as seen in Figure 4.10. Note that the /gpo: switch is case sensitive. For instance, running Gpotool /gpo:Hide is different from running GPOTOOL /gpo:hide .

This example shows when things are going right. This next example (see Figure 4.11) shows when things might be wrong.

Figure 4.11: Gpotool has found trouble in paradise .

In this example, we are verifying the synchronization of the GPO named "Broken2." In this case, the versions between the GPC and GPT do not match. You can see this when comparing what the tool calls the DS version with the SYSVOL version. The DS version represents the GPC, and the SYSVOL version represents the GPT.

Before panicking, recall that this "problem" might not actually be a problem. Remember, the GPC and GPT replicate independently. The DC our clients are currently using might have simply received the SYSVOL (GPT) changes before the Active Directory changes (GPC) or vice versa. Wait a little while, and the two versions might converge. If they do not converge, this problem could indicate either Active Directory or FRS replication issues.

Here are some additional tips about using GPOTOOL:

• Running GPOTOOL on a large domain with lots of GPOs can take a looooong time and really bog down your Domain Controller performance. If possible, run GPOTOOL only after hours, when the fewest number of people will be affected.

• If you must run it during working hours, you might want to specify the /dc: option and specify to check only the GPOs on the PDC-Emulator (the place where GPOs are initially born and initially modified). If you're going to have a problem, it's quite likely to be initially pinpointed on this key Domain Controller.

• GPOTOOL also has one extra super-power. That is, it can also verify the underlying ACLs of the GPT part of a GPO. Recall, that the GPT is the part of the GPO that lives in SYSVOL. To perform this extra check, you need to specifically specify it on the command line of GPOTOOL as GPOTOOL /checkacl. By default, this test is not run because it is additionally time- and resource- intensive . There is one key point about the /checkacl switch: it only checks the ACLs on the SYSVOL itself, not the ACLs on the individual folders which contain the guts of the GPO. So, if you have a specific permissions problem on the folder containing a GPO, the /checkacl switch won't really help you ferret that out.

Using Replmon to See the Version Numbers

The Replmon (Replication Monitor) tool is available as part of the Support tools on the Windows 2003 (or Windows 2000) Server CD. Replmon is one of the most useful free tools Microsoft has ever created.

For our purposes, we'll use it in a fashion similar to how we used Gpotol; that is, Replmon can tell us if a GPO's GPC and GPT are in agreement with the version numbers.

First, load the Support tools in the \SUPPORT\TOOLS folder. Then, choose Start ˜ Run to open the Run dialog box, and type Replmon in the Open box. Right-click the Monitored Servers icon and choose "Add Monitored Server." For now, just add the PDC Emulator. In my case, I'll add WINDC01. Once the server is being monitored , right-click it and choose "Show Group Policy Object Status" to display a screen like that shown in Figure 4.12.

Figure 4.12: Replmon can show you the version numbers of all your GPOs.

In Figure 4.12, you can see that the GPO named "Broken2" has an X in the Sync Status column. The version numbers are dissimilar in the GPC and GPT. Again, this might not be a real "problem" because the GPC and GPT are being independently replicated. Perhaps this Domain Controller did not yet get the latest updates.

Isolating Replication Problems

You can try to see if Active Directory replication is working (and, hence, if GPC replication is working) by performing several " litmus tests." Here are some examples:

• Create a new GPO in the Group Policy Objects container. Just create it with no policy settings, and don't link it anywhere .

• Create a new OU in Active Directory Users And Computers or the GPMC.

• Add a new user in Active Directory.

In each case, you want to see if these objects are replicated to other DCs. After creating your objects on one Domain Controller, use the Active Directory Users And Computers and/or GPMC to check other Domain Controllers. Simply right-click the domain and choose another Domain Controller.

If these litmus tests fail, you can try to force replication using Active Directory Sites And Services. If you need extra-strength replication, Replomon can help force replication in multiple ways.

You can try to see if SYSVOL replication is working via FRS (and, hence, if GPT replication is working) by simply throwing any filesay, a Readme.txt fileinto the SYSVOL share of any Domain Controller, and seeing if it is replicated to the other Domain Controllers' SYSVOL shares. If it is not automatically copied to the other Domain Controllers, test each machine's connectivity using the ping command.

Here are some additional tips for troubleshooting FRS replication:

• Microsoft TechNet has an excellent feature-length article, "Troubleshooting FRS," at the TechNet home page at http://tinyurl.com/7m1t5 .

• Microsoft has a new tool, SONAR (part of the Windows 2003 Resource Kit), that can dramatically help with FRS troubleshooting.

• Microsoft has another new tool, ULTRASOUND, which surpasses SONAR's ability to help troubleshoot FRS.

ULTRASOUND and SONAR are available on the Microsoft website. At last check, SONAR can be found at http://tinyur1.com/5ouk9 , and Ultrasound can be found at http://tinyurl.com/odgu . General FRS and troubleshooting and information can be found at www.microsoft.com/frs as of this writing.

Tip 

The Microsoft Knowledge Base articles Q221112, Q221111, Q272279and Q229928 are good starting points to learn more about FRS and how to trouble-shoot SYSVOL replication problems by debugging FRS. See Q229896 and Q249256 for details on how to debug Active Directory replication.

Windows Server 2003/R2 is forthcoming as of this writing. And rumors have it that the FRS will react differently, have different features, and different troubleshooting tools, etc. Therefore, if you are implementing Windows Server 2003/R2, be sure to follow up with Microsoft at www.microsoft.com/frs for updated tips, tricks, and tools.

Death of a GPO

As you saw in Chapter 2, there are two ways to stop using a GPO at a level in Active Directory. One way is to "Delete the link" to the GPO at the level being used in Active Directory. In the swimming pool analogy, we're simply removing the tether to our child in the pool, but we're leaving the object swimming in the pool should other levels want to use it.

The other way to stop using a GPO is to delete it. With the GMPC, you can delete a GPO only by traversing to the Group Policy Objects node, right-clicking it, and choosing Delete, as you saw in Figure 2.7. But, again, be careful; other levels of Active Directory (including those in other domains and forests) might be using this GPO you're about to whack.