six demon bag

Wind, fire, all that kind of thing!


Importing VMs From external Hyper-V Hosts

I've been working on a project where I needed to migrate (clone actually, in order to maintain a fallback scenario) virtual machines from external (standalone) Hyper-V hosts to a Hyper-V cluster. The external hypervisors were not members of the same domain as the cluster nodes. The networks were separated by a firewall. A trust relationship between the domains was not desired.

System Center Virtual Machine Manager 2012 (SCVMM) supports this scenario, but there are several steps that must be performed to prepare for the migration.

  1. Name resolution must be working on both sides. Ideally the names would be resolvable via public DNS. However, with corporate LANs that usually isn't an option. As a workaround, the remote hosts could be added the local hosts file on each server. However, this only worked on the release candidate for me. On the RTM version it failed for some reason, so I had to make changes to DNS. There are several options for this:

    • If you can open port 53 (both UDP and TCP) and allow zone transfers, create a stub zone on either side.
    • If you can open port 53, but can't allow zone transfers, create conditional forwarders for the remote domain on either side.
    • If for some reason you can't do any of the above, you can create authoritative zones for the remote domains on either side. This is the least desirable configuration, though, because your DNS server will lie about being authoritative for a domain when it actually isn't. If you have to resort to this workaround, make sure you revert it as soon as possible.
  2. Enable WinRM on by running winrm quickconfig.

  3. Make sure you allow NTLM v1 authentication. NTLM v2 only will not work. You'll see logon failures in the Security eventlog on later on (source Microsoft-Windows-Security-Auditing, event ID 4625), for instance when you're trying to deploy the agent. The event message contains the following lines (among others):

    Detailed Authentication Information:
    Logon Process: NtLmSsp
    Authentication Package: NTLM
    Transited Services: -
    Package Name (NTLM only): -
    Key Length: 0

    Define the following three security settings in either the local computer policy or a group policy:

    • Network security: LAN Manager authentication level → Send NTLMv2 response only, Refuse LM
    • Network security: Restrict NTLM: Incoming NTLM traffic → Allow all
    • Network security: Restrict NTLM: Outgoing NTLM traffic to remote servers → Audit all
  4. Allow ping between all hosts in either direction.

  5. Allow the following connections:

    • →
    • →
    • →
  6. Deploy the SCVMM agent on

    • For automatic deployment SMB and RPC are required:

      • →
      • →
      • →

      Normally RPC would also require access to UDP ports 49152-65535, but in my tests TCP alone was sufficient. According to MSKB article 929851 it's possible to restrict the dynamic port range, but I didn't check that.

    • For manual deployment copy vmmAgent.msi from the respective subfolder of %ProgramFiles%\Microsoft System Center 2012\Virtual Machine Manager\agents to (via USB stick or whatever) and manually install it there.

  7. Launch SCVMM, switch to the Fabric section and add the Hyper-V host via Add Resources → Hyper-V Hosts and Clusters. Define/use a runas account that has admin permissions on

  8. Migrate or clone the VMs from to

At one point I received the following error when I tried to add the external hypervisor to SCVMM:

Error (406)
Access has been denied while contacting the server

Recommended Action
1. Verify that the specified user account has administrative privileges on
2. Verify that DCOM access, launch, and activation permissions are enabled on Administrators group. Use dcomcnfg.exe to modify permissions, and then try the operation again.

The account I used had domain admin privileges, and the DCOM permissions were also correct. As it turned out, I had neglected to run winrm quickconfig on, so that SCVMM couldn't access the WinRM service on that host. Actually enabling WinRM resolved the issue.

A similar problem may arise when you're trying to add a vanilla Server 2008 hypervisor, because WinRM 1.0 uses other ports than WinRM 2.0. Make sure you have upgraded all servers to WinRM 2.0 before doing a migration.

Posted 20:03 [permalink]