Neue Sicherheitsupdates für Exchange Server (Februar 2023)

Microsoft hat neue Sicherheitsupdates für Exchange 2013, 2016 und 2019 veröffentlicht. Es werden insgesamt 4 als wichtig eingestufte Schwachstellen behoben. Details zu den geschlossenen Schwachstellen finden sich hier:

Wie zu sehen ist, handelt es sich bei allen 4 Schwachstellen um Remote Code Execution Schwachstellen, die Updates sollten daher möglichst zeitnah installiert werden.

Hier geht es direkt zum Download der Updates:

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU23
  • Exchange Server 2019 CU11 und CU12

Hier findet sich der Artikel aus dem Exchange Team Blog:

Auch meine Seite zu den jeweils aktuellen Exchange Versionen habe ich bereits aktualisiert:

Dort findet sich auch die Möglichkeit, direkt bei Veröffentlichung von Updates eine Mail zu erhalten.

Update 15.02.: Wer das Exchange SU vor dem 15.02.20233 17:00 Uhr via Windows Update installiert hat, darf noch mal ran. Windows Update hat das Januar SU ausgeliefert und nicht das aktuelle Februar SU. Wie schon oft erwähnt ist der sicherste und stabilste Weg für die Installation von Exchange Update, das EXE Paket und nicht der Weg via Windows Update. Dazu der Hinweis vom Exchange Team Blog:

Note: Build availability issues have been resolved. If your server downloaded the February SU via Windows/ Microsoft update before February 15 8 AM Pacific time, you might see the February update be offered again. Installing the updated package will bring your server forward to current February builds (verify using Health Checker after installation). The Download Center .exe update packages were (and still are) correct.

https://techcommunity.microsoft.com/t5/exchange-team-blog/released-february-2023-exchange-server-security-updates/ba-p/3741058

Update 16.02: Nach der Installation des SU kann es auf Exchange 2016 / 2019 Servern zu dem Problem kommen, dass der EWS Application Pool im IIS abstürzt. Im Eventlog wird das Ereignis 4999 mit der folgenden Meldung protokolliert:

E12IIS, c-RTL-AMD64, 15.01.2507.021, w3wp#MSExchangeServicesAppPool, M.Exchange.Diagnostics, M.E.D.ChainedSerializationBinder.EnforceBlockReason, M.E.Diagnostics.BlockedDeserializeTypeException, 437c-dumptidset, 15.01.2507.021.

Der folgende Workaround wurde auf dem Exchange Team Blog veröffentlicht:

1. Create the following regkey in the exchange servers: SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics\DisableBaseTypeCheckForDeserialization
The regkey is ‘string value’ type and needs to have a value of 1.
2. Create the below setting override:

  1. New-SettingOverride -Name „Adding learning location ClientExtensionCollectionFormatter“ -Server <ServerName> -Component Data -Section DeserializationBinderSettings -Parameters @(„LearningLocations=ClientExtensionCollectionFormatter“) -Reason „Deserialization failed“
  2. Force the application of the setting by running the following:
    Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
    Restart IIS app pools.
Neue Sicherheitsupdates für Exchange Server

82 Gedanken zu „Neue Sicherheitsupdates für Exchange Server (Februar 2023)“

  1. Hallo zusammen, letzte Woche Freitag an den Patch getraut..Tests danach alle erfolgreich -> Keine Ereignisse mit der Verbindung zum genannten Crash.

    Am Montag traten dann die Probleme auf -> Im Einsatz 2x Server2019 mit Exchange 2019 in einer DAG-> Unser Add In zum melden von verdächtigen Mails lief in eine Schleife (SoSafe, EWS wird dort genutzt), Mailstore Archivierung lief bei jeden Profil auf dem Server in einen Error, Teams Kalender war kurzzeitig auch nicht erreichbar und zusätzlich die Ereignis Logs auf beiden Mailservern.

    Also Lösung die REG Einträge auf beiden Mailservern gesetzt, anschließend von einem Mailserver den Befehl abgesetzt und die optionalen Befehle noch ausgeführt.
    Danach lief erfolgreich die Archivierung, Teams Probleme weg, nur bei dem Meldebutton haben wir noch ein paar Probleme..Dieser geht bei einem Teil und bei anderen nicht..Hier habe ich einfach noch die Vermutung, dass doch noch die optionalen Befehle ausgeführt werden müssen und es nicht von selber neu startet.

    Antworten
    • Hallo Jens,
      hast du eine Lösung finden können? Wir haben auch das Problem, dass bei manchen das Sosafe Plugin funktioniert, aber bei vielen auch nicht. Der Hersteller verwies uns bisher nur auf den Workaround der hier beschrieben ist, aber natürlich schon durchgeführt wurde.

      Viele Grüße

      Volker

      Antworten
      • Schön das wir wohl doch nicht alleine sind :)

        Auch wir sind an den Hersteller gegangen und haben nur die Antwort bekommen „Workaround einspielen“
        Das ist natürlich wie bei euch schon gleich danach passiert.

        Einzige Änderungen die wir festgestellt haben, dass es bei einem User von Montag bis Dienstag nicht ging und zack aus dem nichts hat der Button wieder funktioniert.
        Das war aber leider nur bei diesem einen User, die anderen haben noch immer die Probleme.

        Ich hoffe hier auf einen Fix von MS in Form eines Patches und dann Abschaltung des Workarounds.
        Weil ich schätze von Sosafe wird nicht viel kommen.

        Einziger Einsatz nochmal zu gucken wäre, dass man den Button nicht über EWS einbindet sondern API.
        Aber das muss ich mir nochmal durchlesen

        Antworten
        • Kann mich euch anschließen. Haben ein ähnliches Setup. Exchange 2019 CU12 in einer DAG mit 2 Servern inkl. SoSafe AddIn und Mailstore. Mailstore machte nach dem Update keine Probleme. Der SoSafe Button hingegen kam nicht wieder. Der Workaround brachte keine Veränderung. Auch die Events 4999 waren nach wie vor vorhanden.
          Viel schlimmer war allerdings, dass über EWS angebundene Postfächer nicht mehr abgerufen werden konnten.
          Update wurde wieder deinstalliert.
          Ich spare mir lieber an dieser Stelle meinen Unmut.

      • Haben noch ein Update erhalten:

        wir hatten bereits die Erfahrung mit anderen Kunden gemacht, dass der Workaround bis zu 7 Tage in Anspruch genommen hat. Um den Prozess ggf. zu beschleunigen, könnte man versuchen das Add-in einmal zu deaktivieren und wieder zu aktivieren.

        Antworten
  2. Update ist installiert (Exchange 2019 CU12 Feb23SU, 15.02.1118.025)

    Im Exchange Health Checker werde ich trotzdem gewarnt.

    Known Issue Detected True

    This build has a known issue(s) which may or may not have been addressed. See the below link(s) for more information.
    Known Issues with Feb 2023 Security Updates: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-february-2023-exchange-server-security-updates/ba-p/3741058

    Kann man wohl getrost ignorieren denke ich mal, wenn keine Probleme auftreten.

    Antworten
  3. Interessanterweise bewegt sich auf unserem Exchange 2016 welcher auf 2012 R2 läuft seit dem Installieren, Reboot und applizieren des Workarounds mit massiv weniger Memory Footprint.

    Antworten
  4. Moin,

    kurzer Tipp zum Workaround oben: Beim „New-SettingOverride“ den „Server“-Parameter weglassen oder alle Server eintragen, falls man (wie wir) eine DAG verwendet. Sonst gilt das eben nur für den einen Server.

    Grüße
    Michael

    Antworten
  5. So heute Abend mal getraut!
    Exchange 2016 CU 23 auf Server 2012 R2.
    „SU Februar 2023“ Update installiert über Windows Update.

    Extra nochmal neu gesucht, damit er auch das aktuelle Update lädt:
    Freigegebene Kalender, Suche usw. funktionieren.

    Build Version wird im Health-Checker richtig angezeigt.

    alles in Ordnung.. und die Exchange Dienste starten nun wieder automatisch, nach dem „Januar SU 2023“ Update wurden diese ja nicht mehr gestartet.

    Hat funktioniert.

    Antworten
  6. Guten Abend, nach den schlechten Erfahrungen habe ich etwas gewartet. Kann man jetzt den Patch installieren und es klappt ggf. dann alles mit dem Workaround, oder doch lieber nochmal warten? Natürlich nicht per WSUS/Windows Update ;-)

    Antworten
      • Bei 1. soll ich einen Reg Key machen – das habe ich verstanden und bei 2. auch einen Eintrag in der Reg oder einen Befehl per die Power Shell oder Exchange Shell abgeben?

        Könnte das jemand mal irgendwie übersetzen?

        1. Create the following regkey in the exchange servers:

        SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics\DisableBaseTypeCheckForDeserialization
        The regkey is ’string value‘ type and needs to have a value of 1.

        2. Create the below setting override:

        New-SettingOverride -Name „Adding learning location ClientExtensionCollectionFormatter“ -Server -Component Data -Section DeserializationBinderSettings -Parameters @(„LearningLocations=ClientExtensionCollectionFormatter“) -Reason „Deserialization failed“

        Force the application of the setting by running the following:
        Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
        Restart IIS app pools.

        Antworten
  7. Also ganz ehrlich. Dieser Fehler mit ews hätte nicht passieren dürfen.
    Hat Microsoft eigentlich keine Qualitätskontrolle mehr?
    Oder wächst denen die Komplexität des Produktes über den Kopf?

    Antworten
    • Sehe ich auch so. Natürlich kann man nicht jeden Eckfall abdecken aber offensichtlich testet MS nicht gründlich genug. Mit einer Test-Farm von ~100 verschiedenen typischen Exchange-Installationen sollten solche Probleme zu finden sein.

      Antworten
    • We are not able to reproduce the crashes with EWS but have received a support ticket with it. The issue is being investigated. The bottom line is – definitely not every install will have this problem. It never cropped up in weeks of testing internally either. But obviously – something is going on. We will update when we know more, at this point I simply do not have anything more to share.

      War die Aussage im exchange teamblog. Offensichtlich ist es eben nicht so einfach. ;)

      Antworten
    • sehe ich genau so. Man muss sich wirklich überlegen ob man den Security Patch installiert und wenn der einen Bug hat die ganze Exchange Umgebung lahmlegt oder den Security Patch nicht installiert und Aufgrund der Sicherheitslücken ein Hacker dann ebenfalls die Exchange Umgebung lahmlegen kann.

      @jcm: Ich sehe das nicht so dass MS nicht jeden Fall abdecken kann. Doch, sie müssen das! Ist mir egal ob die 1 oder 1000 Server testen

      Antworten
      • Was soll ich mich denn über Dinge aufregen, die ich im Normalfall sowieso nicht ändern kann. Wer sich unbedingt aufregen will, kann das ja tun, nur wird das im Allgemeinen eben keine Auswirkungen in der realen Welt zur Folge haben (von Herzinfarkt mal abgesehen). Und nur weil ich in der Öffentlichkeit nu nicht mit wilden Beschimpfungen/Unterstellungen/oder sonstigen starken Worten unterwegs bin, heißt das noch lange nicht, dass ich alles gut finde. Wer mich persönlich kennt, weiß das auch. (Jetzt genug OT).

        Antworten
      • Wobei ich das nicht Installieren des Patches bei dem Februar-SU nicht ganz so kritisch sehe, da die Lücken bisher lt. MS noch nicht in freier Wildbahn ausgenutzt wurden.

        Antworten
        • Grundsätzlich kann ich das zwar nachvollziehen, aber bei Hafnium hat man MS zurecht vorgehalten den Patch zulange zurückgehalten zu haben. Jetzt veröffentlichen Sie rechtzeitig und alle warten drauf, dass nix passiert. Wie sie es machen es ist verkehrt. ;)

  8. Für diejenigen mit Such- / Kalender-, und EWS-Problemen: Microsoft konnte dieses Problem mittlerweile reproduzieren und arbeitet scheinbar an einem Workaround / Fix: „We are currently testing the workaround for the EWS crashing problem and will post more information when we have it. We have reproduced the problem now too. Until the reliable workaround is available, the only way to make this go away is to uninstall the Feb SU temporarily. January SU does not cause this issue.“ -Nino Bilic

    Antworten
    • Jetzt gibts auch einen Workaround:
      https://techcommunity.microsoft.com/t5/exchange-team-blog/released-february-2023-exchange-server-security-updates/ba-p/3741058
      After installation of February 2023 SU, some Exchange 2016 and 2019 customers can see EWS application pool crash with Event ID 4999 with the following error:

      E12IIS, c-RTL-AMD64, 15.01.2507.021, w3wp#MSExchangeServicesAppPool, M.Exchange.Diagnostics, M.E.D.ChainedSerializationBinder.EnforceBlockReason, M.E.Diagnostics.BlockedDeserializeTypeException, 437c-dumptidset, 15.01.2507.021.

      The issue is causing connectivity issues to clients using the EWS protocol. To work around this problem:

      1. Create the following regkey in the exchange servers: SOFTWARE\Microsoft\ExchangeServer\v15\Diagnostics\DisableBaseTypeCheckForDeserialization
      The regkey is ‘string value’ type and needs to have a value of 1.
      2. Create the below setting override:
      New-SettingOverride -Name „Adding learning location ClientExtensionCollectionFormatter“ -Server -Component Data -Section DeserializationBinderSettings -Parameters @(„LearningLocations=ClientExtensionCollectionFormatter“) -Reason „Deserialization failed“
      Force the application of the setting by running the following:
      Get-ExchangeDiagnosticInfo -Process Microsoft.Exchange.Directory.TopologyService -Component VariantConfiguration -Argument Refresh
      Restart IIS app pools.

      Antworten
  9. Könnte eventuell jemand mit dem heute aktualisiertem HealthChecker nochmal seine Server nach dem Update prüfen?
    3 Server erfolgreich upgedatet und zwischen dem 2. und dem 3. wurde der HealthChecker aktualisiert. Dort zeigt er nun
    Bin Search Folder Not Found
    C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\web.config
    an.
    Ich sehe hier jedoch keinen Fehler. IIS Einstellungen korrekt und Verzeichnis alles da.
    Ich vermute daher einen Fehler im neuen Script. Kann das jemand bestätigen?
    HealthChecker Version 23.02.14.1742

    Antworten
  10. Security Update For Exchange Server 2019 CU11 SU10 auf einem Server installiert.

    Danach können Outlook Clients keine Suche auf dem Server mehr durchführen. Und freigegebene Kalender werden nicht mehr aktualisiert.

    Super.

    Antworten
  11. Bisher habe ich die Updates via WSUS installiert. Da das ja nicht soooo optimal sein soll, will ich das ändern und wie exe installieren. Das mit dem Elevated Command Prompt habe ich schon mitbekommen. Wie siehts aber mit der Reihenfolge aus? Erst Windows Updates via WSUS und dann das SU hinterher oder erst das SU und dann die Windows Updates?

    Erst die Windows Updates heisst wahrscheinlich, dass danach ein Neustart fällig ist und erst danach das SU installiert werden kann. Sprich es sind zwei Neustarts fällig.

    Hat da jemand einen Tip?

    Antworten
    • Ich mache immer erst die Windows Updates. Dann zeitgesteuert nachts den Neustart. Anschließend dann manuell den Patch vom Exchange. Anschließend den Neustart. Elevated Command Prompt braucht man mit der Exe nicht mehr, die holt sich die Rechte, die sie braucht. Das war/ist nur nötig, wenn man die Variante mit der .msp benutzt.

      Antworten
    • Am Ende ist die Reihenfolge egal, es sei denn es wäre eine Abhängigkeit von bestimmten Patches gegeben. Ist bei Security Updates afair aber noch nicht vorgekommen.

      Antworten
  12. Hallo zusammen,

    sind die bugfixes vom ExchangeServer 2019 CU 12 Jan23SU im Feb23SU mit drin? Oder lieber doch zuerst das Jan23SU installieren und anschließend das Feb23SU? Habe zum ersten Mal eine SU geskipped. Schande über mich.
    Danke euch für die Antworten.

    Antworten
  13. Installiert auf Exchange 2016 CU23 DAG; Installation lief problemlos durch.
    Uns ist lediglich aufgefallen, dass es jetzt mitunter deutlich länger dauert, einen Kalender eines anderen Postfachs zu öffnen. Zum Teil kommt die Meldung „Kalender xy konnte nicht aktualisiert werden“. Nach mehreren Sekunden bis hin zu wenigen Minuten öffnen sich die Kalender dann doch noch.
    Hat noch jemand das Problem?

    Antworten
    • Hi

      ich habe das gleich Problem. Teams kann nicht mehr auf den Kalender zugreifen. Im Event Log ist seit dem die ID 1325 aufgetaucht.
      /LM/W3SVC/2/ROOT/EWS

      Process ID: 6868

      Exception: Microsoft.Exchange.Diagnostics.BlockedDeserializeTypeException

      Message: Deserialization of type System.MarshalByRefObject blocked due to InDeny at location ClientExtensionCollectionFormatter.

      StackTrace: bei Microsoft.Exchange.Diagnostics.ChainedSerializationBinder.EnforceBlockReason(BlockReason blockReason, String typeName)
      bei Microsoft.Exchange.Diagnostics.ChainedSerializationBinder.BindToType(String assemblyName, String typeName)
      bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.Bind(String assemblyString, String typeString)
      bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.GetType(BinaryAssemblyInfo assemblyInfo, String name)
      bei System.Runtime.Serialization.Formatters.Binary.ObjectMap..ctor(String objectName, String[] memberNames, BinaryTypeEnum[] binaryTypeEnumA, Object[] typeInformationA, Int32[] memberAssemIds, ObjectReader objectReader, Int32 objectId, BinaryAssemblyInfo assemblyInfo, SizedArray assemIdToAssemblyTable)
      bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.ReadObjectWithMapTyped(BinaryObjectWithMapTyped record)
      bei System.Runtime.Serialization.Formatters.Binary.__BinaryParser.Run()
      bei System.Runtime.Serialization.Formatters.Binary.ObjectReader.Deserialize(HeaderHandler handler, __BinaryParser serParser, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
      bei System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Deserialize(Stream serializationStream, HeaderHandler handler, Boolean fCheck, Boolean isCrossAppDomain, IMethodCallMessage methodCallMessage)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.ClientExtensionCollectionFormatter.Deserialize(Stream serializationStream)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionSerializer.TryDeserialize(IUserConfiguration userConfiguration, OrgExtensionRetrievalResult& result, Exception& exception)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.CachedOrgExtensionRetriever.TryDeserializeExtensionsFromCache(OrgExtensionRetrievalResult& deserializationResult)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.CachedOrgExtensionRetriever.Retrieve(OrgExtensionRetrievalContext context)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionDataGetter.GetAllOrgExtensionData(OrgExtensionRetrievalContext context)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.OrgExtensionTable.GetOrgExtensions(IOrgExtensionDataGetter orgExtensionDataGetter, OrgExtensionRetrievalContext retrievalContext, Boolean shouldRetrievePrivateCatalogExtensions, Boolean retrieveOnly1_0)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.InstalledExtensionTable.GetOrgProvidedExtensions(HashSet`1 requestedExtensions, Boolean shouldReturnEnabledOnly, Dictionary`2 masterTableExtensions, Boolean isDebug, Boolean shouldRetrievePrivateCatalogExtensions, String& orgMasterTableRawXml, Boolean shouldReturnECPAddins)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.InstalledExtensionTable.GetProvidedExtensions(HashSet`1 requestedExtensions, Boolean shouldReturnEnabledOnly, Dictionary`2 masterTableExtensions, Boolean isDebug, Boolean shouldRetrievePrivateCatalogExtensions, String& orgMasterTableRawXml, Boolean shouldReturnECPAddins)
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.InstalledExtensionTable.GetExtensions(HashSet`1 requestedExtensions, Boolean shouldReturnEnabledOnly, Boolean shouldFailOnGetOrgExtensionsTimeout, Boolean isDebug, String& orgMasterTableRawXml, CultureInfo culture, Boolean filterOutDuplicateMasterTableExtensions, Boolean shouldRetrievePrivateCatalogExtensions, MultiValuedProperty`1 capabilities, Boolean shouldReturnECPAddins)
      bei Microsoft.Exchange.Services.Wcf.GetExtensibilityContext.GetExtensions(ICallContext callContext, Boolean isUserScope, Boolean shouldReturnEnabledOnly, Boolean shouldFailOnGetOrgExtensionsTimeout, OrgEmptyMasterTableCache orgEmptyMasterTableCache, ExtensionsCache extensionsCache, HashSet`1 requestedExtensions, Boolean isRawXmlRequired, Boolean shouldRetrievePrivateCatalogExtensions, Nullable`1 orgExtensionVersion, Boolean checkForExpiryOfUserCacheOfOrgExtensions, String& masterTableRawXml, Boolean retrieveOnly1_0, Boolean filterOutDuplicateMasterTableExtensions, Version apiVersionSupported, Boolean shouldReturnECPAddins)
      bei Microsoft.Exchange.Services.Core.GetAppManifests.GetExtensionDataList(HashSet`1 privateCatalogAddIns, Version schemaVersionSupported, Boolean shouldIncludeAllInstalledAddIns, Boolean shouldReturnECPAddins)
      bei Microsoft.Exchange.Services.Core.GetAppManifests.c__DisplayClass12_0.b__0()
      bei Microsoft.Exchange.Data.ApplicationLogic.Extension.InstalledExtensionTable.RunClientExtensionAction(Action action)
      bei Microsoft.Exchange.Services.Wcf.GetExtensibilityContext.RunClientExtensionAction(Action action, Exception& exception)
      bei Microsoft.Exchange.Services.Core.GetAppManifests.ExecuteGetAppManifests(Exception& clientExtensionException)
      bei Microsoft.Exchange.Services.Core.GetAppManifests.Execute()
      bei Microsoft.Exchange.Services.Core.ExceptionHandler`1.Execute(IRequestDetailsLogger logger, CreateServiceResult createServiceResult, Int32 index, ExecutionOption executionOption)
      bei Microsoft.Exchange.Services.Core.BaseStepServiceCommand`3.InternalExecuteStep(Boolean& isBatchStopResponse)
      bei Microsoft.Exchange.Services.Core.ServiceCommandBase`1.b__81_0()
      bei Microsoft.Exchange.Services.Core.ServiceCommandBase`1.c__DisplayClass87_0.b__0()
      bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
      bei Microsoft.Exchange.Services.Core.ServiceDiagnostics.SendWatsonReportOnUnhandledException(ICallContext callContext, Action methodDelegate)
      bei Microsoft.Exchange.Services.Core.ServiceCommandBase`1.ExecuteHelper(Func`1 action)
      bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.c__DisplayClass11_0.b__0()
      bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
      bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.SendWatsonReportOnGrayException(Action callback, Action exceptionHandlerCallback, Boolean isGrayExceptionTaskFailure)
      bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.ExecuteHelper(Func`1 multiStepAction)
      bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.b__7_0()
      bei Microsoft.Exchange.Diagnostics.RequestDetailsLoggerBase`1.TrackLatency[TResult](Enum latencyMetadata, Func`1 method)
      bei Microsoft.Exchange.Diagnostics.RequestDetailsLoggerBase`1.TrackLatency[TResult](Enum latencyMetadata, Func`1 method, Double& latencyValue)
      bei Microsoft.Exchange.Services.Core.Types.ServiceTask`1.InternalExecute(TimeSpan queueAndDelay, TimeSpan totalTime)
      bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.c__DisplayClass33_0.b__0()
      bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.LocalTimedCall(Action action)
      bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.ExecuteWithinCallContext(Action action)
      bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.Execute(TimeSpan queueAndDelayTime, TimeSpan totalTime)
      bei Microsoft.Exchange.Services.Core.Types.BaseServiceTask`1.ExecuteLoop(Boolean synchronously)
      bei System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
      bei System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
      bei System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
      bei System.Threading.ThreadPoolWorkQueue.Dispatch()

      Antworten
      • Die gleiche Meldung habe ich auch, gefolgt von WAS 5011. Kalender öffnen klappt zwar, jedoch nicht die Suche im eigenen Postfach, außer man klickt auf „diesen PC durchsuchen“ oder so ähnlich. In einem freigegebenen Postfach funktioniert die Suche problemlos.

        Hab sogar das SU erneut installiert aber leider ohne Besserung. Manuelle Installation per .exe Package über Elevated CMD.

        Alles Murks :)

        Antworten
        • Hab auch nochmal nen Blick in die Ereignisanzeige der Server geworfen. Direkt nach der Installation des Updates fangen die Einträge an. In unserem Fall:

          System-Log Warnung; Quelle: WAS, ID: 5011
          Anwendung-Log Fehler; Quelle: ASP.NET 4.0.30319.0, ID: 1325

          :(

        • Ich hab jetzt das SU deinstalliert und ein Ticket bei Microsoft aufgemacht.
          Momentan sind die Fehler wieder weg und alle können wieder normal arbeiten.

    • Exakt das gleiche Problem bei Exchange 2016 CU23 DAG
      Zertifikat verloren – neu eingebunden
      Kalender- und Teams-Probleme
      System-Log Warnung; Quelle: WAS, ID: 5011
      Anwendung-Log Fehler; Quelle: ASP.NET 4.0.30319.0, ID: 1325
      Quelle: MSExchange CalendarRepairAssistant, ID 24001
      Auch eine wiederholte Installation des SU mit Neustart hat nichts gebracht
      Installiert mit lokal abgelegter .exe im Adminmode

      Antworten
  14. also exchange 2019 CU 12 schön brav versorgt. „Version 15.2 ‎(Build 1118.7)‎“ wird mir schön im ecp angezeigt. alles bestens installtion über exe

    Antworten
    • Scheint nun gelöst zu sein:
      Note: Build availability issues have been resolved. If your server downloaded the February SU via Windows/ Microsoft update before February 15 8 AM Pacific time, you might see the February update be offered again. Installing the updated package will bring your server forward to current February builds (verify using Health Checker after installation). The Download Center .exe update packages were (and still are) correct.

      Antworten
  15. Hallo,

    Installation über Windowsupdate auf Server 2019/Exchange 2019 ohne Probleme. Habe allerdings auch bemerkt mit den Buildnummer passt etwas nicht…
    Im Updateverlauf taucht das Update KB5023038 als erfolgreich installiert auf.
    Der HealthChecker listet es aber am Anfang der Liste nicht mit auf und meckert dann am Ende die 4 CVEs an!

    Antworten
  16. 3x Exchange 2019 CU12 auf Windows Server 2019 und 2019 Core, keine Probleme
    1x Exchange 2016 CU23 auf Windows Server 2012R2, nach dem update Problem beim starten der EMS, Powershell konnte nicht mehr zum Server verbinden, Fehler war: FullyQualifiedErrorId : -2144108477,PSSessionOpenFailed

    Die Lösung war, dass im IIS auf der „Exchange Back End“ Webseite das „Exchange Server“ Zertifikat für https nicht mehr gebunden war.
    Also Zertifikat unter Edit Bindings wieder selektiert und iis neu gestartet.

    Antworten
  17. Merkwürdig, nach der Installation des Updates auf einen Exchange-Server 2019 habe ich die Buildnummer Version 15.2 (Build 15.02.1118.022).

    Eigentlich sollte die Version 15.02.1118.025 angezeigt werden.

    Im Health Checker wird auch gewarnt, dass ich nicht das letzte SU installiert habe. Installiert ist allerdings das Update KB5023038.

    This build has a known issue(s) which may or may not have been addressed. See the below link(s) for more information.
    Known Issues with Jan 2023 Security for Exchange 2016 and 2019: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-january-2023-exchange-server-security-updates/ba-p/3711808

    Hat noch jemand das Problem und weiß wie ich das beheben kann? Vielen Dank

    Antworten
        • Hab das gleiche Problem.
          Deutsche Exchange Version. Manuell will er die (richtige) .25 gar nicht installieren und über Windows Update kommt die .22

        • Irgendwas hat Microsoft gemacht.
          Mein erster Download von Exchange2019-KB5023038-x64-de.exe
          hatte noch den SHA256 Hash 19A1F72086FC2F918787200C9E237FE2B61F2E7B6B90465C5199C68B1DEEE11D

          jetzt hab ichs noch mal runtergeladen und der Hash ist 40F2D1B4376EF3B17B3AE6E5FD00C3A064925D1573D355A51A9BE262C524C9E5

          Bei dem meckert er nun auch nicht mehr das er es nicht installieren kann.

  18. Hi,
    ich habe 2016 CU22 mit dem letzten SU vom November installiert (15.01.2375.037).
    Hierfür finde ich kein neues SU. Weiß jemand, ob das noch kommt oder muss ich auf CU23 updaten?

    Antworten
  19. Installation auf Ex16CU23 / Srv 2016 lief zwar problemlos (.exe Package) aber seither gibt es jede Menge WAS und ASP.NET Fehler im Ereignislog. Die Clients haben scheinbar keine Probleme. HealthChecker zeigt auch die korrekte Version an:
    Version: Exchange 2016 CU23 Feb23SU
    Build Number: 15.01.2507.021

    Könnte ja mal reibungslos ablaufen..

    Antworten
      • Nein, direkt von MS als exe Package. Ich tippe eher auf ein HealthChecker problem, meine da was gelesen zu haben.

        Übrigens gibt es doch ein Problem bei den Clients: die Outlook Suche geht nicht:
        „Da hat etwas nicht geklappt, und Ihre Suche konnte nicht abgeschlossen werden.“ „Es schein ein Problem mit Ihrer Netzwerkverbindung vorzuliegen.“

        Antworten
      • War was spät gestern – sorry.
        OS 2.2023, Dot Net Framework und Exchange Updates werden per Windows Update geladen.
        Letzteren werden installiert, CU Update schlägt mit dem Error Code 0x80070643 fehl.

        Antworten
        • So nochmals probiert.
          Manuell Installiert bringt den Fehler:
          Setup Wizard for Security Update for Exchange Server 2019 Cumultive Update 12 (KB2023038) ended prematurely

          Konnandozeile:
          ERROR: While installing the Exchange Server Update, error 1603 occurred.

          Anschließend ist Exchange nicht mehr lauffähig. Zum Glück habe ich ein Cold Snapshot, den ich nutzen kann.
          Sehr merkwürdeg – bisher nie Probleme mit dem Updates….

          Gibt es irgendwo ein log des Updates, das nähere Infos ergibt….

        • Ja weil die Dienste schon deaktiviert sind. Aktiviere die Dienste und dann nochmal das Setup starten.. dann läufts durch

        • Alle Probleme hier mit Windows Updates. Aber will ja keiner hören, wenn man sagt, machts einfach manuell. Schonmal probiert? Du installierst übrigens ein SU kein CU. ;)

        • @NorbertFE
          Seh ich auch so, aber komischerweise hatte sich heut jemand gemeldet bei dem automatische Updates deaktiviert sind und dann einfach um 8.30 Uhr das EX-Update durch Windows-Update installiert wurde.. das schau ich mir nachher noch an was das war. Das Problem ist tatsächlich auch erstmalig bei demjenigen.

Schreibe einen Kommentar