In Exchange 2010, when a database availability group (DAG) member needs service, it can be placed into maintenance mode. Exchange 2010 includes scripts the StartDagServerMaintenance.ps1 and StopDagServerMaintenace.ps1 scripts to place/remove a DAG member from maintenance mode. For a summary of what these scripts do, see this post.
Within a DAG, it is not uncommon to have one or more databases or servers blocked from automatic activation by the system. Some customers configure entire servers to be blocked from activation, some block individual copies, and some do a combination of both, based on their business requirements. Administrators using the maintenance mode scripts will find their configured activation blocks reset to the unblocked. This behavior is not a problem with the scripts; in fact, the scripts are working as designed.
Here is an example of a database copy that has had activation suspended:
[PS] C:\>Get-MailboxDatabaseCopyStatus DAG-DB0\MBX-2 | fl name,activationSuspended
Name : DAG-DB0\MBX-2
ActivationSuspended : True
Here is an example of a server that has activation blocked:
[PS] C:\>Get-MailboxServer MBX-2 | fl name,databasecopyautoactivationpolicy
Name : MBX-2
DatabaseCopyAutoActivationPolicy : Blocked
When the administrator executes the stopDagServerMaintenance.ps1 script, these states are reset back to their defaults. Here is an example of the states post StopDagServerMaintenance.ps1:
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-MailboxDatabaseCopyStatus DAG-DB0\MBX-2 | fl name,activationSuspended
Name : DAG-DB0\MBX-2
ActivationSuspended : False
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>Get-MailboxServer MBX-2 | fl name,databasecopyautoactivationpolicy
Name : MBX-2
DatabaseCopyAutoActivationPolicy : Unrestricted
Although the maintenance scripts behavior is by design, it can lead to undesirable scenarios, such as lagged database copies being activated. Of course, to eliminate these issues, an administrator can record database and server settings before and after maintenance and reconfigure any reset settings as needed.
To help with this, here is a sample script I created that records database and server activation settings into a CSV file which can then be used with the maintenance scripts to adjust the states automatically.
Download: MaintenanceWrapper.ps1 attached to this post.
When you run the script, it creates two CSV files (on the server you run it on) along with a transcript that contains the results of the command executed. The first CSV file contains all database copies assigned to the server and their activation suspension status. Here's an example:
The second CSV file contains the database copy auto activation policy of the server. For example:
Because this scipt is unsigned, you'll need to relax the execution policy on the server to allow for unsigned scripts.
IMPORTANT: Allowing unsigned PowerShell scripts to execute is a security risk. For details, see Running Windows PowerShell Scripts. If this option does not meet your organization's security policy, you can sign the script (requires a code-signing certificate).
This command sets the execution policy on a server to allow unsigned PowerShell scripts to execute:
You can use the maintenanceWrapper.ps1 script to start and stop maintenance procedure on a DAG member.
Use this command to start the maintenance procedure:
maintenanceWrapper.ps1 –server <SERVERNAME> –action START
The command creates the CSV files containing the original database states and then invokes the StartDagServerMaintenance.ps1 script to place the DAG member in maintenance mode.
After maintenance is completed, you can stop the maintenance procedure using this command:
maintenanceWrapper.ps1 –server <SERVERNAME> –action STOP
The command calls the StopDagServerMaintenance.ps1 script to remove the DAG member from maintenance mode and then resets the database and server activation states from the states recorded in the CSV file.
Give the script a try and see if it makes maintenance mode for activation-blocked servers and databases easier for you. I hope you find this useful, and I welcome any and all feedback.
*Special thanks to Scott Schnoll and Abram Jackson for reviewing this content and David Spooner for validating the script.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.