MCSA/MCSE Self-Paced Training Kit (Exam 70-214): Implementing and Administering Security in a Microsoft Windows 2000 Network (Pro-Certification)

Lesson 4: Troubleshooting Group Policy Application

Testing the application of Group Policy is crucial to understanding the effects on users in any specific implementation. The combination of multiple overriding GPOs on a user or computer can create a myriad of possible outcomes even when Group Policy is operating correctly.

The proper operation of Group Policy mechanisms depends on numerous interdependent operating system features, all of which must be configured correctly to guarantee the proper operation of Group Policy. For this reason, you must understand how to troubleshoot the application of Group Policy to determine why unexpected or unintentional results have occurred.

After you complete this lesson, you will be able to

• Determine why Group Policy application problems can occur

• Test for proper connectivity to domain controllers

• Test the proper configuration of Domain Name System (DNS) settings

• Enable verbose Group Policy logging for troubleshooting purposes

• Use troubleshooting tools to find configuration errors on clients and servers

Estimated lesson time: 30 minutes

Understanding Typical Group Policy Application Problems

Users encounter a number of relatively routine problems when working with Group Policy. Typical problems with Group Policy application include

• Unexpected or unintended results

• Incomplete application of policy

• Lack of policy application

In a properly functioning network, these problems typically occur because multiple GPOs are being applied and it's not always obvious which policy has priority for a specific setting. Other possible causes are a client computer that can't resolve the name of a domain controller or that doesn't have proper access to a GPO or SYSVOL share. Typical solutions to Group Policy problems include verifying that

• The client has properly configured DNS settings and can resolve the domain controller.

• The user or computer account is actually contained within the Active Directory container that is linked to the GPO.

• A previously applied policy is not set to No Override.

• The user has Read and Apply permissions for the GPO.

The Effect of DNS Resolution on Group Policy

Group Policy cannot be correctly applied unless a client can resolve the name of the domain controller responsible for storing the Group Policy. Even if the host name can be resolved from the client, because of the way DNS works, the Group Policy client-side extensions might not be able to resolve the server name.

When a computer attempts to resolve a host name, such as dc01.domain.fabrikam.com, the name of the host is known to the client and can be sent to the DNS server to determine the IP address. However, when a client looks for a domain controller without knowing its name, it sends a special type of DNS lookup called a Service (SRV) record lookup. In an SRV record lookup, DNS returns to the client the name of the domain controller, and the client repeats the request for the server's IP address once it knows the server's host name. The practical result of this process is that, while you might be able to resolve a domain controller's name from a specific client, Group Policy cannot be applied unless a valid SRV record exists on the client's DNS server that will return the appropriate domain controller's name to the client.

For this reason, clients cannot apply Group Policy unless domain controllers have proper SRV records in the DNS service. This is usually not a problem when dynamic DNS is in use, because these records are automatically created when hosts are promoted to domain controllers, but in environments where static or non-Active Directory integrated DNS is in use, keeping these records up to date can be a constant hassle.

If you run a mixed Windows-UNIX network, it's easier to use Windows to provide DNS service. UNIX clients can resolve against Windows servers easily, and Windows DNS can be integrated with Active Directory so that the complex records required for proper domain operation are automatically created.

Esoteric Problems with Group Policy Application

Because of the complexity of Group Policy operations, larger networks are likely to experience problems due to replication of GPOs. Also, more complex Active Directory structures can take significantly more time to analyze when an attempt is made to determine which specific GPO contains a particular setting. Finally, sites in the process of migrating from a Microsoft Windows NT 4 domain structure to Active Directory might find that Windows NT 4 system policy has unexpected results when used with Group Policy. Esoteric problems with Group Policy include

• Changes to Group Policy work locally, but do not work at other sites or in other domains.

• Replication of GPOs can be much slower than anticipated.

• Some portions of Group Policy have been applied, but others have not.

Numerous domain controller configuration problems can interfere with the proper application of Group Policy. However, most of these problems will also affect other areas of domain controller operation, so it should be somewhat obvious if a domain controller is not functioning properly.

When a client computer applies Group Policy, the various Group Policy client-side extensions write their results to the file %systemroot%\Debug\UserMode \User-env.log. Reading this file can usually point you to the problem that is occurring, especially if the problem is related to resource access permissions or DNS lookup failure.

Solving esoteric Group Policy application problems is not necessarily more difficult than solving simple problems, once you know all of the symptoms. You can solve most esoteric Group Policy problems by checking a few additional configurations. To solve esoteric problems, you must

• Confirm that replication is occurring correctly and that the Group Policy is the same across domain controllers.

• Ensure than individual GPOs are kept small so that they replicate quickly among sites.

• Ensure that the user has Read and Apply permissions for the GPO (in other words, ensure that the GPO is not being filtered) using Userenv.log.

• Verify that Windows isn't attempting to apply Windows NT 4 policy to the client.

• Reboot the computer and log on again to ensure that all types of Group Policy extensions have been refreshed.

Understanding Windows NT 4 Domain Migration Issues

Several side effects can occur in Group Policy application for networks that are in the midst of a migration from Windows NT 4 domains to Windows 2000 domains. The following list identifies the specific effects of Windows NT 4 users and client computers on the application of Group Policy in a Windows 2000 domain:

• If the computer is running Windows NT 4, it receives Windows NT 4 style system policy rather than the Windows 2000 style Computer Configuration portion of Group Policy, irrespective of how the computer's account is managed.

• If Windows NT 4 based domain controllers manage a user account, that user account receives Windows NT 4 style system policy rather than the Windows 2000 style User Configuration portion of a GPO, regardless of the client operating system.

• If Active Directory manages the user account, the user receives the User Configuration portion of a GPO no matter which operating system is installed on the client computer. This means that Windows NT 4 clients receive the User Configuration portion of a GPO when an Active Directory account logs on, and that Windows 2000 clients receive system policy when accounts managed by Windows NT 4 domain controllers log on.

To avoid problems with various types of policy affecting client computers, upgrade all user accounts to Active Directory as quickly as possible by upgrading resource domains to Windows 2000. Update Windows NT backup domain controllers to Windows 2000 as quickly as possible after that. Don't upgrade Windows NT clients to Windows 2000 until all domain controllers are running Windows 2000 Server.

Remember that Windows NT 4 compatible system policy permanently tattoos the registry of Windows NT computers. When accounts (machine accounts or user accounts) are moved to Active Directory, or when computers are upgraded from Windows NT 4 to Windows 2000, unwanted residual registry settings might remain from the application of system policy. Use Regini.exe to clean the registry of the computer that has residual system policy problems. Better yet, perform clean installations of Windows 2000 rather than upgrade Windows NT computers.

Anticipating Problems Relating to Windows NT 4 Trust Relationships

Trust relationships control the way that users can access resources in remote domains. When a trust relationship exists between two domains, users in the trusted domain can access resources in the trusting domain without having to log on to the trusting domain.

When you upgrade multiple domains from Windows NT to Windows 2000, trust relationships are not automatically upgraded, which can occasionally cause Group Policy application problems. After upgrading both domains to Windows 2000, break and reestablish trust relationships to ensure that they operate as expected.

In this practice, you troubleshoot the application of Group Policy by enabling user environment logging on the client side, by running Dcdiag.exe to check for the proper configuration of the domain controller, and by running Netdiag.exe to check for the proper connectivity between the client and the domain controller.

Exercise 1: Enabling User Environment Debug Logging in Windows 2000

Windows 2000 logs the application of Group Policy to a file in the %systemroot% \debug\UserMode\userenv.log. By default, this file does not contain much information, but you can record and display more information by enabling verbose logging. Verbose logging tells the client-side extensions to log every message they generate, which provides quite a bit of information about how policy is being applied. Knowing the details about how policy is being applied will help you discover what is going wrong when problems occur, because the error messages will show up in the log file.

To enable verbose logging in Windows 2000 on the client side

1. On the client where you suspect that a Group Policy application problem is occurring, log on as an administrator.

2. Click Start, and click Run.

3. Type Regedit, and press Enter.

4. In the Registry Editor, expand HKEY_LOCAL_MACHINE\Software \Microsoft\Windows NT\CurrentVersion\WinLogon.

5. Click Edit, point to New, and click DWORD Value.

6. Type UserEnvDebugLevel.

7. Double-click UserEnvDebugLevel.

8. In the Edit DWORD Value dialog box, type 10002 in the box and ensure that Hexidecimal is selected.

9. Click OK, close the Registry Editor, and log off.

To interpret the Group Policy application log

1. Log on as a test user to whom the Group Policy should apply.

2. Wait for about one minute for the system to finish accessing the hard disk drive, and then log off.

3. Log on as an administrator.

4. Open C:\WINNT\Debug.

5. Double-click UserEnv.log.

6. If an Open With dialog box appears, click Notepad, and click OK. Notepad displays the log file as a text document.

7. Browse through the log file. The last entry is the most recent (administrative) logon, so you are interested in the section prior to that. A considerable amount of information applies to each logon, so scroll back far enough to see the initial boot log entry to be sure that you're interpreting the correct result set.

Exercise 2: Verifying Domain Controller Configuration

You can use the Dcdiag.exe program to determine what is wrong with a domain controller or to verify that it is operating properly and that the problem is most likely on the client side.

To determine whether a domain controller is properly configured

1. Log on to the domain controller you want to test as the administrator.

2. If the Windows 2000 support tools are not installed, install them from the Windows 2000 Server CD. The tools are located in the \Support\Tools folder.

3. Open a command prompt.

4. Type dcdiag /v >dcdiag.log. The command prompt will pause for about one minute.

5. Type notepad dcdiag.log. Notepad displays the results of the diagnostic in a text document.

6. Scroll through the contents of the log file looking for error messages or test sequences that failed. These will indicate what is wrong and guide your troubleshooting efforts.

Exercise 3: Verifying Client Connectivity

You can use the Netdiag.exe program to determine whether proper name resolution is in place between a client and a domain controller.

To check for proper name resolution between a client and a domain controller

1. Log on to the client you want to test as an administrator.

2. Insert the Windows 2000 Server CD in the computer's CD-ROM drive.

3. Open the \Support\Tools folder.

4. Double-click the Deploy.cab file. The contents of the Deploy.cab file appear.

5. Double-click the Netdiag.exe file. A dialog box asks where you want to extract the file to.

6. Select a path on the client computer's local hard disk (for example: C:\Winnt\Temp).

7. Open a command prompt.

8. Change the directory to the location where you extracted Netdiag.exe.

9. Type netdiag /v >diagnose.log. The command prompt will pause for about one minute.

10. Type notepad diagnose.log. Notepad displays the diagnostic log file in a text document.

11. Browse through the output, scroll down to the line: "DC discovery test:" and ensure that it says Passed. If not, use the output of the log to discover which tests failed and which parameters need to be corrected.

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

1. To which file does Windows log Group Policy application errors?

2. If a new Windows 2000 client computer can log on to the local domain controller, but no Group Policy is applied for the machine or user configurations, what is the most likely problem?

3. If you log on to a Windows 2000 domain from a Windows NT 4 computer using a user account managed by Active Directory, how will Group Policy be applied?

Lesson Summary

• Group Policy is a complex group of services and is highly dependent on the proper operation of many network services. Incorrect configuration of any of these services can cause problems for Group Policy application.

• Because Group Policy is designed to be applied in layers, it is not always obvious which GPO contains a particular setting.

• DNS must be operating correctly and properly configured on the client for GPOs to be downloaded. Users must have permission to read and apply GPOs for the GPOs to take effect.

• You can use the Dcdiag.exe support tool to determine whether or not a domain controller is operating correctly. You can use the Netdiag.exe tool to determine whether a client computer is configured correctly.