Can anyone tell me how to regain the 15-20Gb of disk space that I have (apparently) removed from the Exchange Server mail store ? I've archived about 15-20Gb of emails and attachments to a separate off C: location, but this is not being reflected in free & available up disk space. How do I regain the space previously occupied by the greedy users' INBOXs ? I have already tried to re-boot the server - to no avail. Would it help to dismount and remount the mail store ??

Hi, Just to check - are you expecting the Database size to shrink after removing mail items? It won't - it will stay the same size but will create whitespace within the database when maintenance completes. You'll be able to see how much in your event logs. However, if you are talking about whitespace not being reclaimed then are you shortcutting when archiving? There are known issues re: failing to reclaim whitespace if you are using an archiving product and shortcuts, due to block size changes between 2007 and 2010. Disclaimer: The opinions expressed and/or postings on this site are my own personal opinions. They do not represent or reflect the opinions of my employer.

David is correct. You also need to take into consideration the deleted item retetion. For example if you deleted a mailbox and you have keep deleted mailbox for 7 days then it won't reflect in the whitespace. James Chong MCITP | EA | EMA; MCSE | M+, S+ Security+, Project+, ITIL msexchangetips.blogspot.com

Hi, If you can see the whitespace in your mailbox database then you can offline defragment to reduce the physical size of the Exchange database. http://support.microsoft.com/kb/328804Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

I agree offline defrag works, but I don't think it is really that useful in this day and age (especially when we are talking 10-20GB of space) considering the amount of downtime this causes. I think a bigger issue here is the Database appears to be on the C: drive. I'd propose creating a new Database on a different drive, and migrating the user mailboxes across using new-moverequests choosing the option to not finalise the move until it suits the admin. This will 'reduce' the database size (as in the new DB will not have whitespace), have less impact on end users (greatly reduced downtime while the move finalises) and will ensure the database config subscribes to best practice by getting it off the System Drive (I'm assuming the OS is on C: as well). Disclaimer: The opinions expressed and/or postings on this site are my own personal opinions. They do not represent or reflect the opinions of my employer.