Released: February 2019 Quarterly Exchange Updates
Published Feb 12 2019 10:00 AM 106K Views

Today we are announcing the availability of quarterly servicing updates, cumulative and update rollups, for all supported versions of Exchange Server. Exchange Server 2010, 2013, 2016 and 2019 all receive an update package. These updates include important fixes to address vulnerabilities being discussed in blogs and other social media outlets. While it is not the normal or preferred practice to release security updates in a cumulative update package, the nature of the product changes dictate that they be delivered this way as they include changes to the setup and configuration of Exchange Server. Additional details and recommended customer actions follow.

Changes to Exchange Web Services Push Notifications

An architectural change to Exchange Web Services (EWS) Push Notifications authentication is included in all packages released today. KB4490060 outlines the details of the changes made. Customers who rely upon Push Notifications, should understand the important changes made. We have evaluated the changes to push notifications against many commonly used EWS clients, e.g. Outlook Mac, Skype for Business Client, native iOS mail clients and observed no loss of functionality due to these changes. EWS Pull and Streaming Notifications functionality are unchanged by today’s updates. The update to EWS Push Notifications is considered a critical security update and customers should deploy the update as soon as they understand and accept any potential impact. The change in Push Notification authentication is a permanent change to the product and necessary to protect the security of an Exchange Server. After applying either the cumulative update or update rollup to a server, customers are advised to force a reset of the Exchange servers’ credentials stored in Active Directory. This can be accomplished using the Reset-ComputerMachinePassword cmdlet in PowerShell 5.1 or later. If PowerShell is not an option, netdom can also be used. Microsoft knows of no instances where machine accounts have been compromised. Updating a machine account password is considered a best practice to ensure the security of the server is not compromised. In addition, customers are encouraged to evaluate if their user password expiration policies are appropriate for Exchange enabled accounts.

Decreasing Exchange Rights in the Active Directory

The Exchange team has determined a change in the Active Directory rights granted to Exchange Servers using the default Shared Permissions Model is in order. Changes in the latest cumulative updates, described in KB4490059, reduce the scope of objects where Exchange is able to write security descriptors in the directory. In order to apply these changes, a directory admin will need to run the cumulative update setup program with the /PrepareAD parameter. When multiple Exchange versions co-exist in a single Active Directory forest, the cumulative update matching the latest version of Exchange deployed should be used to run /PrepareAD. Setup will automatically run /PrepareDomain in the domain where /PrepareAD is executed. Environments with multiple domains in the forest will need to run the cumulative update setup program using the /PrepareDomain parameter in all domains in the forest. These steps will update the rights granted to Exchange Servers in the Active Directory to meet the new permissions scope. More information on /PrepareAD and /PrepareDomain is available at this link. Customers running only Exchange Server 2010 will need to follow the instructions in KB4490059 to update their environments. The update rollup package released for 2010 will not apply the directory changes. The directory updates described in KB4490059 are fully compatible with all versions of Exchange Server regardless of cumulative update or update rollup version deployed. There is no loss of product functionality associated with these updates. The rights granted to Exchange in Active Directory using the Active Directory Split Permissions Model are unchanged by the updates released today.

Shared Permissions vs. Split Permissions Model

Early advisories released by Microsoft related to this vulnerability indicated that Active Directory Split Permissions Model was a possible mitigation to Domain Admin elevation. It is true Split Permissions affords additional directory protection over the Shared Permissions Model. However, Microsoft fully supports both modes of directory operation and recognizes that there are relative strengths and weaknesses inherent to both models. Before implementing a change of this type, customers should fully evaluate the impact to line of business processes, security and operational needs. The changes released today improve the security profile of the Shared Permissions Model, while retaining the administrative flexibility it affords. The combination of the directory permission changes and EWS security change provides the best possible protection against possible attacks, meaning that Active Directory Split Permissions are not required, but still optional.

Removing Legacy Auth protocols from Exchange Servers

The Exchange team has been hard at work adding a feature to limit legacy authentication mechanisms on a user by user basis. In Exchange Server 2019 Cumulative Update 1, we are announcing new cmdlet support to create organization policies that restrict legacy authentication protocols. Policies can be defined which restrict legacy authentication on a per protocol and user by user basis. The capabilities added are based upon the same functionality already available in Office 365. In the days ahead, we will release additional details on this blog concerning this exciting new feature.

Release Details

The KB articles that describe the fixes in each release and product downloads are available as follows:

Additional Information

Microsoft recommends all customers test the deployment of any update in their lab environment to determine the proper installation process for your production environment. For information on extending the schema and configuring Active Directory, please review the appropriate Microsoft Docs documentation. Also, to prevent installation issues you should ensure that the Windows PowerShell Script Execution Policy is set to “Unrestricted” on the server being upgraded or installed. To verify the policy settings, run the Get-ExecutionPolicy cmdlet from PowerShell on the machine being upgraded. If the policies are NOT set to Unrestricted you should use the resolution steps in KB981474 to adjust the settings. Reminder: Customers in hybrid deployments where Exchange is deployed on-premises and in the cloud, or who are using Exchange Online Archiving (EOA) with their on-premises Exchange deployment are required to deploy the currently supported cumulative update for the product version in use, e.g., 2013 Cumulative Update 22, 2016 Cumulative Update 12 or 11. For the latest information on Exchange Server and product announcements please see What's New in Exchange Server 2016 and Exchange Server 2016 Release Notes. You can also find updated information on Exchange Server 2013 in What’s New in Exchange Server 2013, Release Notes and product documentation available on Microsoft Docs. The updates released today will replace the quarterly servicing updates originally planned for March. The next planned set of quarterly updates is targeted for delivery in June. Important: To avoid a setup failure, it is necessary to install the Visual C++ 2012 runtime before installing Cumulative Update 22 or Cumulative Update 12 on Edge role if not already present.

Note: Documentation may not be fully available at the time this post is published.

The Exchange Team
123 Comments
Not applicable
I don't see the necessity to make the Exchange Server 2019 CU1 download only available via the VLSC. Getting Product Keys from there, ok. But the source? What are we supposed to do when we are testing and don't have a VLSC contract? My company is a Gold Partner...
Not applicable
I'm guessing as it's only available to buy through the Volume channel, MS is restricting the bits.
Not applicable
Hi Christian,

MSDN is another source to download when you need the bits for testing purposes.

Not applicable
Can't find Exchange server 2019 CU1 on Action pack Benefits download page (Partnercenter).
Not applicable
Don't see it in my MSDN downloads. Any hints?
Not applicable
Still not on MSDN Platforms aswell
Not applicable
I can confirm its presence here (Partner MSDN): https://partner.microsoft.com/en-us/pcv/partnership/benefits \Software Products
Not applicable
It's only available via Volume Licensing and MSDN. Not the Action Pack.
Not applicable
We'll check into it. Thanks for letting us know.
Not applicable
It's now available through MSDN for me.
Not applicable
So I queried this, got told this: https://twitter.com/OfficeSupport/status/1100069535300894721
Not applicable
After two weeks it is still not on my.visualstudio ... only the RTM.

Any updates and is it not possible to provide it through MS downloads?

Thanks

Christian

Not applicable
Thank you very much, works.
Not applicable
Still Nothing on MSDN. I do not understand why it takes more than a week to publish the Content.
Not applicable
Same here, not on MSDN aswell :(
Not applicable
Any reason why the MSDN download question is left unanswered?

Must we ISV devs worry about future availability of Exchange 2019 for testing?

Not applicable
Still not on MSDN for me (Enterprise).
Not applicable
Hi Greg, I can still not find 2019 CU1 on MSDN (Visual Studio Enterprise). I work for an ISV where we like to test our products on current Exchange versions early to check for regressions. Its a bit frustrating to pay MSDN and not get new versions at least the the same time as our customers. Not your teams fault, I know, but maybe you have a way to pass it on?
Not applicable
"When multiple Exchange versions co-exist in a single Active Directory forest, the cumulative update matching the latest version of Exchange deployed should be used to run /PrepareAD"

If i'm moving to Exchange 2019, can I just run the CU /PrepareAD as part of the 2019 CU1 install, or do i need to go back and apply CU22 to all 2013 boxes as well? I'd rather not go through all that CU updating if necessary as i'll be moving off them soon. But dont want any compatibility issues.

Not applicable
@mark49808: Use the Exchange 2019 CU1 sources to updates your Exchange 2019 Servers and to run Setup.exe /PrepareAD and /PrepareAllDomains but then go to the older servers and install the updates to fix the EWS credential vulnerability. Frank
Not applicable
When running 2016 and 2010 in co-existence, do the 2010 manual steps still need to be done or will the /PrepareAD for the 2016 update take care of it already?
Not applicable
HHante: The Exchange 2013/2016/2019 Setup will modify all the permissions, because these are "full setups". The Exchange 2010RU is "only" a Security Update and will fix the EWS vulnerability only. a "Setup" can modify installation settings. A RU can patches a code problem only but no a setup configuration.

So run the Exchange 2016 Setup with PrepareAD/PrepareAllDomains and don't forget to fix the Exchange 2010 afterwards

Not applicable
Just to be completely clear, the 2016 CU12 will take care of the permission changes needed in KB4490059. The only part we will need to do for 2010 is to apply UR26. Is this correct?
Not applicable
@HHante, that is correct.
Not applicable
Thanks for this full detailed description guys, however still one open question on the vulnerability part.

CVE-2018-8581 initially talked about removing the DisableLoopBackCheck Key:

To address this vulnerability, a registry value which enables NTLM authentication on the network loopback adapter needs to be removed. Future cumulative updates will ensure that this registry setting is configured correctly during installation of the cumulative update.

---

We have removed this key on our EX2016 CU11 Servers to be on the safe side and didn't see any negative side effects so far. Is this key also being removed during CU12 install and the recommendation above still valid even after the changes been implemented with the updates been released today?

Thanks for clarifying!

Not applicable
@Martin, yes the CU's released today should remove this key, if present. The 2010 RU will not remove the key. There's no harm if you have already done this, it will not interfere with CU installation.
Not applicable
Hi Brent. If DisableLoopbackCheck is now being disabled in all 2013+ CUs, why was it still in-place? Does this mean Exchange Server has been unwinding a default security feature that's been around for something like 15 years for no benefit? And why didn't the Exchange team push BackConnectionHostNames guidance as is common in other web technologies like SharePoint?
Not applicable
@Tristan - There have been legitimate reasons for Exchange to enable this. We are hearing some reports of certain Exchange monitoring tools requiring loopback to be enabled. We will look to change the behavior of these cmdlets. But honestly it appears to have been an optimization that was made for reasons that may no longer apply to Exchange code, a long time ago. In general we don't like to change behavior that has existed for a very long time due to the surface area that Exchange covers and the risk of regression. In this case however, closing a security hole made that a requirement. Our preference is to remove dependence on NTLM altogether in the product and that is the work that has been more important to us and that we have been working on.

It is a minor optimization based upon reports coming in from SCOM. We likely have to update our cmdlets, but I don't want to give the impression we haven't tested the cmdlets. It's hard for us to tell in a one-box topology what is real and what isn't when tests fail sometimes.

Not applicable
@Brent. Thanks for the candid reply. I appreciate there's always a balance to be achieved between adaptation and stability, but I think the main concern is that Exchange has been fully disabling the loopback check rather than explicitly whitelisting the Exchange URLs with BackConnectionHostNames, as has been the guidance in the SharePoint, NLB, etc. worlds for over a decade.
Not applicable
Great work on addressing this vulnerability. Thank you!
Not applicable
Just tried CU12 on our Test Edge box that did have vcredist_x64 installed already but the installed failed with:

Error:

The following error was generated when "$error.Clear();

$dllFile = join-path $RoleInstallPath "bin\ExSMIME.dll";

$regsvr = join-path (join-path $env:SystemRoot system32) regsvr32.exe;

start-SetupProcess -Name:"$regsvr" -Args:"/s `"$dllFile`"" -Timeout:120000;

" was run: "Microsoft.Exchange.Configuration.Tasks.TaskException: Process execution failed with exit code 3.

at Microsoft.Exchange.Management.Tasks.RunProcessBase.InternalProcessRecord()

at Microsoft.Exchange.Configuration.Tasks.Task.b__91_1()

at Microsoft.Exchange.Configuration.Tasks.Task.InvokeRetryableFunc(String funcName, Action func, Boolean terminatePipelineIfFailed)".

Not applicable
That is the error you will get if the Visual C++ 2012 runtime is not installed on the Edge Transport server. See the "Important" note in the post above for the link.
Not applicable
@PhageDFU - Edge only requires VC++2012. It sounds like MSI went ahead an uninstalled it due to a reference count issue. If you Install VCRedist again, setup should resume where you left off.
Not applicable
It's about time Microsoft added that to the prerequisite checker - this is not new.
Not applicable
We actually found we had VC ++ 2013 installed as the pre-req for CU10, so I added VC ++ 2012 and the install continued and completed successfully. Thanks for the response!
Not applicable
Agreed.
Not applicable
FWIW - The pre-req is included in the rules. However, pre-reqs run before actions taken by the MSI installer are completed. As Exchange was silently installing the pre-req previously, when we apply the CU upgrade that stops silently installing the binaries, the MSI removes on the next upgrade. This occurs after the pre-req engine has run. So we have a chicken and egg situation, where we detect something is installed that the MSI installer is going to remove. That is why we have the note to make certain that the package is installed before invoking setup to avoid the collision caused by the MSI installer removing the previous version.
Not applicable
we only have a small test environment. has anyone tried the cu22 for Exchange 2013 yet? does it negatively affect smartphone users? Outlook Anywhere?
Not applicable
We would expect that all to work properly after this or any update. If it doesn't we'd like to know.
Not applicable
wow.. i'm gonna sit this one out until somebody from Exchange 2013 cu22 does it.
Not applicable
Thanks for addressing this, and again a load of issues that are fixed in these CU's!
Not applicable
Do you need to run the install with /preparead for all Exchange servers or is it only needed for one of the servers of the same version?
Not applicable
You run it once - using the version that matches the highest version in the org.

If you have 2010 and 2016 in the org - run it once using the 2016 bits.

Not applicable
When running the /preparead command for the 2016 CU12 update i noticed it still says Cumulative Update 11 Unattended Setup.
Not applicable
hanskristian85, you are probably executing the old setup from install directory. This occurs when you do not specify the full path to the executable in powershell. Powershell runs hits in PATH directories before resolving hits in the current directory.
Not applicable
That is probably correct, i think i only supplied the name of the .exe file since my prompt was in the same folder.
Not applicable
I'm a bit confused about the EWS push change.

KB4490060 states:

Note This workaround causes some clients to not function correctly. This includes Outlook for Mac, Skype for Business, native iOS mail clients, and some other third-party clients. It may also include custom LOB applications.

You state in this blog:

We have evaluated the changes to push notifications against many commonly used EWS clients, e.g. Outlook Mac, Skype for Business Client, native iOS mail clients and observed no loss of functionality due to these changes.

So what is it? ;)

Not applicable
They are different things:

The workaround is setting EWS policies. That can have impact on clients. The fix is the change that shipped in our latest updates, as discussed in this blog post. In other words - if one installs the updates, the workaround is not needed. If one implements the workaround, however, there can be an impact to clients.

We are saying that we do not know of issues when customers implement a fix (install updates) but there could be impact if you do not do that but implement a workaround. Does that help?

Not applicable
Any idea on the impact for,

1. iPhone native mail app's push setting for retrieving emails, calendar popup, etc?

2. Any testing done with MaaS360 ?

Not applicable
Taken from the blog post above:

We have evaluated the changes to push notifications against many commonly used EWS clients, e.g. Outlook Mac, Skype for Business Client, native iOS mail clients and observed no loss of functionality due to these changes. EWS Pull and Streaming Notifications functionality are unchanged by today’s updates.

In other words - we do not have an exhaustive list of 3rd party EWS apps and their potential impact, but have not observed any impact to most common client apps. Please see appropriate vendors for that guidance and compatibility with our latest releases.

Version history
Last update:
‎Jul 01 2019 04:35 PM
Updated by: