Most administrators are familiar with server diagnostic tools, but client diagnostic tools may be foreign to them.
Although desktops outages affect fewer users than server outages -- and may thus be less of a concern -- the client plays a significant role in certain server problems. Client diagnostic tools can help you gather the data you need to troubleshoot these types of issues.
Windows Event Viewer
Client issues are often the result of authentication, network connectivity or group policy problems. But before we analyze these areas, it's important to note the power of the Windows Event Viewer. Events are clues to help diagnose almost any problem; at the very least, they point us in the right direction. The Event Viewer was improved in Windows Vista and Windows 7, and the tool now includes advanced filtering and custom views. While you can read .evt logs in Windows 7 and Vista event viewers, the reverse is not true.
Authentication and group policy
Authentication and group policy issues are usually related. There are several tools that can help troubleshoot the following areas:
- The Userenv log helps debug group policy and profile issues by providing a verbose set of events as Group Policy Objects (GPOs) are applied and the profile is loaded. Available with Windows XP and Windows Sever 2003 and earlier, this tool lets you find delay gaps in the timeline, and these gaps can help point you to the culprit. Microsoft Knowledge Base 221833 explains how to configure verbose logging. Without this, the Userenv log is useless. The proper procedure to set this up is:
- Configure the UserEnvDebugLevel registry value per KB 221833.
- Delete or rename the existing Userenv log found in %windir%\debug\usermode.
- Reproduce the problem (usually this means logging off/on).
- Save the userenv.log to another location and analyze it.
Note: There is no Userenv log in Windows Vista and newer or Windows Server 2008 and newer. In these versions, the above information is captured in the normal Windows event logs.
- For group policy application failures, run Gpresult /v from the command line and output it to a text file. This powerful tool lists the user and computer policies applied and filtered, the registry policies applied, the security groups, the distinguished names of the user and the computer, and more. This tool can help you determine why a setting doesn't reach the client.
- The security event log can help enable auditing via group policy. Since these logs can get large, if you have Windows Vista or Windows 7, you should use custom views to limit data collection.
- Many authentication problems require a network trace. Two free tools that can help are Microsoft Network Monitor (Netmon) and Wireshark. Although Wireshark has some cool analysis features, many shops prefer Netmon because it's a Microsoft product and "feels safer." But you can get the best of both tools by collecting the network trace with Netmon and then analyzing it in Wireshark.
To get a network trace for a logon problem, take the trace from another client that is plugged into the same hub, or switch and use promiscuous mode. This captures all the traffic the client sees, and if it is physically close to the target machine, it will limit the data to only what you need. Both tools provide a command-line interface, which means you can use the Task Scheduler to set a network trace for a specific time.
Tip: Connect the cable from the wall to a hub, and then plug the target client and the client running Netmon into it. This isolates the traffic. Do not set any filters on the capture -- you can filter the output during the analysis.
- Process Monitor is a Sysinternals tool that can help you solve slow logon issues. The utility, which can be downloaded from the Microsoft website, shows what is going on under the covers. If you set Process Monitor to start at boot, you can see which processes open at startup.
To resolve connectivity and name-resolution issues, you usually need to look at the basics , such as the IP address and mask, the IP gateway and the Domain Name System (DNS) servers. In this situation, IP configuration (ipconfig.exe) is your friend.
- Ipconfig/all shows all IP settings -- IP, mask, DNS, Windows Internet Naming Service (WINS) and Media Access Control (MAC) address. Make sure that all these settings are correct. Although clients mostly use Dynamic Host Configuration Protocol addresses, check to see if the address is valid.
- Ipconfig/flushDNS purges the DNS cache. This is critical to do if you are troubleshooting -- and making changes to -- DNS.
- IPconfig/registerDNS forces dynamic registration of the client and creates a record at the DNS server.
- IPconfig/displayDNS shows the client's DNS record cache. This should be checked for bad records.
- If Ipconfig shows a "169.x.y.z" address, then the network connection is not working. As a result, the cable, driver or network interface card (NIC) may be bad.
- Ping the domain controller by name, or ping the domain name (e.g., ping corp.net).This will test if the DNS is working properly. Of course, you should also ping the IP address to see if there is connectivity.
- Use NSLookup to validate resolution of fully qualified domain names of servers, websites, etc. This will tell you if the client can resolve a name of a resource. If it fails, you know the issue is the DNS configuration.
Share connection and file copy
Users frequently complain about connectivity to shares and slow file copy.
Share connectivity issues could be caused by authentication problems such as incorrect assignment of user rights. This can be diagnosed with the command-line tools MyToken and Xcacls. By comparing the output of these two utilities, you can find security mismatches that cause access denied and other errors.After you download the MyToken tool, run it (C:>mytoken.exe). It will spit out the security token, including groups and the security identifier (SID), for the logged-on user, as shown in Figure 1.
Figure 1: The command link tool, MyToken, shows you a user's security token (click to enlarge).
Windows Server support tool Xcacls exposes the security on a file, share or folder, as shown in Figure 2.
This tool is useful because it shows you if the NT file system (NTFS) security you think you defined is actually what NTFS sees.
For convenience, copy these two tools to a convenient directory on any client.
Another helpful authentication tool from Microsoft is the Kerberos protocol. It provides a ticket-granting ticket (TGT) and a session ticket so that you can access the domain resources. The default lifetimes of the tickets are 10 hours on Windows systems (as defined by group policy). If you change group memberships or rights on a file share or resource, the current tickets for the client may fail. In this case, you either log off and log on to get a new ticket, or you can refresh the tickets by purging and reconnecting to the resource.
The Kerberos tickets can be exposed with klist.exe or kerbtray.exe. Klist is a command-line utility that lists (klist/ticket) or purges (klist/purge) all the Kerberos tickets. Kerbtray launches a program in the Systray and performs the same functions as Klist but with a simple graphical user interface (GUI). Both tools are found in the Windows Resource Kit.
When diagnosing client connectivity and authentication problems, it's important to understand the causes. The best way to do this is to watch what the user is experiencing and see where the delay or failure occurs. Then you can determine which tools are needed to gather the necessary data to troubleshoot.
ABOUT THE AUTHOR:
Gary Olsen is a systems software engineer in Global Solutions Engineering at Hewlett-Packard. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Olsen is a Microsoft MVP for Directory Services and formerly for Windows File Systems.