Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

(this post is a bit lengthy, so advTHANKSance for those who who stick with it to the end)

I have a client whose SBS 2003 server suddenly started crashing every night. The symptoms of the crash itself were weird. Generally the system would just freeze. I could still see the Windows interface on the screen, but the system itself was unresponsive to mouse and keyboard actions. Eventually I'd have to hard-boot the server in order to get it operating again (ugly).

After reviewing the system logs I noticed that the crashes were happening shortly after the online maintenance processes on system's Exchange the Private Store had begun. The online maintenance was scheduled to occur every night during off-hours. I believe it was set for 1am-4am.

Since the online maintenance processes were a precursor to a crash, I disabled them all-together until I could figure out the true underlying cause of the problem. For instance, I wanted to make certain that the problem wasn't related to faulty hardware.

A couple of weeks passed after disabling online maintenance and the server ran just fine, but I noted that the Exchange Store size was growing faster than usual. I chalked this up to the fact that things like online defragmentation weren't happening. I knew I'd need to eventually get the online maintenance tasks running again, but I couldn't schedule them to start on a weekday night because the server was required for production tasks first-thing every weekday morning.

One hunch I had about the crashes is that the online maintenance processes were butting heads with other scheduled tasks that were happening at about the same time (eg, VSS processes, backups, etc).

In order to test that hunch I set the online maintenance of the Private Store to occur during the wee hours Sunday morning and made certain that no other scheduled tasks were slated for the same period.

I fell asleep Saturday night fully expecting to wake up and find that the server had crashed by the time I woke Sunday morning. To my relief, it hadn't crashed. I checked the system logs and noted that the online maintenance processes had completed successfully.

So as it stands, I'm inclined to allow the online maintenance processes for the Exchange database on this particular server to run weekly (every Sunday morning) for a while. This will allow me an opportunity to see whether my hunch is correct or if there's some other underlying problem (like faulty hardware) that needs to be corrected.

My question is (and thanks for reading my 'novel' up to this point)... Is it adequate to allow online maintenance processes to occur once a week instead of every night? What's the downside of not performing this task every night?

share|improve this question
A few questions: 1. Are you referring to the Mailbox Management Process or to the Mailbox store database maintenance? 2. When you refer to the Exchange store size are you referring to the physical file size of the edb file? – joeqwerty Oct 16 '11 at 14:13
Answer to 1... Referring to the Mailbox Store Properties --> Maintenance interval... Answer to 2... Probably not the best way to judge "size", but I'm referring to the size of the resultant nightly backup (.bkf) file that's created when I back up the exchange data via ntbackup. In a couple of weeks the filesize went from 39GB to 44GB.... increasing at a rate of about .5GB per day. – Joe Oct 16 '11 at 14:21
up vote 1 down vote accepted

The database maintenence process cleans up items that are beyond the retention date configured for the mailbox store as well as performing several other tasks. It allows new items to be created without having to grow the physical file size. I would look at the Deleted Item retention setting and make sure they're appropriate. As for the physical file size, an online defrag won't shrink the physical file, only an offline defrag will do that. If you think that the file growth is outpacing the database maintenence then you should look at reducing the deleted items retention time. As far as whether or not the mailbox store maintenence is causing the crash, it depends on how big the database is and how much work is being done cleaning it up. I can tell you from my experience that I think it's doubtful. If it is, it's possibly due to inadequate or faulty hardware. I manage an Exchange 2003 server (Enterprise Edition) with 4 mailbox stores all exceeding 100GB, comprised of 650 mailboxes and I run the mailbox store maintenence process with no problems.

The one point I would make is that you should schedule the mailbox store maintenance and your backups in different time windows as the two can't run at the same time. The malbox database maintenance process will stop when it detects a backup has started. If the two tasks conflict then your database maintenence process may never be completing. It will pick up the next time where it left off. You can check the Application event log for Event ID 1207 which signifies that the cleanup of items past the retention date is complete, Event ID 1209 which signifies that the maintenenace task is complete, and Event ID 1221 which signifies that the online defrag is complete.

Also note that the process will run for a minimum of 15 minutes and a maximum of 1 hour. The time you configure in the maintenance schedule is the time in which it CAN run, not the amount of time it WILL run.

Here's a rundown on what the process does:;en-us;324358

share|improve this answer

Purely asking about the defragmentation, the answer would be "it depends." How fragmented is it in the first place? How heavily used is the mail server? A barely used mail server will hardly suffer much fragmentation in the first place.

I suppose you could get a ballpark estimate by looking at how long the job takes. Is the job fitting easily into the maintenance window you've allowed for the defrag?

If the defrag you run is fitting into the time you allot, and you're not running into performance issues between runs (or soliciting errors), then yes, it's enough to use your workaround scheduling to defragment the store.

Defragmenting isn't something that's meant to keep the Exchange store running. If you never defragment it the Exchange server won't die. Performance may degrade over time and eventually crawl but it won't just up and lose data or corrupt just because it's not defragmented.

share|improve this answer
The mail server is used pretty extensively. There are about 80-90 employees who use the server to varying extent. About 50 users are what I would consider heavy users (not referring to their physiques). The company is an engineering firm. They use email extensively and unfortunately too much for transferring files less than 10MB in size. Yes, the maintenance job runs comfortably within the maintenance time window. So far no one has complained of performance issues... and that's exactly what I'm trying to avoid. – Joe Oct 16 '11 at 14:31
You'd probably have a more accurate measure by looking at incoming and outgoing traffic and their sizes. 80 to 90 users isn't really a big number of users for Exchange. Well, if they were spammers I guess it would be, but ordinarily it isn't. At any rate, if you're not seeing problems then it looks like it's all good. Move on to the next problem to worry about :-) – Bart Silverstrim Oct 16 '11 at 14:47

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.