Exchange 2007 keeps dismounting database daily.

Have an exchange 2007 server? Tired of coming in every day to calls from users that at some point over the night the server has dismounted the database? Then I have the solution for you!

Problem: Exchange Server 2007 will unmount a specific database on a regular basis forcing me to have to remount the database manually. This is due to the database growing to large.

How to confirm this is your problem: I would start by looking in the event log for errors like the following:

Event ID: 1216 
Source: MSExchangeIS Mailbox
The Exchange store ‘some custom group\some name‘ is limited to 250 GB. The current physical size of this database (the .edb file) is 256 GB. If the physical size of this database minus its logical free space exceeds the limit of 250 GB, the database will be dismounted on a regular basis.

This is a good indication that your DB is full. Good news is there is a fix.

Solution: First we need to learn about how Exchange frees up space in a DB this is important.

Odds are the DB wont dismount again until the daily cleanup run. The schedule for this is located in EMC \ Server Configuration \ Mailbox \ Datastore Name \ Database Name \ Properties 

001

Now we have a good idea that during the next online defrag it might dismount again this is generally when it happens. We have established a rough idea on how long we have until we might experience the problem again. Exchange will never shrink the raw file that is has created. If you hit the 256GB default size than you will always have a 256GB DB file unless you run an offline defrag using ESUIL, this creates downtime for the datastore and will take hours to complete.

So how can you reduce the size of the mail in the DB so tomorrow you can enjoy your cup of caffeine in peace? The fastest and often best answer is to move mailboxes out and spread the data across all the datastores. We now need to find out how large the databases are, and how much white space is in them. Looking at the raw files is not a good estimate as I mentioned exchange will not shrink the raw file, just the free space in in.

Open up the EMS and drop in the code that I found online. If your worried about it messing up exchange then I suggest you look up what the command is doing or take a course on powershell. Same rules applies here inspect code before running it on a production machine.

Get-MailboxDatabase | Select Server, StorageGroupName, Name, @{Name=”Size (GB)”;Expression={$objitem = (Get-MailboxDatabase $_.Identity); $path = “`\`\” + $objitem.server + “`\” + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + “$”+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1048576KB; [math]::round($size, 2)}}, @{Name=”Size (MB)”;Expression={$objitem = (Get-MailboxDatabase $_.Identity); $path = “`\`\” + $objitem.server + “`\” + $objItem.EdbFilePath.DriveName.Remove(1).ToString() + “$”+ $objItem.EdbFilePath.PathName.Remove(0,2); $size = ((Get-ChildItem $path).length)/1024KB; [math]::round($size, 2)}}, @{Name=”No. Of Mbx”;expression={(Get-Mailbox -Database $_.Identity | Measure-Object).Count}} | Format-table -AutoSize

The ouput can be seen below:

003

Ah perfect we have some room in my other databses that I can use. I can also another one of my DB’s is getting really close to the 256GB default limit so Ill need to keep and eye on it.

Now when you migrate a mailbox is is down until you finish moving it. From my experience it can take a while to move a lot of mailboxes at once. If you cancel the move of a single mailbox it will take the time elapsed divided by 3 to cancel the task. My guess is to revert the changes. This is just from past experience so don’t start and expect cancel to stop that second if users complain.

We should find out what mailbox are excessively large so we move them out. Based on your needs you might want to move 50 small mailboxes of users who are not working as apposed to the CFOs mailbox that is 30GB in size, save that for the weekend.

To output the list of users and sort by size put in the following command into the EMS,

Get-MailboxDatabase “Name of the storage group” | Get-MailboxStatistics | Sort totalitemsize -desc | ft displayname, totalitemsize

004

Here hopefully you can identify some large mailboxes not in use that you can start moving right away. To move mailboxes head on over to the EMC and choose Recipient Configuration \ Mailbox \ Select the specified mailbox \ Move Mailbox…

005

Now this will move the mail to the new DB. Were not done yet, the database still needs to free up the room after a move. This is done by the scheduler we already looked at earlier. I would modify the schedule to have a longer run time say when work stops until tomorrow morning. Make sure it does not overlap with another databases online defrag.

006

Hopefully tomorrow you will not have to mount the Database again and to prove that you freed up some room open the event viewer. Head to application logs and filter by ID 1221.

Here I can see last week I was freeing up next to nothing on this DB.
007
However the combination of moving mailboxes out, and extending the run time has freed up over 27GB of data compared to the 44MB I had freed up the night before.
008

Wait! Were not done yet. How can I stop worrying about database sizes and get back to enjoying weekends without mailbox migrations?

When I was looking into this issue I noticed some inconstancies with exchanges functions compared to its licensing model. I came across this article: https://technet.microsoft.com/en-us/library/bb232092(v=exchg.80).aspx?ppud=4  where they state that the max size should be 16TB however it has to be manually set via the registry.

To be clear I have not gone ahead and done this yet seeing as everything is now working but once I get a database down to zero mailboxes in the next month or two then I plan on applying this registry edit to that single empty database and playing with it to verify Microsoft’s guide everything thing mentioned above this line has been tested and implemented into active production. Here is how it is done for my and your reference, Ill post if the following has been successful.

See below from technet on clarification on Exchange DB sizes.

1. The default DB size limit in Exchange 2007 (all service packs) is 250GB
2. The limit is in place however can be lifted via the registry
3. The reg key is the only way I know of to change the limit
4. The application log already issues warnings if you are getting close to the limit

First we need to find out if someone has already set the key and if not where we will set the key. Open regedit and head into:

HKEY_LOCAL_MACHINE\SYSTEM\CURRENTCONTROLSET\SERVICES\MSEXCHANGEIS\

009

Here you will see the name of your mail server expand this and you are presented with a list of private GUID’s like such:

I can see there are more entries than DB’s so head on back to EMS to get the corresponding GUIDs for the DB we want to test this on. Type in:

Get-MailboxDatabase | Format-Table Name, GUID

010

Here you can see the GUID’s match well I am telling you they match you will have to use you imagination since its blurred out.

Now that we know the GUID for the database we want to bypass the 256GB limit on we need to add a new REG_DWORD called: Database Size Limit in GB

For the value enter in GB. More details on the key can be found here despite it mentioning it was for server 2003 it was part of the previously linked MS guide.

 

 

 

 

 

 

1 thought on “Exchange 2007 keeps dismounting database daily.”

Leave a Reply

Your email address will not be published. Required fields are marked *