Exchange Management Shell to Fix Exchange 2013 CopyQueue Backlogs, No it’s NOT the Network!

When your Exchange 2013 environment is running smoothly everyone is happy, but there may be times when it is not. Recently I worked on an issue in where my Exchange On-Premises CopyQueue Length was growing rapidly. Now typically this issue is related to network latencies. This can quickly be ruled out by copying data between the two Exchange Database Availability Group (DAG) servers where the delay is being seen. If data is moving slow then there is a networking issue that needs to be resolved. When I learned this wasn’t the case, I engaged Microsoft to learn more about what might be going on. The queues were growing extremely fast causing my environment to lose all failover capabilities. Yes, when your copy queues are backed up the databases will not failover to its other database copies. Big problem if there is a true disaster. The other side effect to this issue is uncontrollable Exchange log file growth and we can use exchange management shell to check on and resolve the issue.

Exchange Management Shell to the Rescue!

So how can you resolve this issue if there is not any other explanation?

Start by logging into the Exchange DAG server with the copyqueue backlog
Open Exchange Management Shell
Run the following command replacing the DatabaseNameHere with the Exchange Database Name having issues

1..5 | %{Get-StoreUsageStatistics -Database DatabaseNameHere | Sort-Object LogRecordBytes – desc | Select-Object -First 20 | ft DigestCategory, guid, LogRecordBytes, *time -auto ; sleep 20}

Note: This command with monitor user connections that may be experiencing a high number of connections. This will run on an interval that will allow you to monitor the active connections by GUID. If a user is continually having a high level of connections then their GUID will always be on top of the list. See example below of what the output would look like.

Unravelling the Mystery

Now that we know we have some high user connections and who at their GUID’s are we need to find out who the user’s are. This can be done with the following steps:

In Exchange Management Shell type the following, but replace GUID with the real GUID as seen above
get-mailbox GUID
Press enter to learn who the user is

Fixing the Issue, the final step

So, the final step to resolving this issue is to simply move the user mailbox to another Exchange database. If there are multiple user mailboxes that are part of this issue move them both. Moving a mailbox is a transparent activity to the user and will not impact their ability to do their job within Outlook.

Continue to monitor the queues until they are clear and monitor the log files to ensure that they are no longer increasing at a rate that is faster than expected for your environment.

Cheers!