Exchange 2010: StopDagServerMaintenance.ps1 resets server and database suspension states…
In Exchange 2010, when a database availability group (DAG) member needs service, it can be placed into maintenance mode. To do this, Exchange 2010 includes scripts for this process called StartDagServerMaintenance.ps1 and StopDagServerMaintenace.ps1. 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:\Windows\system32>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:\Windows\system32>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
While the maintenance scripts behavior are 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 link to 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.
At runtime, and on the server on which this script is run, two CSV files are created 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. For example:
#TYPE Selected.Microsoft.Exchange.Management.SystemConfigurationTasks.DatabaseCopyStatusEntry
"Name","ActivationSuspended"
"DAG-DB0\DAG-3","True"
"DAG-DB1\DAG-3","True"
The second CSV file contains the database copy auto activation policy of the server. For example:
#TYPE Selected.Microsoft.Exchange.Data.Directory.Management.MailboxServer
"Name","DatabaseCopyAutoActivationPolicy"
"DAG-3","Blocked"
To use the script the administrator must relax the execution policy on the server to allow for unsigned scripts. This can be accomplished by using powershell:
Set-ExecutionPolicy UNSIGNED
Once the execution policy has been adjusted the maintenance procedure is started using the following command:
maintenanceWrapper.ps1 –server <SERVERNAME> –action START
It is this command that is responsible for creating the CSV files containing the original database states and invoking the StartDagServerMaintenance.ps1 script.
When the maintenance work is completed the maintenance procedure can be stopped by using the following command:
maintenanceWrapper.ps1 –server <SERVERNAME> –action STOP
It is this command this is responsible for calling the StopDagServerMaintenance.ps1 script and then resetting 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.