Exchange

Exchange 2013 CU17 and Exchange 2016 CU6

4 Comments

On June 27, 2017 Microsoft has released its quarterly updates for Exchange 2013 and Exchange 2016. The current version is now at Exchange 2013 CU17 and Exchange 2016 CU6. Typically I don’t pay that much attention to this, all new developments seem to be for Office 365 and very little developments for on-premises Exchange deployment. But this time there are some interesting things I’d like to point out.

A couple of days before the release of Exchange 2016 CU6 Microsoft blogged about Sent Items Behavior Control and Original Folder Item Recovery. With the Sent Items Behavior Control, a message that’s sent using the Send As or Send on behalf of permission is not only stored in the mailbox of the user that actually sent the message, but a copy is also stored in the delegator mailbox sent items. This was already possible for shared mailboxes, but now it’s also possible for regular mailboxes (like manager/assistant scenarios).

The Original Folder Item Recovery feature is I guess on of the most requested features. In the past (before Exchange 2010) when items were restored after they were deleted, they were restored to their original location. With the Dumpster 2.0 that was introduced with Exchange 2010 this was no longer possible, and items were restored to the deleted items folder. In this case the items had to be moved manually to their original location. With the introduction of the Original Folder Item Recovery the restore of deleted items again takes place in the original folder.

Unfortunately, both Sent Items Behavior Control and Original Folder Item Recovery are only available in Exchange 2016 CU6 (and NOT in Exchange 2013 CU17).

When it comes to security TLS 1.2 is a hot topic. Microsoft is aware of this and working hard towards an Exchange environment that only uses TLS 1.2 (so that TLS 1.1 and TLS 1.0 can be disabled). We are not yet at that stage. Exchange 2016 CU6 does have improved support for TLS 1.2, but Microsoft is not encouraging customers to move to a TLS 1.2 environment only.

.NET Framework and Exchange server continues to be a difficult scenario. This is understandable, Exchange is just a consumer of Windows and .NET so the Exchange Product Group does not have much influence on the .NET (and Windows) Product Group.

Exchange 2016 CU6 does NOT support.NET Framework 4.7 at this moment, and you should NOT install .NET Framework on a server running Exchange 2016. Not before and not after the installation of Exchange 2016 CU6. This is also true for Exchange Server 2013 CU17. More information regarding .NET Framework and Exchange server can be found here: https://blogs.technet.microsoft.com/exchange/2017/06/13/net-framework-4-7-and-exchange-server/.

The .NET Framework 4.6.2 is supported by Exchange 2016 CU3 and higher and Exchange 2013 CU15 and higher. For a complete overview of which scenarios are supported, navigate to the Exchange Server Supportability Matrix on https://technet.microsoft.com/en-us/library/ff728623(v=exchg.150).aspx.

KB articles that describe the fixes, features and information in each release are available as follows:

Installing Exchange 2016 CU6

Exchange 2016 CU6 does introduce a change in the Active Directory Schema, so I recommend upgrading the Schema Partition, Configuration Partition and Domain Partition using the following commands:

Setup.exe /PrepareSchema /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms
Setup.exe /PrepareDomain /IAcceptExchangeServerLicenseTerms

Once upgraded you can update the Exchange 2016 server using the following command:

Setup.exe /mode:upgrade /IAcceptExchangeServerLicenseTerms

But, it looks like there’s an issue with the setup application. After step 7 the setup application stops, and generated the following error message:

“A reboot is required to complete file operations on ‘E:\exchangeserver.msi’. Reboot the machine, and then run setup again”

image

After rebooting and restarting the setup application the upgrade finishes successfully.

Note. Restarting the server prior to executing the upgrade does not solve the issue.

Upgrading DAG members

Upgrading Exchange 2016 servers that are members of a Database Availability Group involves a bit more work (same is true for Exchange 2013 BTW). You have to put the DAG members in maintenance mode before starting the actual upgrade. And don’t forget to disable the Real Servers in your load balancer!

To put a DAG member in maintenance mode you can use the following PowerShell commands:

$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component HubTransport -State Draining -Requester Maintenance
Redirect-Message -Server $Computer -Target <Other Exchange 2013 Server>

# Prevent DAG member becoming PAM
Suspend-ClusterNode $Computer

# Move all Mailbox Databases and prevent hosting copies on current server
Set-MailboxServer $Computer -DatabaseCopyActivationDisabledAndMoveNow $True
Set-MailboxServer $Computer -DatabaseCopyAutoActivationPolicy Blocked

# Put the Exchange 2013 server in Maintenance Mode:
Set-ServerComponentState $Computer -Component ServerWideOffline -State Inactive -Requester Maintenance

You can verify if the server is actually running in maintenance mode by using the following command in PowerShell:

Get-ServerComponentState $Computer | ft Component,State –Autosize

When the server is in maintenance mode (components are shown as Inactive) you can upgrade the server. When the server is upgraded and rebooted, you can use the following PowerShell commands to get the servers out of maintenance mode:

$Computer = $ENV:ComputerName
Set-ServerComponentState $Computer -Component ServerWideOffline -State Active -Requester Maintenance
Resume-ClusterNode $Computer
Set-MailboxServer $Computer -DatabaseCopyActivationDisabledAndMoveNow $False
Set-MailboxServer $Computer -DatabaseCopyAutoActivationPolicy Unrestricted
Set-ServerComponentState $Computer -Component HubTransport -State Active -Requester Maintenance
Restart-Service MSExchangeTransport
Restart-Service MSExchangeFrontEndTransport

To check if the server is fully up and running again you can use the following command in Exchange Management Shell:

Get-ServerComponentState $Computer | ft Component,State –Autosize

Repeat this for other DAG members (but not all at the same time of course ).

With regards to the TLS 1.2 issue, I will continue to monitor this and when new developments appear I’ll blog about it.

And as a disclaimer: as usual you should thoroughly test Exchange 2016 CU6 (or Exchange 2013 CU17) in a test environment to make sure everything continues to work as expected. Especially when it comes to 3rd party software (think about backup vendors, or anti-virus vendors) you sometimes get unexpected results.