Discovery Appliance successfull deployed and configured, Error 60001 on all servers in Azure

I ended up redeploying the VM and before going through the Configuration Manager, I:

• Made the HDD .vhd file larger (100 GB, to account for multiple profiles logging in), and set the memory to static at 8 GB.
• Renamed the VM to match the name I used when creating the appliance
• Set the Local Admin username and password to match the Domain Admin username and password.
• Added the VM to the domain and logged in with the Domain Admin username and password.
• Completed setup of the Configuration Manager and started the discovery

Doing those steps enabled the Azure portal to connect to all the VMs without any issue. I'm not sure if all the steps were needed, but it's working the way it should now and didn't take much more time that when I first did it (and it failed) so that's a win in my books.

Hello Robin Sangster,

Thank you for reaching out to the Microsoft Q&A forum. 

When investigated we see that error 60001 means the appliance can’t establish a WinRM/PowerShell remoting session to your servers. It’s essentially “Access is denied” on all your targets. Here’s what to check and fix:

1. Enable WinRM/PSRemoting on each VM
   • On the VM run PowerShell as admin and execute: • winrm quickconfig -quiet • Enable-PSRemoting -Force
   • Ensure Windows Firewall (or any other firewall) allows inbound on TCP 5985 (HTTP).
2. Configure TrustedHosts on the appliance
   • On the appliance VM, open PowerShell as admin and run: Set-Item WSMan:\localhost\Client\TrustedHosts “”
   • Restart WinRM service: net stop winrm & net start winrm
   • Verify with: Test-NetConnection -ComputerName -Port 5985
3. Validate credentials & UAC filtering
   • For domain-joined VMs, use DOMAIN\Username format and ensure the account is a local/admin on the VM.
   • For workgroup/local accounts, either disable Remote UAC filtering or set the registry key HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\LocalAccountTokenFilterPolicy = 1
   • Make sure you’re not using UPN format ([******@domain.com]) for local accounts; use MachineName\User.
4. Re-validate in the appliance
   • In the Appliance Configuration Manager go to Credentials & Validation, edit your Windows credential entry, then click Re-validate.
   • Once validation passes, go back to the Azure portal’s Discovery & assessment tile and Refresh services on your appliance. 

After these fixes, Error 60001 should clear and your VMs will show up as discovered. 

Let me know if any further queries - feel free to reach out!

Reference docs you might find useful:

• Common software inventory errors (Error 60001) https://learn.microsoft.com/azure/migrate/troubleshoot-discovery?view=migrate#common-software-inventory-errors

• General guidance to troubleshoot WinRM issues https://supportability.visualstudio.com/AzureMigrate/_wiki/wikis/AzureMigrate/1598688/Onboarding-(Appliance)/Generic-TSGs/General-guidance-to-troubleshoot-WinRM-related-issues

• Prerequisites and port requirements for physical servers https://docs.microsoft.com/azure/migrate/migrate-support-matrix-physical#physical-server-requirements

• Troubleshoot the Azure Migrate appliance (Access is denied) https://learn.microsoft.com/azure/migrate/troubleshoot-appliance?view=migrate#access-is-denied-error-occurs-when-you-connect-to-physical-servers-during-validation

Error 60001 (UnableToConnectToPhysicalServer) indicates that the Azure Migrate appliance cannot remotely connect to the discovered servers. In this scenario, the failing Enter-PSSession with “Access is denied” confirms that remote management (WinRM/PowerShell remoting) and/or credentials are not correctly configured between the appliance and the VMs.

Use the following steps, in order, focusing on connectivity, WinRM configuration, and credentials.

1. Verify prerequisites and ports

• Ensure each server meets the Azure Migrate prerequisites and port access requirements for physical/guest servers, especially:
  • WinRM (HTTP) port 5985 open inbound on each Windows VM.
  • Network connectivity between the appliance VM and each target VM (same network or routable, no blocking firewall/NSG in between).
• Confirm that the appliance and all VMs can resolve each other’s hostnames or use IP addresses consistently.

2. Fix WinRM / PowerShell remoting “Access is denied” On each Windows VM that Azure Migrate must connect to:

• Enable WinRM and PowerShell remoting (if not already):
  • Run Enable-PSRemoting -Force in an elevated PowerShell session.
• Ensure the Windows Firewall allows WinRM:
  • Enable the built-in “Windows Remote Management (HTTP-In)” rule for the appropriate profile (Domain/Private).
• If using domain accounts:
  • Confirm the domain admin or service account used in the appliance is a local administrator on each VM.
• If using local accounts:
  • Ensure the local admin account used in the appliance exists with the same username and password on each VM and is a member of the local Administrators group.
• Test from the appliance VM:
  • From the appliance, run Enter-PSSession -ComputerName <ServerNameOrIP> -Credential <same account configured in the appliance>.
  • This must succeed without “Access is denied” before Azure Migrate can connect successfully.

3. Validate authentication method and credentials on the appliance On the Azure Migrate appliance configuration manager:

• Confirm the correct authentication method is selected for Windows servers.
• Verify that the credentials stored for the discovered servers are the same ones that successfully work with Enter-PSSession.
• If passwords were changed or accounts updated, edit the credentials on the appliance and revalidate the servers.

4. Configure TrustedHosts if using IPs or workgroup/local accounts If the appliance connects to servers by IP address or to non-domain-joined machines:

• Add the servers’ IP addresses to the WinRM TrustedHosts list on the appliance, as recommended for error 60001:
  • Configure TrustedHosts on the appliance so it can establish remote WinRM sessions to those servers.

5. Re-run validation and discovery

• After fixing WinRM and credentials:
  • In the appliance configuration manager, revalidate the added servers.
  • Then re-run discovery and confirm that error 60001 clears in the Azure portal.

6. If the issue persists

• If all prerequisites, ports, WinRM, and credentials are correct and Enter-PSSession works from the appliance but Azure Migrate still shows error 60001:
  • Collect the appliance machine ID from the footer of the appliance configuration manager.
  • Submit a Microsoft support case including the machine ID, as recommended for unresolved 60001 issues.

References:

• Onboard on-premises servers in VMware virtual environment to Azure Arc
• Common issues in Azure Migrate assessments