Exchange 2010 Archiving: Summary & Assessment

Exchange 2010, announced on April 15, 2009, has built-in email archiving. In summary:

  • Tightly integrated with Outlook.
  • PSTs can be dragged and dropped into the archive.
  • Unified search across the live message store and the archive.
  • Search across multiple mailboxes for qualified staff.
  • Simple retention policies, based on the number of days of retention, can be defined. These policies can be defined to apply to a folder, individual messages, or an entire mailbox.
  • Legal holds can be imposed, overriding defined retention policy.
  • There's basic mailbox and configuration logs and auditing.
  • Stubbing's not used.

Other comments:

  • It's very good that Exchange now has built-in archiving. This will be welcomed by many people and organizations, because purchasing and supporting a third-party archiving product introduces complexity and requires resources.
  • This is a solid and attractive first step for Microsoft in email archiving.
  • The capability is a sound basis for future enhancements. Examples of areas which no doubt Microsoft will make up for current shortcomings include:
    • More powerful policy definition and enforcement for determining what gets archived, retention policies, and content tagging/labels. Today these facilties are rudimentary.
    • Integrated support for instant messaging, SharePoint, and Windows files and folders. Today only email, voice messages, and text messages are supported.
    • Integrated support for other archive repositories, such as Documentum.
  • You often end up going to PowerShell to implement controls. As these settle down, Microsoft will implement corresponding GUIs.
  • For the moment, third-party products will continue to be able to compete based on superior capabilities. Longer term, however, it's likely that the market for third-party email archiving technology for Exchange will gradually diminish.
  • We look forward to learning more about the archiving. There are plenty of open questions, such as:
    • How scalable is it?
    • How will it integrate with other archives?
    • Do PSTs go away?
    • How are messages ingested?
    • How important is the archiving in reducing the size of large mail stores, given that stubbing isn't used?

... David Ferris

One Comment

  1. Kevin O'Brien
    Posted April 22, 2009 at 5:06 PM | Permalink

    Hi David,

    Great article. Exactly the information I was looking for. My company is about 2 months from rolling out a 3rd party archiving solution and now we are questioning if we should hold off and put the investment into Exchange 2010 early next year to save on the cost of the 3rd party app. I like the way Microsoft is empowering the users to manage their own archive. I have a lot of questions about the archived mail ingestion and database but so far I like what I read in your article.

    Thanks for taking to time to write this up.

    Kevin O’Brien

  2. Joe Vegh
    Posted May 7, 2009 at 12:40 PM | Permalink

    Hi David,

    Our company was about the purchase an email archiving solution, so when we have seen that there is a ex 2010 Beta, I have let my guys to test it.

    Here are our findings so far:

    – The archiving database is in the same exchange database. Not in a separated one. You can have many copies of that database, as the only redundancy concept that MS is going to follow in this version is “replication”.

    This means:

    a- Exchange is going to have larger databases as the database will have “live” data + archived data.

    b- If the plan is to have a replica of this data in another server, the replica is going to be the same large database with not only archived data: it will have live data as well.

    – The archiving method is the same as creating a PST, but in the server. Users will have a secondary archive mailbox as they currently have using PST files.

    – Outlook 2003 users will not be able to use this function. Outlook 2007, probably do, but the info about it is vague.

    – If the customer decides to purge old documents that are older than the retention, will need to use MRM (which was present in 2007 with the same procedure). This is a not really well done feature in 2007 and apparently that haven´t changed in 2010.This feature may impact server performance (taken from MS docs): “…Running the managed folder assistant is a resource-intensive process. You should only run the managed folder assistant when your server can tolerate the extra load…“

    – Retention rules or archiving rules, created by users, can only be done using Outlook 2010. OWA 2010 can see and run the rules, but it cannot create them. Previous versions of Outlook are currently excluded

    Can you please comment those? We are afraid that there will be no real archiving solution from MS until the end of 2010. So should we be waiting or get some third party solution?

    thank you for you advice.

    Joe Vegh

  3. Vaguely
    Posted June 8, 2009 at 10:52 AM | Permalink

    Hi David,

    Great little ‘Heads up’ on E14/2010 archiving…one question I do have is to do with the database sizes. One of the great attractions of 3rd Party archiving solutions (apart from the ease of use of tools to satisify legal) is their ability to move mail out of the Exchnage databases, thus enabling them to be kept undercontrol…how does Exchange handle this aspect? I note you mentioned there is no stubbing, does this imply that I am going to end up with unwieldly multi terabyte datastores?

    Many thanks

  4. Posted June 10, 2009 at 3:40 PM | Permalink

    Exchange 2010 will allow for Messaging Records Management (MRM)-based archiving of data from a primary mailbox to an archive mailbox – which must be located on the same store as the primary mailbox. End users can either drag and drop manually, or apply policy tags to items which MRM will move in the background. Administrators or compliance officers can also set MRM policies which apply regardless of user intervention.

    So this means that – as you suggest – organizations that are especially concerned with single instance storage (SIS) or other storage issues will want to either carefully-plan their storage architecture around Exchange 2010 or consider a 3rd party archiving solution. Microsoft is continually working on substantial performance enhancements with every release of Exchange, though I have not seen any published performance metrics on Exchange 2010 yet – I imagine we will see those once the final code is released to manufacturing later this year.

    Our perception is that Microsoft has built the archiving functionality in Exchange 2010 primarily as a mechanism to deal with PSTs once and for all, in essence taking on the storage archviing market. If you put yourselves in Microsoft’s shoes, any time a company has to deploy 3rd party tools — SANs, storage archives, etc. — this adds to the overall cost of running Exchange Server, and proves to be a sticking point for Microsoft as they position their solution against competitors such as Google Apps, etc. Of course, now that they have the archive built, they will go after the broad market that has no archiving solution yet, and will start chipping away at the low end of the compliance archiving market as well as their solution evolves over the coming years.

    Regarding Joe’s question about client support … I haven’t seen specifics from Microsoft on this yet but typically Microsoft addresses the next-shipping platform (in this case Outlook 2010) as their primary target and if they have time in their development cycle will try and back-port functionality into previous releases, starting with n-1 (i.e., Outlook 2007). This of course depends on how challenging the engineering effort is and whether they had time to get the required plumbing into Outlook 2007 SP2. I’m not sure if this will happen — ask your local Microsoft TAM for details or stay tuned.


Post a comment

You must be logged in to post a comment. To comment, first join our community.