• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / Get-MailboxDatabaseCopyStatus Displays Incorrect Activation Preference Value

Get-MailboxDatabaseCopyStatus Displays Incorrect Activation Preference Value

September 26, 2014 by Paul Cunningham 8 Comments

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

Exchange Server Bugs, DAGs, Database Availability Groups, Exchange 2013, PowerShell

Comments

  1. Frank says

    May 7, 2015 at 5:54 pm

    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

    Reply
    • Paul Cunningham says

      May 7, 2015 at 8:55 pm

      Yep. Hopefully the bug is fixed in CU9.

      Reply
  2. AtlasDan says

    November 22, 2014 at 6:24 am

    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.

    Reply
  3. anonymous says

    October 3, 2014 at 9:55 pm

    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

    Reply
  4. Qhayum says

    October 3, 2014 at 12:24 am

    Thank you for sharing the important update.

    Reply
  5. Mike DiVergilio says

    September 30, 2014 at 7:57 am

    Paul, I posted some of my findings with CU4 on your FB post this weekend.

    Reply
  6. Jürgen says

    September 27, 2014 at 12:38 am

    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

    Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy
  • Making the Case for Identity Governance in Azure Active Directory
  • Prepare an Office 365 migration plan assessment using PowerShell

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland