Настройка удаленного взаимодействия в 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 и 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 , например:

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 и как его использовать?

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 со скриптом для выполнения этих задач на нескольких компьютерах. Кроме того, помните, что вне зависимости от того, используете ли вы эти средства или нет, ваше ПО, управляющее системой, скоро будут их использовать так или иначе.

www.windowsnetworking.com

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

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

Exchange 2007

Если вы хотите прочитать предыдущие части этой серии статей, перейдите по ссылкам: Проведение мониторинга Exchange 2007 с помощью диспетчера System ...

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

Если вы пропустили первую часть этой серии, пожалуйста, прочтите ее по ссылке Использование инструмента Exchange Server Remote Connectivity Analyzer Tool (Часть...

Если вы пропустили предыдущую часть этой серии статей, перейдите по ссылке Мониторинг Exchange 2007 с помощью диспетчера System Center Operations ...

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 и 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 , например:

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 и как его использовать?

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