In a Database Availability Group (DAG), there can be two or more copies of a mailbox database (the maximum number of copies is sixteen). One of these copies is the "active" copy, used by clients to perform daily email and calendaring tasks, and the other copies are "passive", held in reserve in case the active copy fails.
If the active copy becomes unavailable (because the server hosting it is out of service or something happens to the database itself), the DAG will perform a "fail-over". Once the DAG determines that the active copy is indeed unavailable for client use, it will activate the passive copy.
There are also situations when we would want to activate the passive copy manually. One common example would be for server maintenance that requires a reboot, like when we install Windows updates. In this case, we call the operation a "switch-over".
Note: some use the term "*-over" to designate fail-overs and switch-overs in general. The term is prononced "star-over".
This allows us to make the passive copy active (and vice versa) so we can perform maintenance on the server in question while continuing to provide messaging services to our users.
We have at least three methods to perform a switch-over:
- With the Exchange Management Console (EMC)
- With the Exchange Management Shell (EMS)
- With the StartDagServerMaintenance.ps1 script
Note: we use the StopDagServerMaintenance.ps1 script when maintenance is finished.
The last method is preferred because it can not only change the active copy of multiple mailbox databases but also the activation status of the servers and the holder of the "Primary Active Manager" role. We'll see those details later.
Otherwise, the first two methods are prefectly valid if we want to make the passive copy of the database active (and vice versa). Of course, if there are multiple copies, we would say "make one of the passive copies active".
EMC method
In my first example, we have two Exchange 2010 servers in our DAG: EX13-1 and EX13-2.
Currently, EX13-2 holds the active copy of the database "DB1":
The active copy is designated by the term "Mounted". The passive copy is not mounted but "Healthy". In other terms, it is ready for use, or ready to be mounted if necessary.
To move the active copy to Mailbox Server EX13-1, we right-click on database DB1 and select the menu option "Move Active Mailbox Database":
We must select the target server (browse to locate that server):
Note: unless we have reasons to do otherwise, we can leave the "mount dial setting" at None. Please refer to online sources if you are interested in the other options for this setting.
Managing Database Availability Groups (Exchange 2010)
Managing Database Availability Groups (Exchange 2015)
Managing Database Availability Groups (Exchange 2010)
Managing Database Availability Groups (Exchange 2015)
We click on Next (or Finish) to complete the operation:
Now the active database is "Mounted" on EX13-1:
EMS method
Now we'll perform the same operation using the Exchange Management Shell, moving the active copy of the database from EX13-1 to EX13-2. This one line cmdlet is all that is required:
[PS] C:\>Move-ActiveMailboxDatabase DB1 -ActivateOnServer EX13-2 -MountDialOverride:None
The result? Now the active copy of database DB1 is held by EX13-1. This change displays as shown below:
In case the small print is difficult to read, the status of the database copy is now "Mounted" on EX13-1 and "Healthy" on EX13-2.
StartDagServerMaintenance.ps1 script
The methods above simply change the status of the database(s) from active to passive and vice versa. They do not change the server holding the Primary Active Manager role and they do not block the passive databases from becoming active, which we would want to prevent if we were performing maintenance on the server in question.
As explained in the Technet document Managing Database Availability Groups (Exchange 2010) , this script performs the following tasks:
- Makes all active databases hosted on the DAG member in question passive - and the passive copy on other DAG members active .
- If the DAG member currently holds the "Primary Active Manager" (PAM) role, the script transfers this role to another DAG member.
- Pauses the node (the DAG member in question) so it cannot become the PAM during maintenance (which we want to avoid).
- Sets the value of the DatabaseCopyAutoActivationPolicy parameter on the DAG member to Blocked.
- Runs Suspend-MailboxDatabaseCopy to suspend each database copy hosted on the DAG member for activation.
In summary, the script "moves" active database copies to other DAG members, moves the PAM role, and prevents active database copies or cluster roles (like the PAM role) from being "moved" back to the DAG member that is undergoing maintenance.
Note: I have placed quotes around the word "move" because the active copy of the database is not really moved. The content of the database marked active is constantly replicated in the background to the copies marked passive. When we make the active copy passive, and one of the passive copies active, we are simply changing the status of the copies rather than moving entire databases from server to server.
The script is located in the following location:
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\StartDagServerMaintenance.ps1
When you attempt to execute the script, remember to type "." and "\" just before the name of the script itself.
We will be prompted for the name of the DAG member we wish to place in maintenance mode:
cmdlet StartDagServerMaintenance.ps1 at command pipeline position 1
Supply values for the following parameters:
serverName:
I simply enter: EX13-1.
If we want, we can verify that the script has performed at least some of the tasks listed above.
For example, the database should be in the "Healthy" state on the server we designated at the prompt above, and "Mounted" on the server that previously held the passive copy of the database:
We can also see this with the EMS:
[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-2 | fl Name,Status
Name : DB1\EX13-2
Status : Mounted
[PS] C:\>Get-MailboxDatabaseCopyStatus DB1\EX13-1 | fl Name,Status
Name : DB1\EX13-1
Status : Healthy
The script is also supposed to prevent the targeted server from holding active copies of mailbox databases (we would not want it to attempt to activate a database during maintenance). We can observe those results with this cmdlet:
[PS] C:\>Get-MailboxServer | select name,*activation* | ft -auto
Name DatabaseCopyAutoActivationPolicy
---- --------------------------------
EX13-1 Blocked
EX13-2 Unrestricted
The policy is "Blocked" for EX13-1, which is the correct setting for a server undergoing maintenance.
Once we have completed maintenance (installed Windows updates, etc.), we can execute the StopDagServerMaintenance.ps1 script:
[PS] C:\Program Files\Microsoft\Exchange Server\V14\Scripts>.\StopDagServerMaintenance.ps1
As previously, we have to designate the server that we intend to bring out of maintenance mode. In our case, it is obvious and we may wonder why we have to take to trouble of specifying this. In other environments, however, there could be up to sixteen DAG members and possibly more than one in maintenance mode at any given time.
Lastly, we can verify that the server in question is out of maintenance mode using the methods presented above.
Note: even after the server leaves maintenance mode, its mailbox databases will not necessarily become active (mounted) again. The copy on the other server could remain the active copy or a copy on yet another server could become the active copy.
Thank you for reading the article about Exchange 2010 - DAG (Database Availability Group) - Part 2 - Switchovers on the blog NEW TECH If you want to disseminate this article on please list the link as the source, and if this article was helpful please bookmark this page in your web browser by pressing Ctrl + D on your keyboard keys.