This weeks the second version of the second cumulative update has been released for Exchange 2013. As you may already know Microsoft has changed his update process completely with the introduction of Exchange 2013. No more rollups and only cumulative updates (CU’s).
A pretty big change as the CU’s require you to make changes to the AD also as step of the update process. For those not familiar with rollups of Exchange 2010, the rollups where just bit updates and did not include AD changes. In Exchange 2010 the AD changes where only included in service packs.
CU’s are a complete install of Exchange 2013. So if you plan to install Exchange 2013 in the future you will only need to install the latest CU and you’re done.
But what has changed from deployment standpoint? Well pretty much because we now have to think of the Managed Availability feature of Exchange 2013. This feature will continually monitor the environment and takes action if necessary.
You can compare it with placing a node in maintenance mode in a load balancer. Although with placing a node in maintenance mode in a load balancer only ensures that it doesn’t offer any traffic anymore to the specific server.
Managed availability goes steps further, it can do this because the monitors contain knowledge about the product something load balancers don’t have.
For changing the status of the components on a server you will need to use the Set-ServerComponentState cmdlet. Using this cmdlet with the necessary parameters you can influence the components of a server.
Which components are active on a server depends on which roles are deployed to server. To find out which components are available on a server you can run Get-ServerComponentState. In the example below you will see an output example of a multi-role Exchange 2013 server:
As you can see all components are up and running. Let’s assume that we have prepared our AD and are now ready to deploy the bits on our Exchange 2013 servers.
Our environment consists of two Exchange 2013 multirole servers. A third server is used as the File Share Witness (FSW) to maintain quorum.
The first step will me to ensure that the transport queues will be empty before continuing the process. Using the S_et-ServerComponentState_ cmdlet we can set the status of a component. Besides the status we will need to provide the requestor. In this case the requestor we are going to use is maintenance.
Set-ServerComponentState –identity ex02 –component –state draining –requestor maintenance
By using the cmdlet above we will put the transport component in draining state. This means it will take care of the messages which are currently in the queue but will not accept any new messages.
You can speed up the process by moving the messages to a transport component hosted on another server. To do this you will need to use the move-messages cmdlet:
Redirect-Messages -server ex02 –targetserver ex01.corp.local
To check if the queues are empty we can use the good old get-queue cmdlet:
Get-Queue –server ex02
If all queues are clean we can continue with disabling all the other components which are active on the server:
Set-ServerComponentState –identity ex02 –component serverwideoffline –state inactive –requestor maintenance
To verify if all components are set to the status inactive we could run the Get-ServerComponentState cmdlet again:
Now all components are inactive it’s time to handle the database availability group (DAG) part.
There are a two ways to put a DAG member in maintenance mode. Those who are familiar with Exchange 2010 will remember the s_tart-dagmaintenance_ script which will help you in putting s DAG member in maintenance model Well good news the script is still available and can be found in the same location as in Exchange 2010, the Exchange scripting directory.
Another method to put DAG member in maintenance mode is to set the status of the cluster component using the Suspend-ClusterNode, for example:
Suspend-ClusterNode
Once the cluster node has been stopped you will need to prevent the databases from being moved d on the member:
Set-MailboxServer -Identity ex02-DatabaseCopyActivationDisabledAndMoveNow $trueSet-MailboxServer -DatabaseCopyAutoActivationPolicy Blocked
And as final step we want to set the auto activation policy temporarily to blocked:
Set-MailboxServer -Identity ex02 -DatabaseCopyAutoActivationPolicy Blocked
Now all prerequired steps have been taken it is time to kick of the setup. In this blog we will use the cmdline to update our Exchange 2013 server. To update the server start the setup using the following parameters:
Setup.exe /m:upgrade /IacceptExchangeServerLicensing
This will start the upgrade to CU2 as you can see below:
Once the setup has finished you might decide to reboot the server. Once the server is back online it is time to restore the services.
To restore the services we will need need to perform the steps mentioned earlier only then in reverse order.
So we will start with putting the DAG member back online:
First we will make the DAG member and active of part of the cluster again:
Resume-ClusterNode
Once this has been done we need to remove the limits for database failovers which we configured earlier:
Set-MailboxServer -Identity ex02-DatabaseCopyActivationDisabledAndMoveNow $trueSet-MailboxServer -DatabaseCopyAutoActivationPolicy Blocked
Set-MailboxServer -Identity ex02 -DatabaseCopyAutoActivationPolicy Blocked
Now our DAG member is back online we need to change the component states to active:
Set-ServerComponentStatus –identity ex02 –component serverwideoffline –status active –requestor maintenance
When running the Get-ServerComponentStatus cmdlet you will see that the status of the transport component is still draining.
To stop the draining process for the transport component we will need to run the Set-ServerComponentStatus cmdlet again only using a different action parameter:
Set-ServerComponentStatus –identity ex02 –component transport –status active –requestor maintenance
Now when running the Get-ServerComponent cmdlet again the status of each component should show active.
Here ends the blog about how to install a CU on an Exchange 2013 server. If you hate to type the cmdlets manually then have a look at this script from Michael van Hoorenbeeck:
Micheals script: open
The script will perform the same cmdlets only with less typing for your and will simplify the proces of putting a server in maintenance and restore the services again.
Comments
