Exchange 2013 DAG Seeding Error: An address incompatible with the requested protocol was used

Recently this issue came up in our test lab whilst updating to and testing Exchange 2013 CU3.

"The mailbox database copy 'DATABASE\SERVER has failed to update from server . Do you want to clean up that

update request now? Seeding cannot be requested for the same database copy until the failed request has been cleaned up

by the server, which should automatically happen within 15 minutes.

[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [?] Help (default is "Y"):"

Prompting Yes then presented this error:

"The seeding operation failed. Error: An error occurred while performing the seed operation. Error: An error occurred

while communicating with server 'SERVER'. Error: An address incompatible with the requested protocol was used

[Database: DATABASE, Server: SERVER.FQDN.COM]

    + CategoryInfo          : InvalidOperation: (:) [Update-MailboxDatabaseCopy], SeedInProgressException

    + FullyQualifiedErrorId : [Server=SERVER,RequestId=6e64fbd7-a753-453d-805c-704363ec7495,TimeStamp=03/01/201

   4 11:34:54] A35E0624,Microsoft.Exchange.Management.SystemConfigurationTasks.UpdateDatabaseCopy

    + PSComputerName        : server.fqdn.com"

Additionally this was logged in Event Viewer:

Subsequent retries failed to successfully seed the database.

However, once the Replication Service was restarted on the DAG member this issue was resolved and seeding was succesful.

Test-ReplicationHealth was not run to see if this would have given in any insight to the offending DAG member. It would be interesting to see if this would have provided anymore useful information. You can find the Technet article on the Exchange cmdlet here.

Take care,

Oliver Moazzezi - MVP Exchange Server

@OliverMoazzezi

Source Side Operation Failed - Exchange 2010 DAG

I came across this today. I have no idea why the database failed to replicate correctly, especially as it was a new database with no users on it. However fixing it was fairly trivial.

The issue:

Once I was back in the console I actually couldn't see the suspended and failed copy without having to restart EMC (a refresh would not work) however EMS did infact show it:

So via Powershell I simply ran the Resume-MailboxDatabaseCopy and this fixed the issue.


Testing via EMC I noticed once it was restarted I was able to see the failed and suspended database so could have performed it via the UI if I needed too.

Root cause analysis was not done as I was unable to replicate the issue. Hopefully this article will help any other Admins with the issue that may not be quite as quick at fixing it.

Take Care


Oliver Moazzezi MVP - Exchange Server