How to upgrade your existent Exchange Server 2013 to CU3

Share this:

In this Tutorial we are going to upgrade our current Exchange Server 2013 CU2 to CU3. Our environment for this Tutorial has 2 DAG members (BsAEX01 and BsAEX02) and all databases before starting the following steps are hosted on BsAEX01.

In order to perform the upgrade of our DAG we will be starting with server BsAEX01 on this Tutorial, let’s double check a couple of items before moving forward:

  • A really good backup of your environment in place (Databases and Active Directory)
  • Make sure that all systems that use Exchange Server 2013 support the new CU3 (Backup, Archive, MDM vendors and so forth)
  • Stop the current backup agent and System center agent (if they are installed) on the server that we are going to upgrade
  • Make sure that you don’t have any patch requesting a reboot, if you do please restart the server
  • Close all existent Exchange Management Shell sessions of the server
  • If you have any remote connected administrator to the server, please kick them out
  • Make sure that you existent Databases (for a DAG member) is Healthy before going any further
  • As a best practice delete the folder C:ExchangeSetupLogs (or at least move to a different place if you want to keep the current data) and the setup process will create a new folder and all information related to this upgrade will be stored there and we can use for troubleshooting purposes in case something goes South.

Putting the first server into maintenance mode…

In this section the goal is configure the server in maintenance mode and get it ready for the installation process.

  1. List the current status of the components
  2. Change the state for the HubTransport and UMCallRouter components to
  3. Move all Queues to the remaining server (BsAEX02)
  4. Put the server in maintenance on the DAG as well
  5. Validate if everything is well

The first step is to run the following cmdlet to check the current status of our existent server.

Get-ServerComponentState <Server-Name>


Now we need to drain the Hub Transport and Unified Messaging components and we can do that by running these two cmdlets:

Set-ServerComponentState <Server-Name> –Component HubTransport –State Draining –Requester Maintenance

Set-ServerComponentState <Server-Name> –Component UMCallRouter –State Draining –Requester Maintenance


Note: If you run the Get-ServerComponentState <Server-Name> you should see those two component set as Draining on the State column of the output.

This step is not a requirement but you can use to speed up the process for the existent messages to be moved to a remaining server. We can redirect the existent messages from the server that is going under maintenance to the remaining server (BsAEX02) using the following cmdlet.

Redirect-Message –Server <Server-Name> –Target <FQDN-of-the-remaining-server>


Note:  We can check the queues on the server that is about to receive the upgrade and they should be clean.

Since we have only two servers that have also DAG in place, we need to put the current server in maintenance mode on the DAG side of the things. The easier and faster way is using a built-in script called StarDAGServerMaintenance.ps1. These are the steps that can be used to put the server in maintenance mode, after putting the server in maintenance mode we can check the Mailbox Databases and they should show as Healthy instead of mounted.

cd $EXScripts

.StartDAGServerMaintenance.ps1 <Server-Name>

Get-MailboxDatabaseCopyStatus –Server <Server-Name>


Finally we can run the following cmdlet to add the remaining components in maintenance mode. The cmdlet and the results are shown in the figure below as well.

Set-ServerComponentState <Server-Name> –Component ServerWideOffline –State Inactive –Requester Maintenance

Get-ServerComponentState <Server-Name>


Installing Cumulative Update 3..

Let’s go to the place were we extracted the CU3 and run the setup.exe which can be found on the main folder of the extracted location.

In the first page, select connect to the internet and check for updates

In the Downloading Updates page. Just click Next.

In the Copying files.. page. Just wait for the next page that will come up automatically.

In the Upgrade page. Just click next


In the License Agreement page. Read and if you are okay with the agreement click on I accept the terms in the license agreement and click next.

In the Readiness Checks page. Wait for the setup wizard to check your environment and you should receive the results and it shouldn’t show you any issues at this moment, if you do have issues you need to work on each item listed on this page before moving forward. If you have the install button available and there is no outstanding issues, please click on it.



Time for a coffee! The upgrade process consists of 18 steps and it may take a while..


In the final page you should have a window similar to the one shown bellow where the setup was completed successfully, click on Finish.


After that we can restart the server just to make sure that is all good. Next time that we open the Exchange Management Console we can run the following cmdlet and this new Cumulative Update 3 will be the version 15.0 (Build 775.38) as shown in the figure below.

Get-ExchangeServer | ft Name,Admin*


Removing the servers from Maintenance mode…

Now that the upgrade was complete on the first node we need return that server back to production.

The first step is to run the cmdlet bellow to bring the server active, after running the first cmdlet run the second one listed to make sure that all components are back to Active.

Set-ServerComponentState <Server-Name> –Component ServerWideOffline –State Active –Requester Maintenance

Get-ServerComponentState <Server-Name>


Note: The HubTransport and UMCAllRouter will return back to Draining and we will take care of these two in a minute.

Based on the official documentation, we need first to activate the UMCallRouting using the following cmdlet.

Set-ServerComponentState <Server-Name> -Component UMCallRouter -State Active -Requestor Maintenance


Now, it’s time to bring it back to production when the topic is DAG, and these following cmdlets can help us out.

cd $EXScripts

.StopDAGServerMaintenance.ps1 <Server-Name>

Get-MailboxDatabaseCopyStatus –Server <Server-Name>


The last but not least is to bring the Hub Transport back and we can do that by running the following cmdlet

Set-ServerComponentState <Server-Name> –Component HubTransport –State Active –Requester Maintenance


That’s it and Happy Exchange Server 2013 Cumulative Update 3 !!

Written by Anderson Patricio

Anderson Patricio

Anderson Patricio is a Canadian MVP in Cloud and Datacenter Management, and Office Server and Services, besides the Microsoft Award he also holds a Solutions Master (MCSM) in Exchange and several other certifications. Anderson has been contributing to the Microsoft Community with articles, tutorials, blog posts, twitter, forums and book reviews. He is a regular contributor here at,, and Anderson (Portuguese).

Related Post

Solving Test-CSEXStorageConnectivity cmdlet error ... When integrating Exchange Server 2013 and Skype for Business Server you may encounter the error 50043, and the complete description of the error is: “...
How to Export Recoverable Deleted Items and Purges... Hi there folks! In some situation during regular operations an user deletes something and the Operations/Exchange Admin has to work on the issue to r...
Fixing the error “The network path was not found” ... In situations where a new server is built to be used as witness server the administrator can get the error “The network path was not found” during the...
Managing DAG in Exchange Server 2013 – The Series... In this series we are going over the entire process to create a DAG environment in Exchange Server 2013. At the end of the series we will have built ...