A client recently experienced trouble accessing its Exchange server. After starting the Outlook client, it took between three and ten minutes for the splash screen to disappear and the mailbox to appear onscreen.
Using the PING command from the Windows 95 and Windows NT workstations revealed normal round-trip times between the client workstations and the Exchange server. To see if the problem was due to either low memory resources or a memory leak in one of the NT modules, I restarted the server but noticed no changes after the restart.
Since the default gateway for the network server was using multiple network cards, and proxy software stood between the company network and the Internet, I placed an entry in the server’s host file. I then performed a restart to ensure the host file was read.
The problem continued to persist, so I used a protocol analyzer while starting Outlook and discovered that numerous ARP (Address Resolution Protocol) requests were coming from the workstation with no apparent answer. But, at some point, contact was made with the Exchange server, and the process of opening the mailbox proceeded as expected.
In the case of this particular network, no WINS server was being used. If it had, the next step would have been to go into the WINS Manager program and check for tombstoned entries in the Windows database. Tombstoned entries are those that WINS has trouble resolving and marks as possible problem entries. When having difficulty, this is an area worth checking because there is a known problem with WINS tombstoning devices that have static IP addresses assigned and aren’t renewed. If this is the cause, one possible solution is to create a static WINS entry allowing the resolution of the Exchange server name to an IP address.
From what I have read in various Microsoft technical bulletins, Outlook uses RPC (Remote Procedure Call) statements to access and transfer information with Exchange. After working through various Registry changes, which involved changing the protocols used for RPC communication and the order in which they were tried, I didn’t notice any changes in performance. I found the default was NetBIOS.
My final step (and the one that resolved the problem) was to create a HOSTS file on the workstations experiencing the problem. This file contained the Exchange server NetBIOS name (e.g., EXCHANGE_1) and the IP address of the server. No restart of the workstation was required for the change to occur. I didn’t find the true cause of the problem, but this fix satisfied management and allowed productivity to return to normal levels.
# Copyright (c) 1998 Microsoft Corp.## This is a sample HOSTS file used by Microsoft TCP/IP stack for Windows98## This file contains the mappings of IP addresses to host names. Each# entry should be kept on an individual line. The IP address should# be placed in the first column followed by the corresponding host name.# The IP address and the host name should be separated by at least one# space.## Additionally, comments (such as these) may be inserted on individual# lines or following the machine name denoted by a # symbol.## For example:## 220.127.116.11 rhino.acme.com # source server# 18.104.22.168 x.acme.com # x client host 127.0.0.1localhostThe authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.