Home » Exchange Server » Should You Defrag Exchange Server Mailbox Databases?

Should You Defrag Exchange Server Mailbox Databases?

In a recent article I demonstrated how to defrag an Exchange 2010 mailbox database. Since publishing that post a discussion has been ongoing in the comments about some of the pros and cons of defragging databases, as well as the implications for databases in an Exchange 2010 DAG (because my article specifically said not to follow the instructions for DAGs).

So, first things first…

Should Database Defragmentation be Regular Maintenance?

For the answer to that question I’m going to refer to the most authoritative source on Exchange Server – Scott Schnoll, Principal Technical Writer at Microsoft.

What was I doing when he tweeted that to me? I was defragging some mailbox databases 😀

But was I doing that as part of regular maintenance? No I wasn’t, and neither should you 🙂  In my case I was defragging some databases in a site where we have more than 200 mailbox databases. If I defragged 3-4 of those per week each database would still only get defragged once a year.

Of course I’d prefer that I never had to defrag them at all. For one thing it means working on a Friday night. Regular defrags would also probably suggest we’re not managing our capacity properly.  But there are other reasons not to as well.

Reasons Not to Defrag Mailbox Databases

So why shouldn’t you defrag a mailbox database? Well let’s consider what is involved in a defrag.

First the database is dismounted. Then the offline defrag occurs, which in effect writes a brand new database file of the data within the database, excluding the white space. Then the database is remounted again and, ideally, a backup is taken immediately.

So you can already see three pretty good reasons not to defrag databases.

  • It requires an outage (at best this is an inconvenience for the business, at worst it may impact SLAs)
  • There is the risk of corruption as the new database file is written
  • It complicates your backup/recovery scenarios for periods before and after the defrag

Reasons to Defrag Mailbox Databases

But despite those reasons sometimes we have to be realistic about these things, and a defrag is necessary. Often in my case there are considerations such as:

  • No additional storage available to create a new database to migrate the mailboxes to (or only available at significant cost)
  • Migrations would take several days of minor outages for groups of users, instead of one single outage for all users on that database
  • There are active alerts for low free space on the storage for that database that need to be cleared

So in some cases a defrag is the best (or only) course of action.

What about Exchange Server 2010 DAGs?

So why did I say in my previous article not to follow that procedure for mailbox databases on servers in a DAG?

The main reason is that it breaks the resilience of the DAG for that mailbox database. When you defrag a mailbox database you also then need to reseed it to all of the other mailbox servers that host a copy of that database. So for that period of time between the database being defragged, and the reseed completing, your database is not protected by the continuous replication of the DAG.

The second reason is that moving mailboxes within an Exchange 2010 environment can be performed almost as a no-outage scenario for the end user. In previous versions of Exchange Server if you moved mailboxes instead of defragging databases the end users still experience an outage either way. However in Exchange Server 2010 the client experience is much better thanks to online mailbox moves.

One commenter actually contacted Microsoft Support to see if there was a way to run the defrags on passive mailbox database copies. To my surprise Microsoft actually did have a process for this, but as you can see it is quite complex and in my opinion is more effort and risk than it is really worth.

What do you think?

What do you think about defragging mailbox databases? Is it something you do regularly? Or do you avoid it in favour of other methods of achieving the same outcome?

Leave a comment below with your thoughts.

Update – two good discussions going on about this in the Exchange Server Pros and MSExchange.org groups on LinkedIn.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Turbomcp says:

    first of all nice article
    second, part of my design to migrate around 40,000 users dag and the whole thing is to “leave” one lun or two “spare” if i can(if i have enough disks after reconfiguring the storage to raid 5 instead of raid 10) so that i can always move mailbox(whole stores) online and get rid of any major white spaces.
    these might happen since we have specific situation here were some group of users are always moved in and out of dedicated stores that are the only one with multiple site recoveries capabilities.
    since databases are bigger then before i dont think defrag is the way to go anymore.
    (but maybe its just me:))

  2. Kevin DaCosta says:

    Hi Paul,

    I have the TrainSignal Exchange 2010 on order and wondering would you suggest I also get any reading material and if so what would be the books names? I have been out of the MS Exchange world since 2003 and really didn’t didn’t do much besides basic administrator and I am now looking to rehone my skills.

    Kind Regards,


  3. BillS says:

    I totally agree with you, defraging a database is sometimes risky, i had a very bad experience in past where my server got rebooted during the defrag process and the DB got corrupted, god knows how. And, the worst part was the backups were not current, the company had 2 months old backup. The local IT guy didn’t know that the backups are failing since last two months. Ultimately we have to convert OST’s to PST’s and mount a blank database. We had to import those PST’s back. It was doable because total number of users was only 40.

  4. Kate says:

    Quick question:

    I have a database which is 1 TB in size (yes, really – inherited this environment). I have built new databases, and begun the process of taking these HUGE databases, moving all mailboxes off each one and redistributing them amongs these multiple new smaller databases. I have moved ALL but one user off the current database I’m working on, and am ready to reclaim 1TB of space and move on to the next one. HOWEVER, the one mailbox left on the database will NOT move. It hangs at 10% – I’ve even left the move request running overnight. It shows no corrupted items in the move process, and no good info in the event logs. Resarch online seems to indicate that there is simply some corruption preventing the mailbox from being moved, and the only way it seems this can be fixed is to export everything out and then import it back in to a new mailbox. I have run a mailbox repair and a database repair, and still no joy – if there’s corruption, it’s invisible corruption that doesn’t show up anywhere. That being said, I am debating on performing an offline defrag to reclaim the space, and just leave this fool mailbox where it is.

    My question, now, is do I need over 1TB of space in order to do a defrag, when the single mailbox left on it (affecting the resultant database size) is only 2GB? I know in previous versions of exchange you needed 100%+ of the size of the database free someplace in order to do an offline defrag, and I am pretty sure there is not 1TB of space available anywhere for me to use for an offline defrag, even though I’d just be temporarily using it during the defrag process.

    Thoughts? Anyone dealt with similar situation before, and if so what did you do to resolve (if not offline defrag). Any help would be appreciated.. Thanks!!

  5. Carol Ostos says:

    Relevant to this topic (defrag or not defrag?), I noticed event ID 629 on our mailbox servers and the first thing that most people suggested after a quick google search,

    Possible Cause: either a HW issue or a SW issue (third party plugin, etc), I thought could be SW since we have outlook plugins like CRM.

    Possible Fix: increase the maintenance window, offline defrag, move mailboxes, delete DB and create a new one.

    Here’s the event

    Log Name: Application
    Source: ESE
    Date: 2/16/2014 6:42:09 PM
    Event ID: 629
    Task Category: Performance
    Level: Warning
    Keywords: Classic
    User: N/A
    Computer: mailbox server 1
    Information Store (5560) DB2: Database ‘G:DB2DB2.edb’: While attempting to move to the next or previous node in a B-Tree, the database engine skipped over 16121 non-visible nodes in 51 pages. In addition, since this message was last reported 3 hours ago, 0 other incidents of excessive non-visible nodes were encountered (a total of 0 nodes in 0 pages were skipped) during navigation in this B-Tree. It is likely that these non-visible nodes are nodes which have been marked for deletion but which are yet to be purged. The database may benefit from widening the online maintenance window during off-peak hours in order to purge such nodes and reclaim their space. If this message persists, offline defragmentation may be run to remove all nodes which have been marked for deletion but have yet to be purged from the database.
    Name: MSysObjects
    Owning Table: MSysObjects
    ObjectId: 2
    PgnoRoot: 4
    Type: 2
    Unversioned Deletes: 16121
    Uncommitted Deletes: 0
    Committed Deletes: 0
    Non-Visible Inserts: 0

    Has anyone seen this before? Any words of wisdom would be highly appreciated!

    Thanks as always!!!

    • “…offline defrag, move mailboxes, delete DB and create a new one.”

      Kind of pointless to defrag if you’re then going to move the mailboxes and delete the DB 🙂

      You could try an ISInteg to fix the DB but if you’ve got the storage available then I’d just move the mailboxes to a new DB and delete the suspect one (since ISInteg requires an outage etc)

      • Carol Ostos says:

        Thanks for the quick response.

        My bad, I meant to say either offline defrag or move mailboxes, delete and create new DB 😉

        In the end decided to delete and create a new DB, so far so event 628 or 629. Have not moved any mailboxes yet but will do slowly (in batches). I have also decided to update CRM outlook plugin for our CRM users (still deciding between RU 15 and RU 16, for MS CRM 2011).

        Hope that makes these events go away, fingers crossed!

  6. Showkat Mir says:

    First of all best wishes from India and thank you very much Paul sir, for sharing these great articles, i am a beginner to Microsoft Exchange Technollogy and initially i found it very difficult, however, since i have been following you and going through your articles, it seems easy to me and i am very much confortable with it now,

    i will hightly apprecaite sir, if you can suggest me few tips, as i have recently started my career and want grow with this Technology.

    Thanks and regards
    Showkat Mir

  7. Rosario says:

    I do not recall if I ever did it with Exchange 5.5, but I might have done it with EX2003 and/or EX2007. I guess I did prefer moving the mailboxes to a new DB. In EX 5.5 days we had been badly attacked through the default MS-ftp service running and poorly protected on windows servers – ok in 2001 I was completely new to Exchange servers and I took over from a collegue who had left – so I was not even aware that this service was running on most of our windows servers. So I rebuilt most of the windows servers from scratch and amongst them three Exchange 5.5 servers spread across 3 remote sites and connected through a dedicated line (modems in those days). I installed a fresh server, adding it to the existing Exchange Organisation, created new DBs on it and moved all mailboxes on it. Then I removed the three hacked servers from the EX Organisation, built them up from scratch and redistributed the mailboxes on them. If I am not mistaken, to avoid moving the mailboxes over the slow lines, I moved to the remote sites with my new Exchange server to do it on the local lan or vice-versa, moved the remote servers into my office to do it over a week-end down-time. I do not recall exactly whether I really moved the mailboxes or whether I simply restored all DBs to my fresh server from Tape or every DB to its rebuilt server. But either technique is good in disaster recovery scenarios.

    I remember also having repaired a DB once or twice with 5.5 and probably also with 2003. But again, the down-time might not be worth the work, as you are quicker creating new DBs and moving the mailboxes over on them.

    With EX07 I moved mailboxes and then deleted and recreated the DB with the same name. I do not remember if I took the effort of moving back the mailboxes. Probably not, as we had to do it because we might have suspected a corruption in it preventing Free/Busy Times from being updated correctly. So we probably used the new DB with its original filename and location on disk to create new mailboxes on it.

    In another case, still with EX07, we had reached the available space on disk. So we had to move the mailboxes onto a new DB on a bigger SAN-Disk. But as the DB Disk was roughly 100 GB and the LOG-Disk only 20 GB, we hardly experienced that Exchange was doing its job very well, Transaction-logging every data move including the data moved into its log-files! So the Log-Disk filled up with the first 20 mailboxes moved or so. Hence we had to move about 15 mailboxes per night, then wait for the Backup-Task to finish and purge the transaction logs and start over next night with another 15 mailboxes.

    Ok, we learned by doing, as the installation was made by a specialized Exchange-Firm, we blindly trusted them, and I never had noticed that moving mailboxes would make the transaction logs grow. Maybe this had changed from earlier EX versions or my Log-Disks were always big enough then. But in those days SAN-Disks began to become more comfortable, so that you could enlarge and grow up your disks dynamically without down-time. So this is really what is becoming the real reason why you do not have to defrag your DBs any more. They are re-fragmented anyway if you have high activity as we do with roughly 20’000 Mailboxes.

    With EX2010 finally, we are experiencing another fancy case: moved mailboxes to a new DB, deleted the old one, and BINGO: our HP Data Protector Granular Recovery Extension reports an error and stops, saying the original Database is no longer in the Exchange Topology!

    So again, be careful with those operations. For the moment being, I do not know whether I can simply create a new DB with the deleted one’s file name or whether the DBs get unique IDs in the Active Directory and could hence be restored only through a major restore of the whole Exchange and AD at a given point in time. But as more than a day has already passed, a major restore is not acceptable any more. We must find a solution to restore the deleted DBs in case one of our users makes a request to do so. If anyone knows whether we can apply the same trick which worked with EX07, recreating the DB with the same filename, let me know.


  8. Chris says:

    So I run the defrage on my test environment and closes the powershell before the process ended. How do I get the status bar back? Is there a command to show me the %% of the running defrag?


  9. Gabriele Massari says:

    I have a 270 GB mbx database, with 257 GB whitespace in it, which is hosted in a DAG member but not replicated. The DB hosts only disconnected mailboxes that cannot be deleted due to compliance reasons for the next 2 years.
    If I understand correctly, defragmenting this DB will not affect the resilience of any other DB copy on the server, can you confirm that please?

    Kind Regards,

  10. TONNY says:

    Hi Paul ‘ve seen enough feedback on scenarios EX 2010 about DAG in Exchange 2013 works like ?

    Now in my environment I have EX 2013 DAG 9 BD which together account for 524GB and running a powershell command to see how much space would be my gain after defragmenting said to be 23 GB. what do you recommend me…

  11. Jack says:

    Greetings Paul,

    I have an Exchange 2013 environment and I am trying to keep the DBs at a standard 400GB size. I have about 30 DBs right now and I do have the space to create more DBs and/or increase the size of each DB. It is my personal preference not to have DBs larger than 400GB for recovery or reseeding purposes. We also have alerts that let me know (and my boss and his boss) when we get below 10 percent in drive space. I have a couple of DBs that are below that now – I’ve moved mailboxes and have whitespace – but that doesn’t get rid of the alerts. I could change my standard to 450GB – but that would probably lead to 500GB and so on.

    We have maintenance weekends and I could take the outage to do a defrag and reclaim the space. What would be your advice? I understand it is personal choice – but the advice of an expert would be appreciated.



    • Yves LeBouthillier says:

      I’d suggest to maintain your 400GB standard and simply create a new DB with DB copies and use that one up until you reach 400GB again.

Leave a Reply

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