WinRM — удалённая работа с PowerShell. WinRM — удалённая работа с PowerShell Настройка доверия между компьютерами
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
Удаленное управление 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 — учетная запись пользователя с административными правами на удаленном компьютере.
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 со скриптом для выполнения этих задач на нескольких компьютерах. Кроме того, помните, что вне зависимости от того, используете ли вы эти средства или нет, ваше ПО, управляющее системой, скоро будут их использовать так или иначе.
Для всех ОС, даже для 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. переслал сообщение от анонимуса:
«Здравствуйте! Требуется помощь, т.к. сам способа решения не нашел;)). В общем, проблема такая - не знаю как связаться с автором одного из топиков.. Данная статья подтолкнула меня на знакомство с сетевыми возможностями 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
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. (Все проверялось на виртуальной машине с чистой системой). Заранее огромно спасибо!»
В этой статье, я попытаюсь рассказать, каким образом можно централизованно активировать и настроить службу 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 также должна быть активирована.
