In the most recent Cumulative Update for Exchange (CU13 for Exchange 2013 and CU2 for Exchange 2016), Microsoft has implemented changes that warrant attention. These updates have been available for several weeks, with no major issues reported. Administrators should feel comfortable installing the appropriate update to their environments.
.NET Support
Microsoft now supports .NET 4.6.1 for servers running Exchange 2013 and 2016. You don’t have to remove Exchange before updating to 4.6.1, but the new Exchange CU should be installed prior to the .NET installation. Additionally, the Hotfixes below are required after the .NET update:
Windows Server 2012 – KB3146714
Windows Server 2008/2008 R2 – KB3146716
Windows Server 2013 R2 – KB3146715
SHA-2 Support for Self-Signed Certificates
Until now, any self-signed certificates generated by the New-ExchangeCertificate cmdlet have been SHA-1 certificates. After installation, the command will generate SHA-2 certificates. The installation of the CU will not automatically upgrade the certificates, so administrators must actively issue the new certificate. Note that this is for self-signed certificates only; there is no change to Third party SSL certificate requests, and if your Exchange certificate is a SHA-1 Certificate, it must be upgraded regardless of this change.
Database Activation
With Exchange 2016 CU2, Microsoft has made a change in the way Exchange treats activation preference in a Database Availability Group. This change is subtle but requires attention as it conflicts with previous behavior.
Prior to Exchange 2016 CU2 the activation preference property for a database it mattered little which server a database would actually mount on during a failover event. It acted as a “Tie breaker” during the best copy selection process such that if all other factors were equal, a DB copy with the higher activation preference (lower number = higher preference) would activate. Once activated, an administrative action (manual or scripted re-distribution) or another failover event would be required before a database copy with a higher activation preference was activated. In the case of the latter, an additional – “non preferred” – database would potentially be mounted if best copy selection deemed it the healthier copy.
Beginning with Exchange 2016 CU2, the Primary Active Manager (PAM) in the DAG will perform a periodic evaluation of the active databases and will attempt to redistribute active database copies (via a lossless switchover), such that the healthy database copy that has the highest activation preference will be the active database. The frequency with which this check will be performed is defined by a new DAG property called “PreferenceMoveFrequency.” The behavior can be completely disabled by setting this property to ([TimeSPan]::Zero) and restarting the Microsoft Replication Service on ALL DAG members. The default value for this property is 1 hour.
Some admins may have scripts that run as scheduled tasks to redistribute databases, which can likely be decommissioned once the behavior in CU2 is observed.
It is extremely important to remember this behavior when performing maintenance on servers on which an activation is not desired. In those cases, a database or server activation block will prevent the PAM from activating a database.
For reference, a database can be blocked from activation by running the following command:
Suspend-MailboxDatabaseCopy -Identity <Database Name>\<Server Name> -ActivationOnly
And all databases on a server can be blocked from activation by running the following command:
Set-MailboxServer –Identity <Server Name> -DatabaseCopyAutoActivationPolicy Blocked
This behavior should also be noted when troubleshooting issues. It may mean that the DB that is active now may not have been the active database 1 or more hours ago.
Also note that this is an Exchange 2016 ONLY feature, and installation of CU13 for Exchange 2013 will not change the database activation behavior.
Public Folder Migration Behavior
Finally, the Public Folder Migration issue that was detailed here has been resolved. If you have halted or delayed public folder migrations, you can now safely resume or begin them.