Enabling Circular Logging (Round, Round you go)
One of the first settings I look for when examining an unknown Exchange Servers, is whether Circular Logging is enabled. Contrarily to some beliefs, it isn’t something you should enable without reason. In my opinion, there are only 3.5 reasons to do this.
For those who don’t really know what Circular logging is, here a short explanation which hopefully makes the importance more clear. Circular logging is the option for Exchange, tot reuse it’s transaction log files. Transaction log files are buffer files which are used to enhance the performance of the Exchange Server. Being 5 or 1MB (resp. Exchange 2000 and 2003 versus 2007) in size, these are the files where all maildata is stored before being committed to the Exchange Store. Normally those files are only flushed (deleted) when an Exchange Full backup of the storage group in question has been performed.
Now comes the kicker. With a full store backup and the transaction logs of that storage group, you can restore your store up until the moment it went belly up. How? Transaction log replay!. Every mail or other groupware item has been (temporarily) stored in the transaction logs, up until a full backup. This means that you can restore an Exchange server up until the failure, when you have intact transaction logs and a successfully made full backup of your store(s). Just restore your Exchange Store and initiate log replay, that’s that. But when you enable Circular Logging, this restore option is not available to you and you have lost data generated between the moment from your full backup and the failure. Many organizations will find this unacceptable, especially when they know there are solutions for it.
But what are valid reasons to enable this option? Surely, Microsoft didn’t put it there without reason? Indeed they didn’t. Below is a list of scenarios in which Circular Logging is a valid or even wise option to enable IMHO:
I’ve got no room left.
Yeah, sometimes you or your predecessors didn’t expect the amount of data to reach the limits of you physical storage unit. Transaction logs take up about the same amount of data generated by you, your users and received data (including spam if you didn’t filter it out at an earlier stage), between two successful full store backups.
Time to evaluate you capacity management, pick a fight with your predecessor and kick yourself for not noticing and supplying your servers with more storage capacity on time. Not a valid reason in my book, but being lenient I also acknowledge the fact that sometimes you are working in a less than perfect situation. Therefore not a whole reason but just 0.5 of a reason and only a temporary one at best.
I want it there.
Astute readers noticed that with the previous reason, I told you that your users, received data and yourself generate data which end up in the transaction logs. That’s right, you are also a culprit! Every time you move a mailbox from and to another server (or store on the same server for that matter) transaction logs are used. It’s something you notice when you transition to a new server and move all mailboxes. This can hurt, if you are not prepared (yes, I have felt hurt…).
In the front, but not in the back
With Exchange 2000 and Exchange Server 2003 it became possible to construct a front-end/back-end scenario. The back-end Exchange server(s) contained the data and are situated within you inside network. The front-end Exchange server was placed in the perimeter network (if you were doing it the Microsoft way), in any case it was the only internet facing server. It is tasked with cleaning, offloading, client access and such doesn’t has the need for storing mailboxes and thus stores, that is what the back-end servers are for.
Unfortunately the case is not that simple. In order to to send Non Delivery Reports (NDR), convert between mail formats (curse you Linux users! [;)] )and for most of the malware applications, you do need an Exchange store. Because there is no mailbox situated (if you have done your job right), there is no need for a backup and you can safely turn on Circular logging.
It’s just not that important
This last reason was something I recently realized. While configuring the Exchange server in preparations of a transition from Exchange Server 2003, the client decided they wanted to temporarily store mailboxes of users who left the organization. Not very often, but often enough a user would return or other users (their previous manager for instance) needed information out of that mailbox. Having it still available through Exchange is much more user friendly than providing a PST file (and prevents entering the PST Hell). Just an extra service regarding your users!
For the aforementioned reasons I created a separate Storage Group and Store. Reasoning that the mailbox would be placed there after a full backup had been performed earlier, the mailbox data had a low priority etc. etc. the need for a complete restore was at a minimum. The store would not be a part of a normal backup selection (not daily or weekly) and the mailboxes would not be that active with important mails. So for similar situations, this can be a valid reason to enable circular logging.
So, there you have it. 3.5 reasons to enable Circular logging without having to frown. Of course there could be more scenario’s which I haven’t encountered before or failed to imagine. If you did or if you disagree on some of the reasons I mention above, please let me know.