Winrm служба: установка и настройка для служба удаленного управления Windows — Win32 apps

20.05.1979 alexxlab

Содержание

установка и настройка для служба удаленного управления Windows — Win32 apps

09/14/2021
Чтение занимает 13 мин

В этой статье

для выполнения сценариев служба удаленного управления Windows (winrm) и для выполнения операций с данными с помощью программы командной строки winrm служба удаленного управления Windows (winrm) должны быть установлены и настроены.

Эти элементы также зависят от конфигурации WinRM.

Где установлен WinRM

служба WinRM автоматически устанавливается со всеми поддерживаемыми версиями Windows операционной системы.

Настройка WinRM и IPMI

Эти компоненты поставщика службы удаленного управления (IPMI) и SNMP-интерфейса WMI устанавливаются вместе с операционной системой.

служба WinRM запускается автоматически на Windows Server 2008 и выше (в Windows Vista необходимо запустить службу вручную).
По умолчанию прослушиватель WinRM не настроен. Даже если служба WinRM запущена, WS-Management сообщения протокола, которые запрашивают данные, не могут быть получены или отправлены.
Брандмауэр подключения к Интернету (ICF) блокирует доступ к портам.

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

winrm e winrm/config/listener

Чтобы проверить состояние параметров конфигурации, введите следующую команду.

winrm get winrm/config

Быстрая настройка по умолчанию

Можно включить протокол WS-Management на локальном компьютере и настроить конфигурацию по умолчанию для удаленного управления с помощью команды winrm quickconfig .

winrm quickconfigКоманда (или сокращенная версия winrm qc ) выполняет эти операции.

Запускает службу WinRM и задает для типа запуска службы автоматический запуск.
Настраивает прослушиватель для портов, которые отправляют и получают сообщения протокола WS-Management с помощью HTTP или HTTPS по любому IP-адресу.

Определяет исключения ICF для службы WinRM и открывает порты для HTTP и HTTPS.

Примечание

winrm quickconfigКоманда создает исключение брандмауэра только для текущего профиля пользователя. Если профиль брандмауэра изменился по какой-либо причине, следует запустить, winrm quickconfig чтобы включить исключение брандмауэра для нового профиля; в противном случае исключение может быть не включено.

Чтобы получить сведения о настройке конфигурации, введите winrm help config в командной строке.

Настройка WinRM с параметрами по умолчанию

Введите winrm quickconfig в командной строке.
Если вы не используете учетную запись администратора локального компьютера, необходимо выбрать пункт
Запуск от имени администратора в меню » Пуск » или использовать команду runas в командной строке.
Когда средство выводит на экран команду сделать эти изменения [ y/n ] ?, введите y.
Если настройка прошла успешно, отображаются следующие выходные данные.
```
WinRM has been updated for remote management.

WinRM service type changed to delayed auto start.
WinRM service started.
Created a WinRM listener on https://* to accept WS-Man requests to any IP on this machine.
 
```
Используйте параметры по умолчанию для клиентских и серверных компонентов WinRM или настройте их. Например, может потребоваться добавить определенные удаленные компьютеры в список TrustedHosts конфигурации клиента.
Если невозможно установить взаимную проверку подлинности, следует настроить список надежных узлов. Kerberos допускает взаимную проверку подлинности, но не может использоваться — только в доменах рабочих групп. При настройке доверенных узлов для Рабочей группы рекомендуется сделать список максимально ограниченным.
Создайте прослушиватель HTTPS, введя команду
winrm quickconfig -transport:https . Имейте в виду, что для работы транспорта HTTPS необходимо открыть порт 5986.

Параметры по умолчанию прослушивателя и протокола WS-Management

Чтобы получить конфигурацию прослушивателя, введите winrm enumerate winrm/config/listener в командной строке. Прослушиватели определяются транспортом (HTTP или HTTPS) и адресом IPv4 или IPv6.

winrm quickconfig создает следующие параметры по умолчанию для прослушивателя. Можно создать более одного прослушивателя. Для получения дополнительных сведений введите winrm help config в командной строке.

Адрес

Задает адрес, для которого был создан данный прослушиватель.

Транспортировка

Указывает транспорт для отправки и получения запросов и ответов протокола WS-Management. Значение должно быть либо

http , либо HTTPS. Значение по умолчанию — http.

Порт

Задает TCP-порт, для которого создается данный прослушиватель.

WinRM 2,0: HTTP-порт по умолчанию — 5985.

Hostname (Имя узла)

Указывает имя узла компьютера, на котором запущена служба WinRM. Значением должно быть полное доменное имя, строка литерала IPv4 или IPv6 или символ-шаблон.

Активировано

Указывает, включен или отключен прослушиватель. По умолчанию используется значение

True.

URLPrefix

Указывает URL-префикс для приема запросов HTTP или HTTPS. Это строка, содержащая только символы a – z, A – Z, 9-0, символ подчеркивания ( _ ) и косую черту (/). Строка не должна начинаться с косой черты или заканчиваться ей (/). Например, если имя компьютера — самплемачине, то клиент WinRM будет указывать https://SampleMachine/<*URLPrefix*> в адресе назначения. Префикс URL-адреса по умолчанию — WSMan.

CertificateThumbprint

Указывает отпечаток сертификата службы. Это значение представляет собой строку шестнадцатеричных значений из двух цифр, найденных в поле отпечатка сертификата. Эта строка содержит хэш SHA-1 сертификата. Сертификаты используются при проверке подлинности на основе сертификата клиента. Сертификаты могут быть сопоставлены только с локальными учетными записями пользователей и не работают с учетными записями домена.

ListeningOn

Указывает адреса IPv4 и IPv6, используемые прослушивателем. Например: «111.0.0.1, 111.222.333.444,:: 1, 1000:2000:2c: 3: C19:9ec8: a715:5e24, 3FFE: 8311: FFFF: f70f: 0:5EFE: 111.222.333.444, FE80:: 5EFE: 111.222.333.444% 8, FE80:: C19:9ec8: a715:5e24% 6».

Параметры протокола по умолчанию

Многие параметры конфигурации, такие как максенвелопесизекб или

соаптрацеенаблед, определяют взаимодействие клиентских и серверных компонентов WinRM с протоколом WS-Management. В следующем списке описаны доступные параметры конфигурации.

MaxEnvelopeSizekb

Указывает максимальный объем данных протокола доступа к объектам (в килобайтах). Значение по умолчанию — 150 КБ.

Примечание

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

макстимеаутмс

Указывает максимальное время ожидания (в миллисекундах), которое может использоваться для любого запроса, кроме запросов на включение внесенных изменений. Значение по умолчанию — 60000.

MaxBatchItems

Задает максимальное количество элементов, которое может быть использовано в ответе Pull. Значение по умолчанию — 32000.

MaxProviderRequests

Задает максимальное количество одновременных запросов, допускаемое службой. Значение по умолчанию — 25.

WinRM 2,0: Этот параметр является устаревшим и имеет значение только для чтения.

Параметры конфигурации клиента WinRM по умолчанию

Клиентская версия WinRM имеет следующие параметры конфигурации по умолчанию.

нетворкделаймс

Задает дополнительное время ожидания клиента в миллисекундах для поправки на сетевую задержку. Значение по умолчанию — 5000 миллисекунд.

URLPrefix

Указывает URL-префикс для приема запросов HTTP или HTTPS. Префикс URL-адреса по умолчанию — WSMan.

алловуненкриптед

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

Basic

Позволяет клиентскому компьютеру использовать обычную проверку подлинности. При использовании обычной проверки подлинности имя пользователя и пароль передаются серверу или прокси-серверу открытым текстом. Эта схема является наименее безопасным методом проверки подлинности. Значение по умолчанию равно True.

Digest (дайджест)

Позволяет клиентскому компьютеру использовать дайджест-проверку подлинности. Дайджест-проверка подлинности проводится по принципу «запрос-ответ». В качестве запроса поступает строка данных, указанная сервером. Инициировать запрос дайджест-проверки подлинности может только клиентский компьютер.

Клиентский компьютер отправляет запрос на сервер для проверки подлинности и получает строку токена с сервера. Затем клиентский компьютер отправляет запрос ресурса, включая имя пользователя и криптографический хэш пароля, в сочетании со строкой токена. Дайджест-проверка подлинности поддерживается для HTTP и для HTTPS. Клиентские скрипты и приложения оболочки WinRM могут указывать дайджест-проверку подлинности, но служба WinRM не принимает дайджест-проверку подлинности. Значение по умолчанию равно True.

Примечание

Дайджест-проверка подлинности по протоколу HTTP не считается безопасной.

Сертификат

Позволяет клиенту использовать проверку подлинности на основе сертификата клиента. Проверка подлинности на основе сертификатов — это схема, в которой сервер проверяет подлинность клиента, идентифицируемого сертификатом X509. Значение по умолчанию равно True.

Kerberos

Позволяет клиентскому компьютеру использовать проверку подлинности Kerberos. Проверка подлинности Kerberos подразумевает взаимную проверку подлинности клиента и сервера с использованием сертификатов Kerberos. Значение по умолчанию равно True.

Согласование

Позволяет клиенту использовать проверку подлинности согласованием. При проверке подлинности с согласованием клиент отправляет серверу запрос на проверку подлинности. Сервер определяет, какой протокол использовать — Kerberos или NTLM. Протокол Kerberos выбирается для проверки подлинности учетной записи домена, а NTLM — для учетных записей локального компьютера. Имя пользователя должно быть указано в \ _ формате имени пользователя домена для пользователя домена. Имя пользователя должно быть указано в _ формате «имя \ пользователя сервера _ » для локального пользователя на компьютере сервера. Значение по умолчанию равно True.

CredSSP

Позволяет клиенту использовать проверку подлинности с помощью поставщика поддержки безопасности учетных данных (CredSSP). CredSSP позволяет приложению делегировать учетные данные пользователя с клиентского компьютера на целевой сервер. По умолчанию False.

дефаултпортс

Указывает порты, которые клиент будет использовать для HTTP или HTTPS.

WinRM 2,0: HTTP-порт по умолчанию — 5985, а HTTPS-порт по умолчанию — 5986.

TrustedHosts

Указывает список доверенных удаленных компьютеров. В этот список необходимо добавить другие компьютеры в Рабочей группе или компьютерах в другом домене.

Примечание

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

Если для Трустедхост указан IPv6-адрес, адрес должен быть заключен в квадратные скобки, как показано в следующей команде WinRM Utility: winrm set winrm/config/client '@{TrustedHosts ="[0:0:0:0:0:0:0:0]"}' .

Чтобы получить дополнительные сведения о добавлении компьютеров в список TrustedHosts, введите winrm help config .

Параметры конфигурации по умолчанию для службы WinRM

Версия службы WinRM имеет следующие параметры конфигурации по умолчанию.

RootSDDL

Указывает дескриптор безопасности, управляющий удаленным доступом к прослушивателю. Значение по умолчанию — «О:НСГ: BAD: P (A;; Общедоступный;;; BA) (A;; GR;;; ER) С:П (AU; FA; Общедоступный;;; WD) (AU; SA; ГВГКС;;; WD) «.

максконкуррентоператионс

Максимальное количество одновременных операций. Значение по умолчанию — 100.

WinRM 2,0: Параметр Максконкуррентоператионс является устаревшим и имеет значение только для чтения. Этот параметр заменен на свойств maxconcurrentoperationsperuser.

Свойств maxconcurrentoperationsperuser

Указывает максимальное количество одновременных операций, которые любой пользователь может удаленно открыть в одной системе. Значение по умолчанию — 1500.

енумератионтимеаутмс

Указывает время ожидания простоя в миллисекундах между сообщениями о вытягиваниех. Значение по умолчанию — 60000.

MaxConnections

Указывает максимальное количество активных запросов, которые служба может обрабатывать одновременно. Значение по умолчанию — 300.

WinRM 2,0: Значение по умолчанию — 25.

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

Указывает максимальное время в секундах, необходимое службе WinRM для получения пакета. Значение по умолчанию — 120 секунд.

алловуненкриптед

Позволяет клиентскому компьютеру запрашивать передачу данных в незашифрованном виде. По умолчанию False.

Basic

Позволяет службе WinRM использовать обычную проверку подлинности. По умолчанию False.

Сертификат

Позволяет службе WinRM использовать проверку подлинности на основе сертификата клиента. По умолчанию False.

Kerberos

Позволяет службе WinRM использовать проверку подлинности Kerberos. Значение по умолчанию равно True.

Согласование

Позволяет службе WinRM использовать проверку подлинности Negotiate. Значение по умолчанию равно True.

CredSSP

Позволяет службе WinRM использовать проверку подлинности с помощью поставщика поддержки безопасности учетных данных (CredSSP). По умолчанию False.

CbtHardeningLevel

Задает политику относительно требований к токенам привязки канала в запросах проверки подлинности. Значение по умолчанию — ослабление.

дефаултпортс

Указывает порты, которые служба WinRM будет использовать как для HTTP, так и для HTTPS.

WinRM 2,0: HTTP-порт по умолчанию — 5985, а HTTPS-порт по умолчанию — 5986.

IPv4Filter и IPv6Filter

Указывает адреса IPv4 или IPv6, которые могут использоваться прослушивателями. Значения по умолчанию: IPv4Filter = * и IPv6Filter = * .

IPv4: Литеральная строка IPv4 состоит из четырех десятичных чисел с точками в диапазоне от 0 до 255. Например: 192.168.0.0.

IPv6: Строка литерала IPv6 заключена в квадратные скобки и содержит шестнадцатеричные числа, разделенные двоеточиями. Например:: [ : 1 ] или [ 3FFE: FFFF:: 6ECB: 0101 ] .

енаблекомпатибилитихттплистенер

Указывает, включен ли прослушиватель совместимости HTTP. Если этот параметр имеет значение true, прослушиватель будет прослушивать порт 80 в дополнение к порту 5985. По умолчанию False.

енаблекомпатибилитихттпслистенер

Указывает, включен ли HTTPS-прослушиватель совместимости. Если этот параметр имеет значение true, прослушиватель будет прослушивать порт 443 в дополнение к порту 5986. По умолчанию False.

Параметры конфигурации по умолчанию для Winrs

winrm quickconfig также настраивает параметры по умолчанию для WinRS .

AllowRemoteShellAccess

Разрешает доступ к удаленным оболочкам. Если для этого параметра задано значение false, то новые подключения удаленной оболочки будут отклонены сервером. Значение по умолчанию равно True.

IdleTimeout

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

WinRM 2,0: Значение по умолчанию — 180000. Минимальное значение — 60000. Установка этого значения ниже 60000 не влияет на время ожидания.

MaxConcurrentUsers

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

MaxShellRunTime

Указывает максимальное время в миллисекундах, в течение которого разрешено выполнение удаленной команды или сценария. Значение по умолчанию — 28800000.

WinRM 2,0: Параметр Максшеллрунтиме имеет значение только для чтения. Изменение значения Максшеллрунтиме не повлияет на удаленные оболочки.

MaxProcessesPerShell

Задает максимальное количество процессов, которое разрешается запускать любой операции оболочки. 0 означает неограниченное количество процессов. Значение по умолчанию — 15.

MaxMemoryPerShellMB

Указывает максимальный объем памяти, выделяемой на оболочку, включая дочерние процессы оболочки. Значение по умолчанию — 150 МБ.

MaxShellsPerUser

Задает максимальное число одновременно существующих оболочек, которые пользователь может одновременно открыть на одном компьютере. Если этот параметр политики включен, пользователь не сможет открывать новые удаленные оболочки, если число превышает указанный предел. Если этот параметр политики отключен или не задан, будет установлен предел по умолчанию в 5 удаленных оболочек.

Настройка WinRM с групповая политика

используйте редактор групповая политика для настройки Windows удаленной оболочки и WinRM для компьютеров в вашей организации.

Настройка с помощью групповая политика

Откройте окно командной строки с правами администратора.
В командной строке введите gpedit.msc. Откроется окно Редактор объектов групповой политики .
найдите служба удаленного управления Windows и Windows удаленную оболочку групповая политика объектов (GPO) в разделе конфигурация компьютера \ административные шаблоны \ Windows компоненты.
На вкладке Расширенная выберите параметр, чтобы просмотреть описание. Дважды щелкните параметр, чтобы изменить его.

Windows Порты брандмауэра и WinRM 2,0

Начиная с WinRM 2,0, порты прослушивателя по умолчанию, настроенные, Winrm quickconfig — это порт 5985 для транспорта HTTP и порт 5986 для HTTPS. Прослушиватели WinRM можно настроить для любого произвольного порта.

Если компьютер обновлен до WinRM 2,0, ранее настроенные прослушиватели переносятся и по-прежнему получают трафик.

Заметки об установке и настройке WinRM

Служба WinRM не зависит от других служб, кроме WinHttp. если служба iis Admin установлена на том же компьютере, могут отображаться сообщения, указывающие, что WinRM невозможно загрузить до службы IIS (IIS). Однако WinRM не зависит от IIS, — так как эти сообщения возникают из-за того, что служба IIS запускается до службы HTTP. Для WinRM требуется WinHTTP.dll регистрация.

Если на компьютере установлен клиент брандмауэра ISA2004, это может привести к тому, что клиент веб-служб для управления (WS-Management) перестает отвечать на запросы. Чтобы избежать этой проблемы, установите брандмауэр ISA2004 с пакетом обновления 1 (SP1).

Если для двух служб прослушивателя с разными IP-адресами настроен один и тот же номер порта и имя компьютера, служба WinRM прослушивает или получает сообщения только по одному адресу. Это обусловлено тем, что префиксы URL-адресов, используемые протоколом WS-Management, одинаковы.

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

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

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

Если система не обнаруживает BMC и не устанавливает драйвер автоматически, но во время установки был обнаружен контроллер BMC, необходимо создать устройство BMC. Для этого введите в командной строке следующую команду: Rundll32 ipmisetp.dll, AddTheDevice . После выполнения этой команды создается устройство IPMI, которое отображается в диспетчер устройств. Если удалить компонент управления оборудованием, устройство будет удалено.

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

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

Примечания по конфигурации подключаемого модуля WMI

начиная с Windows 8 и Windows Server 2012 подключаемые модули WMI имеют собственные конфигурации безопасности. Чтобы пользователь с обычным или энергопотреблением (не администратором) мог использовать подключаемый модуль WMI, необходимо включить доступ для этого пользователя после настройки прослушивателя . Во-первых, необходимо настроить пользователя для удаленного доступа к WMI с помощью одного из этих действий.

Выполните команду lusrmgr.msc , чтобы добавить пользователя в группу _ _ винрмремотевмиусерс в окне Локальные пользователи и группы .
Используйте программу командной строки WinRM для настройки дескриптора безопасности для пространства имен подключаемого модуля WMIследующим образом: winrm configSDDL http://schemas. microsoft.com/wbem/wsman/1/wmi/ WmiNamespace .

Когда появится пользовательский интерфейс, добавьте пользователя.

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

Большинство классов WMI для управления находятся в корневом пространстве имен \ CIMV2 .

Служба WinRM не начинается — Windows Server

09/24/2021
Чтение занимает 2 мин

В этой статье

В этой статье содержится решение проблемы, которая Windows удаленного диспетчера (WinRM) не начинается после того, как вы удаляйте WinRM 2. 0.

Применяется к: Windows Server 2012 R2, Windows 10 — все выпуски
Исходный номер КБ: 974504

Симптомы

Вы удаляйте Windows удаленного диспетчера 2.0 (WinRM) с компьютера с Windows Server 2008 или Windows Vista. Когда вы пытаетесь запустить службу WinRM с помощью команды winrm чистого запуска, служба WinRM не начинается, и вы получаете ошибку «Отказано в доступе».

Причина

Эта проблема возникает при сдаче winRM 2.0 в порт 5985.

Решение

Чтобы устранить эту проблему, используйте один из следующих методов.

Восстановление конфигурации WinRM

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

Откройте окно командной строки.
В командной строке введите следующую команду, а затем нажмите клавишу ВВОД:
```
winrm quickconfig  
```

Удаление прослушиватель WinRM в порту 5985

Откройте окно командной строки.
В командной строке введите следующую команду, а затем нажмите клавишу ВВОД:
```
winrm enumerate winrm/config/listener  
```
В нем соревнуются все слушатели, которые в настоящее время использует WinRM.
Найдите слушателя, у него есть следующие параметры и значения:
Обратите внимание на значение, которое перечислены для параметра Адрес слушателя.
Введите следующую команду и нажмите клавишу ВВОД:
winrm delete winrm/config/Listener? Адрес= Адрес +Transport=HTTP
В этой команде местообладатель Address — это значение, которое вы отметили на шаге 4.

Служба winrm не прослушивает запросы ws management. Как активировать Windows Remote Management с помощью групповой политики

WinRM и WinRS являются нововведением в Windows Vista, Windows Server 2003 R2, Windows Server 2008 (и Server 2008 Core). Это новые мощные средства командной строки, предлагающие системным администраторам улучшенные возможности удаленного управления и удаленного выполнения программ на машинах с Windows. Однако, их нужно сперва включить, кроме того, вам потребуется некоторое время на изучение их функциональности. Вам повезло: в этой статье есть все, что потребуется вам для того, чтобы начать использовать эти средства прямо сегодня!

Что такое Windows Remote Management (WinRM) (Удаленное управление Windows)?

Windows Remote Management (сокращенно WinRM) – это новая удобная служба удаленного управления для Windows Server 2003 R2, Windows Vista и Windows Server 2008. WinRM – это «серверный» компонент этого приложения удаленного управления, а WinRS (Windows Remote Shell – удаленная среда Windows) – это «клиент» для WinRM, которые запускается на удаленном компьютере, пытаясь удаленно управлять сервером WinRM. Однако должен заметить, что на ОБОИХ компьютерах должен быть установлен и включен WinRM, чтобы WinRS мог работать и получать информацию об удаленной системе. WinRM основан на стандартах Web Services for Management (службы для управления) (WS-Management). Это означает, что WinRM использует протокол HTTP (порт 80) и запросы SOAP для выполнения работы. Это хорошо тем, что запросы HTTP легко пересылать через брандмауэр. Из этого вытекают хорошее и плохое следствия: с одной стороны, так проще будет управлять удаленным компьютером через Internet, но, с другой стороны, злоумышленнику проще удаленно атаковать этот же компьютер. Еще одно небольшое преимущество использования порта 80 в том, что нет необходимости открывать другие порты на сервере, если входящие HTTP соединения уже были разрешены.

Согласно утверждениям Microsoft, WinRM представляет собой «Новое средство от Microsoft для установления основанного на стандартах API для системного управления». Так что, если вы ранее и не были заинтересованы в изучении таких средств, мне кажется, тот факт, что «это новый стандарт Microsoft» делает его достойным изучения.

Возможно, вы уже знакомы с базой данных Windows Management Instrumentation (WMI) (Инструментарий управления Windows). Но, на всякий случай, скажу, что эта база данных содержит всевозможную информацию об аппаратном и программного обеспечении компьютера. Почти каждое приложение, управляющее системой Windows, опускается не уровень базы данных WMI для выполнения всех административных задач на данном ПК.

WinRM будет использовать базу данных WMI для выполнения задач, аналогичных тем, которые вы, возможно, выполняли с помощью других программных средств вроде VBScript. Преимущество WinRM в том, что он использует HTTP(порт 80), как я уже говорил, кроме того, есть даже специальный код, позволяющий WinRM разделять входящие соединения на порт 80 с компонентом IIS, который уже, возможно, работает с этим портом.

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

Производитель вашего ПО, управляющего системой, возможно, уже запланировали использовать WinRM в следующих выпусках своего ПО, так что вы, возможно, уже используете WinRM через другие приложения. Однако вы можете использовать этот компонент и собственноручно, с помощью команды winrm.cmd . С этим средством CLI вы можете очень просто извлекать информацию из базы данных WMI для любой решаемой вами задачи.

Как вы увидите ниже, WinRM обладает интерфейсом командной строки с множеством параметров. Справочная информация о WinRM будет вам показана даже в том случае, когда он не включен на вашей системе.

Рисунок 1: параметры командной строки WinRM

Как включать и использовать WinRM?

Если вы используете Windows 2008 Server, WinRM уже установлен, но не включен по умолчанию. Это хорошая предосторожность. Самый простой способ проверить, включен ли WinRM и запущен ли на вашей машине, это перейти к командной строке и набрать:

winrm enumerate winrm/config/listener

Если вы не получаете ответа, значит, WinRM не запущен. Для настраивания WinRM на автоматический запуск и разрешение удаленного доступа используйте команду winrm quickconfig , например:

После настройки quickconfig, я перезапустил команду перечисления со следующими результатами:

C:\Users\Administrator> winrm e winrm/config/listener Listener Address = * Transport = HTTP Port = 80 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 10.253.15.98, 127.0.0.1, ::1, fe80::5efe:10.253.15.98%11, fe80::9583:2148:e1ef:6444%10 C:\Users\Administrator>

Теперь я знаю, что WinRM включен.

Кстати, если вы хотите отключить WinRM, нужно использовать такую команду:

winrm delete winrm/config/listener?IPAdress=*+Transport=HTTP

Для использования WinRM все узлы, взаимодействующие с ним, должны быть членами того же домена, что и узел с WinRM.

Что такое WinRS и как его использовать?

WinRS – это аббревиатура для Windows Remote Shell (удаленная среда Windows). С WinRS вы можете делать удаленные запросы на машины с Windows, на которых запущен WinRM. Однако не забывайте, что на вашей машине также необходимо запускать WinRM для работы с WinRS.

Как вы видите на диаграмме ниже, winrs представляет собой полнофункциональное средство командной строки с огромным количеством справочной информации по работе и ним.

Рисунок 2: параметры командной строки WinRS

Одним из самых обычных способов использования WinRS является выполнение команд на удаленной машине. Конечно же, это взаимодействие происходит с помощью протокола HTTP (порт 80) (по умолчанию).

Ниже представлен пример использования WinRS: я выполнил команды на узле localhost. Я запустил две команды: ‘ ‘ver ‘ и ‘dir C: ‘. В каждом случае в ответ была получена адекватная информация.

Рисунок 3: демонстрация команд WinRS

Итоги

WinRM и WinRS представляют собой очень мощные новые средства, о которых системные администраторы Windows просто обязаны узнать. Подумайте о возможностях удаленного управления с WinRM/WinRS! Вы можете устанавливать программы, изменять настройки, решать проблемы (конечно, если проблема не в сетевом взаимодействии). Вы можете пойти дальше и соединить WinRS со скриптом для выполнения этих задач на нескольких компьютерах. Кроме того, помните, что вне зависимости от того, используете ли вы эти средства или нет, ваше ПО, управляющее системой, скоро будут их использовать так или иначе.

Постовой

Автозапчасти для вашего автомобиля в любом регионе.

Иногда бываю в Питере по делам, подкинули ссылку на компанию, которая предлагает посуточную аренду квартир в СПб . Неплохая альтернатива гостиницам.

17.10.2011 Дон Джоунз

Я понял, что создатели PowerShell были несколько ленивы, и это хорошо. Они не хотели кодировать параметр -ComputerName для каждой команды, поэтому создали общую систему под названием «удаленное взаимодействие». По существу, эта система активирует любую команду для запуска на удаленном компьютере. Вы даже можете запускать разные команды, которые существуют на удаленном компьютере, но отсутствуют на вашем. Это означает, что вам не нужно постоянно устанавливать каждую команду на своей рабочей станции. Эта удаленная система очень эффективна и дает ряд интересных административных возможностей

Когда я начал использовать PowerShell, я увлекся командой Get-Service и заметил, что у нее есть параметр -ComputerName. Не означает ли это, что можно подключиться к службе и с других компьютеров? После проведения ряда экспериментов я обнаружил, что это как раз то, что написано. Я заинтересовался и принялся искать параметры -ComputerName у других команд. И расстроился, когда выяснил, что их было только несколько.

PowerShell обеспечивает два типа удаленного взаимодействия: удаленное взаимодействие один к одному (1:1) и удаленное взаимодействие один к нескольким (1:n). Прежде чем рассказать о них, хочу пояснить некоторые основы.

Основы удаленного взаимодействия в PowerShell

Удаленное взаимодействие PowerShell работает почти как Telnet и другие старые технологии удаленного управления. Когда вы запускаете команду, она на самом деле запускается на удаленном компьютере. Все, что возвращается на ваш компьютер, является результатом работы этой команды. В отличие от Telnet или Secure Shell (SSH), PowerShell использует новый протокол системы связи, который называется Web Services for Management (WS-Management). Протокол действует поверх HTTP или HTTP Secure (HTTPS), что облегчает прокладывание маршрута через брандмауэры, если это необходимо, поскольку протокол использует только один порт для установления связи. Реализация WS-Management от Microsoft идет в форме фоновой службы, которая называется Windows Remote Management. WinRM устанавливается вместе с PowerShell 2.0 и запускается по умолчанию на серверах, подобных Windows Server 2008 R2. На Windows 7 она устанавливается по умолчанию, но не активируется. Необходимо активировать WinRM на тех компьютерах, на которые вы хотите послать команду. Компьютер, за которым вы находитесь физически, не нуждается в запуске службы WinRM.

Все команды PowerShell производят объекты в качестве выходных данных. Когда вы запускаете команду удаленно, ее выходные данные нужно облечь в форму, которую можно легко передавать по сети, используя протокол HTTP или HTTPS. Так, PowerShell автоматически преобразует выходные объекты в файлы XML, которые передаются по сети. Достигнув вашего компьютера, они преобразовываются обратно в объекты, с которыми может работать PowerShell. Однако эти преобразованные обратно объекты на самом деле являются мгновенными снимками. Они не могут обновлять сами себя ежеминутно. Таким образом, если вы должны добраться до объектов, которые представляют собой процессы, запускаемые на удаленном компьютере, то полученный результат будет верен только для конкретного промежутка времени, в течение которого эти объекты были сгенерированы. Значения, такие как использование памяти и процессора, не изменятся. Более того, вы не сможете заставить преобразованные обратно объекты сделать что-либо. Например, вы не можете приказать объекту остановить самого себя. Это основное ограничение удаленного взаимодействия, но оно не помешает вам работать и выполнять интересные задачи.

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

Как ваш компьютер (он же локальный компьютер) и один из тех, которым вы хотите послать команду (он же удаленный компьютер), должны работать с Windows PowerShell 2.0? Windows XP является устаревшей версией Windows, на которую вы можете установить PowerShell 2.0. Таким образом, старая версия тоже может принимать участие в удаленной сессии.
В идеале локальный и удаленный компьютеры должны быть членами одного домена или членами доверенных/доверяющих доменов. С системой удаленного взаимодействия можно работать и вне домена, но это сложно, и здесь я об этом рассказывать не буду. Чтобы узнать больше об этом сценарии, обратитесь к разделу PowerShell Help, где говорится о Remote_Troubleshooting.

Обзор WinRM

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

Нельзя сказать, что WinRM представляет собой что-то особенное для PowerShell. WinRM может прокладывать трафик к нескольким административным приложениям. По существу, WinRM действует как диспетчер. Когда трафик появляется, WinRM решает, какое приложение должно взаимодействовать с ним, и помечает его именем приложения-адресата. Принимающее приложение должно зарегистрироваться в WinRM, таким образом WinRM сможет прослушивать входящий трафик от его имени. Другими словами, вам нужно не только активировать WinRM, но и зарегистрировать Power Shell как конечную точку для WinRM.

Самым простым способом выполнения обеих задач является запуск PowerShell от имени администратора и выполнение команды Enable-PSRemoting. Вы можете посмотреть руководство по другой команде, которая называется Set-WSManQuickConfig. Нет нужды запускать команду. Это сделает за вас Enable-PSRemoting, и она же выполняет еще несколько шагов, которые необходимы для установления удаленного взаимодействия и работы. В сущности, команда Enable-PSRemoting запускает службу WinRM, задает ее настройки для запуска автоматически, регистрирует PowerShell как конечную точку и даже устанавливает исключения в Windows Firewall для того, чтобы разрешить входящий трафик WinRM.

Если вам не хочется обходить все компьютеры ради активации удаленного взаимодействия, можно задействовать объект групповой политики Group Policy Object (GPO). Необходимые настройки GPO встроены в контроллеры домена Windows Server 2008 R2. Просто откройте GPO и идите по маршруту Computer Configuration\

Administrative Templates\Windows Components. Внизу списка вы найдете как Remote Shell, так и Windows Remote Management (WRM), настройки которых нужно задать. Раздел Help о проблемах системы удаленного взаимодействия (Remote_Troubleshooting) даст вам детальные инструкции о том, как это сделать. Просмотрите разделы How to Enable Remoting in an Enterprise и How to Enable Listeners by Using a Group Policy в Help.

WinRM 2.0 (который применяется PowerShell) по умолчанию использует порт TCP 5985 для HTTP и порт 5986 для HTTPS. Это гарантирует, что WinRM не будет конфликтовать с локально установленными веб-серверами, которые настроены на прослушивание портов 80 и 443. Вы можете задать настройки WinRM для использования альтернативных портов, но я не рекомендую этого делать. Ели вы оставите эти порты, все команды удаленного доступа PowerShell будут работать нормально. Если вы измените эти порты, вам придется всегда указывать альтернативный порт при запуске команды удаленного доступа. Это означает, что вам придется больше печатать. Если вам крайне необходимо изменить порт, можете ввести команду:

Winrm set winrm/config/ listener? Address=* +Transport=HTTP @{Port=»1234″}

Цифры 1234 означают порт, который вам нужен. Здесь эта команда написана в несколько строк, но вам нужно вводить ее в одну строку. То же самое касается и всех других команд, описанных в статье. Если необходимо использовать HTTPS вместо http, вы можете видоизменить эту команду, чтобы настроить новый порт HTTPS. Должен признаться, что есть способ задать настройки WinRM на локальных компьютерах для того, чтобы задействовать альтернативные порты по умолчанию. Таким образом, вам не нужно постоянно определять альтернативный порт, когда вы запускаете команду удаленного доступа. Но давайте поработаем с настройками по умолчанию, заданными Microsoft.

Если покопаться в настройках GPO в Remote Shell, вы заметите, что можете задать, например, насколько долго удаленная сессия будет оставаться неактивной до того, как сервер прервет ее; как много одновременно действующих пользователей могут обращаться к удаленному серверу за один раз; как много памяти и процессов каждая удаленная оболочка может использовать; максимальное количество удаленных оболочек, которые пользователи могут открывать за один раз. Эти настройки помогут убедиться, что ваши серверы не перегружены забывчивыми администраторами. Однако по умолчанию необходимо быть администратором, чтобы использовать удаленное взаимодействие, поэтому вам не стоит беспокоиться об обычных пользователях, засоряющих ваши серверы.

Удаленное взаимодействие 1:1

Используя удаленное взаимодействие 1:1, вы, по существу, получаете доступ к командной строке на одном удаленном компьютере. Любые команды, которые вы даете, запускаются прямо на удаленном компьютере, а вы видите результаты в окне командной строки. Отчасти это похоже на использование Remote Desktop Connection, если не считать того, что вы ограничены средой командной строки PowerShell. Система удаленного взаимодействия PowerShell использует часть ресурсов, которые требует Remote Desktop, поэтому она оказывает намного меньшее воздействие на ваши серверы.

Для того чтобы установить соединение 1:1 с удаленным компьютером, названным Server-R2, нужно запустить

Enter-PSSession -Computername Server-R2

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

PS C:\>

Часть информирует вас о том, что все, что вы делаете, происходит на Server-R2. После этого вы можете запустить любые команды, какие хотите. Вы даже можете импортировать любые модули и добавить расширения PowerShell (PSSnapins), которые будут располагаться на удаленном компьютере.

Даже разрешения останутся те же самые. Ваша копия PowerShell будет работать с тем же маркером безопасности, с которым она запущена. PowerShell делает это с помощью Kerberos, поэтому не передает имени и пароля пользователя по сети. Любая команда, которую вы запускаете на удаленном компьютере, будет запускаться под вашими учетными данными, поэтому все, на выполнение чего вы имеете разрешение, вы сможете делать. Это похоже на регистрацию прямо с консоли компьютера и использование копии PowerShell данного компьютера. Это почти так. Вот несколько отличий.

Если у вас есть сценарий PowerShell для вашего профиля на удаленном компьютере, он не будет запускаться, когда вы подсоединитесь, используя систему удаленного доступа. Проще говоря, профили являются пакетом команд, которые автоматически запускаются каждый раз, когда вы открываете окно командной строки. Они используются для автоматической загрузки расширений, модулей и тому подобного.
Вы ограничены политикой Execution Policy удаленного компьютера. Скажем, политика вашего компьютера устанавливается на RemoteSigned так, что вы можете запускать локальные неподписанные сценарии. Если политика удаленного компьютера установлена в Restricted (настройка по умолчанию), она не позволит запускать никакие сценарии, когда вы взаимодействуете удаленно.

Многие команды PowerShell идут в парах: одна делает нечто, другая — противоположное этому. В нашем случае Enter-PSSession подсоединяет вас к удаленному компьютеру, а Exit-PSSession закрывает это соединение. Exit-PSSession не нужны никакие параметры. После запуска удаленное соединение закрывается, и приглашение вашего окна командной строки возвращается обратно к нормальному виду. А что если вы забудете запустить Exit-PSSession? Не беспокойтесь. PowerShell и WinRM способны выяснить, что вы сделали, и закрыть в случае необходимости удаленное соединение.

Хочу дать один совет. Когда вы подсоединяетесь к удаленному компьютеру, не запускайте на нем Enter-PSSession до тех пор, пока полностью не осознаете, что вы делаете. Например, вы работаете на ComputerА. Вы подсоединяетесь к Server-R2. В строке PowerShell вы запускаете

PS C:\> Enter-PSSession Server-DC4

Теперь Server-R2 содержит открытое соединение с Server-DC4. Это создает «цепь удаленного взаимодействия», которую отследить сложно. Кроме того, ваши серверы без надобности оказываются перегруженными. Могут быть моменты, когда вы должны будете делать это (например, Server-DC4 находится за брандмауэром и вы не можете получить к нему прямой доступ, поэтому в качестве посредника вам нужно использовать Server-R2). Однако общее правило состоит в следующем: старайтесь избегать цепочек удаленного взаимодействия.

Удаленное взаимодействие 1:n

Одна из самых интересных вещей в PowerShell — это удаленное взаимодействие 1: n. Оно позволяет вам отсылать команды на несколько удаленных компьютеров одновременно — полномасштабные распределенные вычисления. Каждый компьютер по отдельности будет выполнять команду и отсылать вам результаты. Все делается при помощи команды Invoke-Command в таком виде:

Invoke-Command -ComputerName Server-R2, Server-DC4, Server12 -Command {Get-EventLog Security -Newest 200 | Where {$_.EventID -eq 1212}}

Команда во внешних фигурных скобках передается на все три удаленных компьютера. По умолчанию PowerShell может разговаривать с 32 компьютерами сразу. Если вы определяете более чем 32 компьютера, они будут выстроены в очередь. Затем, когда один компьютер завершает работу, команду выполняет следующий. Если у вас действительно скоростная сеть и мощные компьютеры, вы можете увеличить их количество, используя параметр ThrottleLimit команды. Прочитать о том, как использовать этот параметр в Invoke-Command, вы можете на странице Help.

Единственный параметр, которого вы не увидите на странице Help этой команды, — параметр Command. Он, как я уже показал, работает прекрасно. Параметр Command является псевдонимом или кратким именем для параметра ScriptBlock, который указан на странице Help. Для меня проще использовать Command, поэтому я склонен задействовать именно его вместо ScriptBlock, однако они работают одинаково.

Если вы прочитали страницу Help для Invoke-Command внимательно, вы также заметили параметр, который позволяет указывать файл сценария, а не команду. Параметр FilePath позволяет посылать сценарий на удаленные компьютеры; это означает, что вы можете автоматизировать некоторые сложные задачи, а каждый компьютер будет выполнять свою долю работы.

Теперь остановимся на параметре Computer Name. В примере кода Invoke-Command у меня был список имен компьютера, разделенный запятыми. Если у вас много компьютеров, то вы, возможно, не хотите печатать их имена каждый раз, когда подсоединяетесь к ним. Вместо этого вы можете создать текстовый файл, который содержит по одному имени компьютера на одной строке, без запятых, кавычек или чего-то еще. Например, если бы ваш текстовый файл был назван webservers.txt, вы бы использовали такой код:

Invoke-Command -Command { dir } -ComputerName (Get-Content webservers.txt)

Круглые скобки заставляют PowerShell выполнять сначала команду Get-Content — это похоже на то, как работают круглые скобки в математике. Затем результаты Get-Content вкладываются в параметр -ComputerName.

Возможен также запрос имени компьютера в Active Directory, но это сложнее. Для того чтобы найти компьютер, вы можете использовать команду Get-ADComputer, но вы не вставите эту команду в круглые скобки, как делали это в Get-Content. Почему нет? Get-Content выдает простые текстовые строки, тогда как Get-ADComputer производит объекты типа «компьютер». Параметр -ComputerName ожидает строки. Если бы он должен был получать объекты «компьютер», то не знал бы, что с ними делать. Поэтому, если вы хотите использовать Get-ADComputer, вам нужно получить значения из свойства Name компьютерных объектов. Вот так:

Invoke-Command -Command {dir} -ComputerName (Get-ADComputer -Filter * -SearchBase «ou=Sales, dc=company, dc=pri» | Select-Object -Expand Name)

В круглых скобках компьютерные объекты передаются команде Select-Object, а параметр -Expand используется для выяснения свойства Name этих компьютерных объектов. Результат выражения в скобках — это набор имен компьютера, а не компьютерных объектов. Имена компьютеров — это как раз то, что нужно параметру -Computer Name.

Если вы не знакомы с Get-ADComputer, давайте посмотрим, что делает эта команда. Параметр -Filter определяет, что все компьютеры должны быть включены в результаты, а параметр -Search Base предписывает PowerShell, чтобы он начал искать компьютеры в организационной группе Sales (OU) в домене company.pri. Команда Get-ADComputer доступна только в Windows Server 2008 R2 и в Windows 7 после установки набора утилит Remote Server Administration Tools. В этих операционных системах вы запускаете

Import-Module ActiveDirectory

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

Есть кое-что еще!

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

Чтобы создать постоянные сессии, нужно использовать команду New-PSSession, затем сохранить их в переменной для легкого доступа. Например, следующий код создает сессию удаленного взаимодействия с тремя компьютерами и сохраняет их в переменной $sessions:

$sessions = New-PSSession -ComputerName One, Two, Three -Port 5555 -Credential DOMAIN\Administrator

Сессии удаленного взаимодействия закрываются автоматически, когда вы закрываете командную оболочку, но до этого времени они могут занимать память и немного загружать процессор на локальной и удаленной системах. Для того чтобы точно закрыть их, вы можете использовать команду Remove-PSSession:

$sessions | Remove-PSSession

Когда вам нужно вновь открыть сессии, вы можете задействовать команду Invoke-Command:

Invoke-Command -Command {dir} -Session $sessions

Или можете применить Enter-PSSession:

Enter-PSSession -Session $session

Заметьте, что в коде Enter-PSSession только одна сессия удаленного взаимодействия открывается повторно. Переменная индекса 1 сообщает PowerShell, что он должен вновь открыть сессию с компьютером, названным Two (индекс отсчитывается с нулевого значения).

Как мы видим, пользы от удаленного взаимодействия PowerShell очень много. Если вы будете использовать его, вы убедитесь, как сильно он расширит горизонты вашей деятельности.

Дон Джоунз ([email protected]) — технический инструктор по PowerShell (www.windowsitpro.com/go/DonJonesPowerShell), автор более 35 книг. Имеет звание Microsoft MVP

У меня как-то раз возникли проблемы с WinRM на двух серверах.

1. SETSPN
На одном проблема была в том, что SPN записи HTTP/ были зарегистрирована для какой-то «левой» учётной записи пользователя.

Нашёл эти записи командой
setspn -F -Q */

Затем удалил их командами
setspn -D http/. \
setspn -D http/ \

Затем enable-psremoting -force выполнилась успешно.

2. LANGUAGE PACK
А на втором сервере была хитрая проблема якобы с фаерволлом Unable to check the status of the firewall , перерыл кучу сайтов, а решение обнаружил интуитивно основываясь на ответе по поводу установленного Language Pack.

WinRm QuickConfig
WinRM service is already running on this machine.
WSManFault
Message
ProviderFault
WSManFault
Message = Unable to check the status of the firewall.

Error number: -2147024894 0x80070002
The system cannot find the file specified.

В ответе было написно, что данная ошибка лечится удалением дополнительного Language Pack.
Но я поступил иначе. У меня Английская операционка с дополнительным русским language pack. Я просто изменил язык интерфейса на Русский.
Панель управления, Язык и региональные стандарты, Языки и клавиатуры изменил язык интерфейса с англиского на русский.
Выполнил logoff и вошёл снова. Открыл PowerShell и повторил WinRm QuickConfig

PS C:\Windows\system32> winrm qc

Служба WinRM не настроена на разрешение удаленного управления компьютером.
Необходимо внести следующие изменения:

Создайте прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.

Выполнить изменения ? y

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

Создан прослушиватель WinRM на HTTP://* для приема запросов WS-Man на любом из IP-адресов этого компьютера.

Выполнилось успешно, но всё же не достаточно.

Появилась ошибка Access Denied при попытке выполнить команды удалённо на этом сервере с другого компа.

New-PSSession: [] Connecting to remote server failed with the following error message: Access is denied. For more information, see the about_Remote_Troubleshooting Help topic.

Тогда я повторил Enable-PsRemoting

PS C:\Windows\system32> Enable-PsRemoting

Быстрая настройка WinRM
Запуск команды «Set-WSManQuickConfig» для включения на данном компьютере удаленного управления с помощью службы WinRM.
Необходимые действия.
1. Запуск или перезапуск (если уже запущена) службы WinRM.
2. Изменение типа службы WinRM на «автозапуск».
3. Создание прослушивателя для приема запросов на любом IP-адресе.
4. Настройка исключений брандмауэра для трафика службы WS-Management (только для протокола http).

Продолжить?

(значением по умолчанию является «Y»):a
Служба WinRM уже настроена на прием запросов на компьютере.
Служба WinRM уже настроена на разрешение удаленного управления компьютером.

Подтверждение
Вы действительно хотите выполнить это действие?
Выполнение операции «Регистрация конфигурации сеанса» над целевым объектом «Конфигурация сеанса
«Microsoft.PowerShell32» не найдена. Будет выполнена команда «Register-PSSessionConfiguration Microsoft.PowerShell32
-processorarchitecture x86 -force» для создания конфигурации сеанса «Microsoft.PowerShell32». Служба WinRM будет
перезапущена.».
[Y] Да — Y [A] Да для всех — A [N] Нет — N [L] Нет для всех — L [S] Приостановить — S [?] Справка
(значением по умолчанию является «Y»):a

После этого WinRM на этом сервере заработал как надо.

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

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

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

Winrm quickconfig

В том случае, если нужно настроить 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. Следующая команда откроет командную строку, запущенную на удаленной системе:

Winrs –r:computer01 cmd

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

Настройка удаленного взаимодействия в PowerShell (часть 1)

Чтобы обеспечить возможность удаленного взаимодействия с помощью PowerShell, необходимо произвести некоторые настройки. Количество этих настроек зависит от операционной системы, сетевого окружения, требований к безопасности (и еще бог знает чего). Поскольку настроек довольно много, я попробую рассказать о наиболее важных из них. Ну, поехали…

Включение удаленного управления

Для того, чтобы управлять удаленным компьютером, необходимо на этом компьютере удаленное взаимодействие разрешить. Исключение составляет Windows Server 2012, где все возможности удаленного управления включены по умолчанию. Для всех остальных операционных систем надо:

1. Стартовать службу WinRM и поставить ее на автозапуск;
2. Создать прослушиватель (listener), который будет слушать запросы на управление;
3. Включить на файерволе правило, разрешающее трафик WS-Management.

Для настройки одного компьютера проще всего использовать командлет Enable-PSRemoting . Он произведет все необходимые действия, а также зарегистрирует конфигурации сессии по умолчанию. Для того, чтобы подавить запросы на подтверждение, можно добавить параметр -force . Консоль необходимо запустить с правами администратора, иначе будет выдана ошибка.

В доменной среде для настройки PS Remoting можно воспользоваться групповыми политиками.

В разделе Computer Configuration\Policies\Windows Settings\System Services включим политику «Windows Remote Management (WS-Management)». Она задает режим запуска для службы WinRM.

В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включаем политику «Allow automatic configuration of listeners», которая создает прослушиватель на порту 5985 (порт для HTTP по умолчанию). Дополнительно можно указать, с каких IP можно принимать подключения. Если в фильтрации по IP нет необходимости, просто ставим знак *, что означает принимать подключения с любого адреса.

Затем идем в раздел Computer Configuration\Windows Settings\Security Settings\Windows Firewall with Advanced Security\Inbound Rules и создаем новое правило. Выбираем пункт Predefined (Предопределенные правила) и в списке выбираем Windows Remote Management.

Обратите внимание, что можно выбрать два режима работы — стандатный и совместимый. В первом случае будет открыт порт 5985, использующийся WinRM по умолчанию, во втором — порт 80 (для совместимости со старыми версиями WinRM). По умолчанию выбраны оба.

Настройка доверия между компьютерами

При удаленном подключении в PowerShell используется взаимная аутентификация между компьютерами. Это означает, что перед установлением соединения удаленная машина должна подтвердить свою подлинность. Проще говоря, если вы подключаетесь к компьютеру с именем SRV1, то перед установкой соединения он (SRV1) должен вам доказать, что это действительно он, иначе подключение не будет установлено.

Если компьютеры являются членами одного домена, или находятся в разных, но доверяющих друг другу доменах, то взаимная аутентификация будет выполнена доменными службами. Главное, чтобы имя компьютера разрешалось в IP-адрес и соответствовало имени компьютера в Active Directory.

Внимание: при подключении нужно указывать действительные имена компьютеров, т.е. так как они указаны в Active Directory. Если компьютер входит в локальный домен, то можно указать просто имя компьютера, например SRV1 . Для указания имени компьютера из другого домена надо указать полное доменное имя (FQDN) — SRV1.contoso.com . Если же указать IP-адрес, или некоторое другое DNS-имя (например CNAME алиас), то взаимная аутентификация не сработает.

Если же один или оба компьютера не входят в домен, то для взаимной аутентификации есть два варианта: добавить удаленную машину в список доверенных узлов (Trusted Hosts) или использовать SSL.

Trusted Hosts

Добавление компьютера в Trusted Hosts — путь простой, но менее безопасный. Для компьютеров, находящихся в Trusted Hosts взаимная аутентификация фактически отключена. Поэтому пользоваться этим способом стоит с большой осторожностью.

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

Set-Item WSMan:\localhost\Client\TrustedHosts -Value SRV1. contoso.com

При добавлении нескольких компьютеров их имена можно перечислить через запятую. Допускается указывать не только имя, но IP-адрес компьютера. Также поддерживаются символы подстановки. Например, можно добавить в доверенные хосты все компьютеры из домена contoso.com, указав значение *.contoso.com, или вообще всех без исключения:

Set-Item WSMan:\localhost\Client\TrustedHosts -Value *

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

$curr = (Get-Item WSMan:\localhost\Client\TrustedHosts).value
Set-Item WSMan:\localhost\Client\TrustedHosts -Value ″$curr,SRV2.contoso.com″

Ну и посмотреть список доверенных узлов можно командой:

Get-Item WSMan:\localhost\Client\TrustedHosts

Также для добавления в TrustedHosts можно воспользоваться групповой политикой. В разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Client включаем политику «Trusted Hosts» и добавляем имена или IP-адреса компов через запятую. Поддерживаются подстановочные символы.

Примечание: если TrustedHosts сконфигурированы через GPO, то из PS изменить их не удастся. То же касается и всех остальных настроек PS Remoting.

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

Во первых, для использования этого метода, нам нужен цифровой сертификат SSL для машины, к которой мы собираемся подключаться. Получение сертификата — отдельная тема, не будем на ней останавливаться. В тестовой среде я воспользуюсь утилитой Makecert , входяшей в состав Windows SDK, и создам самоподписанный сертификат:

makecert -a sha1 -r -pe -n ″CN=wks8″ -eku 1. 3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp ″Microsoft RSA SChannel Cryptographic Provider″ -sy 12 -m 12 ″C:\myssl.cer″

Эта команда создаст SSL-сертификат сроком на год и поместит его в хранилище сертификатов локального компьютера. Обратите внимание, что сертификат должен быть выдан на то же имя, которое вы будете указывать в команде подключения.

После получения сертификат должен быть добавлен в Trusted Root Authority (доверенные корневые центры сертификации). Для этого открываем сертификат и жмем на кнопку «Установить сертификат».

Запускается мастер импорта сертификатов. Указываем расположение хранилища «Локальный компьютер».

В качестве хранилища выбираем «Доверенные корневые центры сертификации».

Теперь наш сертификат является доверенным. Еще раз открываем его, и на вкладке «Состав» находим отпечаток сертификата (CertificateThumbprint). Копируем его в буфер обмена.

Теперь можно создавать прослушиватель для HTTPS. Открываем консоль PowerShell и вводим команду:

New-WSManInstance winrm/config/listener -SelectorSet @{ Address=′*′; Transport=′HTTPS′ } -ValueSet @{ HostName=′wks8′; CertificateThumbrint=′xxx′}

В поле CertificateThumbrint вставляем отпечаток сертификата, скопированный в предыдущем пункте.

Исключения файерволла Windows (если он включен) для нового прослушивателя необходимо настраивать вручную, автоматически они не создадутся. Поэтому создадим новое правило для входящего трафика по портам TCP 5986 и 443:

New-NetFirewallRule -DisplayName ″Windows Remote Management (HTTPS)″ -Direct Inbound -Protocol TCP -LocalPort 5986,443 -Action Allow -Enabled True

Также для создания правила можно воспользоваться графической оснасткой или утилитой командной строки netsh, кому что больше нравится.

Далее идем на компьютер SRV1, с которого будем подключаться. Поскольку я использую самоподписанный сертификат, то его придется добавить к доверенным корневым сертификатам и на клиенте. Копируем файл сертификата myssl.cer на SRV1 и устанавливаем командой:

certutil -addstore root C:\myssl.cer

Вот и все, настройка закончена. Теперь можно подключаться. Откроем интерактивную сессию на wks8 командой:

Enter-PSSession -ComputerName wks8 -Credential wks8\kirill -UseSSL

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

Отключение проверки

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

В принципе это правильно, но при необходимости проверки можно отменить. Для этого в свойствах сессии есть два параметра:

SkipCACheck — отменяет проверку издателя сертификата;
-SkipCNCheck — отменяет проверку соответствия имени компьютера.

Создать новую сессию с использованием этих параметров можно например вот так:

$option = New-PSSessionOption -SkipCACheck -SkipCNCheck
Enter-PSSession -ComputerName wks8 -SessionOption $option -Credential wks8\kirill -UseSSL

Правда в этом случае теряется смысл SSL-сертификатов, и тогда уж проще пользоваться Thrusted Hosts. Но возможность такая есть, и знать о ней надо.

Дополнительные настройки

Начиная со второй версии, WinRM по умолчанию слушает порт 5985 для HTTP и 5986 для HTTPS. Для совместимости со старыми версиями (или чтобы не открывать дополнительные порты на брандмауэре) можно дополнительно включить прослушиватели на традиционных портах 80 и 443. Для HTTP:

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpListener $true

И для HTTPS:

Set-Item WSMan:\localhost\Service\EnableCompatibilityHttpsListener $true

То же самое можно сделать с помощью групповых политик. Для этого надо в разделе Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management (WinRM)\WinRM Service включить политики «Turn On Compatibility HTTP Listener» и «Turn On Compatibility HTTPS Listener».

Порты по умолчанию можно изменить и указать слушать любой нестандартный порт, например порт 8080:

Set-Item WSMan:\localhost\listener\listener*\port -Value 8080

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

На этом все. Во статьи рассмотрим конфигурации удаленных сессий, создание конечных точек (endpoint), ну и что нибудь еще по мелочи 🙂

Баг с потенциалом червя представляет опасность для серверов WinRM — «Хакер»

В рамках майского «вторника обновлений» компания Microsoft устранила опасный баг в Internet Information Services (IIS), который получил идентификатор CVE-2021-31166. Еще на прошлой неделе многие исследователи и ИБ-компании писали, что данная уязвимость – одна из наиболее серьезных проблем, исправленных в этом месяце (9,8 из 10 баллов по шкале CVSS v3).

Уязвимость связана с повреждением информации в памяти стека протокола HTTP, включенного в во все «свежие» версии Windows. Этот стек используется сервером Windows IIS. Если данный сервер активен, злоумышленник может отправить ему специально подготовленный пакет и выполнить вредоносный код на уровне ядра ОС. Хуже того, Microsoft предупреждала, что уязвимость обладает потенциалом червя, то есть может применяться для создания малвари, самостоятельно распространяющейся с сервера на сервер.

Недавно в открытом доступе был опубликован эксплоит для этой проблемы. К счастью, уязвимость затрагивает только наиболее новые версии ОС: Windows 10 2004 и 20h3, а также Windows Server 2004 и 20h3, которые пока распространены не слишком широко.

Как теперь обнаружил ИБ-исследователь Джим ДеВрис, уязвимость также влияет на устройства под управлением Windows 10 и Widows Server, на которых работает служба WinRM (Windows Remote Management), компонент Windows Hardware Management, который тоже использует уязвимый HTTP. sys.

I finally found time to answer my own question. WinRM *IS* vulnerable. This really expands the number of vulnerable systems, although no one would intentionally put that service on the internet.
— Jim DeVries (@JimDinMN) May 19, 2021

И если рядовые пользователи должны включать WinRM вручную, то на корпоративных эндпоинтах Windows Server WinRM включен по умолчанию, что делает их уязвимыми для атак, если они используют Windows версий 2004 или 20h3.

«Не думаю, что это большой риск для домашних ПК, но, если кто-то скрестит [уязвимость] с червем и программами-вымогателями, в корпоративной среде все это может бурно разрастись», — предупреждает эксперт.

Выводы ДеВриса уже подтверждены аналитиком CERT/CC Уиллом Дорманном, который успешно скомпрометировал систему, используя ранее опубликованный DoS-эксплоит. Также Дорманн обнаружил, что в сети можно найти более 2 000 000 систем с запущенной службой WinRM, хотя далеко не все они уязвимы перед CVE-2021-31166, ведь, как было сказано выше, баг затрагивает лишь Windows 10 и Windows Server версий 2004 и 20h3.

Службы удаленного управления windows winrm не выполняется. Удаленное управление Windows с помощью WinRM

Windows Remote Management — это служба удаленного управления 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):

winrm quickconfig

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

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

winrm set winrm/config/client @{TrustedHosts=«имя или IP-адрес удаленного компьютера»}

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

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

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

winrs

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

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

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

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

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

Winrm quickconfig

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

Winrs –r:computer01 cmd

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

Собственно WinRM (или Windows Remote Management ) и переводится как «удаленное управление Windows» . WinRM – служба удаленного управления для операционных систем Windows . Она входит в состав операционных систем начиная с Vista и Server 2008 , для Windows XP и Server 2003 ее нужно устанавливать отдельно отсюда . WinRM – серверная часть приложения удаленного управления, к которому возможно удаленное подключение с помощью клиента Windows Remote Shell (WinRS).

WinRM основан на службах Web Services for Management (WS-Management) и использует протокол HTTP (порт 80) или HTTPS (443) и запросы SOAP для выполнения работы. Независимо от используемого протокола весь трафик, передаваемый WinRM шифруется (если специально не отключить эту опцию). Для аутентификации по умолчанию используется протокол Kerberos .

В Windows Server 2008 WinRM установлен, но (по соображениям безопасности) по умолчанию не включен. Чтобы проверить, запущен ли WinRM на нашей машине, набираем в командной строке winrm enumerate winrm/config/listener

Если ответа нет, значит WinRM не запущен. Для того, чтобы настроить WinRM на автоматический запуск и разрешить удаленное подключение к компьютеру, набираем команду winrm quickconfig или winrm qc

Чтобы WinRM не спрашивал подтверждения, можно добавить к вызову ключ -quiet . Узнать информацию о более тонкой настройке можно посмотреть встроенную справку WinRM : winrm help config

Ну и отключить WinRM можно с помощью такой команды:
winrm delete winrm/config/listener?IPAdress=*+Transport=HTTP

Также все необходимые настройки можно сделать с помощью групповых политик. Для этого нужно:

Настроить службу WinRM на автоматический запуск
Разрешить подключения на соответствующие порты (80 и 443) в брандмауэре Windows
Настроить элемент групповой политики Конфигурация компьютера\Административные шаблоны\Компоненты Windows\Удаленное управление Windows\Служба удаленного управления Windows\Разрешить автоматическую установку прослушивателей (Computer Configuration\Administrative Templates\Windows Components\Windows Remote Management \WinRM Service\Allow automatic configuration of listeners) . Тут нужно будет указать IP-адреса, с которых разрешаются подключения.

Теперь перейдем непосредственно к использованию. Для подключения к удаленному компьютеру используем утилиту WinRS . WinRS – аббревиатура для Windows Remote Shell (удаленная среда Windows ). С WinRS мы можем делать удаленные запросы на компьютеры, на которых запущен WinRM . Однако имейте ввиду, что на вашей машине также необходимо запускать WinRM для работы с WinRS .

Основным способом использования WinRS является выполнение команд на удаленной машине. Имя компьютера задаётся ключом -r , а после него следует выполняемая команда, например winrs – r : SRV 2 ipconfig / all запускает на удаленном компьютере SRV2 команду ipconfig / all

По умолчанию для коммуникаций используется протокол http , но можно использовать и https : winrs -r:https://SRV2 ipconfig /all

Также можно с помощью WinRS открыть интерактивный сеанс на удалённом компьютере: winrs -r:SRV2 cmd.exe

Эта функция аналогична подключению по telnet , но использование WinRS однозначно лучше с точки зрения безопасности.

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

« true»}

« »}

WinRM set winrm/config/client @{TrustedHosts=« ComputerName»}

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

На компьютере, с которого будем подключаться, вводим:

WinRM set winrm/config/service/auth @{Basic=« true»}

WinRM set winrm/config/client @{TrustedHosts=« »}

WinRM set winrm/config/client @{TrustedHosts= «ComрuterName»}

где ComputerName — компьютер, которым будем управлять.

Затем устанавливаем соедининие с помощью команды:

winrs -r: «ComputerName»: –u: Domain\Username –p: Password cmd.exe

где Domain\Username — учетная запись пользователя с административными правами на удаленном компьютере.

Бывают случаи, когда требуется выполнить какую-либо команду на сервере локально (например, сконфигурировать iSCSI Initiator). Подключаться для этого через Remote Desktop и запускать cmd — неудобно, использовать Telnet — небезопасно, ставить на сервер демона ssh — не… хочется…

Специально для таких запущенных случаев, Microsoft, начиная с Windows Server 2003 R2, снабдила администраторов новым средством управления — Windows Remote Management (WinRM), позволяющим удаленно выполнять команды, используя стандартные средства ОС, и обеспечивая при этом должный уровень безопасности.

Вам даже не придется устанавливать дополнительных программ и компонентов — все, что называется, включено:

Настройка WinRM
В качестве примера я рассмотрю процесс настройки WinRM на Windows Server 2008. Эта процедура никак не отличается от настройки WinRM, например, на Windows Vista или Hyper-V Server.

Проще всего WinRM настроить можно, используя режим быстрой конфигурации, набрав в CMD:
winrm quickconfig
и ответив утвердительно («y «) на вопрос о создании нового объекта-listener»а, прослушающего порт TCP 80, и использующего протокол HTTP для коммуникаций между клиентом и сервером.

И все, сервером можно управлять удаленно, используя команду:
winrs -r:
,где — имя или IP адрес сервера, к которому осуществляется подключение;
— удаленная команда, которую требуется выполнить.

Если клиент и сервер не являются членами одного домена, вам потребуется дополнительно указать имя пользователя из-под которого будет запускаться команда и его пароль:
winrs -r: -u: -p:

А заодно, как советует появившееся сообщение, добавить сервер в список доверенных узлов, либо использовать более надежный протокол для коммуникации (HTTPS).

Для добавления узла в список надежных, выполните на клиенте, с которого планируете подключаться:
winrm set winrm/config/client @{TrustedHosts=» [, ]»}

После настройки вы можете получить информацию о существующих listener»ах с помощью команды:
winrm enumerate winrm/config/listener

Удалить существующий listener можно следующим образом:
winrm delete winrm/config/listener?Address=*+Transport=HTTPS

Настройка WinRM с использованием HTTPS
В ряде случаев вам может потребоваться создать надежный канал для безопасной пересылки команд между клиентом и сервером. Для этого можно использовать HTTPS.

Однако, для создания listener»а с поддержкой HTTPS вам потребуется цифровой сертификат, который можно запросить у доверенного Центра Сертификации, либо воспользоваться различными утилитами по созданию самоподписанных (самозаверенных) сертификатов, например, Makecert, входящей в состав Windows SDK . Скачать Makecert отдельно можно отсюда .

Для создания самоподписанного серитификата выполните следующую команду:
makecert -a sha1 -r -pe -n «CN= » -eku 1.3.6.1.5.5.7.3.1 -ss my -sr localmachine -sky exchange -sp «Microsoft RSA SChannel Cryptographic Provider» -sy 12 -m 12
, где соответствует имени, которое будет использовать клиент при подключении к серверу;
— путь к файлу, куда будет сохранен сертификат с открытым ключем.

Сертификат с закрытым ключем будет создан и помещен в хранилище сертификатов локального компьютера. Добавьте его к доверенным корневым сертификатам:
certutil -addstore root cert.cer

Теперь просмотрите хранилище сертификатов, найдите там требуемый сертификат и запишите его Thumbprint (Cert Hash):
certutil -store my

Наконец, можно приступать к созданию HTTPS listener. Введите команду:
winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=» «;CertificateThumbprint=» «;Port=» «}
,где — имя, которое указывается при обращении к серверу
— Thumbprint, который вы узнали на предыдущем шаге (без пробелов).
— порт, на который будет подключаться клиент (TCP 443 по-умолчанию).

Если на сервере включен брандмауэр Windows, не забудьте добавить правило:
netsh advfirewall firewall add rule name=»allow WinRM on 4443″ protocol=TCP dir=in localport=4443 action=allow

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

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

· Комментариев нет

Введение

Что такое Windows Remote Management (WinRM) (Удаленное управление Windows)?

Windows Remote Management (сокращенно WinRM) – это новая удобная служба удаленного управления для Windows Server 2003 R2, Windows Vista и Windows Server 2008. WinRM — это «серверный» компонент этого приложения удаленного управления, а WinRS (Windows Remote Shell – удаленная среда Windows) – это «клиент» для WinRM, которые запускается на удаленном компьютере, пытаясь удаленно управлять сервером WinRM. Однако должен заметить, что на ОБОИХ компьютерах должен быть установлен и включен WinRM, чтобы WinRS мог работать и получать информацию об удаленной системе. WinRM основан на стандартах Web Services for Management (службы для управления) (WS-Management). Это означает, что WinRM использует протокол HTTP (порт 80) и запросы SOAP для выполнения работы. Это хорошо тем, что запросы HTTP легко пересылать через брандмауэр. Из этого вытекают хорошее и плохое следствия: с одной стороны, так проще будет управлять удаленным компьютером через Internet, но, с другой стороны, злоумышленнику проще удаленно атаковать этот же компьютер. Еще одно небольшое преимущество использования порта 80 в том, что нет необходимости открывать другие порты на сервере, если входящие HTTP соединения уже были разрешены.

Рисунок 1: параметры командной строки WinRM

Как включать и использовать WinRM?

winrm enumerate winrm/config/listener

C:\Users\Administrator> winrm quickconfig WinRM is not set up to allow remote access to this machine for management. The following changes must be made: Create a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. Make these changes ? y WinRM has been updated for remote management. Created a WinRM listener on HTTP://* to accept WS-Man requests to any IP on this machine. C:\Users\Administrator> После настройки quickconfig, я перезапустил команду перечисления со следующими результатами: C:\Users\Administrator> winrm e winrm/config/listener Listener Address = * Transport = HTTP Port = 80 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 10.253.15.98, 127.0.0.1, ::1, fe80::5efe:10.253.15.98%11, fe80::9583:2148:e1ef:6444%10 C:\Users\Administrator>

Теперь я знаю, что WinRM включен.

Кстати, если вы хотите отключить WinRM, нужно использовать такую команду:

winrm delete winrm/config/listener?IPAdress=*+Transport=HTTP

Для использования WinRM все узлы, взаимодействующие с ним, должны быть членами того же домена, что и узел с WinRM. Если в вашем случае это не так, рекомендую ознакомиться с различными сценариями безопасности в статье ‘Remotely managing your Server Core using WinRM and WinRS‘.

Что такое WinRS и как его использовать?

Рисунок 2: параметры командной строки WinRS

Рисунок 3: демонстрация команд WinRS

Итоги

www.windowsnetworking.com

Смотрите также:

Readers Comments (Комментариев нет)

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System … Введение В этой статье из нескольких частей я хочу показать вам процесс, который недавно использовал для перехода с существующей среды Exchange 2003 … Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть… Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations …

WinRM — удалённая работа с PowerShell / Хабр

Итак

вышел Windows Management Framework

для всех ОС, даже для XP.

Для меня там, кроме собственно, PowerShell 2.0, основное это WinRM. В приложении к PowerShell это просто способ выполнять команды на удалённом компе.

Вот как это сделать:
0. Поставить Windows Management Framework Core

1. Для конфигурирования winrm, на той машине, которая будет сервером:
1.1 зайти в cmd.exe (я пытался сделать это из-под ISE, но оно не работает с интерактивными консольными программами)
1.2 запустить winrm qc
1.3 ответить Y на вопрос об изменениях

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

А еще с помощью набора команд *-PSSession возможет такой сценарий. Зайти на удаленную машину, выполнить там длительную операцию, вернуться и сообщить пользователю, что всё сделано.

P.S. Boomburum переслал сообщение от анонимуса:

«Здравствуйте! Требуется помощь, т.к. сам способа решения не нашел ;)). В общем, проблема такая — не знаю как связаться с автором одного из топиков. (конкретно — habrahabr.ru/post/73613/). Данная статья подтолкнула меня на знакомство с сетевыми возможностями powershell. При настройке данной возможности на пк с Windows XP SP3 возникла проблема — выскочила ошибка следующего содержания:
**********************************************************************
PS C:\Documents and Settings\Administrator> winrm qc
WinRM is not set up to receive requests on this machine.
The following changes must be made:

Start the WinRM service.

Make these changes [y/n]? y

WinRM has been updated to receive requests.

WinRM service started.
WSManFault
Message = Access is denied.

Error number: -2147024891 0x80070005
Access is denied.
PS C:\Documents and Settings\Administrator>
**********************************************************************
Я долго-долго искал пути решения данной проблемы в Интернете, но всё никак — ничего путного найти не мог. В общем,
Для решения данной проблемы следует зайти в Пуск->Администрирование ->Локальная политика безопасности ( Local Security Settings — secpol.msc) -> Параметры безопасности (Security option) -> Ищем «Сетевой доступ: модель совместного доступа и безопасности для локальных учетных записей» (Network Access: Sharing and security model for local accounts) -> изменяем политику на «Обычная -…» (Classic -…) -> Перезагружаемся и всё — проблеме конец!

Огромная просьба, отправьте это сообщение автору данного топика, т.к. я не могу этого сделать самостоятельно. Пускай он это разместит, т.к. русскоязычной части населения сети Интернет это очень сильно упростит поиск решения данной проблемы. Проблема довольно широко распространена! Но мною была замечена только на Windows XP. (Все проверялось на виртуальной машине с чистой системой). Заранее огромно спасибо!»

Включаем PowerShell Remoting через групповую политику — UniTec

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

Настройка PowerShell Remoting

1 . Создаем объект групповой политики

Для этого открываем консоль «Управление групповыми политиками» и создаем в ней новый объект групповой политики, в нашем случае это GPO_PowerShell_Remoting и редактируем его.

2 . Включаем Windows Remote Management (WinRM)

Редактируем объект политики GPO_PowerShell_Remoting.
Редактируем политику Разрешить удаленное администрирование сервера средствами WinRM

В свойствах Разрешить удаленное администрирование сервера средствами WinRM, мы включаем саму политику и в поле фильтра IP-адресов мы можем указать, с каких IP можно принимать подключения. В нашем примере мы укажем * , что означает со всех IP адресов.

3 . Настраиваем Windows Firewall (Бранмауэр Windows)

Создаем новое правило в брандмауэре.

Выбираем предопределенное правило для входящего подключения.

Порт 5985, используется WinRM по умолчанию, выбираем.

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

4 . Настройка запуска Windows Remote Service

Задаем режим запуска для службы WinRM.
Для этого редактируем политику Служба удаленного управления Windows (WS-Management)

Задаем свойства для службы WinRM, создаем новое правило.

Выбираем имя службы, действие и на вкладке Восстановление, выбираем правила перезапуска.

5 . Настраиваем

Trusted Hosts (Доверительные отношения)

Редактируем политику Доверенные узлы

В свойствах хххххххххххххххххх

Проверка созданной нами политики GPO_PowerShell_Remoting

Соединяемся с рабочей станцией.

Enter-PSSession win-cm-test2

Troubleshooting — Устранение неполадок

Больше детально можно почитать на сайте Microsoft:
Синтаксис Enter-PSSession

Проверка состояния на клиенте

# Получаем информацию по Listener (Слушатель)
winrm e winrm/config/listener
# Listener_641507880 это мой ID, добиваем табом.
dir WSMan:\localhost\Listener\Listener_

# Выводим информацию по TrustedHosts 
Get-Item WSMan:\localhost\Client\TrustedHosts

Установка и настройка для удаленного управления Windows — приложения Win32

10.09.2021
14 минут на чтение

В этой статье

Для запуска сценариев удаленного управления Windows (WinRM) и инструмента командной строки Winrm для выполнения операций с данными необходимо установить и настроить удаленное управление Windows (WinRM).

Эти элементы также зависят от конфигурации WinRM.

Где установлен WinRM

WinRM автоматически устанавливается со всеми поддерживаемыми в настоящее время версиями операционной системы Windows.

Конфигурация WinRM и IPMI

Эти компоненты поставщика WMI WinRM и интерфейса интеллектуального управления платформой (IPMI) устанавливаются вместе с операционной системой.

Служба WinRM запускается автоматически в Windows Server 2008 и более поздних версиях (в Windows Vista необходимо запускать службу вручную).
По умолчанию прослушиватель WinRM не настроен. Даже если служба WinRM запущена, сообщения протокола WS-Management, запрашивающие данные, не могут быть получены или отправлены.
Брандмауэр подключения к Интернету (ICF) блокирует доступ к портам.

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

  WinRM и WinRM / config / слушатель

Чтобы проверить состояние параметров конфигурации, введите следующую команду.

  winrm получить winrm / config

Быстрая конфигурация по умолчанию

Вы можете включить протокол WS-Management на локальном компьютере и настроить конфигурацию по умолчанию для удаленного управления с помощью команды winrm quickconfig .

Эти операции выполняет команда winrm quickconfig (или сокращенная версия winrm qc ).

Запускает службу WinRM и устанавливает тип запуска службы на автоматический запуск.
Настраивает приемник для портов, которые отправляют и получают сообщения протокола WS-Management с использованием HTTP или HTTPS на любом IP-адресе.
Определяет исключения ICF для службы WinRM и открывает порты для HTTP и HTTPS.

Примечание

Команда winrm quickconfig создает исключение брандмауэра только для текущего профиля пользователя. Если профиль брандмауэра был изменен по какой-либо причине, следует запустить winrm quickconfig , чтобы включить исключение брандмауэра для нового профиля; в противном случае исключение может быть не разрешено.

Чтобы получить информацию о настройке конфигурации, введите winrm help config в командной строке.

Для настройки WinRM с настройками по умолчанию

Введите winrm quickconfig в командной строке.
Если вы работаете не под учетной записью администратора локального компьютера, вам необходимо выбрать Запуск от имени администратора в меню Пуск или использовать команду Runas в командной строке.

Когда инструмент отображает Внести эти изменения [да / нет]? , тип y .

Если конфигурация прошла успешно, отобразятся следующие выходные данные.

  WinRM обновлен для удаленного управления.

Тип службы WinRM изменен на отложенный автоматический запуск.
Служба WinRM запущена.
Создал прослушиватель WinRM на https: // * для приема запросов WS-Man на любой IP-адрес на этом компьютере.

Сохраните настройки по умолчанию для клиентских и серверных компонентов WinRM или измените их.Например, вам может потребоваться добавить определенные удаленные компьютеры в список TrustedHosts конфигурации клиента.
Вы должны настроить список доверенных хостов, если не удается установить взаимную аутентификацию. Kerberos допускает взаимную аутентификацию, но его нельзя использовать в рабочих группах — только в доменах. Лучшая практика при настройке доверенных хостов для рабочей группы — сделать список как можно более ограниченным.
Создайте прослушиватель HTTPS, набрав команду winrm quickconfig -transport: https .Имейте в виду, что вы должны открыть порт 5986 для работы транспорта HTTPS.

Настройки прослушивателя и протокола WS-Management по умолчанию

Чтобы получить конфигурацию прослушивателя, введите в командной строке winrm enumerate winrm / config / listener . Слушатели определяются транспортом (HTTP или HTTPS) и адресом IPv4 или IPv6.

winrm quickconfig создает следующие настройки по умолчанию для слушателя. Вы можете создать более одного слушателя. Для получения дополнительных сведений введите в командной строке winrm help config .

Адрес

Задает адрес, для которого был создан этот слушатель.

Транспорт

Задает транспорт, используемый для отправки и получения запросов и ответов протокола WS-Management. Значение должно быть либо HTTP , либо HTTPS . По умолчанию HTTP .

Порт

Задает TCP-порт, для которого создается этот прослушиватель.

WinRM 2.0: Порт HTTP по умолчанию — 5985.

Имя хоста

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

Включено

Указывает, включен или отключен прослушиватель. Значение по умолчанию — Истинно .

URLPrefix

Задает префикс URL-адреса, по которому принимаются запросы HTTP или HTTPS. Это строка, содержащая только символы a-z, A-Z, 9-0, подчеркивание (_) и косую черту (/). Строка не должна начинаться или заканчиваться косой чертой (/). Например, если имя компьютера — SampleMachine , то клиент WinRM должен указать https: // SampleMachine / <* URLPrefix *> в адресе назначения.Префикс URL-адреса по умолчанию — «wsman».

Сертификат

Задает отпечаток сертификата службы. Это значение представляет собой строку двузначных шестнадцатеричных значений, содержащихся в поле отпечатка сертификата. Эта строка содержит хэш SHA-1 сертификата. Сертификаты используются при проверке подлинности на основе сертификатов клиента. Сертификаты могут быть сопоставлены только с локальными учетными записями пользователей, и они не работают с учетными записями домена.

Прослушивание

Задает адреса IPv4 и IPv6, которые использует прослушиватель.Например: «111.0.0.1, 111.222.333.444, :: 1, 1000: 2000: 2c: 3: c19: 9ec8: a715: 5e24, 3ffe: 8311: ffff: f70f: 0: 5efe: 111.222.333.444, fe80: : 5efe: 111.222.333.444% 8, fe80 :: c19: 9ec8: a715: 5e24% 6 «.

Настройки протокола по умолчанию

Многие параметры конфигурации, такие как MaxEnvelopeSizekb или SoapTraceEnabled , определяют, как компоненты клиента и сервера WinRM взаимодействуют с протоколом WS-Management. В следующем списке описаны доступные параметры конфигурации.

MaxEnvelopeSizekb

Задает максимальное количество данных протокола простого доступа к объектам (SOAP) в килобайтах. По умолчанию 150 килобайт.

Примечание

Поведение не поддерживается, если для параметра MaxEnvelopeSizekb задано значение больше 1039440.

Максимальное время ожидания

Задает максимальный тайм-аут в миллисекундах, который может использоваться для любого запроса, кроме запросов на извлечение. По умолчанию — 60000.

MaxBatchItems

Задает максимальное количество элементов, которые можно использовать в ответе по запросу.По умолчанию 32000.

MaxProviderRequests

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

WinRM 2.0: Этот параметр устарел и установлен только для чтения.

Параметры конфигурации клиента WinRM по умолчанию

Клиентская версия WinRM имеет следующие параметры конфигурации по умолчанию.

NetworkDelayms

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

URLPrefix

Задает префикс URL-адреса, по которому принимаются запросы HTTP или HTTPS. Префикс URL-адреса по умолчанию — «wsman».

AllowUnencrypted

Позволяет клиентскому компьютеру запрашивать незашифрованный трафик. По умолчанию клиентскому компьютеру требуется зашифрованный сетевой трафик, и этот параметр равен Ложь .

Базовый

Позволяет клиентскому компьютеру использовать обычную проверку подлинности. Обычная проверка подлинности — это схема, в которой имя пользователя и пароль отправляются в виде открытого текста на сервер или прокси.Этот метод является наименее безопасным методом аутентификации. По умолчанию True .

Дайджест

Позволяет клиенту использовать дайджест-аутентификацию. Дайджест-проверка подлинности — это схема запрос-ответ, в которой для запроса используется указанная сервером строка данных. Только клиентский компьютер может инициировать дайджест-запрос проверки подлинности. Клиентский компьютер отправляет запрос на сервер для проверки подлинности и получает от сервера строку токена. Затем клиентский компьютер отправляет запрос ресурса, включая имя пользователя и криптографический хэш пароля в сочетании со строкой токена.Дайджест-проверка подлинности поддерживается для HTTP и HTTPS. Клиентские сценарии и приложения WinRM Shell могут указывать дайджест-аутентификацию, но служба WinRM не принимает дайджест-аутентификацию. По умолчанию True .

Примечание

Дайджест-проверка подлинности по HTTP не считается безопасной.

Сертификат

Позволяет клиенту использовать проверку подлинности на основе сертификата клиента. Аутентификация на основе сертификатов — это схема, в которой сервер аутентифицирует клиента, идентифицированного сертификатом X509.По умолчанию True .

Kerberos

Позволяет клиенту использовать проверку подлинности Kerberos. Проверка подлинности Kerberos — это схема, в которой клиент и сервер взаимно проверяют подлинность с помощью сертификатов Kerberos. По умолчанию True .

переговоры

Позволяет клиенту использовать проверку подлинности с согласованием. Аутентификация с согласованием — это схема, в которой клиент отправляет запрос на сервер для аутентификации. Сервер определяет, использовать ли протокол Kerberos или NTLM.Протокол Kerberos выбран для аутентификации учетной записи домена, а NTLM выбран для учетных записей локальных компьютеров. Имя пользователя должно быть указано в формате домен \ имя_пользователя для пользователя домена. Имя пользователя должно быть указано в формате «имя_сервера \ имя_пользователя» для локального пользователя на серверном компьютере. По умолчанию True .

CredSSP

Позволяет клиенту использовать аутентификацию поставщика поддержки безопасности учетных данных (CredSSP). CredSSP позволяет приложению делегировать учетные данные пользователя с клиентского компьютера на целевой сервер.По умолчанию Ложь .

Порты по умолчанию

Задает порты, которые клиент будет использовать для HTTP или HTTPS.

WinRM 2.0: Порт HTTP по умолчанию — 5985, порт HTTPS по умолчанию — 5986.

TrustedHosts

Задает список доверенных удаленных компьютеров. В этот список следует добавить другие компьютеры в рабочей группе или компьютеры в другом домене.

Примечание

Компьютеры в списке TrustedHosts не аутентифицированы.Клиент может отправлять учетные данные на эти компьютеры.

Если для TrustedHost указан IPv6-адрес, он должен быть заключен в квадратные скобки, как показано следующей служебной командой winrm: winrm set winrm / config / client '@ {TrustedHosts = "[0: 0: 0: 0 : 0: 0: 0: 0] "} '.

Для получения дополнительной информации о том, как добавлять компьютеры в список TrustedHosts, введите winrm help config .

Параметры конфигурации службы WinRM по умолчанию

Служебная версия WinRM имеет следующие параметры конфигурации по умолчанию.

Корень SDDL

Задает дескриптор безопасности, который управляет удаленным доступом к слушателю. Значение по умолчанию — «O: NSG: BAD: P (A ;; GA ;;; BA) (A ;; GR ;;; ER) S: P (AU; FA; GA ;;; WD) (AU; SA; GWGX ;;; WD) «.

Максимальное количество одновременных операций

Максимальное количество одновременных операций. По умолчанию — 100.

WinRM 2.0: Параметр MaxConcurrentOperations устарел и установлен только для чтения. Этот параметр был заменен на MaxConcurrentOperationsPerUser.

MaxConcurrentOperationsPerUser

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

EnumerationTimeoutms

Задает тайм-аут простоя в миллисекундах между сообщениями Pull. По умолчанию — 60000.

MaxConnections

Задает максимальное количество активных запросов, которые служба может обрабатывать одновременно. По умолчанию — 300.

WinRM 2.0: По умолчанию 25.

MaxPacketRetrievalTimeSeconds

Задает максимальное время в секундах, которое требуется службе WinRM для получения пакета. По умолчанию 120 секунд.

AllowUnencrypted

Позволяет клиентскому компьютеру запрашивать незашифрованный трафик. По умолчанию Ложь .

Базовый

Позволяет службе WinRM использовать обычную проверку подлинности. По умолчанию Ложь .

Сертификат

Позволяет службе WinRM использовать проверку подлинности на основе сертификата клиента.По умолчанию Ложь .

Kerberos

Разрешает службе WinRM использовать проверку подлинности Kerberos. По умолчанию True .

переговоры

Позволяет службе WinRM использовать проверку подлинности с согласованием. По умолчанию True .

CredSSP

Позволяет службе WinRM использовать аутентификацию поставщика поддержки безопасности учетных данных (CredSSP). По умолчанию Ложь .

Cbt Уровень закалки

Устанавливает политику требований к токену привязки канала в запросах аутентификации.По умолчанию — Relaxed .

Порты по умолчанию

Задает порты, которые служба WinRM будет использовать для HTTP или HTTPS.

WinRM 2.0: Порт HTTP по умолчанию — 5985, порт HTTPS по умолчанию — 5986.

IPv4Filter и IPv6Filter

Задает адреса IPv4 или IPv6, которые могут использовать слушатели. Значения по умолчанию: IPv4Filter = * и IPv6Filter = *.

IPv4: Строка литерала IPv4 состоит из четырех десятичных чисел, разделенных точками, каждое в диапазоне от 0 до 255.Например: 192.168.0.0.

IPv6: Строка литерала IPv6 заключена в скобки и содержит шестнадцатеричные числа, разделенные двоеточиями. Например: [:: 1] или [3ffe: ffff :: 6ECB: 0101].

EnableCompatibilityHttpListener

Указывает, включен ли прослушиватель HTTP совместимости. Если этот параметр равен True , то слушатель будет прослушивать порт 80 в дополнение к порту 5985. По умолчанию False .

ВключитьСовместимость httpsListener

Указывает, включен ли прослушиватель HTTPS совместимости.Если этот параметр равен True , то слушатель будет прослушивать порт 443 в дополнение к порту 5986. По умолчанию False .

Параметры конфигурации Winrs по умолчанию

winrm quickconfig также настраивает параметры Winrs по умолчанию.

AllowRemoteShellAccess

Разрешает доступ к удаленным оболочкам. Если вы установите для этого параметра значение False , то новые подключения удаленной оболочки будут отклонены сервером. По умолчанию True .

Таймаут простоя

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

WinRM 2.0: Значение по умолчанию — 180000. Минимальное значение — 60000. Установка этого значения ниже 60000 не повлияет на тайм-аут.

MaxConcurrentUsers

Задает максимальное количество пользователей, которые могут одновременно выполнять удаленные операции на одном компьютере через удаленную оболочку.Новые подключения к удаленной оболочке будут отклонены, если они превышают указанный предел. По умолчанию — 5.

MaxShellRunTime

Задает максимальное время в миллисекундах, в течение которого удаленной команде или сценарию разрешено выполнение. По умолчанию — 28800000.

WinRM 2.0: Для параметра MaxShellRunTime задано значение только для чтения. Изменение значения MaxShellRunTime не повлияет на удаленные оболочки.

MaxProcessesPerShell

Задает максимальное количество процессов, которые разрешено запускать любой операции оболочки.Значение 0 допускает неограниченное количество процессов. По умолчанию 15.

MaxMemoryPerShellMB

Задает максимальный объем памяти, выделяемой для каждой оболочки, включая дочерние процессы оболочки. По умолчанию 150 МБ.

MaxShellsPerUser

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

Настройка WinRM с помощью групповой политики

Используйте редактор групповой политики для настройки Windows Remote Shell и WinRM для компьютеров в вашем предприятии.

Для настройки с помощью групповой политики

Откройте окно командной строки от имени администратора.
В командной строке введите gpedit.msc . Откроется окно редактора объектов групповой политики .
Найдите Windows Remote Management и Windows Remote Shell Group Policy Objects (GPO) в Computer Configuration \ Administrative Templates \ Windows Components .
На вкладке Extended выберите параметр, чтобы просмотреть описание. Дважды щелкните параметр, чтобы отредактировать его.

Брандмауэр Windows и порты WinRM 2.0

Начиная с WinRM 2.0, портами прослушивателя по умолчанию, настроенными с помощью Winrm quickconfig , являются порт 5985 для транспорта HTTP и порт 5986 для HTTPS.Прослушиватели WinRM можно настроить на любой произвольный порт.

Если компьютер обновлен до WinRM 2.0, ранее настроенные прослушиватели переносятся и по-прежнему получают трафик.

Замечания по установке и настройке WinRM

WinRM не зависит от какой-либо другой службы, кроме WinHttp. Если на том же компьютере установлена служба IIS Admin, вы можете увидеть сообщения, указывающие, что WinRM не может быть загружен до Internet Information Services (IIS). Однако на самом деле WinRM не зависит от IIS — эти сообщения появляются потому, что порядок загрузки гарантирует, что служба IIS запускается до службы HTTP.WinRM требует, чтобы была зарегистрирована WinHTTP.dll .

Если на компьютере установлен клиент брандмауэра ISA2004, это может привести к тому, что клиент веб-служб для управления (WS-Management) перестанет отвечать. Чтобы избежать этой проблемы, установите ISA2004 Firewall SP1.

Если две службы прослушивания с разными IP-адресами настроены с одним и тем же номером порта и именем компьютера, то WinRM прослушивает или принимает сообщения только по одному адресу. Это связано с тем, что префиксы URL-адресов, используемые протоколом WS-Management, одинаковы.

Драйвер IPMI и примечания по установке поставщика

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

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

Если ваша система не обнаруживает BMC автоматически и не устанавливает драйвер, но BMC был обнаружен в процессе установки, вы должны создать устройство BMC. Для этого введите в командной строке следующую команду: Rundll32 ipmisetp.dll, AddTheDevice . После выполнения этой команды создается устройство IPMI, которое отображается в диспетчере устройств.Если вы удалите компонент «Управление оборудованием», устройство будет удалено.

Для получения дополнительной информации см. Введение в управление оборудованием.

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

Примечания к настройке подключаемого модуля WMI

Начиная с Windows 8 и Windows Server 2012, подключаемые модули WMI имеют собственные конфигурации безопасности.Чтобы обычный или опытный (не администратор) пользователь мог использовать подключаемый модуль WMI , вам необходимо разрешить доступ для этого пользователя после настройки прослушивателя. Во-первых, вы должны настроить пользователя для удаленного доступа к WMI, выполнив один из следующих шагов.

Запустите lusrmgr.msc , чтобы добавить пользователя в группу WinRMRemoteWMIUsers__ в окне Локальные пользователи и группы или
используйте инструмент командной строки winrm для настройки дескриптора безопасности для пространства имен подключаемого модуля WMI следующим образом: winrm configSDDL http: // schemas.microsoft.com/wbem/wsman/1/wmi/ WmiNamespace .

Когда появится пользовательский интерфейс, добавьте пользователя.

После настройки пользователя для удаленного доступа к WMI необходимо настроить WMI , чтобы разрешить пользователю доступ к подключаемому модулю. Для этого запустите wmimgmt.msc , чтобы изменить защиту WMI для пространства имен, к которому будет осуществляться доступ в окне WMI Control .

Большинство классов WMI для управления находятся в пространстве имен root \ cimv2 .

Удаленное управление Windows — приложения Win32

10.09.2021
2 минуты на чтение

В этой статье

Что такое WinRM?

Windows Remote Management (WinRM) — это реализация Microsoft WS-Management Protocol, стандартного протокола SOAP, ориентированного на брандмауэр, который позволяет аппаратному обеспечению и операционным системам от разных поставщиков взаимодействовать друг с другом.

Спецификация протокола WS-Management предоставляет системам общий способ доступа и обмена управляющей информацией в ИТ-инфраструктуре. WinRM и Intelligent Platform Management Interface (IPMI) вместе со сборщиком событий являются компонентами функций управления оборудованием Windows.

Где я могу использовать WinRM?

Вы можете использовать объекты сценариев WinRM, средство командной строки WinRM или средство командной строки Windows Remote Shell WinRS для получения данных управления с локальных и удаленных компьютеров, на которых могут быть установлены контроллеры управления базовой платой (BMC) .Если на компьютере установлена операционная система Windows, включающая WinRM, данные управления предоставляются инструментарием управления Windows (WMI).

Вы также можете получить данные об оборудовании и системе из реализаций протокола WS-Management, работающих в операционных системах, отличных от Windows, на вашем предприятии. WinRM устанавливает сеанс с удаленным компьютером через протокол WS-Management на основе SOAP, а не через DCOM, как это делает WMI. Данные, возвращаемые протоколу WS-Management, форматируются в XML, а не в виде объектов.

Поставщик WMI интерфейса интеллектуального управления платформой (IPMI) — это стандартный поставщик WMI с классами, которые получают данные датчиков BMC с компьютеров с соответствующим оборудованием. Доступ к данным IPMI можно получить с помощью API сценариев WinRM, сценариев WMI или COM API.

Для кого это?

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

Требования к времени выполнения

WinRM является частью операционной системы. Однако для получения данных с удаленных компьютеров необходимо настроить прослушиватель WinRM . Дополнительные сведения см. В разделе «Установка и настройка удаленного управления Windows». Если BMC обнаруживается при запуске системы, то загружается провайдер IPMI; в противном случае объекты сценариев WinRM и средство командной строки WinRM по-прежнему доступны.

Узнать больше

Об удаленном управлении Windows

Ссылка на общедоступную спецификацию протокола WS-Management, архитектуру WinRM, связь с WMI, управление оборудованием с поставщиком IPMI, настройку и установку.

Использование удаленного управления Windows

Начало работы с API сценариев WinRM и управлением оборудованием.

Справочник по удаленному управлению Windows

Список интерфейсов сценариев, определенных Microsoft Web Services for Management (WS-Management) Automation, и определения классов классов WMI, созданных поставщиком IPMI, и классов, которые обмениваются данными с драйвером IPMI для получения данных контроллера управления основной платой (BMC).

Как включить WinRM на компьютерах с Windows — ежедневно изучать ИТ и DevOps

В этом сообщении блога я покажу вам, как включить WinRM на компьютерах с Windows (10 и серверах), и расскажу вам немного о WinRM.

WinRM

Прежде чем мы углубимся в технические детали, давайте разберемся, что такое WinRM. WinRM — это платформа удаленного управления, встроенная в операционные системы Windows и основанная на .NET и PowerShell.

По умолчанию WinRM включен на Windows Server, но не на компьютерах с Windows 10, что означает, что вам необходимо включить его, как вы скоро увидите, как это сделать.

Зачем нужен WinRM

WinRM может помочь нам, управлять машинами под управлением Windows с помощью удаленного командлета PowerShell без RDP или входить в систему на удаленном компьютере.Этот метод позволяет администраторам управлять несколькими компьютерами с помощью сценариев и командлетов.

Включить WinRM

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

 Enable-PSRemoting -force

Важно отметить, что вы не находитесь в среде на основе Active Directory и ваш компьютер с Windows 10 не присоединен к домену, вам необходимо добавить компьютер, с которого вы собираетесь подключиться, к доверенному узлу компьютера с Windows 10.пожалуйста, посетите это сообщение в блоге о том, как добавить машину в список доверенных хостов.

Включение WinRM с помощью групповой политики

Вышеупомянутый вариант отлично подходит, если у вас есть один компьютер с Windows 10, на котором необходимо включить WinRM, но что, если у вас есть 50 компьютеров с Windows 10 в среде, присоединенной к домену? вам нужно будет использовать групповую политику. Чтобы использовать GPO, создайте новый или отредактируйте существующий, измените следующие параметры и установите для WInRM значение Enabled.

 Конфигурация компьютера> Политики> Административные шаблоны> Компоненты Windows> Удаленное управление Windows (WinRM)> Служба WinRM> Разрешить удаленное управление сервером через WinRM

Не забудьте применить GPO к OU, в котором находятся все ваши компьютеры с Windows 10.После применения в течение 30 минут все ваши хосты получат политику. В этом случае нет необходимости изменять список доверенных хостов.

портов WinRm по умолчанию и как их изменить

WinRM и удаленное взаимодействие PowerShell — важная функция, необходимая для управления удаленными компьютерами с Windows. Как и другие службы, WinRM прослушивает определенные порты при определенных обстоятельствах. В этом руководстве вы узнаете об этих портах WinRM и даже о том, как их изменить при необходимости.

Связано: PowerShell Remoting: The Ultimate Guide

Слушатель WinRM

Одна из наиболее важных частей WInRM (и портов, на которых он работает) — это прослушиватель WinRM.

Слушатель WinRM по своей сути является веб-сервером. Он взаимодействует с HTTP и HTTPS, а в дни до Windows 7 он даже использовал по умолчанию тот же порт 80 и порт 443, что и большинство веб-серверов.

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

Слушатель WinRm может прослушивать двумя разными способами; HTTP или HTTPS. Порт WinRM для HTTP — 5985, а порт WinRm для HTTPS — 5986 по умолчанию.

HTTP — Порт 5985
HTTPS — Порт 5986

Связано: PowerShell Remoting: The Ultimate Guide

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

И если вы не добавите правило брандмауэра при изменении порта, вы получите такое же сообщение, даже если предоставите порт, подобный этому.

Изменение портов WinRM

Хотя Microsoft рекомендует использовать порты прослушивания по умолчанию для совместимости и простоты использования, вы можете изменить их.Это может быть полезно в случаях, когда возникает конфликт с портами по умолчанию или ограничение брандмауэра, блокирующее использование этих портов.

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

Ошибка подключения WinRM из-за неправильного порта

Если да, то пора сменить порт WinRM на стороне сервера!

Чтобы изменить порты WinRm, вам сначала нужно выяснить, есть ли у вас уже служба, прослушивающая эти порты.

Отслеживание существующих подключений

Самый простой способ узнать, какие порты используются на компьютере с Windows, — это использовать инструмент netstat . Netstat проверяет все активные порты в вашей системе и, если они активны, возвращает исходный и целевой IP-адрес и используемый порт.

Чтобы отследить порты прослушивания перед изменением сообщений WinRm, запустите netstat -aon . Коммутаторы -aon :

показать все активные соединения ( a )
показать идентификатор процесса для процесса, который открыл соединение ( o )
не пытаться разрешить какие-либо DNS-имена IP-адресов назначения ( n )

Выполняется netstat для поиска прослушивающих соединений

Если веб-сервер, например, прослушивает порт 80, вы увидите строку, в которой локальный адрес заканчивается на : 80 в столбце Локальный адрес .В этой строке вы увидите PID или идентификатор процесса, который использует соединение.

Как только вы узнаете PID, вы можете ссылаться на PID, чтобы найти имя процесса, используя что-то вроде командлета PowerShell Get-Process .

Запуск Get-Process для поиска имени процесса

Хотя в этом случае, как вы можете видеть выше, имя процесса просто System . Это означает, что процесс сильно интегрирован в ОС и, вероятно, встроен в Windows.

Настройка портов совместимости с WinRM

WinRM имеет функцию, называемую портами совместимости .Порты совместимости существуют для обратной совместимости с некоторыми устаревшими системами, которые работают только на портах 80 для HTTP и 443 для HTTPS. Если вам нужно изменить WinRm для прослушивания этих портов, включите прослушиватели совместимости.

Как только вы узнаете, что у вас больше ничего не работает на портах 80 и 443, настройте прослушиватели WSMan на использование портов совместимости (80 для HTTP и 443 для HTTPS).

  Set-Item WSMan: \ localhost \ Service \ EnableCompatibilityHttpListener -Value $ true
 Set-Item WSMan: \ localhost \ Service \ EnableCompatibilityHttpsListener -Value $ true

Настройка WinRM для прослушивания на любом порту

Если по какой-то причине вам нужно настроить WinRM для прослушивания нестандартного порта, вы тоже можете это сделать.Для этого:

Найдите имя слушателя. Это можно сделать, перечислив все прослушиватели WinRM с помощью командлета Get-Item . Приведенная ниже команда выводит список всех ( * ) прослушивателей, установленных в настоящее время.

  Get-Item WSMan: \ localhost \ Listener *

Получение всех существующих слушателей WinRm

2. Затем, используя имя слушателя, показанное выше, настройте каждый слушатель, используя Set-Item , указав путь к слушателю и номер порта, на который его нужно изменить.

  Set-Item WSMan: \ localhost \ Listener \\ Port -Value

3. На данный момент прослушиватели WinRM прослушивают правильные порты, брандмауэр Windows, вероятно, отклоняет любые удаленные подключения к этим портам. Вам нужно открыть эти порты. Для этого выполните следующую команду. New-NetFirewallRule ниже создает правило брандмауэра Windows, разрешающее все входящие TCP-подключения к настраиваемому порту.

  $ FirewallParam = @ {
     DisplayName = 'Пользовательское правило порта WinRM'
     Direction = 'Inbound'
     LocalPort =
     Протокол = 'TCP'
     Действие = 'Разрешить'
     Программа = 'Система'
 }
 Новый NetFirewallRule @FirewallParam

Связано: Отключить брандмауэр Windows: откройте для себя множество способов

Если у вас , а не , открыли соответствующий порт брандмауэра Windows, вы получите такое сообщение при попытке подключения:

Ошибка подключения WinRM из-за брандмауэра Windows

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

Теперь, когда вы успешно установили и настроили WinRM на сервере WinRM, необходимо протестировать соединение с клиентом WinRM.Для этого требуется всего один дополнительный параметр; Порт .

Используя любую из команд PSRemoting, например Invoke-Command или Enter-PSSession , укажите параметр Port и порт, настроенный для успешного установления соединения.

  Enter-PSSession -ComputerName  -Port 1111

Успешное соединение WinRm

Связано: Invoke-Command: лучший способ запуска удаленного кода

Как включить WinRM (удаленное управление окнами)

Если вы что-нибудь знаете о PDQ.com, вы знаете, что мы в восторге от инструментов, которые делают нашу жизнь проще. Вот почему мы такие большие поклонники PowerShell. Насколько мы большие фанаты? Мы достаточно большие поклонники, чтобы добавить в наши продукты функции командной строки. Мы достаточно большие поклонники, чтобы добавить сканер PowerShell прямо в PDQ Inventory. Мы достаточно большие поклонники, чтобы иметь специальные видео и сообщения в блогах о PowerShell. Черт возьми, мы даже носим футболки PowerShell.

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

Не удается подключиться к серверу CIM

Во время написания моего недавнего сообщения в блоге Что такое PowerShell-эквивалент IPConfig , я столкнулся с проблемой при попытке запустить простой однострочный сценарий.

  Get-NetIPConfiguration -Computer «имя-компьютера»

Запуск Get-NetIPConfiguration сам по себе локально на моем компьютере работал отлично, но выполнение этой команды на удаленном компьютере завершилось ошибкой из-за следующей ошибки.

«Get-NetCompartment: имя-компьютера: не удается подключиться к серверу CIM. Клиент не может подключиться к месту назначения, указанному в запросе … »

Если вы хотите увидеть очень непреднамеренный, но идеальный пример этой ошибки в виде видео, посмотрите наше видео на YouTube, посвященное IPConfig в PowerShell .

К счастью, PowerShell довольно хорошо дает нам подробные сообщения об ошибках (хотелось бы сказать то же самое о Windows). Если вы продолжите читать сообщение, оно фактически дает нам решение нашей проблемы.

«См. Журналы и документацию для службы WS-Management, работающей в месте назначения, чаще всего IIS или WinRM. Если местом назначения является служба WinRM, выполните следующую команду в месте назначения, чтобы проанализировать и настроить службу WinRM: «winrm quickconfig».”

Поскольку я работал над недавно построенной лабораторией, неработающая служба WinRM (Windows Remote Management) определенно была возможностью, на которую стоит обратить внимание. PowerShell даже был достаточно любезен, чтобы дать мне команду «winrm quickconfig», чтобы проверить, нужно ли настраивать службу WinRM.

Настройка удаленного управления Windows с помощью WinRM Quickconfig

Команда «winrm quickconfig» — отличный способ включить удаленное управление Windows, если у вас есть только несколько компьютеров, на которых нужно включить службу.Команду нужно будет запустить локально или удаленно через PSEXEC. Вот что происходит, когда вы запускаете команду на компьютере, на котором не был настроен WinRM.

Поскольку служба еще не настроена, команда спросит вас, хотите ли вы начать процесс настройки. Для начала введите «y» и нажмите Enter.

После запуска службы вам будет предложено включить исключение брандмауэра WinRM. Введите «y» и нажмите Enter, чтобы продолжить.

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

Включение WinRM с помощью групповой политики

Если у вас есть сотни или даже тысячи компьютеров, на которых необходимо включить WinRM, групповая политика — отличный вариант. С помощью групповой политики вы можете включить WinRM, запустить службу автоматически и установить правила брандмауэра.

Откройте консоль управления групповой политикой
Щелкните правой кнопкой мыши подразделение, к которому нужно применить объект групповой политики, и выберите Создать объект групповой политики в этом домене и связать его здесь…
Назовите политику Включите WinRM и нажмите ОК
Щелкните правой кнопкой мыши новый объект групповой политики и выберите Изменить
Разверните Конфигурация компьютера> Политики> Административные шаблоны> Компоненты Windows> Удаленное управление Windows (WinRM)> Служба WinRM.
Найдите параметр Разрешить удаленное управление сервером через WinRM и дважды щелкните его.
Выберите Включить
Для фильтра IPv4 и IPv6 вы можете указать диапазон IP-адресов или использовать звездочку * , чтобы разрешить все IP-адреса. По завершении нажмите ОК.
Затем мы установим автоматический запуск службы WinRM. Перейдите к Computer Configurations> Preferences> Control Panel Settings
Щелкните правой кнопкой мыши в окне Services и выберите New> Service
Изменить Startup на Automatic (Delayed Start)
Нажмите кнопку с многоточием с тремя точками рядом с названием службы.
Найдите и выберите имя службы WinRM
Выберите Запустить службу в меню действий службы и затем нажмите Применить и ОК
Наконец, нам нужно настроить правила брандмауэра. Перейдите к Computer Configuration> Policies> Windows Settings> Security Settings> Windows Firewall with Advanced Security> Windows Firewall with Advanced Security
Щелкните правой кнопкой мыши Входящие правила и выберите Новое правило…
Выбрать Предопределенный и выберите Удаленное управление Windows из раскрывающегося меню, затем нажмите Далее
Снимите флажок с правила общедоступного профиля
Нажмите Далее
Выберите Разрешить подключение и нажмите Готово

Поздравляем! Как только все ваши компьютеры применит новые параметры групповой политики, ваша среда будет готова для удаленного управления Windows.

Включение WinRM с помощью PDQ Deploy

Если групповая политика не подходит для вашей среды, вы можете использовать PDQ Deploy, чтобы распространить команду «winrm quickconfig» на все ваши компьютеры, и мы будем использовать «-quiet» », Чтобы обеспечить автоматическую установку без вмешательства пользователя.

В PDQ Deploy щелкните New Package
Введите имя для вашего пакета, например, Включить WinRM
Нажмите Новый шаг> PowerShell
Добавьте команду winrm quickconfig -quiet
Нажмите 41 Сохранить 41

Вот и все! Теперь вы можете развернуть этот пакет на любых компьютерах, на которых должен быть включен WinRM.

Заключение

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

Если вы ищете другие способы облегчить вашу работу, ознакомьтесь с PDQ Deploy и Inventory . PDQ Deploy and Inventory поможет вам автоматизировать процессы управления исправлениями.Мы сделаем всю работу, и мы предоставим вам всю заслугу. Попробуйте PDQ Deploy and Inventory бесплатно с 14-дневной пробной версией .

Как установить тип запуска службы WinRM

Удаленное взаимодействие Windows PowerShell зависит от Windows Remote Служба управления (WinRM). Служба должна быть запущена для поддержки удаленные команды.

В Windows Server 2003, Windows Server 2008 и Windows Server 2008 R2, тип запуска удаленного управления Windows (WinRM) сервис автоматический.Однако по умолчанию в Windows XP, Windows В Vista и Windows 7 служба WinRM отключена, и вы необходимо изменить тип запуска на Автоматический.

Если вы пытаетесь установить удаленное соединение и WinRM служба не запущена, Windows PowerShell отображает следующее сообщение об ошибке.

	Копировать код
ОШИБКА: ОТКАЗАНО В ДОСТУПЕ

Чтобы просмотреть тип запуска WinRM сервис

Чтобы просмотреть тип запуска службы WinRM, используйте Командлет Get-WmiObject с объектом Win32_Service .Объект, который командлет Get-Service return не включает тип запуска службы.

Следующая команда получает тип запуска Служба WinRM на компьютерах Server01 и Server02. Стартап Тип появляется в значении свойства StartMode объект, который Get-WmiObject возвращается.

	Копировать код
C: \ PS> get-wmiobject win32_service -filter "name = 'WinRM'" -computername Server01, Server02 ExitCode: 0 Имя: WinRM Идентификатор процесса: 848 StartMode: Авто Состояние: Бег Статус: ОК ExitCode: 0 Имя: WinRM Идентификатор процесса: 1308 StartMode: Авто Состояние: Бег Статус: ОК

Копировать код

C: \ PS> get-wmiobject win32_service -filter "name = 'WinRM'" -computername Server01, Server02

ExitCode: 0
Имя: WinRM
Идентификатор процесса: 848
StartMode: Авто
Состояние: Бег
Статус: ОК

ExitCode: 0
Имя: WinRM
Идентификатор процесса: 1308
StartMode: Авто
Состояние: Бег
Статус: ОК

Чтобы установить тип запуска WinRM сервис

Чтобы установить тип запуска службы WinRM на на удаленном компьютере используйте командлет Set-Service.Следующая команда устанавливает тип запуска компьютеров, которые перечислены в значении параметра ComputerName .
Копировать код
set-service WinRM -computername имя-компьютера -startuptype Автоматически

	Копировать код
set-service WinRM -computername имя-компьютера -startuptype Автоматически

Для установки типа запуска большого количества компьютеры

Создайте файл.txt или .csv с именами компьютеров.
Используйте Get-Content или Импорт-CSV командлеты, чтобы получить имена компьютеров из файла, а затем назначить их в переменную. Например, следующая команда получает имена компьютеров из файла Servers.txt и сохраняет их в переменная $ servers.
Копировать код
$ servers = серверы get-content.текст
Используйте командлет Set-Service для установки типа запуска службы WinRM на всех компьютеры в переменной $ servers.
Копировать код
set-service WinRM -computername $ servers -startuptype Автоматически

	Копировать код
$ servers = серверы get-content.текст

	Копировать код
set-service WinRM -computername $ servers -startuptype Автоматически

См. Также

Проблема WINRM — служба WinRM не может получать запросы WS-Management ~ Tech Blog

Проблема WINRM — служба WinRM не может получать запросы WS-Management

Здравствуйте,

Я столкнулся со сценарием, когда служба WinRM не может получать запросы WS-Management, а средство просмотра событий заполняется событием ошибки 10150 и источником: WinRM.

Хмммм, что нам теперь делать ???

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

winrm quickconfig

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

winrm enum winrm / config / listener
=============================== Listener Address = * Transport = HTTP Port = 5985 Hostname Enabled = true URLPrefix = wsman CertificateThumbprint ListeningOn = 127.0.0.1, 172.22.13.227, :: 1, fe80 :: 5efe: 172.22.13.227% 12, fe 80 :: 8cf: d5f2: 1fab: b2cd% 11 ====== ==================== Я получил приведенный выше вывод, который показывает нам, что WINRM прослушивает успешно. Чтобы понять, в чем именно заключается проблема, я обратился к исходному серверу, на котором возникла проблема. Я инициировал следующую команду, чтобы проверить слушателя. winrm enum winrm / config / listener ======================= = Слушатель [Source = «GPO»] Адрес = * Транспорт = HTTP Порт = 5985 Имя хоста Включено = правда URLPrefix = wsman Сертификат ListeningOn = null ============================ Я получил странный вывод, который говорит, что он слушает нулевой.Теперь я проверил, как настроен этот WinRM, когда я раскопал причину, я узнал, что он настроен с использованием GPO. Теперь я инициировал RSOP на этом сервере и заметил, что WinRM устанавливает «Разрешить автоматическую настройку слушателей» включен. Пожалуйста, посмотрите на мероприятие ниже. И затем инициировал gpresult / v / scope computer , и когда я проверил результат и узнал, что он фильтруется, а значение IPv4: 0,0 — это то, что его не слушает. Теперь вернемся к групповой политике и вместо фильтра IPv4 я присвоил звездочке символ «*» и принудительно обновил групповую политику на сервере. Это сотворило для меня волшебство, теперь служба WinRM снова прослушивает все IP-адреса. Размещено в Microsoft Windows .No related posts.