In this article let me discuss about troubleshooting unusual growth in log files and database in Exchange 2007 and Exchange 2010.
It’s always better to check and validate first before we jump into any troubleshooting. It’s better to check first from what time the log files and the database starts growing rapidly.
We can probably filter out events for any related information about logs and database in the application logs in the affected mailbox server.
Also we need to collectively gather all information about the list of third party software’s installed and running on the affected mailbox server.This could be the problem as well if the handshake between Exchange and third party agent is broken.
I have classified few troubleshooting steps which would help us in narrowing down and rectifying these kind of issues.Below are the list of troubleshooting that can be possibly done .
The first step that would easily help us in identifying the problem is using EXMON tool to see if there are any user’s unusual activity which causes the log files to grow rapidly.
You can download the exmon tool from the below location
Run exmon tool and sort the the value by % cpu and look for high CPU consuming users. Also you can check the log bytes column to monitor the log growth.
If you identify any potential users then you can see the following things
- See if there are any email with a large attachment which is stuck on the outbox.
- Also you can monitor if there are any spam mails circulating on the affected user’s mailbox.
Exclude FILE LEVEL AV SCANNING
If the AV scanning running on mailbox servers is not aware of exchange databases and log files then this will definitely cause the transaction logs to grow rapidly.
Following things can be checked
- Check if there are any recent updates that happened on the AV scanner on the mailbox servers which might remove exchange databases and log files exclusions.
- Ensure that AV exclusions are set for Exchange databases and Log files on the AV scanner in the mailbox servers.
- Disable AV scanning on the affected mailbox server where transaction logs and DB are growing rapidly. Monitor for few hours and see the log files and database growth and compare the results.
Check if the server is an open relay to the internet, there will be tons of transaction logs. You will also usually see a bunch of items in the junk mail folder. So ensure that the environment is not open for relay as huge amount of spam mail circulated also will cause the server performance and server to send out more number of spam messages internally as well as externally.
It’s better to have a look at all the queues in all hub servers to ensure that no spam messages are been sent out from our organization in such kind of scenarios.
PUBLIC FOLDER REPLICATION
- Check if there are any PF replicas initiated recently on the affected mailbox server recently as it could cause the problem.
- Check in the message queue if there is more number of public folder replication messages.
CHECK BACKUP CONFIGURATION
If you have any backup running in the environment ensure that the backup is scheduled properly. Ensure that you are running only full and incremental backups as only these two types of backups will truncate the logs and the rest wouldn’t have the capability to truncate them.
If a server hosting the data being backed up is a member of a database availability group (DAG) and hosts both active and passive database copies, you must disable the Microsoft Exchange Replication service VSS writer. If the Microsoft Exchange Replication service VSS writer is enabled, the backup operation will fail.
To disable the Microsoft Exchange Replication service VSS writer, perform the following steps:
- Log on to the server by using an account that has local administrator access, and then start Registry Editor (regedit).
- Navigate to HKEY_LOCAL_MACHINE\Software\Microsoft\ExchangeServer\v14\Replay\Parameters.
- Add a new DWORD value named EnableVSSWriter, and set its value to 0.
Exit Registry Editor and then restart the Microsoft Exchange Replication service.
Bulk Mailbox Move
If there are any recent bulk mailbox move that is happening that could generate lot of log files if few of the mailboxes are larger in size and if it has more corrupted items. Probably for this as a temporary fix until the mailbox move completes you can enable circular logging on the source and the destination mailbox database. Ensure that you need to disable circular logging once the move is completed as enabling circular logging always is not a good choice.
Hope this helps in scenarios where we come across scenarios in troubleshooting unusual rapid growth in database and log files.