I'm a self-confessed road warrior—one of those people who spend far too much time figuring out how to make connections from hotel rooms, airport lounges, and other places so that I can send and receive email. Slow connections are frustrating, and I never seem to have enough time to get through all the mail.

Microsoft Outlook supports offline working, which means that you read, delete, create, and send messages without a network connection; Outlook synchronizes all the activities with the server the next time you make a network connection. The basis of these actions is an offline store (OST) file, which stores replicas of folders that you nominate for offline access. By default, Outlook always makes replicas of the set of special folders (i.e., Inbox, Sent Items, Outbox, Deleted Items), and you can mark other folders by setting the synchronization properties of selected folders. I describe this process in more detail later in this article.

Good offline working habits make synchronization faster. Paying attention to the way you work offline and the data that Outlook holds offline can help you get through your messages more quickly. You can also tweak Outlook slightly to throttle back some functionality in a trade for shorter online sessions. Let's look at how you can streamline work on the road.

The Synchronization Process
Outlook 2000 is the first Exchange client to support background synchronization. Background synchronization means that the client can synchronize folders through a thread that runs in the background, while you continue to read, send, and file messages. The idea is great, and Outlook 2000 is much better to work with than earlier clients such as Outlook 98 or Outlook 97, which can't do anything else while the synchronization process is active. However, implementing background synchronization can't overcome the basic limitation of a slow connection. If you connect at less than 33.6Kbps, you can forget about doing much useful work while synchronization proceeds. In most cases, it's best not to attempt to do anything else that might slow down communications, including other network activities such as Web browsing, until synchronization is complete.

The synchronization process goes through several phases to transmit messages that you've prepared offline and to ensure that any other offline changes (e.g., updates, deletions, messages refiled to another folder) are replicated to the server to which you make a connection. Outlook signals each phase in the bottom right corner of the Outlook status bar, and you can keep an eye on the status and the statistics that the DUN applet reports to get an estimate of the network traffic involved in each operation. The exact amount of data transferred will vary because the amount depends heavily on the number and type of messages sent and the other changes that Outlook must replicate to the server.

Let's look at a typical scenario in which you've created several messages offline and then connected to send the messages. The default synchronization process goes like this. Outlook

• Makes initial contact—Outlook connects to the Exchange server where your mailbox resides. The program validates Windows 2000 or Windows NT LAN Manager (NTLM) security credentials for the user's account, opens the OST, and checks the security access. Every OST is tied to a Messaging API (MAPI) profile and mailbox, and you can access the OST when you use that MAPI profile to start Outlook. The OST contains a security token to ensure that Outlook can use it only with a specific mailbox, which is why you can't use an existing OST if you delete and recreate an account. To maintain security, you must always recreate the OST to ensure that only a specific account can access its contents.
• Starts synchronization—Outlook scans the OST for offline changes, and if it detects any changes, the synchronization process begins. Outlook 2000 uses a background thread for this purpose.
• Sends any outgoing mail—Outlook loads each message it finds in the Outbox folder up to the server and sends it as you created it on the server. Exchange might reject some messages at this point, if recipient addresses are invalid (e.g., if Outlook has validated addresses against an old Offline Address Book—OAB—or contacts with obsolete addresses). For this reason, encourage users to download the OAB regularly—at least once a month. You can automate OAB downloads by including the OAB in a synchronization group. However, my company's OAB is about 70MB, so I download it only when I'm connected to the LAN.
• Synchronizes the Inbox—Outlook changes to read the status of messages on the server that the user has read offline, updates message flags to signify whether the user forwarded or replied to a message, and removes from the Inbox messages deleted offline or moved to another folder.
• Synchronizes the Sent Items folder—After Outlook sends messages created offline, it must update the Sent Items folder on the server with copies of these messages. Outlook also updates the Sent Items folder in the OST, but to shorten the synchronization session, you can avoid this step by excluding the folder from the synchronization group.
• Synchronizes views—The final phase of the synchronization process ensures that the views of offline and server folders are the same. In other words, you need to see the same thing if you open either copy. Outlook also synchronizes any user-selected views (such as View by Conversation Topic or the Preview Pane), including any customized views that the user has created. Outlook holds views as special hidden items in Outlook folders. Behind the scenes, views are represented as indexes in mailbox databases.

As you can see from this process, the data sent during any session is a mixture of overhead and messages. For example, I created 23 messages offline and calculated the message sizes that Outlook reported, which came to 147KB. This measurement is unscientific, but it provides a guideline. When the synchronization process was over, the DUN applet, which Figure 1 shows, reported that the client sent 455KB and received 308KB (to update message status, views, and so forth).

These numbers don't mean that overhead increases by roughly three times the amount of data transmitted to send messages; the amount of overhead data remains almost constant as the message traffic grows. For example, if you sent the same number of messages that include some large attachments, making their total size approximately 3MB, I'd expect the total data transmitted would be around 3.5MB.

Recipients and Message Content and Attachments
You can easily see where some of the data that Outlook transfers from client to server comes from. Outlook uses remote procedure calls (RPCs) to transmit the content (including attachments) and properties of messages. Message properties include the recipients of the message, the subject, the date sent, and similar information. Some messages transfer far more properties data than content, especially when the message has many recipients. For example, if you send a one- or two-line message to 20 people, the content is likely to occupy less than a kilobyte, but the recipient data could take up 5KB or 6KB, based on roughly 600 bytes per recipient.

You can reduce the amount of this data by using system distribution lists (DLs) instead of inserting the address of each recipient individually. A system DL is expanded when the message arrives at the Exchange server (the SMTP Routing Engine expands DLs on Exchange 2000 servers, and the Message Transfer Agent—MTA—expands DLs on servers running earlier Exchange versions), but details of individual recipients don't travel around with the message. Personal DLs, which users set up in their contact folders or Personal Address Books (PABs), are expanded before Outlook transfers a message to the server, so Outlook always holds the individual recipients' addresses in the message header. When the header includes addresses, the overall size of the message increases. Thus, paying attention to how they add recipients to messages is one way users can limit the data sent between client and server.

However, even the most fastidious attention to recipients probably won't reduce connection times significantly. Message content and attachments affect connection times much more. Graphics in AutoSignature files probably cause the most wasted transmission time during Outlook synchronization. AutoSignatures let users provide additional information about a message sender, such as telephone numbers and business title. Unfortunately, artistically inclined users swiftly realized that they can incorporate graphics files into AutoSignatures. Most of these graphics only increase the amount of data that Outlook must transmit during synchronization.

Users might not realize the effect of cute AutoSignatures, but even the simplest graphic adds tens of kilobytes of data to each message, and more complex graphics can add up to a megabyte. For example, a small Compaq logo adds 40KB, while a logo rendered in 256 colors adds 212KB. If enough people add logos and graphics to AutoSignature files, the flow of email messages across dial-up connections slows dramatically, and your databases fill up with useless graphics. A better solution is to use text-based AutoSignature files that use a combination of fonts, type sizes, and colors to create the desired effect.

Proponents of graphics in AutoSignatures ignore the fact that the Exchange Server 5.5 Internet Mail Service (IMS) strips out embedded graphics when the IMS converts Rich Text Format (RTF) messages to SMTP/MIME before transmitting them outside an organization. Exchange usually passes through graphics in HTML messages. Thus, although internal recipients will see the graphics content, external recipients are blissfully unaware that the sender has included a sophisticated graphic. In light of this fact, there's absolutely no reason why people should engage in such a wasteful habit.

The standard format for Outlook messages is Microsoft RTF. Outlook can compress RTF content when messages are sent between client and server, and the DUN applet reports how successful compression is, if you look at the session statistics. For example, Figure 1 shows that the current session has attained a 46 percent compression ratio, which is quite good. The ratio covers both message content and attachments. If you use HTML instead of RTF as your standard message editor, the ratio gets worse because HTML content is never compressed. Adding Zip file attachments has the same effect. These attachments are already compressed and can't be compressed any further. The compression ratio for a session in which you send a number of messages with Zip file attachments will be much lower—5 percent to 10 percent isn't unusual. On the plus side, because most files become much smaller when they're compressed, a Zip file usually requires less transmission; therefore, synchronization is faster. Microsoft PowerPoint 2000 files are the exception; graphics are already compressed inside these files, so putting PowerPoint files in a message doesn't reduce the files' size significantly. The same is true of Microsoft Word 2000, which compresses graphics inside .doc files. However, Outlook doesn't handle graphics in documents and presentations generated by earlier versions of Microsoft Office so elegantly. Therefore, you'll do well to send those files in Zip files.

Controlling Flags and Properties
Microsoft designed Outlook to be a full-featured client, and enabling features incurs some overhead. Many features rely on updating flags or properties to reflect a message's current status. Any overhead becomes more obvious when communication links are slow, but fortunately, you can reduce Outlook's network requirements in this area.

Outlook treats every message as an object that has a set of properties, which MAPI defines. Familiar properties include message subject, the recipients, and date sent. Other properties are less obvious, and some aren't essential if you just want to send and receive email. For example, Figure 2 shows some detail from my Inbox. You can see that most of the messages have an icon with an arrow pointing to the left. This icon signifies that I've replied to the message.

Figure 3, page 12, is another example. In this case, the message header shows the time and date of your reply. Forwarded messages hold the same type of data. Outlook holds information about a message's reply or forward status in a set of properties that are updated during the synchronization process. However, because Outlook doesn't support field-level updates, it must update a complete item to effect these changes, so the data that Outlook must send from client to server increases dramatically. Typically, this is an insignificant factor in the background overhead of the synchronization process, but if you start to forward or reply to a message that has a large attachment, Outlook must resynchronize the complete message to ensure that it has the same status on the server and OST.

A future release of Outlook might address the lack of field-level updates, but until then, the only thing you can do is to instruct Outlook not to bother tracking reply and forward status: In effect, you disable these features. You can't disable the features only during synchronization operations, however. Once disabled, reply and forward information won't be tracked even when you're connected to the server across a high-speed LAN.

Like most magic with Microsoft products, you disable tracking of replies and forwards through a registry entry. Figure 4 shows a registry subkey you can add to disable the features in Outlook 2000. The subkey in Outlook 2000 is HKEY_CURRENT_USERSoftware\Microsoft\Office\9.0\OutlookOptions\Mail\RFNoTrack = 1. In Outlook 98 or Outlook 97, you use HKEY_ CURRENT_USER\Software\MicrosoftOffice\8.0\Outlook\Options\Mail\RF NoTrack = 1. After you add this subkey, the features will be disabled the next time you start Outlook. To enable the features again, simply delete the registry subkey. As always, use caution when you edit the registry to avoid damaging your system.

I've been running Outlook with these features disabled for several months, and I haven't missed them. I suspect many other users who spend a lot of time working across telephone connections don't care about this information, either.

Free/Busy Updates
Outlook uses free/busy information to track when people are available for others to schedule meetings and appointments with them. Exchange Server holds free/busy data in a system folder on the same server as your mailbox. At the end of an Outlook session, the client updates free/busy information on the server. The data transmitted at this point typically doesn't amount to more than a few thousand bytes, but it does account for a short delay before the client exits. If you're pressed for time and want to save a few seconds, you can break the connection before Outlook updates the free/busy information. The transaction will then time out, and Outlook will report that it can't perform the update.

Filtering Offline Folders
An OST file contains replicas of server-based folders. To make a mailbox folder available offline, right-click the folder, then select Properties. The Synchronization tab, which Figure 5 shows, lets you make a folder available offline. You can also apply a filter, if you want, by clicking Filter on the same tab. Filters specify criteria for Outlook to use when it selects items from the server to download to the offline replica. You typically use filters to restrict the amount of information in the OST. For example, you might decide that you don't want to download messages with large attachments. You can easily perform this task by creating a filter that specifies that Outlook copy only messages smaller than a certain size (e.g., 50KB) to the offline replica. Larger messages remain on the server until you can get back to the office and use a LAN connection.

If you want to limit connection times, you can create synchronization groups—target sets of folders that you want to synchronize together. For example, you can create a group that instructs Outlook to synchronize only essential folders when you connect. As I mentioned earlier, you can also download the OAB automatically by including it in a synchronization group. Figure 6 shows a synchronization group that I created to download the OAB and synchronize only two folders. To create a synchronization group, go to Tools, Synchronize, Offline Folder Settings.

You can also use public folders offline. However, before you can mark a public folder for offline access, you must first make the folder one of your Public Folder Favorites.

Every folder you mark for offline access adds overhead to a synchronization session. Outlook must check every folder and compare the contents of the server with that of the OST, and then synchronize the changes while considering any filter. If you want snappy synchronization sessions, limit the number of folders marked for offline access.

Streamline Your Client
Microsoft designed Outlook 2000 to be the premier, top-of-the-line client for Exchange. When you decide to use Outlook, you must accept that it's going to occupy resources such as disk space, make demands on your CPU and memory, and occupy network bandwidth. Outlook uses bandwidth not only when you use a dial-up link but also when you connect over a WAN link or have several users sharing a limited-capacity connection, such as a 64Kbps link from a branch office to a central server.

If you decide that Outlook requires too many resources, consider using Outlook Express as your client on the road. Outlook Express uses IMAP4 or POP3 (the former is preferred) to access an Exchange mailbox and uses far less bandwidth than Outlook. IMAP4 or POP3 requires less bandwidth than Outlook's MAPI RPCs, and Outlook Express is a less-functional client than Outlook. The good news is that both can happily access the same mailbox, so if you want the fastest connection across a low-bandwidth link and can live without features such as shared calendaring, Outlook Express is a solution you should consider. You can also use Outlook in Internet Mail Only (IMO) mode and connect it to Exchange through IMAP4. However, this option seems like overkill because Outlook's rich features are best used in conjunction with Exchange when connected through MAPI.

However, if you want to use all of Outlook's features, take care to work intelligently. Working offline and using synchronization thoughtfully, paying attention to the format and content of messages, and making some trade-offs between features and network consumption are all things you should keep in mind. Training is also an essential part of any deployment—the good habits you teach users can help keep down the demand for network capacity and reduce expensive phone bills from hotels and other locations.

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6