Служба 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, Наприклад:

C: \\ Users \\ Administrator\u003e 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\u003e

Після настройки quickconfig, я перезапустив команду перерахування з наступними результатами:

C: \\ Users \\ Administrator\u003e winrm e winrm / config / listener ListenerAddress \u003d *Transport \u003d HTTPPort \u003d 80HostnameEnabled \u003d trueURLPrefix \u003d wsmanCertificateThumbprintListeningOn \u003d 10.253.15.98, 127.0.0.1, :: 1, fe80 :: 5efe: 10.253.15.98% 11, fe80 :: 9583: 2148: e1ef: 6444% 10C: \\ Users \\ Administrator\u003e

Тепер я знаю, що WinRM включений.

До речі, якщо ви хочете відключити WinRM, потрібно використовувати таку команду:

winrm delete winrm / config / listener? IPAdress \u003d * + Transport \u003d 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 \u003d * + Transport \u003d HTTP @ (Port \u003d "+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: \\\u003e

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

Навіть дозволу залишаться ті ж самі. Ваша копія PowerShell буде працювати з тим же маркером безпеки, з яким вона запущена. PowerShell робить це за допомогою Kerberos, тому не передає імені та пароля користувача по мережі. Будь-яка команда, яку ви запускаєте на віддаленому комп'ютері, буде запускатися під вашими обліковими даними, тому все, на виконання чого ви маєте дозвіл, ви зможете робити. Це схоже на реєстрацію прямо з консолі комп'ютера і використання копії PowerShell даного комп'ютера. Це майже так. Ось кілька відмінностей.

• Якщо у вас є сценарій PowerShell для вашого профілю на віддаленому комп'ютері, він не буде запускатися, коли ви під'єднали, використовуючи систему віддаленого доступу. Простіше кажучи, профілі є пакетом команд, які автоматично запускаються кожен раз, коли ви відкриваєте вікно командного рядка. Вони використовуються для автоматичного завантаження розширень, модулів і тому подібного.
• Ви обмежені політикою Execution Policy віддаленого комп'ютера. Скажімо, політика вашого комп'ютера встановлюється на RemoteSigned так, що ви можете запускати локальні непідписані сценарії. Якщо політика віддаленого комп'ютера встановлена \u200b\u200bв Restricted (настройка за замовчуванням), вона не дозволить запускати ніякі сценарії, коли ви взаємодієте віддалено.

Багато команд PowerShell йдуть в парах: одна робить щось, інша - протилежне цьому. У нашому випадку Enter-PSSession під'єднує вас до віддаленого комп'ютера, а Exit-PSSession закриває цю сполуку. Exit-PSSession не потрібні ніякі параметри. Після запуску віддалене з'єднання закривається, і запрошення вашого вікна командного рядка повертається назад до нормального вигляду. А що якщо ви забудете запустити Exit-PSSession? Не турбуйтесь. PowerShell і WinRM здатні з'ясувати, що ви зробили, і закрити в разі необхідності віддалене з'єднання.

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

PS C: \\\u003e 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 \u003d Sales, dc \u003d company, dc \u003d 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 \u003d 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 \u003d Unable to check the status of the firewall.

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

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

PS C: \\ Windows \\ system32\u003e winrm qc

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

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

Виконати зміни? y

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

Створено прослуховувач 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\u003e 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 can not connect to the destination specified in the request. Error number: - 2144108526 0x80338012

Якщо потрібно налаштувати WinRM вручну на окремій системі, досить набрати команду:

Winrm quickconfig

У тому випадку, якщо потрібно налаштувати WinRM на групі комп'ютерів, то можна скористатися спеціальними параметрами групової політики. Цікавить нас політика знаходиться в розділі: Computer Configuration -\u003e Policies -\u003e Windows Components -\u003e Windows Remote Management (WinRM) -\u003e WinRM Service. потрібно активувати наступні параметри:
Allow automatic configuration of listeners
Allow Basic Authentication

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


Потім в розділі Computer Configuration -\u003e Policies -\u003e Windows Components -\u003e Windows Remote Shell активуємо пункт:
Allow Remote Shell Access


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


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

Переконався, що тип запуску служби WinRM заданий в автоматичний. Хоча за фактом тип запуску «автоматичний із затримкою», тому що за замовчуванням для служби WinRM задана затримка запуску (параметр DelayedAutoStart \u003d 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 \u003d (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 \u003d 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 \u003d '*'; Transport \u003d 'HTTPS') -ValueSet @ (HostName \u003d 'wks8'; CertificateThumbrint \u003d '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 \u003d 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), ну і що небудь ще по дрібниці 🙂