Azure Migrate Hyper-V guest discovery fails (Error 60001 / WinRM Negotiate 0x8009030d “Failed to open runspace”) even though manual remoting works

Hello Michael S,

It sounds like you're having a tough time with Azure Migrate while assessing your Hyper-V environment. The Error ID 60001, along with the specifics regarding "Failed to open runspace" and "0x8009030d," indicates an authentication issue, even though you’ve confirmed manual remoting works.

1. Azure Migrate uses WinRM with Negotiate (Kerberos first, NTLM if Kerberos fails). It’s stricter about matching the server’s identity than a simple PowerShell test. If the appliance connects using an IP address or a name that doesn’t match the server’s registered identity, Kerberos can fail and Negotiate may not recover, causing error 0x8009030d. Use the server’s full DNS name (FQDN) instead of IP. Add those names (and IPs if needed) to the appliance’s TrustedHosts list, and make sure the appliance can reach the domain. Windows Admin Center known issues | Microsoft Learn
2. For Hyper‑V discovery, the appliance prefers WinRM over HTTPS (port 5986). If HTTPS is enforced but the target VM/host doesn’t have a valid certificate with the hostname in the CN field, the connection fails. Either set up proper WinRM HTTPS certificates on your targets, or temporarily disable HTTPS enforcement in the appliance until certificates are fixed.Windows Admin Center known issues | Microsoft Learn
3. To collect software and performance data, Azure Migrate needs access to WMI/CIM and performance counters. Just being in the Remote Management Users group may not be enough because UAC filtering can block access. Add the discovery account to Remote Management Users, Performance Monitor Users, and Performance Log Users. For quick testing, you can add it to Administrators. If UAC still blocks access, grant explicit permissions to the CIMV2 namespace. Support for physical discovery and assessment in Azure Migrate and Modernize - Azure Migrate | Microsoft Learn
4. Azure Migrate may try connecting to a VM using different addresses (FQDN, hostname, IP). If the WinRM listener is not set to Address=* or TrustedHosts doesn’t include the address being used, Negotiate can fail. Check that WinRM listeners on your targets are bound to Address=*. Add all possible names the appliance might use to TrustedHosts.
5. Hyper‑V discovery uses HTTPS (5986) by default and falls back to HTTP (5985) if HTTPS isn’t available. If you enforce HTTPS without proper certificates, discovery fails. If you rely on HTTP fallback, make sure port 5985 is open. Set up an Azure Migrate appliance for physical servers - Azure Migrate | Microsoft Learn

To resolve this you can try below steps:

1. Check WinRM listeners on each VM/host: run the below command

       `winrm e winrm/config/listener`
   

   • Make sure you see Address=*.
2. Confirm ports are open: Ensure TCP 5985 (HTTP) and 5986 (HTTPS) are open from the appliance to each VM. If HTTPS is enforced, verify the TLS handshake works (valid cert chain, CN matches hostname).
3. **Validate authentication path:**Prefer connecting by FQDN instead of IP. On the appliance, run:

       `winrm get winrm/config/client`
   

   Add the VM hostnames (and IPs if needed) to TrustedHosts
4. Fix HTTPS certificate issues (if enforced)

• Each VM/host must have a Server Authentication certificate with CN = hostname.
• If you don’t have proper certs yet, disable HTTPS enforcement in the appliance until they’re fixed.

5. Adjust permissions for discovery account Add the account to:

• Remote Management Users
• Performance Monitor Users
• Performance Log Users

For quick validation, add it to Administrators. If UAC still blocks access, grant explicit permissions to the CIMV2 namespace.

Check logs for failure

1. On the Azure Migrate Appliance:

• Appliance Diagnostic Logs: Use the Configuration Manager UI > Support > Download Logs.
• Windows Event Viewer (Appliance VM):
  • Application Log: Errors from the Azure Migrate agent or PowerShell remoting.
  • System Log: Network or service-level issues.
  • Windows Remote Management Operational Log: Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Remote Management > Operational

2. On Target VMs / Hosts

• Security Log: Check for Kerberos or NTLM logon failures (Event IDs 4625, 4776). These indicate authentication handshake issues.
• WinRM Operational Log: Event Viewer > Applications and Services Logs > Microsoft > Windows > Windows Remote Management > Operational. Look for errors related to session creation or authentication.
• WMI-Activity Log: Event Viewer > Applications and Services Logs > Microsoft >Windows > WMI-Activity > Operational. Shows if CIM/WMI queries fail due to permissions or UAC filtering.

Hope this helps. if you still encounter any issue, please do let us know, thanks.

1. I have already configured the appliance with the FQDN. The appliance's trusted host is set to *. This should allow access to all servers.
2. We don't have certificates on the VMs, so I have allowed it to connect through HTTP (this was done prior to posting). Same errors.
3. I've granted CIMV2 permissions (all) to my account. (this was added new at your suggestion). After a refresh of the appliance in the portal, I still get the same errors.
4. I have verified that the WinRM listener is set to Address=*
5. I rely on fallback. Port 5985 is open and accessible.

As a sanity check, I switched the discovery account to a domain admin account. I am still receiving the same error.

However, I just noticed the "Troubleshoot" button at the top of the appliance webpage. When I run that, there are 2 tests that are failing. They are:

The first item references "azcmagent" service. That service does not exist on the appliance virtual machine. These are the closest matches:

Regarding the second error "400 Bad Request", from the appliance VM I ran a

Test-NetConnection discoverysrv.wus2.prod.migration.windowsazure.com -Port 443

And it succeeded. So it is not getting blocked by our firewalls.

Any guidance on why that service doesn't exist on the downloaded appliance VM? Or why it's getting a bad request?

I am hoping this is related to the issue of discovery. I assume it is.

Hello Michael S, Thaks for the update. If the appliance is registered with a project key from a different Azure Migrate project/region, the request can hit the wrong discovery endpoint and be rejected.

Example: key created in East US while the appliance calls West US 2 (wus2). From Azure Migrate > Servers > Discover get a fresh project key for the exact project/region you intend, then re-register the appliance using Appliance Configuration Manager.

Also note that we cannot use Hyper-v host as the physical appliance and it should be dedicated windows server without hyper-v installed. to resolve this you recreating it with hyper-v host option.

I have completely removed and restarted a new migrate project, downloaded the appliance VM again, and configured everything with a new key (for the third time now). and I still have the diagnostic problems. There is something wrong with the Azure Migrate VM that is getting downloaded. Your suggestion of:

Also note that we cannot use Hyper-v host as the physical appliance and it should be dedicated windows server without hyper-v installed. to resolve this you recreating it with hyper-v host option.

relates to installing the migrate services on a separate machine. I am downloading the VM...not running the install script.

Can this be escalated to someone. I'm about to give up and just put everything on AWS.