Exchange 2010, Windows Server Backup does not Truncate Logs

So, you have successfully built a new Standalone Exchange 2010 server on Windows Server 2008 R2 Enterprise.  Everything is in working order and humming along nicely.  Of course humming along nicely does mean you have transaction logs piling up, slowly eating away space.  If you did an optimal install the logs and databases are on a larger volume separate from your C drive, so not a big worry right away, but it eventually will be.  Fortunately one of the other things you must do with an Exchange server is make frequent backups, which indecently will truncate all those log files every time it completes, thus solving your pile of files.

Then you discover that the backups, while claiming to be complete, have not truncated any log files.


I fought with this myself for several weeks.  I’ve been through every forum out there on the subject and made little headway until something finally clicked.  So, I am going to detail what I did here so that anyone else out there that might stumble upon this can find closure as well.


First.  There are several things that can cause this, and my situation was specific.  I am going to start by detailing some specific setup items and symptoms.  If your situation matches what I list then this will most likely work.  If not then I would move on and keep searching.

As always use these instructions at your own risk.

For this solution to work the following must be occurring:

1. When running Windows Server Backup, either scheduled or once, you are backing up each volume that contains exchange db and log files.  Other volumes or items do not matter, you must backup the whole volume(s) that contain the db and log files.

2. When setting up the backup you went to Advanced and the VS Options tab and set it to “Full” backup.  Copy will not truncate files.  The advanced button is on the same screen you added the volumes to backup.

3. When the backup is run once, you never see the top status say “Running consistency checks on the application Exchange”

4. When the backup completes, Windows Server Backup says it is successful.  But in Event Viewer you get an event ID 9782 in MSExchangeIS for each database being backed up, plus one event ID 2007 for ESE.

5. If you look in Services you have “Microsoft Exchange Server Extension for Windows Server Backup”  and it is not started.  If you do start it then run a backup you will find it is no longer started once the backup completes.  Even if you set it to automatic.

6. If you run the command “vssadmin list writers” you do have “Exchange VSS Writer” listed, and it reports No Errors.

7. You have disabled or uninstalled any Anti-Virus programs on the server

8. You are not either running out of space on any of the drives (especially the location you are backing up to) or finding any drive errors in event viewer.


If the items I have listed above apply to you, then your Exchange Server Extension for Windows Server Backup is most likely not registered properly.  This requires some registry editing.

As always follow these instructions at your own risk.  You can severely damage your system when changing things in the registry.


There are 3 keys in question, so first check to see if they even exists.

In regedit.exe go to HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion

There should be a key under CurrentVersion named WindowsServerBackup, under that is Application Support, and under that is {WriterGUID}  all of which I will explain.  If you are missing any of those 3 keys, or they are incorrect it is most likely the problem.

Some good information on Windows Server Backup API Keys

The full path is HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\WindowsServerBackup\Application Support\{WriterGUID}

WindowsServerBackup and Application Support are just keys, no sub strings or dwords, though if you already have them they might have some items in them, so don’t mess with those. The important part is that WriterGUID must be created and filled in.  The GUID is the Exchange VSS Writer GUID that is listed when you run the command VSSadmin List Writers.  Put that value in between the braces for the key.  EX: {CE4EF7DC-18CE-4A11-B4C9-D7A668637D1B}.  Note that your value will be different so do not use that example.

Once you key is done you must make two items underneath it.

1. Create a subkey with the name Application Identifier and type REG_SZ.  The value I used was Exchange.

2. Create a subkey with the name CLSID and type REG_SZ.  according to Microsoft in the linked to article above the value “should be the GUID of the COM coclass that implements the add-in.”  I have no idea how to find this, but every example I have come across in forums where people have posted a script they got from Microsoft had the same CLSID value.  Which is {D8A2E312-3B17-4293-B71E-CD72A7C04BF3}.  This is what I used and it worked, so it will most likely work in any exchange 2010/Server 2008 r2 environment.

Once those keys have been created I rebooted the server just for good measure.

Then I manually started the Windows Server Backup job.  Once started it reported it was “Running consistency checks on the application Exchange”.  If you get this then the backup will be successful, and the log files will truncate upon completion.

Be aware however that if you have a lot of log files the consistency check can take a very long time.  In my case I had not noticed the problem for a long time and had a good 500GB of log files.  The consistency check took about 7 days to complete.  So its generally good to notice and solve this early on.  If you do have a lot of log files the safest thing to do is to just let the consistency check run its course.

1 comment to Exchange 2010, Windows Server Backup does not Truncate Logs

Leave a Reply




You can use these HTML tags

<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>