Exchange Log Truncation Failure in a DAG


Today I visited a client who had noticed that no log files had ever been removed after any backup within Exchange 2010 SP1. It was fortuitous that they had enough log disk space for about eight months of log generations. The disadvantage was that we were four months into this time period, so it was a ticking clock, and that the nightly incremental backups were taking longer and longer.

They were getting the following error in their backup datacentre:

image

Unable to communicate with the Microsoft Exchange Information Store service to coordinate log truncation for database ‘name’ due to an RPC communication failure. Error 3355379671 Extended Error: 0 and Event ID 2136 for the MSExchangeRepl service in the Application event log.

What the error does not clearly say is that the Microsoft Exchange Replication service (MSExchangeRepl) on the server in the DR site (a passive node in the DAG) needs to communicate via RPC to the Microsoft Exchange Information Store service on the server holding the active node of the database.

In the case of my client, the Exchange team is not the same people as the network team or indeed the firewall team, and these teams are in different countries. In the case of the network for this client, the Replication network for the DAG had been opened to allow RPC traffic, but the MAPI (Client) network had not.

When Exchange in the DR site needed to check which logs it could truncate (a process it performs every 15 minutes), it needs to talk to the Microsoft Exchange Information Store service on the server holding the active copy of the database, and name resolution was returning (as expected) the IP address of the server on the MAPI/Client network. This network blocked RPC between servers and so (as one of the many issues they now attribute to this problem) logs could not be truncated and Event ID 2136 was posted once per database on the passive node in the DR site. The two servers in the primary site could RPC each other, so this log is not repeated in the primary site.

To solve this log growth problem without waiting for a response from the firewall team, we added a record to the hosts file on the passive server to override DNS name resolution, and within 15 minutes 2TB of log files instantly disappeared on all servers. Name resolution was reverted to DNS and the firewall team contacted.


Posted

in

, , , , , ,

by

Tags:

Comments

4 responses to “Exchange Log Truncation Failure in a DAG”

  1. Charles Derber avatar

    I wonder Ex-Admin did not monitor the growth of the log files on DR noes….???

  2. Brian Reid avatar

    No – they monitored it. It would not clear the logs because RPC access had been blocked to the primary site.

  3. JB avatar
    JB

    Could this be the same for a 2019 server that is setup in a DAG.

    Unable to communicate with the Microsoft Exchange Information Store service to coordinate log truncation for database ‘ArchDB01\SERVER01’ due to an RPC communication failure. Error: 3355379671

    Also, this message.

    Extended error: Failed to open a log truncation context to source server ‘server02.domain.com’. Hresult: 0xc7ff07d7. Error: Failed to open a log truncation context because the Microsoft Exchange Information Store service is not running.

    And this message.

    The log copier was unable to communicate with server ‘server02.domain.com’. The copy of database ‘MailDB01\SERVER01’ is in a disconnected state. The communication error was: An error occurred while communicating with server ‘server02’. Error: Unable to write data to the transport connection: An established connection was aborted by the software in your host machine. The copier will automatically retry after a short delay.

    1. Brian Reid avatar

      Yes. They have the same underlying database replication technology, of course with many years of updates and improvements. This issue would be true for any version of Exchange Server from 2007 and later.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.