Quest has been named as an ASP "Ten Best Web Support Sites" award winner. Learn more.
If Exchange logs are not truncating please follow these steps:
If there are no errors, then please review the following information regarding log truncation as it may not be necessary for Exchange to truncate logs at the time the job was run. According to Microsoft (http://technet.microsoft.com/en-us/library/dd335158(v=exchg.150).aspx_): Log truncation works the same in Exchange 2013 as it did in Exchange 2010. Truncation behavior is determined by the replay lag time and truncation lag time settings for the copy.
The following criteria must be met for a database copy’s log file to be truncated when lag settings are left at their default values of 0 (disabled):
The following criteria must be met for truncation to occur for a lagged database copy:
To find the checkpoint time for a database please follow the steps in this article -http://blogs.technet.com/b/timmcmic/archive/2012/03/12/exchange-2010-log-truncation-and-checkpoint-at-log-creation-in-a-database-availability-group.aspx
Hence if there are no logs that meet the above criteria, then log truncation will not be performed. To verify that Exchange log truncation has been called and attempted to run, review the Application Log for ESE Event ID 224 and 225. Event 224 indicates that logs are being deleted and denotes the associated database. Event 225 indicates that there were no logs available for truncation.
It's also possible to verify Exchange 2010 logs truncation functionality outside of AppAssure/Rapid Recovery using the following VSStester script: https://blogs.technet.microsoft.com/exchange/2013/04/29/troubleshoot-your-exchange-2010-database-backup-functionality-with-vsstester-script/