Our Exchange 2003 is backed up nightly. However, although the tlogs are truncated, the log generation number is not reset - it continues to increment. Event 514 now warns of impending doom with the tlogs running out of available generation numbers. I have dismounted the databases cleanly but cannot "delete" all the tlogs. I have moved the tlogs to another location and still the same issue. I have tried the ExTRA (troubleshooting assistant) but the task option to resolve the log generation issue is not available. ExTRA does not seem to function with Exchange 2010 (we are currently testing Exchange 2010 for deployment in a co-existence environment). Any assistance would be most appreciated.

Exchange 2010 (and 2007 for that matter) has longer log file names, three extra characters I believe it is, which provides for 4096 times as many log files as Exchange 2003, so it is not anticipated that this problem will occur. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Desertonian" wrote in message news:7353412c-bc5c-4910-b20d-27f611188948... Our Exchange 2003 is backed up nightly. However, although the tlogs are truncated, the log generation number is not reset - it continues to increment. Event 514 now warns of impending doom with the tlogs running out of available generation numbers. I have dismounted the databases cleanly but cannot "delete" all the tlogs. I have moved the tlogs to another location and still the same issue. I have tried the ExTRA (troubleshooting assistant) but the task option to resolve the log generation issue is not available. ExTRA does not seem to function with Exchange 2010 (we are currently testing Exchange 2010 for deployment in a co-existence environment). Any assistance would be most appreciated.Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Great Ed, but this helps me how?

Hi There, Using EXTRA is one option and easy one. The second option is to perform a full backup of the storage group and dismount the store manually, goto the command prompt and ensure the database is in clean shutdown state by running eseutil /mh <database name>. Ensure the database is State:Clean shutdown . Once you confirm this, you may move all the logs related to that storage group to a temp location and mount the database again. This will start the new log generation numbering. Hope this will help you! Regards, Surjeet

Hey Surjeet, Have been through the process you describe without success. After confirming clean shutdown state for the 4 databases in this storage group I am not able to move the E00tmp.log or the tmp.edb files. the system complains that "an application is still using these files" and so they cannot be moved. I am concerned that if I stop the Information Store Service and Attendant Service and then move these files that I will not be able to mount the databases thereafter. Also, as mentioned previously, I used the ExTRA (Database Recovery Management); the only options available to me are (1) Analyze log drive space, (2) Show database related event logs, (3)Verify database and transaction log files. Am I missing something here? No option to resolve the log generation number is available to me. Help....

http://msexchangeteam.com/archive/2008/07/23/449339.aspx Transaction log file names running out http://support.microsoft.com/kb/830408 Check any services that may be holding open the store: A/V, Backup agents etc... http://technet.microsoft.com/en-us/library/aa998701(EXCHG.80).aspx

On Sun, 30 May 2010 09:11:06 +0000, Desertonian wrote: >Have been through the process you describe without success. After confirming clean shutdown state for the 4 databases in this storage group I am not able to move the E00tmp.log or the tmp.edb files. the system complains that "an application is still using these files" and so they cannot be moved. I am concerned that if I stop the Information Store Service and Attendant Service and then move these files that I will not be able to mount the databases thereafter. Also, as mentioned previously, I used the ExTRA (Database Recovery Management); the only options available to me are (1) Analyze log drive space, (2) Show database related event logs, (3)Verify database and transaction log files. Am I missing something here? No option to resolve the log generation number is available to me. Shut down the Information Store service. Then remove the remaining log files and checkcpoint file. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

It helps you because you should not have the problem with Exchange 2010 and that is what I thought what you were asking. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Desertonian" wrote in message news:c70a60e5-f4bc-480a-b88a-0733bab21450... Great Ed, but this helps me how?Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Hi Desertonian, As Rich mentioned please stop the Exchange Information store service and try it again. Yes i was able to perfrom this with success. Please let us know! Cheers, Surjeet

Ed, Apologies for the snappy retort. Rich / Surjeet, Thanks for the advice. I will confirm all is well once scheduled downtime has passed (this Friday). Thanks to everyone for their participative support.

Ed, Apologies for the snappy retort. Rich / Surjeet, Thanks for the advice. I will confirm all is well once scheduled downtime has passed (this Friday). Thanks to everyone for their participative support.

No problem. Hope you get your problem resolved. -- Ed Crowley MVP "There are seldom good technological solutions to behavioral problems." . "Desertonian" wrote in message news:7b05ce22-767e-42f7-8589-d48416487123... Ed, Apologies for the snappy retort. Rich / Surjeet, Thanks for the advice. I will confirm all is well once scheduled downtime has passed (this Friday). Thanks to everyone for their participative support. Ed Crowley MVP "There are seldom good technological solutions to behavioral problems."

Try running the script below to display the log sequence numbers left on the E2K3 storage groups. You might want to tweak the selection of the non-exchange 2007 servers to narrow down to only those servers with log files. This script saved us when we had an Event 514 during one of our mantenance windows, running this told me that we had a log sequence issue on a server. This doesn't 'solve' the problem but it will help you plan for the eventuallity that the log sequence numbers need to be reset on E2K3. # .\List-MostRecentLOGFileNameforE2K3.ps1 # # Tired of keeping track of Log File Sequence numbers and when you are about to run out on servers. # This script will explore all the E2K3 Exchagne Servers in the organization (Or a selection of them) # It will then map the Log File location and pull the most recent stored LOG file. # It will then parse out the Log Sequence Number and present the output showing Server / SG LastLog.log and the number of log # file sequence numbers remaining to reach the limit of 1048559 ( the X'FFFEF' log sequence number) # # Phil Braniff 8/18/2009 # $E2K3SG = Get-ExchangeServer | where {$_.ServerRole -eq "None"} | Sort | Get-StorageGroup Write-Host "Server Storage Group : Last Log File - Message" foreach ($SG in $E2K3SG) { [string] $SGServer = $SG.ServerName [string] $SGName = $SG.Name [string] $LinkPath = $SG.LogFolderPath $LinkPath = $LinkPath.Replace(":","$") [string] $LogContent = "\\$SGServer\$LinkPath" $gcPath = $LogContent+"\E*.log" $LastLogFile = Get-ChildItem -path $gcPath | where{$_.Name -NotLike "*tmp.log"} | Select-object -last 1 [string] $LastLogName = $LastLogFile.Name $HexString = $($LastLogName.substring(3,5)) # Log file name format "EXXLLLLL.log" the XX=is the SG index LLLLL=Log Sequence HEX string. [string] $logsLeft = $HexString | % { 1048559 - [Convert]::ToInt32($_,16)} write-host "$($SGServer.PadRight(15)) $($SGName.PadRight(15)) : $LastLogName - This leaves $($logsLeft.PadLeft(7)) log sequence numbers remaining." } Phil Braniff

Thank you Gentlemen for your constructive input. After taking the IS service offline on the cluster, I was able to remove the logs files. Problem solved.