Exchange 2000 log file

I then tried a backup overnight but it didn't complete and the log files filled the 20GB back up again. I use backup assist for Exchange backups and backup assist shows status of the last back up that Exchange database consistency check failed.

Also shows a VSS error in the backup job that has resulted in the loss of most of your backup history and my backup drive has a ton of free space on it now where it didn't before. I do have a backup from a week ago as an emergency. I'm still not sure what is causing this currently. I believe we've found the problem. Ran Exchange User Monitor program and initially it didn't show much. Everything appeared normal, but then I noticed logs starting to pile up again and started monitoring it at that point and one user remained at the top of the list constantly.

This person had been out and we had just re-enabled their AD account yesterday right around the time when the problem started. I believe the issue is with their mobile device so I have disabled active sync and so far things have calmed down. I moved around 30GB of log files to another drive and Exchange is back up and running. Now just trying to get a full backup completed. To continue this discussion, please ask a new question.

Adam CodeTwo. Get answers from your peers along with millions of IT pros who visit Spiceworks. Thanks for your response. Looking at the log files it doesn't appear that they are being deleted by the backup at all; despite the databse being aware of the fact that a Full Backup has taken place.

Last night I started the Veritas backup Exec 9. After 13 hours it has backed up MB of the Bricklecvel Mailbox backup. Something is very wrong here Do you think I should move the log files previous to the last committed file not delete, just move!

I have a funny feeling that this is not going to help. After desperation we went with an incremental backup I'm going to test a full backup later on today to make sure that the files are purged Backup exec backup took 27 hours over the weekend Not sure what to do about that yet; we need the brick level backup to work.

The reason for the Bricklevel backup is simply fast restoration of user mailboxes. We don't have a secondary server which we can use for recovery purposes, so the bricklevel backup is our only viable solution considering we're using Exchange Reply to author.

Report message as abuse. We wanted to revisit this topic with Exchange in mind. While the troubleshooting steps needed are virtually the same, we thought it would be useful to condense the steps a bit, make a few updates and provide links to a few newer KB articles.

The below list of steps is a walkthrough of an approach that would likely be used when calling Microsoft Support for assistance with this issue. It also provides some insight as to what we are looking for and why. It is not a complete list of every possible troubleshooting step, as some causes are simply not seen quite as much as others. An example of this is when an Administrator notes a transaction log file drive is close to running out of space, but had several GB free the day before.

When looking through historical records kept, the Administrator notes that approx. This is obviously a red flag for the log creation rate. Same principle applies with the database in scenarios where the rapid log growth is associated to new content creation. In other cases, the database size or transaction log file quantity may increase, but signal other indicators of things going on with the server. For example, if backups have been failing for a few days and the log files are not getting purged, the log file disk will start to fill up and appear to have more logs than usual.

Another example is with the database, where retention settings have been modified or online maintenance has not been completing, therefore, the database will begin to grow on disk and eat up free space. It should be noted that in some cases, you may run into a scenario where the database size is expanding rapidly, but you do not experience log growth at a rapid rate. As with new content creation in rapid log growth, we would expect the database to grow at a rapid rate with the transaction logs.

The steps to troubleshoot this specific issue can be a little more invasive as you can see in some analysis steps listed here taking databases offline, various kinds of dumps, etc. Once you have established that the rate of growth for the database and transaction log files is abnormal, we would begin troubleshooting the issue by doing the following steps. Note that in some cases the steps can be done out of order, but the below provides general suggested guidance based on our experiences in support.

Use Exchange User Monitor Exmon server side to determine if a specific user is causing the log growth problems. If it appears that the user in Exmon is a? Query the message tracking logs using the Message Tracking Log tool in the Exchange Management Consoles Toolbox to check for any large messages that might be running through the system.

See 15 for a PowerShell script to accomplish the same task. With Exchange Service Pack 2 Rollup Update 2 and higher, you can use KB to troubleshoot abnormal database or log growth by adding the described registry values.

The registry values will monitor RPC activity and log an event if the thresholds are exceeded, with details about the event and the user that caused it.

These registry values are not currently available in Exchange Server Check for any excessive ExCDO warning events related to appointments in the application log on the server. Examples are or events. If recurrence meeting events are found, then try to regenerate calendar data server side via a process called POOF. The calendar is being repaired.

If other errors occur with this calendar, please view the calendar using Microsoft Outlook Web Access. If a problem persists, please recreate the calendar or the containing mailbox. This may be the result of many very old recurring appointments. To correct this, please remove them or change their start date to a more recent date. In here, you can look for repeated user account sync attempts and suspicious activity. For example, a user with an abnormally high number of sync attempts and errors would be a red flag.

If a user is found and suspected to be a cause for the growth, you can follow the suggestions given in steps 5 and 6. If a suspected user is found via Exmon, the event logs, KB , or parsing the IIS log files, then do one of the following:.

Have the user launch Outlook while holding down the control key which will prompt if you would like to run Outlook in safe mode. If launching Outlook in safe mode resolves the log growth issue, then concentrate on what add-ins could be attributing to this problem. For a mobile device, consider a full resync or a new sync profile. Also check for any messages in the drafts folder or outbox on the device. A corrupted meeting or calendar entry is commonly found to be causing the issue with the device as well.