As many of you are well aware through recent Microsoft Blog postings, the Connect forum and the Symantec KB Article 16949 there is an issue with space not being reclaimed by the Exchange 2010 store when objects are deleted or truncated. This impacts many scenarios some of which are prevalent when archiving.
Before we get into too much detail here's the good news - Microsoft have fixed this issue and it's available on request. For the fix go to http://support.microsoft.com/kb/2621266 .
This is an interim update (IU) and will hopefully be made available in an upcoming Rollup Update (RU) for Exchange Server 2010 SP2. There are something's to note for the fix, once installed it won't magically reclaim all space, there are undefined deletion thresholds that have to been passed before the online defrag attempts to reclaim the space. So don't install the IU and immediately expect to see the space reclaimed, apply the fix and over a number of days the available space should start to grow (see what to do next later for alternatives).
So the question you all want to ask...what space do I get back?
Well that depends on a number of parameters and what portions of Enterprise Vault functionality that you are using.
Let's first look at Journaling...
Where an Exchange 2010 SP1 database is hosting a journal mailbox being processed by Enterprise Vault the EDB (Exchange database) file continued to grow. This is because in some circumstances the object being deleted was never cleaned up by the Exchange store. This has been fixed and the space of the deleted item (whitespace) will be made available for re-use. Therefore once Enterprise Vault removes the item from the store it will shortly be available for re-use again and new mail arriving.
Now mailbox archiving...
This isn't so clear cut as journaling as there are a number of considerations:
- Shortcut policy settings
- Size of email messages
- Number of messages containing attachments
The Exchange fix will reclaim all the space an attachment was consuming when removed during shortcut creation. However, the amount of space reclaimed during shortcut creation depends on the size of the item and the shortcut policy settings.
In testing the amount of database space reclaimed for average sized messages (75kb) is 46%. This is based on a shortcut creation policy including the banner, link to archived item and keeping 1000 characters from the body.
- For example, archiving 10,000 average sized messages reclaimed 321.26MB in the database and the mailbox statistics showed a reduction in mailbox size of 692.82MB.
- Importantly the database file did not grow during the archiving process. For comparison without the fix installed the same test grew the database file by 128MB.
In testing the amount of space reclaimed for average sized messages with attachments (75kb message plus one 150kb attachment) is 83%. This is based on a shortcut creation policy including the banner, link to archived item, links to attachments and keeping 1000 characters from the body.
- For example, archiving 10,000 average sized messages with attachments reclaimed 1.74GB in the database and the mailbox statistics showed a reduction in mailbox size of 2.1GB.
- Again as with the previous test the database file did not grow and remained the same size. For comparison without the fix installed the database file remained the same size but consumed 79MB of the originally available 118MB space leaving only 39MB free.
What to do next?
1. Go and request the IU from Microsoft.
2. Install the IU on your Exchange servers hosting the MBX role.
3. Consider creating new mailbox databases to host journaling and user mailboxes. Why do this? Well the existing work around was to move mailboxes periodically to a new database. Doing this one last time means that you start from a clean DB with the working fix. You can then delete the old DBs and get back the maximum amount of disk space.
4. Continue to monitor the available new mailbox space (get-mailboxdatabase -status | ft Name, AvailableNewMailboxSpace)
5. Check and revise your shortcut deletion strategy to potentially recover further space.