How to enable winrm via group policy

WinRM configuration and commands

For the WinRM command-line tool and scripts to run, and perform data operations effectively, Windows Remote Management (WinRM) must be installed and configured. However, the good news is that WinRM is automatically installed with all currently-supported versions of the Windows operating system, including IPMI (Intelligent Platform Management Interface) WMI (Windows Management Instrumentation) provider components.

By default, WinRM is enabled on Windows Server OS since Windows Server 2012, but not on Windows 10 operating system. This means that you need to enable it on Windows 10 machines. To enable WinRM on a Windows 10 machine, open PowerShell and run the following cmdlet:

Enable-PSRemoting -force

If you have a single Windows 10 machine that is not part of an Active Directory domain network, you may need to add the machine you are going to connect from to the trusted host of the Windows 10 machine. The reason we need to add trusted hosts is to be able to connect to a Windows machine using WinRM.

However, in situations where you have 100+ Windows 10 machines in an Active Directory domain network, you may need to use a Group Policy (GPO) to get it working with minimal effort. To use a GPO, create a new one or edit an existing one and modify the following settings and set WinRM to “Enabled”:

Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Remote Management (WinRM) > WinRM Service > Allow remote server management through WinRM

Remember to apply the GPO to the Organizational Units (OU) that have all your Windows 10 machines. Within a few minutes after applying the GPO to the OU, all your hosts will get the policy update. In this case, there is no need to modify the trusted hosts’ list.

The table below is a collection of some WinRM commands you can use to execute remote operations. Please note that these commands work best when you are on an Active Directory domain network. For workgroup machines, the WinRM service may require additional configuration such as modifying the trusted hosts’ list.

Description	Command	Remark
Locate listeners and the addresses	winrm e winrm/config/listener
Check the state of configuration settings	winrm get winrm/config
Quickly configure the WS-Man service	winrm QuickConfig	Run from an Elevated Command prompt
Quickly delete the WS-Man listener	winrm invoke Restore winrm/Config @{}	Run from an Elevated Command prompt
Display your machine’s basic hardware info	winrm enumerate wmicimv2/Win32_ComputerSystem	Run from an Elevated Command prompt
Display your operating system properties	winrm get wmicimv2/Win32_OperatingSystem	Run from an Elevated Command prompt
Output your OS info in XML	winrm get wmicimv2/Win32_OperatingSystem -format:pretty	Run from an Elevated Command prompt
Test WS-Man access to a remote machine	winrm id -remote:	Run from an Elevated Command prompt
Grab a remote machine’s WS-Man config	winrm get winrm/Config -r:	Run from an Elevated Command prompt
Grab a remote machine’s CPU load	winrm g wmicimv2/Win32_Processor?DeviceID=CPU0 -fragment:LoadPercentage -r:	Run from an Elevated Command prompt
Grab a remote machine’s free memory	winrm g wmicimv2/Win32_OperatingSystem -fragment:FreePhysicalMemory -r:	Run from an Elevated Command prompt
Stop a service on a remote machine	winrm invoke stopservice wmicimv2/Win32_Service?name=w32time -r:	Run from an Elevated Command prompt
Start a service on a remote machine	winrm invoke startservice wmicimv2/Win32_Service?name=w32time -r:	Run from an Elevated Command prompt
Reboot a remote machine	winrm invoke reboot wmicimv2/Win32_OperatingSystem -r:	Run from an Elevated Command prompt
Run a command on a remote machine (this uses winrS, not winrM)	winrs -r: ipconfig /all	Run from an Elevated Command prompt
Use PowerShell to grab the WS-Man Win32_OperatingSystem XML output	$osInfo = winrm get wmicimv2/Win32_OperatingSystem /format:pretty	Run from PowerShell
Display the OS version property	$osInfo.Win32_OperatingSystem.Version	Run from PowerShell
Display the last boot time	$osInfo.Win32_OperatingSystem.LastBootupTime.DateTime	Run from PowerShell
Put free memory metric into an XML variable	$freemem = cmd /c “winrm get wmicimv2/Win32_OperatingSystem -fragment:FreePhysicalMemory -f:pretty -r:”	Run from PowerShell
Display the free memory value	$freemem.XMLFragment.FreePhysicalMemory	Run from PowerShell

Table 2.0 | Common WinRM commands and description

Включение или отключение параметров проверки подлинности

Параметр проверки подлинности по умолчанию при установке системы — Kerberos. Дополнительные сведения см. в разделе «Установка и настройка» для Windows удаленного управления.

Если для скрипта или приложения требуется определенный метод проверки подлинности, который не включен, необходимо изменить конфигурацию, чтобы включить этот тип проверки подлинности. Это изменение можно внести с помощью программы командной строки Winrm или с помощью групповая политика для объекта групповая политика Windows удаленного управления. Вы также можете отключить определенные методы проверки подлинности.

Включение или отключение проверки подлинности с помощью средства Winrm

Заметки об установке драйвера IPMI и поставщика

Драйвер может не обнаружить наличие драйверов IPMI, которые не от корпорации Майкрософт. Если драйвер не запускается, его может потребоваться отключить.

Если ресурсы отображаются в BIOS системы, ACPI (Plug and Play) обнаруживает оборудование BMC и автоматически устанавливает драйвер IPMI. Plug and Play поддержка может присутствовать не во всех контроллерах BBM. Если контроллер BMC обнаружен Plug and Play, то перед установкой компонента управления оборудованием в диспетчер устройств появится неизвестное устройство. После установки драйвера в диспетчер устройств появится новый компонент, Microsoft ACPI Generic IPMI-совместимое устройство.

Если ваша система не обнаруживает контроллер BMC автоматически и не устанавливает драйвер, но во время установки обнаружен BMC, создайте устройство BMC. Чтобы создать устройство, введите в командной строке следующую команду:

После выполнения этой команды устройство IPMI создается и отображается в диспетчер устройств. При удалении компонента «Управление оборудованием» устройство удаляется.

Дополнительные сведения см. в статье Общие сведения об управлении оборудованием.

Поставщик IPMI помещает классы оборудования в корневоепространство имен WMI. Дополнительные сведения о классах оборудования см. в разделе Поставщик IPMI. Дополнительные сведения о пространствах имен WMI см. в разделе Архитектура WMI.

Configuring WinRM via Group Policy

You can automatically enable and configure WinRM on domain computers using Windows GPO.

Open the Group Policy Management Console (), select an Active Directory container (Organizational Unit) with the computers you want to enable WinRM on, and create a new GPO: corpEnableWinRM;
Open the policy to edit it;
Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> System Services. Find the Windows Remote Service (WS-Management) service and enable automatic startup for it;
Then go to Computer Policies -> Preferences -> Control Panel Settings -> Services. Select New -> Service. Enter the service name WinRM, and select the Restart the Service action on the Recovery tab;
Go to Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service. Enable Allow remote server management through WinRM. In the Ipv4/IPv6 filter box, you can specify IP addresses or subnetworks, on which WinRM connections must be listened to. If you want to allow WinRM connections on all IP addresses, leave * here;
Create Windows Defender Firewall rules allowing WinRM connections on the default ports TCP/5985 and TCP/5986. Go to Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Windows Firewall with Advanced Security -> Windows Firewall with Advanced Security -> Inbound Rules. Select Windows Remote Management predefined rule;
Learn more about how to configure Windows Defender rules and open ports using GPO.
Go to Computer Configuration -> Policies -> Windows Components -> Windows Remote Shell and enable Allow Remote Shell Access.

Update GPO settings on your clients and make sure that WinRM has been configured automatically. You can use the gpresult tool to troubleshoot Group Policy settings on client computers.

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

Для управления удаленным сервером с помощью Диспетчер серверов, выполните следующие действия.

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

Запустите программу Диспетчер серверов. Чтобы открыть компонент «Управление сервером», нажмите Пуск, Администрирование, а затем Управление сервером.
В древовидном представлении щелкните правой кнопкой мыши узел Диспетчер сервера и выберите команду Подключиться к другому компьютеру.

В диалоговом окне Подключение к другому компьютеру введите имя или IP-адрес другого компьютера, работающего под управлением Windows Server 2008 R2, в поле Другой компьютер или найдите другой сервер в сети при помощи обзора. Нажмите кнопку ОК.
В поле Другой компьютер можно указать NetBIOS-имя, полное доменное имя либо адрес IPv4 или IPv6. Если номер порта не указан, то используется номер порта по умолчанию. Далее приведены примеры форматов, которые можно указать в поле Другой компьютер.

ComputerName

ComputerName:PortNumber

IP-адрес: n.n.n.n

IPv6-адрес:
IPv4-адрес с номером порта: n.n.n.n:PortNumber

IPv6-адрес с номером порта: :PortNumber

Примечание

Если администратор изменил на компьютере номер порта по умолчанию, то нужно открыть нестандартный порт в брандмауэре Windows, чтобы разрешить для этого порта принимать входящие подключения. Порт 5985 открыт по умолчанию, если служба удаленного управления Windows настроена так, как описано в разделе в этой главе. Нестандартные порты остаются заблокированными, пока не будут открыты. Дополнительные сведения о том, как разблокировать порт в брандмауэре Windows, см. в справке по брандмауэру Windows

Для получения дополнительных сведений о настройке службы удаленного управления Windows в сеансе командной строки введите winrm help и нажмите клавишу ВВОД.
Обратите внимание, что после подключения к удаленному компьютеру имя вашего компьютера изменилось в консоли Диспетчер серверов. Имя компьютера в узле Диспетчер серверов древовидного представления, значение поля Полное имя компьютера в области Сводка сервера Диспетчер серверов и имя компьютера в заголовке консоли меняются на имя удаленного компьютера, к которому вы подключились

Поскольку Диспетчер серверов разрешает IP-адреса в полные доменные имена, то при подключении к удаленному компьютеру с использованием IP-адреса консоль Диспетчер серверов отображает полное доменное имя удаленного компьютера.

Примечание

При подключении к компьютеру в другом домене с использованием IP-адреса возможен сбой удаленного подключения из-за ограничений DNS-сервера, которые могут привести к ошибке разрешения IP-адреса в имя узла. В этом случае попробуйте подключиться, указав полное доменное имя.

Чтобы выполнить командлет Get-WindowsFeature диспетчера сервера на удаленном компьютере в сеансе Windows PowerShell, выполните следующие действия.

Откройте сеанс Windows PowerShell с повышенными правами пользователя. Для этого нажмите кнопку Пуск, последовательно выберите компоненты Все программы, Стандартные и Windows PowerShell, затем щелкните правой кнопкой мыши ярлык Windows PowerShell и выберите команду Запуск от имени администратора.
Введите следующую команду (где ComputerName — имя удаленного компьютера, работающего под управлением Windows Server 2008 R2, а UserName — имя пользователя, являющегося членом группы Администраторы на удаленном компьютере), затем нажмите клавишу ВВОД:

Enter-PSSession <имя_компьютера> -credential <имя_пользователя>
Будет запрошен пароль, который нужно ввести в защищенном диалоговом окне. Введите пароль и нажмите клавишу ВВОД.
Для загрузки оснастки Диспетчер серверов в сеансе Windows PowerShell введите следующую команду и нажмите клавишу ВВОД:

Import-Module ServerManager
Введите приведенную ниже команду и нажмите клавишу ВВОД:

Get-WindowsFeature
После того, как результаты выполнения командлета Get-WindowsFeature будут показаны в сеансе Windows PowerShell, введите следующую команду, чтобы закрыть сеанс Windows PowerShell, и нажмите клавишу ВВОД:

Exit-PSSession

Настройка

Поставщик услуг безопасности CredSSP является частью операционной системы и входит в состав Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2. Кроме того, он может быть установлен в качестве отдельного обновления на Windows XP SP3. Этот процесс подробно описан в статье «Description of the Credential Security Support Provider (CredSSP) in Windows XP Service Pack 3 ». Для установки и включения CredSSP на Windows XP SP3 необходимо выполнить следующие действия.

1. Запустить редактор реестра regedit и перейти в ветку: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa.

2. Добавить значение tspkg
к ключу Security
Packages

3. Перейти
в
ветку
реестра
: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders
.

4. Добавить значение credssp.dll
к ключу SecurityProviders
(остальные значения этого ключа следует оставить неизменными).

После того как CredSSP включен, необходимо настроить его использование с помощью групповых политик или соответствующих им ключей реестра. Для настройки SSO на клиентских компьютерах используются групповые политики из раздела:

Computer Configuration\Administrative Templates\System\Credentials Delegation
.

В русскоязычных версиях операционных систем это выглядит следующим образом (рис. 1).

Рис. 1. Управление передачей учетных данных при помощи групповых политик

Для использования SSO следует включить политику:

Разрешить передачу учетных данных, установленных по умолчанию
.

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

В окне редактирования политики (рис. 2) нажать кнопку «Показать
»

Рис. 2. Окно редактирования групповой политики

Добавить список терминальных серверов (рис. 3).

Рис. 3. Добавление терминального сервера для прозрачной авторизации

Строка добавления сервера имеет следующий формат:

TERMSRV/имя_сервера
.

Также можно задать сервера по маске домена. В этом случае строка приобретает вид:

TERMSRV/*.имя_домена
.

Если нет возможности использовать групповые политики, соответствующие настройки можно установить при помощи редактора реестра. Например, для настройки Windows XP Sp3 можно использовать следующий файл реестра:

Windows Registry Editor Version 5.00

«Security Packages»=hex (7):6b,00,65,00,72,00,62,00,65,00,72,00,6f,00,73,00,00,\

00,6d,00,73,00,76,00,31,00,5f,00,30,00,00,00,73,00,63,00,68,00,61,00,6e,00,\

6e,00,65,00,6c,00,00,00,77,00,64,00,69,00,67,00,65,00,73,00,74,00,00,00,74,\

00,73,00,70,00,6b,00,67,00,00,00,00,00

«SecurityProviders»=»msapsspc.dll, schannel.dll, digest.dll, msnsspc.dll, credssp.dll»

«AllowDefaultCredentials»=dword:00000001

«ConcatenateDefaults_AllowDefault»=dword:00000001

«1»=»termsrv/*.mydomain.com»

Здесь вместо mydomain.com следует подставить имя домена. В этом случае при подключении к терминальным серверам по полному доменному имени (например, termserver1.mydomain.com) будет использоваться прозрачная авторизация.

Для использования технологии Single Sign-On на терминальном сервере необходимо выполнить следующие действия.

Открыть консоль настройки служб терминалов (tsconfig.msc
).
В разделе подключения перейти в свойства RDP-Tcp
.
На вкладке «Общие
» установить уровень безопасности «Согласование
» или «SSL (TLS 1.0)
» (рис. 4).

Рис. 4. Настройка уровня безопасности на терминальном сервере

На этом настройку клиентской и серверной части можно считать законченной.

Blog of Khlebalin Dmitriy

Terminal Server на Windows 2016. RemoteApp (часть 4).

В целом, терминальный сервер настроен, на нем благополучно крутится 1С и работают пользователи.

Но настроить RemoteApp пришлось не просто так. У нас на сервере крутятся 2 платформы: 1с83 и 1с82. В 1с83 проблем нет, а вот в 1с82, люди жалуются на невозможность изменения масштаба в 1с и мелкий шрифт в ней же. Именно по этому было принято решение прокинуть 1с через RemoteApp.

Еще раз коротко о ролях терминального сервера:

1. Посредник подключения к удаленному рабочему столу. Он занимается подключением клиентского устройства к удаленным приложениям «RemoteApp», а также рабочим столам на базе сеансов, либо к виртуальным рабочим столам, зависит от того на базе какой технологии мы RDS построили.

2. Роль, которая обеспечивает веб-доступ к удаленным рабочим столам. Ее задача – предоставление ресурсов через веб-браузер.

3. Узел сеансов удаленных рабочих столов – данная роль позволяет размещать на сервере удаленные приложения, или основанные на сеансах рабочие столы.

4. Узел виртуализации удаленных рабочих столов. На данном узле, это у нас сервер Hyper-V, на котором у нас разворачиваются все виртуальные машины, доступ к которым получат все пользователи, что использую технологию VDI.

5. Шлюз удаленных рабочих столов, это посредник между клиентами из внешней сети и коллекции сеансов во внутренней сети и приложений. Шлюз – это безопасность, сервис у нас абсолютно безопасный. И благодаря тому, что RDS в 2012/2016 и 2012R2/201 становится более гибким, проработаны абсолютно все недочеты, которые были раньше. Сейчас этот сервис легко реализуем для огромных, масштабных проектов, для больших корпораций. Раньше возникали некоторые вопросы.

Преимущества «RemoteApp» над обычным «Сервером терминалов» :

Пользователь не путается между удаленным рабочим столом и своим локальным.
Программа 1С запускается сразу при клике по ярлыку, и выглядит как локально установленная.
Пользователь не видит всего рабочего стола и работает лишь с теми программами, которые назначил администратор.
Безопасность выше, чем на обычном сервере терминалов.
Скорость передачи изображения с сервера, выше, чем в сравнении с обычным сервером терминалов. (Оптимизация за счет, передачи не всей картинки, а лишь нужной программы).

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

Далее публикуем сами приложения RemoteApp (Публикация удаленных приложений).

Выбираем необходимое нам приложение (в моем случае это соответственно 1С):

Вроде благополучно все опубликовалось.

Теперь со своего компьютера набираю в браузере: https://your_server_ip/RDWeb/Pages/ru-RU/login.aspx (ругнется на сертификат, так как его нет, но это не страшно)

Далее предлагается локально скачать файлик:

Здесь сразу запускается 1С.

Все достаточно быстро и без проблем. Но, к сожалению, нашу текущую проблему с масштабированием 1С82 RemoteApp не решает. Но все работает.

На этом настройка закончена.

Всем хорошей работы.

P.S.

Думали опубликовать еще 1с82 через IIS WEB, но с платформой 1с82 это оказалось достаточно проблематично.

По публикации платформы 1с83 почитать можно здесь:

Обновление от 01.10.2020.

Ранее никогда не сталкивался с развертыванием терминального сервера без домена. И тут столкнулся, оказалось, что поставить его можно, а вот управлять через GUI не получится, только через PS.

Или вариант управлять через GUI с другого компа, описан здесь.

Теневое подключение RDS Shadow из PowerShell

Воспользоваться функционалом теневого подключения к сессии пользователя через теневое подключение Remote Desktop Services можно и из Powershell.

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

Get-RDUserSession | ft Username, UnifiedSessionId, SessionState, HostServer, ApplicationType -GroupBy Sessionstate

1	Get-RDUserSession\|ft Username,UnifiedSessionId,SessionState,HostServer,ApplicationType-GroupBy Sessionstate

На данном сервере мы обнаружили три активных RDP сессии пользователей. Чтобы подключиться к сессии пользователя с ID сессии 3, выполните команду:

Mstsc /shadow:3 /control /noConsentPrompt

1	Mstsc/shadow3/control/noConsentPrompt

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

quser
Или
qwinsta

1
2
3

quser
Или
qwinsta

На экране отобразится список RDP сессий, их ID и статус: активная сессия (Active) или отключенная (Disconnected).

Для получения списка сессий на удалённом сервере выполните команду:

query session /server:servername

1	query session/serverservername

Чтобы подключиться к сессии пользователя на удаленном сервере, используйте команду:

Mstsc /v:rdsh2:3389 /shadow:3 /control

1	Mstsc/vrdsh23389/shadow3/control

Для более удобного теневого подключения к RDP сессиям пользователей можно использовать следующий скрипт. Скрипт предложит ввести имя удаленного компьютера и выведет список всех пользователей с активными RDP сеансами. Вам нужно будет указать ID сеанса, к которому нужно подключится через Shadow сессию:

shadow.bat

@echo off
set /P rcomp=»Enter name or IP of a Remote PC: »
query session /server:%rcomp%
set /P rid=»Enter RDP user ID: »
start mstsc /shadow:%rid% /v:%rcomp% /control

1
2
3
4
5

@echo off

set/Prcomp=»Enter name or IP of a Remote PC: «

query session/server%rcomp%

set/Prid=»Enter RDP user ID: «

start mstsc/shadow%rid%/v%rcomp%/control

Можно поместить данный файл в каталог %Windir%\System32. В результате для теневого подключения к пользователю достаточно выполнить команду shadow.

Для подключения к консольной сессии можно использовать такой скрипт:

@echo off
set /P rcomp=»Enter name or IP of a Remote PC: »
for /f «tokens=3 delims= » %%G in (‘query session console /server:%rcomp%’) do set rid=%%G
start mstsc /shadow:%rid% /v:%rcomp% /control

1
2
3
4

@echo off

set/Prcomp=»Enter name or IP of a Remote PC: «

for/f»tokens=3 delims= «%%Gin(‘query session console /server:%rcomp%’)doset rid=%%G

start mstsc/shadow%rid%/v%rcomp%/control

script rdp-view.bat

@echo off
query session
set /P rid=»Enter RDP user ID: »
start mstsc /shadow:%rid% /noConsentPrompt

1
2
3
4

@echo off

query session

set/Prid=»Enter RDP user ID»

start mstsc/shadow%rid%/noConsentPrompt

script rdp-control.bat

@echo off
query session
set /P rid=»Enter RDP user ID: »
start mstsc /shadow:%rid% /control /noConsentPrompt

1
2
3
4

@echo off

query session

set/Prid=»Enter RDP user ID»

start mstsc/shadow%rid%/control/noConsentPrompt

script rdp-view.ps1

Write-Host »
»
quser
$user = Read-Host -Prompt »
Enter ID»
mstsc /shadow:$user /noConsentPrompt

1
2
3
4
5
6

Write-Host»

quser

$user=Read-Host-Prompt»

Enter ID»

mstsc/shadow$user/noConsentPrompt

script rdp-control.ps1

Write-Host »
»
quser
$user = Read-Host -Prompt »
Enter ID»
mstsc /shadow:$user /control /noConsentPrompt

1
2
3
4
5
6

Write-Host»

quser

$user=Read-Host-Prompt»

Enter ID»

mstsc/shadow$user/control/noConsentPrompt

Как разрешить обычном пользователям использовать теневое подключение?

В рассмотренных выше примерах для использования теневого подключения к RDP сессиям пользователей необходимы права локального администратора на RDS сервере. Однако вы можете разрешить использовать теневое (shadow) подключение и для непривилегированных пользователей (не предоставляя им прав локального администратора на компьютере/сервере).

К примеру, вы хотите разрешить членам доменной группы AllowRDSShadow использовать теневое подключение к RDP сессиям. Выполните команду в cmd.exe с правами администратора:

wmic /namespace:\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE (TerminalName=’RDP-Tcp’) CALL AddAccount ‘corp\AllowRDSShadow’,2

1	wmic/namespace\\root\CIMV2\TerminalServices PATH Win32_TSPermissionsSetting WHERE(TerminalName=’RDP-Tcp’)CALL AddAccount’corp\AllowRDSShadow’,2

В январе 2018 года после установки обновления KB4056898 (патч Windows против Meltdown и Spectre) пользователи столкнулись, что в Windows Server 2012 R2 перестал работать теневой доступ. При попытке выполнить теневое подключение к чужой сессии появляется сообщение «Неопознанная ошибка» (в логах присутствует ошибка STATUS_BAD_IMPERSONATION_LEVEL ). Аналогичная проблема возникала и на RDS ферме на базе Windows Server 2016.

Для решения проблемы нужно установить отдельные обновления:

для Windows Server 2016 — KB4057142 (от 17 января 2018)
для Windows Server 2012 R2 — KB4057401 (от 17 января 2018)

Windows Remote Management

Windows Remote Management — это служба удаленного управления Windows. Под этим общим названием скрываются сразу два инструмента, которые позволяют пользователю удаленно управлять компьютером. В отличие от двух предыдущих инструментов Windows(Удаленный рабочий стол и Удаленный помощник Windows), которые позволяли видеть происходящее на удаленном компьютере на своем экране и манипулировать удаленным компьютером с помощью мыши и клавиатуры, данные два инструмента кардинально отличаются от них. Инструменты, которые входят в службу Windows Remote Management, позволяют управлять компьютером одними командами. Эти команды выполняются либо в командной строке, либо в Windows Power Shell. Единственный отклик об управлении — ответ оболочки о выполнении команды. Вы во многом в слепую отправляете команды на удаленный компьютер и получаете односложные ответы о том, выполнена она или нет. Минимум удобств. Но для администрирования компьютеров это самое то.

Активация Windows Remote Management

Под Windows Remote Management скрываются две команды, которые позволяют выполнять команды на удаленном компьютере. Эти команды, как уже говорилось, принадлежат двум разным оболочкам: командная строка Windows и Windows Power Shell. Думаю, все знакомы с командной строкой Windows. Ну, а Power Shell это инструмент, который призван заменить устаревшую командную строку. С первого взгляда, эти инструменты очень похожи. Но на деле Power Shell стоит выше командной строки, которая не претерпевела серьезных изменений уже очень давно. Именно в связи с этим ему и приготовили замену.

Для возможности удаленного управления компьютером средствами Windows Remote Management, целевой компьютер необходимо должным образом настроить. Для этого на целевом компьютере необходимо выполнить команду(в окне командной строки Windows):

Данная команда включает и настраивает отложенный автоматический запуск службы Windows Remote Management(кстати, для работы со службами Windows можно так же использовать инструмент Службы), а так же настраивает соответствующие исключения для Брандмауэра Windows, которые необходимо для правильного функционирования этих инструментов.

Но выполнение данной команды недостаточно. Чтобы удаленные подключения стали возможными, компьютер, с которого будет вестись удаленное управление, должен стать доверенным для целевого компьютера. Дело облегчается, если оба этих компьютера находятся в одном домене — в таком случае, оба компьютера взаимодоверенные. Если же нет, то необходимо внести удаленный компьютер в список доверенных компьютеров, либо по его IP-адресу, либо по имени компьютера(что довольно серьезно осложняется в условиях Глобальной сети).

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

Удаленное управление с помощью Windows Remote Management

Ну и наконец-то пришло время познакомится с самими командами для удаленного управления. В среде командной строки такую возможность дает команда

а в среде Power Shell — команда

Синтаксис данных команд Вы можете увидеть в самих средах, если вызовите справку по данным командам. Я же приведу только общий вид таких команд:

icm имя_компьютера <любая команда> winrs -r: Имя_компьютера -u: имя_пользователя Любая_команда

Надеюсь, Вы разберетесь в том, что имя_компьютера, имя_пользователя и любая_команда должны быть заменены на соответствующие Вашему желанию переменные. И тут нужно учесть тот момент, что эта самая любая команда должна принадлежать той оболочке, в которой происходит удаленной управление.

WinRM architecture and components

The WinRM architecture consists of components on the client and server computers. The diagram in Figure 1.0 below shows the components on both the requesting client and responding server computers, and how they interact with each other, including the protocol that is used to communicate between them.

Figure 1.0 | Diagram showing WinRM architecture and component | credit: Microsoft

Table 1.0 below is a breakdown of the various WinRM components and where they reside.

Component	Description	Residence
WinRM application	WinRM command-line tool that uses the WinRM scripting API to make calls to request data or to execute methods	Client-side
WSMAuto.dll	The Automation layer that provides scripting support	Client and server-side
WsmCL.dl	API layer within the OS	Client and server-side
HTTP API	Provides support for HTTP and HTTPS transport	Client and server-side
WsmSvc.dll	WinRM listener service	Server-side
WsmProv.dll	Provider subsystem	Server-side
WsmRes.dll	Resource file	Server-side
WsmWmiPl.dll	WMI plug-in that allows you to obtain WMI data through WinRM	Server-side
IPMI driver and WMI IPMI provider	Supply any hardware data that is requested using the IPMI (Intelligent Platform Management Interface) classes	Server-side

Table 1.0 | WinRM components and description

WinRM configuration and commands

Включение или отключение параметров проверки подлинности

Заметки об установке драйвера IPMI и поставщика

Configuring WinRM via Group Policy

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

Настройка

Blog of Khlebalin Dmitriy

Terminal Server на Windows 2016. RemoteApp (часть 4).

Share this:

Теневое подключение RDS Shadow из PowerShell

Как разрешить обычном пользователям использовать теневое подключение?

Windows Remote Management

Активация Windows Remote Management

Удаленное управление с помощью Windows Remote Management

WinRM architecture and components

Похожие записи:

Похожие записи: