Install Exchange 2013 CU Update Part 3 – Installation and Verification

The Exchange server being updated should be in a clean state if you follow the steps outlined in part 2 of this series. Let us continue with installing the CU and applicable .NET Framework.

This article loosely follows the guidance from another great Exchange gurus Paul Cunningham. You can check out his post here.

You may ask: “Tom, you are just re-inventing the wheel then if others have done it many times before. Why bother documenting it on your blog?” For me, it’s always good to enhance my knowledge through blogging and to complement with screenshots or additional info that others might have missed.

First, set the PowerShell execution policy on the Exchange server to Unrestricted.

CU5.jpg

Then, launch Setup.exe from the installer directory.

CU6.jpg

CU7.jpg

If your server is blocked from connecting to update server directly (i.e. communication being restricted to internal WSUS), you can ignore and continue with the install.CU8.jpg

CU10.jpgCU11.jpgCU12.jpgCU13CU14.jpgCU15.jpgCU16.jpgCU17.jpgCU18.jpgCU19

Restart the server before proceeding with steps below.

If applicable, we will now upgrade .NET Framework to 4.6.2. This is required before we can install CU beyond version 15 in the future.

CU20.jpgCU21.jpgCU22CU23.jpgCU24.jpgCU25.jpg

After reboot, you can verify the version of .NET Framework installed under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full.

CU26.jpg

Once the server is back online, review the event logs to make sure the server is in a healthy state. Then, proceed, removing the server from maintenance (assuming again you have more than one Exchange servers set up within a DAG).

As a reminder, launch Exchange Management Shell as administrator before running the commands below. Otherwise, it will fail.

Here are the commands:

  • Set-ServerComponentState ServerName -Component ServerWideOffline -State Active -Requester Maintenance
  • Resume-ClusterNode –Name ServerName
  • Set-MailboxServer –Identity ServerName –DatabaseCopyActivationDisabledAndMoveNow $False
  • Set-MailboxServer –Identity ServerName –DatabaseCopyAutoActivationPolicy Unrestricted
  • Set-ServerComponentState –Identity ServerName –Component HubTransport –State Active –Requester Maintenance
  • Restart-Service MSExchangeTransport
  • Restart-Service MSExchangeFrontEndTransport

CU27.jpg

Again, we will confirm server is out of maintenance mode by running:

  • Get-ServerComponentState <ServerName> | ft Component,State –Autosize

All components should show Active.

CU28.jpg

Additional steps to take are:

  • Verify all cluster nodes are up (if you have a DAG): Get-ClusterNode
  • Test server health: Test-ServiceHealth

CU29.jpg

  • Check database copy status of DAG: Get-MailboxDatabaseCopyStatus
  • Test replication health of DAG: Test-ReplicationHealth

CU30.jpg

We will now move the database back to the server (Move-ActiveMailboxDatabase DB -ActivateOnServer Server). Afterward, test MAPI connectivity with this command: Test-MAPIConnectivity

CU31.jpg

Due to an issue with attachment size when sending email from mobile devices, we modified the value within specific web.config files manually. This value gets overwritten each time a new CU is installed. Thus, we need to update the value of these files once more to avoid the same from occurring.

  • On Client Access Server: %ExchangeInstallPath%FrontEnd\HttpProxy\Sync\web.config
  • On Mailbox Server: %ExchangeInstallPath%ClientAccess\Sync\web.config

And we are done!

I will sure update the posts within this series if there are significant changes with future CU update.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.