Blog Post

Exchange Team Blog
3 MIN READ

Re-release of November 2024 Exchange Server Security Update packages

The_Exchange_Team's avatar
The_Exchange_Team
Icon for Microsoft rankMicrosoft
Nov 27, 2024

Today we are re-releasing the November 2024 SUs for Exchange Server. The original release of these SUs (released on 11/12/2024) introduced an issue with Exchange Server transport rules stopping after a certain amount of time in some environments. The re-released SUs resolve this issue.

To help you understand how to move forward, in this post we use the following naming convention to distinguish between the original November 2024 SU and the re-release:

  • Nov 2024 SUv1: original November 2024 SU (released on 11/12/2024 with article KB5044062)
  • Nov 2024 SUv2: re-released November 2024 SU (released on 11/27/2024 with article KB5049233)

The following table describes the actions you need to take based on your environment:

If Nov 2024 SUv1…

Then…

was installed manually and you do not use any transport or DLP rules

OR

was installed manually and you had a problem with rules stopping but used some sort of workaround to keep the rules running

it is recommended to install the Nov 2024 SUv2 to gain more granular control over the X-MS-Exchange-P2FromRegexMatch header. Please see the FAQ below.

was installed using Microsoft / Windows update and you do not use any transport or DLP rules,

download and install the Nov 2024 SUv2 (it will not be released on Microsoft / Windows update for automatic installation).

was installed (manually or automatically) and then uninstalled to fix the issue with transport rules,

install the re-released Nov 2024 SUv2.

was never installed,

install the re-released Nov 2024 SUv2.

Download links are updated in the November 2024 SU announcement blog post.

For any additional actions you might need to take after installing the Nov 2024 SUv2, please see the original release blog post. You should always run Exchange Health Checker to see if any additional steps might be needed.

An issue reported during installation in January 2025

Over the last week, we have heard a number of customers with the following problem; please review this KB article if you have an error installing a November SU:

File version error when you try to install Exchange Server November 2024 SU

FAQs

We installed the original Nov 2024 SUv1 manually and had no problems. Do we need to install the Nov 2024 SUv2?
Yes. We recommend installing the Nov 2024 SUv2. Please see below for more details.

We installed the Nov 2024 SUv1 through Microsoft / Windows Update and had no problems. Will our server install the Nov 2024 SUv2 automatically?
No. Please see the Are Nov 2024 SUv2 packages going to be released on Windows / Microsoft update? question below.

What are the differences between the Nov 2024 SUv1 and Nov 2024 SUv2 packages?
The Nov 2024 SUv2 package resolves the transport rules issue introduced in the Nov 2024 SUv1 package. It also adds more granular control for “Non-RFC compliant P2 FROM header detection.”  More details can be found here.

Are Nov 2024 SUv2 packages going to be released on Windows / Microsoft update?
Because of the known issues after the installation (please see this KB article) we have decided not to release the updates on Windows / Microsoft update. While we have not seen many customers have this issue, the fact that the solution to the issue requires manual intervention means that we want our customers to deliberately install Nov 2024 SU packages.

Due to how we install updates, we need the update in the .msp format and not the .exe format. How can we get the .msp if the update is not published to Windows Update Catalog?
Extract the .msp by doing the following: download the .exe package you need to a workstation that does not have Exchange installed and double-click on it. The update will fail to install and display an error message, but a command line window will display where the package was extracted (usually a temporary folder). Copy the .msp file from the temporary folder before dismissing the error message (dismissing the error removes the files from the temporary folder).

The original Nov 2024 SU blog post, applicable CVEs, and our recommended actions post-installation still apply.

The Exchange Server Team

Updated Jan 28, 2025
Version 11.0
announcements
exchange 2016
exchange 2019
on premises
security
  • i_misi's avatar
    i_misi
    Copper Contributor
    Feb 18, 2025

    Neither of the workaround worked for us from here FileVersionError and we opened this MS support case: 2501270050002516 and they suggested to use this CopyMissingDlls  before Nov SUv2 install and it worked in our case (WS2019+E2019 CU14)

  • Daniel_Testarossa's avatar
    Daniel_Testarossa
    Copper Contributor
    Feb 15, 2025

    In my case a still running ForefrontActiveDirectoryConnector.exe was possibly the culprit holding a lock on Microsoft.Exchange.Data.Common leading to the error.

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft
      Feb 14, 2025

      Can you clarify what it means "workarounds do not work"?

      Workaround 2 is the process where you find the process that has an open handle on the file in question. Several things cna happen then: you not find an open handle against the file, or could not follow the steps to get to that informationm or there was an open handle but you could not figure out what the process was?

      • martinthiem's avatar
        martinthiem
        Copper Contributor
        Feb 15, 2025

        Hello Nico! Yes sure and thanks for your Reply! 

        Workaround 1: i restarted multiple times. The Update was already installed and i still cannot install the November SUv2 with the same error

         

        Workaround 2: i check the Processmon and did not have any Results for the Microsoft.Exchange.Data.Common.dll and still cannot install the November SUv2 with the same error.

         

        do you have any other tips to solve this issue?

      • martinthiem's avatar
        martinthiem
        Copper Contributor
        Feb 15, 2025

        Hi, thanks for Feedback. This could help but the process to install a CU does take more time for us... so this is no fast solution for us... 

  • Pixa123's avatar
    Pixa123
    Copper Contributor
    Jan 29, 2025

    Hi,

    i also run into the same problem. 

    Windows Server 2019 Standard

    Two Exchange 2019 CU14 (15.02.1544.004) in DAG

    KB5049615 - installed last week. (Server rebooted twice after that).

    Workaround from the blog doesn't work since all services are started and Automatic.

    • SEANCHIU's avatar
      SEANCHIU
      Copper Contributor
      Feb 05, 2025

      Step 1. the blog script can't bring the Exchange services, so I bring the service up manually. (refer other running server and check every single service )
      Step 2. uninstall the WINDOWS update (2025/Jan) and reboot.
      Step 3. Install the EXCHANGE SU (Exchange2019-KB5049233) and reboot
      Step 4. run windows update and reboot 

      Exchange server up to date and Mail Service back to normal.


  • Wess33's avatar
    Wess33
    Brass Contributor
    Jan 29, 2025

    Nino/Luke.  We have just run into this exact problem on our Exchange 2019 server where the SU install failed due to the Jan 25 OS updates.  Now the services are all in Disabled mode and I'm not sure from the comments if the workaround you introduced actually works or if there is a possibility of corruption? Please confirm how to move forward in this case. Also does this mean that we cannot proceed with installing the SU successfully?

  • falcon4fun's avatar
    falcon4fun
    Copper Contributor
    Jan 27, 2025

    Same with 0x800700B7 error on WS2016 + Exch2016 CU23 base (w/o SU).

    Fixed by:

    1. Restoring services via reg file from backup with  (Tryed .\servicecontrol.ps1 Afterpatch - didn't work for me. Maybe tryed to execute it too late but script doesn't restored correct order, only started all services)
    2. Reboot
    3. Compare inetpub, inetsvr and V15 directories via WinMerge with pre-patch snapshot to verify no corruption on MSI Rollback sequence occured
    4. Remove KB5049993 (will rollback to December patch, even if you have installed KB5049993 on earlier version)
    5. Reboot
    6. Install again November v2 patch again
    7. Reboot
    8. Install KB5049993 again
    9. Reboot

    Funny thing: I've tested installation in testlab 3 times :D All was fine. And only step I've changed: installed Jan OS update :D And "Ah shiiiiiiit here we go again" meme comes into chat :D 

    Service restore file. Extracted via Diff from backup. Still missing 2 services: "Performance Logs & Alerts" and "W3SVC". Set first to "Manual", second to "Automatic". Updated. Added them to reg file too.

    Moreover I've added manualy DependsOnService +MSExchangeADTopology to MSExchangeHM. Not always starting after reboot for me. Maybe my server RAID1 HDDs are too slow.

    Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\FMS]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HostControllerService]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeADTopology]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeAntispamUpdate]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDagMgmt]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDelivery]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeDiagnostics]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeEdgeSync]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeFastSearch]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeFrontEndTransport]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeHM]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeHMRecovery]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeImap4]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIMAP4BE]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMailboxAssistants]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeMailboxReplication]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangePop3]
"Start"=dword:00000003

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangePOP3BE]
"Start"=dword:00000003

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRepl]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeRPC]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeServiceHost]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeSubmission]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeThrottling]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransport]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeTransportLogSearch]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeUM]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteRegistry]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\SearchExchangeTracing]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Winmgmt]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\wsbexchange]
"Start"=dword:00000003

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W3SVC]
"Start"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\pla]
"Start"=dword:00000003

     

    • osozu's avatar
      osozu
      Brass Contributor
      Jan 30, 2025

      same problem nothing helped, im giving up on this, workaround not working 

    • mrcr7's avatar
      mrcr7
      Copper Contributor
      Jan 29, 2025

      Can validate that uninstalling KB5050008 on Windows Server 2019 with Exchange 2019, restart, install November 2024v2 Exchange CU update, restart, install KB5050008, restart and all is well.  

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft
      Jan 27, 2025

      I just updated the blog post with our current understanding of the failure (we did reproduce this). The issue seems to be related to January .NET update having been installed, but the server was not rebooted after installation was completed.

      • Wess33's avatar
        Wess33
        Brass Contributor
        Jan 29, 2025

        Nino, we have just run into this exact problem on our Exchange 2019 server.  Now the services are all in Disabled mode and I'm not sure from the comments if the workaround you introduced actually works or if there is a possibility of corruption? Please confirm how to move forward in this case. Also does this mean that we cannot proceed with installing the SU successfully?

  • 909Pro's avatar
    909Pro
    Copper Contributor
    Jan 25, 2025

    I have a similar experience with KB5049233 and error 0x800700B7. None of the proposed fixes have worked. tried twice under 2 different AD admin accounts. Results were the same each time. Also after each attempt we were left with all exchange services disabled. Along with IIS admin, World wide web and other services we had to re-enable. Then after a reboot all is working again. I will await the next release to see if it fixes the issue.

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft
      Jan 27, 2025

      I just updated the blog post with our current understanding of the failure (we did reproduce this). The issue seems to be related to January .NET update having been installed, but the server was not rebooted after installation was completed.

      • Dan_Withrow's avatar
        Dan_Withrow
        Copper Contributor
        Feb 23, 2025

        I rebooted the Exchange servers before I installed the 2nd release of the patch, still had the same issue.  all exchange services are disabled along with other services, that I had to reset/re-enable.

  • nseh17's avatar
    nseh17
    Brass Contributor
    Jan 17, 2025

    Nino_BilicLukasSMSFT 

    tried to install v2 on exchange server 2016 cu23 with last su installed but it keeps failing with this assembly error.. previous security updates never show this or similar errors, only this time.

    started install with admin cmd and this file is in \v15\Public directory.. key exists in reg under key_classes_root\installer\assembilies\global (multi-string).. also repaired visual c++ redist.. any ideas?

    note- we did not install v1 of this update as it got pulled in time before sccm can find it

    Product: Microsoft Exchange Server -- Error 1935. An error occurred during the installation of assembly 'Microsoft.Exchange.Data.Common,version="15.1.2503.00",fileVersion="15.1.2507.43",culture="neutral",publicKeyToken="31BF3856AD364E35",processorArchitecture="MSIL"'. For more information, refer to Microsoft Help and Support. HRESULT: 0x800700B7. assembly interface: IAssemblyCacheItem, function: Commit, component: {B79F9EB4-6D81-48F3-BC2D-3A0A83C30742}

    • rennstrecke's avatar
      rennstrecke
      Copper Contributor
      Jan 23, 2025

      Same problem here on multiple customers with german OS / Exchange versions. 

      Link to german forum where this problem is discussed. Possible workaround: https://www.frankysweb.de/community/postid/8051/

      • LotharMueller's avatar
        LotharMueller
        Brass Contributor
        Jan 23, 2025

        One idea Nino_Bilic LukasSMSFT rennstrecke 

        According to the german forum:

        Perhaps "add-PSSnapin -Name Microsoft.Exchange.Management.PowerShell.Setup -ea SilentlyContinue" in servicecontrol.ps1 is not done correctly on non-English systems after January Updates. Perhaps with the mentioned assembly error.

        The snapin brings the commands CMDlets "Stop-SetupService" und "Start-SetupService" into the Powershell. I can't test it at the moment, perhaps someone can test it ad-hoc.

        So it would explain that a Alias creation workaround mentioned in the German post makes the setup complete successfully.

        On windows server 2016 with Exchange Server 2016 without January patches it worked an the CMDlets are available in Exchange Powershell.

    • Lukas-B's avatar
      Lukas-B
      Copper Contributor
      Jan 23, 2025

      I have a similar experience with KB5049233 and error 0x800700B7.
      Just a hopeless shot in the dark, I tried applying patch KB5036401 first and then KB5049233 and went through without errors. Maybe helps to you too.

    • Nino_Bilic's avatar
      Nino_Bilic
      Icon for Microsoft rankMicrosoft
      Jan 17, 2025

      Sorry to say, I am not sure that I found anything useful. I found nothing related to specifically this SU, and everything I see indicates that there might be some sort of Windows Update issue on the machine. Note that our updates DO plug into the regular Windows update process / engine (they are .msp files underneath it all) so if there is some sort of issue related to update state on the server, that could explain it. My suggestion is to try running both Setup Assist https://aka.ms/ExSetupAssist (which is not really for SUs but might show if there was a Setup issue before) and Health Checker https://aka.ms/ExchangeHealthChecker .

      • i_misi's avatar
        i_misi
        Copper Contributor
        Jan 26, 2025

        Hello, I have the same issue as the others in 2 different environments too.

        1. OS: W2019 ENG (v1809, 17763.6775), EXCH: 2019 ENG (v15.02.1544.011), 2015-01 OS updates installed, 2 nodes DAG, 1st node no issue, 2nd node: ERROR: While installing the Exchange Server Update, error 1603 occurred.
        2. OS: W2016 ENG (v1607, 14313.7699), EXCH: 2016 ENG (v15.01.2507.039), 2015-01 OS updates installed, single exchange server, same error: ERROR: While installing the Exchange Server Update, error 1603 occurred.

        It's not possible to remove all 2025-01 OS updates so I can't install this SU successfully. Is it worth to open an MS case or just wait maybe you can reproduce this issue and provide any fix later?

  • karil222's avatar
    karil222
    Copper Contributor
    Jan 08, 2025

    Dear Microsoft Exchange team, LukasSMSFT. I'm a bit confused of your comments regarding possible transport and poison queue issues caused possibly by missing or incomplete AES256-CBC configuration.

    You mentioned that all steps in an article https://support.microsoft.com/en-us/topic/enable-support-for-aes256-cbc-encrypted-content-in-exchange-server-august-2023-su-add63652-ee17-4428-8928-ddc45339f99e should be completed, otherwise it might cause problems.

    However, step 2 registry key and Network Service accessrights should be already in place after August 2023 SU. At least what I noticed, new installation of 2019 CU14 does it already, so step 2 could therefore be skipped. Although it would not hurt to do it anyway just in case. Step 3 cannot be done if RMS is not in use. Step 4 says that November 2024 SU enables MSIPC by default so manual configuration of SettingOverride for decryption is not needed. Only Encryption Override needs to be set manually.

    So my question is, how the CBC configuration can be missing or incomplete in a such way that it could crash transport and stuck messages in poison queue? Can missing override for Encryption be a reason? If yes, why it's not builtin to SU similarly as Decryption? I have understood that enabling the CBC was originally optional, required basically only if RMS was in use.

    I'm not confident with existing information that "enabling" CBC (step 2, step 4-6) is a foolproof solution for transport issues.

    Btw, in my test the HealthChecker did not notice missing rights of the Network Service.