Azure Migrate: Discovery and Assessment - Error 2147942405: Access Denied

Taranjeet Singh Malik 11 Reputation points
2021-08-16T03:01:54.877+00:00

Hi

We're trying to perform discovery and assessment of a single AWS VM. Have downloaded and installed the appliance locally on the VM. The:

  1. Setup prerequisites (connectivity to Azure, Time sync, and updates) passed
  2. AM appliance got registered
  3. Entered the physical server credentials and tried validating, however, this is failing with the below error

123348-access-denied-error.png

This is a workgroup system and the account used is a member of these groups:

  1. Local Administrator
  2. Performance Log Users
  3. Performance Monitor Users
  4. Remote Management Users

Followed the guidance here--> https://learn.microsoft.com/en-us/azure/migrate/troubleshoot-appliance#access-is-denied-when-connecting-to-physical-servers-during-validation

and here

https://learn.microsoft.com/en-us/azure/migrate/troubleshoot-discovery#error-9022-getwmiobjectaccessdenied

Also validated that the machine is accessible over Port 5985 (WinRM).

Any further suggestions / articles to troubleshoot the issue please?

Thanks
Taranjeet Singh

Azure Migrate
Azure Migrate
A central hub of Azure cloud migration services and tools to discover, assess, and migrate workloads to the cloud.
722 questions
{count} votes

1 answer

Sort by: Most helpful
  1. SadiqhAhmed-MSFT 38,891 Reputation points Microsoft Employee
    2021-08-23T07:43:50.65+00:00

    Sharing the solution with broader community!

    Here is a summary of this case for your reference:

    Issue Definition:
    Source validation failed with "Access is denied" when connecting to physical server.

    Root Cause Analysis:
    We confirmed the user account has the documented privileges and checked registry for UAC and appliance. Confirmed the WinRM is working fine.

    Per testing, we added host name and public IP in hosts, then we can pass the validation by using host name and local host, but still failed validation with public IP.

    Discovery completed successfully as expected.

    Per investigation by Ipsit, the machines created are configured as default with a private VPC. This would explain the reason why the Public IP failed to validate successfully. The loopback path as verified from nslookup stands correct as it uses a Private IP defined DNS network. Now we had 2 machines A and B:
    A trying to connect to A with a public IP address failed since A being part of a private Network was using the local DNS to identify the destination. The local VPC usually does not have global NAT data so the address translation of the public IP to a Private IP fails. The reason for this being public IPs of a machine are assigned and stored by the network provider which in this case is AWS.

    In the scenario where B connects to A or A connects to B wherein they are both part of the subnet but created independent of each other. The address translation was possible as B lies outside A’s VPC, so global AWS NAT for that environment was able to get the private IP of A associated public IP of A. Hence the connection from B to A and A to B were successful.

    More details can be found in the AWS documentation.

    ---------------------------------------------------------------------------------------------------------------

    If the response helped, do "Accept Answer" and up-vote it.