2. Top causes of fast growing logs and how to handle them

    - Looping messages / very busy recipients

            - Looking for loops

            - Looking for "top recipients"

            - Looking for possible large incoming spam volume

            - Public folder replication

-          Open relay- M: drive / IFS file level AV scanning-

         - Online maintenance

1. The problem

The server is generating unusual amount of transaction logs that is filling up the transaction log drive. 

The databases might or might not grow as a result of this problem, depending on the cause.

2. Top causes of fast growing logs and how to handle them

    - Looping messages 

This means that there are messages in the transport that are looping between mailboxes or servers.. There are several things that we can do to try figure this one out:

1. Go to the server object in ESM, and on Diagnostics Logging, turn up logging on:

MSExchangeIS > Public Folder > Rules

MSExchangeIS > Mailbox > Rules

This will show you if there is a specific rule or rules that is getting fired very often, repeatedly, which could possibly lead to the problem as to why email is bouncing.

2. Go to the server object in ESM, on the General tab - turn on Message Tracking if it is not turned on yet. If it was not turned on, then after you do so, you should wait for a while to generate some activity in it. If the logging was already turned on, we should get the message tracking log from the customer. The tracking logs are going to be located (by default) in the following folder:

<DRIVE:>\Program Files\Exchsrvr\<servername>.log

The General tab will show you the location on Exchange 2003 servers. The log files will have the name in the format of:

<YEAR><MONTH><DAY>.log

So - the log that is called "20070131.log" is created on January 31 2007. A new log is going to be created every day. If the server is a very busy server, the message tracking logs can get quite large. Needless to say, we should get the message tracking log from the time that the problem was happening.

When we get the message tracking log in house, there are several things that we can do with it:

            - Looking for loops

Get the tool to try detecting looping messages in the tracking log. There are two tools for this, and you should try both (if one does not give you results, the other one most likely will - as they are both .EXE tools that were compiled from slightly different original scripts). The tools are called "msgtrack-loopdetect.exe" and "loopdetect.exe".

This will create the "loopoutput.txt" which should then be looked into. 

            - Looking for possible large incoming spam volume

The same message tracking log can be analyzed using the tool called "spamcount.exe". This tool returns the list of most frequent senders. So - if someone is sending a lot of email to our mailboxes - he will be listed on the list - again, something to look into.

Public folder replication issues:

We can turn on diagnostics logging on the public folder replication messages to see if the server is getting hammered with those. To do so, go to the server object in ESM, and on Diagnostics Logging, turn up logging on:

MSExchangeIS > Public Folder > Replication Incoming Messages (set it to Max)

If the server is getting a lot of public folder replication messages, you will see a lot of events with event IDs of 3028 and 3030 (those will be the most common ones).

    - Open relay

If the server is an open relay, there will be tons of transaction logs. You will also usually see a bunch of items in the BADMAIL folder. The key here is of course, locking the server down so it is not an open relay anymore. There are several articles that talk about how to work on that,Huge amount of email in BADMAIL though is an indication of possible problems.

    - M: drive / IFS file level AV scanning

Scanning the M: drive / Exchange IFS will definitely cause the transaction logs to show up. File-level AV scanners in most cases modify the item that they touch. Seeing that the M: drive is a virtual representation of your databases, those modifications are made to the database data. Therefore - there will be tons of transaction logs, usually generated over short period of time (during the duration of the scan). Databases will typically not increase in size as a result.

You will usually be able to see events in the Application log that give you clues that the M: drive / IFS are being scanned.

The following is a sample event that could get logged if the M: drive is exposed and scanned:

Event: ID 6 
Source: Norton Antivirus
The description for Event ID ( 6 ) in Source ( Norton AntiVirus ) cannot be found. The local computer may not have the necessary registry information or  message DLL files to display messages from a remote computer. The following information is part of the event:
Scan could not open file M:\DOMAIN.COM\MBX\alias\Inbox\somesubject.EML

The following is a sample event that could get logged if the AV software scans the files through the //./backofficestorage/ path (note that this is still file level scanning - and the M: drive does not have to be exposed for it; in fact - the below event was taken from an Exchange 2003 server that did not have the M: drive exposed!):
 
Event ID: 2045
Source: McAfee GroupShield
The description for Event ID ( 2045 ) in Source ( McAfee GroupShield ) cannot be found. The local computer may not have the necessary registry information or  message DLL files to display messages from a remote computer. The following information is part of the event:
The On-Demand 4 Hours Cycle scanner failed to scan the item 'file://./backofficestorage/domain.com/mbx/alias/Calendar/important meeting.EML' with error 80040e19.

    - Move mailbox / Emerge operations

Large amount of move mailbox operations will cause a lot of transaction logs on both servers - the server that the mailboxes are being moved from and the server that the mailboxes are being moved to. This is simply because all of the mailbox messages are ultimately created on the target server and deleted on the source server. Both creations and deletions are logged transactions.

Additionally, certain Exmerge operations will create a lot of transaction logs too. Example would be archiving of email into PST files (which deletes the messages from the store) or importing messages from PST files into the store (which creates messages in the IS).

Merging mailboxes using the Exchange 2003 SP1 Recovery Storage Group functionality will also create transaction files.

    - Online maintenance

Seeing that online maintenance performs a series of actions on the data within the Exchange database - some of online maintenance tasks will also generate transaction logs on the server. This will typically be only during the online maintenance period though, but it is a good thing to keep this in mind as one of things that cause log file creation.

Please check all these things you will be able to rectify why logs are getting generated.

Jatin kakkar