The last blog post generated some great questions, and I wanted to address some of them in a little more depth and continue the archiving discussion.
“We are all for removing pst files from the network; however, the major challenge that we have is handling the use case where users are offline (i.e. not connected and require access to the archive ….)“
“is it possible to include and/or exclude the archive mailbox in the offline file set (.OST)?”
These are great questions because they get at something that comes up a lot when I am talking to customers: "Is there a difference between the 'archive' and a large mailbox?" The issue is important because the answer is at the core of the design decisions made in implementing this feature. The basic idea is that the reason that a user would move content from their primary folders to folders in their archive is because they rarely want to see this data but would prefer it off on the side. This could be just a clutter question or it could be about the amount of data that sits on their client machine. Fundamentally, if a user has .PST data that they consider to be part of their active working set that they always want to be able to refer to, it probably makes sense to keep that data in the main set of folders. Data there will be available off-line through the .OST. Only when the data gets old enough that, either due to space constraints on their client or for risk mitigation it is not longer worth keeping on the client should they need to move it to the archive.
Another way of putting it is that the ability to put content under the archive node is a way to manage the usability of the overall mailbox not to manage costs. To be precise, all the benefits of the low-cost storage design in Exchange 2010 accrue equally to all the content in Exchange. The ability to discover and retain data applies equally to all content. Where exactly the data should reside is about optimizing the productivity of the end-user.
For me, personally, I keep the most recent two years of email in my primary set of folders and then content older than that migrates to the archive to keep things from getting too cluttered. So I have mirrors of folders like inbox and sent items that contain older data and then I have project oriented folders that I move when they are no longer of immediate interest.
Perry
So far we have spent some time talking about how Exchange has been engineered to take advantage of large commodity storage while keeping the data protected and the overall system highly available in order to deliver large, low cost mailboxes.
This time I wanted to spend some time talking about how to take those abilities out for a spin and get some concrete benefits. Specifically, taking advantage of the extra storage to deploy an integrated archive at almost no additional cost and replace expensive add-on solutions.
The term archive covers a lot of different scenarios that people have deployed for email. The scenarios include: extending people's mailboxes to replace .pst’s and keep reference data around to reduce the amount of work recreating thoughts and ideas that have been worked through before; ensuring that the data that needs to be kept for compliance or policy reasons is actually retained; to make sure that discovery operations are reliable and cost-effective. The great thing about an integrated approach is that, not only is the cost of any one of these scenarios lower than the alternatives but once you have deployed the archive for discovery and policy retention reasons, users get the direct benefit of an extended mailbox for free.
Ensuring that Exchange 2010 delivers across the complete set of scenarios that people think about when they design archiving solutions did mean working through a suite of features. A lot of the discussion in this video is about how the different use cases are covered by the functionality in Exchange, but I also talk about the future of Exchange Archiving…there is always more work which can be done.
I'm interested in any questions or comments you have about Storage and Archiving.