An Exchange Server 2010 Database Availability Group (DAG) provides several benefits to an organization, primarily that of continuous availability of mailbox databases.
To update the DAG members with new patches, update rollups or service packs, the update process should be managed to prevent all of the DAG members from being offline at the same time.
To do this you can move the active mailbox databases off a particular server so that it can be patched, and if necessary rebooted, without causing any downtime for mailbox users on that database.
This tutorial demonstrates how to update the servers in an Exchange Server 2010 Database Availability Group without causing downtime. Because this process differs depending on the version of Exchange Server 2010 you’re running I’ve covered each method here.
- Preparing an Exchange Server 2010 RTM DAG member for updates, or
- Preparing an Exchange Server 2010 SP1 DAG member for updates
- Stopping Conflicting Services
- Disabling Server Monitoring
- Updating the Server
- Verifying the Update
- Returning an Exchange Server 2010 RTM DAG member to production, or
- Returning an Exchange Server 2010 SP1 DAG member to production
For this tutorial Update Rollup 4 for Exchange Server 2010 is being installed.
Preparing an Exchange Server 2010 RTM DAG Member for Updates
The first step is to move active mailbox databases to another DAG member so that the server can be updated.
To see a list of mailbox databases and their current active server use the Get-MailboxDatabase cmdlet.
[PS] C:\>Get-MailboxDatabase Name Server Recovery ReplicationType ---- ------ -------- --------------- Mailbox Database 02 EX1 False Remote Mailbox Database 01 EX2 False Remote
In this example I want to apply updates to server EX1, and I can see that it currently hosts the active copy of Mailbox Database 02.
If your environment has a lot of DAG members and mailbox databases you can refine this query to only show active mailbox databases for a specific server.
[PS] C:\>Get-MailboxDatabase | where {$_.Server -eq "EX1"}
Name Server Recovery ReplicationType
---- ------ -------- ---------------
Mailbox Database 02 EX1 False Remote Move the mailbox databases using the Move-ActiveMailboxDatabase cmdlet.
[PS] C:\>Move-ActiveMailboxDatabase "Mailbox Database 02" -ActivateOnServer EX2
Confirm
Are you sure you want to perform this action?
Moving mailbox database "Mailbox Database 02" from server "ex1.exchangeserverpro.local" to server
"EX2.exchangeserverpro.local".
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y
Identity ActiveServerAtS ActiveServerAtE Status NumberOfLogsLost RecoveryPoint MountStatus MountStatus
tart nd Objective AtMoveStart AtMoveEnd
-------- --------------- --------------- ------ ---------------- ------------- ----------- -----------
Mailbox Data... ex1 ex2 Succeeded 0 14/09/2010... Mounted Mounted All of the mailbox databases are now active on server EX2.
[PS] C:\>Get-MailboxDatabase Name Server Recovery ReplicationType ---- ------ -------- --------------- Mailbox Database 02 EX2 False Remote Mailbox Database 01 EX2 False Remote
As another example, if there were multiple databases active on a server you can move all of them with a single command.
[PS] C:\>Get-MailboxDatabase | where {$_.Server -eq "EX1"} | Move-ActiveMailboxDatabase -ActivateOnServer EX2 -Confirm:$false
Identity ActiveServerAtS ActiveServerAtE Status NumberOfLogsLost RecoveryPoint MountStatus MountStatus
tart nd Objective AtMoveStart AtMoveEnd
-------- --------------- --------------- ------ ---------------- ------------- ----------- -----------
Mailbox Data... ex1 ex2 Succeeded 0 14/09/2010... Mounted Mounted
Mailbox Data... ex1 ex2 Succeeded 0 14/09/2010... Mounted Mountede Note the use of -Confirm:$false to avoid having to confirm each move. Use this option with caution.
After moving all active mailbox databases off the server that you are planning to update, the final preparation step is to block activation on the server to prevent it from automatically reactiving a database copy while you are performing maintenance.
First check the current activation policy on the server using Get-MailboxServer.
[PS] C:\>Get-MailboxServer EX1 | fl Name,DatabaseCopyAutoActivationPolicy Name : EX1 DatabaseCopyAutoActivationPolicy : Unrestricted
Next, use Set-MailboxServer to block activation.
[PS] C:\>Set-MailboxServer EX1 -DatabaseCopyAutoActivationPolicy Blocked
Preparing an Exchange Server 2010 SP1 DAG Member for Updates
For Exchange 2010 with Service Pack 1 the process is a little easier thanks to some scripts provided by Microsoft. Open the Exchange Management Shell and navigate to the scripts folder on the Exchange server.
cd $exscripts
Next run the StartDagServerMaintenance.ps1 PowerShell script.
.\StartDagServerMaintenance.ps1 -serverName ho-ex2010-mb1
The script will automatically do the following tasks for you:
- Calls Suspend-MailboxDatabaseCopy on the database copies.
- Pauses the node in Failover Clustering so that it can not become the Primary Active Manager.
- Suspends database activation on each mailbox database.
- Sets the DatabaseCopyAutoActivationPolicy to Blocked on the server.
- Moves databases and cluster group off of the designated server.
Stopping Conflicting Services
If the mailbox server is running any Exchange-integrated services, such as antivirus software, these should be disabled prior to the update.
For example to disable Forefront use the FSUtility command.
C:\> fsutility /disable
Another example is Data Protection Manager 2010, which may be configured to perform Copy backups from passive database copies at frequent intervals through the day. Make sure these jobs are paused to prevent errors or conflicts from occuring.
Disabling Server Monitoring
If the DAG members are monitored using SCOM or a similar system then this should also be disabled or placed into maintenance mode.
This will prevent alarms from being raised as well as prevent any automatic remediation actions from being run by the monitoring agent that may cause the server updates to fail.
Updating the Server
Install the update following the deployment notes for that update type.
Update rollups come in the form of a .MSP file (Windows Installer Patch) that is applied to the server. Simply double-click the file or launch it from a command line window.
Service packs are a complete reissue of the Exchange Server setup files and are installed by running setup in upgrade mode, which can be run in either graphical or command line mode.
C:\> setup /m:upgrade
Both update rollups and service packs can take some time to install, so plan a large window of time for these updates.
Verifying the Update
After the update has completed, and if necessary the server rebooted, you should check the server’s health before placing it back into production in the CAS array.
Event Logs – look for error or warning events that have started since the update was applied.
Setup Logs – service packs write a complete setup log file to C:\ExchangeSetupLogs
Services – check the Exchange services are running (or at least those that you expect to be running, some such as IMAP and POP will be stopped if you have not explicitly enabled them)
[PS] C:\>Get-Service *exchange* Status Name DisplayName ------ ---- ----------- Running MSExchangeADTop... Microsoft Exchange Active Directory... Running MSExchangeIS Microsoft Exchange Information Store Running MSExchangeMailb... Microsoft Exchange Mailbox Assistants Running MSExchangeMailS... Microsoft Exchange Mail Submission Stopped MSExchangeMonit... Microsoft Exchange Monitoring Running MSExchangeRepl Microsoft Exchange Replication Running MSExchangeRPC Microsoft Exchange RPC Client Access Running MSExchangeSA Microsoft Exchange System Attendant Running MSExchangeSearch Microsoft Exchange Search Indexer Running MSExchangeServi... Microsoft Exchange Service Host Running MSExchangeThrot... Microsoft Exchange Throttling Running MSExchangeTrans... Microsoft Exchange Transport Log Se... Running msftesql-Exchange Microsoft Search (Exchange) Running vmickvpexchange Hyper-V Data Exchange Service Stopped wsbexchange Microsoft Exchange Server Extension...
Returning an Exchange Server 2010 RTM DAG Member to Production
If the update was successful and the server healthy then it can be placed back into production.
Re-enable services such as Forefront Protection for Exchange.
C:\> fsutility /enable
Re-enable monitoring agents and alarms for the server.
Set the server’s activation policy back to its original setting.
[PS] C:\>Set-MailboxServer EX1 -DatabaseCopyAutoActivationPolicy Unrestricted
At this stage you might move all of the active mailbox databases to the server that was just updated so that you can update the other servers in the DAG. After all of the DAG members have been updated it is likely that mailbox databases will be active on servers that are not their first activation preference.
For Exchange Server 2010 RTM you can view the activation preferences for each database, and manually move active mailbox databases to their preferred server.
[PS] C:\>Get-MailboxDatabase | fl name,activationpreference
Name : Mailbox Database 02
ActivationPreference : {[EX2, 1], [EX1, 2]}
Name : Mailbox Database 01
ActivationPreference : {[EX1, 1], [EX2, 2]} [PS] C:\>Move-ActiveMailboxDatabase "Mailbox Database 01" -ActivateOnServer EX1
Confirm
Are you sure you want to perform this action?
Moving mailbox database "Mailbox Database 01" from server "EX2.exchangeserverpro.local" to server
"ex1.exchangeserverpro.local".
[Y] Yes [A] Yes to All [N] No [L] No to All [?] Help (default is "Y"): y
Identity ActiveServerAtS ActiveServerAtE Status NumberOfLogsLost RecoveryPoint MountStatus MountStatus
tart nd Objective AtMoveStart AtMoveEnd
-------- --------------- --------------- ------ ---------------- ------------- ----------- -----------
Mailbox Data... ex2 ex1 Succeeded 0 14/09/2010... Mounted Mounted Returning an Exchange Server 2010 SP1 DAG Member to Production
Once again Exchange 2010 with Service Pack 1 makes this task easier thanks to a script provided by Microsoft. Open the Exchange Management Shell and navigate to the scripts folder on the Exchange server.
cd $exscripts
Next run the StopDagServerMaintenance.ps1 PowerShell script.
.\StopDagServerMaintenance.ps1 -serverName ho-ex2010-mb1
The script will automatically reverse each of the actions made by StartDagServerMaintenance.ps1 except that it will not move active mailbox databases back to the server.
To move the active mailbox databases you can continue to go to each mailbox server in the DAG and run StartDagServerMaintenance.ps1 and perform your updates. When all of the servers have been updated you can rebalance the DAG automatically using a script from Microsoft which is demonstrated here.
