Exchange 2007 logs not flushed after successful backup with Backup Exex 12.5

how are you running exchange backups ? are you selecting LCR drive to backup the mailbox db's ? if yes, that is wrong.

You'll have to select the active server and select information store.

Firstly, to flush logs you have to run Online backup and not Offline or VSS ..
Secondly, apart from LCR do you also have SCR or something else ?? maybe in the past tried and left it ??
You are taking back of the Original DB or LCR DB ??
How may Storage Groups and Stores do you have ??

I am not backing up the LCR.  I am doing an online backup of the live Information Store.  

I have used BE for years with Exchange so I am familiar with the settings.  In the link I provided in my original post, the poster stated the problem went away in his environment when they turned off LCR.  They were using BE 11d.  I figured this would not be an issue with BE 12.5, but maybe it still is?

can you provide us with the output of:
Get-StorageGroupCopyStatus

You may need to reseed the LCR...
http://exchangeserverpro.com/exchange-server-2007-replication-problems-can-lead-to-backup-issues

Ideally when you try Backup and you have "Continous Replication" enabled .... Backup cannot purge log files till the replication services inform the ESE engine about the Log copy and replayed to the Target DB .....

You can try few additional things like ... Restart the Replication service ... Is there some other DB as well, if so enable LCR and try backup on it ....

Ours was doing the EXACT SAME THING. I have been on the phone with Symantec and I always get the same exact answers "Backup Exec just sends the command to truncate, it is then up to Windows/Microsoft to finish the truncation process". So, to test this theory we did an NTBackup, since our Exch 2007 is running on Server 2003 x64. It did NOT truncate again. So, if Microsoft could not truncate it then for sure Symantec would not be able to. We ended up rebooting the passive nodes and then failing over. This seemed to fix the issue....for a few weeks and then it happened again. I dont know that we have ever found a definitive fix for it except for doing this. Somehow the failovers finished the truncation process = Microsoft issue. It has something to do with the "writer status" (which all the VSS writers were OK).

So, before I dig too much further in all this, is it likely there is no definitive fix, and I will just have to continue manually purging files until a formal "fix" comes from Symantec and/or Microsoft?

Reseed and then you won't have to do manual fixes

@MegaNuk3:

Let me look at your link and report back.  Thanks.

@MegaNuk3:

Per instructions to reseed from the link you provided:

[PS] C:\>Suspend-StorageGroupCopy "SERVER1\First Storage Group" -StandbyMachine
SERVER2

[PS] C:\>Update-StorageGroupCopy "SERVER1\First Storage Group" -StandbyMachine
SERVER2 -DeleteExistingFiles

[PS] C:\>Resume-StorageGroupCopy "SERVER1\First Storage Group" -StandbyMachine
SERVER2

I want to try this, but I am not running a "standby" server.  Therefore, I do not know what to input in place of "server2" in the '-StandbyMachine' portion of the script.

http://technet.microsoft.com/en-us/library/aa995973(EXCHG.80).aspx

@MegaNuk3:

If I follow the steps in the Technet article you supplied, will I be taking my Exchange server offline when I dismount and remount?

I really liked the PowerShell instructions, I just need to know if I can run it without having a standby server.

@MegaNuk3:

Ok, thanks for your last post.  I still need to know if this process will take my server offline when I perform the PowerShell scripts.  If it is only down for a few minutes, that is ok, otherwise I need to schedule when I take it offline.

It would be great to hear if this won't affect the online status of my server at all, and will only affect the LCR portion, so my server can continue to operation while I perform the PS script commands.

Let me know.

It just affects the passive (LCR) copy of the database

The production or Online server is nerver affected ....
What this exactly will do is ... Remove the copy of the Secondary DB and remake .... sono downtime or production affect will take place

Ok, I am trying this now and will report back.

After I complete the following on all my storage groups (I have three separate ones):

1.) Suspend-StorageGroupCopy -Identity:<Server>\<StorageGroupName> -SuspendComment:"Seeding"
2.) Update-StorageGroupCopy -Identity:<Server>\<StorageGroupName> -DeleteExistingFiles
3.) Get-StorageGroupCopyStatus to verify it is all working and playing in the logs

The final step I do is re-enable seeding on each storage group by typing the following, correct?

4.) Update-StorageGroupCopy -Identity:<Server>\<StorageGroupName>

Let me know and thanks.

Step 2 will do it

@MegaNuk3:

Ok, so step two will not only delete the current files, it will restart the seeding process?

Forgive all my questioning and apprehension, I have never run these commands before and I am over-protective of my Exchange server.

Currently the PS script from step two is running and states "Seeding Mailbox Database".  It also shows a progress bar with the word "Working" above it.  

I see a "temp-seeding" folder was created in the "Exchange LCR" folder.  I assume this temporary seed will be converted to the live seed once the step two PS script completes?

I still need to run this on my other two storage groups and will continue to report back.

Yep, it deletes the existing files and reseeds the Edb

Yep, the temp seed should become live.

Get-storagegroupcopystatus should show you how many log files are to be played  in etc.

Ok, the scripts finished successfully on my first storage group.  Running it now on the others.

Has the 1st one finished playing in all the logs etc?

I have to wait until this next storage group is done before I can run another PS command.  PS is currently busy running the current script.  I will run 'Get-StorageGroupCopyStatus' as soon as this one completes.

I have four storage groups:

Admin Employees Storage Group
Line Employees Storage Group
Public Folders Storage Group
Special Exceptions

So far I have done Admin and Line.  When I run 'Get-StorageCopyStatus' it currently says that Line Employees Storage Group has a 'ReplayQueueLength' of 207.  Everything else for all other columns of all other storage groups are 'zero'.

UPDATE:  I just ran 'Get-StorageCopyStatus' again and now all columns are 'zero'.  I presume that is good?

@MegaNuk3:

I have now completed the scripts on all four storage groups.  When running 'Get-StorageCopyStatus' everything comes back as 'healthy' and 'zero'.

What do I need to do next?

Run a full backup tonight and hopefully the logs will get purged for a change.

@MegaNuk3:

I run nightly full backups.  I will report back and let you know if things reset correctly.  If they do, all I should see are *.log files dated after the backup completes, correct?

Yep, only the logs after the backup should remain

Ok, great news!  My logs all reset after my successful backup last night!  The logs for each storage group purged correctly in my Symantec Backup Exec 12.5 and I only have logs listed for after the backup completion time.

To summarize exactly what I did, these are the steps I performed on the server in the PowerShell console:

1.) Suspend-StorageGroupCopy -Identity:<Server>\<StorageGroupName> -SuspendComment:"Seeding"
2.) Update-StorageGroupCopy -Identity:<Server>\<StorageGroupName> -DeleteExistingFiles

Step two not only deletes the files, it restarts the seeding process with new files.  Once each storage group had completed the re-seed process, I ran 'Get-StorageCopyStatus' in PowerShell to verify each storage group's status is "healthy" and all replay queue lengths were "0".

Thank you again for everyone's assistance with this problem, and providing a solution.

Glad to hear it worked.

remember if you defrag or repair any of the production databases then you need to reseed the LCR copy.

Once again, quick and helpful responses.  Thanks to everyone who helped.  I hope this solution will be able to help others as it helped me.

MegaNuk3 stated: "remember if you defrag or repair any of the production databases then you need to reseed the LCR copy."

Thanks for this tip.

It's kind of mentioned in the technet article http://technet.microsoft.com/en-us/library/aa995973(EXCHG.80).aspx :
"Seeding is required under the following conditions:

When the system has detected a corrupted log file that cannot be replayed into the database copy.

After an offline defragmentation of the production database occurs.

After a page scrubbing of a database on the active node occurs, and you want to propagate the changes to the passive node."

Basically anthing that changes the database signature means you have to reseed (or a corrupt shipped log file)