Skip navigation

Optimize Outlook on Exchange

Configure Outlook for improved performance

Microsoft Exchange Server 5.5 has several components you can use to improve client, server, and networking performance. You can optimally configure Microsoft Outlook 8.03 to interact with Exchange by using the same techniques you used to optimize previous versions of Outlook and the Exchange client.

Optimizing network communications improves Outlook's startup time. If you misconfigure the client, it might have trouble locating the Exchange server. Two networking configuration areas you need to control are the network binding order and name resolution order. You can also optimize performance if you configure optimal address storage, message storage, and message archival.

Outlook Client Connections
When Outlook needs to communicate with the Exchange server, it establishes a remote procedure call (RPC) connection to the server, based on the RPC binding order you specify in the Registry. Depending on your Exchange and Outlook configuration and how you use the client, Outlook might frequently establish such a connection. An Outlook client connects to an Exchange server when Outlook starts up, connects to your mailbox, opens another person's special folder, and views Microsoft Schedule+ information or public folders.

When Outlook starts up or views special folders, it establishes connections to the Exchange server's private information store. Outlook identifies the Exchange server to connect to from your home server. Your user profile specifies this server. After you connect to your private information store, Outlook establishes a session to your home server and then uses that session for future communication.

Another user might give you access to a special folder. To view the folder, you must establish an RPC connection to the user's home server (which might also be your server). Select File, Open Special Folder, Exchange Server Folder. Specify the user's name and the folder to view.

A special public folder stores the Microsoft Schedule+ free and busy information. By default, the first server in a site contains the free and busy time for users in the site. When you invite users to a calendar-requested meeting, the calendar automatically connects to the public folder to retrieve free and busy information. If your home Exchange server doesn't house the free and busy public folder, Outlook establishes an RPC connection to the server in your site to get the free and busy information.

Multiple servers in a site can house public folders. As with the free and busy information folder, the client establishes an RPC connection to the server that contains the requested public folder. Large Exchange organizations with multiple sites can replicate public folders to all sites for easy access.

A client might have access only to public folders in another site. In this situation, Exchange uses public folder site affinity to inform the client which sites contain public folder servers and what order to use in connecting to them (based on affinity value). If the requested public folder is not on a server in the client's site, the client connects to other Exchange sites, in order of affinity, to look for the folder. A client might have to connect to multiple Exchange servers in the site before it finds the requested folder. Thus, a quick RPC connection between the client and Exchange servers is important.

RPC Binding Order
To connect to the Exchange server from Outlook, you must first find the server. This process involves checking the available network paths and resolving the server name. Outlook uses RPCs to communicate with the Exchange server. The RPC binding order determines the order in which networking protocols and applications protocols search for the server. Networks use multiple protocols and network programming interfaces. Outlook is network independent, so it methodically searches for the server on the network interfaces. The RPC binding order on the network interface is specific to Outlook and Exchange and is not related to the network binding order in Control Panel.

When an Outlook client communicates with an Exchange server, it uses the RPC binding order identified in the Registry to determine the appropriate protocol and interface for connecting to the server. Table 1 lists available transports.

The default binding order for a Windows NT or Windows 95 client is ncalrpc, ncacn_ip_tcp, ncacn_spx, ncacn_np, netbios, ncacn_vns_spp. The Outlook client attempts to use the first transport in the Rpc_Binding_Order Registry line. The client waits for a transport to time out before attempting to use the next transport listed. To improve connection time to a server, edit the binding order so the client uses the first binding in the list to connect to the server. The binding order you use depends on the protocols your server and client support. On TCP/IP protocols, the binding order depends on the name resolution mechanism.

You can change the Outlook client's binding order in the Exchange Registry. Go to the HKEY_LOCAL_MACHINE\ SOFTWARE\Microsoft\Exchange\ Exchange Provider Rpc_Binding_Order"="ncalrpc, ncacn_ip_tcp,ncacn_spx,ncacn_np,netbios,ncacn_vns_spp Registry key. To change the binding order on one or two machines, you can edit the Registry. If you need to make widespread changes, or you want your changes to be part of the standard installation, refer to the Microsoft Support Online article "XGEN: Changing the RPC Binding Order" (http://support.microsoft.com/support/ kb/articles/q163/5/76.asp).

We performed tests to determine which RPC binding order works with which network protocol. We put Outlook on an NT server, and we configured an NT server as an Exchange server. Table 2, Table 3, and Table 4 show the results for the TCP/IP, NetBEUI, and IPX/SPX protocols, respectively. Each network protocol allowed access only through specific RPC binding orders. We reconfigured Outlook to test each network binding. The order of binding options is unimportant if you place the preferred binding at the beginning of the list. The preferred binding depends on the protocol your Exchange server supports.

If your workstation uses IPX/SPX and TCP/IP but the Exchange server uses only TCP/IP, your RPC binding order must list TCP/IP as the first binding. If IPX/SPX is first, Outlook tries to connect via IPX/SPX, times out, and tries another protocol. These unnecessary steps slow your connection speed. If you use Named Pipes, Outlook tries to connect via TCP/IP or IPX/SPX, depending on your network settings search order for LANA bindings.

Name Resolution
After Outlook determines the communications pathway, it must resolve the Exchange server's name. Outlook's name resolution method depends on the RPC binding. When Outlook connects to an Exchange server, it relies on the current protocol's name resolution method. How long the Outlook client takes to resolve the Exchange server name depends on the protocol and resolution method it uses. Table 5 lists the available protocols and name resolution methods, in the order in which the client uses them.

LANA uses standard name resolution over the first protocol bound to the network card, as specified in the Registry by LANA 0. Table 6 lists LANA resolution methods for the specified protocols, in the order in which LANA uses them.

Clients using NetBEUI, IPX/SPX, or Vines IP protocols employ broadcast name resolution. TCP/IP has more difficult name resolution than the other protocols, because it uses different IP address resolution pathways.

Changing name resolution order. The binding order determines the connection type and the name resolution method Outlook uses, because both mechanisms relate to a protocol. On TCP/IP networks, the name resolution method depends on the type of NetBIOS node you configure your client for--that is, hybrid node (h-node), mixed node (m-node), point-to-point node (p-node), or broadcast node (b-node). You must understand when the client communicates with the server and how to modify communication to optimize performance.

On TCP/IP networks, the default name resolution method is Domain Name System (DNS), which creates problems. The name resolution search begins with DNS querying. If you have a DNS server that doesn't resolve the Exchange server name, Outlook continues querying the DNS server. Outlook repeats the DNS query as many as 10 times before moving to another resolution mechanism, and each query takes more than a minute. On a TCP/IP network, use TCP/IP as your first binding order to eliminate the DNS querying problem.

When Outlook uses TCP/IP as the network protocol and as the first RPC binding option, the connection is a sockets connection. Therefore, Outlook uses the Windows Sockets (Winsock) name resolution order, as Table 7 outlines. If NetBEUI is your network protocol, select Named Pipes for your first binding order. On IPX/SPX clients, select IPX/SPX as the first binding order.

We used TCP/IP as the network protocol and performed name resolution tests on three NT servers (an Outlook client, an Exchange server, and a sniffer) to validate the name resolution order for each binding order. We expected the ncacn_np binding order to use the NetBIOS name resolution search order. However, ncacn_np and ncacn_ip_tcp used the Winsock name resolution search order, as Table 7 shows. These bindings attempt to use DNS for name resolution (if you configure the client for DNS), so you need to make some adjustments when you set up Outlook to avoid the increased connection time we discussed earlier. You can set up a DNS server in your organization to support the Exchange server, or you can create HOST file entries.

When we connected to the company's network through Remote Access Service (RAS) or Dial-Up Networking (DUN), the RAS configuration prevented us from accessing the client's DNS server. The DNS server did not respond to the client's request and thus delayed Outlook's startup. After the DNS query timed out, the client checked the NetBIOS name cache, Windows Internet Naming Service (WINS) server, broadcast, and LMHOSTS file. To prevent this delay, we placed the Exchange server's IP information in the client's HOSTS file.

Managing Message and Address Storage
For optimal performance, the Outlook client must efficiently access information from the server. You can configure Outlook to access the server in several ways. The client software communicates with the server to send and receive messages and to access the global address list (GAL) and public folders. You can control how often this communication takes place. Modifying communications timing preserves network bandwidth.

You must decide where to store messages, addresses, and archive information. You can store messages and addresses on the Exchange server (within the Exchange database) or outside the Exchange database. Address information within the Exchange database forms a GAL, and address information outside the database forms a personal address book. You can use the contacts application to store information within or outside the Exchange database. Archive information includes old messages and meeting requests. You maintain this information on a workstation or file server.

Messages. You configure the client to dictate where it stores messages. You can configure Outlook to keep messages in personal folders (.pst files) or in offline storage (.ost) files. The Microsoft Outlook 97 Administrator's Guide (http://www.microsoft.com/outlook/adminguide) provides complete details about these files. You need to understand how each mechanism affects your networking and where to store the two file types.

You can store .pst files on your workstation or server. When you use a .pst file to store your inbox messages, Outlook funnels messages from the Exchange server to the .pst file. If you maintain the file on your workstation, messages move across the network from the server to the workstation only once. You can quickly read .pst messages because no network traffic is involved. Storing .pst files on your workstation has two disadvantages: You need to use backup strategies to prevent data loss, and you need to share your hard disk if you want to access your messages from another machine. In addition, Exchange places an exclusive lock on open .pst files, so you can't access your messages from a remote machine if your local machine uses Exchange.

If you store .pst files on a server (file share), Outlook moves messages from the Exchange server to the .pst file. As Figure 1 shows, this procedure requires two network transactions: one to move the message to the client and another to move the message to the file server. When you try to read a message in Outlook, a third network move occurs, to move the message back from the file server to the client. Deleting a message generates additional network traffic.

You maintain .ost files on your workstation. An .ost file maintains a synchronized copy of information from the server. If you have an inbox in the .ost file, incoming messages move from the server to the .ost file only once. You then work from a local message store. You specify the frequency for updating offline storage. If network bandwidth availability is inconsistent, you can use .ost files and synchronize events to improve performance. Offline folders increase the availability of messages. Outlook synchronizes the .ost file with the server, so you can maintain backups at the server, and you can retrieve messages from any workstation with access to the Exchange server.

If you store .ost messages on a server, the messages move across the network each time you access them. If you read messages only once and delete them, you generate the same amount of network traffic as if you used a local .pst file. Deleting messages without reading them (i.e., reading only the header) reduces network traffic. Reading messages multiple times generates excessive network traffic. Consider how you will access messages to determine the best storage option.

Addresses. You can maintain address information on the server (GAL) or the workstation or file server (personal address list). Each time you attempt to send a message, you access this information.

Working offline lets you use a locally cached copy of the GAL. This cached GAL resolves names more quickly than if you access the list over a WAN link. If your address book changes frequently, you must download it more often to maintain a current file.

You can maintain a personal address book (.pab) file locally on your workstation or remotely on a file server. File server storage provides central access if you switch machines, but it requires more network attention. Instead of using the .pab file, you can use the mailbox contacts to store personal addresses. One drawback is Outlook's inability to incorporate contact resources into distribution lists. This feature would eliminate the need for personal address books.

Archive information. Archiving messages can cause complications. You can archive messages you stored as .pst files or messages you stored on the server. The archive file is a .pst file, so if you archive .pst-stored messages, you move messages from one .pst file to another and thus create additional network traffic. The amount of network traffic you generate depends on where you store the archive .pst files. The default archive file location is the NT or Win95 profile path. If you use server-based profiles, the archive file follows you. Outlook copies the file as part of your profile, so your logon and logoff time increases as the file gets larger.

Outlook 98
Improperly configuring the client software can cause performance problems in Outlook and Exchange. Outlook 98 includes several enhancements. For example, many communications tasks that currently tie up the workstation are background tasks in Outlook 98, giving you more time to read and compose messages. If you haven't upgraded to Outlook 98, consider doing so.

Hide comments

Comments

  • Allowed HTML tags: <em> <strong> <blockquote> <br> <p>

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.
Publish