none
MSExchangePowerShellFrontEndAppPool fehlt im Anwendungspool des IIS RRS feed

  • Frage

  • Hallo,

    ich habe ein Problem mit dem Update eines EXCHANGE 2016 auf einem Windows Server 2012R2.

    kurz vor Ende der Aktualisierung der Transport Rules bricht er mit Fehler ab: "System.InvalidOperationException: Fehler beim Erstellen des virtuellen IIS-Verzeichnisses 'IIS://EX-01.lohnpack.lan/W3SVC/2/ROOT/PowerShell' auf 'EX-01'. ---> System.Runtime.InteropServices.COMException: Eine Datei kann nicht erstellt werden, wenn sie bereits vorhanden ist. (Ausnahme von HRESULT: 0x800700B7)

    Jetzt habe ich beim Vergelci hmit einem anderen EXCHANGE 2016 Server festgestellt, daß der Anwendungspool MSExchangePowerShellFrontEndAppPool im IIS fehlt und dadurch die Einträge PowerShell von 'Default Web Site' und 'Exchange Back End' dieselbe Anwendung (MSExchangePowerShellAppPool) hinterlegt haben.

    Ich vermute, daß das Upgrade deswegen fehlschlägt.

    Wie kann ich die Anwendung MSExchangePowerShellFrontEndAppPool hinzufügen, damit ich sie der PowerShell in 'Default Web Site' hinterlegen kann?

    MfG,

    Ulrich Frey.

    Montag, 20. Mai 2019 07:37

Alle Antworten

  • Schau mal in der IIS-Konsole unter "Anwendungspools".
    Wenn der Name so stimmt, was du in den Eigenschaften der Sites prüfen kannst, legst du den Pool einfach so an.
    Wichtig ist nur die richtige .Net-Version (aktuell eher V4 als V2) einzustellen und den Pool zu starten.

    Montag, 20. Mai 2019 07:41
  • Genau dort gibt es die Anwendung eben nicht.

    Und wenn ich sie händisch hinzufüge stimmt die Identität nicht: sie ist dann ApplicationPoolIdentity und nicht LocalSystem ...

    Montag, 20. Mai 2019 10:35
  • Nach dem Anlegen des Pools kannst du über "Anwendungspoolstandardwerte festelgen" die Identität LocalSystem festlegen.
    Montag, 20. Mai 2019 14:30
  • OK, die Anwendung habe ich anlegen und konfigurieren können. Nur hätte ich 'erweiterte Einstellungen' nehmen müssen und nicht 'Anwendungspoolstandardwerte festlegen'. Das hat mir die Konfiguration bei allen anderen Anwendungen überschrieben ... :(

    Jetzt ist nur die Frage, wo das EXCHANGE ServicePack die Standardwerte für die Anwendungen hernimmt.

    Ich muß nämlich unter 'Default Web Site' und 'Exchange Back End' die beiden Anwendungen PowerShell entfernen, damit das Update sie neu anlegen kann und nicht abbricht, da sie schon vorhanden sind ...

    Montag, 20. Mai 2019 15:34
  • Da frage ich mich, wieso du das alles selber manuell machen musst und Exchange das nicht selber installiert.
    Vielleicht hilft dir dies ja weiter:
    https://www.frankysweb.de/exchange-2016-virtuelle-verzeichnisse-im-iis-neu-erstellen/

    Montag, 20. Mai 2019 16:19
  • Moin, meiner Erfahrung nach kannst Du nicht mehr tun als noch einmal zu prüfen, ob die installierte .NET-Version mit dem zu installierenden Exchange-CU supported ist. Falls nicht, korrigieren und ein letztes mal versuchen. Falls bereits kompatibel oder nach Korrektur erfolglos, die Windows-Installation auf dem Server wegschmeißen (NICHT aus dem AD entfernen!!!), das Computer-Konto im AD zurück setzen und eine Reparatur-Installation von Exchange (mit dem vorherigen CU). Danach, falls nötig, .NET updaten und anschließend das gewünschte CU installieren.

    Evgenij Smirnov

    http://evgenij.smirnov.de

    Montag, 20. Mai 2019 18:01
  • Ich befürchte, daß es mit den Abhängigkeiten von EXCHANGE 2016 und .NET zu tun hat.

    Ich will nämlich von der RTM Version auf CU12 aktualisieren ...

    Da es ein Produktivsystem ist, möchte ich ungern die Installation wegwerfen. Da hilft dann wohl nur einen 2. EXCHANGE hochziehen und migrieren ...

    Dienstag, 21. Mai 2019 07:33
  • Moin,

    RTM auf CU12 kannst Du in einem Schritt nicht migrieren.

    Dein Produktives System ist ja jetzt auch schon kaputt, oder? Wenn es auf RTM lauffähig ist, kannst Du auch updaten - in mehreren Schritten:

    • innerhalb von .NET 4.6.2 auf CU8 oder CU9
    • dann .NET auf 4.7.1
    • dann auf CU12
    • und dann, wenn Du willst, .NET auf 4.7.2

    Wenn es aber kaputt ist, wie willst Du dann migrieren? Und "Produktive Installation wegschmeißen" ist nicht ganz zutreffend: Die ganze Konfiguration ist ja im AD gespeichert. Die Datenlaufwerke musst Du mit den gleichen Pfaden wieder bereitstellen, Zertifikate möglichst vor Exchange-Installation einspielen, dann ist die Installation nach der Reparatur-Installation fast wie vorher.


    Evgenij Smirnov

    http://evgenij.smirnov.de

    Dienstag, 21. Mai 2019 10:33
  • Moin,

    das Produktionssystem läuft immernoch. Gibt nur ab und an Probleme bei einer Benutzerin. Deswegen ja der Versuch auf CU12 zu aktualisieren.

    Da man mittlerweile bei MS nur noch CU10-12 herunterladen kann, komme ich leider nicht an frühere Updates.

    Es ist mittlerweile .NET 4.7.2 installiert, deswegen wird ein Update mit Zwischenversionen vermutlich nicht funktionieren.

    Mit migrieren meinte ich die Postfächer migrieren ...

    Dienstag, 21. Mai 2019 10:45