Cluster Aware Updating -Test-CauSetup -Hostname Failing -FQDN Working RRS feed

  • Question

  • I have been searching blog after blog and trying everything I have seen but I cannot seem to get "Cluster Aware Updating" past the below error. I tried posting in the Hyper-V forum but I was told I should try the PS forum.

    When I run: Test-CauSetup -ClusterName hvcluster    (tried with -authentication as well)

    Rule ID 3, "Windows Powershell remoting should be enabled on each failover cluster node". 

    WARNING: Connecting to remote server HV1 failed with the following error message : WinRM cannot process the request. The following error occurred while using Kerberos authentication: Cannot find the
    computer HV1. Verify that the computer exists on the network and that the name provided is spelled correctly. For more information, see the about_Remote_Troubleshooting Help topic.

    When I try connecting with WBEMTest it connects fine with the host name and FQDN.

    Enter-PSSession -Computername HV1   fails

    Enter-PSSession -Computername HV.domain   (FQDN) connects

    I can use computer manager and server manager remotely from a Windows 2K16 without any issues. I have gone through each machine and ran Enable-Psremoting -force. I have also tried putting in the remote server in the trusted host list via IP, host name and * even though they are on the same domain. I added the hostnames into the proxy, same error. Nothing seems to work.

    Is there a way to have the CAU use the FQDN or am I missing something else? 

    Through my testing it seems to be something to do with Kerberos.

    Thank you

    • Moved by jrv Thursday, February 21, 2019 1:32 PM Better forum
    Monday, February 4, 2019 10:46 PM

All replies

  • Enable WinRM on the remote.  Please read the whole error carefully.  The command requires remoting to be enabled.


    Tuesday, February 5, 2019 1:25 AM
  • Hi Jrv,

    OP said he has gone through each machine and ran Enable-Psremoting -force. So I don't think it is the reason why winrm is not enabled. 

    Best Regards,


    Just do it.

    Tuesday, February 5, 2019 6:45 AM
  • "Cannot find the computer" is a place to start.

    DNS?  RPC? Firewall?


    Tuesday, February 5, 2019 7:17 AM
  • Per my original post I have ran "Enable-PSRemoting - Force".

    Enter-PSSession -Computername HV1   fails

    Enter-PSSession -Computername HV.domain   (FQDN) connects

    Are you suggesting something else besides this?

    Tuesday, February 5, 2019 2:26 PM
  • Firewall is disabled all the way around for testing. I can ping the hostname and the FQDN, they both resolve. 

    In order to try and narrow down where the issue is, I enabled CredSSP on HV1 and not on HV2. 

    I tried these steps that were suggested from another blog:

    $cred = get-credential

    Enter-Pssession -ComputerName HV1 -Credential $cred

    I was able to connect

    On HV2, where CredSSP is not enabled, it does not connect. Throws the same Kerberos message. Makes me think that there is something wrong with the how Kerberos is being processed.

    Tuesday, February 5, 2019 2:33 PM
  • The two computers do not appear to be in the same domain.


    Tuesday, February 5, 2019 6:22 PM
  • JRV,

    Please read the original post as I stated "they are on the same domain". I have tried running this command from the hosts themselves with the same error. The only domain difference in domain is our credentials from from a domain that has a trust with this subdomain. Works fine if I use explicit credentials and the FQDN, just not the hostname.  

    Tuesday, February 5, 2019 6:28 PM
  • Then you have issues with registration of the names or with DNS.

    There is not enough information to answer your issue.  You will need to do come old fashioned troubleshooting.


    Tuesday, February 5, 2019 6:55 PM
  • Then you have issues with registration of the names or with DNS.

    There is not enough information to answer your issue.  You will need to do come old fashioned troubleshooting.


    This is not very helpful. This is why I posted on here because everything I have tried is not working. DNS is working, I can resolve the hostname and FQDN. 
    Tuesday, February 5, 2019 6:59 PM
  • Sorry but we cannot troubleshoot your system for you.  You can also search for articles and posts with similar issues.  It is clear that something is missing.  Have you checked the SPNs? What steps have you taken to troubleshot name resolution?

    You have a clearly reported Kerberos error.  This says your domain cannot contact the necessary servers to validate the Kerberos ticket.  This can be due to the second hop restriction.  The fact the CredSSP works also validates a second hop issue.


    Tuesday, February 5, 2019 7:06 PM
  • As stated I have searched various blogs and other sites for different items to try. If I had not done that, I would not of posted a new request. 

    Please elaborate on what you mean by checking SPNs?

    As for DNS, I have verified that the IPs are resolved via ping and nslookup.

    Tuesday, February 5, 2019 7:20 PM
  • If PSRemoting was not configured properly, should connecting to the remote system via PowerShell not work? I can connect to it fine with the FQDN, just not the hostname. 
    Tuesday, February 5, 2019 7:40 PM
  • It is more complex than that. Without training in Windows networking and authentication methods this can be a challenge to resolve.  There are at least two other threads in this forum with nearly the same issue. 

    Forums are not good places to do troubleshooting beyond a basic look-see.  If this is critical then either contact a consultant or open an incident with MS support.

    Again.  The error and tests show that you have Kerberos or networking issues that have to be resolved.   There are too many steps to locating the issue for us to help you with.  It could take days.


    Tuesday, February 5, 2019 7:54 PM
  • JRV, 

    I don't appreciate you talking down to me. Will you please stop responding because you are not providing any constructive assistance. I have plenty of network knowledge, I am just new to Hyper-V and not as well versed with the inner workings of PowerShell. I came here looking for assistance not to be criticized.

    Can someone besides JRV please offer some assistance. 

    Thank you 

    Wednesday, February 6, 2019 4:13 PM
  • Sorry but there is no way to solve your issue remotely in a forum.  Your issue has to be fixed at your end.  It will require a good understanding of Windows networking and authentication mechanisms.


    Wednesday, February 6, 2019 5:06 PM
  • I believe I have located the issue, just need to understand how to correct it. It looks to be related to our one-way domain transit of trust. 


    HVT (W2K16 Management)

    HV1 (Hyper-V)

    HV2 (Hyper-V)


    UserA from DomainA

    UserB from DomainB

    When I log into the HVT VM, which is on DomainB as the user (my main user account) from DomainA, which has a one-way transit of trust and then run the Test-CauSetup, it fails with the error above.

    If I login as the user from DomainB, which is the same domain as the hosts and the management system, it passes. 

    I have gone into the AD object of each host and added the management system, HVT in there with cifs. Right now I have it set to "Trust this computer for delegation to specific services only", "Use Kerberos ony". I have seen some posts that say to change it to "Use any authentication protocol" instead. I want to make this work but not open a security hole. 

    With the current delegation setting, I still get the error message when logging in with DomainA user, so what am I missing?

    Thursday, February 7, 2019 5:58 PM
  • This is usually a TGT failure caused by the "second hop" restriction.  Try using CredSSP to test if this is the issue.

    You are trying to run a command on a remote system that is trying to contact the cluster root. 

    You can also try targeting a cluster member or members to see if this will allow the authentication to proceed.

    This issue is normal for commands that access remote resources.  Installing the cluster tools locally is usually the easiest solution assuming the system used is in the same domain as the cluster.

    I usually start by drawing a diagram of all systems involved in the issue and identifying the connections that are in use.  This is a starting point for tracing the events via the logs on each system involved. 

    You should also post this in the clustering forum.  Don't post a long wordy question.  Just show the command and the error.  Those using clustering in this way will likely have experienced your issue.


    Thursday, February 7, 2019 6:16 PM
  • Hi,

    Was your issue resolved?

    If you resolved it using our solution, please "mark it as answer" to help other community members find the helpful reply quickly.

    If you resolve it using your own solution, please share your experience and solution here. It will be very beneficial for other community members who have similar questions.

    If no, please reply and tell us the current situation in order to provide further help.

    Best Regards,


    Just do it.

    Thursday, February 21, 2019 6:38 AM
  • No it has not been answered. Most of the comments prior were somewhat condescending or not helpful. Still looking for assistance.
    Thursday, February 21, 2019 1:29 PM
  • Why did you move this? I already posted in the Cluster forums. They are the ones that asked me to post in the Powershell forum since these are Powershell commands that are not going through. CredSSP is not working as well. 

    Credentials come from Domain1

    HV host is part of Domain2. 

    There is a transitive one way trust between them.

    Any thoughts on that?

    Thursday, February 21, 2019 1:36 PM
  • Curious, did this randomly break over the last couple weeks?

    Where the Why meets the What in IT.

    Friday, February 22, 2019 3:46 PM
  • No this is a new install. First time installing Hyper-V 2016 and trying to manage remotely. 
    Friday, February 22, 2019 3:52 PM
  • We had an issue where this was caused because of our proxy settings on the domain.

    If you use and http or https proxy, try:

    $PSSessionOption = New-PSSessionOption -ProxyAccessTypeNoProxyServer

    Enter-PSSession -Computername HV1

    To fix in our environment I'm just moving the servers to an OU that doesn't get the GPO with the proxy settings.
    Wednesday, April 17, 2019 9:17 PM