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:
Das Löschen des PowerShell Verzeichnisses verhindert dass die Exchange Shell startet:
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
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
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
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
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
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:
Im IIS Metabase Explorer muss nun unter “LM –> W3SVC –> 2 –> ROOT” der Eintrag “PowerShell” gelöscht werden:
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:
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:
In den erweiterten Einstellungen des Verzeichnisses wird nun der physikalische Pfad um “-Proxy” ergänzt:
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:
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?
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.
habe hier eine Lösung gefunden, die mein gleiches Problem gelöst hat:
https://anotherexchangeblog.wordpress.com/2015/09/25/nothing-is-working-after-cu9-installation/#respond
Cause :
ListenOnlyList reg key value allowing only 127.0.0.1
Solution:
deleted HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters ‘ListenOnlyList’
-Rebooted the server
super Anleitung, leider finde ich den “ IIS Metabase Explorer“ nicht mehr zum Download
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
Vielen Dank,
hat super geklappt.
Hatte vorher vieles ausprobiert, das war die Lösung für mich.
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.
Hallo Frank,
Kann Leider trotz deiner sehr guten erklärung keine Virtuelle Powershelldirectory Erstellen wo kann es noch klemmen?
Hi. Bei mir funktioniert das leider genau so nicht. Kommt immer noch die gleiche Meldung.
Mfg
Vielen Dank!
Das mit dem Pfad zum Proxy hatte ich „vergessen“…