Exchange 2016 Log Truncation Not Happening

Question

Exchange 2016 on top of Server 2012 R2 deployed in December of 2016
Rapid Recovery Version: 6.1.1.137

Nightly jobs:

Rollup YES
Recovery Point Integrity Checks NO
Checksum of Exchange Databases NO
Log Truncation YES
Enable automatic mountability check NO

RR has NEVER truncated logs, but backups are going hourly. I have about a BILLION log files on the Exchange server. We could call it a "log jam" :-)

Tim Seymour · Answer

Are you seeing one backup run per day that says "with log truncation" for that Exchange server? If so, is it completing successfully. If it is, that means that Rapid Recovery has done it's job of backing up the server and notifying Exchange that it has been properly backed up and can go ahead and truncate it's logs. If Exchange isn't truncating the logs, then you have to start looking for Exchange errors that would cause log truncation not to work. 
 
Check to see if Exchange is even trying to truncate. 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. 
 
Also check for errors related to the Exchange VSS writer or the Replica writer. Usually when we see this sort of problem, it's because something in Exchange is not working properly and so even though RR is doing it's job correctly, Exchange can't truncate because of the errors.

Tudor.Popescu · Answer

Hi JRuehle:

You are correct in that as long as you cannot log in with your credentials you won't be able to do the log truncation.

I would suggest using the format of <domain>\<user> and try again. In most cases you should be able to log in without any problems.

However, I have seen cases where it was impossible to connect directly to a computer in a domain from a machine outside the domain. that was caused by some very peculiar group policies. It should not be your case as you were able to protect the Exchange server -- thus your credentials were accepted (have you used local credentials for the Exchange Server when you protected it?)

Tudor.Popescu · Answer

I see two options -- add the Exchange User you are using to connect to the Domain Admins group (it makes sense to make sure that no special characters such as ".","$","-" are in the username). 
The second -- which is not that simple is to use the posttransfer.ps1 script (located in c:\Programdata\Apprecovery\scripts when exists) and force a log truncation from there. 
The content of the script should be 
 
diskshadow -s c:\Programdata\Apprecovery\scripts\script.txt 
 
where script.txt is a diskshadow script, located in the same directory. 
The script.txt content should be something like: 
#DiskShadow script file 
set context volatile 
set verbose on 
 
add volume c: # whatever Exchange Volume 
add volume d: # whatever another Exchange Volume and so on 
 
create 
end backup 
#End of script 
 
You may need to create the c:\Programdata\Apprecovery\scripts folder and the posttransferscript.ps1 file and run set-executionpolicy remotesigned from an elevated PowerShell command prompt to make sure that the script is allowed to run. 
Give it a try!