Azure Migrate Appliance - Unable to Validate HyperV Cluster - WinRM error

Dale 10 Reputation points

I am running into an error where the Azure Migration appliance will not validate a HyperV cluster with 2 servers.

Worked through: https://learn.microsoft.com/en-us/azure/migrate/tutorial-discover-hyper-v

  1. Ran the Hyper-V prep script "MicrosoftAzureMigrate-Hyper-V.ps1" as described in the documentation, finished without errors.
  2. Created the project and generated keys
  3. Downloaded the VHD and set up the appliance
  4. Connected to the web interface
  5. Followed all the Setup Prerequisites by running the script on both hosts, all finished successfully.
  6. Registered the appliance successfully - was able to confirm in Azure Portal and see the appliance
  7. Set up domain admin credentials in the domain\username format with password
  8. Added the cluster as a discovery source
  9. Validation fails with error "Server '[ClusterName]' WinRM cannot complete the operation - Verify that the specified computer name is valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows Access from this computer"
  10. Modified firewall of each cluster host server to ensure WinRM was allowed from public
  11. Tried pointing to an individual server, appliance detected cluster and changed to the cluster automatically.
  12. Re-Validation same failure
  13. Tried "enforce SSL" same failure.
  14. Verified the time on the migration appliance, time and time zone are correct
  15. Ran the "#Needs client/Appliance side settings change" from the "MicrosoftAzureMigrate-Hyper-V.ps1" script, validation still failed.

Screenshot of the error:
👁 Screenshot 2025-11-07 160844

Additional troubleshooting performed:
From the Hyper-V host servers (both):

  • Verified time was correct
  • Verified they are on the domain
  • Verified they are using a supported OS (Server 2016)
  • Verified we can log in using the same username and password as was being used by the appliance
  • Ran “winrm quickconfig” finished out saying it was already installed.

From the migration appliance:

  • Enter-PSSession -ComputerName "[cluster address]" -Credential $Creds
    • Same credentials as is being used on the appliance
    • Able to access Cluster with same creds used by appliance from the appliance.
  • Test-wsman -computerName "[Host1]" -Credential $creds -Authentication Default
    • Same credentials as is being used on the appliance
    • Get a positive response
  • Test-wsman -computerName "[Host2]" -Credential $creds -Authentication Default
    • Same credentials as is being used on the appliance
    • Get a positive response
  • Test-wsman -computerName "[cluster]" -Credential $creds -Authentication Default
    • Same credentials as is being used on the appliance
    • Get a positive response
  • Get-Item WSMan:\localhost\Client\TrustedHosts
    • Returns "*", so all should be good.
  • Dug through Event logs with nothing really standing out.

After looking through the communities and Google, I am not finding a lot on this error. Any help would be appreciated.

  1. Sam Erde 151 Reputation points • MVP

    You tested everything I would have. Let me know what the resolution turns out to be!

  2. Siva shunmugam Nadessin 10,895 Reputation points • Microsoft External Staff • Moderator

    Hello Dale,

    Kindly share the screenshot of the error you are facing for us to investigate further?

  3. Dale 10 Reputation points

    👁 Screenshot 2025-11-07 160844

    Screenshot attached.

  4. Bharath Y P 9,730 Reputation points • Microsoft External Staff • Moderator

    Hello Dale, Thanks for the update,

    • when you added the cluster as a discovery source, did you enter the full FQDN (e.g., ClusterName.domain.local) or just the short NetBIOS name? This matters because Kerberos and WinRM validation often fail if the SPN doesn’t match the exact name used. If it’s the short name, switching to FQDN usually resolves the issue.
    • Make listeners accept traffic arriving via the cluster IP and open the firewall for the active profile. 
       # Run elevated on each node
 Enable-PSRemoting -Force
 # Verify listeners are present and bound broadly
 winrm e winrm/config/listener
      Binding to Address=* avoids failures when requests hit the node via the cluster VIP.  
    • Check the SPN for the cluster FQDN; add port‑scoped SPNs to each node if needed.
    • The certificate CN/SAN must equal the exact FQDN used by the appliance (cluster FQDN).

    https://learn.microsoft.com/en-us/azure/migrate/how-to-set-up-appliance-hyper-v?view=migrate

    If still encounter an issue, please let us know, thanks

  5. Dale 10 Reputation points

    Bharath thanks for the reply!

    • FQDN - When the cluster was added the FQDN was used, not the NetbiosName.
    • Accepted traffic - In the troubleshooting performed, "Enter-PSSession" was accessed via the IP and the FQDN of the cluster, both which worked when starting from the desktop of the appliance. I am unable to check right now, but would that mean that the listener is configured to allow connections from a broad address like *?
    • I will check the SPNs and Certificate CN/SAN. If the port scoped SPNs are added, are there any ports other then 5985 and 5896 that should be added?
    • The article shared appears to be substantially similar to the one linked in the original post with no additional information on the error. Is there something I am missing in the article?

    Thanks again for helping to get to the bottom of this!

Sign in to comment

1 answer

  1. Rushabh Shah 0 Reputation points

    I was also facing the same issue and spend loads of time trying to resolve this. Finally took MS support and was able to resolve with their help. We just needed to adjust the payload size and it worked. From the appliance as well from all hosts run below cmd in powershell and this will resolve this issue.

    Set-Item -Path WSMan:\localhost\MaxEnvelopeSizeKb -Value 8192

    0 comments No comments
    Sign in to comment
Sign in to answer

Your answer