When you discover problems with Group Policy processing, you can take a number of avenues to track down the problem. Because Group Policy processing has many moving parts, with many interdependent pieces of infrastructure, it is important to take a methodical approach to troubleshooting. By using the information about Group Policy processing presented in Chapter 13, we can create a high-level list of items to check when Group Policy processing fails on a workstation or server. Here are the steps:
Check the required infrastructure. Make sure required services and components are running and configured as expected.
Check the core configuration. Verify that the computer is connected to the network, joined to the domain, and has the correct system time. Check the startup state of services and other basics.
Check the scope of management (SOM). Verify that items such as security filtering, WMI filters, block inheritance, enforcement, loopback processing, and slow-link settings aren’t affecting normal GPO processing.
Use tools such as GPResult.exe, GPOTool.exe, and the Group Policy Management Console (GPMC) to ensure that Group Policy settings are being delivered as expected and that Group Policy objects (GPOs) on domain controllers are consistent and available.
Use event logs and Group Policy core and client-side extension (CSE) logs to drill into the problem and find the solution.
In this chapter, we will look closely at each of these steps and at the tools and techniques for solving many Group Policy problems. Chapter 17 also provides details on resolving common problems with Group Policy.
Administrators frequently jump into in-depth troubleshooting of Group Policy without checking the essentials. Before you get too deep into troubleshooting, you should always perform some essential checks:
Verify the network connection and configuration.
Verify the computer account and domain trust.
Validate the computer and network time.
Verify the computer and user account configuration.
To receive and process policy, a computer must be connected to the network and have a properly configured connection. You can verify this by typing the following command at the command prompt:
netsh interface ip show configIf a computer’s network connection is disabled or corrupted, you’ll see an error message such as this one:
No more data is available.In this case, you must access Network Connections and solve the problem by enabling or repairing the connection. To enable the connection, right-click the connection and select Enable. To attempt to repair the connection, right-click the connection and select Repair.
If the network connection is enabled, you should see network configuration details similar to the following:
Configuration for interface "Local Area Connection" DHCP enabled: No IP Address: 192.168.1.28 SubnetMask: 255.255.255.0 Default Gateway: 192.168.1.50 GatewayMetric: 0 InterfaceMetric: 0 Statically Configured DNS Servers: 192.168.1.50 Statically Configured WINS Servers: None Register with which suffix: Primaryonly
Note
Netsh is a built-in utility. Chapter 15 in the Microsoft Windows® Command-Line Administrator’s Pocket Consultant(Microsoft Press, 2004) covers Netsh in detail.
This list of settings shows that there is an active network connection and provides the settings of this connection. As part of troubleshooting, check the network settings closely to ensure that they are configured as expected.
To receive and process policy, a computer must be joined to the domain, and the trust between the computer and the domain must be properly established. You can verify the computer account and computer trust in the domain by typing the following command at the command prompt:
nltest /sc_query:DomainNamewhere DomainName is the name of the domain to which the computer is joined, such as:
nltest /sc_query:cpandl.comIf the computer is properly joined to the domain and the trust is valid, you should see a query response similar to the following:
Flags: 30 HAS_IP HAS_TIMESERV Trusted DC Name \corpsvr04.cpandl.com Trusted DC Connection Status Status = 0 0x0 NERR_Success The command completed successfully
Kerberos validation and authentication will fail if the time difference between a client computer and its logon domain controller is greater than 5 minutes. This failure can in turn cause problems with DNS registration, Group Policy processing, and other essential computer processes.
To check a computer’s current system time and date, type the following command exactly as shown at a command prompt:
net time \%ComputerName%The output is the current time and date on the local computer, such as:
Current time at \ENGPC07 is 2/7/2005 2:02 PMTo check the system time on the logon domain controller, type the following command at a command prompt:
net timeThe output is the current time and date on the logon domain controller, such as:
Current time at \CORPSVR04 is 2/7/2005 2:02 PMSometimes we assume that computers and users are in a particular container or that they are members of a particular security group. When you are troubleshooting Group Policy, you can no longer make this assumption, and you should verify both the Active Directory container in which computer and user accounts are placed and the security groups they belong to.
The fastest way to determine the container in which a computer is placed is to type the following command:
dsquery computer -name ComputerNamewhere ComputerName is the name of the computer, such as:
dsquery computer -name engpc07The output of this command specifies the current container location of the related computer object, such as:
"CN=engpc07,OU=Engineering,DC=cpandl,DC=com"Note
If a computer or user was recently moved to this container, the computer or user might not be processing the applicable GPOs for this container. This occurs because Active Directory clients cache their location within the directory. To solve this problem you must either reboot the machine or wait for the location cache to be refreshed (which occurs in approximately 30 minutes). You can verify which GPOs are being processed by using Resultant Set of Policy (RSoP) logging, as discussed later in the chapter. Chapter 11 through Chapter 13 in the Microsoft Windows Command-Line Administrator’s Pocket Consultant provide in-depth details on dsquery, dsget, and related directory services commands.
The fastest way to determine the container in which a user is placed is to type the following command:
dsquery user -samid LogonAccountNamewhere LogonAccountName is the logon name of the user, such as:
dsquery user -samid wrstanekThe output of this command specifies the current container location of the related user object, such as:
"CN=William R. Stanek,CN=Users,DC=cpandl,DC=com"When security filtering is used, you might also want to know the security groups a user belongs to. You can determine this by typing the following command:
dsquery user -samid LogonAccountName | dsget user -memberofwhere LogonAccountName is the logon name of the user, such as:
dsquery user -samid wrstanek | dsget user -memberofThe output of this command specifies the group membership for the specified user, such as:
"CN=Domain Admins,CN=Users,DC=cpandl,DC=com" "CN=Administrators,CN=Builtin,DC=cpandl,DC=com" "CN=Domain Users,CN=Users,DC=cpandl,DC=com"
For Group Policy to work properly, a number of key infrastructure components must be functioning properly. These include:
Active Directory Replication. Domain controllers use Active Directory to replicate changes to the GPC to other domain controllers. If Active Directory replication isn’t working properly, changes to files in the GPC won’t be distributed properly. Active Directory makes extensive use of a storage engine and has a data store referred to as the Active Directory data store. The data store and related files are stored in the %SystemRoot%Ntds folder on domain controllers.
DNS. Computers processing Group Policy must be able to find the Windows domain controllers that are acting as LDAP servers. They do this via DNS. If DNS isn’t available or SRV records are not registered for available domain controllers, computers cannot correctly query a domain controller for the GPOs that apply to them.
ICMP (Ping). Computers processing Group Policy rely on ICMP pings to determine whether the domain controller that is servicing them is available over a slow or fast network link. If ICMP is blocked or domain controllers are unable to respond to ICMP pings, Group Policy processing will fail.
TCP/IP NetBIOS Helper Service. After a Windows computer obtains its list of GPOs to process from Active Directory, it contacts the Distributed File System (DFS) SYSVOL share to get the contents of the GPT for each GPO. Windows then requests the contents of the GPT in the SYSVOL. Because SYSVOL is a fault-tolerant DFS root, it is referred to using the DNS name of the domain in which it resides (for example, \cpandl.comSYSVOL). If the TCP/IP NetBIOS Helper service is not running on the computer processing Group Policy, the conversion of the DNS domain name within the UNC request into a valid server name will fail. The TCP/IP NetBIOS Helper service must be running for any computer that is processing Group Policy.
Distributed File System (DFS). Domain controllers use DFS and its related services to share the SYSVOL. If DFS isn’t working, computers in the domain cannot read the contents of the GPT in SYSVOL. DFS depends on the DfsDriver and Mup components as well as the Security Accounts Manager, Server, and Workstation services.
File Replication Service (FRS). Domain controllers use FRS to replicate changes to the GPT to other domain controllers. If FRS isn’t working properly, changes to files in the GPT won’t be distributed properly. Like Active Directory, FRS makes extensive use of a storage engine and has a data store referred to as the replication store. The replication store uses the Microsoft Jet database technology, and the related files are stored in the %SystemRoot%NtfrsJet folder on domain controllers.
Your Group Policy troubleshooting should always start with an examination of these infrastructure components. Once you’ve eliminated the underlying infrastructure as a possible source of the problem, start troubleshooting Group Policy by verifying the scope of management. For more information on troubleshooting required infrastructure, see Chapter 17.
Sometimes the problem with Group Policy processing is a simple but not obvious one: a particular policy is not being applied because it should not apply. To verify whether a policy should or should not apply, you can use a number of techniques.
A GPO can have a variety of status states that can affect processing. A GPO can be disabled, or just the user or computer sides of the GPO can be disabled. To rule out GPO status as a potential source of a problem, you can examine the GPO in the GPMC by completing these steps:
In the GPMC, expand the entry for the forest you want to work with, expand the related Domains node, and then expand the related Group Policy Objects node.
Select the GPO you are troubleshooting, and in the right pane, click the Details tab.
The GPO Status field reflects the current state of the GPO (Figure 16-1). Generally speaking, the GPO should have a status of Enabled. Any other status means that the GPO is either partially or fully disabled. Before you change the status of the GPO, you should check with other administrators to see if there is a reason why the GPO state has been reset.
The User Version and Computer Version fields provide details on the current version of the GPO, as reflected in Active Directory (the GPC) and the SYSVOL (the GPT). Changes to the user and computer configuration are tracked separately, but the version number for each should be the same in the GPC and GPT. If they aren’t, there might be a problem with Active Directory replication or FRS.
When you work with the GPMC, remember that you are connected by default to the PDC Emulator for the domain and are therefore seeing the general state of the GPO in question. In most cases, though, the problem will be with another domain controller or will be in another area of the network. As a result, you’ll often want to log on to a computer that is experiencing problems with Group Policy and determine to which domain controller you are connected. You can then either identify or rule out this domain controller as a source of the problem.
Complete the following steps to troubleshoot a specific domain controller:
If a particular user is experiencing a problem with Group Policy, access a command prompt on his computer and type set. Otherwise, log on to a computer in the area or network segment that is having problems with Group Policy, access a command prompt, and then type set.
Scroll back through the results to determine the value of the LOGONSERVER environment variable. This is the domain controller to which you are (or the current user is) connected.
Note
Because logon information can be cached, the computer might be disconnected from the network or have a disabled local area connection and still have a setting for the LOGONSERVER environment variable. Check the status of Local Area Connection under Network Connections or try to connect over the LAN to a network resource to confirm the network status.
In the GPMC, right-click the domain node and then select Change Domain Controller. Under Change To, select This Domain Controller and then select the logon server you located previously. Click OK.
Expand the Group Policy Objects node for the domain in question. Select the GPO you are troubleshooting, and in the right pane, click the Details tab.
You will see the status and version of the GPO as seen by the selected domain controller.
Note
There are, of course, other ways to check the logon server and the status of GPOs with regard to a particular user or computer. You can, for example, use RSoP logging to determine this information (as covered in the "Essential Troubleshooting Tools" section in this chapter). Keep in mind that Windows Firewall on computers running Windows XP Professional Service Pack 2 may block you from remotely accessing the problem machine. See Chapter 11 to learn how to configure Windows Firewall exceptions.
A Group Policy link can have different states that affect whether that GPO applies to a user or computer. For example, a Group Policy link might be disabled or enforced. If a link is disabled, the GPO will not apply to users or computers within the container to which that GPO is linked. If a link is enforced, the GPO will actually apply over any conflicting settings that are subsequently processed. For example, an enforced GPO linked to the domain will overwrite any conflicting settings from a GPO linked to an organizational unit (OU) in that domain.
Link order also affects how policy is applied. When multiple policy objects are linked to a particular level, the link order determines the order in which policy settings are applied. Generally speaking, the order of inheritance goes from the site level to the domain level and then to each nested OU level.
To check link status and link order for a specific GPO, complete these steps:
In the GPMC, expand the entry for the forest you want to work with, expand the related Domains node, and then expand the related Group Policy Objects node.
Select the GPO you are troubleshooting, and in the right pane, click the Scope tab.
On the right side, you will see the containers to which that GPO is linked and their status, as shown in Figure 16-2.
To check the order and status of GPOs linked to a specific container, complete these steps:
In the GPMC, expand the entry for the forest you want to work with.
Do one of the following:
If you are troubleshooting domain policy, select the domain node.
If you are troubleshooting OU policy, select the OU node.
If you are troubleshooting site policy, expand Sites and then select the site node.
The Linked Group Policy Objects tab shows the link order and the status of each GPO linked to the selected container (Figure 16-3). Linked policy objects are always applied in link ranking order. Lower-ranking policy objects are processed first and then higher-ranking policy objects are processed.
As discussed in Chapter 3, you must set Read and Apply Group Policy permissions to ensure that a GPO is processed. By default, members of the Authenticated Users group are granted these permissions on all GPOs, which means the policy will be applied to all users and computers in the container to which a particular GPO is linked. If the default security filtering is changed, this will also affect how users and computers process a particular GPO. An additional type of filter that can be applied to GPOs is a WMI filter. The specific criteria of the WMI filter must be met in order for the GPO to be processed.
A security group, user, or computer must have both Read and Apply Group Policy permissions for a policy to be applied. By default, all users and computers have these permissions for all new GPOs. These permissions are inherited from their membership in the implicit group Authenticated Users. An authenticated user is any user (or computer) that has logged on to the domain and been authenticated.
To examine the filtering that has been applied to a GPO, complete these steps:
In the GPMC, expand the entry for the forest you want to work with, expand the related Domains node, and then expand the related Group Policy Objects node.
Select the GPO you are troubleshooting, and in the right pane, click the Scope tab. The Security Filtering and WMI Filtering panels show the current filtering configuration.
To see the exact set of permissions for users, groups, and computers, click the Delegation tab and then click Advanced. Select the security group, user, or computer you want to review. Keep the following in mind:
If the policy object should be applied to the security group, user, or computer, the minimum permissions should be set to allow Read and Apply Group Policy.
If the policy object should not be applied to the security group, user, or computer, the permissions should be set to allow Read and deny Apply Group Policy.
You can manage loopback processing by enabling User Group Policy Loopback Processing Mode under Computer ConfigurationAdministrative TemplatesSystemGroup Policy and then setting the loopback processing mode to either replace or merge settings:
When you use the Replace option, user settings from the computer’s GPOs are processed and the user settings in the user’s GPOs are not processed. This means the user settings from the computer’s GPOs replace the user settings normally applied to the user.
When you use the Merge option, user settings in the computer’s GPOs are processed first, then user settings in the user’s GPOs are processed, and then user settings in the computer’s GPOs are processed again. This processing technique serves to combine the user settings in both the computer and user GPOs. If there are any conflicts, the user settings in the computer’s GPOs take precedence and overwrite the user settings in the user’s GPOs.
Because loopback processing changes the way policy is applied, you must know whether the computer that a user is logging on to has loopback processing enabled. Otherwise, you cannot troubleshoot properly. One way to determine whether loop-back processing is enabled is to use the Group Policy Results Wizard in the GPMC to view which policies are in effect on a machine. To learn more about loopback processing and how to disable it, see "Changing Policy Processing Preferences" in Chapter 3, or see Chapter 12, which provides additional scenarios for configuring and working with loopback processing.
Slow links can also affect policy processing. By default, the client computer considers any connection speed less than 500 kilobits per second as slow. As a result, only Security Settings and Administrative Templates in the applicable policy objects are sent by the domain controller during policy refresh (by default). See "Configuring Slow Link Detection" in Chapter 3 for more information.