The replay queue was continuously played down to zero despite of having the ReplayLagTime set to 3 and a half days.
ContentIndexState was in status Healthy instead of AutoSuspended.

The following screenshot shows states of  lagged copies on the server where only lagged copies reside. The affected ones have a replay queue count zero or one :

We have for each mailbox database 2 copies and a lagged mailbox database copy in place. According to that the ActivationPreference for each lagged mailbox database copy is 4.
But the mentioned lagged copies appeared to behave like normal copies. ActivationSuspended was set to $true since they were born to be lagged copies.

Not every passive copy on the same server ( this server hosts only lagged copies ) showed this behaviour and all parameters for the affected lagged copies were identical with each passive copy where it worked.

My colleague created a new mailbox database that day with 2 copies and a lagged mailbox database copy. After the new database was in place the lagged copy was not lagging as well. This time the passive copy was hosted on another server.

It turns out that all mailbox databases where the lagged mailbox database copy does not work correctly have a normal copy on the same other server. Next step was to check the state of the DatabaseCopyAutoActivationPolicy of this server.

And yeah , this was it :

The DatabaseCopyAutoActivationPolicy was set to Blocked. We switched it to unrestricted and stayed patient. After some hours the lagged mailbox database copy started replay logs

As we understand :

Exchange assumes you have a mounted mailbox database, 2 copies and a lagged mailbox database copy in place. When the replication does not see one of the copies it will treat the next available database copy [ in this case the lagged copy ] as the second copy and will play down the replay queue utilizing this copy as a healthy normal copy.

As soon the original 2nd copy becomes visible [ setting the DatabaseCopyAutoActivationPolicy state to unrestricted ] the assumed default set is complete ( with min. 2 existing normal copies ) the lagged copy will be treated as lagged mailbox database copy again.

I think we left one server in state blocked after our maintenance. Luckily it got noticed straight away.

It was not a big task to solve the problem with switching the activation policy to unrestricted , but it took time to get a clue where the culprit was in the chain.
Hope you can save this time with this post.

Have a nice day

Got an Healthy And Upgrading state on your passive copy ? See what it means :

ContentIndexState Healthy And Upgrading

The post Lagged mailbox database copy not lagging appeared first on Webbanshee.