Troubleshooting Exchange Server 2003

In the Utopian world, nothing would ever go wrong with your Exchange Server 2003 organization. Unfortunately, we do not live in Utopia. In the following sections we will briefly examine some of the more common problem areas in Exchange Server 2003: network connectivity, Active Directory, and host name resolution.

Troubleshooting Network Connectivity Issues

Without network connectivity, there really is no Exchange organization. Network connectivity troubleshooting is part science, part art, and part luck. Those who do it well typically do it very well ‚ luckily for the rest of us, several very useful tools exist that can be used to diagnose and troubleshoot network connectivity issues.

PING To start out with, you should conduct the simplest of all tests: Can you ping key servers on the network? The ping command works by sending a series of ICMP Echo Request datagrams to a destination and waiting for the corresponding ICMP Echo Reply datagrams to come back. The return packets are then used to determine how many datagrams are getting through, the response time, and the TTL (time to live). Try to ping other Exchange servers, the DNS servers, the DHCP servers, the domain controllers, and the global catalog servers. This simple test can quickly rule out problems with network connectivity.

Ipconfig The ipconfig command can be issued from the command line to quickly detail the TCP/IP configuration status of all network adapters in a server.

Note ‚  

You ‚ d be surprised at the number of network connectivity problems that can be traced back to incorrectly entered TCP/IP configuration information (since most servers have static TCP/IP configuration, this can be a real problem if values are entered without caution).

Nbtstat The nbtstat command is used to resolve NetBIOS names to IP addresses. If your network is still supporting WINS, then the nbtstat command can be useful in your troubleshooting efforts.

Netstat The netstat command is used to display TCP/IP connection information and protocol statistics for a computer. You can use netstat to quickly determine what other workstations and servers have open connections with a server.

Tracert The tracert command uses ICMP packets to determine the path that an IP datagram takes to reach its final destination. Along each hop of the path , information is returned to the requesting server (where the tracert command was issued). The tracert command is useful in determining that a specific link or router is not functioning properly.

Pathping The pathping command is a newer command that is a mix of both ping and tracert . The pathping command provides the ability to determine the packet loss along each link in the path and at each router in the path to the destination, which can be particularly helpful when troubleshooting problems where multiple routers and links are involved. When you are tempted to use the ping or tracert command to troubleshoot a problem, the pathping command should more often than not be your first choice.

Telnet The telnet command can be used to test basic responsiveness of a service on a port even if ICMP packets are being blocked at the firewall (a common configuration in these times). By successfully connecting to an Exchange server at port 25, you ‚ d then know that SMTP was operating.

NetDiag and DCDiag More advanced network connectivity tools exist in the Windows Server 2003 Support Tools, which can be found in the Support/Tools directory on the Windows Server 2003 CD. You can use the NetDiag tool to troubleshoot and isolate network connectivity problems by performing a number of tests to determine the exact state of a server. You can even fix some simple problems directly with the NetDiag tool. The DCDiag tool is used to analyze the status of all domain controllers in a forest and provides very detailed output, which can then be used to identify problematic behaviors.

Troubleshooting Active Directory Issues

Exchange Server 2003 relies on Active Directory for virtually every operation that it performs . Therefore, should domain controllers and global catalogs be unable to be contacted, you should expect that problems will quickly appear in your Exchange organization. Common problems include users being unable to authenticate themselves , new objects (such as users) cannot be created, group membership changes cannot be made, or the schema cannot be extended for installation.

Users cannot authenticate In organizations that are still operating at the Windows 2000 Server mixed domain functional level and have non ‚ Active Directory ‚ aware clients , such as Windows NT 4.0 Workstation or Windows 95, difficulty contacting the Primary Domain Controller (PDC) emulator will result in authentication problems. In non-mixed domains, the failure to contact a global catalog server or domain controller will result in authentication problems.

New objects cannot be created New objects cannot be created without first contacting the Relative Identity (RID) master . When this problem occurs, you should check connectivity to the RID master and ensure that it is, in fact, still operating correctly.

Group membership cannot be changed The Infrastructure master must be contacted any time you need to change group membership. When group membership cannot be changed, you should check connectivity to the Infrastructure master and ensure that it is, in fact, still operating correctly.

Schema cannot be extended As discussed previously, a failure to contact the Schema master when attempting to run the forestprep command will prevent the schema from being extended. When this problem occurs, you should check connectivity to the Schema master and ensure that it is, in fact, still operating correctly. If your DNS settings in the TCP/IP configuration are incorrect, you will likely have this problem.

Troubleshooting Name Resolution Issues

Name resolution issues can sometimes be the most difficult to troubleshoot and correct because they can manifest themselves in a seemingly endless number of ways. The situation becomes even more complex when you still use and support WINS servers or legacy non ‚ Active Directory ‚ integrated DNS zones.

Most times, the complete failure of DNS in an Active Directory domain is highly unlikely ‚ especially when Active Directory integrated zones are in use. More likely problems with name resolution include improper or no TCP/IP properties configured on the computer, negative cache entries in the local DNS resolver cache, or network problems that are preventing effective communications between DNS servers and DNS clients.

To clear the local resolver cache, issue the ipconfig /flushdns command from the command line. If the issue is that the DNS client has not properly registered its host records with DNS, then you can force the situation by issuing the ipconfig /registerdns command at the command line. You can also use the nslookup command to gather information about the DNS infrastructure inside and outside your organization and troubleshoot DNS- related problems. Note that for nslookup to function completely properly, there must be a reverse lookup zone configured on the DNS server that is authoritative for the DNS zone you are querying.