Exchange: Transaction Log Files Growing Rapidly; Case Scenarios

Summary:

An Exchange admins worst nightmare is to come into work one morning to find out your partition housing your transaction log files has been filled up with an abundant amount of log files. You continue to monitor your disk space which is filling up at a rapid pace. What to do? In this article I will share my experience in dealing with these situations.

Note: If you are currently experiencing rapid log file growth and your partition housing your log files is running low on disk space, enable circular logging immediately. This will flush all log files as they are committed to your database. This will prevent your partition housing your log files from filling up and causing your store to dismount.

XADM: How to Modify the Circular Logging Setting
http://support.microsoft.com/kb/258470/


Case Scenario #1 Script Gone Haywire

In this scenario, I came into work to find out that the log files have grown tremendously and eating up disk space at rate of almost 1-2GB an hour. Because of the rate at which the logs being generated, users were complaining about messages being delayed. This is because the rate at which the log files were being committed to the database could not keep up with the rate that they were being generated in additional to a high store.exe process.

The root cause analyses was a script that an employee wrote which was part of our ticketing system. I ran MS Netmon which is a packet sniffer to determine if I could find the source of where the traffic was being generated from, which helped me to pinpoint it to our ticketing system.

You can download Netmon from ftp://ftp.microsoft.com/PSS/Tools/ The file is zipped and contains a password. The unzip password is "trace"



Case Scenario #1 Routing Loop (Migration)

In this scenario, I also experienced rapid log file growth. This scenario occured during a migration from 5.5 to 2003. The root cause analyses for this situation was more of how the organization's mail topology was configured.

This organization used a Sendmail server as it's frontend and thus hosted the MX record for the organization say abc.com. It then forwarded to the Exchange backend using an alias table. The Exchange backend environment thus hosted an internal MX record say xyz.local. The recipient policy of the Exchange org was configured as:

Primary: abc.com
Secondary: xyz.local

Internet mail would arrive to user@abc.com, the Sendmail server would lookup the alias table and forward to user@xyz.local which would deliver to the Exchange Org. Now because our Exchange Org did not host all users for for the recipient policy of abc.com, the SMTP Virtual Server was configured to "Send all unknown recipients to" another Sendmail smarthost.

The loop was caused because the alias table on the Sendmail server was not maintained. Therefore, when an email arrived at the frontend Sendmail server destined to user@abc.com, it would look up the alias table and see it mapped to user@xyz.local and forward it to the Exchange Org. The Exchange Org did not have this recipient and would foward it out to a Smarthost because "Send all unknown recipients to" was configured. This Smarthost would then send it back to the frontend Smarthost causing a loop.

Resolution was to enable "Filter Recipients who are not in the directory" in the Global Settings in Exchange System Manager in addition to having a procedure to maintain a current alias table.



James Chong
MCSE M+, S+, MCTS, Security+
msexchangetips.blogspot.com


How useful was this article? Want to see a tip not listed? Please leave a comment.