Exchange Management Shell startet nicht (PowerShell vDir)

Im vorigen Artikel hatte ich bereits gezeigt, wie die virtuellen Verzeichnisse für beispielsweise OWA neu angelegt werden. Für das Neuerstellen wurde allerdings immer die Exchange Management Shell benutzt. Wenn die Exchange Management Shell allerdings nicht mehr startet, was dann?

Falls die virtuellen Verzeichnisse neu angelegt werden müssen und auch die Exchange Management Shell nicht mehr startet, dann hilft dieser Artikel weiter.

Exchange Management Shell startet nicht (PowerShell vDir)

Eine Besonderheit stellt das virtuelle Verzeichnis “PowerShell” dar. Dieses Verzeichnis wird von der Exchange Management Shell benutzt um sich mit Exchange zu verbinden. In den Beispielen oben ist zu erkennen, dass immer die Exchange Management Shell benutzt wird, um die virtuellen Verzeichnisse neu zu erstellen. Dies ist natürlich nicht möglich, wenn die Exchange Shell selbst nicht startet.

In diesem Beispiel habe ich einfach beide PowerShell Verzeichnisse im IIS gelöscht um einen Fehler zu simulieren:

PowerShell vDir

Das Löschen des PowerShell Verzeichnisses verhindert dass die Exchange Shell startet:

Exchange Management Shell

Die Fehlermeldung der Shell zeigt den HTTP Fehlercode 403 an:

New-PSSession : [tex1.frankysweb.local] Beim Verbinden mit dem Remoteserver „tex1.frankysweb.local“ ist folgender
Fehler aufgetreten: Der WinRM-Client hat einen HTTP-Statuscode „403“ vom Remote-WS-Verwaltungsdienst erhalten. Weitere
Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.

Wenn die Exchange Shell nicht mehr startet, kann mit der regulären PowerShell das Verzeichnis neu erstellt werden. Dazu muss zunächst die normale Windows PowerShell mit Administrator Rechten gestartet werden. Mit dem folgenden Befehl lässt sich dann das Exchange SnapIn zur PowerShell hinzugefügen:

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn

PowerShell

Da ich “nur” die Verzeichnisse aus dem IIS gelöscht habe, sind die PowerShell Verzeichnisse noch in der Exchange Konfiguration enthalten. Um die gelöschten Verzeichnisse neu zu erstellen, muss daher auch die Exchange Konfiguration bereinigt werden. Dafür können die folgenden beiden Befehle verwendet werden:

Get-PowerShellVirtualDirectory -Server TEX1 | Remove-PowerShellVirtualDirectory
Get-PowerShellVirtualDirectory -Server TEX1 -ShowMailboxVirtualDirectories | Remove-PowerShellVirtualDirectory

PowerShell

Das PowerShell Verzeichnis für das Front-End (Default Web Site” lässt sich nun mit dem folgenden Befehlen neu erstellen:

New-PowershellVirtualDirectory –Name "Powershell" -RequireSSL $false -CertificateAuthentication $true -BasicAuthentication $false -InternalUrl http://tex1.frankysweb.local/powershell

PowerShell

Falls nur das Front-End defekt war, startet die Exchange Shell jetzt schon wieder. Wenn wie in meinem Fall das Back-End auch defekt/gelöscht ist, muss auch dieses neu erstellt werden.

Back-End neu erstellen

Das PowerShell Verzeichnis für das Back-End lässt sich mit folgendem Befehl erstellen:

New-PowershellVirtualDirectory –Name "Powershell" -Role Mailbox -CertificateAuthentication $true -BasicAuthentication $false -WindowsAuthentication $true

PowerShell Backend

Wenn das Erstellen des Back-End Verzeichnisses Verzeichnisses geklappt hat, kann der nächste Schritt übersprungen und direkt der Pfad korrigiert werden. Wenn es zur Fehlermeldung kommt, dann muss der nächste Schritt ausgeführt werden.

Optional: IIS Metabase bereinigen

Wenn die folgende Fehlermeldung beim Erstellen der Back-End Verzeichnisses auftaucht, muss noch etwas Hand angelegt werden:

New-PowershellVirtualDirectory : Fehler beim Erstellen des virtuellen IIS-Verzeichnisses
‚IIS://TEX1.frankysweb.local/W3SVC/2/ROOT/Powershell‘ auf ‚TEX1‘.
In Zeile:1 Zeichen:1
+ New-PowershellVirtualDirectory –Name „Powershell“ -Role Mailbox -WebS …
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo          : InvalidOperation: (TEX1\Powershell (Exchange Back End):ADObjectId) [New-PowerShellVirtua
lDirectory], InvalidOperationException
+ FullyQualifiedErrorId : [Server=TEX1,RequestId=b2ccfa0d-722e-4ccb-92b6-7e2e5761f5b4,TimeStamp=17.10.2017 18:37:3
0] [FailureCategory=Cmdlet-InvalidOperationException] 5B396E6B,Microsoft.Exchange.Management.SystemConfigurationTa
sks.NewPowerShellVirtualDirectory

PowerShell Backend

Hier sind noch Rückstände in der IIS Metabase zu vorhanden, die zunächst auch gelöscht werden müssen. Um die Leichen in der IIS Metabase zu bereinigen, kann das ziemlich alte Tool “IIS Metabase Explorer” verwendet werden. Das Tool gibt es hier zum Download:

Der “IIS Metabase Explorer” benötigt .NET Framework 3.5 Funktionen, diese müssen ggf. nachinstalliert werden:

.NET Framework Feature

Im IIS Metabase Explorer muss nun unter “LM –> W3SVC –> 2 –> ROOT” der Eintrag “PowerShell” gelöscht werden:

IIS Metabase Explorer

Wichtig: Unbedingt auf die 2 (Blau markiert) achten. Unter 1 befindet sich das Front-End.

Nachdem der Eintrag gelöscht wurde, lässt sich auch das virtuelle Back-End Verzeichnis mit dem Befehl wie oben beschrieben wieder anlegen:

PowerShell

Jetzt muss nur noch der Pfad korrigiert werden.

PowerShell Back-End Pfad korrigieren

Für das PowerShell Back-End muss zum Schluss noch der Pfad im IIS-Manager angepasst werden.Der Pfad zeigt nach dem Neustellen auf das falsche Verzeichnis.

Der Pfad lässt sich via IIS-Manger korrigieren, auch hier ist es wichtig nicht die “falsche” Website zu erwischen, also unbedingt darauf achten, dass “Exchange Back End” als Website ausgewählt wird:

IIS Manager

In den erweiterten Einstellungen des Verzeichnisses wird nun der physikalische Pfad um “-Proxy” ergänzt:

IIS Manager

In meinem Fall wird also der Pfad “D:\Exchange\ClientAccess\PowerShell” um “-Proxy” ergänzt und verweist nun auf “D:\Exchange\ClientAccess\PowerShell-Proxy”.

Jetzt startet auch die Exchange Management Shell wieder:

Exchange Management Shell

10 thoughts on “Exchange Management Shell startet nicht (PowerShell vDir)”

  1. Hallo,

    ich habe diesen Fehler in einem anderen Zusammenhang. Ich habe im IIS per „Einschränkungen für IP-Adressen und Domänen“ alle Virtuellen Verzeichnisse gesperrt und nur noch von dem lokalen Adressbereich zugreifbar gemacht. Für das virtuelle Verzeichnis „Powershell“ war das aber wohl zu viel des Guten. Auch das hinzufügen von 127.0.0.1 brachte keine Besserung. Nur wenn ich die Einsschränkung komplett aufhebe geht es wider. Kann das einer erklären?

    Reply
  2. Hallo zusammen,
    ich hab unseren Exchange 2016 CU16 auf CU19 upgegraded und bin genau in dieses Problem gelaufen.
    Die im Artikel vorgeschlagene Maßnahme hat nicht zum Erfolgt geführt.
    Virtuelle Verzeichnis ließen sich wie oben beschrieben ohne weiteres löschen und neu erstellen.
    Vielleicht weiß jemand Rat.

    Reply
  3. Hallo Franky,

    vielen Dank für die Anleitung. Bei mir scheint aber die web.config defekt zu sein in dem Ordner „PowerShell-Proxy“. Kann ich den auch einfach löschen und wird der dann inkl Config Datei neu erstellt?

    Falls das nicht geht, wie bekomme ich die Config Datei neu erstellt bzw. repariert?

    Danke!
    King Hundi

    Reply
  4. Seit dem letzten Update bekomme ich auf der Shell folgenden Fehler:
    Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht ermittelt werden.

    Wenn ich dann im Browser localhost/Powershell aufrufe gibt es folgenden Fehler:
    Die Datei oder Assembly „Microsoft.Exchange.Clients.Strings, 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.

    Debug:
    === Zustandsinformationen vor Bindung ===
    LOG: DisplayName = Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
    (Fully-specified)
    LOG: Appbase = file:///C:/Program Files/Microsoft/Exchange Server/V15/FrontEnd/HttpProxy/PowerShell/
    LOG: Ursprünglicher PrivatePath = C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell\bin
    Aufruf von Assembly : (Unknown).
    ===
    LOG: Diese Bindung startet im default-Load-Kontext.
    LOG: Die Anwendungskonfigurationsdatei wird verwendet: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\PowerShell\web.config
    LOG: Die Hostkonfigurationsdatei wird verwendet: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\aspnet.config
    LOG: Die Computerkonfigurationsdatei von C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config wird verwendet.
    LOG: Verweis nach der Richtlinie: Microsoft.Exchange.Data.Directory, Version=15.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35
    LOG: Download von neuem URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/powershell/788cbad3/5ed4f687/Microsoft.Exchange.Data.Directory.DLL.
    LOG: Download von neuem URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/powershell/788cbad3/5ed4f687/Microsoft.Exchange.Data.Directory/Microsoft.Exchange.Data.Directory.DLL.
    LOG: Download von neuem URL file:///C:/Program Files/Microsoft/Exchange Server/V15/FrontEnd/HttpProxy/PowerShell/bin/Microsoft.Exchange.Data.Directory.DLL.
    LOG: Download von neuem URL file:///C:/Program Files/Microsoft/Exchange Server/V15/FrontEnd/HttpProxy/PowerShell/bin/Microsoft.Exchange.Data.Directory/Microsoft.Exchange.Data.Directory.DLL.
    LOG: Download von neuem URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/powershell/788cbad3/5ed4f687/Microsoft.Exchange.Data.Directory.EXE.
    LOG: Download von neuem URL file:///C:/Windows/Microsoft.NET/Framework64/v4.0.30319/Temporary ASP.NET Files/powershell/788cbad3/5ed4f687/Microsoft.Exchange.Data.Directory/Microsoft.Exchange.Data.Directory.EXE.
    LOG: Download von neuem URL file:///C:/Program Files/Microsoft/Exchange Server/V15/FrontEnd/HttpProxy/PowerShell/bin/Microsoft.Exchange.Data.Directory.EXE.
    LOG: Download von neuem URL file:///C:/Program Files/Microsoft/Exchange Server/V15/FrontEnd/HttpProxy/PowerShell/bin/Microsoft.Exchange.Data.Directory/Microsoft.Exchange.Data.Directory.EXE.

    Reply
  5. Hallo Frank,

    Kann Leider trotz deiner sehr guten erklärung keine Virtuelle Powershelldirectory Erstellen wo kann es noch klemmen?

    Reply

Leave a Comment