Beginning with Exchange 2010, the ability to give users a Personal Archive hosted within Exchange was brought into the core product. Previously users would rely on either PST files held locally or copied to a network share, or by using a third party product like Symantec Enterprise Vault, which with software add-ons and a third party management server allowed messages to be archived and retrieved via “stub” messages.
The personal archive feature (sometimes known as the “Online Archive”) works by allocating a user a second mailbox. With SP1, the Personal Archive can be located on a separate database, separate server or even (when Office 365 is released) in the cloud. Server-side policies control when messages are automatically moved to the Personal Archive and this can be accessed by users using Outlook Web App, Outlook 2010 and very soon, Outlook 2007. Effectively, it’s a way of splitting the current, important mailbox data from the little used reference material that is kept for compliance or convenience reasons.
However, one of the big strengths in Exchange 2010 is that you don’t need to archive just to maintain performance and keep server costs down. Due to the lower disk performance required Exchange architects can design solutions that make use of large 2TB SATA disks to give users massive mailboxes of sizes higher than 25GB in some cases. And when it comes to mailbox server sizing, the advice for databases that will store primary mailboxes and archive mailboxes is pretty much the same.
This lead to the obvious question – if I can give users massive mailboxes, what is the point of the personal archives? Wouldn’t it make more sense to just give them the whole mailbox as one?
I’ve thought about this a little bit and while just using large mailbox does make some sense – especially from a client compatibility point of view (e.g. limitations of IMAP, Mac, Activesync), and because archiving requires Enterprise CALs, there are certainly a number of good, sound reasons to consider the use of personal archives:
Reason 1 – Reducing Outlook Client’s Offline Cache Size
If you give your users a 25GB mailbox, then for most clients, that means a 25GB OST needs to be maintained on each workstation. With the rise of remote workers, “bring your own PC”, virtual desktops and taking into account the amount of fragmentation that will occur on the local cache file, this might be undesirable. Although many users won’t immediately make full use of these massive mailbox sizes, don’t underestimate how many users may take the opportunity to (wisely?) import their old PST files into their larger mailboxes.
By splitting the full quota between the primary mailbox and personal archive, you have a predictable offline file size for clients and can still grant users the larger quotas.
Reason 2 – Tiered Database Copy Levels
How important is the archive data? If it’s previously been stored on the local users’ PCs, then it’s probably not mission critical to the business. If it’s been on file shares, then again there might only be two copies – one online and one on the file server backups.
So, why not consider having different database “collections” for primary and archive mailboxes, and having a different level of copies for the archive databases. For example, databases dedicated to primary mailboxes may have two on-site copies, a lagged copy and a copy at a DR datacentre. The databases dedicated to archive databases may only need one on-site and one at the DR datacentre. You could reduce the number of mailbox servers and storage required to support a large mailbox infrastructure whilst still maintaining the levels of resilience you want for your most important data.
Reason 3 – Choose Different Backup Policies for Archive Databases
If you’re still backing up the traditional way, then you are probably making sure the databases containing the user’s primary mailboxes have a reliable, up-to-date backup. It may well be direct to disk then streamed off to tape after a certain amount of time has past.
Does all the email need this level of recoverability? The personal archive will have messages moved to it daily as it hits the policy for removal from the primary mailbox – but those messages about to be archived are already being backed up as part of the main backups. You could consider using a different backup policy altogether for databases dedicated to archives, such as weekly if you do daily, or daily if you do hourly? Maybe backup direct to tape, or even consider relying on database copies alone. You could reduce the amount of infrastructure you need to build out for your backup systems.
Reason 4 – Total Disaster Recovery
By a total disaster, I mean total! We like to think it won’t happen to us, and thankfully with Exchange 2010 the prospect of having to do a dial-tone recovery is one many Exchange admins will never face. But what if the worst does happen? At upto 2TB a mailbox database, how long will it take to restore all those massive mailboxes?
Using dedicated archive databases and personal archives could mean in such a scenario you can bring users to near full working ability by bringing their smaller primary mailboxes from backups and then bring the personal archives back afterward. Given most of the users will be able to work normally, management will hopefully stop breathing down your neck and let you get on with the (still mammoth!) task of bringing back those archives.
Reason 5 – Host Archive Databases Centrally with Primary Mailboxes at Branch Offices
It may be be that for branch offices, you aren’t even going to consider placing Exchange servers at each location and just have everyone hooked into HQ. But if you are placing Exchange servers at each branch office, then you will be no doubt need to plan for backups. Deploying massive mailboxes could be a problem as then you need to take into account how you will re-seed (if using DB copies) or restore from backups should the need arise.
Hosting personal archives at HQ could be an option to mitigate against these risks, whilst still ensuring the primary mailbox is local to the client. You can deploy smaller servers at the remote offices and reduce the time taken to restore should the need arise.
Reason 6 – Host Archive Mailboxes in the Cloud
Finally, why not host the archives in the cloud? Early next year after the release of Office 365, you’ll be able to look at the option of letting Microsoft host your entire Exchange infrastructure. But if that isn’t for you, Office 365 will also offer the ability for personal archives to be hosted in the service. Obviously there are a lot of other factors to consider, such as costs compared to hosting these in-house, regulations you need to comply with, and any internal barriers to adoption. But there could be serious savings to be made; and the chance to limit the up-front costs associated with moving to Exchange 2010, whilst still providing large total mailboxes and an on premises Exchange system.
What are your thoughts? Do these reasons make sense to you, or not.. Have any more ideas about why you should or shouldn’t use archiving in Exchange 2010? Let me know in the comments…
Great article, one thing I think is worth mentioning that almost caught me out when speccing Exchange 2010 archiving was that it requires Office Pro Plus at the client side (Plus Enterprise CAL of course). Client’s without this can still manage their archive via OWA but it’s not really ideal.
through the streets of the city, only their pudenda covered, as they had gone beyond any sense of shame. Each carried a leather lash in his hand and hit himself on the shoulders till blood came; and they were shedding abundant tears as if they saw with their own eyes the Passion of the Savior;
Before you ditch your third-party archive, you might want to talk with your GC to see what requirements they have to ensure your business complies with Federal and State regulations. If you for instance are in Finance and have stock brokers you will need to comply with SEC 17-a rule that states clearly that the archives must be stored in a non-tamperable format, something that Exchange 2010 can’t do.
The article is good from a technology standpoint, but misses why people have archives .. it isn’t just about Exchange anymore, but also to ensure other vital records like File and SharePoint data is retained and put on litigation hold when reasonably anticipated. The Discover functionality will only work if ALL your servers are running Exchange 2010 and the archive is ONLY available for the client if he runs Outlook 2010 and for some organizations this might mean that they will need to do a desktop refresh (on top of course of buying the eCAL which is roughly the same cost of a 3rd party archive)
The Discovery functionality in Exchange 2010 is extremely lightweight and fails to provide you with an chain of custody audit including if any data got deleted from the search result set, something a plaintiff might challenge you on.
Lastly .. Exchange 2010 doesn’t really do much to bring in those pesky PST files from laptops and desktops. Relying on end users to this themselves is doomed out of my nearly 15 years of Exchange experience.
🙂
Hi Martin,
I agree with you almost entirely – there may well be needs that Exchange out of the box cannot meet and add on software may be required. Isn’t this always the way with Microsoft products, though? If it did everything there’d be a lot of upset partners!
The main point is about use cases where one might not deploy archives at all, given the ability to use much larger primary mailboxes. My thinking is to see if you can do more with the same or less kit and still provide the same sort of levels of resilience.
Regarding the eCAL – don’t forget that the eCAL covers more than just archiving – it can replace other expensive solutions like voicemail, virus protection and outsourced spam filtering to name just a few. And because of MS’s heavily discounted enterprise/campus agreements the eCALs can be cheaper than just the maintenance on one of those solutions.
I totally agree with you on the PST issue. The SP1 mailbox import features are not ready for prime-time yet due to issues still being worked out by Microsoft and even then require complicated scripts to import, just from file shares. I’ll be doing a write-up on a third party solution soon that manages this process.
Steve
Hi Steve and Martin,
I don’t ompletely agree with both of you.
You can enforce pst usage from gpo, thus preventing pesky pst’s.
The archives can now be viewed with clients Outlook 2007 Sp3 and higher.
With my clients I see the interest in Exchange 2010 including archiving growing rapidly.
The interface for end users is the same as the Outlook or OWA client, no special Vault Explorers.
For admins there are less solutions to manage, have you ever tried to restore a mailbox with an Enterprise Vault archive that had been deleted ?
It took me 2 days to setup a test environment with Exchange 2007 and Enterprise Vault.
Maintanance is so much easier for admins.
We have a very costly cloud 10 year archive and DR site for a relatively simple two site Exchange setup and the new features in Exchange 2010 archiving has made me wonder …do I need expensive third party bolts on when I can do so much now with Excahnge, lets do a bit more centrally with personal archives and decrease the weight in our branch office archives and Dis recovery times. Good article
Hi Robert,
Glad to see I’m not the only one thinking along these lines. And yep ditching third party software is something I have been proposing (where it’s the right thing to do) as the savings just on software maintenance or subscriptions can pay towards better infrastructure or just to keep the bosses happy 😀
Steve
Pingback: Tweets that mention Why you should consider using Exchange 2010′s archiving features | Steve Goodman's Tech Blog -- Topsy.com