\[Editor's note: Share your Exchange and Outlook problems and solutions. Email contributions (under 400 words) to Karen Fisher at [email protected] Please include your phone number. We will edit submissions for style, grammar, and length. If we print your contribution, you'll get $25.\]
In our company, we use Exchange Server 5.5 for email messages on our intranet. However, the only Exchange server in our company doesn't have Internet connectivity. For Internet email, users connect to an Internet Service Provider (ISP) over a modem. All users use Outlook as an intranet and Internet messaging application in a Windows 95 (versions A and B) environment in a Windows NT 4.0 domain. Using Outlook as the only email application lets users keep all messages in one Information Store, maintain one address book, and use distribution lists containing internal and external addresses.
Our problem was that users on the same subnet as the Exchange server didn't have any problem connecting to the ISP, but users across routers experienced a connectivity glitch. When users across routers connected to Exchange Server and dialed in to check for messages on the ISP, Outlook froze after downloading the first message. When users weren't connected to Exchange (i.e., when they were working offline and using an .ost file), they could download messages, and Outlook disconnected gracefully. Microsoft Technical Support told us to include the Exchange server name in HOSTS and LMHOSTS files and remove unnecessary protocols from remote procedure call (RPC) binding. These actions didn't help.
We found out that a client machine loses its default gateway address while it is connected to the ISP. We created a batch file containing the route command to add a static entry in a routing table:
route add 10.1.00 mask 255.255.0.0 10.2.0.1
This entry explicitly points to a host 10.2.0.1 (the original default gateway for this subnet), which is responsible for delivering IP packets to Exchange Server subnet 10.1.0.0. In NT 3.51 and later, the route command has a -p switch that adds an entry permanently, but in Win95, the only solution is to run this batch file. At startup, every client machine executes this route add command.
Without the right default gateway, a client can't find Exchange Server if it is across a router. On a local subnet, you don't need a default gateway to contact a host; therefore, the client on a local Exchange Server subnet didn't experience this problem. Careful examination of the routing table showed us that the default gateway supplied by the ISP doesn't replace the original default gateway. Instead, the ISP adds a second default gateway.
Table 1 shows the first two entries in the routing table. The original default gateway is still in place, but it isn't operational. Its metric value increased from 1 to 2 when we added the second entry; however, the original gateway's higher cost won't prevent it from functioning.
|TABLE 1: Active Routes to Solve the Connectivity Problem|
|Network Address||Netmask||Gateway Address||Interface||Metric|