1 November 2026, 18:07Виталий Лещенко

Hyper-V. Part 7: Managing Hyper-V from a workstation

In all the previous parts, commands were run on the host itself. That is not how it is done in practice: there is no need to log on to the host over RDP for every machine, and a Server Core host has nowhere to open a console window anyway. Let's look at how to manage Hyper-V from an administrator's workstation: which tools to install on it and which rights to grant, how to connect to a host in a domain and outside a domain, how to open a machine's console and how to run commands inside a guest without its network.

Management tools

Hyper-V Manager and the PowerShell module are available in Windows 10 and 11 Pro and Enterprise editions; Home has no Hyper-V feature (Hyper-V on Windows). The hypervisor itself doesn't have to be installed on the workstation — the management tools are enough (remote management of hosts):

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Tools-All -All
Get-WindowsOptionalFeature -Online -FeatureName 'Microsoft-Hyper-V-Management*' | Format-Table FeatureName, State

Microsoft-Hyper-V-Tools-All includes two features: Microsoft-Hyper-V-Management-Clients — Hyper-V Manager (virtmgmt.msc) and the virtual machine connection window vmconnect.exe, and Microsoft-Hyper-V-Management-PowerShell — the Hyper-V module. In the "Windows Features" window this is the "Hyper-V Management Tools" item.

On another Windows Server from which you manage hosts, the same tools without the role itself are installed by Install-WindowsFeature RSAT-Hyper-V-Tools (installing the role). The clustering module, which will be needed in the parts about building and maintaining the cluster, is RSAT-Clustering-PowerShell on a server or the Rsat.FailoverCluster.Management.Tools capability on Windows 10/11:

Add-WindowsCapability -Online -Name 'Rsat.FailoverCluster.Management.Tools~~~~0.0.1.0'

Rights on the host

The user must be a member of the local Administrators or Hyper-V Administrators group on the host. The latter gives full access to Hyper-V but not to the rest of the system (built-in groups), so virtualization administrators are added to it:

Invoke-Command -ComputerName hv1, hv2 { Add-LocalGroupMember -Group 'Hyper-V Administrators' -Member 'CORP\hv-admins' }
Invoke-Command -ComputerName hv1, hv2 { Get-LocalGroupMember -Group 'Hyper-V Administrators' }

Membership in Hyper-V Administrators gives no rights to files: if a machine needs a disk from a folder the user has no access to, Add-VMHardDiskDrive will refuse. Hyper-V folders on the host are usually configured so that the group has full access to them.

Host in the same domain

If the workstation and the host are in the same domain, logon uses Kerberos and nothing needs to be configured except remote management enabled on the host (Enable-PSRemoting; on Windows Server it is enabled by default). Hyper-V module cmdlets accept -ComputerName and reach the host over WMI — that is TCP port 135 and a dynamic port from the 49152–65535 range (Windows service ports):

Get-VM -ComputerName hv1, hv2 | Format-Table ComputerName, Name, State, Uptime
Start-VM -ComputerName hv1 -Name app1
virtmgmt.msc    # Hyper-V Manager, "Connect to Server" → hv1

It is more convenient to open a CIM session once and pass it to all commands — then you don't have to repeat the connection for each one:

$hv = New-CimSession -ComputerName hv1, hv2
Get-VM -CimSession $hv | Format-Table ComputerName, Name, State
Get-VMSwitch -CimSession $hv | Format-Table ComputerName, Name, SwitchType

Everything beyond the Hyper-V module — the Storage and NetAdapter modules, files, services — is more convenient to run on the host itself through PowerShell Remoting (WinRM, TCP 5985):

Invoke-Command -ComputerName hv1 { Get-Volume | Format-Table DriveLetter, FileSystemLabel, SizeRemaining, Size }
Enter-PSSession -ComputerName hv1

If your account is not an administrator of the host, Hyper-V Manager can connect as a different user ("Connect as another user"), and PowerShell has -Credential: Enter-PSSession -ComputerName hv1 -Credential CORP\hv-admin.

Host outside the domain

Hyper-V Manager connects to a host in a workgroup (or in another domain without a trust) through CredSSP. The setup follows the documentation (remote management of hosts). On the host:

Enable-PSRemoting
Enable-WSManCredSSP -Role Server

On the workstation:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value 'hv9.example.net' -Concatenate
Enable-WSManCredSSP -Role Client -DelegateComputer 'hv9.example.net'

Sometimes the group policy "Computer Configuration → Administrative Templates → System → Credentials Delegation → Allow delegating fresh credentials with NTLM-only server authentication" with the value wsman/hv9.example.net is also needed. The credentials for connecting are those of a local account on the host: hv9\Administrator.

$cred = Get-Credential 'hv9\Administrator'
Get-VM -ComputerName hv9.example.net -Credential $cred

Machine console: vmconnect

To see a machine's screen — OS installation, the boot loader, a blue screen, a machine without a network — you need the console. It is opened by vmconnect.exe — the same window we opened on the host itself in part one:

vmconnect.exe hv1 app1

Over the network the connection goes only as far as the host: the picture of the machine's screen is served by the VMMS service, which listens on TCP 2179 (Windows service ports). That is why the console works even if the guest has neither a network nor RDP enabled. To check on the host:

Invoke-Command -ComputerName hv1 { Get-NetTCPConnection -LocalPort 2179 -State Listen }

The console has two modes. Basic shows the screen and passes the keyboard and mouse — like a monitor connected to the machine. Enhanced session is RDP that runs not over the network but over VMBus: with it, the clipboard and file copying work, as well as redirection of local drives, printers, audio, USB devices and smart cards, and the window changes the guest's screen resolution (local resources in VMConnect). Requirements:

the enhanced session setting is enabled on the host — Set-VMHost -EnableEnhancedSessionMode $true; on Windows Server it is disabled by default (Set-VMHost);
vmconnect runs on Windows 10, Windows Server 2016 or a newer system;
the guest runs Windows 10 or Windows Server 2016 or newer with Remote Desktop Services enabled.

Set-VMHost -ComputerName hv1 -EnableEnhancedSessionMode $true
vmconnect.exe hv1 app1 /edit     # open the session settings: resolution, drives, devices

For Ubuntu and other Linux distributions, enhanced session is configured separately, inside the guest (same source).

The console is a tool for cases when there is no other way to connect to the machine. For everyday work, you connect to the guest as to any server — over RDP, WinRM or SSH over the network: that way you don't need Hyper-V administrator rights on the host, and the session doesn't depend on which cluster node the machine is currently on.

PowerShell Direct

From the host you can run commands inside the guest without a network and without configured WinRM — the channel runs over VMBus. This is PowerShell Direct, which we already used in the parts about disks and networking: it requires a host and a guest no older than Windows Server 2016 (or Windows 10) and the guest's credentials (PowerShell Direct).

$cred = Get-Credential 'app1\Administrator'
Invoke-Command -VMName app1 -Credential $cred -ScriptBlock { Get-NetIPAddress -AddressFamily IPv4 }
Enter-PSSession -VMName app1 -Credential $cred
$s = New-PSSession -VMName app1 -Credential $cred
Copy-Item -ToSession $s -Path 'D:\dist\agent.msi' -Destination 'C:\Temp\'

This is how machines with a misconfigured network or firewall are rescued: you can't get into them over the network, but you can over VMBus. The machine must be running and be on the same host where the command runs; the credentials are checked by the guest itself, so membership in Hyper-V Administrators on the host gives no access inside the machine.

PowerShell Direct works only locally on the host, so from a workstation it is called from inside a session on the host, and the guest's credentials are passed through $using::

$cred = Get-Credential 'app1\Administrator'
Invoke-Command -ComputerName hv1 {
    Invoke-Command -VMName app1 -Credential $using:cred { Get-Service W32Time }
}

Looking at it by hand

All machines on all hosts in one table — from the workstation:

$hv = New-CimSession -ComputerName hv1, hv2
Get-VM -CimSession $hv | Sort-Object ComputerName, Name |
    Format-Table ComputerName, Name, State, Uptime, @{n='MemGB'; e={[math]::Round($_.MemoryAssigned/1GB, 1)}}

Check that all the required host ports can be reached from the workstation:

foreach ($p in 135, 5985, 2179) {
    Test-NetConnection -ComputerName hv1 -Port $p | Select-Object ComputerName, RemotePort, TcpTestSucceeded
}

Sources

Install Hyper-V on Windows and Install the Hyper-V role on Windows Server — Windows editions, management tools;
Remotely manage Hyper-V hosts with Hyper-V Manager — connecting to a host in a domain and outside a domain;
Active Directory security groups — the Hyper-V Administrators group;
Service overview and network port requirements for Windows — WMI, WinRM and VMConnect ports;
Use local resources on Hyper-V virtual machine with VMConnect — basic and enhanced session;
Set-VMHost — enabling enhanced session on the host;
Manage Windows virtual machines with PowerShell Direct — PowerShell Direct requirements and sessions.

An administrator's workstation needs only the management tools and membership in Hyper-V Administrators: the module reaches the hosts over WMI, the machine console goes to VMMS on port 2179, and PowerShell Direct leads inside a guest without a network.

Next — part 8: moving virtual machines between hosts. Export and import, live migration without a cluster and its authentication, storage migration of a running machine, processor compatibility, updating the configuration version after a move, and Hyper-V Replica for disaster failover.