Outlook 2013, swelling OSTs, and retention policies


Speaking about OST sizes and the change made in Outlook 2013 to drive down the amount of data cached by users, another thought came into my mind (I know, a very unusual occurrence). Just how big can an OST grow to given that we’re in an era of 25GB-plus mailboxes? Mind you, I don’t know many people outside the Exchange development team and a handful of corporate executives that let their mailboxes get to such a size. The developers do so because they have to test the outer extremes of the product; corporate executives are forced to keep email in case a lawyer wants to know who they met, what they discussed, and what breakfast was like two years or more ago.

In any case, large mailboxes are here to stay. Indeed, the nature of the mailbox beast is that it will continue to swell over time. I’m sure that we will see 100GB-plus mailboxes touted as a major feature of email servers in a few years’ time. Maybe even a 1TB mailbox, but maybe not as the opportunity to store so much rubbish (for such is the nature of much email today) in one place is too much to contemplate.

An OST is not a particularly fast file format. It never has been and even the tweaks of the developers in Outlook 2013 to reduce file size through compression is unlikely to do much to transform this Fiat into a Ferrari. What’s more interesting is the focus on caching based on age, an attempt to help users keep their OST size under control by automatically removing items from the mailbox once they reach a certain age.

But users being users, there is a temptation to immediately change Outlook’s 1 year cache default to “all”, meaning that everything in the mailbox should be cached. This is absolutely fine if your mailbox, like mine, is a svelte 2GB or so. It’s probably not as good if you’re in the 10GB-plus range.

Changing Outlook 2013 Account Settings to set the data cached in the OST

The advent of solid-state disks (SSDs) for laptop PCs was seen as a solution to the problem a couple of years ago. However, although SSDs address a big issue for OSTs (the need to get to data faster than possible with a 5,400rpm standard laptop disk), they remain expensive and only really work if the OST remains under 10GB. Once you’re dealing with a big time mailbox, an SSD is mandatory but it’s not a panacea.

As it has been since the first corporate mailbox was deployed, the best way to achieve performance is to remove data from the mailbox. Less data means less work for all of the computers involved in mailbox access. So what’s the best way to achieve this goal?

The first point is that you can’t depend on users. No amount of preaching from on high will convince users to do the boring and mundane work necessary to review information in their mailbox and keep what they really need to retain. There’s always something more interesting and worthwhile to do, such as watching a football game or clipping your nails.

Given that users won’t clean their mailboxes, you have to automate to solve the problem. With Exchange (on-premises or Exchange Online in Office 365), that means the development and deployment of retention policies that will remove aged items from mailboxes either to the Deleted Items folder or (better) to an archive mailbox. Of course, there’s cost involved here because archive mailboxes require Enterprise CALs to be purchased, but I think it’s fair to say that most companies will acquire Enterprise CALs one way or another anyway and also that automation is so much easier and cheaper than any manual process.

It’s easy to understand that users won’t like Exchange to meddle with their mailboxes so some additional work is required to prepare the user community for the introduction of retention policies. In other words, don’t define a retention policy on Friday night and launch it without warning on users without expecting squeals of complaint and an additional workload for your help desk. This might well be what you want to achieve (at least the squeals) but probably not.

With Outlook 2013 on the way, it’s a good time to concentrate on what your long term mailbox retention strategy should be. It’s always good to be able to blame the introduction of new software for issues that impact users. Maybe you should take this opportunity?

Follow Tony @12Knocksinna

About Tony Redmond

Lead author for the Office 365 for IT Pros eBook and writer about all aspects of the Office 365 ecosystem.
This entry was posted in Email, Exchange, Office 365, Outlook and tagged , , , . Bookmark the permalink.

6 Responses to Outlook 2013, swelling OSTs, and retention policies

  1. My mailbox is right around 10GB, so, from disk space and perf perspective this feature is nice for me. Especially given the OST often balloons to multiples of the mailbox size.

    The downside is that the historical search experience effectively requires two searches as you have to re-request the search to do an online search of the server.

  2. Andrew says:

    It always seemed to me that the Online Archive was a clunky solution to give users lots of server-side storage without the OST growing too large. If the OST is now smart enough to only cache the most recent 12 months, then could this spell the end of Online Archive mailboxes? With this feature users could have 25+ GB primary mailboxes (with no Online Archive) and the OST would only every contain the last 12 months. Sounds good.

  3. Rich S. says:

    What about having retention policy’s that would archive and stub the email so that it’s available in an online archive or it is only brought down to the ost when accessed. Instead of saying only bring down the last 12mths of data we could set a policy to download the last X months AND download stubs for anything older I think this would be a great built in solution rather than implementing a 3rd party solution.

    • You can use retention policies to move items into an archive mailbox. This doesn’t “stub” items. It moves them completely into the archive and no trace is left in the primary mailbox. Feel free to give your comments to your local Microsoft representative for inclusion in their thinking about future versions, but I doubt this will happen anytime soon.

      TR

  4. Keith K. says:

    Microsoft will never use stubs! It’s useless and defeats the overall purpose. Either delete the email or archive the entire item. End of story…

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.