We have mounted the DB files to a separate drive however I found the C drive overwhelmed today with log files going back months! They are located in C:\program files\microsoft\exchange server\mailbox\first storage group. All 1 mb files. 1) Can these be safely deleted? If so, what is the best practice to do so? Can I just highlight and deletd? 2) How can I prevent these files from being created or set up a rollover limit so the folder doesn't get so large?

1) No. Run a full Exchange-aware backup of the Information Store object. 2) Don't send or receive any e-mail. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "nesdog1122" wrote in message news:de899d3d-d17b-40df-9453-a07b564f380c... We have mounted the DB files to a separate drive however I found the C drive overwhelmed today with log files going back months! They are located in C:\program files\microsoft\exchange server\mailbox\first storage group. All 1 mb files. 1) Can these be safely deleted? If so, what is the best practice to do so? Can I just highlight and deletd? 2) How can I prevent these files from being created or set up a rollover limit so the folder doesn't get so large? Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Thanks, Ed. I think I've come up with the answer based on your response....it turns out the admin who set this server up isn't using a standard backup process. Rather, he found some way of exporting the mailboxes to .pst's. So we aren't running an Exchange aware backup application. I'll start working on that right away. I appreciate the quick response! Sheldon

You're welcome. Good luck! -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "nesdog1122" wrote in message news:371971b6-e733-44a6-9d3d-7a0c29f56b7b... Thanks, Ed. I think I've come up with the answer based on your response....it turns out the admin who set this server up isn't using a standard backup process. Rather, he found some way of exporting the mailboxes to .pst's. So we aren't running an Exchange aware backup application. I'll start working on that right away. I appreciate the quick response! Sheldon Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Just to follow up on Ed's suggestion, if you are happy with you non Exchange aware backup method (I recommend using Exchange aware method) then you could enable circular logging. This would eliminate the logs from growing and you could still continue to export your mailboxes as your backup method.Tim Harrington - Catapult Systems - http://HowDoUC.blogspot.com

However, circular logging increases your risk substantially. If you have to do a restore, it's likely you'll lose data. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "TWHarrington" wrote in message news:408214cd-4624-44bc-907e-8c2307786975... Just to follow up on Ed's suggestion, if you are happy with you non Exchange aware backup method (I recommend using Exchange aware method) then you could enable circular logging. This would eliminate the logs from growing and you could still continue to export your mailboxes as your backup method. Tim Harrington - Catapult Systems - http://HowDoUC.blogspot.comEd Crowley MVP "There are seldom good technological solutions to behavioral problems."

What I ended up doing is enabling circular logging for the moment. This allowed the backed up log file folder to be properly cleansed. The next step will be to examine our backup strategy. I think what happened was that we had no budget for software and we found what seemed to be an inexpensive way to export the mail into .pst's via script. Obviously this works but created other issues for us. So we will need to look at Exchange aware software and take it from there. Ultimately, we'll disable circular logging so that we have a proper database recovery scheme. I am very much appreciative of the comments and suggestions in response to my post. I needed a quick solution to keep things working and that is exactly what I got!

For someone not familiar with Exchange 2010, can you explain why backup software is the appropriate solution to solve the problem with the logs? Most backup software does not delete files after backing them up so I don't see how this would be a solution to the problem.

On Thu, 13 Jan 2011 18:31:45 +0000, Tank wrote: >For someone not familiar with Exchange 2010, can you explain why backup software is the appropriate solution to solve the problem with the logs? Most backup software does not delete files after backing them up so I don't see how this would be a solution to the problem. The log files that are no longer needed to restore the backup are removed. Since those log files wouldn't be replayed into the restored database there's no reason to keep them. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Thanks for the reply Rich. Let me see if I understand this correctly... What I'm hearing is that Exchange 2010 depends on other software (in this case backup software) to delete it's own log files that are no longer needed and could even be a source of performance problems (at least in nesdog's case). Backup software that is "Exchange Aware" apparently has this capability. Can anyone provide examples of backup software that is confirmed to have this feature? Also, Ed Crowley said these log files cannot be safely deleted. If these log files are "disposable" why can't they be deleted by something other than backup software? Thanks for helping me to understand this.

Tank, These log files aren’t informational like the Windows event logs. These are transaction logs that hold all changes to the Exchange information store (a database) since the last backup. In the event of a corrupt or destroyed information store you would restore the last backup. Exchange then replays the logs in order, which recreates the changes since the last backup. When a backup is created the previous logs are deleted since the backup now contains those changes. Most Exchange aware backup programs will list it as a feature or have an “Exchange Agent”. BTW this isn't new to Exchange 2010, I know it has worked this way since at least Exchange 2003.

That is extremely helpful information. Thank you! Does anyone know of any backup software that has this feature for Exchange 2010?

Most of the main players do. I've used Symantec BackupExec and Commvault Simpana. You can even use Windows Backup (http://technet.microsoft.com/en-us/library/dd876854.aspx) Just Google "exchange backup software" and you'll get lots of options.

1) Do full backups of the DB; 2) Schedule an online maintenance.

On Fri, 14 Jan 2011 19:00:42 +0000, Tank wrote: >Thanks for the reply Rich. Let me see if I understand this correctly... > >What I'm hearing is that Exchange 2010 depends on other software (in this case backup software) to delete it's own log files that are no longer needed and could even be a source of performance problems (at least in nesdog's case). The transaction log files ARE needed until a normal/full backup of the database is completed. At that point any transaction log files that have no uncommitted transactions are no longer necessary. >Backup software that is "Exchange Aware" apparently has this capability. Can anyone provide examples of backup software that is confirmed to have this feature? Legato, CommVault, BackupExec, etc. etc. >Also, Ed Crowley said these log files cannot be safely deleted. If these log files are "disposable" why can't they be deleted by something other than backup software? They can be -- if you understand how they're used, how to determin which are "safe" to remove, etc. But making a backup with the appropriate software gets you a backup that you can use to restore the file and be able to bring the database back to a consisten state without data loss -- if you have the right log files. The backup software uses Exchange to remove the log files, they don't do it themselves. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP