GSX Blog

How To Resolve a PowerShell Kerberos Issue

Posted by Olivier Raynaut on Fri, Aug 23, 2013

powershell kerberos

Today I was trying to connect to an Exchange 2013 server using remote PowerShell, and I had this strange error come up:

Connecting to remote server SERVERNAME failed with the following error message : WinRM cannot process the request. The following error with errorcode 0x80090311 occurred while using Kerberos authentication: There are currently no logon servers available to service the logon request.

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.  

When I researched this error on the Internet, every case mentioned that this can happen when there is no trust between the domain or when no trusted host is set. In my case, everything was set properly. I tried addressing the issue on other computers and it was working fine. My computer was the only one failing to connect remotely with PowerShell…

After looking over the Exchange server event log, I found out that I could not see the successful logon event. Then, I tried to connect using the Negotiate authentication and found that NTLM was used in the event log instead of Kerberos…That’s when I thought the issue had to be related to Kerberos.

Once I started to install Network monitors to look at the network frames on both ends, I found a TechNet article explaining the steps on how to troubleshoot Kerberos. The article instructed me to clear all the caches, including Kerberos tickets. I started immediately with the Kerberos tickets cache, and it solved the issue!

So, in case you encounter similar issues with Kerberos, this could be your solution (in cmd.exe):

KList purge

I hope this will save you time someday, as I spent several hours finding the issue myself. For any other PowerShell errors, this article will help you find even more solutions.

CTA-bas-Blog3

 

 

 

 


GSX' solution provides greater visibility into Office 365 performance with precise insights and a holistic view to manage the end-user experience. We monitor ever-changing conditions and expose any obstacles in the cloud, on-premises, or anywhere in between.

Getting set up is quick and easy- Get started today and see how you can keep your employees on the path to optimal productivity. 

Tags: Exchange 2013, kerberos, Exchange, Powershell, Best practices