Microsoft Exchange and Blackberry Server Specialists

What Uses the Disk Space?

On this Page

  • Introduction
  • Identifying the File Use
    • Exchange Database Files
    • Message Tracking Logs
    • Web Access Logs
    • Protocol and Connectivity Logs
    • Exchange Transaction Logs
  • Questions

This is for Exchange 2007 ONLY. For the version for Exchange 2003, click here: What uses the disk space on Exchange 2003


Among some Exchange administrators there is some confusion of the use of disk space. Usually when an administrator comes in one morning to find that the server has died because it has run of our disk space.

There are up to four main types of files that can grow on an Exchange server.

  1. The Exchange Database Files
  2. The Exchange transaction log files
  3. Message Tracking log files.
  4. Web Access Log Files
  5. Exchange 2007 Connectivity and Protocol Logging Files.

Identifying the file use

In order to work out where the disk space has gone, you need to identify the file types.

A good first option is to use a tool which will analyse the disk space and tell you what folders have the most data in them. Use something like TreeSize for this. (Download). Once you know where the space is being used up, you can look to see what they are.

Exchange Database Files

Exchange database files are a single file, ending in the extension of "edb". You should do nothing with those files while Exchange is running. 

Message Tracking Logs

Message tracking logs are a lot of every message that goes through the server. They only log the date time, sender and recipient, plus if you have enabled it, the subject.

The status of Message Tracking can be seen on the Properties of the server under Server Configuration, Hub Transport. Right click on the server and choose Properties. Click on the tab "Log Settings". To change the advanced settings of Message Tracking, such as retention time and the logs location, you need to use the Shell command set-transportserver

More information on message tracking is here.

Web Access Log Files

If your site is heavy user or web services, such as Outlook Web Access, RPC over HTTPS, Exchange ActiveSync then you will quickly clock up web logs. These are standard IIS logs and therefore can be treated as such. The default location for them is C:\Windows\System32\Logfiles. For the default web site it will be a folder named W3SVC1. The files in that folder can be deleted without any issues, no services need to be stopped. However you may wish to keep the last month or so in case you need to refer to them in the future.

Protocol And Connectivity Logging Files

The status of Protocol Logging and their location can be seen on the Properties of the server under Server Configuration, Hub Transport. Right click on the server and choose Properties. Click on the tab "Log Settings".
For more information on Protocol Logging see here: For Connectivity Logging:

Exchange Transaction Logs

Exchange transaction logs are the most common cause of loss of disk space use, as they are not flushed unless there is a successful backup. After a backup is successful the transaction logs are marked as committed and flushed. If a backup fails for some reason then you can get a rapid build up of the logs. The transaction logs are a log of everything the Exchange server has done since the last backup. Transaction log files are easily identified as they are always the same size - 1024kb.

Do NOT delete these files manually.

If you are seeing a lot of transaction log build up, then you should first check your backups to see that they are working correctly. If you are using a third party backup tool to backup Exchange and it doesn't seem to be working correctly, then as a quick and dirty method to flush the logs, use Windows Backup that is built in to Windows on the Exchange server to backup Exchange. This will flush the logs.

A rapid build up of transaction logs can also be an indication of a problem with your email - an email loop or the server is being abused by a spammer. This should be investigated as well, particularly if the backup was successful and the transaction logs are all timed after the backup has completed.

If you need to create space quickly, then transaction logs will compress very easily with little performance impact. Do NOT compress the entire directory, as this can cause problems. When you are compressing the files, make sure that you only select the transaction logs - not the database files that may be in the same folder, nor any other files that are in the folder that are not 1024kb in size. Do not compress the current log file either, as that will have a performance impact on the server.

If you do need to manually delete the files, or you have reason to believe that Exchange isn't flushing the logs files correctly after a backup and there are committed log files still there, then you should review this KB article:


Q: How can I tell when the last successful backup was taken?
A: You can see if Exchange is aware of a successful backup in EMC, Server Configuration, Mailbox, <your server>. Under <your storage group>, <your mailbox store> right click on on the mailbox store and choose Properties. On the first tab "General" the backup time will be shown. If blank, then the database has never been backed up.

Q: I backup our server using Ghost, True Image or other disk image based system, but the transaction logs don't flush.
A: This type of backup is not considered by Exchange to be a valid backup of the database and therefore will not flush the transaction logs.
Exchange isn't particularly well suited to this type of backup either. These are snap shot type backups and therefore do not give you options for restoring the additional data.
For example, you run a backup at 3am on a Tuesday which completes successfully. The next day your users come in, work on their email etc. At 1am the next morning, the server fails and you need to restore from a backup.
With an image based backup you would lose the last 22 hours of email. For many companies, the most recent email is the most valuable.
However if you had carried out an Exchange aware backup and had also followed the best practises of having the Exchange database separate from the transaction logs, you could restore the data and then replay the transaction logs in to the database. This would bring the database close to the point of failure.
If you insist on carrying out an image based backup type without an Exchange aware backup application then you should enable circular logging. This will ensure that there is not a build up of the transaction logs, but limits your data recovery options.

Q: Why shouldn't I simply enable circular logging to get rid of the transaction logs?
A: Circular logging should not be considered a valid method of dealing with transaction logs that have built up and not been flushed by a backup application. You should investigate why the backup application and/or Exchange is not flushing the committed logs.

Q: Can I move the database and/or transaction logs to another drive?
A: You can move both elements to another drive. It is actually best practises to have them on separate physical drives/arrays for performance and redundancy reasons. To move the files, follow the instructions in this Technet article

Q: Can other things take up a lot of space?
A: A very common cause of rapidly reducing disk space is Shadow Copies. You should investigate whether Shadow copies is enabled and if it is, reduce the amount of space available to it.
Also don't forget to look at old user profiles, temp files and temporary internet files which can also take up a lot of space, particularly on newly built servers where you could have a lot of remains from application installations.