Skip to main content

The attempt to connect to http://yourserver/PowerShell using "Kerberos" authentication failed

The error you get: The attempt to connect to http://yourserver/PowerShell using "Kerberos" authentication failed: 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

If you removed Exchange server from the machine and installed it again, you can get following error when you open Exchange Management Console:
The following error occurred while attempting to connect to the specified Exchange server 'yourserver.domain.com':The attempt to connect to http://yourserver.domain.com/PowerShell using "Kerberos" authentication failed: 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.


The solution is to first export and then delete
HKCU\Software\Microsoft\ExchangeServer\v14\AdminTools\NodeStructureSettings (REG_BINARY key) registry key.

All credits go to Paul Newell on this forum http://social.technet.microsoft.com/Forums/en-US/exchangesvradmin/thread/cef4a010-0a64-40a7-8601-1539ffdb2568.

Comments

  1. anybody tried this? was it successful?

    ReplyDelete
  2. Well, actually everything that you see on this blog was in fact done by me and tested before it is put out for public. There are no "sounds like" stories here. Just facts. :)

    ReplyDelete
  3. This fixed did indeed fix my issue! consider it tested

    ReplyDelete
  4. yup worked like a charm

    ReplyDelete
  5. This worked for me - confirmed nice easy fix. Thank You !
    2pages.co.uk

    ReplyDelete
  6. No luck. Now it fails with "the client cannot connect to the destination specified in the request. Verify that the service on the destination is running." and yes, it's running.

    ReplyDelete
  7. Thanks it worked but no before I restarted the server I am using 2008 R2, after deleted the registry key it showed another error message so I restarted and tried again to open EMC and it worked , restarted a couple of time and it keeps working. Thanks

    ReplyDelete
  8. This worked perfectly.

    Thanks!

    ReplyDelete
  9. Thanks for this information, wish I had gotten this sooner.

    Greg Tench

    ReplyDelete
  10. Thanks so much for this. You are a genius!

    ReplyDelete
  11. I tried it, it work like a charm

    Thanks Dušan

    Mahmood Sabt

    ReplyDelete
  12. Thank you very much for the great post Dusan, worked wonders in minutes!

    ReplyDelete
  13. Truly saved my backside... Thanks my friend.

    ReplyDelete
  14. Worked a charm. Thanks

    ReplyDelete
  15. thanks.saved a lot of time for me.

    ReplyDelete
  16. This worked perfectly. Note:I had to log off after and log back in before it worked. Thank you for this article. -Willy

    ReplyDelete
  17. We havn't un/installed Exchange and have 3xMB 3xCas 2xEdge... Oddly I could connect to the EMC on everything except one of the MB servers.

    Removing this key on that one server fixed the issue!

    Thanks!

    ReplyDelete
  18. i tested it and its worked right away :)

    Million Thanks

    ReplyDelete
  19. Thank you that was a quick and easy fix, that came up on my first search for the issue. Well done!

    ReplyDelete
  20. This procedure works, only need to IIS reset

    ReplyDelete
  21. Worked for me - didn't need an IIS reset or server reboot. Made the change and launched EMC, right in. Still get an error on PowerShell but otherwise EMC works...

    ReplyDelete
  22. Спасибо огромное, очень пригодилось.

    ReplyDelete
  23. It didn't work for me, I had to restart IIS in order for it to connect. the problem happened when I changed the local DNS to an external one in order to check whether Exchange's Hybrid wizard will be able to confirm the public DNS changes for my domain. but didn't work.

    ReplyDelete
  24. This worked perfect for me after an IISreset, no need to reboot server.

    ReplyDelete
  25. experienced the same issue with EMC on exch2010sp3/w2008r2 server after applying Windows patch for wannacry virus, i ve tried all the solutions posted here without succes, finally got it to work again by modifying this IISmanager>default web site>ecp>Windows authentication>Advanced setting> extended protection = accept (it was on OFF)

    thanks everybody
    Mouden

    ReplyDelete
  26. i can't fix i had the same issue

    ReplyDelete

Post a Comment

Popular posts from this blog

Netscaler vs Exchange 2019 "time out during ssl handshake stage

If you are using Citrix Netscaler as load balancer in front of Exchange 2019 server you must know this: Microsoft Exchange 2019 is secured by default and allows only TLS 1.2. Therefore default schannel settings are as follows (using IISCrypto tool from Nartac Software): While Citrix Netscaler offers following Cipher Suites: TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT1024_WITH_RC2_CBC_56_MD5 TLS_DH_anon_WITH_DES_CBC_SHA TLS_DH_anon_WITH_AES_128_CBC_SHA TLS_DH_anon_WITH_AES_256_CBC_SHA TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA Now, you will fi

Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}]

 If you got this error checking the mail flow for a distribution group, it means the distribution group is closed and only internal senders can send e-mail to this group. When outside user sends e-mail to this group you get  Reason: [{LED=250 2.1.5 RESOLVER.GRP.Expanded; distribution list expanded};{MSG=};{FQDN=};{IP=};{LRT=}] Set Delivery for this group to internal and external users and your problem will be solved. 

Ports that need to be open on Firewall for Edge Transport servers

Ports that need to be open on firewall for Edge Server subscription with Hub Server to function properly: For Inbound traffic: SMTP - TCP port 25 (from Internet) SMTP - TCP port 25 (from Edge server to Hub server on internal network) For Outbound traffic: SMTP - TCP/UDP port 25 (from Edge to Internet) SMTP - TCP/UDP port 25 (from Hub to Edge server) LDAP for EdgeSync - TCP port 50389 (from Hub to Edge server) Secure LDAP for EdgeSync - TCP port 50636 (from Hub to Edge server) Since Edge server needs to communicate with Hub server it is important that it can resolve Hub transport servers by FQDN and Hub transport servers must be able to resolve Edge servers by its FQDNs. To accomplish this you need to either open 53 (DNS) port and configure internal network adapter to use internal DNS but as a security precaution I would suggest to enter DNS records for Edge servers on local DNS manually and to fill hosts file on Edge servers with FQDNs for Hub transport servers.