This is going to be a short post about Exchange 2013 and Archive Mailboxes.
Most organizations are faced with a plethora of mail storage issues – size limits, retention policies, PSTs management, and storing old mailbox data – which can be a challenge to navigate. Exchange 2010 introduced Archive Mailboxes and seemed to gain a large amount of popularity in Exchange 2013. An archive mailbox is a mailbox which is tied to a user’s existing account and acquires mail from the mailbox older than a certain date (2 years, by default). What this means is that you can very easily with, PowerShell or through the ECP, enable the Archive-Mailbox feature on a user’s mailbox and separate old mail from current mail.
So far this doesn’t sound very impressive. The real selling points, however, are the simplicity of setup, that the archive can be on a different database/DAG, it’s accessible by default in OWA and Outlook, and that they are transparent to the end user.
To highlight how planning, executing, and assessing Archive Mailbox migrations and benefits we’ll look at a sample organization and walk through the process.
In this sample organization there are 4 Exchange 2013 servers, each one hosting the Mailbox and CAS roles. The servers are spread evenly across two geographic sites, each contain two virtualization clusters and two SANs with tiered storage.
The 4 servers are all members of a DAG with 4 databases – one for each server – and each database is sized to 1TB. This means each server would have drives provisioned something like the following:
D: Site1DB1
E: Site1DB2
F: Site2DB1
G: Site2DB2
Storage Summary: 4 servers with 4TB of mailbox databases provisioned. Recovery of a database if all 4 copies fail is a rebuild of up to 1TB of data. This could mean a long wait for users on that database in the event of a recovery!
This setup allows for up to three servers go down and still provide full service from the one remaining. However, as time goes on, you notice – given legal regulations and commands from the corporate on high – a lot of that mail is OLD and and unused. You could try to get the users to clean up their mail but that is unlikely to go smoothly and will either result in nothing happening or in a considerable amount of restore requests over the coming months. Archive mailboxes give us a few benefits in this situation and this is the motivation of the post.
Let’s lay them out clearly:
- Archives help you manage old mail. Instead of storing that old mail in a mailbox database along with recent, important, business critical mail it can be stored in a different database. This means faster restores, less downtime, and greater control of old mail.
- Optimize your storage usage. Instead of storing all of your email on that pricey new SAN and have 4 copies of it as described above. Create an archive database or two on that older SAN or slower storage and maybe only have two copies available. This way, you can still sustain outages and have redundancies but if there is a major issue you can restore the urgent mail data and databases right away and save the old data in the archive databases for later!
- NO MORE PSTS. Most likely there are PSTs on shares, on local machines, in weird backups, and generally all over the place. They are a pain to manage and they get corrupted. Once an archive mailbox is set up, you can simply import PSTs in to them. There, now they’re back on a server, getting backed up as needed, unlikely to get corrupted, unlikely to get lost. Pretty nice, right?
- It’s easy.
So, let’s go over how to set this up!
First, let’s look at managing our storage.
Assume we have, at each site, an older SAN array with 5TB of usable protected space on mid-tier SATA drives and a newer SAN array with 10TB of space with some of that being in SSDs, High-Speed disks, and lower-speed disks. It would likely be a waste to include old mail on new, fast storage – especially if using something like automatically tier-ing active blocks. Additionally, it is likely you could convince management that data older than say 2 or 3 years shouldn’t require as many highly available copies. Let’s say they agree to having 4 copies of the active databases with data that is newer than 2 years and everything older only needs two database copies.
This is where things start to get cool. First, we’ll create 2 new LUNs on each of the old storage arrays, each sized at 2TB. We’ll then create 2 new databases in our DAG – Site1Archive1 and Site2Archive1. We’ve now created the two required copies for our archive and can start setting them up!
Go to the ECP, select a user you want to put in an archive mailbox, go to the right column, and select to enable In-Place Archive as seen below:
While enabling, select the new archive databases we just created and that’s it.
The user will now see a new archive mailbox in Outlook or OWA and over time their messages will flow in to that mailbox! Even better, you can start to import all of those PSTs back in to the users mailbox and have it automatically migrate the appropriate data to the archive!
Overall, archive mailboxes are pretty cool Exchange objects which can provide a lot of benefits if time is spent deciding how best to implement them. In addition to the method mentioned above you can use PowerShell:
Enable-Mailbox Username -Archive -ArchiveDatabase AchiveDatabaseName
You could obviously create a set of users from a file in variable and then loop those users in to an archive database or even alternate the databases.
Take some time to consider if archive mailboxes are a good choice for your organization! Leave any questions or feedback in the comments below.