Isolating Failures

When monitoring software or users report failures or send alerts, the administrator should start troubleshooting by validating that the failure really exists. To do this, the administrator needs a test workstation and test user account and also needs to understand how the particular application or service works.

Using a Test Workstation

To test a reported problem, the administrator should use a test workstation. This workstation should be configured to match an end user's workstation so that tests yield the same results the end user received. User applications should be installed on this workstation with the same settings and permissions. An alternative to having a test workstation is to use remote control software such as Remote Assistance to connect directly to the user's workstation and witness the reported issue firsthand.

Configuring a Test User Account

A test user account should be configured and used when troubleshooting user-reported failures or functionality issues. The test account should have the same level of privileges as the end user; otherwise, testing may yield different results.

Validating the Failure

The actual process for re-creating the failure should be known before the administrator tries to validate the failure. Usually, it's good to start with the end user who reported the problem. If the error, failure, or issue was reported by monitoring software, the server should be checked to see whether the system appears to be functional and the services or applications are running. If the system, services, and/or applications are still running, connectivity then needs to be tested. If the application is network based, as most are, network connectivity to the server should be tested first, followed by testing the application itself using the appropriate client software.

Locating Application and Service Dependencies

To isolate failures associated with applications and services, the administrator needs to understand and be aware of any service dependencies. For example, if a report indicates that Internet email has not been received, the problem could be the mail server, or it could be a dependency such as the firewall or DNS server for the email domain. If the Internet DNS server for the email domain is down or offline, the failure is not the mail server but merely the Internet DNS server, because other organizations are dependent on first locating the host record for mail from that DNS server before mail can be delivered.

To determine the network dependencies of a particular network application, refer to the manufacturer's documentation. If it is a Windows Server 2003 application, refer to Windows Server 2003 Help and Support for detailed information. If a server application runs as a Windows Server 2003 service, using the Services applet from the Administrative Tools menu, you can learn a service's dependencies on other services or system drivers, as shown in Figure 33.1 for the Windows Server 2003 DNS Server service.

Figure 33.1. DNS Server service dependencies.