You may get this message when you open up Exchange Management Console (EMC) for Exchange 2010.
"Connecting to remote server failed with the following error message : The WinRM client received an HTTP server error status (500), but the remote service did not Include any other information about the cause of the failure. It was running command 'Discover-ExchangeServer -UseWIA $true ..."
And you may also not be able to connect to your Exchange server from Exchange Management Shell together with the following error message:
"VERBOSE: Connecting to servername.domainname.local New-PSSession : [servername.domainname.local ] Connecting to remote server failed with the following error message : The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure."
(the same shows up 3 times)
1. Reboot the server, usually fixes this error.
2. Make sure your authentication settings on your virtual directory for PowerShell is correct.
>Internet Information Services (IIS) Manager, <Servername>, Sites, Default Web Site, PowerShell and in the right panel, scroll down to the Authentication module
Make sure that Anonymous access is disabled and Windows Authentication is enabled.
3.
a) Make sure the current logged in user has remote powershell enabled. Should return “True” if enabled.
(Get-User ).RemotePowershellEnabled
b) Enable remote powershell for a user with the below cmd in “Exchange Management Shell”
Set-User “User Name” -RemotePowerShellEnabled $true
I read most of the above on the following site, but I still couldn’t access my EMC, EMS or OWA.
http://msexchangeteam.com/archive/2010/02/04/453946.aspx
My solution which I seem to be alone with wasn’t covered anywhere on the web but I solved it eventually.
4.
a) If you still can’t access EMC or EMS then go ahead below with caution. (Write down your custom settings for the “PowerShell” and “OWA” Virtual Directory in IIS)
b) Start Windows PowerShell as administrator
c) Load snapin for ex2k10:
Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
d) Display a full list (fl)
Get-PowerShellVirtualDirectory |fl
e) Delete your failing PowerShell virtual directory, one of these two commands should work:
Get-PowerShellVirtualDirectory | Remove-PowerShellVirtualDirectory
Remove-PowerShellVirtualDirectory -identity "powershell-vdir "
f) Restart IIS:
iisreset
g) Create a new IIS PowerShell virtual directory
New-PowerShellVirtualDirectory
Name: PowerShell
h) Restart IIS once more:
iisreset
j) Disable “Require SSL” Setting on the virtual directory.
Set-PowerShellVirtualDirectory -identity "powershell-vdir" -RequireSSL:$false
You may also go ahead and set SSL settings manually on the virtual directory “PowerShell” in IIS 7.
>Internet Information Services (IIS) Manager, <Servername>, Sites, Default Web Site, PowerShell and in the right panel, scroll down to SSL Settings.
Untick Require SSL and set to Ignore. Apply.
If you get this error when visiting OWA together with a Forms Based authentication:
"The Microsoft Exchange Active Directory Topology service on server localhost can't be contacted via RPC. Error 0x5."
5.
a) Then remove your OWA virtual directory and re-create it with default settings:
Get-OwaVirtualDirectory | Remove-OwaVirtualDirectory
b) Restart IIS:
iisreset
c) Create a new OWA virtual directory:
New-OwaVirtualDirectory
e) Restart IIS once more:
iisreset
Now go ahead and see if OWA works. It all worked fine for me.
This worked great for me when getting an error 403 when opening my exchange management console. This, in combination with manually adding the Powershell app pool fixed my issues. Thanks!
I’m very pleased to hear that it helped you!
Cheers
Niklas
Thaks, Great help
Niklas, thanks so much for this post.
I’m wondering if you might have a suggestion for an issue where I can succesfully connect to Exchange 2010 using the following Target on the EMS icon properties as follows:
C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -noexit -command “. ‘D:\Program Files\Microsoft Exchange\V14\bin\RemoteExchange.ps1’; Connect-ExchangeServer -serverFQDN SERVER”
HOWEVER,
if change to -auto (instead of “serverFQDN SERVER”), I get the following:
[server.domain.com] Connecting to remote server failed with the following error message : WinRM cannot process the request. The following error occured while using Kerberos authentication: The
network path was not found.
Possible causes are:
-The user name or password specified are invalid.
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The Service Principal Name (SPN) for the remote computer name and port does not exist.
-The client and remote computers are in different domains and there is no trust between the two domains.
After checking for the above issues, try the following:
-Check the Event Viewer for events related to authentication.
-Change the authentication method; add the destination computer to the WinRM TrustedHosts configuration setting or use HTTPS transport.
Note that computers in the TrustedHosts list might not be authenticated.
-For more information about WinRM configuration, run the following command: winrm help config. For more information, see the about_Remote_Troubleshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException
+ FullyQualifiedErrorId : PSSessionOpenFailed
I did check IP settings and I can succesfully ping the FQDN wth no problems. Any suggestions?
thanks!
No problem, I’m glad I could help!
I’m assuming your DNS is setup correct.
Then I would guess it has something to do with any of these:
-Kerberos is used when no authentication method and no user name are specified.
-Kerberos accepts domain user names, but not local user names.
-The client and remote computers are in different domains and there is no trust between the two domains.
-Check the Event Viewer for events related to authentication.
Did you check Event Viewer? – What does it say?
i let myself o be the next with trouble )
-Kerberos is used when no authentication method and no user name are specified.
– Where ? gpedit.msc for winrm ? i allowed everything just to make it work somehow!
-Kerberos accepts domain user names, but not local user names.
– there is no need to accept local usernames i guess!
-The client and remote computers are in different domains and there is no trust between the two domains.
– Both of them are on 1 server! let me say LOCALY!
btw!! if i “action” – “add exchange forest” – and i uncheck “logon with default credentials” (it willl ask me for right credentials.. ) (with the “check” i see the same error.. network path now found..) i don’t see summary of my server (when step cursor on the name i’ve added minute ago) but i see all my mailboxes … very strange behaviour… so i would be apritiate mush for help! Thank you!
$session = New-PSSession -Configurationname http://localhost/powershell/Microsoft.Exchange -Connect
ionUri http://localhost/powershell?serializationLevel=Full -Credential $user
[localhost] Connecting to remote server failed with the following error message : The WinRM client cannot process the r
equest. The WinRM client tried to use Negotiate authentication mechanism, but the destination computer (localhost:80) r
eturned an ‘access denied’ error. Change the configuration to allow Negotiate authentication mechanism to be used or sp
ecify one of the authentication mechanisms supported by the server. To use Kerberos, specify the local computer name as
the remote destination. Also verify that the client computer and the destination computer are joined to a domain. To u
se Basic, specify the local computer name as the remote destination, specify Basic authentication and provide user name
and password. Possible authentication mechanisms reported by server: For more information, see the about_Remote_Troubl
eshooting Help topic.
+ CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExc
eption
+ FullyQualifiedErrorId : PSSessionOpenFailed
PS C:\Users\aerotop>
I really have no clue, I can’t help you much more.
But I really believe it has do to with Kerberos authentication.
we can really run some test.. if you have a time for it…
we have right where it was started. -auto doesn’t work. FQDN works!
if in gpedit.msc we disallow Negotiate authentication for client we have an error
PS C:\Users\aerotop> winrm get winrm/config/client/auth
WSManFault
Message = The WinRM client cannot process the request. Negotiate authentication is currently disabled in the client
configuration. Change the client configuration and try the request again. If this is a request for the local configurati
on, use one of the enabled authentication mechanisms still enabled. To use Kerberos, specify the local computer name as
the remote destination. To use Basic, specify the local computer name as the remote destination, specify Basic authenti
cation and provide user name and password.
Error number: -2144108319 0x803380E1
The WinRM client cannot process the request. Negotiate authentication is currently disabled in the client configuration.
Change the client configuration and try the request again. If this is a request for the local configuration, use one of
the enabled authentication mechanisms still enabled. To use Kerberos, specify the local computer name as the remote des
tination. To use Basic, specify the local computer name as the remote destination, specify Basic authentication and pro
vide user name and password.
Does it mean that it tries to use NOT kerberos by default ? is it alright ? how can we change it ?
Huge Thanks !
Was scrolling the Net for almost 2 weeks, then your last suggested powershell tips solved my problem.
Thanks again,
Peter
THANK YOU! THANK YOU! THANK YOU!
This worked great! I spent 3 days (including my birthday) trying to resolve this for my client.
God Bless,
Steven
Solution:
Server Manager > Roles > Web Server (IIS) > Scan this role
Comes up with error “Application pools should be set to run as application pool identitiies”.
To fix that, I went to Administrative Tools > IIS Manager > (hostname) > Application Pools > Right-click each application pool except Classic .NET AppPool > Advanced Settings > Identity > “Change to:” Application Pool Identity
Now I did that… and then calls started coming in no one was able to get to their OWA. I couldn’t even get to the EMC or EMS without errors similar to as mentioned above.
Being as the permissions as shown in Step 2 above were correct. I remembered having also made this change and reverted it.
So again: To fix that, I went to Administrative Tools > IIS Manager > (hostname) > Application Pools > Right-click each application pool except Classic .NET AppPool > Advanced Settings > Identity > “Change to:” LOCAL SYSTEM
Now, at least everything works again. I didn’t need to reboot for this to take effect, but if it makes ya feel better select ‘recycle’ on each Application Pool item.
Exchange 2010 functionality is more important to me than a best practices warning here.
I’m really glad I could help you solve your nightmares :)
Thanks for your efforts. The web has many sites with solutions like this one:
http://blogs.technet.com/b/exchange/archive/2010/02/04/3409289.aspx
No site ever mention what you do on step 2 above, authentication methods. By enabling Windows Authentication only I was able to start the Exchange 2010 console and shell.
Thanks!
Peter A
Thank You,Thank You,Thank You,Thank You,
You have no idea how long I have been working on this.
Yet you made so simple. You have been promoted to Guru status.
Not to mention you saved my ass.
Thnaks again
Angelo
Hi
Sorry for my English…
I had exactly the same problem (The WinRM client received an HTTP server error status (500)).
This was due to dupplicated SID’s (2 cloned VM’s, one for DC, the other for Exchange).
What worked for me, and since no problem :
– Sysprep on my Exchange server (under C:\Windows\System32\Sysprep\Sysprep.exe),
– Join domain
– Reinstall Exch,
And everything’s fine
…
I’m thrilled! =) I’m hoping more can find this small blog and benefit out of this post.
Great information. I had to go down the path of removing and creating the Powershell directory. All working after that.
Only thing that was different was “powershell-vdir”, it wasn’t called that on my machine, but using the alternative suggestions worked.
Why can’t Microsoft just bloody well sort this out, you spend a load on money for their software and it breaks itself. I found that ECM was working fine until I installed SQL Server, then it stopped working.
@DavidAVO
Awesome :) I assume you mean that this alternative suggestion was working?
Get-PowerShellVirtualDirectory | Remove-PowerShellVirtualDirectory
That command would delete ALL powershell vdirs. Even those custom you might have created, which is quite odd. So its relatively safe.
Believe me, the same thoughts was in my head when I had this problem.
Hi Niklas,
I have tried to recreate the powershell vdir with name “PowerShell” but it display an error. If I recreate it with another name it created it but the EMC can not access:
The error is:
cmdlet New-PowerShellVirtualDirectory en la posición 1 de la canalización de comandos
Proporcione valores para los parámetros siguientes:
Name: PowerShell
New-PowerShellVirtualDirectory : Error al crear el directorio virtual de IIS “IIS://MIRAFLORES.inder.gov.local/W3SVC/1/
ROOT/PowerShell” en “MIRAFLORES”.
En línea: 1 Carácter: 31
+ New-PowerShellVirtualDirectory <<<<
+ CategoryInfo : InvalidOperation: (MIRAFLORES\PowerShell (Default Web Site):ADObjectId) [New-PowerShellV
irtualDirectory], InvalidOperationException
+ FullyQualifiedErrorId : F96A52FA,Microsoft.Exchange.Management.SystemConfigurationTasks.NewPowerShellVirtualDire
ctory
Can you help me to link the EMC to use the new PowerShell vdir?
Hi,
i´m not able to recreate the Powershell-VDir.
The cmdlet first writes a warning: System.NotSupportedException: Not supported field(MailEnabled)
and then quits with an error: InvalidOperationException
No VDir is created, i´ve also tried it with different names and even on another server…
This is very Bad!
Any Help appreciated…
For anyone who found this (as I did) because they had the same error as Mario: I found out that running Powershell in version 2.0 mode worked, as Exchange 2010 doesn’t like Powershell 3.0.
Type:
powershell -version 2.0
to start a new powershell session in version 2 mode. Then, New-PowershellVirtualDirectory should work.
It’s a pity you don’t have a donate button! I’d definitely donate to this excellent blog! I suppose for now i’ll settle for book-marking and adding your RSS feed to my Google account. I look forward to brand new updates and will share this website with my Facebook group. Chat soon!Pinellas Park Roofing, 9753 66th St., #206, Pinellas Park, FL 33782 – (727) 755-0026
Thank you a bunch for sharing this with all folks you really recognize what you are talking approximately! Bookmarked. Please also discuss with my website =). We could have a hyperlink exchange arrangement between us
Thank you for taking the time to publish this article. I had the same issue with Exchange 2013 after installing AD CS on the same server. I needed to make one amendment to your steps and add an extra step:
Step 4j;
Replaced:
Set-PowerShellVirtualDirectory -identity “powershell-vdir” -RequireSSL:$false
with
Get-PowerShellVirtualDirectory | Set-PowerShellVirtualDirectory -RequireSSL:$false
Extra Steps:
6a : get-ecpvirtualdirectory | remove-ecpvirtualdirectory
6b : iisreset
6c : new-ecpvirtualdirectory
6d : iisreset
7 : reboot server
8a: Follows steps in article http://support.microsoft.com/kb/2027063
8b: Check PowerShell vDir under Default website is pointing to \Program Files\Microsoft\Exchange Server\V15\ClientAccess\PowerShell
Below is the solution that solved my problem to access the management shel and console to exchange 2010.
Before the change
netsh winhttp show proxy
Current WinHTTP proxy settings:
Proxy Server(s) : http=10.214.17.11:8080
Bypass List : (none)
After the change
C:\Windows\system32>netsh winhttp set proxy proxy-server=”http=10.214.17.11:8080″
bypass-list=”*.xxx.com.xx”
Current WinHTTP proxy settings:
Proxy Server(s) : http=10.214.17.11:8080
Bypass List : *.xxx.com.xx
I set the winhttp settings earlier and later i was not able to acces the exchange console anymore using management shell and managment console. everything is back to normal.
Thanks.. i moved my lab to a new building and my VM had changed to DHCP rather than my manual configuration. but once I entered my DNS manually and my Domain controller was detected then all was back to normal.. thanks for this article.. thought I mentioned it in case there’s one that has just moved always check the simple first before going to the difficult stuff.