I've inherited a server that's in a pretty bad way (ridiculously large mailboxes for a start) - but am relatively new to Server 2007. The database is 129gb on a 136gb drive. I've used the Exchange Management Shell to find out who have got the biggest mailboxes and archived the first 2 to a pst - as well as deleted 2 users that no longer work here. Did all that without any problem, should have freed up at least 30gb - but the database is still 129gb. Am I missing something out here? (I did this over 2 weeks ago, because I was wondering if it was a time issue, too) I'm sure it's a relatively easy one to sort out - but can't seem to find what it is Thanks in advance, Karn

Hi The actual physical database wont be reduced. To reduce the database you have to perform an offline defrag or set a newmailbox database, move the users to it and delete the old one. http://support.microsoft.com/kb/328804 Sukh

Excellent - thank you very much

I see several problems with this approach: 1. You just took data out of managed storage (gets backed up regularly, relatively easy for legal discovery, some assurance the data is not corrupt, etc) on the exchange server and moved it to unmanaged storage in PST files (scattered about, no way to verify backup status or file integrity). 2. Removing mail items from mailboxes within an exchange database does not reduce the size of the database. For that matter, it may or may not increase the amount of free space inside database. Let's say Bob, Susan, and I have mailboxes on the same store. I compose a message, then send it to Bob and Susan. There are now three "copies" of the message in the store; one in my sent items, one in Bob's inbox, and one in Susan's inbox. In reality, there is only one copy (you stated Exchange 2007) with three pointers pointing to it. If I delete all my sent items, and Susan deletes the mail from her inbox, but Bob didn't because he was on vacation, then after the deleted items retention period expires and online maintenance completes a pass absolutley no space is saved; all we did was remove two out of three pointers to the same item. Now that brings up another point. Even for items with only one instance, when you delete them they are simply marked and reteaned for a period defined by your deleted items retention. Once the deleted items retention expires, you still have to wait for the next pass of online maintenance to complete. If any of the items that mave been marked have no references to them when online maintenance runs after the expiration of the deleted items retention period, then the pages occupied by the item are marked as free. The sum of the space occupied by pages marked as free inside a database is ascully logged in the application log at the completion of online maintanence (the online defrag that occurs during online maintenance that is) as an event ID 1221 in the application log. 3. Even after removing mail and waiting for deleted items retention expiration/online maintenance completion, the physical size of the database file is not reduced; you simply have more free pages within the database. This is the point where you may toy with the idea of an offline defrag to reduce the size of the database file. Before you proceed, you may want to consider a few things. First, the offline defrag process reads pages that contain data, and writes them to a temporary file, and updates brand new primary indexes (cause the pages have new page numbers). Once it completes a pass, the process deletes the original database and then renames the temporary database to the name of the original. This means you're going to need some space. Microsoft recommends space equal to 110% of the size of the orininal database. Once past the space issue, remember that this is a brand new database; that means all your previous backups are invalid. Your woes only begin here. Although primary indexes were rebuilt, all your seconday indexes are gone. You will incur a perfomance hit while exchange rebuilds them during the normal course of operations. Yes, offline does mean just that; you will incur an outage for the duration of the offline defrag (hours long). In the end, if you do not impose space limits or otherwise control the growth of your DB, it will all be for naught; the database will simply grow again. Unless you are permanantly removing a large amount of email (say half the employees in your organization have permanently left), it's pointless to do an offline defrag. The official word is here: http://technet.microsoft.com/en-us/library/aa997972(EXCHG.80).aspx 4. There is another alternative. If you have another mailbox server in your organization, or another drive in your existing exchange server, simply create a new blank database and move all or some subset of the mailboxes to it. J

As John says check for event ID 1221 to see how much free space Exchange thinks is within the database. 2 things to note though. 1. Because of single instance storage even if you remove what you think is GB's of data very little white space may be created - look for the Single Instance Storage ratio counter for the database in performance monitor to get an idea of how efficient Exchange is being. 2. Make sure your online maintenance is actually running, check the properties of the database to see, and that its window ISN'T within your backup window. Also the online defrag only runs for about an hour at the end of the online maintenance so it can take several nights for a full online defrag cycle to complete depending on how much Exchange thinks you have removed. It's a bit of a black art really. Neill