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 (115)

  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. Rob Hardman says:

            Still not on MSDN for me (Enterprise).

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

          4. Same here, not on MSDN aswell :-(

          5. andreveit says:

            Still Nothing on MSDN. I do not understand why it takes more than a week to publish the Content.

          6. Rob Hardman says:

            It’s now available through MSDN for me.

      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.

          1. EinmalIM says:

            Thank you very much, works.

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


    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:

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

      1. PhageDFU says:

        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!

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

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

  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.

      1. Reno Mardo says:

        wow.. i’m gonna sit this one out until somebody from Exchange 2013 cu22 does it.

  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 (

    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

    This cumulative update requires Microsoft .NET Framework 4.7.1.

    Support 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: – .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.

    1. @Sander Siemonsma addresses the issue of CU22 being displayed as CU20

  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

        1. Johnny_Yao says:

          Hi sir

          If I upgrade E2016 CU10 to CU12 directly, DO I need to prepareSchema before prepareAD/Domains?
          I’m not followed CU11 details.

          Thanks in advanced!

          1. @Johnny_Yao – You don’t need to run /PrepareSchema separately if you are using /PrepareAD. /PrepareAD will automatically apply any changes that /PrepareSchema would apply if they are required.

  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 ?


  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.

    2. nkpurohit says:

      @Dmitry Horushin – Do you mind sharing your experience with Spark email client if you have already performed the upgrade ?

      1. Hi,
        The upgrade is postponed. I asked for help the Spark support and my colleague who is responsible for Skype4Business servers.
        The only thing I’ve found on the Spark site is

      2. Hi

        The Spark support team believes that the update will not affect the mail client.

        “Thank you for your patience while waiting. We believe that this update should not influence the performance of push notifications in Spark. At the moment all is well on our side.”

  19. benoit krier says:


    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.

  20. Ex365 says:

    I see same in my lab test “Microsoft Exchange Server 2013 Cumulative Update 20” 15.0.1473.3

    1. @EX365 – We are aware of this issue. As your version number is correct, you have successfully applied the update. This is an error on the part of the installer to update the product string correctly.

      1. Ex365 says:

        Q….is MS is going to release a new CU22 install file because of this? i”masking before we will install in prod…currently im only testing in the lab, if there will be a new revision I will wait for production install

      2. MichaelAdyne says:

        @Brent – is this going to be fixed?

  21. Abyss46 says:

    Can you please confirm the prerequisite if we need to apply “Visual C++ Redistributable Packages for Visual Studio 2013” as mentioned in OR “Visual C++ 2012 runtime” as mentioned in this blog?

    Also, we are upgrading from CU20. I’ve seen two comments saying this upgrade appears as “Microsoft Exchange Server 2013 Cumulative Update 20” 15.0.1473. Can this be fixed soon?

    1. @Abyss46 – Mailbox Servers require VC+2013 to be installed. Edge Servers require VC++2012 to be installed. We are aware of the Product Description appearing incorrectly in Control Panel. Unfortunately, to resolve this we would have to re-release the Cumulative Update and this would create problems for customers who have already installed it. We have no plans to re-release the package at this time.

      1. Abyss46 says:

        Our environment is Exchange 2013 CU20 Multi-Role (CAS/MBX) Servers but our Edge Servers are Exchange 2010 SP3 RU21. So in this scenario, for both our Exchange 2013 and Exchange 2010 servers, I will apply VC++2013. Can you please confirm that this is correct? Thank you.

  22. voyciech01 says:

    I noticed a problem with logging to OWA by users with an expired (but correct) password. Last week I installed RU26 for Ex2010SP3 and I made the AD changes described in KB4490059. Until now, everything worked OK. Since last week users with the expired password receive a standard wrong-password-error message, instead of the form forcing the password change. The password change available in the OWA options works correctly (but is not available to people with the expired password, because they can’t sign in). Exchange 2010 only. Enyone else?

  23. Pavel Jirka says:

    Exchange 2013 CU22 setup failing on error 1603:

    Installing product C:\Install\Ex13CU22\exchangeserver.msi failed. Fatal error during installation. Error code is 1603. Last error reported by the MSI package is ‘Error reading from file: C:\Install\Ex13CU22\Setup\ServerRoles\ClientAccess\Sync\Bin\Microsoft.Exchange.AirSyncHandler.dll. Verify that the file exists and that you can access it.’.

    Btw. the file Microsoft.Exchange.AirSyncHandler.dll is in installation directory, PS execution policy is unrestricted, checksum of the CU file matches – I tried to redownload the CU and still the same error :-(

    Windows Server 2012 R2, .Net Framework 4.7.2, previous CU is 21.

    Do you have any ideas how to solve this?


    1. The same environment, the same issue.
      I checked execution policy, C++runtime, nothing helped me.
      any solution?

      Installing product e:\EXCU22\exchangeserver.msi failed. Fatal error
      during installation. Error code is 1603. Last error reported by the MSI package
      is ‘Error reading from file: e:\EXCU22\Setup\ServerRoles\ClientAccess\S
      ync\Bin\Microsoft.Exchange.AirSyncHandler.dll. Verify that the file exists and
      that you can access it.’.

      Thank you

    2. I have the same problem with Slovak regional settings.
      After change all regional settings to English, the problem was solved.

      1. Pavel Jirka says:

        I found another workaround. You can use ProcMon utility to monitor which files could not be copied where and then manually copy the files from setup files to destination. In my case, I had to copy 7 files and create one folder. Please see orignal thread

      2. @michal.chovan
        It was the first think what came on my mind, when I saw Czech and Slovak only customers with this issue. I changed regional settings, but it didn’t solve my problem.

        1. Question to Exchange team.
          Are you planning release fixed version Exchange 2013CU22?
          Because we have a lot of customers with EX2013

  24. Ex365 says:

    Q is there is a need to install C++ 2012 ? or C++ 2013 ?

    1. @EX365 – It depends on what you are coming from and the version you are updating. If you applied the October Update for Exchange 2016 or are running Exchange 2019, you should not have to install anything. If you are upgrading from something earlier than either of these versions, you will need to install VC++2012 on Edge Servers and VC++2013 on Mailbox Servers before applying the Cumulative Updates released in February.

      1. Ex365 says:

        Thanks, my env is Ex2013 CU21 separated Roles for CAS/MB/EDGE on all of them currently have C++2013 (x64), so for CU22 i will install C++2012 only on edge…

  25. nkpurohit says:

    “The change in Push Notification authentication is a permanent change to the product and necessary to protect the security of an Exchange Server.” – when does this change take place ? I assume when the first of the servers in Exchange 2016 environment is upgraded ?
    What will be the rollback if there is a critical application that doesn’t like the changes in EWS push notifications ?

    1. @nkpurohit – This change takes effect on a server by server basis as the Cumulative Update is applied to each server. Servers which have not been upgraded will not accrue the benefit of the fix. There is no rollback for this change as this is a deliberate (and required) change in behavior.

      1. nkpurohit says:

        Thank you ! So hypothetically, if a third party application that uses EWS and impersonation rights granted to a service account breaks after the CU upgrade, then I can potentially fix the application by taking the upgraded server out of load balancer for EWS. Correct ?

        1. @nkpurohit – You should only have to remove it from the load balancer if the application mailbox is located on a mailbox server that is also an endpoint for your load balancer. In addition you need to make certain that the application mailbox is not hosted on a database that could be activated on an upgraded server. This would apply to all members of the DAG where the database can be activated (assuming you have deployed a DAG).

          1. nkpurohit says:

            Regarding your comment “In addition you need to make certain that the application mailbox is not hosted on a database that could be activated on an upgraded server.” – Could I have application mailbox’s database copies on two DAG members where one is upgrade and the other one is not ? This way, if thing don’t go well, I can block the activation of the DBs on the upgraded server ?

  26. AndrewD12 says:

    When attempting to execute setup with the /prepareAD switch prior to installation of the update itself I receive the following error.

    Currently running Exchange 2016 CU10.

    The following error was generated when “$error.Clear();
    # O15# 2844081 – Create PartnerApplication “Exchange
    Online” in DC and On-Premise
    $exch =
    $exchApp =
    Get-PartnerApplication $exch -ErrorAction SilentlyContinue -DomainController $RoleDomainController | Where {
    $_.UseAuthServer } | Where { [string]::IsNullOrEmpty($_.IssuerIdentifier)};
    if ($exchApp -eq $null)
    $exchAppName =
    “Exchange Online”;
    $exchApp = New-PartnerApplication -Name $exchAppName -ApplicationIdentifier $exch -Enabled
    $RoleIsDatacenter -AcceptSecurityIdentifierInformation $false -DomainController $RoleDomainController;

    # Create
    application account for Exchange
    $appAccountName = $exchApp.Name + “-ApplicationAccount”;
    $appAccount =
    Get-LinkedUser -Identity $appAccountName -ErrorAction SilentlyContinue -DomainController $RoleDomainController;
    ($appAccount -eq $null)
    $appAccountUpn = $appAccountName.Replace(” “, “_”) + “@” + $RoleFullyQualifiedDomainName;

    $appAccount = New-LinkedUser -Name $appAccountName -UserPrincipalName $appAccountUpn -DomainController
    Set-PartnerApplication -Identity $exchApp.Identity -LinkedAccount $appAccount.Identity
    -DomainController $RoleDomainController;

    foreach ($roleName in (“UserApplication”, “ArchiveApplication”,
    “LegalHoldApplication”, “Mailbox Search”, “TeamMailboxLifecycleApplication”, “MailboxSearchApplication”,
    $roleIdentity = Get-ManagementRole $roleName -DomainController $RoleDomainController;

    $roleAssignment = Get-ManagementRoleAssignment -Role $roleIdentity.Identity -RoleAssignee $appAccount.Identity
    -DomainController $RoleDomainController;
    if ($roleAssignment -eq $null)
    New-ManagementRoleAssignment -Role
    $roleName -User $appAccount.Identity -DomainController $RoleDomainController;
    ” was run:
    “Microsoft.Exchange.Data.Directory.ADObjectAlreadyExistsException: Active Directory operation failed on
    Domaincontroller123. The object ‘CN=Exchange
    Online-ApplicationAccount,CN=Users,DC=X,DC=X,DC=X,DC=X,DC=X’ already exists. —>
    System.DirectoryServices.Protocols.DirectoryOperationException: The object exists.
    System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll
    resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut)

    1. AndrewD12 says:

      FYI – Fixed by removing the Exchange Online-ApplicationAccount from ADUC.

  27. SizeOfQueue says:

    Would there be any negative side effects of running the ” /PrepareAD” now and then, possibly, having to wait an extended period of time (e.g. weeks) before actually updating the servers?
    (Which would be trying to get the effects of the reduced permissions in AD straight away while doing some detective work regarding odd 3d party applications using EWS.)

    1. Stivie says:

      Hi Exchange Team,

      same Question like @SizeOfQueue. Thanks for Answer.

      1. There is no downside to running the /PrepareAD and /PrepareDomain updates while you evaluate deploying the cumulative update packages to servers. We actually encourage this. Realize that this will reduce the permissions that Exchange has on the domain, but will not resolve the vulnerability in EWS until the cumulative update is applied to the servers. You should evaluate deploying a throttling policy to block Push Notifications until the cumulative update is applied to individual servers.

  28. RobK_ says:

    Any news about powershell -verbose switch? Are you going to ever fix this? its been years…….
    Even in your own Office666 it does not work, congrats…

  29. LADORCO says:

    Can’t find Exchange server 2019 CU1 on Action pack Benefits download page

  30. Hamzziiii says:

    I don’t see the necessity to make the Exchange Server 2019 CU1 download only available via the VLSC.

  31. Hi,
    I installed the CU12 on two Exchange 2016 servers (DAG) in a single Domain Enviroment.
    After installation I used the Reset-ComputerMachinePassword cmdlet.

    But I did not use the /PrepareAD parameter. Can I do this now?
    Is it important if I run the setup with the parameter before or after the cu12 installation?

  32. Rajesh Gawai says:

    Exchange 2013 CU22 upgrade stuck at Mailbox Role : Unified Messaging Service (91%). Deleted “Action” and “WaterMark” registry key’s from Unified Messaging role and re-ran setup but again stuck at same stage. application event id 1040 is not logged for “umLanguagepack.en-us.msi”.

  33. Mayimbe says:

    I have Exchange 2013 CU21 multiple-role servers and I’m about to apply latest CU22. I have couple of questions:
    1) Do I need to run Setup.exe /PrepareAD or just simple execute Setup.exe?
    2) I have Visual C++ 2012 Redistributable (x64) – 11.0.60610 & Visual C++ 2013 Redistributable. Do I still need to apply latest Visual C++ 2012 updates indicated above? Thanks.

  34. Jason_L. _ says:

    It seems that Exchange 2010 Update Rollup 26 has broken EWS functionality with Outlook 2016 and Outlook 2019. This appears to be causing continuous password prompts for some users in Outlook 2016 & 2019. Analyzing the traffic with Fiddler shows a 500 error accessing the EWS URL with Outlook 2016. Further inspection of the EWS traffic shows the error “The specified server version is invalid” when using Outlook 2016. Outlook 2013 does not seem to have an issue, and the traffic does not show this error, it shows the version number that is returned from the server, MajorVersion=”14″ MinorVersion=”3″ MajorBuildNumber=”442″ MinorBuildNumber=”0″ Version=”Exchange2010_SP2.”

  35. Vasily T says:

    We’ve hit an issue where a powershell script running on Exchange server using a separate domain account could no longer send email via Send-MailMessage after the update. There was an authentication error message logged.

    I think this is related to CVE-2018-8581 and DisableLoopBackCheck key, because Send-MailMessage uses ntlm auth only. The solution was to move this monitoring script to a different server.

  36. NathanHD says:

    Since implementing CU12 for Exchange 2016, in both our lab and production environments, we occasionally receive an authentication prompt when accessing the ECP. It’s frustrating to diagnose : ) Anyone else with this? No doubt I’m missing something in my knowledge on how the CU changed things with authentication.

    1. NathanHD says:

      I see, seems to be the CVE-2018-8581 and DisableLoopBackCheck key thing and only happens when the server connects to itself. And I guess, accessing the ECP from one of my exchange servers is bad practice anyway. All good.

  37. Good changes and updates…Thank you

Skip to main content