#Azure Migrate "Unable to connect to server" Inventory error despite discovery succeeding

1 messages · Page 1 of 1 (latest)

molten cobalt
#

Running Azure Migrate discovery against a single Linux (Ubuntu) source server via an appliance (Physical/AWS scenario, SSH key-based credential). Discovery completes and shows 1 server discovered, but I get this error on the Inventory feature:

Unable to connect to server '' due to an error. Error code: '' Error details: ''.

Note the server name/error code/details are all blank in the error itself, not just redacted by me.
What I've confirmed works:

Test-NetConnection -ComputerName <ip> -Port 22 from the appliance → succeeds
Manual ssh -i key.pem ubuntu@<ip> from the appliance → connects cleanly
sudo whoami on the source → returns root, no password prompt (NOPASSWD sudo confirmed working)
sudo -l shows the NOPASSWD:ALL rule is present and correctly applied
Clicking Revalidate on the discovered server does nothing / doesn't clear the error

So network, auth, and sudo all check out manually, but the Inventory pass still fails with an essentially empty error message. Anyone run into this or know what logs on the appliance to check for more detail (assuming there's a more verbose log than what shows in Config Manager)? Trying to figure out if this is safe to ignore or if it'll block later assessment/migration steps.

#

This is the error
Error message(s)
Unable to connect to server '' due to an error. Error code: '' Error details: ''.
Possible cause(s)

  1. Network access — the server is unreachable from the appliance due to firewall rules, NSGs, port blocks (SSH 22 / WinRM 5985/5986), DNS resolution failure, proxy interference, antivirus blocking, or the server being powered off.
  2. Remote management service not running — SSH (Linux) or WinRM/PowerShell Remoting (Windows) is disabled, misconfigured, or blocked by Group Policy on the target server.
  3. Authentication or trust — credentials are invalid, the account lacks remote access permissions, or domain trust / TrustedHosts settings prevent the appliance from authenticating (common in workgroup or cross-domain setups).
  4. The prerequisites to connect to the server have not been met.
    Recommended action(s)
  5. Test connectivity from the appliance: Run Enter-PSSession -ComputerName '' (Windows) or ssh user@'' (Linux). If this works, the issue is likely transient — click Revalidate. If it fails, proceed to the next steps.
  6. Check network and ports: Run Test-NetConnection -ComputerName '' -Port 5985 (Windows) or -Port 22 (Linux). If the port is not reachable, check firewall rules, NSGs, and DNS resolution.
  7. Verify remote management: On Windows, run winrm quickconfig and Enable-PSRemoting -Force on the target. On Linux, run systemctl status sshd. For workgroup/cross-domain Windows servers, add the target to TrustedHosts on the appliance.
  8. Review prerequisites and retry: See prerequisites. After fixing, click Revalidate. If the issue persists, contact Microsoft Support and provide the appliance machine ID (shown in the footer of the appliance configuration manager).
    Affected objects/feature(s)
    Inventory