Traditionally, Microsoft Exchange Server has supported only Messaging API (MAPI) remote procedure calls (RPCs) over protocols such as NetBIOS over TCP (NetBT). This model assumes that clients connect to servers across perfect networks or at least assumes a consistent standard of service in a corporate LAN. Many of us understand the frustration of watching Microsoft Outlook report frequent problems connecting to Exchange when we use slow or high-latency links such as a RAS dial-in. The RPC interchange is also fragile and prone to timeouts and failures.
A combination of Outlook 11 and Exchange Server 2003 (formerly code-named Titanium)—and to a lesser extent, a combination of Outlook 11 and Exchange 2000 Server—will deliver significant improvements in these networking areas. Both Outlook 11 and Exchange 2003 are currently scheduled for release in mid-2003, so the information that I report here is subject to change as Microsoft refines the products before their final release. The good news is that the new products offer such far-reaching enhancements that the idea of all these improvements being absent from the final code is inconceivable. We have much to look forward to.
Outlook 11 Networking Improvements
RPCs are sensitive to network latency—a problem that can affect both Exchange clients and servers. From a client perspective, RPC problems (most of which are due to excessive latency) become apparent when you see a pop-up window reporting that Outlook is waiting for Exchange to respond. Outlook might communicate with several Exchange servers during one session, as users move between their mailbox and public folders. Latency can affect any of these connections, so the existence of pop-up windows isn't necessarily an indication that a problem exists between the client and the mailbox server.
Because of the nature of RPCs, you can use low-bandwidth networks to connect Outlook to Exchange and transfer large items across the link, albeit slowly. (For example, many people use 9.6Kbps dial-up connections through cell phones.) To handle transfers over low-bandwidth links, RPCs split large items into multiple packets and transmit the packets in parallel. Unfortunately, applications might need to wait for the RPC transaction to complete and a response to return—a phenomenon you often see in Outlook-to-Exchange communications across high-latency links. In Outlook XP, Microsoft improved Outlook's ability to continue working while waiting for a transaction to complete, but room to improve further exists.
Among other improvements that Microsoft wanted to introduce in Outlook 11, making the client smarter about how it consumes network resources was important to the company, primarily because of the increasing demand for connectivity for mobile devices that use wireless networks—or even the latest cell phone networks. Devices such as the Tablet PC also pose interesting challenges for applications that need persistent connectivity with servers and become temperamental if they experience a network interruption. Outlook falls squarely into this category.
The four major areas of networking improvement in Outlook 11 are the use of HTTP to transport RPCs, the introduction of cached replication, improved compression and best-body support, and the addition of bandwidth profiles.
The use of HTTP to transport RPCs. Outlook 11 puts an HTTP or HTTP Secure (HTTPS) wrapper around the MAPI RPCs it sends to Exchange 2003. You can connect Outlook 11 to an Exchange 2003 server any time you're able to connect Outlook Web Access (OWA) to Exchange—with no requirement to remap RPC ports or establish a VPN. However, because Microsoft has changed the way RPCs work to permit this functionality, you must deploy Outlook 11 on Windows XP Service Pack 1 (SP1) or later on the desktop and connect to Exchange 2003 servers to enable secure authentication. In a front-end/back-end configuration, the front-end Exchange 2003 servers in the demilitarized zone (DMZ) can proxy the HTTP-wrapped RPCs to back-end Exchange 2003 servers. Also, the Exchange 2003 servers must run on Windows 2003 Server, as must the Global Catalog (GC) servers that Outlook uses. This functionality isn't available if you run Exchange 2000—you must upgrade to Exchange 2003 before you can connect Outlook to Exchange over HTTP.
Cached replication. Outlook 11 can fetch data from Exchange 2003, Exchange 2000, and Exchange Server 5.5 servers to maintain a local cache on the PC. The client then uses this cache to access messages and attachments. I discuss how the local cache works in the next section.
Improved compression and best-body support. New code in Outlook 11 optimizes the flow of RPCs exchanged with the server, so the amount of data sent over the wire during synchronization operations is reduced. Microsoft's efforts to reduce the level of Outlook's communication with Exchange should come as no surprise if you've ever monitored the flow of bytes across a dial-up connection as client and server patiently move messages from one to the other. Better compression and smarter use of network resources mean that you see fewer dialog boxes reporting that Outlook is waiting for Exchange to respond.
Best-body support means that Outlook can ask Exchange to provide native-mode content instead of forcing the server to convert message bodies into Rich Text Format (RTF). When an older Outlook client connects to Exchange, the server can't be sure of the message formats that the client can support. For example, Outlook 97 doesn't support HTML-format message bodies. If Exchange receives an HTML message, it doesn't take the chance that a client requesting synchronization supports HTML, so the server automatically converts the HTML to RTF and sends both copies to the client. Every MAPI client and Exchange server supports RTF, so RTF is effectively the lowest common denominator in any transfer operation. Sending two copies of every message body increases the amount of data that passes between server and client and makes offline folder store (OST) files much larger than they need be. When Outlook 11 connects to Exchange 2003, it asks the server to send its best body part, and the server can transmit just one copy without conversion.
Not only does this change reduce network traffic but it also takes a large processing load off the server because messages don't require conversion. Instead, if the client detects that it needs to convert the format of a message body, the client can perform the conversion locally rather than request a new copy of the data from the server. You won't realize the full advantage of best-body support until you upgrade every client to Outlook 11.
Bandwidth profiles. To force different replication behavior across different network connections, Outlook 11 features bandwidth profiles. The code that Outlook uses to replicate data across fast LAN-type connections is different from that used to replicate across slow high-latency links. In the status bar, Outlook displays the type of connection it's currently using. For example, Figure 1 shows that the current connection is "Fast," implying LAN or similar high-speed connectivity.
The prospect of corrupted data always exists when computers want to send data to one another. When Outlook encounters a "bad item" in a mailbox or public folder, synchronization can fail. Worse, a loop situation might result, in which Outlook merrily sends RPCs to the server with no effect except increasing network traffic. Outlook 11 incorporates a bad-item check to validate that items are complete (i.e., formed with a body part and full set of properties) before it attempts to synchronize into the OST.
The Local Cache
Previous versions of Outlook use online mode or offline mode. When a client is online, it connects to Exchange and you can work with any item in any mailbox folder, as well as public folders. All user actions generate server transactions and round trips between the client and server. When a client is offline, it uses an OST—to which you must first synchronize items before Outlook can use it. All activity is local until you connect Outlook to Exchange to synchronize changes between the server and local folders.
Working offline is acceptable if you can't do anything else and can't connect to Exchange. However, in offline mode, you have no access to the up-to-date Global Address List (GAL), can't perform free/busy lookups for meetings, and don't have access to folders unless you marked them for synchronization and then performed synchronization. Organized users prepare for road trips by downloading the Offline Address Book (OAB) and synchronizing their folders, but many people have found themselves offsite with no connectivity and a set of unsynchronized folders—so offline mode comes with some big potential traps.
You can use a combination of Outlook 11 and Exchange (Exchange 2003, Exchange 2000, or Exchange 5.5) to implement—as the default mode for Outlook to connect to Exchange—a cached mode for client-server communications. Essentially, this cached mode is a combination of online and offline working in which clients continually fetch data from the server in a background thread while processing user actions against data held in a local cache.
To set up the local cache, you change the properties of your Exchange server profile to use a local copy of your mailbox, as Figure 2 shows. By default, Outlook downloads headers, then the full content of items, to the local cache. To alter this behavior, you can change the mailbox's advanced settings to instruct Outlook to download headers only (to restrict network activity) or download full items immediately, as Figure 3 shows. My preference is to download full items because then the mailbox is in a completely populated state whenever I remove my PC from the network.
After selecting cached mode and logging out of Outlook, you log back on to Exchange as you normally do (i.e., to enable new mail notifications and so on), and Outlook begins to use the cache. The first task Outlook must perform is to build the local cache. If you've already been using an OST with a previous version of Outlook, you probably didn't synchronize every folder in your mailbox. Therefore, Outlook populates the content in those folders so that you have a complete local replica of your mailbox. If you hadn't used an OST before, Outlook builds the local cache from scratch.
In either case, ensuring that the local cache is completely up-to-date requires a substantial amount of processing and network activity. You might find that your PC's performance is a bit sluggish until Outlook finishes downloading content from the server. This operation can take longer than an hour to complete, depending on your PC's configuration, other work that you're doing during the download, the network connection's speed, your mailbox's size, and the number of folders your mailbox holds.
The size of the OST file on your local hard disk will inevitably grow larger than your mailbox. OST storage isn't as efficient as that of the Exchange database, so the typical result is an OST file that's approximately 80 percent larger than the mailbox. For example, my 686MB mailbox exploded to a 1.8GB OST file—a spike I couldn't initially explain, unless it was because of the mixture of RTF, plain text, and HTML messages in my mailbox. Later, I found that Outlook 11 copies the complete contents of any public folder that I included in my Favorites list. In my case, Outlook copied some folders that held more than 10,000 items, which accounted for much of the growth. After I removed the folders from my Favorites list, the OST file size dropped to about 900MB—still pretty big, but the functionality that the local cache delivers justifies the size.
Certainly, the availability of a complete copy of all folders available for offline work gives users an excellent opportunity to clean out old material and reduce the size of the OST file, but in reality, few users will take this chance. Best-body support, which is available only when you connect Outlook 11 to an Exchange 2003 server, helps to reduce OST bloat by downloading only one copy of each message.
While the download proceeds, Outlook displays its progress on the status bar. If you move to a folder that Outlook hasn't yet downloaded, Outlook immediately begins to download items into the folder so that you can work. Eventually, all folders are up-to-date.
Once you're using a local cache, Exchange asks the client to initiate synchronization any time new content arrives in your server mailbox. When a user receives mail, Outlook downloads the message header and the first 254 bytes of the message body so that the user knows who sent the message (and can see this information in the Inbox). Also, after Outlook downloads the initial data, it can execute rules and display message data in the preview pane (now called the reading pane). Simultaneously, Outlook downloads the message body and any attachment information and stores this data in the local cache. If the user decides to read the message and view the attachments, Outlook fetches the information from the server, displays it, and stores it in the local cache.
This processing works without any obvious impact on mail delivery, and users are unaware that Outlook is operating differently. New messages will take a little extra time to appear in the Inbox, but users won't notice unless they're running a client that doesn't use cached mode.
If the user decides to leave the message for later processing, a background thread ultimately synchronizes its full content into the local cache. If a network interruption occurs, Outlook can continue working with the local cache and wait until network functionality returns before recommencing synchronization and updating the local cache. Once Outlook is caching messages locally, it uses the cached versions and never goes to the server unless absolutely necessary—for example, to fetch an attachment that it hasn't yet downloaded.
Outlook uses an algorithm called Incremental Change Synchronization (ICS) to set checkpoints with which to determine the data that it has replicated with Exchange during synchronization sessions. In Outlook 11 and earlier, Microsoft set large checkpoint windows with ICS—a good idea for performance, but it means that any interruption of connectivity between the client and server forces Outlook to restart synchronization from a potentially old checkpoint. Microsoft has improved the ICS algorithm (it's now called Advanced ICS) to ensure that less data is recopied if an outage interrupts synchronization. Outlook's increases in performance more than compensate for the small decrease that smaller checkpoint windows cause.
The idea behind trickle-mode synchronization is to keep the local cache always up-to-date. Trickle-mode replication is also more suited to the type of slow, high-latency roaming network links that mobile devices (e.g., wireless and cell phones) use. It's also well suited to the roaming behavior that the Tablet PC encourages, wherein users can pick up their device and move from place to place within a building—a behavior that often results in frequent wireless-network connections and disconnections. The advantage of the mixed-mode approach is that you get good client performance while maintaining access to all the server features. People will still want to work in traditional offline mode to preserve network resources, especially across expensive dial-in links from hotel rooms or similar locations, but most users will find working in cached mode beneficial.
Cached Mode and Server Performance
Microsoft argues that cached mode improves client performance (because Outlook works with local data) and reduces network traffic and server load by replacing the typical client-server traffic and server transactions with a constant trickle-down to the client. Server performance improves because client operations are smoother, so supporting large user communities on a particular server becomes feasible. However, consolidation to a smaller set of servers is possible only when you deploy Outlook 11 and Exchange 2003 everywhere so that you can implement cached mode and take advantage of automatic data compression—a feature that only the Outlook 11 and Exchange 2003 combination supports. (I cover automatic data compression in more detail in a moment.)
In some instances, cached mode is inappropriate. Consider the following examples:
- Someone who roams from PC to PC shouldn't use cached mode because Outlook would need to rebuild the local cache on each PC the user visits, resulting in a drain on network bandwidth and an increase in server load. Also, the user wouldn't be too happy with a mailbox that's in a state of constant refresh. Your best bet is to advise roaming users to continue connecting to their mailbox and work online.
- Someone who uses a workstation infrequently shouldn't use cached mode because every connection would provoke a massive download.
- Someone who has a large mailbox shouldn't use cached mode. I know many people who have mailboxes larger than 2GB—some over 5GB. Creating a complete replica of such a large mailbox on a laptop doesn't make much sense, especially when you consider the increase in the OST file size. If you want, you can now create an OST file in Unicode format and grow the OST to a virtually unlimited size. Doing so isn't an especially good idea because OST performance seems to suffer if you use an OST file larger than about 1GB. Users with large mailboxes are better off working with an OST in offline mode because they can apply filters in their send and receive groups to restrict the amount of data that Outlook synchronizes with Exchange.
- Someone who uses Outlook through a Windows 2003 or Windows 2000 Terminal Services or Citrix MetaFrame thin-client connection can't use cached mode.
To monitor the flow of communications, Outlook 11 can track and report RPC performance data. Periodically, Outlook posts the data it captures to Exchange 2003, which collates the data reported by all connected clients. Administrators can use Performance Monitor to view the client-performance counters for the MSExchangeIS (Information Store) object. Clients experience a slight performance penalty when performance logging is enabled, but anyone who runs Outlook on a recent desktop or laptop computer will hardly notice the difference. Collation consumes some network resources when Outlook sends the data to Exchange.
Compression and Buffers
MAPI clients request that servers provide data in chunks or buffers. To optimize communication between client and server, the size of the buffers varies depending on the client version and the type of network in use. For example, as Table 1 shows, Outlook 2002 uses large 32KB buffers on LAN-quality networks and reduces the buffer to 8KB or even 4KB as the connection slows. Neither clients nor servers compress data before it goes onto the network.
In addition to its changes in local caching, Outlook 11 tweaks the buffer size and can now compress data. Exchange 2003 includes the same compression technology, so compression is full-duplex rather than one-way. However, compression occurs only when an Outlook 11 client connects to an Exchange 2003 server. Exchange 2003 knows whether a client can receive compressed data only if the client uses a special MAPI call to request data. Older clients don't use this call, so Exchange 2003 reverts to uncompressed transfers.
To perform compression and decompression, Exchange exacts a performance penalty. However, Microsoft believes that because the server needs to process fewer network packets, that penalty is negligible. Complete messages, including attachments, are compressed. In much the same way that Zip utilities achieve different compression ratios for different file formats, Exchange produces ratios that vary across different message types and attachments. For example, HTML and plain-text body parts compress to between 60 and 80 percent of their original size. Microsoft Word documents and Microsoft Excel spreadsheets compress well, whereas Microsoft PowerPoint presentations are less amenable to compression. Exchange, which already compresses RTF message bodies, gains further savings in bytes transmitted on the network.
Table 2 shows how Outlook 11 changes buffer sizes in different situations. (In an "offline" scenario, you prepare mail offline, then connect to synchronize your mailbox.) If you compare this data with that of Outlook 2002, you can see that Outlook 11 pays more attention to network utilization. I want to emphasize that the impact on servers gained through buffer optimization will vary depending on user behavior and format mixes. For example, if you upgrade servers to Exchange 2003 and leave clients alone, you won't see any improvement in terms of network demand.
Upgrading each client to Outlook 11 will bring some improvement, but not much if your users are using HTML as their message editor and sending large PowerPoint presentations to one another. You'll get the best results after your users upgrade to the latest version of Outlook and are sending a reasonable mix of HTML, plain-text, and RTF messages with various attachments.
Best Exchange Client?
Microsoft has done a lot of work to make Outlook 11 the best network client for Exchange, and the improvements are quite welcome. As Table 3 shows, you can exploit some of the new Outlook features against Exchange 2000 or Exchange 5.5, but you won't realize the full benefits of the network improvements until you combine Outlook 11 with Exchange 2003.
The biggest concern on the horizon is that many companies will need several years before they're ready to leverage smarter network behavior. Two- and three-year desktop refresh cycles are common, so the need to deploy a new version of Office and possibly upgrade the desktop OS is a more difficult hurdle to overcome than in Windows 2003 and Exchange 2003 on typical servers. However, if your company has many mobile users—particularly people who use notebook computers and travel extensively—you will certainly benefit from accelerating your upgrade program.
