Released: February 2019 Quarterly Exchange Updates


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

Comments (59)

  1. 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…

    1. Hi Christian,

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

      1. EinmalIM says:

        Don’t see it in my MSDN downloads. Any hints?

        1. We’ll check into it. Thanks for letting us know.

          1. EinmalIM says:

            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?

          2. Anonymous says:
            (The content was deleted per user request)
          3. Rob Hardman says:

            Still not on MSDN for me (Enterprise).

          4. EinmalIM says:

            Any reason why the MSDN download question is left unanswered?

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

      2. Can’t find Exchange server 2019 CU1 on Action pack Benefits download page (Partnercenter).

        1. It’s only available via Volume Licensing and MSDN. Not the Action Pack.

    2. Rob Hardman says:

      I’m guessing as it’s only available to buy through the Volume channel, MS is restricting the bits.

  2. mark49808 says:

    “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.

    1. Frank Carius says:

      @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

  3. HHante says:

    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?

    1. Frank Carius says:

      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

      1. HHante says:

        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?

  4. 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!

    1. @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.

      1. 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?

        1. @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.

          1. @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.

  5. Great work on addressing this vulnerability. Thank you!

  6. PhageDFU says:

    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)”.

    1. 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.

      1. rt3465345 says:

        It’s about time Microsoft added that to the prerequisite checker – this is not new.

  7. Reno Mardo says:

    we only have a small test environment. has anyone tried the cu22 for Exchange 2013 yet? does it negatively affect smartphone users? Outlook Anywhere?

    1. We would expect that all to work properly after this or any update. If it doesn’t we’d like to know.

  8. Thanks for addressing this, and again a load of issues that are fixed in these CU’s!

  9. Harmankardon says:

    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?

    1. 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.

  10. When running the /preparead command for the 2016 CU12 update i noticed it still says Cumulative Update 11 Unattended Setup.

    1. Mike Crowley says:

      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.

      1. That is probably correct, i think i only supplied the name of the .exe file since my prompt was in the same folder.

  11. FrancWest says:

    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? ;-)

    1. Nino Bilic says:

      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?

      1. JT_CP says:

        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 ?

        1. Nino Bilic says:

          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.

  12. I am trying to follow the steps for Exchange 2010 (https://support.microsoft.com/en-us/help/4490059/using-shared-permissions-model-to-run-exchange-server)

    How do I find the place so my LDP looks like the graph in step 5? How do I ‘Find the two “Allow” ACEs that grant “Write DACL”…. ??

    Very incomplete/confusing….

    1. @The Guy – Sorry for our confusion. A certain level of familiarity with LDP was assumed in the KB. You can find the security descriptors after you have chosen Tree View, if you right click on the Domain object at the root of the tree in the left pane, then choose ‘Advanced’ from the right click menu, followed by ‘Security Descriptor’. You can then click on the ‘Trustee’ column header to sort the entries as appears in the image in the KB.

      1. found it, thanks for the concise instruction!

  13. For Exchange 2016 there are two different prerequisites/requirements for .net

    KB4471392
    This cumulative update requires Microsoft .NET Framework 4.7.1.

    Support Matrix (https://docs.microsoft.com/en-us/exchange/plan-and-deploy/supportability-matrix)
    for Exchange 2016 CU11 or later only .NET Framework 4.7.2 is supported

    1. Nino Bilic says:

      Thanks! Yes we are aware that this table needs some updates. As we announced before (in October: https://blogs.technet.microsoft.com/exchange/2018/10/16/released-october-2018-quarterly-exchange-updates/) – .NET Framework 4.7.2 is supported now but it is still not required (it is expected to be required starting with the next update).

  14. Exchange 2013 CU22 is reported in Programs and Features as CU20 when installed.

  15. Concerning Exchange rights in Active Directory, only the /PrepareAD parameter is necessary (in a single forest / single domain environment), correct? I do not see anything about upgrading the schema but since *some* cumulative updates do upgrade the schema, I would like to confirm that this is NOT the case with Exchange 2016 CU12. Thank you.

    1. Current CU is CU11, so I’d be going from CU11 to CU12.

      1. Correct on all counts. No schema changes, and in a single domain forest you only need to run /PrepareAD

  16. Paul WWF-UK says:

    We’re running Exchange Online, but we got there via a Hybrid migration – so we are left with an on-prem Exchange Server (2016) just for admin purposes. I’m intending to install 2016 CU12. But I wonder – should we be upgrading this box to Exchange Server 2019, or replacing it with an Exchange 2019 server? And if not now, when will we need to do this?

    1. rt3465345 says:

      Not sure why you are asking here – but Exchange does not support in place upgrades so you would have to replace it to update. The support lifecycle for Exchange 2016 is published.

    2. Nino Bilic says:

      No, you do not need to worry about updating this machine to Exchange 2019. Just leave it be as an Exchange 2016 server, keep up with updates and you are good to go.

  17. benoit krier says:

    We have a Top domain yyy.zzz and we have exchange oragnization 2016 CU11 installed in the below sub-domain xxx.yyy.zzz . (several server)
    Where should I execute the prepareAd (setup.exe /IAcceptExchangeServerLicenseTerms /PrepareAD) ?on the exchange server or in a DC of the sub domain or in a DC of the top domain ?

    Same question for the /preparedomain (Setup.exe /PrepareAllDomains /IAcceptExchangeServerLicenseTerms) ? on an exchange server or in a DC of the top domain or in a DC of the sub-domain ?

    Thanks

  18. Hi
    I’ve looked for Pull subscription in EWS log and found
    – subscriptions from our Lync (S4B) servers (~ 5000);
    – subscriptions made by Spark e-mail client.
    How the update affects S4B functionality (interaction between S4B and Exchange)?
    We are using on-premises Exchange 2016 and S4B (Lync/6.0.9319.534/Storage – user agent in logs).

    1. Nino Bilic says:

      We have observed no issues with Skype for Business after this update is installed. Note that if a workaround was implemented instead (EWS policy modification) that might be different. But update does not impact the interoperability with Skype for Business per our results.

  19. benoit krier says:

    Hello,

    I read this well described documentation, especially the EWS part.

    You stated that you evaluated the changes to push notifications against mainly commonly used EWS clients , Outlook MAC, S4B,native IOS mail clients .

    Have some third party partner tested the exchange 2016 CU12 , I thinking especially to the Blackberry UEM 12.9.x

    1. Nino Bilic says:

      For compatibility with 3rd party products, please check with a particular 3rd party vendor. We do not validate 3rd party product functionality.

Skip to main content