In the previous article I have already shown how to create new virtual directories for OWA, for example. However, the Exchange Management Shell was always used to recreate them. But what happens if the Exchange Management Shell no longer starts?
If the virtual directories need to be recreated and the Exchange Management Shell no longer starts, this article will help.
Exchange Management Shell does not start (PowerShell vDir)
A special feature is the virtual directory "PowerShell". This directory is used by the Exchange Management Shell to connect to Exchange. In the examples above, you can see that the Exchange Management Shell is always used to recreate the virtual directories. This is of course not possible if the Exchange Shell itself does not start.
In this example, I simply deleted both PowerShell directories in IIS to simulate an error:
Deleting the PowerShell directory prevents the Exchange Shell from starting:
The error message of the shell shows the HTTP error code 403:
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“.
If the Exchange Shell no longer starts, the directory can be recreated using the regular PowerShell. To do this, the normal Windows PowerShell must first be started with administrator rights. The Exchange SnapIn can then be added to the PowerShell with the following command:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.SnapIn
Since I "only" deleted the directories from the IIS, the PowerShell directories are still contained in the Exchange configuration. To recreate the deleted directories, the Exchange configuration must therefore also be cleaned up. The following two commands can be used for this:
Get-PowerShellVirtualDirectory -Server TEX1 | Remove-PowerShellVirtualDirectory Get-PowerShellVirtualDirectory -Server TEX1 -ShowMailboxVirtualDirectories | Remove-PowerShellVirtualDirectory
The PowerShell directory for the front-end ("Default Web Site") can now be recreated with the following commands:
New-PowershellVirtualDirectory –Name "Powershell" -RequireSSL $false -CertificateAuthentication $true -BasicAuthentication $false -InternalUrl http://tex1.frankysweb.local/powershell
If only the front-end was defective, the Exchange Shell will now start again. If, as in my case, the back end is also defective/deleted, this must also be recreated.
Create new back-end
The PowerShell directory for the back-end can be created with the following command:
New-PowershellVirtualDirectory –Name "Powershell" -Role Mailbox -CertificateAuthentication $true -BasicAuthentication $false -WindowsAuthentication $true
If the creation of the back-end directory has worked, the next step can be skipped and the path can be corrected directly. If an error message appears, the next step must be carried out.
Optional: Clean up IIS Metabase
If the following error message appears when creating the back-end directory, you need to do a little more work:
New-PowershellVirtualDirectory : Error creating the virtual IIS directory
‚IIS://TEX1.frankysweb.local/W3SVC/2/ROOT/Powershell‘ auf ‚TEX1‘.
In line:1 Character: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
There are still residues in the IIS Metabase that need to be deleted first. The rather old tool "IIS Metabase Explorer" can be used to clean up the corpses in the IIS Metabase. The tool can be downloaded here:
The "IIS Metabase Explorer" requires .NET Framework 3.5 functions, which may have to be installed later:
In the IIS Metabase Explorer, the "PowerShell" entry must now be deleted under "LM -> W3SVC -> 2 -> ROOT":
Important: Pay attention to the 2 (marked blue). The front end is located under 1.
After the entry has been deleted, the virtual back-end directory can also be created again using the command as described above:
Now only the path needs to be corrected.
Correct PowerShell back-end path
For the PowerShell back-end, the path in the IIS Manager must be adjusted at the end; the path points to the wrong directory after the new setting.
The path can be corrected via IIS Manager, here too it is important not to get the "wrong" website, so make sure that "Exchange Back End" is selected as the website:
"-Proxy" is now added to the physical path in the advanced settings of the directory:
In my case, "-Proxy" is added to the path "D:\Exchange\ClientAccess\PowerShell" and now refers to "D:\Exchange\ClientAccess\PowerShell-Proxy".
Now the Exchange Management Shell starts again:
