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:

3 Replies to “Exchange 2016: Serverfehler in Anwendung (OWA und/oder ECP)”

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

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

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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.