Как активировать Windows Remote Management с помощью групповой политики

В этой статье, я попытаюсь рассказать, каким образом можно централизованно активировать и настроить службу Windows Remote Management (WinRM) на всех целевых компьютерах с помощью групповой политики. Напомню, что Windows Remote Management – это специальный сервис, позволяющий администраторам получить возможность удаленного доступа и управления клиентскими и серверными ОС Windows (и, думаю, если вы ранее пользовались набором утилит Microsoft Sysinternals PSTools, то WRM должен вам понравиться).
Возьмем обычный ПК с Windows 7, который включен в домен, и на котором не активирована функция Windows Remote Management. В командной строке введем следующую команду:

, должно появиться следующее сообщение об ошибке, свидетельствующее о том, что WRM не установлен:
WSMan Fault. The client cannot connect to the destination specified in the request. Error number: — 2144108526 0x80338012

Если нужно настроить WinRM вручную на отдельной системе, достаточно набрать команду:

В том случае, если нужно настроить WinRM на группе компьютеров, то можно воспользоваться специальными параметрами групповой политики. Интересующая нас политика находится в разделе: Computer Configuration -> Policies -> Windows Components -> Windows Remote Management (WinRM) -> WinRM Service. Нужно активировать следующие параметры:
• Allow automatic configuration of listeners
• Allow Basic Authentication

В разделе IPv4 filter укажем *, что означает, что компьютер может принимать подключения (а значит и управляющие команды) откуда угодно, это значит что листенеры на компьютере будет принимать запросы на всех IP интерфейсах.

Затем в разделе Computer Configuration -> Policies -> Windows Components -> Windows Remote Shell активируем пункт:
• Allow Remote Shell Access

И, наконец, нужно задать тип запуска у службы Windows Remote Service в «Автоматический» (Automatically). Напомню, что управлять способом запуска служб можно из следующего раздела групповых политик: Computer Configuration -> Windows Settings -> Security Settings ->System Services.

После активации WinRM с помощью групповой политики, на клиентской системе проверим статус службы с помощью знакомой команды:

Удостоверимся, что тип запуска службы WinRM задан в автоматический . Хотя по факту тип запуска «автоматический с задержкой», т.к. по умолчанию для службы WinRM задана задержка запуска (параметр DelayedAutoStart=1 в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinRM ).

Теперь, после активации WinRM с помощью групповой политики, данной системой можно управлять удаленно с помощью команд WinRS. Следующая команда откроет командную строку, запущенную на удаленной системе:

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

Remote Desktop Services (Remote Desktop Services)

Purpose

Windows ServerВ 2012В R2, Windows ServerВ 2012, Windows ServerВ 2008В R2, or Windows ServerВ 2008 with Remote Desktop Services (formerly known as Terminal Services) allow a server to host multiple, simultaneous client sessions. Remote Desktop uses Remote Desktop Services technology to allow a single session to run remotely. A user can connect to a Remote Desktop Session Host (RDВ Session Host) server (formerly known as a terminal server) by using Remote Desktop Connection (RDC) client software. The Remote Desktop Web Connection extends Remote Desktop Services technology to the web.

This topic is for software developers. If you are looking for user information for Remote Desktop connections, See Remote Desktop Connection: frequently asked questions.

Where applicable

A Remote Desktop Connection (RDC) client can exist in a variety of forms. Thin-client hardware devices that run an embedded Windows-based operating system can run the RDC client software to connect to an RDВ Session Host server. Windows-, Macintosh-, or UNIX-based computers can run RDC client software to connect to an RDВ Session Host server to display Windows-based applications. This combination of RDC clients provides access to Windows-based applications from virtually any operating system.

Developer audience

Developers who use Remote Desktop Services should be familiar with the C and C++ programming languages and the Windows-based programming environment. Familiarity with client/server architecture is required. The Remote Desktop Web Connection includes scriptable interfaces to create and deploy scriptable virtual channels within Remote Desktop Services web applications.

Run-time requirements

Applications that use Remote Desktop Services require Windows ServerВ 2012В R2, WindowsВ 8.1, Windows ServerВ 2012, WindowsВ 8, Windows ServerВ 2008В R2, WindowsВ 7, Windows ServerВ 2008, or WindowsВ Vista. To use Remote Desktop Web Connection functionality, the Remote Desktop Services client application requires Internet Explorer and a connection to the World Wide Web. For information about run-time requirements for a particular programming element, see the Requirements section of the reference page for that element.

In this section

Describes how to use the Remote Desktop ActiveX control.

You use the Remote Desktop Protocol Provider API to create a protocol to provide communication between the Remote Desktop Services service and multiple clients.

Virtual channels are software extensions that can be used to add functional enhancements to a Remote Desktop Services application.

The RemoteFX Media Redirection API is used in a Remote Desktop session to identify areas of the server that are displaying fast changing content, such as video. This content can then be video encoded and sent to the client in encoded format.

Describes how to use the Remote Desktop Connection Broker client API.

The personal desktop task agent API is used to handle scheduled updates to a personal virtual desktop.

Remote Desktop Services (formerly known as Terminal Services) provides functionality similar to a terminal-based, centralized host, or mainframe, environment in which multiple terminals connect to a host computer.

The Remote Desktop Management Services (RDMS) Provider manages virtual desktop infrastructure (VDI) environments.

Documentation of property methods that you can use to examine and configure Remote Desktop Services user properties. Remote Desktop Services functions, structures, and Remote Desktop Web Connection scriptable interfaces are also documented.

A list of the Remote Desktop Services shortcut keys.

The Remote Desktop Services WMI provider provides programmatic access to the information and settings that are exposed by the Remote Desktop Services Configuration/Connections Microsoft Management Console (MMC) snap-in.

How to program in the Remote Desktop Services environment and how to extend Remote Desktop Services (formerly known as Terminal Services) technology to the web by using Remote Desktop Web Connection.

Windows Remote Management на службе системного администратора.

Я опишу процесс, каким образом можно централизованно активировать и настроить службу Windows Remote Management (WinRM) на всех целевых компьютерах с помощью Group Security Policy. Windows Remote Management – это специальный сервис, позволяющий администраторам получить возможность удаленного доступа и управления клиентскими и серверными ОС Windows.

Возьмем обычный ПК с Windows 7, который включен в домен, и на котором не активирована функция Windows Remote Management. В командной строке введем следующую команду:

Запустим командную строку с правами администратора.

WinRM enumerate winrm/config/listener

, должно появиться следующее сообщение об ошибке, свидетельствующее о том, что WRM не установлен:

WSMan Fault. The client cannot connect to the destination specified in the request. Error number: – 2144108526 0?80338012

Если нужно настроить WinRM вручную на отдельной системе, достаточно набрать команду:

winrm quickconfig

Это я рассмотрел вариант установки на единичную рабочую станцию.

В том случае, если нужно настроить WinRM на группе компьютеров, то можно воспользоваться специальными параметрами групповой политики. Создадим групповую политику на контейнер где располагаются рабочие станции. Конфигурация компьютера — Политики — Административные шаблоны -> Компоненты Windows – Удаленное управление Windows . Активируем следующие параметры:

• Клиент службы удаленного управления Windows.

• Служба удаленного управления Windows

В разделе IPv4 filter укажем *, что означает, что компьютер может принимать подключения (а значит и управляющие команды) откуда угодно.

Далее в разделе Конфигурация компьютера – Политики — Административные шаблоны – Компоненты Windows – Удаленная оболочка Windows

Разрешить доступ к удаленной оболочке – Включена

Управлять способом запуска служб можно из следующего раздела групповых политик: Конфигурация компьютера – Политики — Конфигурация Windows — Параметры безопасности — Системные службы.

Открыть службу «Служба удаленного управления Windows (WM-Management) и произвести настройки ниже, см. скриншот.

Все готово. Перезагружаем рабочую станцию и после активации WinRM с помощью групповой политики, на клиентской системе проверим статус службы с помощью знакомой команды:

WinRM enumerate winrm/config/listener

Удостоверимся, что тип запуска службы WinRM задан в автоматический . Хотя по факту тип запуска «автоматический с задержкой», т.к. по умолчанию для службы WinRM задана задержка запуска (параметр DelayedAutoStart=1 в ветке HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WinRM ).

После применения групповой политики, данной системой можно управлять удаленно с помощью команд WinRS. Следующая команда откроет командную строку, запущенную на удаленной системе:

winrs –r: cmd

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

В моем случаем тестовая машина называется alektest4

Поддерживаемые конфигурации для служб удаленных рабочих столов Supported configurations for Remote Desktop Services

Область применения. Windows Server 2016, Windows Server 2019 Applies To: Windows Server 2016, Windows Server 2019

Когда речь идет о поддерживаемых конфигурациях для сред служб удаленных рабочих столов, наибольшую озабоченность вызывает взаимодействие версий. When it comes to supported configurations for Remote Desktop Services environments, the largest concern tends to be version interoperability. Большинство сред включают несколько версий Windows Server — например, у вас может быть существующее развертывание Windows Server 2012 R2 RDS, но вы хотите обновить его до Windows Server 2016, чтобы воспользоваться преимуществами новых функций (таких как поддержка OpenGL\OpenCL, дискретное назначение устройств или локальные дисковые пространства). Most environments include multiple versions of Windows Server — for example, you may have an existing Windows Server 2012 R2 RDS deployment but want to upgrade to Windows Server 2016 to take advantage of the new features (like support for OpenGL\OpenCL, Discrete Device Assignment, or Storage Spaces Direct). Тогда возникает вопрос, какие компоненты RDS могут работать с разными версиями и какие должны быть одинаковыми? The question then becomes, which RDS components can work with different versions and which need to be the same?

Исходя из этого, ниже перечислены основные рекомендации по поддерживаемым конфигурациям служб удаленных рабочих столов в Windows Server. So with that in mind, here are basic guidelines for supported configurations of Remote Desktop Services in Windows Server.

Рекомендации Best practices

Используйте Windows Server 2019 для инфраструктуры удаленного рабочего стола — веб-доступа, шлюза, посредника подключений и сервера лицензирования. Use Windows Server 2019 for your Remote Desktop infrastructure (the Web Access, Gateway, Connection Broker, and license server). Windows Server 2019 обеспечивает обратную совместимость с этими компонентами. Это означает, что узел сеансов удаленного рабочего стола Windows Server 2016 или Windows Server 2012 R2 может подключаться к RDCB 2019, но не наоборот. Windows Server 2019 is backward-compatible with these components, which means a Windows Server 2016 or Windows Server 2012 R2 RD Session Host can connect to a 2019 RD Connection Broker, but not the other way around.

Для узлов сеансов удаленных рабочих столов — все узлы сеансов в коллекции должны находиться на одном уровне, но вы можете иметь несколько коллекций. For RD Session Hosts — all Session Hosts in a collection need to be at the same level, but you can have multiple collections. У вас может быть коллекция с узлами сеансов Windows Server 2016 и коллекция с узлами сеансов Windows Server 2019. You can have a collection with Windows Server 2016 Session Hosts and one with Windows Server 2019 Session Hosts.

Если вы обновляете свой узел сеансов удаленных рабочих столов до Windows Server 2019, также обновите сервер лицензирования. If you upgrade your RD Session Host to Windows Server 2019, also upgrade the license server. Помните, что сервер лицензирования версии 2019 может обрабатывать клиентские лицензии всех предыдущих версий Windows Server, вплоть до Windows Server 2003. Remember that a 2019 license server can process CALs from all previous versions of Windows Server, down to Windows Server 2003.

Следуйте порядку обновления, рекомендованному в разделе Обновление среды служб удаленных рабочих столов. Follow the upgrade order recommended in Upgrading your Remote Desktop Services environment.

Если вы создаете высокодоступную среду, все ваши посредники подключений должны быть на одном уровне ОС. If you are creating a highly available environment, all of your Connection Brokers need to be at the same OS level.

Посредники подключений к удаленному рабочему столу RD Connection Brokers

Windows Server 2016 снимает ограничение на количество посредников подключений, которое может иметься в развертывании при использовании узлов сеансов удаленных рабочих столов (RDSH) и узлов виртуализации удаленных рабочих столов (RDVH), которые также работают под управлением Windows Server 2016. Windows Server 2016 removes the restriction for the number of Connection Brokers you can have in a deployment when using Remote Desktop Session Hosts (RDSH) and Remote Desktop Virtualization Hosts (RDVH) that also run Windows Server 2016. В следующей таблице показано, какие версии компонентов RDS работают с версиями посредника подключений R2 2016 и 2012 годов в высокодоступном развертывании с тремя или более посредниками подключений. The following table shows which versions of RDS components work with the 2016 and 2012 R2 versions of the Connection Broker in a highly available deployment with three or more Connection Brokers.

3+ посредников подключений к удаленному рабочему столу 3+ Connection Brokers in HA	Узлы сеансов удаленных рабочих столов (RDSH) или узлы виртуализации удаленных рабочих столов (RDVH) 2019 RDSH or RDVH 2019	Узлы сеансов удаленных рабочих столов (RDSH) или узлы виртуализации удаленных рабочих столов (RDVH) 2016 RDSH or RDVH 2016	Узлы сеансов удаленных рабочих столов (RDSH) или узлы виртуализации удаленных рабочих столов (RDVH) 2012 R2 RDSH or RDVH 2012 R2
Посредник подключений Windows Server 2019 Windows Server 2019 Connection Broker	Поддерживается Supported	Поддерживается Supported	Поддерживается Supported
Посредник подключений Windows Server 2016 Windows Server 2016 Connection Broker	Н/Д N/A	Поддерживается Supported	Поддерживается Supported
Посредник подключений Windows Server 2012 R2 Windows Server 2012 R2 Connection Broker	Н/Д N/A	Н/Д N/A	Не поддерживается Not Supported

Поддержка ускорения с помощью графического процессора (GPU) Support for graphics processing unit (GPU) acceleration

Службы удаленных рабочих столов поддерживают системы, оснащенные графическими процессорами. Remote Desktop Services support systems equipped with GPUs. Приложения, которым требуется GPU, можно использовать через удаленное подключение. Applications that require a GPU can be used over the remote connection. Кроме того, можно включить ускорение отрисовки и кодирования с помощью GPU, чтобы повысить производительность и улучшить масштабируемость приложений. Additionally, GPU-accelerated rendering and encoding can be enabled for improved app performance and scalability.

Узлы сеансов служб удаленных рабочих столов и односеансовые клиентские операционные системы поддерживают возможности физических или виртуальных графических процессоров, представляемых в операционной системе различными способами. Сюда входят размеры виртуальных машин, оптимизированных для Azure GPU; GPU, доступные для физического сервера RDSH; GPU, предоставляемые виртуальным машинам поддерживаемыми гипервизорами. Remote Desktop Services Session Hosts and single-session client operating systems can take advantage of the physical or virtual GPUs presented to the operating system in many ways, including the Azure GPU optimized virtual machine sizes, GPUs available to the physical RDSH server, and GPUs presented to the VMs by supported hypervisors.

Поставщики GPU могут применять отдельную схему лицензирования для сценариев узлов сеансов удаленных рабочих столов или ограничивать использование GPU в серверных ОС. Ознакомьтесь с требованиями выбранного поставщика. GPU vendors may have a separate licensing scheme for RDSH scenarios or restrict GPU use on the server OS, verify the requirements with your favorite vendor.

Графические процессоры, представленные гипервизорами или облачной платформой сторонних производителей, должны иметь драйверы с цифровой подписью WHQL, предоставляемые соответствующими поставщиками. GPUs presented by a non-Microsoft hypervisor or Cloud Platform must have drivers digitally-signed by WHQL and supplied by the GPU vendor.

Поддержка GPU узлами сеансов удаленных рабочих столов Remote Desktop Session Host support for GPUs

В следующей таблице приведены сценарии, в которых возможно применение различных версий узлов RDSH. The following table shows the scenarios supported by different versions of RDSH hosts.

Функция Feature	Windows Server 2008 R2 Windows Server 2008 R2	Windows Server 2012 R2 Windows Server 2012 R2	Windows Server 2016 Windows Server 2016	Windows Server 2019 Windows Server 2019
Использование аппаратного GPU для всех сеансов RDP Use of hardware GPU for all RDP sessions	Нет No	Да Yes	Да Yes	Да Yes
Аппаратное кодирование H.264/AVC (если поддерживается GPU) H.264/AVC hardware encoding (if suppported by the GPU)	Нет No	Нет No	Да Yes	Да Yes
Балансировка нагрузки между несколькими GPU, предоставленными операционной системе Load balancing between multiple GPUs presented to the OS	Нет No	Нет No	Нет No	Да Yes
Оптимизация кодирования H.264/AVC для минимизации использования пропускной способности H.264/AVC encoding optimizations for minimizing bandwidth usage	Нет No	Нет No	Нет No	Да Yes
Поддержка кодирования H.264/AVC для разрешения 4K H.264/AVC support for 4K resolution	Нет No	Нет No	Нет No	Да Yes

Поддержка VDI для GPU VDI support for GPUs

В следующей таблице описывается поддержка применения GPU в клиентской операционной системе. The following table shows support for GPU scenarios in the client OS.

Функция Feature	Windows 7 с пакетом обновления 1 (SP1) Windows 7 SP1	Windows 8.1 Windows 8.1	Windows 10 Windows 10
Использование аппаратного GPU для всех сеансов RDP Use of hardware GPU for all RDP sessions	Нет No	Да Yes	Да Yes
Аппаратное кодирование H.264/AVC (если поддерживается GPU) H.264/AVC hardware encoding (if suppported by the GPU)	Нет No	Нет No	Windows 10 (сборка 1703) и более поздние версии Windows 10 1703 and later
Балансировка нагрузки между несколькими GPU, предоставленными операционной системе Load balancing between multiple GPUs presented to the OS	Нет No	Нет No	Windows 10 (сборка 1803) и более поздние версии Windows 10 1803 and later
Оптимизация кодирования H.264/AVC для минимизации использования пропускной способности H.264/AVC encoding optimizations for minimizing bandwidth usage	Нет No	Нет No	Windows 10 (сборка 1803) и более поздние версии Windows 10 1803 and later
Поддержка кодирования H.264/AVC для разрешения 4K H.264/AVC support for 4K resolution	Нет No	Нет No	Windows 10 (сборка 1803) и более поздние версии Windows 10 1803 and later

Поддержка 3D-видеоадаптера RemoteFX (vGPU) RemoteFX 3D Video Adapter (vGPU) support

Из соображений безопасности процессор RemoteFX vGPU по умолчанию отключен для всех версий Windows, начиная с обновления для системы безопасности за 14 июля 2020 г. Because of security concerns, RemoteFX vGPU is disabled by default on all versions of Windows starting with the July 14, 2020 Security Update. См. KB 4570006. To learn more, see KB 4570006.

Службы удаленных рабочих столов поддерживают процессоры vGPU RemoteFX, когда виртуальная машина работает в качестве гостевой виртуальной машины Hyper-V в Windows Server 2012 R2 или Windows Server 2016. Remote Desktop Services supports RemoteFX vGPUs when VM is running as a Hyper-V guest on Windows Server 2012 R2 or Windows Server 2016. В следующих гостевых операционных системах поддерживается vGPU RemoteFX: The following guest operating systems have RemoteFX vGPU support:

• Windows 7 с пакетом обновления 1 (SP1) Windows 7 SP1
• Windows 8.1 Windows 8.1
• Windows 10 (сборка 1703) или более поздней версии Windows 10 1703 or later
• Windows Server 2016 (только односеансовое развертывание) Windows Server 2016 in a single-session deployment only

Поддержка дискретного назначения устройств Discrete Device Assignment support

Службы удаленных рабочих столов поддерживают физические GPU, предоставляемые с помощью дискретного назначения устройств с узлов Hyper-V Windows Server 2016 или Windows Server 2019. Remote Desktop Services supports Physical GPUs presented with Discrete Device Assignment from Windows Server 2016 or Windows Server 2019 Hyper-V hosts. Дополнительные сведения см. в разделе Планирование развертывания устройств с помощью дискретного назначения устройств. See Plan for deploying Discrete Device Assignment for more details.

Развертывание VDI: поддерживаемые гостевые ОС VDI deployment – supported guest OSes

Серверы узлов виртуализации удаленных столов Windows Server 2016 и Windows Server 2019 поддерживают следующие гостевые ОС: Windows Server 2016 and Windows Server 2019 RD Virtualization Host servers support the following guest OSes:

• Windows 10 Корпоративная Windows 10 Enterprise
• Windows 8.1 Корпоративная Windows 8.1 Enterprise
• Windows 7 SP1 Корпоративная Windows 7 SP1 Enterprise

• Службы удаленных рабочих столов не поддерживают разнородные коллекции сеансов. Remote Desktop Services doesn’t support heterogeneous session collections. Операционные системы всех виртуальных машин в коллекции должны быть одной версии. The OSes of all VMs in a collection must be the same version.
• Вы можете иметь отдельные однородные коллекции с разными версиями гостевой ОС на одном узле. You can have separate homogeneous collections with different guest OS versions on the same host.
• Узел Hyper-V, используемый для запуска виртуальных машин, должен иметь ту же версию операционной системы, что и узел Hyper-V, использованный для создания исходных шаблонов виртуальных машин. The Hyper-V host used to run VMs must be the same version as the Hyper-V host used to create the original VM templates.

Единый вход Single sign-on

Службы удаленных рабочих столов Windows Server 2016 и Windows Server 2019 поддерживают два основных режима единого входа: Windows Server 2016 and Windows Server 2019 RDS supports two main SSO experiences:

• В приложении (приложение удаленного рабочего стола в Windows, iOS, Android и Mac) In-app (Remote Desktop application on Windows, iOS, Android, and Mac)
• Веб-служба SSO Web SSO

Используя приложение удаленного рабочего стола, вы можете хранить учетные данные либо как часть информации о подключении (Mac), либо как часть управляемых учетных записей (iOS, Android, Windows ) безопасно с помощью механизмов, уникальных для каждой ОС. Using the Remote Desktop application, you can store credentials either as part of the connection info (Mac) or as part of managed accounts (iOS, Android, Windows) securely through the mechanisms unique to each OS.

Чтобы подключиться к рабочим столам и приложениям RemoteApp с помощью единого входа в клиенте подключения удаленных рабочих столов в Windows, необходимо подключиться к веб-странице удаленных рабочих столов через Internet Explorer. To connect to desktops and RemoteApps with SSO through the inbox Remote Desktop Connection client on Windows, you must connect to the RD Web page through Internet Explorer. На стороне сервера требуются следующие параметры конфигурации. The following configuration options are required on the server side. Другие конфигурации для единого входа для интернет-решений не поддерживаются. No other configurations are supported for Web SSO:

• Веб-интерфейс удаленного рабочего стола установлен на проверку подлинности на основе форм (по умолчанию) RD Web set to Forms-Based Authentication (Default)
• Веб-интерфейс шлюза удаленного рабочего стола установлен на проверку пароля (по умолчанию) RD Gateway set to Password Authentication (Default)
• Для развертывания RDS установлено значение «Использовать учетные данные шлюза удаленных рабочих столов» (по умолчанию) в свойствах шлюза удаленных рабочих столов. RDS Deployment set to «Use RD Gateway credentials for remote computers» (Default) in the RD Gateway properties

Из-за требуемых параметров конфигурации единый вход для интернет-решений не поддерживается смарт-картами. Due to the required configuration options, Web SSO is not supported with smartcards. Пользователи, которые входят через смарт-карты, могут столкнуться с несколькими приглашениями на вход. Users who login via smartcards might face multiple prompts to login.

Дополнительные сведения о создании развертывания служб удаленных рабочих столов VDI см. в разделе Поддерживаемые настройки безопасности в Windows 10 для служб удаленных рабочих столов VDI. For more information about creating VDI deployment of Remote Desktop Services, check out Supported Windows 10 security configurations for Remote Desktop Services VDI.

Использование служб удаленных рабочих столов со службами прокси приложений Using Remote Desktop Services with application proxy services

Вы можете использовать службы удаленных рабочих столов с прокси приложениями Azure AD. You can use Remote Desktop Services with Azure AD Application Proxy. Службы удаленных рабочих столов не поддерживают использование прокси-службы веб-приложения, включенного в Windows Server 2016 и более поздние версии. Remote Desktop Services does not support using Web Application Proxy, which is included in Windows Server 2016 and earlier versions.