Exchange 2010 Server patching in DAG Environment

Windows and Exchange Application patching is an important regular requirement for the any Environment and this also requires a proper planning and regularity. If we don’t follow the process and don’t patch our servers then we leave our servers open for security risk and application bugs. Following the article will help in patching windows OS and Exchange application on an exchange server. 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.

This tutorial demonstrates how to update the servers in an Exchange Server 2010 Database Availability Group without causing downtime.

if we don’t perform patch on the servers there are chances that we might see Servers on risk like

1: Security risk

2: Exchange Server’s bugs.

So we will discuss how to perform Patching on Windows and Exchange Servers.In-order to perform we need to have proper permissions. As we discussing about Windows and Exchange Servers so let’s see what are Permissions that are required.

 

The following permissions will be required.

  1. Windows Patching: Local Administrator
  2. Exchange Patching: The following group membership will be required: Local Administrator; Schema Admins; Enterprise Admins; Domain Admins and Organization management.

What should be the order for Exchange Server role to be patched, here is the order

  1. Client Access servers (beginning with the internet-facing site if any)
  2. Hub Transport and Edge Transport servers
  3. Mailbox servers
  4. Unified Messaging servers

Prerequisites :

1  Test the patches in the Lab machines.

2  Raise a change request if your using Monitoring Tools, and wait for the approval “Also write tested in the lab”.

3  Once Change has been approved go ahead with further steps.

4  Place servers in the Maintenance mode SCOM/Tivoli/Solarwinds or other monitoring tool

So we will be starting patch 1st on CAS server:-

Most of the organization has CAS Array to avoid client connection downtime.

So when it comes time to update the CAS array members with patches, update rollups or service packs, the update process needs to be managed in a way that prevents all of the CAS array members from being offline at the same time. so remember my friend you must patch any server one by one (Best practice to install any role one by one and verify the service , you can do at a time if you have vast knowledge of exchange and can recover any issue if it occur in middle and you are in notice period LOL  😉 so you will ask what you follow, i will say i follow one by one ) you should always patch your CAS servers first, starting with the internet-facing one(s) if you have multiple sites.

Preparing NLB cluster for Update, if CAS Array is configured with HLB or F5 then you should make node offline before patching each CAS so the request will not go to that node , nowadays many HLB are intelligent enough go route traffic to healthy node.

The first step is to remove the server that is about to be updated from the Network Load Balancing (NLB) cluster.

There are two ways to take a CAS array member our of the NLB cluster:

  • Issue a Stop command to the server
  • Issue a Drainstop command to the server

The difference between the two is that Stop will immediately stop the server regardless of who is currently connected to it, while Drainstop will put the server in a state where it will not accept new connections but will continue serving existing connections until they disconnect.

For urgent updates a Stop command may be necessary, but for planned maintenance a Drainstop has the least potential impact on active client connections to the CAS array.

To issue a Drainstop launch Network Load Balancing Manager, right-click on the desired server, choose Control Host and then Drainstop. When the server has no more active connections it will be in a stopped state.

Right click the server and choose Properties.  Set the default state of the server to Stopped.  This will prevent it from automatically starting and accepting client connections after any reboots that the updates require, to allow you time to verify the updates were successful first before rejoining the NLB cluster.

Now install the update either through Bigfix, SCCM or manyally from windows update.

Go to start -> All Programs -> Windows Update -> Click the Available updates.

 

Patch2

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

If the update was successful and the server healthy then it can be placed back into production.

Set the NLB initial host state to Started.

And re-enable monitoring agents and alarms for the server. here now our first CAS has been patched successfully now we can move to other server.

 

Patching for HUB server pretty simple, install or patch one by one each HUB server and reboot and test service and mailflow.

our main focus will on Mailbox server as it is very critical  and moving database here and there testing things has more steps to take.

Preparation

  1. Test the patches in the Lab
  2. Raise a change and wait for the approval. Also write tested in the lab.
  3. Once Change has been approved go ahead with further steps.
  4. Place servers in the maintenance mode Scom/Tivoli/Solarwinds or other monitoring tool
  5. On Exchange Server Move PAM to other Exchange server

    a) Open Exchange management shell

    b) Run the following cmdlet

    cluster.exe “DagName” group “Cluster Group” /MoveTo:”destinationServer”

    c) Put Mailbox server in Maintenance mode  On the DAG member server, navigate to the script folder, by default under “C:\Program Files\Microsoft\Exchange Server\V14\Scripts”:b) Use script “StartDagServerMaintenance” to put the DAG member server into maintenance mode:.\StartDagServerMaintenance.ps1 –serverName “DAGnode1”Note: Please replace “DAGnode1” with the DAG member server name which you want to put into maintenance mode.After that, the DAG member server will be put into maintenance mode, the script will do the following

    i) Move all the active databases off of the server
    ii) Set the “DatabaseCopyAutoActivationPolicy” to Blocked on the mailbox server, thus it will block databases from moving to that server;
    iii) make sure all critical DAG support functionality (for example, the Primary Active Manager PAM role) that might be on the server is moved to another server, and blocked from moving back to the server.

So if you putting server in maintenance mode you can ignore step 5 above to move PAM to another node as this script will move as described.

 

To check the Database mounted on which server run the below cmdlet:

Get-MailboxDatabase | fl name,Server

If the above cmdlet cause any issue and server does not go in to the maintenance mode then follow this manual process to move database. On Exchange Server Move the Exchange Databases to other Exchange Servers

Open Exchange management shell and run the following cmdlet

Move-ActiveMailboxDatabase -Identity ‘Database Name’ -ActivateOnServer ‘DestinationServer’ -MountDialOverride ‘None’

Move PAM to another host (if we are not moving PAM to another host reboot will take care of putting PAM to another host but for precautionary measure we will move either manually or by script)

 

 

Patching Procedure

  1. Login to the server

Once installing of patches completed click finished and restart the server.

 

Post Patching Activity

a) Stop the maintenance mode

  1. After finish your maintenance activities bring the DAG member out of maintenance mode. So use the “StopDagServerMaintenance” scripts which is also reside in the scripts folder to stop maintenance mode on DAG Node2) Navigate to the script folder again , by default under “C:\Program Files\Microsoft\Exchange Server\V14\Scripts”:3) .\StopDagServerMaintenance.ps1 -serverName “DAGnode2”Above script “StopDagServerMaintenance” is used to stop the maintenance for the specified server
  2. To check the Database mounted on which server run the below cmdlet:

    Get-MailboxDatabase | fl name,Server

    Move-ActiveMailboxDatabase -Identity ‘DBNAme’ -ActivateOnServer ‘DestinationServer’ -MountDialOverride ‘None’

  3. On Exchange Server Move back PAM to Exchange server if we have moved while patching or from scripting it did not move.
    1. Open Exchange management shell
    2. Run the following cmdlet

      cluster.exe “DagName” group “Cluster Group” /MoveTo:”destinationServer”

      If  you have DR step then make sure rebooting mailbox server does not go to DR mailbox server for this you should be moving either by script or manually by command.

Check Mailbox by running below command,

1 Test-Servicehealth

2 Test-Replicatinhealth

 

 

3 Check the Queue if there are any emails stuck in the queue.

4: Test-OutlookWebServices

5: Test-Mapiconnectivity

6: Get-mailboxdatabasecopystatus **

Login to OWA using test account and test send and receive of the email.

If all looks fine then move to another DAG node

  • To re-balance the mailbox databases over all members of the cluster according to your activation preference, execute the command:
  • .\RedistributeActiveDatabases.ps1 -DagName DAG01 -BalanceDbsByActivationPreference 
  • You will be asked if you really want to set the active database on one of the other servers. The script will give a summary of all actions taken when it’s finished. Outlook clients will receive a disconnect message immediately followed by a connect message.
  • exchange-dag-maintenance-05

Note:- you don’t have to move PAM on each server, you will be moving PAM to other server in case you are patching server on which PAM role exist.

Thanks

 

 

Leave a Reply

Your email address will not be published. Required fields are marked *