Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I have spent a few hours figuring out how to delete messages from a mailbox in a particular date range in Exchange 2010. Still I wasn't able to find out a correct PowerShell script to do it.

So I dropped all the messages with the cmdlet Get-Mailbox | Search-Mailbox -DeleteContent.

Although 5GB should have been deleted (Statistics show that the required mailboxes are now empty), it didn't free up space on a hard drive that contains my Exchange Database.

Is there any SQL-like stuff I need to do, to "Commit" the delete transaction?

share|improve this question

2 Answers 2

up vote 3 down vote accepted

What you're looking for is an offline defrag. The command eseutil /d will get you what you need. See the linked Microsoft KB.

Please note that when doing this, you want to put your temporary database on a different partition that has the same amount of free space that your current exchange DB has.

share|improve this answer
    
I am not limited to having the Exchange operational for the time of the defrag, so I can go ahead and don't bother about the temp database. Thanks for the tip! –  Maxim V. Pavlov Jul 27 '11 at 17:58

To answer your actual question, Nixphoe has the correct answer with the offline defrag. As a warning though, all mailboxes in the database you are defragging will be offline for the duration of the defrag (which can be an obscene of hours).

If however you're seriously considering doing a major operation like an offline defrag to reclaim a lousy 5GB of disk space, you need to upgrade your storage as a matter of great urgency (bad things happen to Exchange when the disks fill up).

If you're really intent on doing this, a better and easier alternative is to create a new mailbox database and move your mailboxes from the old database to this new one. This also has the very attractive benefit of only taking the mailboxes offline that are currently in transit and means considerably less downtime for your users than an offline defrag. The caveat of this method though is that you need enough storage space to hold the existing database as well as the new one while you move mailboxes between the two.

The reason your .edb file (the actual Exchange database) didn't get any smaller is a performance feature of Exchange and unless you have a really good reason to, I'd never recommend you do an offline defrag on a production database. With respect, you asking this question means you don't understand why the ESE database engine works this way, and as such probably don't have a good reason to do an offline defrag.

share|improve this answer
    
As evidenced by his comment about the temp db –  Holocryptic Jul 29 '11 at 21:48

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.