Exchange 2016 Log Truncation Not Happening

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.

I figured it out.

RR requires credentials to do the truncation. Domain Admin credentials won't cut it. It pertains to Exchange"roles".

NOW I have to peel back that friggin onion to try to find an account that will work.

I made sure the user account I am using for backups is a member of the Organization Management security group. It was not, so I added it to the OM group. Tried to get Rapid Recovery to truncate and no go. It still will not authenticate.

Hi Tim,

I did as you said, checked the Event Viewer for 224 & 225 in MSExchange Management section of the logs, filtered on 224 or 225 and found nothing.

No VSS errors.

I am sure this is an authentication error. The Rapid Recovery server is NOT a member of the domain. I have tried to authenticate with several accounts that are members of the Organization Management security group with no success.

This is what I get:

Try putting your domain name in front of the user account. Example: domain\appassure.replay

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?)

Yes, I did that too. :-(

I tried to use <domain>\<user>, no luck.

I used <domain>\<domain admin> to connect to the Exchange server for the initial backup. That works fine.

Have you restarted the Rapid Recovery core service or server since changing the permissions of the user account you used to protect the Exchange server? Those credentials should now have the rights to be able to view the Exchange data and run the log truncation job. I'm wondering if for some reason the permissions update just isn't being recognized. A reboot might help break things loose...

Hi Tim,

I have not done a restart of the services..... I can do that now! I'll let you know in a few minutes.

--Jon