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 <username>).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.E2010d) 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: PowerShellh) 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-OwaVirtualDirectorye) 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.