Microsoft posted a hotfix for Windows NT 4.0 Service Pack 4 (SP4) for a problem that can cause Exchange Server to stop responding with all Messaging API (MAPI) clients. The Microsoft article "Exchange Clients Appear to Intermittently Hang During Normal Operation" (http://support.microsoft.com/support/kb/articles/q239/1/32.asp) discusses the problem, but the details in the article are a little sketchy.
The root of the problem apparently lies with clients that connect over slow links. If you travel like I do, you spend quite a lot of time connected over RAS links back to an Exchange server. Most of the time you can send and receive mail without a problem, but occasionally Outlook 2000 appears to hang when I try to reply to or send a message. Outlook also hangs occasionally when I change folders or views on a folder. In most instances, if I leave the client alone for a little while, everything returns to normal.
Every MAPI client from Capone, the original client shipped with Exchange Server 4.0 in 1996, through Outlook 2000 uses Windows remote procedure calls (RPCs) to communicate with the server. MAPI clients use more network resources than other clients in part because they provide extra features (e.g., calendaring) but also because they depend on RPCs.
You can run a simple test to verify that MAPI clients use more resources. Connect to a server using DUN, and monitor the number of bytes being sent and received. Connect a MAPI client, and send a simple message. Then connect to another client such as Outlook Express 5.0 over either POP3 or Internet Message Access Protocol 4 (IMAP4), and repeat the same action. Although your mileage will vary, inevitably you'll find that Outlook Express connects to Exchange Server faster and uses fewer network resources to do the same job.
I don't intend this observation to slam MAPI but to prove that the MAPI/RPC combination can demand a lot of network. If you want to keep phone charges to a minimum, you might want to use Outlook Express to check mail when you're on road trips.
The Microsoft article explains that MAPI clients that connect to Exchange over slower connections have a higher latency in sending and receiving datagrams (the basic building blocks of RPCs). NT provides an RPC Receive Any Thread service that the Exchange Information Store (IS) service uses to process client requests. The problem occurs when the thread waits for additional datagrams to arrive from a client before it moves on to respond to other clients. A temporary network condition might well block the remote client and prevent it from transmitting to the server; if this blockage occurs, clients seem to hang. The problem can be infuriating for administrators because the problem can affect one client but not a similar client that is connected on the same LAN at the same time.
When the data arrives from the remote client, the block lifts, and the thread resumes regular operation. However, if the network is slow, the hang can become noticeable and last between 10 and 120 seconds. In these conditions, users typically conclude that Exchange or Outlook has stopped working and flood the Help desk with calls.
The fix has nothing to do with Exchange Server, and it doesn't matter which version of the server you are running. The IS service continues to run while clients appear hung, and you can start up a new client and connect to Exchange Server while the problem persists.
The hotfix addresses the problem by replacing rpcltscm.dll, a standard NT component. You can get a copy of the fix from ftp://ftp.microsoft.com/bussys/winnt/winnt-public/fixes/usa/ nt40/hotfixes-postsp5/rpcltscm-fix. Download rpslwfxi.exe for Intel systems or rpslwfxa.exe for Alpha. I've been running the hotfix for several weeks and haven't noticed any problems. Clients are operating smoothly and haven't hung, so I recommend that you investigate and test the fix if your installation supports remote clients. Microsoft undoubtedly will include this fix in NT 4.0 SP6.
This discussion illustrates that the world of Exchange and its clients is complex. Small problems anywhere along the line can stop service, so you need to keep an eye on everything—network, OS, clients, and server—and not just Exchange.
