Ein Leser berichtete von einem Problem nach der Installation eines Cumulative Update (CU) auf einem Exchange 2016 Server. Der Aufruf von OWA und ECP war nach der Installation nicht mehr möglich. Beide Anwendungen lieferten nur noch einen Serverfehler.
Beim Aufruf von OWA lautete die Fehlermeldung in etwa so:
Die Datei oder Assembly „Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.“ und OWA “
:-( Da hat etwas nicht geklappt.
Ihre Anforderung konnte nicht abgeschlossen werden. HTTP-Statuscode: 500.
X-ClientId: 69461D0170F742F09942BB1B8E75C0C6
request-id 1a567512-c2b4-4d4e-8f05-5481c5713adf
X-OWA-Error System.Web.HttpUnhandledException
X-OWA-Version 15.1.1531.7
X-FEServer Servername
X-BEServer Servername
Date:12.10.2018 14:56:03
InnerException: System.IO.DirectoryNotFoundException“.
Ähnliches Fehlerbild auch beim Aufruf von ECP:
Die wichtige Meldung hier an dieser Stelle:
Ausnahmedetails: System.IO.FileNotFoundException: Die Datei oder Assembly „Microsoft.Exchange.Common, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35“ oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.
Die Funktionalität von OWA ließ sich recht schnell mittels dem von Exchange mitgelieferten Scripts “UpdateCas.ps1” wiederherstellen. Das Script lässt sich wie folgt mittels Exchange Management Shell starten:
cd $exinstall cd .\Scripts\ UpdateCas.ps1
OWA lies sich danach wieder ohne Probleme öffnen, lieferte allerdings immer noch den oben genannten Fehler. Die Ursache waren falsche Pfadangaben in den Anwendungseinstellungen für das Verzeichnis ECP der Exchange Backend Webseite. In diesem Fall war für den Schlüssel “BinSearchFolders” Pfade mit einer nicht existierenden Variabel angegeben.
Wie im folgenden Screenshot zu sehen ist, enthält der Schlüssel “BinSearchFolders” keine absoluten Pfade, sondern Pfade mit der Variable ExchangeInstallDir (%ExchangeInstallDir%):
Die Variable ExchangeInstallDir gibt es allerdings nicht, daher rührt auch die Fehlermeldung System.IO.FileNotFoundException. Damit ECP wieder funktioniert, müssen die entsprechenden Pfade für “BinSearchFolders” angegeben werden:
Die richtigen Pfade können mit der Exchange Management Shell ermittelt werden. Dazu kann der folgende Befehl verwendet werden:
$folders = "$exinstall" + "bin;" + "$exinstall" + "bin\CmdletExtensionAgents;" + "$exinstall" +"ClientAccess\Owa\bin" $folders
Der Wert muss nun wie oben beschrieben eingetragen werden. Danach einmal den IIS mittels IISRESET neu starten.
Wie schon erwähnt existiert die Variable ExchangeInstallDir nicht, möglicherweise ist hier beim Update etwas schief gelaufen. Zum Vergleich habe ich andere Exchange 2016 Server überprüft, in allen Installationen waren hier die absoluten Pfade ohne Variablen angegeben. Es gibt allerdings die Variable ExchangeInstallPath, diese ließe sich hier auch verwenden:
Falls OWA oder ECP nach diesen Schritten noch nicht funktionieren, hilft oft die entsprechenden Verzeichnisse neu zu erstellen. Das Vorgehen ist hier beschrieben:
Gleicher Fehler bei Ex2K16 und Update auf CU23 SU8.
Ausführung des Skripts und Korrektur der BinSearchFolders hat perfekt geholfen – vielen Dank!!
Kann hier einer Helfen?
Serverfehler in der Anwendung /ecp.
——————————————————————————–
Kompilierungsfehler
Beschreibung: Fehler bei der Kompilierung einer Ressource, die zur Verarbeitung dieser Anforderung erforderlich ist. Überprüfen Sie die folgenden spezifischen Fehlerdetails, und ändern Sie den Quellcode entsprechend.
Compilerfehlermeldung: CS0117: ‚Microsoft.Exchange.Management.ControlPanel.Strings‘ does not contain a definition for ‚MigrationOnboardingCommandText‘
Quellfehler:
[Keine relevanten Quellzeilen]
Quelldatei: c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\ecp\d3731aae\fb815e98\App_Web_viewusermailboxdetails.aspx.b1f2c2eb.f09ljqa6.0.cs Zeile: 5289
Detaillierte Compilerausgabe anzeigen:
——————————————————————————–
Versionsinformationen: Microsoft .NET Framework-Version:4.0.30319; ASP.NET-Version:4.8.4667.0
Hab exakt den selben Fehler…
Bei mir haben die Scripts leider nichts genützt,
gibt es sonst noch Lösungsvorschläge?
Ex2019 CU12. Gleichen Symptome. Danke an Frank. Auch bei mir waren die Variablen auf %ExchangeInstallDir% gesetzt (klingt fast nach Entwicklerumgebung :-)). UpdateCas und UpdateConfig ($exinstall\bin) haben es wieder gerichtet-
Habe Exchange Server 2019 CU11 Nov21SU KB5007409 installiert.
ECP ging nicht mehr. Das Exchange ist schon so ein Scheiß, bei jedem 2. Update geht was nicht mehr.
Musste auch beides laufen lassen:
„UpdateCas.ps1“
„UpdateConfigFiles.ps1“
Kann ich von Exchange2016/ 2019 nicht behaupten. Hatte dieses, oder war es letztes Jahr, nur einmal ein Problem am Exchange2016.
Kann mich schon gar nicht mehr erinnern und da war wohl nur ein fehlender Neustart oder ein Zertifikatsproblem.
Habe alle Exchange Server 2016/ 2019 auch nicht unter den Standard Pfaden instl.
Ich instl. die CU`s oder SU`s immer gleich zeitnah.
Adminrechte beim Ausführen der Datei vergessen? Ansonsten Windows Update oder sconfig nutzen.
Danke Franky,
cd $exinstall
cd .\Scripts\
UpdateCas.ps1
und dann einfach noch das Script
UpdateConfigFiles.ps1
durchlaufen lassen, dann brauchst du die manuellen Eintragungen im IIS noch zu machen.
LG Peter
Bei mir waren nach CU 21 und dem Juli SU gleich mehrere Dienste und Pfade betroffen. Zusätzlich zu den beschriebenen Schritten musste ich noch die jeweilige web.config unter FrontEnd\HttpProxy anpassen, da sich auch dort die Variable %ExchangeInstallDir% eingeschlichen hatte. Ob es auch hilft, die Variable einfach manuell anzulegen, habe ich nicht getestet.
Gruß
Matthias
Danke Franky!!
Hatte das Problem bei Exchange 2019 nach dem Update von CU9 auf CU10.
Deine Anleitung hat mich wieder gerettet!
Beim Exchange 2019 scheint das Script unter
…\Exchange Server\V15\Bin zu liegen. Jedenfalls war dies bei mir der Fall.
Hallo
Genau dieses Problem nach CU21 und JUL21SU 15.1.2308.14 Installation…
Und wieder mal hat Frank mir den Tag gerettet…
Und das gute daran: erster Suchtreffer im Google…. ;-)
Danke für alles!
Gruss aus der Schweiz
Markus
Hallo zusammen,
zuerst natürlich und wichtig: Danke an Frank für seine Seiten!!!
Mit Ex2016 und dem Einspielen von CU20 ist es mal wieder aufgetreten.
Hier bin ich mit „UpdateCas.ps1“ allein nicht weiter gekommen, es hat mich allerdings auf den richtigen Weg gebracht bzw. bei der Suche geholfen.
Es fehlte hier quasi ein anschließendes „UpdateConfigFiles.ps1“
https://docs.microsoft.com/de-de/exchange/troubleshoot/client-connectivity/owa-stops-working-after-update
Beste Grüße – Karsten
Hallo Frank,
die Anleitung hat mir gerade viel Zeit für die Suche erspart.
Nach Installation des letzten Sicherheitspatches nach Hafnium funktionierte ECP und OWA an einem aktuell eingepatchten Exchange 2016 nicht mehr, Anleitung befolgt, läuft wieder.
Wieder mal hat mir deine Seite geholfen.
Vielen Dank!!
Alex
Hallo Franky,
Bei mir das gleiche mit dem „Notfallupdate“.
„you saved my Day!!!“
Vielen, Vielen Dank, bleib so wie Du bist!
Nach dem Patch KB5000871 auf einem EXCHANGE 2013 lief OWA und ECP nicht mehr.
UpdateCas.ps1 reparierte ’nur‘ OWA.
Was hilft, außer dass man das ECP Verzeichnis vollständig ’neu‘ erstellt?
Vielen Dank für die Unterstützung !!!
Guten Tag Herr Vetterling, ich hab das gleiche Problem. UdpateCas.ps1 hat zwar owa repariert nur die Seite von ECP ist nicht zum öffnen. Haben Sie schon eine Lösung gefunden?
You safe my day..thanks for sharing
yep, selbes Problem -> Upgrade eines Exchange Server 2019 CU5 (15.2.595.3) auf 2019 CU 8 (15.2.792.3) und anschließend den Patch vom 2. März 2021 (KB5000871) angewandt (die Exchange Server 2019 Build-Nummer änderte sich somit auf 15.02.0792.010)
-> ECP und OWA funktionierten danach nicht mehr.
Das Problem konnte mit Hilfe dieser Anleitung gelöst werden. Vielen herzlichen Danke
Grüße aus Wien
MR.
Gleiches Problem nach KB5000871 und habe erstmal wie wild die Datei UpdateCas.ps1 gesucht.
Bei mir lag die Datei nicht unter Scripts sondern im BIN-Verzeichnis.
Danach Funktion OWA und ECP wider hergestellt.
Danke. :)
Gruß
ITF
Die Anleitung funktioniert auch super bei einem Exchange 2019. Nach der Installation des Hotfixes für die aktuelle Sicherheitslücke stand ich genau vor diesem Problem. Die Anleitung hat super geholfen, vielen Dank dafür :)
Kunden Server; EX2016 CU18. Super geholfen.
Nach dem KB5000871 Aufgetreten.
Vielen Dank!
Hallo,
1000 Dank. Habe nach dem 0-Day Patches von Exchange 2019 CU7 das gleiche Problem wie oben gehabt und durch die vorgeschlagenen Einstellungen klappt wieder alles. OWA sowie ECP funktionieren wieder.
LG
Prima. Das klappt nun wieder mit dem OWA.
Nur kann ich dort keine E-mails mehr lesen. Da kommt nun „Fehler: Ihre Anforderung kann gerade nicht abgeschlossen werden. Versuchen Sie es später noch mal.“
Hat da wer eine Lösung??
Hallo habe den Fehler das sobald ich mich bei Exchange Admin Console anmelde ich den Fehler Http 500 bekomme.
OWA funktioniert problemlos.
Schritte aus der Anleitung,bis auf Virtuelle Verzeichnisse neu erstellt, ausgeführt leider ohne erfolg.
Exchange Server 2019 CU4
Jemand noch ein Tip?
VG
Vielen Dank für Deine Tipps.
Haben mir sehr geholfen.
VG
Eine großartige Hilfestellung. Danke, Frank! Ein Dank geht gleich auch via Papyal raus!
Herzlichen Dank für die Anleitung. Mit Exchange 2013 CU23 + KB4536988 hatte ich die gleiche problemen und ihre Losung hat es auch geschaft
Super, war die Lösung für selbiges Problem, Exchange 2016 CU14 + KB4536987
Vielen Dank
Super Anleitung hatte das Problem mit Exchange 2019 CU4 + KB4536987
Vielen Dank
Herzlichen Dank für die Anleitung. Nach Update von CU14 auf CU15 und .net 4.8 + KB4536987 genau diese Probleme.
Hi Franky, danke für den hilfreichen Artikel.
Trat nun auf Exchange 2013 CU23 mit .Net 4.8 auf, jedoch nicht mit dem in 2019 installieren CU23, sondern nach der Installation des aktuellen KB gegen CVE-20200688
Backlink zu dem Artikel in twitter.
Hallo und Danke Frank!
Auch mich hat es getroffen nach dem CU23 Update inkl. Sicherheitspatch Exchange2013-KB4536988-x64-en.msp.
Nun läuft es wieder !
Vielen vielen Dank
Nachtrag, nach dem Serverneustart ist das Loginverhalten absolut wieder in der Norm, ev. waren noch nicht alle Dienste bereit und haben demnach das Loginverfahren etwas verzögert.
Danke für den wertvollen Beitrag von Franky. Merkwürdig ist aber wieso die variable ExchangeInstallDir auf einmal vergessen geht. Aber das weiss wohl nur Microsoft…
Hallo Franky,
Ich habe heute das kumulative Update für Exchange 2016 (Februar 2020 CVE-2020-0688) installiert und bin genau auf das von Dir beschriebene Problem gestossen. Mit der Änderung der BIN-Parameter konnte ich das Problem genau wie von Dir beschrieben beheben.
Merkwürdig ist aber dass das Login etwa 25 Sekunden dauert, während es bis gestern nur wenige Augenblicke gebraucht hat. Liegt das Problem ev. am Security Update (4536987)? Hat jemand ähnliche Erfahrungen gemacht?
Gruss Dave
Hallo zusammen, ich hatte das Problem auf drei Exchange 2016 Servern nachdem ich das Security Update KB4523171 installiert habe. Dank der Anleitung konnte ich das Problem schnell lösen. Bei mir reichte es auch aus die absoluten Pfade in den IIS Anwendungseinstellungen zu setzen. Vielen Dank!
Hatte diese Probleme nach der Installation des September-2019-Patches.
Das Vorgehen gemäß dieser Anleitung hat alle Probleme beseitigt – ziehe davor den Hut!
Eine kleine Ergänzung dazu noch:
Auf meinem Problem-Server existierte die Variable ExchangeInstallPath (wie am Ende des Artikels erwähnt).
Trotzdem lief es damit nicht, erst die Änderung der BIN-Parameter auf die absoluten Pfade hat geholfen.
Hallo zusammen,
hier an dieser Stelle mal wieder ein dickes Lob an unseren Franky. Wieder einmal hat er, nicht nur mir, sondern vielen, die das hier lesen, den @rsch gerettet.
Frank, wenn Du jemals in den schönen Odenwald, nach Südhessen, Darmstadt oder Umgebung kommst, hast ein Essen und 1-30 Bier bei mir gut!
vielen Dank für Deine Arbeit
Beste Grüße aus Kirchbrombach
Jörg
Vielen lieben Dank!
Musste das ECP Verzeichnis komplett zurücksetzen und dies war die einzigste Anleitung die mir deutlich weiter geholfen hat.
Großes Lob!!!
TOP!!
Hat bei mir auch nach dem CU11 geholfen.
Ebenfalls die Probleme mit CU11 gehabt.
Nach den beiden Hilfestellungen von Frank läuft es wieder!
Vielen Dank. :-)
noch ein kleines Problem mit CU11
nach der Installation war eine Anmeldung mit Outlook nicht mehr möglich.Im IIS war bei MAPI die Windows-Authentifizierung deaktiviert.
Alles andere OWA sowie auch ECP und Active-Sync funktionierten einwandfrei.
@Jochen: Ich mache es ähnlich:
– Email Eingang stoppen (Anti-Spam Appliance herunterfahren oder Firewall)
– Exchange Server herunterfahren (Wenn mehrere eben alle)
– Snapshot unter VMware!
– Installieren
– Wenn alles läuft, Snapshot löschen und Email Eingang wieder starten
Einen Snapshot im heruntergefahrenen Zustand halte ich persönlich für die sauberste Lösung. Selbst wenn ich zurück gehe (was nur Sekunden dauert) ist es für den Server selbst nicht erkennbar.
Hallo,
habe heute ebenfalls das neue CU11 für Exchange2016 auf einem Server2016 instl. in einer Domäne auf einer mittelmäßigen Hyper-V VM, ohne Probleme. Läuft alles wie zuvor.
Ein Tipp vielleicht noch, vor jedem Exchange Server Update aller Art, immer zuvor ein Neustart durchführen und Virenscanner deaktivieren. Evtl. noch eine Sicherung mit Veeam Backup durchführen, dann ist man auf der sicheren Seite.
Hatte Anfangs, noch unter CU5 massiv Probleme und konnte schnell, dank Veeam Backup, auf diesen Stand von ca. vor 2 Stunden zurück und alles lief wieder.
Da ich nun die oben erwähnten Schritte einhalte, gelingt jedes Update.