[English]Zum 10. Januar 2023 (Patchday) hat Microsoft Sicherheitsupdates für Exchange Server 2013, Exchange Server 2016 und Exchange Server 2019 veröffentlicht. Diese Sicherheitsupdates schließen zwei Schwachstellen (Elevation of Privilege und Spoofing) in dieser Software, haben aber bekannte Fehler und verursachen neue Probleme bei der Installation. Hier ein kurzer Überblick über den Sachstand.
Anzeige
Exchange Januar 2023-Sicherheitsupdates
Microsoft hat für den Januar 2023 die nachfolgenden Sicherheitsupdates für Exchange Server 2013, 2016 und 2019 veröffentlicht (siehe auch Exchange Server Sicherheitsupdates (10. Januar 2023), dringend patchen):
- Exchange Server 2013 CU23, KB5022188
- Exchange Server 2016 CU23, KB5022143
- Exchange Server 2019 CU11, CU12, KB5022193
um die Schwachstellen CVE-2023-21763 und CVE-2023-2176 sowie CVE-2023-21745 und CVE-2023-21762 zu schließen. Die Updates sollen zeitnah auf den Systemen installiert werden, um die betreffenden Schwachstellen zu schließen.
Microsoft Exchange 2013 ist lediglich von der Schwachstelle CVE-2023-21762 (Microsoft Exchange Server Spoofing) betroffen. Nino Bilic von Microsoft gibt hier an, dass die Code-Basis eine andere als für Server 2016/2019 sei, die durch zusätzliche Schwachstellen betroffen sind.
Bei Exchange Sever 2013 und 2016 wird nur noch das aktuelle CU23 angeboten (und nicht mehr das vorletzte). Microsoft begründet dies damit, dass die vorletzten CUs ein Jahr alt seien und daher entfallen seien. Zudem seien die Updates ja kumulativ und auf Exchange Servern mit älteren Patchstand bezüglich der CUs könne das letzte CU23 installiert werden (siehe FAQ zum Patchday).
Probleme mit den Updates
Mit den Sicherheitsupdates vom Januar 2023 treten wohl einige Probleme bei oder nach der Installation auf, die ich nachfolgend kurz im Überblick zusammenfasse.
Webseitenvorschauen in OWA falsch
Webseitenvorschauen für in OWA freigegebene URLs werden nach der Installation der Sicherheitsupdates unter Microsoft Exchange Server 2016 oder Microsoft Exchange Server 2019 nicht mehr korrekt wiedergegeben. Dies ist ein bekanntes Problem, welches bereits bei Freigabe der CUs dokumentiert wurde. Microsoft will dies mit einem künftigen Update beheben.
Anzeige
ECP HTTP-Fehler 500; Dienste down
Im Blog berichtet ein Nutzer in diesem Kommentar, dass er beim Login-Versuch im Exchange Control Panel (ECP, Microsoft Exchange-Systemsteuerung) den HTTP-Fehler 500 erhalte. Ursache sind nicht automatisch startende Exchange Dienste, was wohl auch bei einem Neustart auftritt. Abhilfe schafft alle Dienst manuell neu zu starten, dann sollte die ECP-Anmeldung wieder funktionieren.
MSExchangeADTopology hängt
Bei Exchange 2016 CU23 gibt es unter Windows Server 2012 R2 das Problem, dass der Dienst Microsoft Exchange Active Directory-Topologie (MSExchangeADTopology) nicht mehr automatisch. Dadurch bleiben weitere Dienste hängen – was wohl auch die Ursache für den obigen ECP HTTP-Fehler 500 sein dürfte. Microsoft hat dieses Problem inzwischen hier bestätigt und schreibt:
If Exchange Server 2016 is installed on Windows Server 2012 R2, after installation of the January 2023 SU, the AD Topology service might not start automatically, causing services that depend on it to not start automatically either. To work around this problem, start Exchange services manually. We are investigating this further.
Auch hier heißt es als Abhilfemaßnahme, die Exchange-Dienste manuell neu zu starten. Dann sollte alles wieder funktionieren. Microsoft untersucht das Problem.
Health Checker-Script zeigt Schwachstellen
Nach der Installation des Sicherheitsupdates empfiehlt Microsoft, das Exchange Server Health Checker Script auszuführen. Direkt nach Freigabe der Updates meldete das Script trotz installiertem Update, dass der Exchange Server gegenüber diversen Schwachstellen angreifbar sei (siehe den Kommentar von nak_87). Inzwischen hat Microsoft ein aktualisiertes Health Checker-Script bereitgestellt, welches korrekte Ergebnisse anzeigen sollte.
Queue Viewer startet nicht
Zudem deutet sich in den Kommentaren hier an, dass der Queue Viewer der Exchange Toolbox nicht startet, wenn Certificate Signing für die PowerShell Serialization Payload aktiviert ist.
Hi,
after enabling Certificate Signing of PowerShell Serialization Payload the Exchange Toolbox with Queue Viewer won't start.
The Health Checker Script shows "SerializedDataSigning Enabled" only on Exchange 2016 but not on Exchange 2019.
Mir sind zwei Fälle aus Kommentaren bei Microsoft bekannt, aber die Diskussion ist noch am laufen. Eigentlich sollte der Fehler, der in Microsoft Exchange Server 2016 unter Windows Server 2012 R2 auftritt, mit dem Januar 2023-Update behoben sein. Der Fehler ist vom November 2022-Sicherheitsupdate (SU) bekannt.
Ähnliche Artikel:
Exchange Server Sicherheitsupdates (11. Oktober 2022)
Exchange Server Sicherheitsupdates (8. November 2022)
Exchange Server Sicherheitsupdates (10. Januar 2023), dringend patchen
Probleme mit Exchange März 2022-Updates
Exchange Update-Fehler und -Infos (13. April 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service
Exchange Server 2016-2019: Benutzerdefinierte Attribute in ECP nach CU-Installation (Juli 2021) nicht mehr aktualisierbar
Exchange Health Checker – Script-Erweiterungen von Frank Zöchling
Anzeige
"Auch hier heißt es als Abhilfemaßnahme, die Exchange-Dienste manuell neu zu starten. Dann sollte alles wieder funktionieren. Microsoft untersucht das Problem.
"
Was heißt "manuell starten"?
Wenn die user anrufen, das da was nicht geht macht der Admin ne remote shell auf und gibt dann "sc …." oder so ein?
oder der scheduler testet alle 3 Minuten und startet ein script, das die Dienste zur Sicherheit nachstartet? Das kann doch nicht sein.
Wie soll ein Admin ruhig schlafen, wenn auf "seinem" System ab und zu Dienste nicht starten und er manuell eingreifen muß?
> Wie soll ein Admin ruhig schlafen, …
Kein Admin, der wirklich versteht, welche Risiken er betreut, kann und wird jemals ruhig schlafen.
Die Aussage stimmt leider mal sowas von…
Das macht der heutige Admin so, das er irgendwelche Klicki-Bunti Module dazu kauft.
Wenn es nicht funktioniert ist dieses hakt Zusatzteil schuld.und man muß ein weiteres Teil dazu kaufen.
Und so wird das immer komplizierter, er blickt immer weniger durch.
Auch wird er von Anbietern verarscht.
Ich sah gerade ein Angebot, in dem jemand gegen Aufpreis anbot seinen selbst erfundenen Algorithmus einzusetzen um echte und falsche Bounces zu erkennen.
Der clicki-bunti-Admin weiß nicht was DKIm/Dmark ist und kauft stattdessen dieses Schlangenöl – Modul dazu.
Oha.
Das war früher anders.
Der BOFH sorgte dafür das die Kiste automatisch lief, wusste aber auch wie es funktioniert…
Die große Frage ist doch: Warum startet der Dienst wenn ich ihn als Admin manuell "bitte", aber nicht, wenn das System diesen automatisch auffordert?
Wahrscheinlich wird das irgendwie mit der Reihenfolge oder dem Timing zusammenhängen. Trotzdem bekommt man langsam echt den Eindruck, dass Exchange on Premise von Microsoft zu Gunsten der Cloud bewusst zerstört wird. So schlecht kann eine Qualitätskontrolle doch gar nicht sein. Auch muss mit jedem neuen Patch immer irgendwas Neues eingestellt oder konfiguriert werden. Schon auffällig die letzte Zeit.
Welche Qualitätskontrolle meinst du? Da kommt doch bald eine Anzeige wegen Computersabotage mit Schadenersatzforderung in Betracht bei dem was Microsoft da abliefert. Aber scheinbar wissen die Entscheider in den Unternehmen nicht was die Administratoren mit dem Gerümpel für Arbeit haben sonst wäre doch schon lenkst die Abkehr von Microsoft in die Wege geleitet.
"Welche Qualitätskontrolle meinst du?"
Meine Aussage "So schlecht kann eine Qualitätskontrolle doch gar nicht sein." bezog sich darauf, dass eine Qualitätskontrolle die diversen Probleme wohl hätte finden müssen. Da die Probleme trotzdem vorliegen liegt die Schlussfolgerung nahe, dass es wohl keine im Sinne der Kunden zu geben scheint.
Oder aber die Probleme sind ein Qualitätsmerkmal zur Förderung der Cloud und wurden von der Qualitätskontrolle als korrekt implementiert verifiziert. Das ist aber nur ein Gefühl und nichts was ich durch Fakten belegen könnte. ;-)
Gruß Singlethreaded
Es könnte eine Kreis Abhängigkeit geben.
Aber ich weiß das ich bei Windows sehr gut dafür sorgen kann, das ein Service solange restartet wird bis er läuft und wenn er absemmelt neu gestartet wird.
Oder verwechsle ich das mit Unix?
Das siehst Du richtig, man kann das Neustartverhalten von Diensten entsprechend einstellen. Bei mir lief das Update aber gestern normal durch (Windows Server Datacenter 2016, Exchange 2016). Alle Dienste von alleine gestartet, auch SerializedDataSigning ließ sich problemlos aktivieren. Schwein gehabt ;-)
Es könnte eine Kreis Abhängigkeit geben.
Aber ich weiß das ich bei Windows sehr gut dafür sorgen kann, das ein Service solange restartet wird bis er läuft und wenn er absemmelt neu gestartet wird.
Oder verwechsle ich das mit Unix?
Ihr wisst doch, dass die einzige echte Abhilfe die Migration zu Exchange-Online sein soll :-)
Alle entsprechenden Dienste ins Monitoring aufnehmen…
3 Exchange Server in Betrieb.
1 x 2016 – Updates installiert, Neustart –> Exchange Dienste starten nicht automatisch, händisch gestartet, sonst keine Probleme
Die anderen beiden 1 x 2016 & 2019 keinerlei Probleme nach Update Installation und Neustart.
Gestern Abend auf 2016 mit CU23 und 2012R2 installiert.
Nach Neustart haben folgende Dienste nicht automatisch gestartet:
Microsoft Exchange-Konformitätsprüfung,
Microsoft Exchange-Antispamupdate,
Microsoft Exchange DAG-Verwaltung,
Microsoft Exchange EdgeSync,
Microsoft Exchange IMAP4,
Microsoft Exchange-IMAP4-Back-End,
Microsoft Exchange-Notfallschutzdienst,
Microsoft Exchange POP3,
Microsoft Exchange-POP3-Back-End,
Microsoft Exchange-RPC-Clientzugriffsdienst,
Microsoft Exchange-Diensthost,
Microsoft Exchange-Einschränkungen,
Microsoft Exchange Unified Messaging,
Microsoft Exchange Unified Messaging-Anrufrouter
Nach manuellem Dienststart soweit alles OK.
Certificate Signing noch nicht aktiviert. Schaue ich mir die Tage an…
Da hat wohl wer die Abhängigkeiten falsch gesetzt und manchmal braucht ein Service länger bis er hoch kommt.
Aber warum merkt die Start Routine das nicht selbst?
2019ner alles gut keinerlei Problem auch die Dienste machten kein Problem.
Hallo zusammen,
wir haben gestern 9 2019er Exchange Systeme und 8 2016 Systeme mit den Januar Updates versorgt und konnten bis jetzt keine Fehler (weder bei der Installation noch im Betrieb) feststellen.
O.k. die Anwender sind jetzt keine Power-User – aber die Systeme scheinen rund zu laufen. Die Updates wurden alle nach gleichen Schema installiert (über cmd mit erweiterten Rechten, ggf. vorhandene Ex-Zusatzmodule/Dienste von 3.Anbietern wurden vorher deaktiviert, selbstredend) und anschließend neu gestartet.
Gruß
Markus
Bei dem Exchange-Server eines Kunden wird seit dem Update das Webinterface der ECP nicht mehr richtig dargestellt. Bedienung ist nicht moeglich.
Ist dahingehend jemandem was bekannt?
Gruesse
siehe oben
ECP HTTP-Fehler 500; Dienste down
Im Blog berichtet ein Nutzer in diesem Kommentar, dass er beim Login-Versuch im Exchange Control Panel (ECP, Microsoft Exchange-Systemsteuerung) den HTTP-Fehler 500 erhalte. Ursache sind nicht automatisch startende Exchange Dienste, was wohl auch bei einem Neustart auftritt. Abhilfe schafft alle Dienst manuell neu zu starten, dann sollte die ECP-Anmeldung wieder funktionieren.
Hatte die Aussage nicht mit meinem Problem in Verbindung gebracht, weils nicht ganz mit der Situation beim Kunden-Exchange uebereinstimmt.
Ich warte derzeit noch auf ein Zeitfenster vom Kunden, dass ich den Exchange neustarten kann.
Ich glaube aber die eigentlich Ursache fuer das Problem gefunden zu haben:
Der Ordner "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\ecp\15.1.2507.17" hat eine Groesse von ~3,5 MB. Ordner der vorherigen Versionen allo so um die 17MB
Der Ordner "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\Owa\15.1.2507.17" ganze 0MB, Ordner der vorherigen Versionen alle 1,25MB
Scheint mir als waeren beim (Security)Update die Pfade nicht korrekt befuellt worden. Ich werd als naechstes versuchen, die Ordner von nem funktionierenden Exchange rueberzukopieren
Edit: Bin durch den Kommentar von Alex hier https://www.frankysweb.de/neue-sicherheitsupdates-fuer-exchange-server/ drauf gekommen
2012 R2 und EX2016 …
Selbes Problem ECP OWA 500, Dienste laufen nicht.
Alle Dienste ins RMM mit Auto-Dienst-Starts aufgenommen und eine Aufgabe die den betroffenen MSExchangeADTopology Dienst nach den Neustarts einmal erneut neu startet. Aber das kann es doch nicht sein oder?
Hat jemand inzwischen eine bessere Lösung oder eine Dauerlösung gefunden damit Server-Neustarts ohne Sorgen möglich sind?
Zudem stoppt der "Windows-Dienst-Überprüfung – Microsoft Exchange-Konformitätsprüfung " Dienst im Betrieb (fällt erst jetzt durch die Prüfungen auf)
, ist das normal bzw. bei euch auch so?
Microsoft hat das mit den Diensten offiziell als Problem auf der Patch-Infoseite aufgenommen und schreibt als Lösung: Dienste manuell starten:
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-january-2023-exchange-server-security-updates/ba-p/3711808
Ausfuehren des UpdateCas.ps1-Skripts aus dem Exchange-Installordner hat OWA und ECP wieder hergestellt in meinem Fall
Http 500 kann ich leider auch bestätigen. Manueller Start der Dienste problemlos möglich.
UpdateCAS etc. habe ich schon durch. Nochmalige Installation des CU auch. Get-ComponentState zeigt, dass das Update keine Dienste gesperrt hat.
Die internen Zertifikate sind alle noch gültig, nach extern (Lets Encrypt) sowieso. Die Bindings im IIS habe ich alle geprüft.
Trotzdem stolpert der Exchange über folgendes:
[Eas] An internal server error occurred. The unhandled exception was: System.MissingMethodException: Methode nicht gefunden: "Void Microsoft.Exchange.Security.Authentication.AuthenticationContext.NegotiateSSL(System.String, Int32, Boolean)".
bei Microsoft.Exchange.HttpProxy.KerberosUtilities.GenerateKerberosAuthHeader(String host, Int32 traceContext, AuthenticationContext& authenticationContext, String& kerberosChallenge, Int32 port)
bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.c__DisplayClass167_0.b__0()
bei Microsoft.Exchange.HttpProxy.LatencyTracker.GetLatency(Action operationToTrack, Int64& latency)
bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.PrepareServerRequest(HttpWebRequest serverRequest)
bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.CreateServerRequest(Uri targetUrl)
bei Microsoft.Exchange.HttpProxy.ProxyRequestHandler.b__170_0()
bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch(Action tryDelegate, Func`2 filterDelegate, Action`1 catchDelegate)
Viele Grüße, Simon
Welche Version denn?
Hier, aus dem alten Technet und ohne Gewähr ;-)
https://social. ** .Forums/mvpforum/it-IT/9b8da9e7-0d0c-4b48-96e7-41fcc6fc7e45/exchange-2016-nach-installation-cu16-kein-owa-und-ecp?forum=exchange_serverde
1.
OWA mittels Exchange "UpdateCas.ps1" wiederherstellen
cd $exinstall
cd .\Scripts\
UpdateCas.ps1
2.
SharedWebConfig.config gelöscht und neu erstellt, aus:
C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy
C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess
cd "C:\Program Files\Microsoft\Exchange Server\V15\Bin"
DependentAssemblyGenerator.exe -exchangePath "C:\Program Files\Microsoft\Exchange Server\V15\Bin" -exchangePath "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess" -configFile "C:\Program Files\Microsoft\Exchange Server\V15\ClientAccess\SharedWebConfig.config"
DependentAssemblyGenerator.exe -exchangePath "C:\Program Files\Microsoft\Exchange Server\V15\bin" -exchangePath "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy" -configFile "C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\SharedWebConfig.config"
iisreset
3.
Installation eines weiteren Exchange Servers auf virtueller Maschine
– die beiden Dateien "SharedWebConfig.config" kopiert und im Produktivserver eingefügt
Bei mir war dann letztendlich der Punkt 3 erfolgreich. Vielleicht hauchst du schon mit 1. oder 2. deinem owa und ecp neues Leben ein.
Viel Erfolg und beste Grüße
Uwe"
Hier hatte ich auch das Problem, das nach dem Update einige Exchange-Dienste nicht automatisch starteten.
Die habe ich dann manuell gestartet.
Sonst gibts keine Probleme, der Exchange läuft einwandfrei.
Certificate Signing habe ich aber noch nicht aktiviert.
Die Frage ist, wenn ich nun den Server nochmal neu starte, ob die Dienste dann wieder nicht starten ?
Welche Dienste müssen denn genau automatisch starten?
Alle beginnend mit Microsoft Exchange und Starttyp Automatisch :-)
Allen voran der Microsoft Exchange AD Topolgie Dienst.
danke – war nämlich gerade so!
witzigerweise wurde der Mirosoft Exchange AD Topolgie Dienst gestartet und einige andere schon, aber wiederum einige nicht… kann auch sein, dass man eine richtige Verzögerung nun hat. naja zumindest weiß man sich zu helfen, wenn man alle manuell anstarten kann.
Früher (als Anfänger) haben wir dann debugging modus aktiviert.
Diese Ausgaben haben das System dann so verlangsamt (und Rechenzeit für andere freigegeben) das es klappte.
Blöd nur, wenn beim Kunden das Debugging ausgeschaltet war und das Timing nicht mehr hinkam.
Das betraf dann aber nur ein paar Kunden, alfa tester…
Wie viele Kunden hat MS?
Das wäre der Job des Betrübtsystem Herstellers…
er will aber die Kunden in seine Cloud nötigen…
Du kannst Dir eine Abhängigkeit Liste ausgeben lassen.
Möglicherweise hilft es die Dienste Stück für Stück und nicht parallel starten zu lassen.
Aber sind das Aufgaben die rin Windows-Admin erledigen kann?
Doch noch ein größeres Problem gehabt.
Installation von Exchange Server 2019 CU11, CU12, KB5022193 abgebrochen.
Server neu gestartet –> Dienste bleiben auf deaktiviert stehen. Keine Möglichkeit diese händisch zu starten etc. Update lässt sich auch nicht mehr starten/installieren da es meint die Dienste nicht stoppen zu können.
Einige Stunden Fehlersuche etc. später das hier gefunden:
Create a file "profile.ps1" in "C:\Windows\System32\WindowsPowerShell\v1.0" containing the following command:
New-Alias Stop-SetupService Stop-Service
(This simply creates an alias that makes Windows think there's a valid "Stop-SetupService cmdlet)
–> Update manuell installiert und funktioniert. Danach Server neu starten und alles wieder OK
Wieder mal einige Stunden für ein Exchange SU verbrannt….
Steinigt mich, aber ich bin dermaßen froh wenn ich die letzten On Premise Haufen noch zu Exchange online migriert habe…. Was so eine Exchange Fehlersuche an Zeit verschlingt ist nicht mehr zu argumentieren.
Neben dem Fehler beim Aufruf der Mailqueue funktioniert auch der MAPI Test mit dem "Exchange Server Health Check Report" https://practical365.com/powershell-script-exchange-server-health-check-report/ nicht mehr.
Selbst wenn ich nun das HealthChecker.ps1 in der Shell aufrufe muss ich die Ausführung bestätigen. Da werden einige Skripte wohl nicht mehr ohne weiteres funktionieren.
Habe jetzt auch folgende Auffälligkeit bei der Ausgabe von HealthChecker.ps1.
Die 3 Befehle zur Aktivierung wurde auf einem Server ausgeführt und auch niur dort die Dienste neu gestartet.
In der Ausgabe von ExchangeAllServersReport.html fehlt mir nun der Server auf den ich die Befehle abgesetzt habe und die Punkte "Valid Internal Transport Certificate Found On Server" sowie "Valid Auth Certificate Found On Server" sind Rot weil angeblich keine Zertifikate gefunden wurden.
Was ist das denn bitte für eine schwache Leistung von MS.
Korrektur:
Es muss nun das Skript (HealthChecker.ps1.) direkt auf einem Exchange Server ausgeführt werden denn wenn es nur auf einen Server mit den Exchange Tools ausgeführt wird kommen die obigen Fehler.
Es gibt auf Reddit zwei mMn wichtige Aussagen eines MS Mitarbeiters:
"We are not sure (we do not have telemetry like this for on-premises deployments) – how many people run their environments with auth certificates expired, mis-configured and so on. So taking a default feature dependency on this certificate seemed like a problematic proposition. What would possibly break is machine to machine PowerShell communication. So errors when running cmdlets or even EAC errors, as signing might be enabled but certificate was invalid etc. So it would not be a catastrophic issue but still it seemed a bit risky to enable this by default because we know (through the support grapevine) that there are customers we have that never touched this certificate and it might be expired etc. I think those certs live for 5 years and the script that we have published with this feature can do this for you automatically if you run it as a scheduled task (see script documentation – https://aka.ms/MonitorExchangeAuthCertificate )."
Ferner wir davon abgeraten die Funktion auf Exchange 2013 zu aktivieren:
"Note that starting today, we are recommending that if you have Exchange Server 2013 anywhere in the org, you do not turn on certificate signing of serialization payload. There are a few management tools (PowerShell and / or EAC) issues that popped up with Exchange 2013 in the mix so we are saying to wait with this feature for now. If no Exchange Server 2013 is present in the org, then go right ahead…"
Ich habe gestern Abend 7 Exchange-Server geupdatet. Bei zwei davon hatte ich es auch, dass die Dienste nach dem Update nicht gestartet sind. Bei einem dieser zwei lies sich auch die Shell nicht mehr starten. Hier musste ich im IIS am Exchange-Backend die Bindungen editieren und das Zertifikat neu einstellen. Nach einem Neustart des IIS lief das dann auch wieder.
VG
Frank
Also bei mir werden nach der Installation des SU auf Ex 2016 auf Windows Server 2012R2 die Dienste nicht gestartet (obwohl alle auf automatisch stehen).
Manueller Neustart der Dienste funktioniert; leider müssen nach einem Serverneustart die Dienste dann immer wieder manuell neu gestartet werden. Die Exchange Funktionalität ist aber nach diesem manuellen Neustart der Dienste vollständig gegeben.
Hat irgendjemand es hinbekommen, dass die Dienste wieder vollautomatisch von selbst starten nach einem Serverneustart?
MS sucks. Mann muss echt schon bei jedem Update zittern, was dann nicht alles wieder auf uns an Fehlersuche und Troubleshooting auf uns Admins zukommt ;)
IM-Integration mit SfB on Premise geht nach dem Update nicht mehr. Das dokumentierte Commandlet
New-SettingOverride -Name "IM Override" -Component OwaServer -Section IMSettings -Parameters @("IMServerName=skype01.contoso.com","IMCertificateThumbprint=CDF34A740E9D225A1A06193A9D44B2CE22775308") -Reason "Configure IM"
geht nicht mehr.
https://learn.microsoft.com/en-us/powershell/module/exchange/new-settingoverride?view=exchange-ps
Output:
New-SettingOverride : The parent object for could not be found. Please check that Setting Overrides exists.