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

Schreibe einen Kommentar

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