Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP)

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:

Exchange 2016: Serverfehler in Anwendung (OWA und/oder 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

Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP)

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%):

Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP)

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:

Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP)

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

Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP)

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:

image

Falls OWA oder ECP nach diesen Schritten noch nicht funktionieren, hilft oft die entsprechenden Verzeichnisse neu zu erstellen. Das Vorgehen ist hier beschrieben:

44 Gedanken zu „Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP)“

  1. 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

    Antworten
  2. 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-

    Antworten
  3. 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“

    Antworten
    • 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.

      Antworten
  4. 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

    Antworten
  5. 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

    Antworten
  6. 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.

    Antworten
  7. 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

    Antworten
  8. 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

    Antworten
  9. 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

    Antworten
  10. 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 !!!

    Antworten
    • 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?

      Antworten
  11. 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.

    Antworten
  12. 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

    Antworten
  13. 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 :)

    Antworten
  14. 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

    Antworten
  15. 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??

    Antworten
  16. 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

    Antworten
  17. Herzlichen Dank für die Anleitung. Mit Exchange 2013 CU23 + KB4536988 hatte ich die gleiche problemen und ihre Losung hat es auch geschaft

    Antworten
  18. 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.

    Antworten
  19. 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

    Antworten
  20. 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…

    Antworten
  21. 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

    Antworten
  22. 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!

    Antworten
  23. 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.

    Antworten
  24. 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

    Antworten
  25. 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!!!

    Antworten
  26. 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.

    Antworten
  27. @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.

    Antworten
  28. 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.

    Antworten

Schreibe einen Kommentar