Клиенту winrm не удается обработать запрос hyper v windows 10

Первым делом следует скачать дистрибутив операционной системы(ОС), т.к. ОС условно бесплатная, ее можно совершенно спокойна скачать с сайта microsoft, скачивать и устанавливать ОС нужно на английском языке, т.к. система не понимает русского и большая часть команд могут не работать, но проблемы в этом не вижу в самой ОС на англиском языке мы увидим только первоначальную настройку сервера! Для удаленного управления Hyper-V Server можно использовать ОС Windows Server 2012 R2 Standard или Datacenter, а также Windows 88.110.

В случае использования Windows Server 2012 R2 Standard или Datacenter необходимо установить консоль Hyper-V Manager. Это можно сделать в Server Manager или при помощи командлета PowerShell Install-WindowsFeature -Name ‘RSAT-Hyper-V-Tools’

В Windows 88.110 для установки Hyper-V Manager можно использовать средство настройки компонентов Windows.

Для остальных версий Windows необходимо установить Remote Server Administration Tools (RSAT), которую также можно скачать на официальном сайте Microsoft.

Прежде, чем перейти непосредственно к настройке серверов, хочу подробнее остановиться на схеме сети, которая будет использоваться в нашей демонстрации.

В моем случае я буду использовать наипростейший вариант — локальная подсеть 192.168.1.0/24 с двумя машинами: Hyper-V Server 2012 R2 с IP-адресом 192.168.1.5 в качестве хоста виртуализации и Windows Server 2012 R2 Standard R2 с IP 192.168.1.6 в качестве хоста управления. Обе машины не являются участниками домена и входят в рабочую группу TESTLAB.

Итак, после завершения вполне себе интуитивной установки Hyper-V Server 2012 R2 перед нами предстает рабочий стол с двумя окнами, стандартная командная строка cmd.exe и окно скрипта sconfig.cmd:

Данный скрипт позволяет произвести первоначальную настройку сервера:
– сменить имя сервера
– сменить имя рабочей группы или ввести сервер в домен
– добавить локального администратора
– включить удаленный доступ к серверу, что позволить управлять им с помощью Server Manager, консолей MMC, PowerShell, подключаться по RDP, проверить доступность с помощью pingили tracert
– настроить Windows Update и устанавливать обновления
– настроить сетевые карты сервера
– настроить время на сервере

Также настройку времени на сервере можно выполнить с помощью команды controltimedate.cpl, а настройку региональных параметров — с помощью команды control intl.cpl. При этом будут запущены привычные консоли Панели Управления.

АВТОМАТИЧЕСКИЙ ЗАПУСК POWERSHELL ПРИ ВХОДЕ В СЕАНС

Когда вышла первая версия Hyper-V Server 2008, PowerShell в нем официально не поддерживался, и, единственным способом настройки и получения информации с сервера были утилиты командной строки, такие как net, netsh, wmic, и множество других. Они не обладали единообразным интерфейсом и способом использования, что в итоге увеличивало порог вхождения для администратора и влияло на производительность работы. Но время не стоит на месте и, начиная с Hyper-V Server 2008 R2, Microsoft внедряет поддержку PowerShell, а в Hyper-V Server 2012 PowerShell можно использовать сразу после установки системы. Более того, в Hyper-V Server 2012 включен модуль PowerShell для взаимодействия с Hyper-V, а в Hyper-V Server 2012 R2 количество командлетов для работы с Hyper-V превысило значение 170. Точное значение можно посмотреть с помощью
Get-Command -ModuleHyper-V | Measure-Object

Зайдем в оболочку PowerShell и запустим командлет New-ItemProperty, который создаст новый ключ в реестре HKLM:SOFTWAREMicrosoftWindowsCurrentVersionrun.

New-ItemProperty -path HKLM:SOFTWAREMicrosoftWindowsCurrentVersionrun -Name PowerShell -Value "cmd /c start /max C:Windowssystem32WindowsPowerShellv1.0powershell.exe -noExit" -Type string

Теперь при следующем входе в систему будет запускаться окно с оболочкой PowerShell, в которой мы продолжим настройку нашего сервера.

НАСТРОЙКА СЕТЕВЫХ АДАПТЕРОВ
Если сетевые адаптеры до этого не были настроены с помощью sconfig.cmd, сделаем это с помощью командлетов PowerShell.

Смотрим текущую конфигурацию IP на сетевых интерфейсах. В моем случае адресация назначена службой APIPA, так как в сети нет DHCP сервера.

Get-NetIPConfiguration

Назначаем статическую адресацию, маску сети, шлюз по умолчанию и адреса DNS серверов. InterfaceIndex сетевого адаптера берем из вывода предыдущего командлета.

New-NetIPAddress -InterfaceIndex 13 -IPAddress 192.168.1.5 -DefaultGateway 192.168.1.1 -PrefixLength 24

Set-DnsClientServerAddress -InterfaceIndex 13 -ServerAddresses 192.168.1.2,192.168.1.3

Если использование IPv6 на сетевом интерфейсе пока не планируется, имеет смысл отключить его на интерфейсе для уменьшения «attacksurface».

Проверяем текущую настройку IPv6 на интерфейсе. Имя интерфейса берем из вывода командлетов Get-NetAdapter или Get-NetIPConfiguration.

Get-NetAdapterBinding -InterfaceDescription "Microsoft Hyper-V Network Adapter" | Where-Object -Property DisplayName -Match IPv6 | Format-Table –AutoSize

Отключить поддержку IPv6 на сетевом адаптере можно командлетом Disable-NetAdapterBinding. Данное действие будет аналогично снятию галки «Internet Protocol Version 6 (TCP/IPv6)» в настройках адаптера в графическом интерфейсе Windows.

Disable-NetAdapterBinding -InterfaceDescription "Microsoft Hyper-V Network Adapter" -ComponentID ms_tcpip6

Настройка межсетевого экрана (Advanced Firewall)

С внедрением PowerShell в Hyper-V Server появился удобный способ управления правилами межсетевого экрана, взамен устаревающего netsh. Просмотреть список комадлетов можно с помощью Get-Command.

Get-Command -Noun *Firewall* -Module NetSecurity

В качестве примера включим возможность традиционного управления межсетевым экраном через оснастку MMCс хоста управления. Для начала получим список правил, относящихся к удаленному управлению межсетевым экраном.

Get-NetFirewallRule | Where-Object -Property DisplayName -Match "firewall" | Format-List -Property Name, DisplayName, Enabled

Включаем оба правила.

Enable-NetFirewallRule -Name RemoteFwAdmin-In-TCP,RemoteFwAdmin-RPCSS-In-TCP

Теперь можно попробовать подключиться к оснастке MMC управления межсетевым экраном с хоста управления.

ВЗАИМОДЕЙСТВИЕ С SERVER MANAGER

Если гипервизор и хост управления не являются частью домена, а находятся в рабочей группе, как в нашем случае, то при попытке добавить сервер Hyper-V в Server Manager на удаленном хосте возникнет ошибка согласования WinRM.

Решается проблема довольно просто – достаточно добавить на Hyper-V Server в доверенные узлы WinRM на хосте управления и обновить текущее состояние в ServerManager.

Set-Item wsman:localhostClientTrustedHosts HYPER-V01 -Concatenate –Force

HYPER-V01 — имя вашего Hyper-v сервера

Создание дискового хранилища для виртуальных машин

Теперь настало время создать хранилище файлов виртуальных машин и файлов виртуальных дисков. Для хранения данных будем использовать отдельный раздел на физическом диске. Для начала посмотрим список командлетов PowerShell, которые используются для управления носителями. Как обычно будем использовать для этого командлет Get-Command. Во втором случае мы получим список командлетов, служащих для получения информации.

Get-Command -Module Storage

Get-Command -Verb *Get* -Module Storage

Просмотрим список физических дисков на сервере.

Get-Disk

Создаем новый раздел на диске максимально возможного размера, назначаем букву D. Используем id из Get-Disk. После этого форматируем раздел в NTFS и указываем его метку.

New-Partition -DiskNumber 0 -DriveLetter D –UseMaximumSize

Format-Volume -DriveLetter D -FileSystem NTFS -NewFileSystemLabel "VMStore"

Убедимся в правильности проделанных нами операций с помощью оснастки MMC Disk Management на удаленном хосте, для этого включим соответствующие правила на межсетевом экране.

Enable-NetFirewallRule RVM-VDS-In-TCP,RVM-VDSLDR-In-TCP,RVM-RPCSS-In-TCP

Как мы видим, наш только что созданный диск прекрасно отображается в Disk Management.

Создадим папку на нашем разделе, где будем хранить настройки и файлы дисков виртуальных машин. Командлет New-Item позволяет создавать вложенные пути, так что нет необходимости запускать его два раза для каждой папки.

New-Item -Path "D:Hyper-VVirtual Hard Disks" -Type Directory

Создадим папки D:Distrib и D:ImportedVM, которые будем соответственно использовать для хранения дистрибутивов ОС и импортированных ВМ с других хостов виртуализации.

New-Item -Path D:Distrib -ItemType Directory

New-Item -Path D:ImportedVM -ItemType Directory

Для создания шары используем командлет New-SmbShare, с помощью которого дадим полный доступ по сети для группы локальных администраторов сервера.

New-SmbShare -Path D:Distrib -Name Distrib -Description "OS Distributives" -FullAccess "BUILTINAdministrators"

New-SmbShare -Path D:ImportedVM -Name ImportedVM -Description "Imported VMs" -FullAccess "BUILTINAdministrators"

Проверяем с помощью PowerShell и с помощью ServerManager с хоста управления.

Get-SmbShare -Name Distrib,ImportedVM | Format-List

Get-SmbShareAccess -Name Distrib,ImportedVM | Format-List

Общий список командлетов, относящихся к SMB (ServerMessageBlock), как обычно можно получить с помощью командлета Get-Command.

Get-Command -ModuleSmbShare

В заключение этой темы добавлю только то, что если на сервере не используется физический или логический RAID, то для повышения производительности и надежности работы с хранилищем ВМ целесообразно использование технологии Storage Pools (к примеру, такие командлеты, как New-StoragePool, New-Volume). Более подробнее об использовании Storage Pools совместно с Hyper-V я напишу в одной из будущих статей.

НАСТРАИВАЕМ ПАРАМЕТРЫ ГИПЕРВИЗОРА

Приступим к настройке параметров гипервизора. Основные параметры Hyper-V можно получить с помощью командлета Get-VMHost.

Get-VMHost | Format-List

Как мы видим из вывода командлета, пути ВМ и виртуальных дисков сейчас размещаются на одном разделе с ОС, что нас не устраивает ни с точки зрения скорости работы, ни с точки зрения надежности. Пропишем пути к созданным в прошлом разделе папкам с помощью командлета Set-VMHost.

Set-VMHost -VirtualMachinePath D:Hyper-V -VirtualHardDiskPath 'D:Hyper-VVirtual Hard Disks'

Проверим с помощью PowerShell…

Get-VMHost | Format-List

… и с помощью Hyper-V Manager.

Как я упоминал выше, в Hyper-V Server 2012 R2 возможно использование EnhancedSessionMode для ВМ, что позволит пробросить в ВМ локальные диски, принтеры, звук, использовать буфер обмена и многомониторные конфигурации. Давайте включим его.

Set-VMHost -EnableEnhancedSessionMode 1

СОЗДАДИМ ВИРТУАЛЬНЫЙ КОММУТАТОР

Виртуальный коммутатор Hyper-V (Hyper-V Extensible Switch) предназначен для организации сетевого взаимодействия между различными ВМ, между ВМ и хостом виртуализации, между ВМ и внешней средой. На самом деле у Hyper-V Extensible Switch обширное количество возможностей, много вкусного появилось в версии 2012 R2. Так что сейчас не будем углубляться в эту тему, и создадим простейший External Switch, который привязывается к сетевой карте Hyper-V Server, и организует взаимодействие ВМ с физической сетью.

Для начала проверим поддержку SR-IOV (Single-Root Input/Output (I/O) Virtualization).

Get-VMHost | Select-Object -Property "Iov*" | Format-List

или

Get-NetAdapterSriov

В моем случае поддержки SR-IOV нет. Это связано с тем, что я немного схитрил, и в данной демонстрации у меня Hyper-V сервер запущен не на живом железе, а в виртуальной среде.

Получим список подсоединенных сетевых адаптеров

Get-NetAdapter | Where-Object -PropertyStatus -eqUp

Привязываем виртуальный свитч к сетевому адаптеру и при наличии SR-IOV включим его поддержку.

Внимание: Включить или отключить поддержку SR-IOV после создания свитча будет невозможно, для изменения этого параметра необходимо будет пересоздавать свитч.

New-VMSwitch -Name "Extenal_network" -NetAdapterName "Ethernet 2" -EnableIov 1

В моем случае Hyper-V выдает ошибку, опять же связанную с тем, что гипервизор сам запущен в виртуальной среде. На живом железе командлет создаст External Switch с именем «External_network» и привяжет его к сетевому адаптеру Ethernet 2. Виртуальный свитч также появится в списке сетевых адаптеров и на него будет перепривязаны все сетевые параметры физического адаптера Ethernet 2

Проверить можно с помощью командлетов

Get-VMSwitch и Get-NetIPConfiguration –Detailed

На этом этапе первоначальная настройка Hyper-V Server 2012 R2 закончена, и все готово для создания нашей первой виртуальной машины. Но об этом мы поговорим в следующей статье, использовать будем, естественно, PowerShell.

Hi,

I’ve been trying to configure Hyper-V remote management for 2 days now, going through Microsoft’s overcomplicated configuration requirements to get it working, but without any success.

Configuration:

Client (CLIENT01): Windows 10, WORKGROUP

Server (SERVER01): Windows 10, WORKGROUP

Microsoft’s HVRemote script runs fine on both the client and the server, meaning configuration is supposedly correct (name resolution, ANONDCOM, authentication, etc.). The client is able to query the WMI store on the server. However, it does not seem
to be enough to get things working.

Hyper-V -> «Connect to server…» is still throwing an error when connecting to the remote server: «The WinRM client cannot process the request. The destination machine must be added to the TrustedHosts configuration settings.»

Alright, so after Googling a bit, adding the host to the TrustedHosts seems simple:

Set-Item WSMan:localhostClientTrustedHosts -Value SERVER01 -Concatenate

But running this on the client gives:

Set-Item : The client cannot connect to the destination specified in the request. Verify that the service on the
destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service
running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following
command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
At line:1 char:1
+ Set-Item WSMan:localhostClientTrustedHosts -Value SERVER01 -Conc ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Set-Item], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.SetItemCommand

So let’s check WinRM on the server:

winrm e winrm/config/listener

Outputs:

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 169.254.36.241, 169.254.55.69, 169.254.84.105, 192.168.2.101, ::1, 2001:0:9d38:6abd:10ac:1878:3f57:fd9a, fe80::5efe:192.168.2.101%4, fe80::10ac:1878:3f57:fd9a%13, fe80::588e:b748:2bd:24f1%15, fe80::7120:37fa:11f9:3745%14, fe80::8409:52cd:a9fa:5469%3, fe80::a45e:493a:f66c:d28d%7

So WinRM is listening. I am able to TelNet this port from the client computer. But still PowerShell complains it can’t connect. Maybe WinRM in Windows 10 only supports HTTPS? Alright, so let’s setup WinRM HTTPS on the server:

winrm quickconfig -transport:https

WinRM complains it needs a certificate. So let’s create a certificate:

Created a ROOT CA using:

makecert -pe -n "CN=My Company Root Certification Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "My Company Root Certification Authority.cer"

Installed the ROOT CA in the Trusted Root Certification Authorities on the SERVER and the CLIENT.

Also created a certificate issued from the previously created CA using:

makecert -pe -n "CN=SERVER01" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "My Company Root Certification Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 SERVER01.cer

Installed the certificate in the personnal store on the SERVER and the CLIENT.

Still, WinRM complains it cannot find an appropriate certificate. So let’s add the listener manually:

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="SERVER01";CertificateThumbprint="ac87de6d91ae8ff5e2fd66cd02738fc2b6a6ae53"}

WinRM complains that the «Enhanced Key Usage (EKU) field of the certificate is not set to «Server Authentication».«

When I check the certificate in MMC, IT IS SET TO SERVER AUTHENTICATION!!!

Now I’m out of ideas and I just want to bang my head against a brick wall…

Any help is greatly appreciated!

Hi,

I’ve been trying to configure Hyper-V remote management for 2 days now, going through Microsoft’s overcomplicated configuration requirements to get it working, but without any success.

Configuration:

Client (CLIENT01): Windows 10, WORKGROUP

Server (SERVER01): Windows 10, WORKGROUP

Microsoft’s HVRemote script runs fine on both the client and the server, meaning configuration is supposedly correct (name resolution, ANONDCOM, authentication, etc.). The client is able to query the WMI store on the server. However, it does not seem
to be enough to get things working.

Hyper-V -> «Connect to server…» is still throwing an error when connecting to the remote server: «The WinRM client cannot process the request. The destination machine must be added to the TrustedHosts configuration settings.»

Alright, so after Googling a bit, adding the host to the TrustedHosts seems simple:

Set-Item WSMan:localhostClientTrustedHosts -Value SERVER01 -Concatenate

But running this on the client gives:

Set-Item : The client cannot connect to the destination specified in the request. Verify that the service on the
destination is running and is accepting requests. Consult the logs and documentation for the WS-Management service
running on the destination, most commonly IIS or WinRM. If the destination is the WinRM service, run the following
command on the destination to analyze and configure the WinRM service: "winrm quickconfig".
At line:1 char:1
+ Set-Item WSMan:localhostClientTrustedHosts -Value SERVER01 -Conc ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Set-Item], InvalidOperationException
    + FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.PowerShell.Commands.SetItemCommand

So let’s check WinRM on the server:

winrm e winrm/config/listener

Outputs:

Listener
    Address = *
    Transport = HTTP
    Port = 5985
    Hostname
    Enabled = true
    URLPrefix = wsman
    CertificateThumbprint
    ListeningOn = 127.0.0.1, 169.254.36.241, 169.254.55.69, 169.254.84.105, 192.168.2.101, ::1, 2001:0:9d38:6abd:10ac:1878:3f57:fd9a, fe80::5efe:192.168.2.101%4, fe80::10ac:1878:3f57:fd9a%13, fe80::588e:b748:2bd:24f1%15, fe80::7120:37fa:11f9:3745%14, fe80::8409:52cd:a9fa:5469%3, fe80::a45e:493a:f66c:d28d%7

So WinRM is listening. I am able to TelNet this port from the client computer. But still PowerShell complains it can’t connect. Maybe WinRM in Windows 10 only supports HTTPS? Alright, so let’s setup WinRM HTTPS on the server:

winrm quickconfig -transport:https

WinRM complains it needs a certificate. So let’s create a certificate:

Created a ROOT CA using:

makecert -pe -n "CN=My Company Root Certification Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "My Company Root Certification Authority.cer"

Installed the ROOT CA in the Trusted Root Certification Authorities on the SERVER and the CLIENT.

Also created a certificate issued from the previously created CA using:

makecert -pe -n "CN=SERVER01" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "My Company Root Certification Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 SERVER01.cer

Installed the certificate in the personnal store on the SERVER and the CLIENT.

Still, WinRM complains it cannot find an appropriate certificate. So let’s add the listener manually:

winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname="SERVER01";CertificateThumbprint="ac87de6d91ae8ff5e2fd66cd02738fc2b6a6ae53"}

WinRM complains that the «Enhanced Key Usage (EKU) field of the certificate is not set to «Server Authentication».«

When I check the certificate in MMC, IT IS SET TO SERVER AUTHENTICATION!!!

Now I’m out of ideas and I just want to bang my head against a brick wall…

Any help is greatly appreciated!

Возникла необходимость удаленного управления сервером с запущенной ролью Hyper-V с компьютера под управлением Window 10 (личный ноутбук), который не состоит в домене. Чтобы такая схема заработала, нужно выполнить следующие настройки на стороне сервер-гипервизора и клиента.

Содержание:

• Настройка сервера Hyper-V
• Настройка клиента Windows 10 для подключения к серверу Hyper-V
• Удаленное подключение из Windows 10 к Hyper-V

Настройка сервера Hyper-V

На сервере Hyper-V (Windows Server 2016) нужно включить удаленное управление PowerShell Remoting и открыть соответствующие порты на файерволе. Включаем службу WinRM командой

Enable-PSRemoting

Теперь нужно разрешить подключение со всех клиентов (из публичных сетей в той же самой локальной подсети) и разрешить передавать и получать CredSSP:

Enable-PSRemoting -SkipNetworkProfileCheck -Force

Enable-WSManCredSSP -Role Server

Включим правило межсетевого экрана WinRM-HTTP-In-TCP-Public.

Set-NetFirewallRule -Name "WinRM-HTTP-In-TCP-Public" -RemoteAddress Any

Проверьте удаленную доступность порта WinRM (TCP 5985) на сервере

Test-NetConnection -ComputerName target_name -Port 5985

Настройка клиента Windows 10 для подключения к серверу Hyper-V

В первую очередь на компьютере с Windows 10 нужно установить консоль управления Hyper-V. Для этого в панели управления в разделе программ нужно нажать кнопку Turn windows features on or off и в разделе Hyper-V-> Hyper-V Management Tools -> выбрать Hyper-V GUI Management Tools.

Проверьте, что тип сетевого подключения у вас установлен на Private.

Откройте консоль PowerShell с правами администратора и выполните следующие команды:

Enable-PSRemoting
Set-Item WSMan:localhostClientTrustedHosts -Value "Hyper-V-FQDN"
Enable-WSManCredSSP -Role client -DelegateComputer "Hyper-V-FQDN"

Тем самым мы добавили наш сервер в список доверенных и разрешили аутентификацию CredSSP.

Теперь в редакторе локальной групповой политики (gpedit) нужно включить NTLM аутентификацию на недоменных компьютерах. Перейдите в раздел Computer Configuration > Administrative Template > System > Credentials Delegation и включите политику Allow delegating fresh credentials with NTLM-only server authentication, добавьте в нее строку  wsman/Hyper-V-FQDN.

Удаленное подключение из Windows 10 к Hyper-V

На компьютере Windows 10 откройте консоль Hyper-V Manager, щелкните ПКМ по “Hyper-V Manager” и выберите Connect to Server… Введите имя сервера и отметьте галку Connect as another user и укажите имя пользователя с правами на сервере Hyper-V.

После этого, консоль должна отобразить список ВМ, запущенных на хосте Hyper-V.