Has anyone seen this or know the solution to fix it? Exchange error: The attempt to connect to (server/PowerShell) using "Kerberos" authentication failed: Connecting to remote server failed with the following error message: The WinRM cannot process the request. The authentication mechanism requested by the client is not supported by the server or unencrypted traffic is disabled in the service configuration. Verify the unencrypted traffic setting in the service configuration or specify one of the authentication mechanisms supported by the server. I am also unable to launch the Exchange Power Shell and also receive a connection error. I have verified that the path is correctly point to the “C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\PowerShell” directory. I ran the EMTShooter tool http://blogs.technet.com/b/exchange/archive/2010/12/07/3411644.aspx Error from EMTShooter log file: Connecting to remote server failed with the following error message : The WinRM client cannot process the request. The WinRM client tried to use Kerberos authentication mechanism, but the destination computer (ServerName.domain.local:80) returned an 'access denied' error. Change the configuration to allow Kerberos authentication mechanism to be used or specify 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 use 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_Troubleshooting Help topic. + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException + FullyQualifiedErrorId : PSSessionOpenFailed The Exchange Management Troubleshooter successfully completed connecting to: Output from screen: Welcome to the Exchange Management Troubleshooter! We recommend that you run the troubleshooter after making changes to IIS to ensure that connectivity to Exchange Powershell is unaffected. Checking IIS Service... Checking the Exchange Install Path variable... Checking the Powershell Virtual Directory... Checking the Powershell vdir SSL setting... Checking the Powershell vdir path setting... Checking HTTP Port 80... Checking HTTP Port 80 Host Name... Testing for errors... VERBOSE: Connecting to servername [servername.local] Connecting to remote server failed with the following error message : The WinRM client cannot process + CategoryInfo : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportExcep + FullyQualifiedErrorId : PSSessionOpenFailed The Exchange Management Troubleshooter successfully completed connecting to: servername Failed to connect to any Exchange Server in the current site. Problem found: Looking for error... The Path of the Powershell virtual directory has been modified. The PowerShell virtual directory must point to the "\Exchange Server\v14\ClientAccess\PowerShell" directory or you will encounter problems. After each error is resolved, close this window and re-run the tool to check for additional problems. [EMTS] C:\Windows\System32\WindowsPowerShell\v1.0> The issue is that it does point to that directory!!! Also I have verified the following are correct…. -KERBAUTH should only be registered in IIS under modules on the PowerShell Site (not at the Default Site, and not at the Server level) -KERBAUTH should only be registered as NATIVE, not as Managed at the PowerShell Site in IIS -KERBAUTH should only be registered directly at the PowerShell Site in IIS, not Inherited. Check to see if the Default Web Site has HTTP Redirect setting enabled, by selecting Default Web Site on IIS, and expanding “HTTP Redirect”. If it is enabled, try the workaround of selecting the option under “Redirect Behavior”:

Hi, Try the below links out and see if it resolve your problem. http://social.technet.microsoft.com/Forums/en-US/winservercore/thread/ee86c814-0932-4380-be9c-cd40adbbdaf9/ http://itproafrica.com/technology/exchange/exchange-2010-remote-powershell-breaks-after-addremovechange-of-ip-address/

Hi check the bindings of default web site. is there any IP address un related your system on HTTP and HTTPS? they must be * (All unsigned)Best Regards, Sonat YAYLALI

I am running this from the Exchange server and not from a Win7 box. So are you saying that I need to have the server and any clients that connect listed as a trusted host? Here is the current output and nothing listed under trusted host. PS C:\Users\BHCAdmin> winrm get winrm/config/client Client NetworkDelayms = 5000 URLPrefix = wsman AllowUnencrypted = false Auth Basic = true Digest = true Kerberos = true Negotiate = true Certificate = true CredSSP = false DefaultPorts HTTP = 5985 HTTPS = 5986 TrustedHostsJeff Fantin

The only IP I see is the 127.0.0.1 address for http and https. Also, I have not changed the IP of the server at any time. Read some articles that it could cause this but thats not the case in my situation. Thanks!Jeff Fantin

Hi, Is the https assigned to a cert? If yes, which one? If it is assign to the self-assigned one? if yes, do you have another cert for this box i.e. cert called exchange cert. If that's the case then assign it to the cert you generated for the exchange server.

Yes, both the * SSL and the 127. SSLs are the self assigned ones that SBS created (remote.webname) cert. One thing I left out that might be helpful is that this is an SBS 2011 server. All of the install and config was done through the install package. It was working up until the lastets bunch of patches I applied. I honestly dont know which one would have caused the config issue though. The issue is that at this point uninstalling the patches doesnt seem like a good idea. There was a server name cert and I tried that but it didnt work so I switched it back.Jeff Fantin

Can you generate another cert and assign it to the new cert. It might not be the patch but who knows about sbs patches.

Ok, went into cert manager and found the names of the Exchange CA certs. I applied it to both * and 127 SSl entries and restarted IIS and it didnt work.Jeff Fantin

Do you have any entries there that is assign to 127.0.0.1? If yes, then apply the certs to the https

· Hi Jeff, Just a suggestion for you to check. Please confirm that whether you have other applications using the same port (80) with Default website . For instance whether you have sharepoint deployed. If indeed, try to change the application to use other port and test again. Thanks. Best Regards!

Rowen... That was it. Somehow there was a new site called SharePoint that I figured was normal because SharePoint is installed as part of SBS 2011. I disabled it and the SBS install of SharePoint continued to function somehow. I dont understand that unless one of the patches installed this outside of the SBS install. Now I just have to figure that one out. Thanks to everyone helping out!!! JeffJeff Fantin