0

I have Windows SBS 2011 running on a virtual machine, hosting an Exchange 2010 server. It has worked for years without issues, but a couple weeks ago something happened and I'm no longer able to log into the EMC. This isn't our primary email service, as we only use it for some internal application, but it's still causing a lot of headaches for me.

When I try to log in to the EMC, it gives me this error:

The attempt to connect to using "Kerberos" authentication failed: Connecting to remote server failed with the following error message: The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.

I've found a number of different articles about this issue, and they all seem to have slightly different answers for different situations, but none have worked for me.

I've tried:

  1. Restarting the VM, making sure the proper services are running and restarting any that seemed relevant
  2. Looked at the registry settings under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\HTTP\Parameters to make sure the decimal sizes are big enough.
  3. Set the TrustedHosts to *

I tried running the command "Test-FederationTrust" from Exchange Powershell and it gave me the following error:

[test-federationtrust] Connecting to remote server failed with the following error message : WinRM cannot process the r equest. 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 us e 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) [], PSRemotingTransportExc eption + FullyQualifiedErrorId : PSSessionOpenFailed

I'm not sure where to go from here. Any advice would be greatly appreciated.

Ryan
  • 3
  • 1
  • 2

2 Answers2

0

How about EMS?

In IIS manager, the Kerbauth module is not enabled on the default web site, but in the PowerShell virtual directory, the module type is Native and the DLL location is C:\Program Files\Microsoft\Exchange Server\v14\Bin\kerbauth.dll.

Figure as below: enter image description here Note: my lab is Exchange 2013.

Jianfei Wang
  • 387
  • 1
  • 4
  • Oh man, it's working!!! When I tried to view the "Modules" of the Powershell component, it gave me an error message saying it couldn't log in as the user WebAppUser. All I did was reset the password for that account to what it should have been, and everything started working again. Thank you so much! – Ryan Jan 18 '18 at 21:06
0

I've just solved this for myself and it may be that it will help everyone else - I was resigned to having to do a rebuild. Turns out to be something very simple - I had hardened my IIS setup and that's when things went awry.

Simple fix = go into IIS manager, under default website select powershell folder. in the options double click authentication and make sure that ASP .Net impersonation is switched off.

You don't even need to restart, worked straight away for me both EMS and EMC working perfectly !! Hope this helps all those stuck with this.

rob d
  • 1
  • This "simple fix =" solution worked for me 100%. I was about to set this instance on fire. Such a dumb thing to cause this bustage. Happy trails and thanks for the solution! – Arthur Apr 06 '23 at 14:47