Exchange Server 2016 introduced the PowerShell cmdlet Get-MailboxServerRedundancy. This cmdlet helps you plan and prepare for Exchange Server maintenance by querying the current maintenance readiness of the database availability group (DAG).
Interestingly, there is no PowerShell help available for this vital cmdlet. Microsoft Docs or Exchange Management Shell’s Get-Help provide any valuable information.
When querying a DAG about the server redundancy status, the cmdlet’s default output provides you with the essential information.
The default output contains information about:
- Identity
Name of the DAG member server
- IsServerFoundInAD
Indicates if the corresponding server computer object exists Active Directory
- IsInMaintenance
Indicates if the server is currently in maintenance mode
- RepairUrgency
Indicates an aggregated state of the mailbox database and search index repair modes
- SafeForMaintenance
Indicates if you can safely activate the maintenance mode for this server
- HealthInfoLastUpdateTime
Timestamp when the server’s health state was last updated
Example – Prior Maintenance
This example shows the Get-MailboxServerRedundancy output of a six-server DAG before activating maintenance mode for server LOCEXS06.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 09:10:11
LOCEXS02 True False Normal True 17.02.2020 09:10:11
LOCEXS03 True False Normal True 17.02.2020 09:10:11
LOCEXS06 True False Normal True 17.02.2020 09:10:11
LOCEXS05 True False Normal True 17.02.2020 09:10:11
LOCEXS04 True False Prohibited False 17.02.2020 09:10:11
As Exchange Administrator, you are most interested in the information displayed in columns RepairUrgency and SafeForMaintenance.
As you can see in this screenshot, no server is in maintenance mode. Servers S01 and S04 have a RepairUrgency state of Prohibited, and a SafeForMaintenance state of False. The latter tells us that we cannot activate maintenance mode for servers safely without risking mailbox database redundancy.
What is the reason for this? Let’s have a look.
Server Information
You can use the same cmdlet to query detailed information for each member server of the DAG. The default output for a single server does not provide any additional information on the server status.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 09:11:11
Because we cannot safely activate maintenance mode for server LOCEXS01, we are interested in identifying which redundancy state is responsible.
You can find this information by displaying detailed server information.
Detailed Server Information
Use the Format-List, or short FL, cmdlet to display the Get-MailboxServerRedundancy cmdlet output as a formatted list.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup EXDAG01 -Identity LOCEXS01 | FL RunspaceId : 70d82f8d-e6ca-4bfc-863f-11300a9784ff Identity : LOCEXS01 IsServerFoundInAD : True IsInMaintenance : False RepairUrgency : Prohibited SafeForMaintenance : False ServerContacted Fqdn : LOCEXS04.VARUNAGROUP.DE HealthInfoCreateTime : 15.06.2018 15:16:19 HealthInfoLastUpdateTime : 17.02.2020 09:11:11 ServerFoundInAD : CurrentState: Active; LastActiveTransition: 15.06.2018 15:22:16; LastInactiveTransition: InMaintenance : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02; LastInactiveTransition: 17.01.2020 10:42:02 AutoActivationPolicyBlocked : CurrentState: Inactive; LastActiveTransition: 09.01.2020 10:14:50; LastInactiveTransition: 09.01.2020 11:00:51 ActivationDisabledAndMoveNow : CurrentState: Inactive; LastActiveTransition: ; LastInactiveTransition: 15.06.2018 15:22:16 HighAvailabilityComponentStateOffline : CurrentState: Inactive; LastActiveTransition: 17.01.2020 09:07:02; LastInactiveTransition: 17.01.2020 10:42:02 CriticalForMaintainingAvailability : CurrentState: Inactive; LastActiveTransition: 31.01.2020 16:52:49; LastInactiveTransition: 31.01.2020 16:56:49 CriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 29.01.2020 11:43:06; LastInactiveTransition: 29.01.2020 11:42:06 PotentiallyCriticalForMaintainingRedundancy : CurrentState: Active; LastActiveTransition: 01.02.2020 05:49:37; LastInactiveTransition: CriticalForRestoringAvailability : CurrentState: Inactive; LastActiveTransition: 06.05.2019 09:16:36; LastInactiveTransition: 06.05.2019 09:20:36 CriticalForRestoringRedundancy : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06; LastInactiveTransition: 29.01.2020 11:43:06 HighForRestoringAvailability : CurrentState: Inactive; LastActiveTransition: 29.01.2020 11:42:06; LastInactiveTransition: 29.01.2020 11:43:06 HighForRestoringRedundancy : CurrentState: Inactive; LastActiveTransition: 10.02.2020 09:05:02; LastInactiveTransition: 10.02.2020 09:06:02 IsSafeForMaintenance : CurrentState: Inactive; LastActiveTransition: 03.11.2019 09:42:35; LastInactiveTransition: 12.11.2019 06:29:58 IsValid : True ObjectState : Unchanged
Lines 24-27 show the information we want to know. Both the CriticalForMaintainingRedundancy and PotentiallyCriticalForMaintainingRedundancy parameters have a CurrentState value of Active. The Primary Activation Manager (PAM) considers the server availability critical to provide redundant availability of the database copies hosted by this server.
Each of state-parameter shows three pieces of information:
- CurrentState
The current state, either Active or Inactive
- LastActiveTransition
The timestamp of the last state change to Active
- LastInactiveTransition
The timestamp of the last state change to Inactive
But there is still the bothering question of why two of the six servers are unsafe for activating maintenance.
The reason is simple. The mailbox databases mounted by the member servers of the DAG have a different number of database copies. This configuration is due to data storage capacity constraints.
The mailbox databases storing primary user mailboxes use four database copies per database. Those copies are evenly distributed across all six mailbox servers. Mailbox database storing online archive mailboxes use three copies per database. This database copy layout allows for safely activating server maintenance for one server at a time without risk to database redundancy.
The servers LOCEXS01 and LOCEXS04 hold mailbox databases with just two copies per configured database. Placing one of those two servers into maintenance mode reduces the database availability for these mailbox databases to one. Therefore, PAM informs us that database redundancy is at risk when activating maintenance for those two servers.
Example – During Maintenance
This example shows the member server redundancy state while LOCEXS06 is in maintenance. The reason for monthly maintenance for installing Windows updates.
Maintenance was activated using StartDagServerMaintenance.ps1 PowerShell script.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 11:04:12
LOCEXS02 True False Normal True 17.02.2020 11:04:12
LOCEXS03 True False Prohibited False 17.02.2020 11:04:12
LOCEXS06 True True High True 17.02.2020 11:04:12
LOCEXS05 True False Prohibited False 17.02.2020 11:04:12
LOCEXS04 True False Prohibited False 17.02.2020 11:04:12
Having a single server in maintenance has a significant impact on all other servers in the DAG. The servers LOCEXS03 and LOCEXS05 are not safe for maintenance, too. Activating maintenance for those two servers would affect the database redundancy for the databases hosted by those two servers.
Example – After Maintenance
After completing all maintenance tasks, e.g., installing Windows Updates or a new Exchange Server Cumulative Update, you end server maintenance using the PowerShell script StopDagServerMaintenance.ps1.
We query the server redundancy state again.
Get-MailboxServerRedundancy -DatabaseAvailabilityGroup indag01
Identity IsServerFound IsInMainten RepairUrgency SafeForMaintenance HealthInfoLastUpdateTime
InAD ance
-------- ------------- ----------- ------------- ------------------ ------------------------
LOCEXS01 True False Prohibited False 17.02.2020 11:23:12
LOCEXS02 True False Normal True 17.02.2020 11:23:12
LOCEXS03 True False Normal True 17.02.2020 11:23:12
LOCEXS06 True False High True 17.02.2020 11:23:12
LOCEXS05 True False Normal True 17.02.2020 11:23:12
LOCEXS04 True False Prohibited False 17.02.2020 11:23:12
Server LOCEXS06 is not in maintenance, but the RepairUrgency state is High. The local Exchange Server replication engine is still busy replicating and processing log files and updating the search indices. When CopyQueueLength and ReplayQueueLength are back to 0 and ContentIndexStates are back to Healthy, the RepairUrgency switches to Normal.
Tip
-
You receive an error message when activating maintenance for an Exchange Server not safe for maintenance using
StartDagServerMaintenance.ps1 -serverName [SERVER]In this case, you must use:
.\StartDagServerMaintenance.ps1 -serverName SERVERNAME -overrideMinimumTwoCopies:$true
Enjoy Exchange Server!
