1

I moved ~50.000 emails from the Sent Folder to several .pst files [split by year] and the size of the Sent Folder was then indeed reduced by ~36GB [This is what I see in Outlook when I right click it and check the size - before and after I moved the emails].

Then I ran eseutil /d DatabaseName.edb /p /tNewDatabase.edb.

I expected the size of NewDatabase.edb to be smaller by at least 36GB but it were only 4GB. The current DatabaseName.edb has around 88GB and then it had 84GB.

What am I doing wrong?

Peter VARGA
  • 332
  • 1
  • 2
  • 15

2 Answers2

2

This is most likely due to retention.

For each database there's 2 parameters related to deletion : 

Keep deleted items for

and 

Keep deleted mailboxes for

Obviously the first one concern items within a mailbox while the second on concern mailboxes themselves.

enter image description here

If those parameters are not set to "O" then the item will not be marked in the database as deleted (and the space marked as "free") and so those records will still be copied in the new database by the eseutil /d

Note that event with a value of 0, you have to wait for the database purging / pruning process to occur to mark the records as deleted.

JFL
  • 2,006
  • 1
  • 11
  • 16
  • Ok, so `moving` emails from a folder is internal considered as `delete` and therefore the "`moved`" emails still remained in the "Deleted container"? This sounds very logical to me. I have 30 days. Either, I set it to 0 and the next weekend [when I can shutdown the database] the size should be really reduced or I wait this period - as you suggested. Did I get it? – Peter VARGA Mar 30 '16 at 12:16
  • Yes, when a user "delete" an item it is moved in the dumpster area and it's still recoverable by the user (with Outlook, there's a registry key that allow it) or by an admin with powershell. Regarding the choice between waiting 30 days or setting the retention to 0, it depends on your company policy about email retention and you backup scheme / retention. In all case, perform a full backup prior to do anything. – JFL Mar 30 '16 at 12:27
  • But is `moving` and item from the `Sent Folder` the same like `deleting` it. This is not clear to me. I did not actually `delete` anything. I only `moved` the items. – Peter VARGA Mar 30 '16 at 12:29
  • Moving an item to a pst does "delete" it from the user point of vue, but it's a "soft delete". For the mailbox, the result is exactly the same as putting the item in the trash and empty the trash. From the technical point of vue, the item is actually moved to the dumpster folder, where it can still be retrieved. During database maintenance, the system compare the age of items in the dumpster vs the retention limit. If retention limit is over, the item is then removed from the dumpster and the space in the db marked as free. I.E. "hard delete" – JFL Mar 30 '16 at 12:38
  • Perfect. According to your statement "_Note that even with a value of 0, you have to wait for the database purging / pruning process to occur to mark the records as deleted._". I changed **now** the value from `30` to `0`. Is the `purging process` going to be executed before this weekend in order the space is definitely marked as free or how can I check/initiate the process? – Peter VARGA Mar 30 '16 at 12:43
  • Not quite sure about this point. A "Get-MailboxDatabase -Status | FL AvailableNewMailboxSpace" should give you a hint. Note that my answer was aimed to explain why the size did not reduce. It does not imply that it's the best thing to do. [Grant](http://serverfault.com/users/108667/grant) is right in that the best way (I.E. Microsoft recommendation) is to create a new db and move mailboxes to it. See [this article](http://blogs.technet.com/b/exchange/archive/2011/12/14/database-maintenance-in-exchange-2010.aspx) for more info. – JFL Mar 30 '16 at 12:54
  • I accepted your answer. Now the database is ~22 GB smaller - there are still ~18GB _missing_ but I will try to defrag the database next weekend. May be something has not been deleted permanently. "Grant" did not reply and due to lack of knowledge I did the "easier" part... – Peter VARGA Apr 03 '16 at 07:30
1

Exchange will keep that blank space around for future data.

If you want to reduce the file size the best way is to create a new mailbox database and move all the mailboxes to it. This new database will be just a bit larger than your actual data size.

With Exchange 2010 that can be done completely online, so no downtime is required.

Grant
  • 17,671
  • 14
  • 69
  • 101
  • a "eseutil /d" actually create a blank database and copy all active records from the current database to the new one, then swap them. There's no blank space in the new database after this process. – JFL Mar 30 '16 at 12:11
  • @JFL ah, I've always done all exchange 2010 maintenance with powershell. – Grant Mar 30 '16 at 13:01
  • Is the way what `JFL` suggested a solution for me? I "stopped" the corporation with my Exchange Administrator and I don't have really any experience with Exchange. The `defrag` method seems to me as the easier part as I don't know how to move all the mailboxes to the new database. Do you have a link? Due the fact my current storage does not have enough space I would have to create the new database on another drive and then move it in the Exchange console... – Peter VARGA Mar 30 '16 at 13:06