blog

The Microsoft Exchange Replication service does not appear to be running on Exchange Server

When moving a mailbox database inside a DAG, one of the more confusing errors is:

The Microsoft Exchange Replication service does not appear to be running on "PassiveMailboxServer". Make sure that the server is operating, and that the services can be queried remotely.

It sounds like a simple service failure, but that is not always the real cause.

Why this message is misleading

In our case the Microsoft Exchange Replication service was running and the server still reported as healthy. Even so, every database move failed with the same message.

That is why this error deserves broader troubleshooting than just restarting the service.

Example error

Error Message

The Microsoft Exchange Replication service does not appear to be running on "MBX2". Make sure that the server is operating, and that the services can be queried remotely.

Exchange Management Shell command attempted: **Move-ActiveMailboxDatabase -Identity ‘MDB01’ -ActivateOnServer ‘MBX2’ -MountDialOverride ‘None’

Activate Database Copy Error

What fixed it in our environment

The issue turned out to be broken or missing group membership. Adding the following groups back to the local Administrators group on the Exchange servers resolved it:

  • Organization Management
  • Exchange Trusted Subsystem

In our case it was clearly broken because the SIDs were not resolving correctly.

OrganizationManagementMissing

What to verify

If you hit this error and the service itself is running, check:

  • whether Exchange Trusted Subsystem membership is intact
  • whether Organization Management is resolving correctly
  • whether broken SID history or orphaned memberships are showing up instead of valid groups
  • whether the administrative account is actually in the expected Exchange admin role group

Important scope note

This was a fix for our environment, not a claim that every replication-service error has the same root cause. DAG networking, witness configuration, name resolution, cluster state, and permissions can all produce similarly misleading symptoms. The important takeaway is that the service status alone may not tell the whole story.