Current builds of Exchange Server 2013 and Exchange 2016 have a behavior in the Get-MailboxDatabaseCopy cmdlet that may cause an incorrect value to be returned for the activation preference of a database copy.
The bug is harmless to the operation of the database availability group (it will still use the correct activation preference values during BCSS), but if you’re relying on Get-MailboxDatabaseCopy to return those values in a script, or just during general admin, then you may be misled by the results.
Here’s an example. In this case I’ve used Set-MailboxDatabaseCopy to set each copy of the database DB02 to an activation preference of 4.
1 2 3 4 | [PS] C:\>Set-MailboxDatabaseCopy DB02MELEX1 -ActivationPreference 4 [PS] C:\>Set-MailboxDatabaseCopy DB02MELEX2 -ActivationPreference 4 [PS] C:\>Set-MailboxDatabaseCopy DB02SYDEX1 -ActivationPreference 4 [PS] C:\>Set-MailboxDatabaseCopy DB02SYDEX2 -ActivationPreference 4 |
There are no warnings or other indications that it isn’t working, and Get-MailboxDatabaseCopyStatus shows me a result like this.
1 2 3 4 5 6 7 8 | [PS] C:\>Get-MailboxDatabaseCopyStatus DB02 | select name,status,activationpreference | ft -auto Name Status ActivationPreference ---- ------ -------------------- DB02MELEX1 Healthy 4 DB02MELEX2 Healthy 4 DB02SYDEX2 Mounted 4 DB02SYDEX1 Healthy 4 |
Activation preference values are unique for each copy of a database, you can’t have an AP of 4 for every copy. And in this case I don’t, it is just the way the cmdlet works, because it queries the server instead of Active Directory (which is the authoritative source).
If I use Get-MailboxDatabase to query the AP instead I see the correct values.
1 2 3 4 5 6 7 8 | [PS] C:\>Get-MailboxDatabase DB02 | Select -expandproperty:ActivationPreference Key Value --- ----- SYDEX2 1 MELEX1 2 MELEX2 3 SYDEX1 4 |
And if I use the RedistributeActiveDatabases.ps1 script to rebalance the DAG it uses the correct AP values in doing so (truncated output here just to demonstrate the point).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 | ----------------------- Starting Database Moves ----------------------- Considering move of 'DB02' from 'SYDEX2' (AP = 3) to 'MELEX1' (AP = 1)... Database 'DB02' successfully moved from 'SYDEX2' to 'melex1'. ServerName ActiveDbs PassiveDbs ---------- --------- ---------- MELEX1 2 2 MELEX2 1 3 SYDEX1 1 3 SYDEX2 0 4 `n ---------------- Summary of Moves ---------------- Successfully moved : 1 Moved to less preferred : 0 Failed to move : 0 Not moved : 3 DbName : DB02 ActiveOnPreferenceAtStart : 3 ActiveServerAtStart : SYDEX2 ActiveOnPreferenceAtEnd : 1 ActiveServerAtEnd : melex1 IsOnMostPreferredCopy : True MoveStatus : MoveSucceeded |
When I originally wrote this article, I referred to this behavior as a bug, because that’s what was confirmed to me. Since then, a Microsoft engineer has clarified why this behavior is expected, and is not considered a bug. It isn’t a serious issue, as long as you’re aware of it and use the Get-MailboxDatabase cmdlet to verify your AP values are correct.
Updated: 22nd June, 2016
Hi Paul,
The DAG Health report is reporting wrong databases activation preferences.
Would it be because of this. I verified the AP are correct in Get-MailboxDatabase and also in the EAC but wrong in the Get-MailboxDatabaseCopyStatus cmdlet.
Thanks
Yep. Hopefully the bug is fixed in CU9.
That explains why the Lagged DB Copy configuration didn’t work. I tried the procedure in your article “Exchange Server 2013 Lagged Database Copies In Action” to configure them all at once but it filters on the ActivationPreference value.
Hello Paul,
thanks for your great blog.
I have installed CU6 on my production environment yesterday and I don’t have similar bug like yours.
I have 2 DAGs and 24 servers with CAS/MBX mutualized.
regards
Thank you for sharing the important update.
Paul, I posted some of my findings with CU4 on your FB post this weekend.
Hi Paul, there are also test-popconnectivity and a few more test cmdlet not working anymore.
Assume you have a 2 Node DAG and the Extest Mailbox is on Store 1 on Node 1 located, and you run test-popconnectivity | fl you get an failure reported that the Mailbox and User located in different AD Sites.
cheers, Jürgen