atom beingexchanged: As promised, some more info on Online Maintenance Part 1

Friday, March 6, 2009

As promised, some more info on Online Maintenance Part 1

Quite some time ago I promised to go into some more detail on what happens during the Online Maintenance period of Exchange Server.  This is an often-confusing topic as it happens in the background and - except for the whopping load it puts on the server when it's running - there is not a lot of indication that it happened at all.  Today, let's talk about some of the basics, such as when it happens and why you should allow it to happen regularly.

Online maintenance (OM) is an automated set of procedures that Exchange 2000-2007 servers perform nightly by default.  Though often referred to as one big process, OM is in fact a catch-all term that describes several different procedures, one or all of which may happen during the OM window each night.  These processes include, but aren't limited to, Deleted Item Retention; Mailbox Cleanup, online defragmentation and Public Folder Cleanup.

Left to its own devices, Exchange will perform OM automatically between Midnight and 4am each day.  This is mostly due to the fact that OM will use a significant amount of processor power and disk I/O while it runs through its various processes, so it isn't a great idea to let OM run during the normal business day.  If, however, your peak times are between Midnight and 4am, you can definitely change when OM runs through the GUI for Exchange by right-clicking the Store in question and going to the Properties dialog box.  That will let you go to the Database tab, where you can adjust the Maintenance Interval to match your less-than-normal server load times.

Even if the default schedule is good for your organization, you may still want to edit the times for individual Information Stores if you have more than a few of them.  This is a good idea since you'll be able to stagger the OM runs, allowing the server to spread the overhead of performing OM on multiple stores by not forcing the server to run them all at once.  Running OM on all of the Stores at once is possible, but will put a heavy burden on the server if you have many Stores, and may cause some maintenance tasks to fail.  They'll be retried in the next window, so you aren't out of luck, but if the load can be spread out, that's always a good idea with Exchange as a general rule of thumb.  Check the Application Logs in Windows Event Viewer in the AM, and you can see the results of the OM processes as log events.  That will give you an idea of some things are not finishing.

As to why you should do OM often and completely, that's a bit easier to explain.  Exchange is a database, not a collection of mail files.  Like just about every other database, when items are written out to disk, they are done in the fastest way possible, instead of trying to group everything into (human) logical areas of control.  This translates into faster write times, but can lead to a highly fragmented database structure, which can cause slowdowns in general and errors down the line.  Also, since we're not talking about discrete files for each email, when something is deleted, what really happens is that Exchange marks the areas of its database where that information existed as available to be reused.  This is commonly known as creating white space in the database, and can add to the overall level of fragmentation as you will have pockets of white space all over the place.

OM - during one of its processes - combs through the database to find areas where defragmentation can occur.  This allows Exchange to move all the white space to the back of the database, where it can more effectively be re-used for new information coming in.  While this isn't strictly required, it does help speed up the overall Exchange system and make it more efficient, slowing the growth rate of your databases in the process.  Note that your databases won't shrink during this process, and we'll talk about that more in a future column, but they will grow slower, as Exchange will be able to use available space more effectively before it starts allocating new space.

In addition to fragmentation, Exchange doesn't really delete an email or mailbox when you hit delete in Outlook or the Exchange management GUI's. Most Exchange Engineers will know that items are marked for future deletion, and that doesn't happen until OM is run.  We'll delve into Deleted Item Retention and what OM does to address it in later columns, but the take-away here is that unless you allow OM to run regularly, you will have to manually run processes to remove old, deleted mail items and mailboxes.  For those with strict compliance and regulatory concerns about deleted email, this becomes a vital consideration.

To wrap up Part 1, you should allow OM to run nightly if you can, spreading out the times over as long a period of time as you can, with different Stores having OM run at different times if possible.  This will allow for the most effective running of the OM processes, but constrict them to happening when fewer users are trying to send/receive mail.  You should also run OM at least monthly if not more often, because otherwise your databases will become less efficient and items that are deleted will never be removed.

Next week...How Deleted Item Retention works in Part 2!

Bookmark and Share
posted by Mike Talon at

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home