Hi!

We recently moved all mailboxes from a certain mailbox database to another mailbox database hosted on the same server. The mailboxes show the new database in its properties and everything works fine.

On the old mailbox database, the retention period was reduced to zero, Clean-MailboxDatabase was issued and an offline defragmentation was performed on it to clear all the space on the database and make it completely empty.

However, the case is that the mailbox database is about 10 GB in size at the moment. When we issue Get-Mailbox -Database <DatabaseName>, the result shows nothing. When we issue Get-MailboxStatistics -Database <DatabaseName>, the database shows three mailboxes and huge item counts. The LastLogonTime, although, is empty in the case of the said four mailboxes.

This is the production environment, and we need some guidance on how to proceed with the situation. The mailboxes are fine on the other database, and the users can send and receive emails with no problems whatsoever. But redundant usage of 10 GB is a cost, and we do not want to delete this database since it has dependencies and configurations done on backup applications and stuff.

[PS] C:\Windows\system32>Get-Mailbox -Database "DBNAME"
[PS] C:\Windows\system32>Get-MailboxStatistics -Database "DBNAME"

DisplayName               ItemCount    StorageLimitStatus                                                                     LastLogonTime
-----------               ---------    ------------------                                                                     -------------
SystemMailbox{8cf4f4a7... 19                   BelowLimit
LastName1, FirstName1     24823              IssueWarning
LastName2, FirstName2     75765              IssueWarning
LastName3, FirstName3     51457              IssueWarning

Our environment uses Exchange 2010. Sorry to have posted it in Exchange 2013 Exchange 2010 wasn't listed in the selection box.

• Edited by ram7489 12 hours 20 minutes ago Added a note about the forum selection.

Hmm that is odd for sure....  and from your perspective the DB contains no valid data, i.e. you say the mailboxes are actually on another db correct?

If yes to the above then have you tried dial toning the DB, i.e.

1. Dismount the DB in EMC
2. Then rename or delete the EDB files on disk that are associated with that DB
3. Mount the DB in EMC and it will squawk about the fact that it cannot find the DB files and states it will create new ones
4. Say yes and the NEW DB files are created.
5. Monitor it to see what happens next

NOTE:  The above process is much faster and cleaner than a defragmentation process when you don't care about the data within.  Actually its also good to get a crashed system running again if you have a DB that wont mount and the primary goal is to get email flowing again, i.e. if you had active mailboxes within the DB you simply rename the existing db to OLD_Existing, mount to create a fresh DB and users can then immediately send and receive data.  Then you can fix the other DB and then restore from the repaired EDB OR change it out and then restore from the EDB with fresh data.

COUPLE MORE Things

1. Whats your patch level on the server, i.e. are you all up to date

2. I know that in 2010 early on there were some algorithm issues where exchange would try to optimize the mailbox sizes within the DB and it would go all crazy and expand the database to ridiculous levels however that was early on and I haven't see that arise for some time, however if your not all patched you may want to try that first.

3. If you want to see whats inside that database of question you can take it offline and use our DigiScope product with a DEMO license to peek inside it and see if there is actually any data within

Hi Troy,

Wow, thank you for all this information!

and from your perspective the DB contains no valid data, i.e. you say the mailboxes are actually on another db correct?

Yes, the DB doesn't contain any valid data. I'll try the dial toning process and post the results here.

The above process is much faster and cleaner than a defragmentation process when you don't care about the data within.

Noted. We'll check with our managers and adopt this process going forward.

Actually its also good to get a crashed system running again if you have a DB that wont mount and the primary goal is to get email flowing again.

Wonderful! This is going to come in handy. Thank you!

What's your patch level on the server, i.e. are you all up to date?

Yes, we're up to date when it comes to the patches and SP.

If you want to see whats inside that database of question you can take it offline and use our DigiScope product with a DEMO license to peek inside it and see if there is actually any data within.

We'll try this out if it is approved by our managerswe'd need to go through the approval process since it is the production environment. An alternative is to copy-paste this EDB into one of the test boxes and try to peek in, but let's see.

Once again, thanks a tonne!

• Edited by ram7489 8 hours 53 minutes ago

Happy to assist and FYI while you can safely run DigiScope on an Exchange server you dont have to i.e. you can run it on as little as a 64 bit Windows 7 Machine and dont even need to be connected to the network, i.e. during setup we do a one time pull of Exchange DLL's onto the DigiScope enabled machine and then your all set.

You can literally then take a copy of the OFFLINE EDB load it onto a local drive, disconnect from the network and then open the EDB and you will be able to see everything within.  Once in you Browse, Search, Export data to PST and if your connected to the network you can recover/migrate data directly into a production Exchange server.

Anyway its a super robust tool that do even more then outlined above and you can safely load on any 64 bit supported OS, i.e. Win7, 8, Windows Server 2003, 2003 R2, 2008, 2008R2, 2012, 2012R2 etc...