Is Exchange 2010 the End of Third-Party Archiving

ARNnet columnist Lee Dumas writes:

Deploying Exchange with low-cost storage eliminates the need for a stand-alone archiving system in order to support large mailboxes. That’s because the whole purpose of archiving systems designed to enable large mailboxes is simply to move data to inexpensive storage.

He immediately adds this caveat though:

For customers that need to meet compliance mandates, a third-party solution is required.

Which is correct in many cases.  Initial discussions with some of our clients have indicated that Exchange Server 2010 archiving may not meet all of the compliance requirements.

But I disagree with this:

However, it can be limited to only those employees that fall under the compliance mandate’s umbrella.

The assertion here is that compliance is the only reason to use a third party archiving solution for Exchange Server 2010, now that Exchange supports much larger databases, mailboxes, and improvements have also been made to Outlook’s OST format for mailbox caching (Outlook 2010 can reportedly cache up to +10Gb mailboxes, the main constraint being hard disk speed in the client computer rather than the previous risks of OST corruption).

There is no doubt that the improvements to Exchange Server 2010 archiving in Service Pack 1 are a big step forward.  The main improvement is the ability to host the archive mailbox on a separate database than the primary mailbox, currently not possible under the RTM version.

However three significant limitations remain:

  • the archive mailbox must be on a database that is located in the same Active Directory Site as the primary mailbox’s database.  This will limit some organizations from being able to centralize their archives.

One important thing to note, is that in order to have support for personal archive mailboxes being on separate databases, both mailbox databases must be located within the same Active Directory Site.  The only time a personal archive will be supported on a database in a separate Active Directory Site is during a failover scenario where the database copy fails and activates on a separate server located in a separate Active Directory site.  But for normal operations, the user mailbox and personal archive mailbox database should be in the same Active Directory Site.

- Elan Shudnow

  • archive mailboxes are not cached.  This is a serious issue for mobile users, for example sales people working remotely on laptops.  Some third party archiving products do support offline caching of archives.
  • archive mailbox access requires Outlook 2010 or OWA 2010.  Exchange Server 2010 adoption will likely precede Office 2010 adoption in a lot of environments (eg anywhere that another application integrates with part of the Office suite, or the business uses custom macros, or they simply don’t want to do an Office update outside of their normal desktop/laptop refresh cycle).

Aside from those technical limitations the other common reason I hear from clients is that they are reluctant to lock themselves into an archiving solution until they have found one that meets 100% of their requirements.

Exchange Server 2010 archiving is good, but the reasons for choosing or not choosing it extend beyond the question of compliance.

About Paul Cunningham

Paul is a Microsoft Exchange Server MVP and publisher of Exchange Server Pro. He also holds several Microsoft certifications including for Exchange Server 2007, 2010 and 2013. Connect with Paul on Twitter and Google+.

Comments

  1. Good observations; can’t emphasize enough to customers that Exchange archiving is nice but may not comply with policies and regulations and it should be investigated before they expect to throw Vault out :)

    • I’m surprised that vendors (apparently) aren’t interested in integrating with Exchange archiving. It would be a killer feature for orgs that use the built-in feature but want to transition to a third party solution later.

  2. Gareth Murton says:

    I have read various articles praising Exchange 2010 SP1′s PST importing capabilities, but can only seem to find rather lengthy cmdlet/PowerShell processes. Until MS sorts this out, surely there are still opps for third party vendors.

    • Hi Gareth, the third party import tools aren’t always better. Sometimes, but not always.

      PST import is one of those “one time pain” exercises. Once you’ve gotten them imported and discontinued their use on an ongoing basis the quality of the import tools becomes a non-issue.

      I would say it could definitely be a decision point though for large orgs with heaps of PSTs scattered all over the place, or anyone uncomfortable working with scripts.

Leave a Comment

*

We are an Authorized DigiCert™ SSL Partner.