TCP/IP and Exchange Server

Systems administrators frequently choose TCP/IP as their basic network protocol. Large corporate installations prefer TCP/IP, and you must use TCP/IP to connect to the Internet. The sidebar "How Exchange Uses TCP/IP," page 2, explains why TCP/IP is essential when you use Exchange Server. Sometimes problems with TCP/IP configurations can delay client communications with an Exchange server. In this article, I describe two problem scenarios. The first scenario applies only to large deployments but illustrates that sometimes the most unexpected interaction between Exchange, Windows NT, and TCP/IP can cause problems. The second scenario, related to protocol binding order, is the most common cause of user complaints about slow connections.

WINS, Large Domains, and Client Authentication
Exchange uses NT to authenticate client connections. Whenever a Messaging API (MAPI) client such as Outlook attempts to connect to the Information Store or the Directory via the standard NT challenge/response mechanism, Exchange must locate a Primary Domain Controller (PDC) to authenticate the client's credentials against those for the primary NT account for the mailbox. In addition, large NT infrastructures usually deploy a set of Windows Internet Naming Service (WINS) servers to help servers find one another. WINS can tell you the name and IP address of any computer on the network registered with the WINS server. For more information about these concepts, see "Related Articles in Windows NT Magazine," page 3.

In large or distributed domains, systems administrators usually deploy Backup Domain Controllers (BDCs) to each location to ensure that NT will continue to authenticate clients even if the connection to the rest of the network is lost. For example, Digital Equipment uses one account domain for its European employees. The domain holds 26,000 accounts and deploys 45 BDCs and 18 WINS servers. Most locations have one BDC, but some have two or three (one for each major network segment). With so many domain controllers in use, the potential exists for multiple responses to logon requests.

Exchange checks client credentials by asking WINS for a list of domain controllers. WINS returns a list of as many as 25 domain controllers, composed of the PDC and the last 24 BDCs that made themselves known to WINS. (In small domains, the list is much smaller.) Exchange uses the list to broadcast a request for authentication and establishes a secure channel with the first controller that responds. Exchange uses this secure channel to authenticate subsequent client connections until two consecutive errors occur on the channel. Exchange then attempts to find another controller and establishes a new channel.

WINS delivers significant benefits to an NT infrastructure, but multiple domain controllers communicating with WINS can result in slow client authentication. Because the number of domain controllers in use affects authentication speed, you won't see a delay during authentication until the infrastructure expands. This problem illustrates why you must treat NT, WINS, and Exchange as an interconnected combination when you design systems.

Many factors contribute to how fast a controller responds to a request. A domain controller might be busy or temporarily unavailable, or the network link between the Exchange server and the domain controller might be saturated. Exchange can end up communicating with the most unlikely domain controller. When Exchange establishes secure channels in this manner, client logons are slower than usual, and people complain about how long Exchange takes to open their mailbox. Exchange isn't the culprit, but it takes the blame for one of NT networking's quirks. So, when you have large domains, you need to direct Exchange to the proper domain controllers.

To work around this quirk, you can specify the IP address of the preferred domain controller in the LMHOSTS file on each server. From Control Panel, Network, Protocols, select the TCP/IP Protocol, and then Properties, WINS Addresses. Select Enable LMHOSTS Lookup for the TCP/IP protocol, as you see in Screen 1. You can then use a text editor to enter the preferred controller into the LMHOSTS file. For example, the entry

16.240.80.144 "EXDOMAIN x1C" #PRE

specifies that the IP address for EXDOMAIN domain's preferred domain controller is 16.240.80.144. The #PRE suffix tells NT to load the address into the NetBIOS cache. Note that the text within the quotation marks must be exactly 15 characters long; insert spaces to make the text the required length. When you have inserted the information into LMHOSTS, exit the text editor, and use the NBTSTAT utility to reload the NetBIOS cache with the new data into LMHOSTS. Making an entry in LMHOSTS in this manner won't affect the current secure channel. The entry instructs NT where to look the next time it wants to establish a channel.

You can use NLTEST, a utility included in the Microsoft Windows NT Server Resource Kit, to find out which controller NT is using for a secure channel at any time. (For more information about NLTEST, see "Related Articles in Windows NT Magazine." For example, the command

NLTEST /SC_QUERY:EXDOMAIN

instructs NLTEST to check the controller for the domain EXDOMAIN. You can also use NLTEST to force a server to reestablish a secure channel. NLTEST looks at whether the contents of the NetBIOS cache specifies a preferred domain controller; therefore, you can use NLTEST with an updated LMHOSTS file to force NT to establish a new secure channel to a specified controller.

You can register other servers in LMHOSTS to ensure that messages will continue to flow even if WINS presents problems. In particular, you need to register crucial servers, such as those that act as bridgehead servers for sites, or those that host X.400 or Internet connectors. Then, even if WINS becomes unavailable, Exchange can still get the mail through. Remember that populating LMHOSTS is not a one-time operation, so arrange to keep the file up to date as you deploy new servers.

Although effective, the combination of LMHOSTS and NLTEST is labor-intensive, and you must set it up on each server. A better procedure is to use a mechanism—for example, SET-PRFDC, a utility available from Microsoft Technical Support (http://support.microsoft.com)—that you can manipulate programmatically as the need arises. SETPRFDC (for Set Preferred Domain Controller) provides NT with a list of the preferred controllers to look for when you need a secure channel. The syntax is

SETPRFDC  

For example,

SETPRFDC EXDOMAIN EXBDC1 EXBDC2 EXBDC3

tells NT that any time it needs a secure channel for the domain EXDOMAIN, NT must make a connection to the controller EXBDC1. If EXBDC1 is unavailable, NT tries to contact EXBDC2, and so on. You must make separate calls to SETPRFDC if you've allocated mailboxes to accounts in several different NT domains.

You can include the commands in a batch file and schedule them for execution at regular intervals. Digital Equipment uses SETPRFDC routinely; the batch job usually executes once an hour. Running SETPRFDC has no effect on either the network or NT, so you can use it whenever you like. A more sophisticated version of the batch file might consult a data file to determine the correct domain controllers for any particular server; this version can accommodate changes in the NT infrastructure as you add more servers and controllers.

Protocol Binding Order
The most common cause of user complaints about slow connections is clients using the wrong protocol binding order. MAPI clients such as Outlook always use remote procedure calls (RPCs) to communicate with Exchange. You can transport RPCs over several network protocols, including IPX/SPX, TCP/IP, and Banyan VINES. Clients attempt to bind to a suitable network protocol according to an order specified in the system Registry. Using the wrong order results in slow client connections. But you can easily correct the situation.

Table 1 lists the protocols that a Windows 95 client can use to send RPCs to a server. The trick is to put the protocol the client is most likely to use first and discard any protocols that the client will never use (or at least list them at the end of the order). Here's why: When a client attempts to connect to Exchange, the client retrieves the list of protocols from the system Registry. The client tries to bind to each protocol in order until it makes a successful connection. A connection attempt times out after approximately 1 minute, and a client might take 3 or 4 minutes to make a connection if it has to navigate through some unwanted or unsupported protocols en route. Because PCs have to look through the binding order, one PC can connect to the server in seconds, while another, identical PC might take minutes.

You can change the binding order on a PC at the following Registry key:

HKEY_LOCAL_MACHINESOFTWAREMicrosoftExchange Exchange ProviderRPC_Binding_Order

As you can see in Screen 2, TCP/IP is my preferred protocol. I could remove protocols such as IPX/SPX and Banyan VINES from the list because I never use them, but leaving them in the list is harmless.

If you use TCP/IP and have a well-managed infrastructure, you don't have to set a binding order on each PC. Tools such as the PROFGEN/NEWPROF combination can generate prepopulated Messaging API (MAPI) profiles for users the first time they connect to a PC. You can find out more about these tools in the Microsoft Knowledge Base article "XCLN: How to Set Up Windows 95 Roving Users with Profgen.exe" (http://support.microsoft.com/support/ kb/articles/q182/0/35.asp).

Problems with WINS servers affect client connections, too. For example, a client might fail to resolve the server name contained in a profile to an IP address because a WINS server is unavailable. However, the system will send a message to users that their Exchange server is unavailable or down for maintenance. Frequently, the server is not unavailable; however, the erroneous message illustrates how an application can take the blame for a problem in the supporting infrastructure.

Interconnecting Elements
A good TCP/IP implementation is important to Exchange. I've discussed two WINS-related problems, one slightly esoteric and encountered only in large deployments, and the other the most common cause of slow client connections. These examples demonstrate that Exchange is an enterprise application that depends on interconnecting elements: NT, the network, clients, and Exchange servers.