Problem solve Get help with specific problems with your technologies, process and projects.

Microsoft Outlook caching considerations

Microsoft Outlook's cached mode is a valuable feature, but it can consume a considerable amount of system resources, and there are some environments for which it isn't recommended. In this tip, SearchExchange.com contributor Brien Posey explores the issues you need to consider when implementing cached mode on your Outlook clients.

In Outlook 2003 cached mode is a mechanism that keeps users' Exchange Server mailboxes synchronized with offline folders that reside on their local hard disks. The idea is that if an Exchange Server fails, users can still access their messages.

Outlook cached mode is a valuable feature, but it can consume a considerable amount of system resources, and there are some environments for which it isn't recommended.

There are two primary types of system resources you need to consider when deciding whether or not to use Outlook cached mode in your organization -- disk capacity and network bandwidth.

Disk capacity 

With disk capacity, you obviously must ensure your users have enough free hard disk space to store the cached file. Just as importantly though, you need to check the sizes of users' mailboxes.

This is important because Microsoft Outlook uses an .OST file to store cached data. Once an .OST file exceeds 1 GB in size, performance begins to suffer. If some users' mailboxes are too large, consider archiving older data to lighten the load.

Network bandwidth and synchronizations

At first, network bandwidth would appear to be a non-issue -- assuming that all users are located on the company's LAN, and nobody is connecting via a dial-up or a slow WAN link. However, bandwidth consumption can be a serious issue even on a high-speed network.

By far the biggest impact on network bandwidth is the initial synchronization between workstations and Exchange Server. During the initial synchronization, all pre-existing Microsoft Exchange data must be copied from the Exchange server to the .OST file being used for a user's cache. Subsequent synchronizations only copy data that has been added or modified since the previous synchronization.

Normally, even an initial synchronization doesn't generate enough traffic to severely impact a network. The problem comes into play when multiple workstations are simultaneously performing initial synchronizations.

Imagine the impact that the synchronization process would have on a network if 500 workstations tried to synchronize simultaneously, and each user had an average of 250 MB of Exchange Server data. Over 122 GB of data would have to be synchronized! That data would then have to be distributed among 500 different clients. So the performance impact would be much higher than if a single 122 GB file were being copied from one computer to another.

You can ease the pain of initial synchronizations by staggering cached mode implementations. Try implementing cached mode on just a few computers at a time, rather than all of the computers at once, to avoid a major network traffic jam.

Synchronization traffic can also become an issue if users are in the habit of clicking the Send/Receive button (or pressing F9). Once the initial synchronization has occurred, subsequent synchronizations are automatic. However, if a user clicks the Send/Receive button, they will initiate an unnecessary manual synchronization.

I know a few administrators who have gotten around this problem by disabling the Send/Receive button. But, disabling the Send/Receive button prevents users from downloading e-mail from a POP3 server. In a pure Exchange environment, this shouldn't be a problem -- but it is something to consider before you decide to disable the button.

Outlook cache mode caveats

There are some Exchange Server environments in which implementing cached mode can be problematic. Unfortunately, it's impossible for me to address every situation in which cached mode could perform less than ideally. What I can tell you is that it works well as long as Microsoft Outlook does not try to access data from the network while the user is working offline.

One example of such an environment is one in which instant messaging is integrated into Microsoft Outlook. In such an environment, if a user right clicks on the Person Names smart tag in the message header, Outlook will attempt to access the person's free/busy information, which requires network access.

Another example of a problematic configuration is an environment in which address books other than the Global Address List and the Outlook Contacts List are in use. Since Outlook allows you to specify in which order address books should be checked when resolving names, a custom address list can take higher search priority than the Global Address List or the Outlook Contact List. That being the case, Outlook may attempt to access the network in an effort to access the address list to resolve a name when a user composes an e-mail message.

Conclusion

Microsoft Outlook cached mode can be a handy feature, but you should think about the impact on your network before enabling it.

About the author: Brien M. Posey, MCSE, is a Microsoft Most Valuable Professional for his work with Windows 2000 Server and IIS. Brien has served as the CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. As a freelance technical writer he has written for Microsoft, CNET, ZDNet, TechTarget, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal Web site at http://www.brienposey.com.

 


MEMBER FEEDBACK TO THIS TIP

Another caching gotcha is a situation where messages leaving Outlook 2003 in cached mode are not being checked for Exchange Sending Size Limit as the user sent the message from Outlook, but only by the server once the message reached it. An NDN (non-delivery notification) with the large attachment will come back from the server with a friendly Send Again button just sitting there asking users to click it.

So if someone sends a 10 MB message from cached mode Outlook, those 10 MB would go over the network. The Exchange servers would then see that the message is over the Sending Limit (let's say 2 MB). The message would subsequently be sent back at 10 MB in the NDN. The user -- having limited understanding of the error message in the NDN -- would send it again and you'd have 40 MBs going over your network when none should have been allowed.

This is fixed in Service Pack 2 of Exchange 2003 and Outlook 2003, but you must deploy both the server- and client-side service packs!
—Lee Benjamin

******************************************

This is the first that I have heard of this particular issue. Thank you for sharing it with me.
—Brien Posey, tip author

******************************************

"This is important because Microsoft Outlook uses an .OST file to store cached data. Once an .OST file exceeds 1 GB in size, performance begins to suffer. If some users' mailboxes are too large, consider archiving older data to lighten the load."

Regarding the above statement, I was under the impression that Microsoft increased the limit to 20 GB beginning with Outlook 2003. Why would they increase to 20 GB if performance suffers at 1GB?
—Steve B.

******************************************

Microsoft has a long history of developing software that exceeds the capabilities of the current hardware. The physical limit is much higher than the point at which performance begins to suffer because the folks in Redmond have designed Outlook so that it can grow with the hardware.
—Brien Posey, tip author

******************************************

This is a very interesting article. How much network bandwidth can be conserved if users save their messages to a .PST file?
—Ted O.

******************************************

Saving to a .PST file doesn't really do anything to conserve bandwidth.
—Brien Posey, tip author

******************************************

We recently migrated to Exchange 2003 Enterprise Edition with SP2 and Outlook 2003 clients. We have roaming profiles which means the .OST file ends up in their User drives. Our backups have since started to bloat.

We need to figure out a way to exclude the .OST in the backup (we use NTBackup) or redirect the .OST file. This will probably cause problems when users log on to different PCs. Do you know to exclude types of files in NTBackup? Any recommendations?
—Brian C.

******************************************

If you want to exclude .OST files, select NTBackup's Backup tab and then select the Options command from the Tools menu. When the Options properties sheet opens, go to the Exclude tab. Click the Add button and you have the option of excluding any file type that you want.
—Brien Posey, tip author

******************************************

Excellent! This is exactly the information I was looking for. It can also be used for excluding other superfluous stuff from tape backups.

Thank you!
—Brian C.

 


Do you have comments on this tip? Let us know.

Related information from SearchExchange.com:

 

Dig Deeper on Outlook management

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchServerVirtualization

SearchCloudComputing

SearchSQLServer

SearchEnterpriseDesktop

SearchVirtualDesktop

Close