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:
- CVE-2023-21707 – Microsoft Exchange Server Remote Code Execution Vulnerability
- CVE-2023-21706 – Microsoft Exchange Server Remote Code Execution Vulnerability
- CVE-2023-21710 – Microsoft Exchange Server Remote Code Execution Vulnerability
- CVE-2023-21529 – Microsoft Exchange Server Remote Code Execution Vulnerability
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:
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:
- New-SettingOverride -Name „Adding learning location ClientExtensionCollectionFormatter“ -Server <ServerName> -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.
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.
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
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
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.
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.
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.
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
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.
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 ;-)
Der workaround ist ja offenbar nicht überall notwendig. Insofern kann dir das vorab niemand sagen. ;)
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.
Ja das geht per Exchange powershell.
https://learn.microsoft.com/en-us/powershell/module/exchange/new-settingoverride?view=exchange-ps
Gerade den Workaround auf einem Ex2019 installiert. Die genannte Fehlermeldung ist immer noch da!
Sorry, hatte überlesen, dass die Fehlermeldung bleibt. Laut Microsoft soll die Funktionalität aber gegeben sein
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?
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.
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. ;)
Dann darf ich keinen Patch veröffentlichen ?
genau.
@NorbertFe: Ich schätze deine Expertise im Exchange Bereich sehr, schon lange. Ich habe aber noch nie gelesen dass du irgendetwas von MS kritisierst, warum? Deine Kommentare und Meinungen Richtung MS sind immer zu weich.
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
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).
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.
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. ;)
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
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.
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
Hab ich vorhin auf einem Windows 2012R2 mit Exchange 2016 auch gesehen. Da alles funktioniert, hab ich das erstmal ignoriert.
Das mit dem bin Folder zeigt das Script bei mir auch an. Ebenfalls 2012R2 + Exchange 2016
Habe das erstmal so wie Norbert gehandhabt und ignoriert weil sowohl ECP als auch OWA funktionieren.
Der Lösungsansatz im KB Artikel klingt so als ob danach wirklich was nicht mehr funktioniert…
Selbes „Problem“ mit 2012R2 + Exchange 2016. Scheint ein Fehler im HealthChecker zu sein.
Fehler ist nun zumindest gemeldet: https://github.com/microsoft/CSS-Exchange/issues/1506
Bei mir sind es übrigens Server 2019 mit Ex2019
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.
ICh hatte heute eine volle mail.que
Der Wert war bei mir auf 10 Tage eingestellt. Default ist wohl 2 Tage. Ich habe nie an diesen Werten etwas geändert.
Wie sieht das bei euch aus?
geändert habe ich es so:
Set-TransportConfig -SafetyNetHoldTime 2:00:00:00
Danke auch hier wieder an Frank:
https://www.frankysweb.de/exchange-2016-dag-warteschlange-wird-zu-gross-mail-que/
https://www.alitajran.com/mail-que-file-large-in-size-exchange-server/
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?
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.
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.
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.
SUs sind kumulativ, d.h. im Februar Patch ist alles drin. Steht auch so im MS Blog.
Heute auf zwei Exchange 2016 ohne Probleme mit der EXE installiert.
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?
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()
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 :)
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.
Was für ein MS Betriebssystem und Exchange Version setzt Ihr denn ein?
Exchange 2016 CU 23 auf Server 2016. Februar Patchstand.
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
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
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-february-2023-exchange-server-security-updates/ba-p/3741058
Mit der Bereitstellung über den Update Katalog kommt es aktuell wohl zu Problemen
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.
das einfachste wäre den HealthChecker anzupassen. Update ist installiert. von daher!
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!
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.
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
Das selbe Phänomen bei mir. Hab über Windows Update installiert.
Na, da bin ich beruhigt. Ich habe das Update manuell installiert. Merkwürdig.
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.
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?
Es wird nur noch CU23 supported, also ja, updaten auf CU23 dann gibt es das aktuelle SU.
Und im Januar geschlafen? ;) Da gabs das Problem ja auch schon. Wie schon geschrieben. Für Exchange 2016 wird nur noch das letzte CU23 supported und nur dafür gibts noch Security Updates.
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..
2016 CU23: Du hast Buildversion 15.01.2507.021. Ich habe nur Buildversion 15.01.2507.018. Hast du es über Windows Updates geladen?
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.“
2x Exchange 2016 problemlos installiert. Dienste kommen wieder hoch, Outlook holt sich die Autodiscover. Danke!
Welche Buildversion hast du nach dem Update?
15.01.2507.018 oder 15.01.2507.021?
Ich habe 2 x Exchange 2016 – nach dem Update 15.01.2507.021 im Healthchecker und auch unter Programme und Features
Hast du es manuell heruntergeladen und installiert oder über Windows Update?
Ich lade es immer manuell.
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-february-2023-exchange-server-security-updates/ba-p/3741058
Es gibt wohl Probleme mit der Bereitstellung via Katalog
danke, aber der schlaue NorbertFe kommt gleich daher, bloß nicht über Windows Update… ;-)
Hallo Jens, mit der Aussage „Exchange Updates niemals via Windows Update installieren“ hat NorbertFe auch völlig Recht. ;-)
(siehe Update des Artikels)
Beste Grüße,
Frank
Nö ihr macht das schon und heult hier dann rum, dass das sonst ja nie Probleme gibt. ;)
Ich sehe es wie Norbert
Ich wähle den bewährten Weg.
Bin kein Freund über Windows Update – aber das ist meine Meinung
Gerade auf 2x Exchange 2016 aktuelles CU via Windows Updates installiert keine Probleme.
Erhalte leider die Fehlermeldung 0x80070643 – Exchange 2019
Nur nicht zu ausführlich, man wäre fast versucht zu helfen. ;) wo/wann bekommst du den Fehler? Was genau hast du gemacht?
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.
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.
Gerade auf 5 Exchange 2019 (3x Edge 2x Mailbox) installiert. Lief problemlos.