Today was a big day for Exchange updates. Not only did we get Cumulative Update 9 for Exchange 2016, but we also got Cumulative Update 20 for Exchange 2013. Exchange 2010 also receives a critical security update in rollup 20.
As always, test these updates in a lab first! I recommend checking out this 7-part guide on configuring Exchange in your lab. It doesn’t take much to get one going.
The updates are as follows:
So, what’s new in these Cumulative Updates?
The March 2018 updates introduces full support for TLS 1.2. This is critical because in future updates Exchange will disable support for the older TLS protocols. TLS 1.2 boasts significantly stronger ciphers than its predecessors by introducing SHA-256. For a great comparison on the differences between each version of the protocol I recommend the article TLS 1.2 vs TLS 1.1 by KeyCDN.
Disabling the older TLS protocols does present some challenges. As mentioned in my article Disabling TLS 1.0 may cause Outlook to crash, older operating systems such as Windows 7, will require additional registry hacks and tweaks to work in a pure TLS 1.2 environment. Before disabling TLS 1.0 in your environment you may want to look at the state of your client operating systems as a whole and determine if a project to upgrade to Windows 10 should be tackled first. TLS support is based on what the operating system can do and not the Outlook client.
I highly recommend checking out Brian Day’s series on transitioning an Exchange organization to TLS 1.2.
These updates also contain security and bug fixes. Check the appropriate KB article above for a list of issues each update resolves.
The previous cumulative updates added support for .NET Framework 4.7.1. While optional now, 4.7.1 will become a mandatory requirement in the June 2018 updates. This can make your upgrade path a little tricky if you typically stay behind on cumulative updates.
We saw similar cases with previous cumulative updates, where CU15 added support for .NET 4.6.2 but then CU16+ mandated the installation of .4.6.2. The challenge was that you needed CU15 before you could install 4.6.2 and, you needed 4.6.2 before you could install CU16 or later. The problem is that CU15 is no longer publicly available. The good news is that you can still get this download by opening a case with support.
Alternatively, Microsoft added this statement to the Exchange supportability matrix.
This doesn’t exactly make me feel warm and fuzzy. Especially as certain combinations of .NET and Exchange have been reported to quarantine mailboxes. The only recommendation I can make is that if you can’t stay up to date on updates is to at least download and store the bits as they become available.
To navigate the cumulative update path I recommend the article Upgrade Paths for CU’s & .NET by Michel de Rooij.
As a reminder, the September cumulative update had introduced a forest functional requirement of Server 2008 R2. This means that if you are upgrading from CU6 or earlier all domain controllers in the forest must be running Server 2008 R2 and higher. Exchange 2013 CU20 can still be installed in a forest functional level of Server 2003.
Exchange 2016 Cumulative Update 9 does not include schema updates. If upgrading from CU 7-8 then there are no schema changes. However, if migrating from CU 6 or earlier you will need to perform a schema update.
Exchange 2013 Cumulative Update 20 does not include any schema updates. If upgrading from CU 7-19 then there are no schema changes. However, if migrating from CU 6 or earlier you will need to perform a schema update.
In addition to the schema, you will want to run SETUP /PrepareAD to get the latest RBAC definitions. The graphical setup performs this step automatically assuming you have permissions.
More Awesome News
Back in December Microsoft announced it was adding support for Email Address Internationalization (EAI) in Office 365. As of February 26th this support has been rolled out to all Office 365 tenants. In addition, this support has also been rolled out to anyone on the consumer Outlook.com product. Microsoft further announced that EAI support will be coming to Exchange 2019, which is scheduled to ship in the second half of 2018.
EAI support allows for users in Office 365 to send and receive messages to and from email addresses with internationalized characters sets. Previously support only existed for Latin characters sets. EAI allows email addresses to contain Greek, Chinese, Japanese, Cyrillic and Hindi characters. While this advance adds support for the transmission of email to and from internationalized addresses, it does not permit internationalized domains to be registered for use within Office 365. Nor does it permit Office 365 mailboxes to have internationalized characters in their email address. This support will likely come later.
Microsoft has announced that they are retiring the app, OWA for iPhone, iPad and Android. This app was the precursor to the more popular app, Outlook for iOS and Android. Outlook for iOS and Android was an app Microsoft acquired during the purchase of Accompli back in 2014. After that purchase, all development quickly shifted away from the Microsoft app in favor of the Accompli app. The OWA app has not been updated for quite some time. Some important dates to note:
- The OWA app will be unavailable to download from both the iTunes and Google Play store as of April 2018
- Users of the OWA app will see an in-app notification with a download link to the Outlook app starting in April 2018
- After May 15th 2018 the OWA app will cease to function
With only around 90 days before the app completely shuts down it is time to migrate to Outlook for iOS or Android.
Microsoft has also released the parameter PermanentlyClearPreviousMailboxInfo for the Set-User cmdlet. This parameter fixes a scenario where you have duplicate mailboxes for a user in a hybrid environment. For example, before migrating a user from on-prem to Office 365 you license the user for Exchange Online. However, during this process you discover Office 365 has incorrectly created a brand new empty mailbox in Exchange Online. This not only creates two mailboxes for the same user but also causes routing issues for the original mailbox. This can happen when the Exchange GUID of the on-prem mailbox is not correctly synchronized to Office 365 for that user.
Previously, to resolve this issue you would have to remove the user from Office 365. This could be particularly challenging if you had migrated other workloads for that user to Office 365 (such as OneDrive). For example, removing that user would remove both the empty mailbox and their OneDrive data. With this new parameter you can now completely kill the duplicate empty mailbox without affecting other workloads. Keep in mind that you may want to check the mailbox first to export any incorrectly delivered messages.
Microsoft had originally announced that the TLS 1.0 and 1.1 protocols in Office 365 would be disabled on March 1st, 2018. This has since been postponed to October 31st, 2018. In preparation for this date, I highly recommend reading the blog series Exchange Server TLS guidance, part 1: Getting Ready for TLS 1.2. In this post the Exchange team outlines the software updates needed on-prem to both prepare for TLS 1.2 and disable the older TLS protocols. This is a critical read if you operate a hybrid environment.
The Exchange team has also published guidance regarding the Spectre and Meltdown vulnerabilities which can be found here.
David Paulson has also made some changes to his excellent Exchange Log Collector Script. This can save you a lot of time and I highly recommend checking it out.
Lastly, if you were unable to attend Ignite I recommend checking out my post, 15 Microsoft Ignite sessions every Exchange admin should see. I have included notes for each session and the time each topic starts, so you can quickly skip to the content that interests you most. It’s also a great primer for Ignite 2018, which is only 6 months away.
We need your help – Universal Signatures
Fellow MVP, Jeff Guillet, has recently been the spearhead for an initiative to get universal signatures developed. The outcome of this initiative is two-fold.
- When a user sets a signature on one device that signature should be synchronized across all devices (desktop, mobile, web app)
- A signature should be stored in the mailbox so it is not lost if a device is wiped or an Outlook profile is recreated
We need your help! If you think this is an awesome feature please vote for it on UserVoice. It only takes a few seconds. The Exchange and Outlook product groups truly notice and take action on the requests made here. Please vote here.
You can read more about Jeff’s initiative on his blog.
So what do you think is coming next? What would you like to see? Drop a comment below or come join the conversation on Twitter @SuperTekBoy.