Відправка команд в інше консольний додаток powershell. Прийоми роботи з віддаленими системами через PowerShell. WinRM - Віддалене управління Windows

Я часто працюю з командами на віддалених системах через PowerShell як під час пентестов, так і при вирішенні повсякденних завдань. Запуску віддалених команд відбувається через протокол WinRM (Windows Remote Management), який, наскільки мені відомо, підтримується в Windows Vista SP 1, Windows 7, Windows Server 2008 і Windows Server 2012.

Вступ

початкові налаштування

Перед тим як почати роботу з віддаленої системою, необхідно виконати настройку.

1. Запустіть консоль PowerShell від імені адміністратора і виконайте наступну команду:

Enable-PSRemoting -force

Команда вище дозволяє запуск команд на віддалених системах. Якщо у вас виникли проблеми, використовуйте команди нижче:

2. Переконайтеся в тому, що служба WinRM запускається автоматично.

# Встановлюємо потрібний режим

Set-Service WinRM -StartMode Automatic

# Перевіряємо, що служба запущена

Get-WmiObject -Class win32_service | Where-Object ($ _. Name -like "WinRM")

3. Встановлюємо у всіх хостів статус «достовірний» (можна зробити пізніше).

# Довіряємо всім хостам

Set-Item WSMan: localhost \ client \ trustedhosts -value *

# Перевіряємо налаштування достовірних хостів

Get-Item WSMan: \ localhost \ Client \ TrustedHosts

Приклади роботи з віддаленими системами

Запуск одиночної команди на віддаленій системі

Команда "Invoke-Command" призначена для запуску команд на віддалених системах. Можна працювати від імені поточного користувача, або використовувати сторонню обліковий запис, якщо ви працюєте в системі, яка не є частиною домену:

Invoke-Command -ComputerName MyServer1 -ScriptBlock (Hostname)
Invoke-Command -ComputerName MyServer1 -Credentials demo \ serveradmin -ScriptBlock (Hostname)

Якщо встановлений модуль для роботи з ActiveDirectory, стає можливим запуск команд на безлічі систем за допомогою каналів (pipeline):

Get-ADComputer -Filter * -properties name | select @ (Name = "computername"; Expression = ($ _. "name")) |
Invoke-Command -ScriptBlock (hostname)

Іноді на віддаленій системі потрібно запустити скрипт, що зберігається локально:

Invoke-Command -ComputerName MyServer1 -FilePath C: \ pentest \ Invoke-Mimikatz.ps1
Invoke-Command -ComputerName MyServer1 -FilePath C: \ pentest \ Invoke-Mimikatz.ps1 -Credentials demo \ serveradmin

Якщо ви генеруєте команди або функції динамічно, які потім передаються на віддалену систему можна використовувати зв'язку команд invoke-expression і invoke-command:

$ MyCommand = "hostname"
$ MyFunction = "function evil (write-host` "Getting evil ...` "; iex -command $ MyCommand); evil"
invoke-command -ComputerName MyServer1 -Credentials demo \ serveradmin -ScriptBlock
(Invoke-Expression -Command "$ args") -ArgumentList $ MyFunction

Організація інтерактивної консолі на віддаленій системі

Організувати інтерактивну консоль в PowerShell на віддаленій системі можна за допомогою команди "Enter-PsSession" (трохи схожа на SSH). Команда "Enter-PsSession" також запускається або від імені поточного користувача, або за допомогою альтернативної облікового запису:

Enter-PsSession -ComputerName server1.domain.com
Enter-PsSession -ComputerName server1.domain.com -Credentials domain \ serveradmin

Закриття сесії виконується за допомогою команди "Exit-PsSession":

Створення фонових сесій

Ще одна корисна можливість дозволяє створювати фонові сесії (команда "New-PsSession"). Фонові сесії можуть виявитися корисними при запуску безлічі команд в безлічі систем. Як і попередні команди, команда "New-PsSession" запускається від імені поточного користувача, або за допомогою альтернативної облікового запису:

New-PSSession -ComputerName server1.domain.com
New-PSSession -ComputerName server1.domain.com -Credentials domain \ serveradmin

Якщо встановлений модуль для роботи з ActiveDirectory, стає можливим одноразова створення фонових сесій для безлічі систем (цей трюк можна виконати різними способами). Нижче показаний приклад створення фонових сесій для всіх систем, що входять в домен. У прикладі створення сесій відбувається в системі, яка не входить в домен, за допомогою альтернативної облікового запису домену.

New-PSDrive -PSProvider ActiveDirectory -Name RemoteADS -Root "
"-Server a.b.c.d -credential domain \ user
cd RemoteADS:
Get-ADComputer -Filter * -Properties name | select @ (Name = "ComputerName"; Expression = ($ _. "name"))
| New-PSSession

Висновок переліку фонових сесій

Як тільки створено кілька фонових сесій, можна переглянути їх перелік за допомогою команди "Get-PsSession".

Взаємодія з фоновими сесіями

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

Enter-PsSession -id 3

Для виходу з сесії використовуйте команду "Exit-PsSession". Сесія перейде назад в фоновий режим.

Запуск команд через фонові сесії

Якщо ви хочете виконати команду у всіх активних сесіях, використовуйте зв'язку команд "Invoke-Command" і "Get-PsSession".

Invoke-Command -Session (Get-PSSession) -ScriptBlock (Hostname)

Видалення фонових сесій

Для видалення всіх активних сесій використовуйте команду "Disconnect-PsSession"

Get-PSSession | Disconnect-PSSession

висновок

Дистанційні команди в PowerShell відкривають величезні можливості, як для адміністраторів, так і для пентестеров. Незалежно від ситуації, як ви будете працювати з віддаленими системами, все зводиться до наступного:

Для запуску одиночної команди на віддаленій системі використовуйте "Invoke-Command".
Для взаємодії з одиночною системою використовуйте "Enter-PSSession".
Якщо ви хочете запускати безліч команд в безлічі систем, використовуйте фонові сесії.

Сподіваюся, ця стаття виявилася для вас корисною.

04.03.2011 Білл Стюарт

В версії Windows PowerShell 2.0 реалізований альтернативний механізм підключення до віддалених комп'ютерів, іменований remoting (віддалене взаємодія). Цей механізм використовує кошти служби дистанційного керування Windows (Windows Remote Management, WinRM). Він забезпечує підключення до віддаленого комп'ютера, а також запуск команд, які виконуються на цьому віддаленому комп'ютері

Розробка оболонки PowerShell 1.0 стала справжнім проривом у розвитку засобів управління і автоматизації Windows XP, а також більш пізніх версій платформи ОС Windows. Базована на платформі. NET Frameworkтехнологія PowerShell 1.0 включає в себе однакову структуру команд (cmdlets), вона наділена потужними вбудованими засобами форматування вихідних даних і забезпечує значне підвищення доступності інших технологій, і перш за все - інструментарію управління Windows (WMI). Однак, хоча деякі складові команди PowerShell 1.0 і об'єкти. NET можуть підключатися до віддалених комп'ютерів, ця функція реалізується диференційовано, залежно від конкретного випадку. Команди, що підтримують віддалені з'єднання, мають параметр -ComputerName; крім того, при встановленні з'єднань вони використовують або виклики віддалених процедур (RPC), або модель DCOM.

У багатьох ситуаціях RPC і DCOM добре справляються з завданнями управління, однак при виконанні процедур діагностики і при виявленні причин неполадок часом виникають проблеми. Наприклад, команда Get-Service може зчитувати дані служб з віддаленого комп'ютера за допомогою параметра -ComputerName, проте ця команда не має параметра -Credential, і тому для її виконання слід зареєструватися з обліковим записом, що має дозвіл на доступ до віддаленої системи.

Але вже в версії Windows PowerShell 2.0 реалізований альтернативний механізм підключення до віддалених комп'ютерів, іменований remoting (віддалене взаємодія). Цей механізм використовує кошти служби дистанційного керування Windows (Windows Remote Management, WinRM). Він забезпечує підключення до віддаленого комп'ютера, а також запуск команд, які виконуються на цьому віддаленому комп'ютері. Поясню сказане на прикладі. Засоби підключення до віддаленого робочого столу ставляться до графічного інтерфейсу користувача так само, як віддалене взаємодія до командного рядка оболонки PowerShell. Коли ви запускаєте складову команду з використанням механізму віддаленого взаємодії, команда фактично виконується на віддаленому комп'ютері, але отримані результати ви можете бачити на локальній машині.

Де можна отримати Windows PowerShell 2.0

Оболонка PowerShell 2.0 і служба WinRM входять до складу систем Windows 7 і Windows Server 2008 R2, так що, якщо ви використовуєте ці операційні системи, немає необхідності встановлювати дані компоненти. Якщо ж ви працюєте з системами Windows Vista SP2, Windows XP SP3, Windows Server 2008 SP2 або Windows Server 2003 SP2, вам доведеться завантажити і встановити пакет Windows Management Framework Core (support.microsoft.com/kb/968930).

Включення функції віддаленого взаємодії

Для того щоб комп'ютер міг встановлювати з'єднання з віддаленими системами, на яких встановлена оболонка PowerShell, необхідно забезпечити такі умови.

Повинна бути активована служба WinRM.
Повинен бути встановлений прослуховувач WinRM, який приймає з'єднання з одного або декількох IP-адрес.
Мережевий екран Windows повинен бути налаштований таким чином, щоб з'явилася можливість встановлення з'єднань через WinRM.
Повинен бути включений і належним чином налаштований сеанс PowerShell.

Якщо комп'ютер не буде приймати з'єднання від оболонок PowerShell, встановлених на віддалених комп'ютерах, виконання зазначених умовне обов'язково.

Щоб користувачі могли якомога швидше приступити до роботи, розробники Microsoft PowerShell створили команду Enable-PSRemoting, що забезпечує автоматичне налаштування згаданих компонентів. Цю настройку потрібно виконувати не на машині, з якої ви будете здійснювати віддалене взаємодія, а на комп'ютері, до якого ви будете звертатися дистанційно. Виконувати команду Enable-PSRemoting можна лише в тому випадку, якщо ви працюєте з оболонкою PowerShell з правами адміністратора. Якщо ви працюєте з машинами Windows Vista, Server 2008 і пізніших версій, правою кнопкою миші на значку PowerShell і в меню, що розкрилося виберіть пункт Run as administrator. Якщо ви запустите команду Enable-PSRemoting з параметром -Force, при її виконанні система не буде звертатися до вас за дозволом на виконання кожного етапу конфігурації. Щоб отримати докладніші відомості про складову команді Enable-PSRemoting, виконайте команду

Get-Help Enable-PSRemoting

Виконання однієї команди на віддаленому комп'ютері

Найпростіший спосіб підключитися до середовища PowerShell на віддаленому комп'ютері - скористатися командою Enter-PSSession. За замовчуванням ця команда виконується з параметром -ComputerName, тому при її введенні з клавіатури даний параметр можна не вказувати. Наприклад, для встановлення з'єднання з віддаленим комп'ютером з ім'ям rigel треба ввести з клавіатури

PS C: \> Enter-PSSession rigel

Зверніть увагу: для повноти картини я включаю в текст запрошення. Вам же не потрібно вводити запрошення як частина команди.

Після того як ви введете дистанційний сеанс, синтаксис запрошення PowerShell зміниться. Тепер воно буде включати в себе укладену в квадратні дужки ім'я віддаленого комп'ютера; це буде означати, що ви встановили з'єднання з віддаленим комп'ютером. В даному випадку запрошення буде виглядати так:

: PS C: \>

після встановлення дистанційного підключеннявсі команди, введені вами в командному рядку, будуть виконуватися на віддаленій машині. Так, якщо ви введете команду

: PS C: \> Get-ChildItem C: \

команда Get-ChildItem буде виконана на віддаленій машині. Її вихідні дані будуть містити імена файлів і папок, що зберігаються в накопичувачі C віддаленого комп'ютера. Щоб завершити сеанс віддаленого взаємодії, скористайтеся командою Exit-PSSession

: PS C: \> Exit-PSSession

Виконання блоку сценарію (Scriptblock) на віддаленому комп'ютері

Віддалене взаємодія за допомогою PowerShell дозволяє виконувати на віддаленому комп'ютері блок сценарію, або scriptblock (тобто блок коду PowerShell, укладений у фігурні дужки). Для цього потрібно скористатися командою Invoke-Command з параметром -ComputerName. Наприклад, в команді, відображеної на екрані 1, я використовував команду Invoke-Command, з тим щоб виконати Get-ChildItem на віддаленому комп'ютері. Переглядаючи екран 1, зверніть увагу на те, що для встановлення з'єднання з віддаленим комп'ютером перед тим, як запустити блок сценарію, я не використовував команду Enter-PSSession. Команди Enter-PSSession і Invoke-Command - це два різних методу віддаленого взаємодії.

Першим параметром команди Invoke-Command є параметр -ScriptBlock; він вказує на код, який ви збираєтеся виконати. На екрані 1 я опустив ім'я параметра -ScriptBlock, оскільки вказувати його необов'язково. Параметр -ComputerName містить ім'я віддаленого комп'ютера. Як можна побачити в вихідних даних команди Get-ChildItem, середа PowerShell для зручності оператора навіть вказує ім'я віддаленого комп'ютера в стовпці PSComputerName вихідних даних.

Виконання блоку сценарію на декількох віддалених комп'ютерах

Блок сценарію можна виконувати і на декількох віддалених комп'ютерах. Це називається конфігурацією «один до багатьох» або віяловим розгортанням. На екрані 1 параметр -ComputerName команди Invoke-Command містить одне ім'я, однак в нього можна включати і кілька імен комп'ютерів. Так, команда

PS C: \> Invoke-Command (Get-ChildItem env: co *) -Computer titan, rigel

забезпечує виконання команди Get-ChildItem на двох віддалених комп'ютерах. У тексті статті дана команда розбита на кілька рядків, проте в консолі PowerShellїї слід вводити одним рядком. Те ж стосується і інших команд, розділених на кілька рядків. Так само, як і на екрані 1, стовпець PSComputerName в вихідних даних буде містити імена комп'ютерів.

Виконання блоку сценарію в фоновому режимі

Середа PowerShell 2.0 дає можливість виконувати фонові завдання, тобто оператор може запускати команду в фоновому режимі. Така можливість корисна при запуску команд, виконання яких вимагає багато часу.

Щоб запустити фонове завдання на локальному комп'ютері, можна скористатися командою Start-Job. Але треба сказати, що дана команда не має параметра -ComputerName, а це значить, що її не можна використовувати для виконання фонового завдання на віддаленій машині. Замість цього вам потрібно буде виконати команду Invoke-Command з параметром -AsJob. Так, верхня команда на екрані 2 ініціює виконання блоку сценарію у вигляді фонового завдання на віддаленому комп'ютері titan. Після того як я ввів цю команду, на екрані відразу ж з'явилося запрошення: оболонка PowerShell відправила блок сценарію для виконання на віддалений комп'ютер і після цього повернула мені управління. У попередженні йдеться, що виконана команда не вмістилася в вікні консолі і тому не була включена в вихідні дані. Якби вікно консолі у мене було ширше, засіб форматування оболонки PowerShell включило б команду в перелік вихідних даних. У стовпчиках Id і Name вказується завдання (його ідентифікатор і зрозуміле ім'я відповідно), а в стовпці State вказується, в якому стані знаходиться завдання: виконується, призупинено або завершено. У стовпці HasMoreData міститься інформація, яка свідчить про те, що вилучені всі дані, що стосуються того чи іншого завдання, або що завдання містить більший обсяг відомостей, які слід винести.

Щоб встановити, чи завершено виконання фонового завдання, ви можете виконати команду Get-Job, як показує друга команда на екрані 2. Якщо при цьому ви не використовуєте будь-яких параметрів, Get-Job перевіряє стан усіх завдань, запущених в ході поточного сеансу. Якщо у вас виконується більше ніж одне завдання одночасно, можете використовувати такі параметри, як -Id або -Name, для вказівки на те, яке саме завдання ви хочете перевірити. Коли виконання фонового завдання завершиться, стовпець State вихідних даних буде мати значення Completed.

Для зчитування результатів виконання фонового завдання можна використовувати команду Receive-Job. Ця команда, як і команда Get-Job, повертає вихідні дані всіх завдань, запущених в ході поточного сеансу, якщо ви не використали параметр для вказівки на те, яке саме завдання вас цікавить. Так, остання команда на екрані 2 включає в себе параметр -Id, який вказує на те, що необхідно отримати вихідні дані про завдання з ідентифікатором 9. Я опустив ім'я параметра -Id, оскільки його вказувати необов'язково. На екрані 3 відображені останні рядки вихідних даних, що стосуються виконання даного дистанційного фонового завдання.

Створення сеансів PowerShell

Наведені вище приклади показують, як отримати доступ до запрошення PowerShell на віддаленій машині і як виконувати команди на віддалених комп'ютерах. Але я поки не згадував про те, що віддалене взаємодія завжди здійснюється в контексті сеансу. Сеанс - це, скажімо так, місце проживання PowerShell. Коли ви відкриваєте вікно консолі PowerShell або вікно інтегрованого середовища сценаріїв (ISE) PowerShell, ви створюєте сеанс. Без використання коштів віддаленого взаємодії всі сеанси виконуються на локальному комп'ютері і не залежать один від одного. У всіх наведених вище прикладах віддаленого взаємодії створюються тимчасові сеанси, які автоматично припиняються після закінчення віддаленого взаємодії. Крім того, існує можливість створювати екземпляри сеансів віддаленого взаємодії і повторно використовувати їх. Такий підхід набагато ефективніше у випадках, коли необхідно звертатися до віддалених комп'ютерів більш ніж один раз.

Для створення нових сеансів використовується команда New-PSSession з параметром -ComputerName. Ім'я цього параметра в командах можна опускати. Так, команда

C: \> $ sessions = New-PSSession phineas, ferb, perry

створює три сеанси на трьох комп'ютерах з іменами phineas, ferb і perry. Ви можете переглянути ці сеанси, створивши змінну $ sessions. Для цього в командному рядку потрібно ввести ім'я

$ sessions

і натиснути клавішу введення. Параметр -Session команди Invoke-Command підтримує об'єкти session, створені за допомогою команди New-PSSession, тому далі ви можете використовувати команду, подібну до наступного:

C: \> Invoke-Command (Get-ChildItem) -session $ sessions

Ця команда виконує команду Get-ChildItem на машинах phineas, ferb і perry, але не розриває з'єднання. Ви можете додати параметр -AsJob і виконати команду в фоновому режимі:

C: \> Invoke-Command (Get-ChildItem) -session $ sessions -asjob

Новий підхід до роботи

Віддалене взаємодія за допомогою засобів PowerShell - це новий потужний механізм виконання команд на віддалених комп'ютерах. Сподіваюся, ця стаття надихне вас на дослідження нових можливостей. Більш докладні відомості про віддалений взаємодії, включаючи проблеми діагностики, можна знайти в довідкових темах PowerShell about_Remote за адресою technet.microsoft.com/en-us/library/dd347616.aspx.

Білл Стюарт ( [Email protected]) - системний і мережевий адміністратор компанії French Mortuary, Нью-Мехіко

Віддалене управління за допомогою PowerShell

Існує досить багато методів для роботи з віддаленими комп'ютерами. є Windows Management Instrumentation (WMI), широко використовуваний в VBScript. Є різні утиліти, які дозволяють здійснювати віддалене управління, типу від Sysinternals. Навіть багато командлети PowerShell мають параметр ComputerName для виконання на віддалених комп'ютерах.

Загалом методів повно, але у кожного з них є свої мінуси. По-перше - різний синтаксис, в якому легко заплутатися. По друге - деякі команди поводяться по різному в залежності від того, локально або віддалено вони виконуються. Ну і нарешті, для зв'язку може знадобитися відкриття додаткових портів на брандмауері, що не є добре з точки зору безпеки.

PowerShell Remotingвирішує більшість описаних проблем. Він заснований на Microsoft реалізації протоколу Web Services for Management (WS-Management), а для зв'язку використовує службу (WinRM). Зв'язок між комп'ютерами здійснюється по HTTP (за замовчуванням) або HTTPS. Весь трафік між двома комп'ютерами шифрується на рівні протоколу (за винятком випадків, коли використовується SSL). Підтримуються кілька методів аутентифікації, включаючи NTLM і Kerberos.

На відміну від утиліт, що використовують різні програмні інтерфейси, PS Remoting працює наступним чином: команди, що вводяться на локальному комп'ютері, передаються на віддалений комп'ютер і там виконуються, потім результат передається назад. Оскільки всі команди виконуються локально, немає необхідності піклується про сумісність. Крім того, для роботи PS Remoting потрібен всього один відкритий портна брандмауері.

Є кілька способів управління за допомогою PowerShell Remoting.

Управління «один до одного»

Найпростіший спосіб віддаленого управління - інтерактивно відкрити віддалену сесіюі в ній виконати потрібні дії. Наприклад, відкриємо сесію на комп'ютер SRV4 і рестартуем на ньому сервіс друку:

Enter-PSSession -ComputerName SRV4
Restart-Service -Name spooler

Подивимося стан сервісу і закриємо віддалену сесію:

Get-Service -Name spooler
Exit-PSSession

Інтерактивна робота підходить для вирішення нескладних завданьвіддаленого адміністрування. Якщо ж треба автоматизувати процес, то краще скористатися Командлети Invoke-Command. Ось так з його допомогою можна зробити те ж саме діяння:

Invoke-Command -ScriptBlock (Restart-Service spooler) -ComputerName SRV4

Ця команда відкриє віддалену сесію на SRV4, виконає блок команд, вказаний в параметрі -ScriptBlock, і закриє сесію. А щоб завдання виконувалося в фоновому режимі, додатково можна вказати параметр -AsJob.

Cледует пам'ятати про те, що при роботі в фоновому режимі PowerShell не повертає результат. Для його отримання доведеться скористатися Командлети Receive-Job.

Для того, щоб виконати не пару-трійку команд, а будь-якої скрипт, у Invoke-Command є параметр -FilePath, який можна використовувати замість -ScriptBlock для визначення файлу сценарію. Для прикладу я створив скрипт, який виводить список зупинених служб і запустив його на віддаленій машині SRV4:

Invoke-Command -FilePath. \ Script.ps1 -ComputerName SRV4

Управління «один до багатьох»

Досить частина виникає необхідність паралельно виконати одну задачу на декількох комп'ютерах. Це досить легко можна зробити за допомогою того ж Invoke-Command. Наприклад, імена комп'ютерів можна просто перерахувати через кому:

Invoke-Command -ScriptBlock (Restart-Service spooler) -ComputerName SRV4, SRV5

Помістити в змінну:

$ Servers = @ ( "SRV1", "SRV2", "SRV3")
Invoke-Command -ScriptBlock (Restart-Service spooler) -ComputerName $ servers

Або взяти з файлу:

Invoke-Command -ScriptBlock (Restart-Service spooler) -ComputerName`
(Get-Content. \ Servers.txt)

Примітка:у Invoke-Command є параметр ThrottleLimit, що обмежує максимальна кількістькомп'ютерів, якими можна управляти одночасно. За замовчуванням цей параметр дорівнює 32. При необхідності його можна змінити, але врахуйте, що підвищення цього параметра збільшить навантаження на процесор і пам'ять вашого комп'ютера, тому цю операцію потрібно виконувати з великою обережністю.

сесії

Кожен раз при виконанні Invoke-Command створюється нова сесія, на створення якої витрачається час і ресурси. Щоб цього уникнути ми можемо відкрити одну сесію, в якій і виконувати всі команди. Наприклад, відкриємо сесію з ім'ям SRV4 на комп'ютер SRV4 і помістимо її в змінну $ session, а потім цій сесії виконаємо нашу задачу (зупинимо багатостраждальний spooler):

$ Session = New-PSSession -ComputerName SRV4 -Name SRV4
Invoke-Command -ScriptBlock (Get-Service spooler | Stop-Service) `
-Session $ session

Сесія буде активна до того моменту, поки ми не вийдемо з консолі PowerShell. Також сесію можна закрити - Disconnect-PSSession або видалити - Remove-PSSession.

А тепер кілька цікавих можливостей, що з'явилися в PowerShell 3.0. Якщо раніше при виході з сесії або закриття консолі сесія віддалялася, то в PS 3.0 при закритті сесія переходить в стан disconnected. Ми можемо відкрити новий сеанс на цьому ж (або будь-якому іншому) комп'ютері і виконати команду прямо в цій відключеною сесії. Як приклад стартуємо на комп'ютері SRV4 сервіс друку, зупинений в минулий раз:

Invoke-Command -ScriptBlock (Start-Service spooler) `
-ComputerName SRV4 -Disconnected

Ще один варіант використання відключених сесій - запуск тривалих за часом завдань. Для прикладу відкриємо сесію c ім'ям LongJob на SRV4 і запустимо в ній фонове завдання, яке буде виводити список сервісів з інтервалом в 1 хвилину:

$ Session = New-PSSession -ComputerName SRV4 -Name LongJob
Invoke-Command -Session $ session -ScriptBlock`
(Get-Service | foreach ($ _; sleep 60)) -AsJob

Подивимося, як виконується завдання і закриємо сесію:

Receive-Job -Name Job2
Disconnect-PSSession $ session

Йдемо на інший комп'ютер і відкриваємо консоль, Підключаємося до сесії LongJob і за допомогою командлета Receive-PSSession отримуємо результат виконання завдання:

Connect-PSSession -Name LongJob -ComputerName SRV4
Receive-PSSession -Name LongJob

Або ще варіант, без явного підключення до сесії за допомогою Connect-PSSession:

$ Session = Get-PSSession -Name LongJob -ComputerName SRV4
$ Job = Receive-PSSession $ session -OutTarget Job
Receive-Job $ job

Примітка:для того, щоб результат залишився в системі, Receive-Job треба використовувати з параметром -Keep.

Неявне віддалене управління

Ще один, досить нестандартний спосіб віддаленого управління - неявне дистанційне керування (Implicit remoting). Використовуючи його можна, не створюючи віддаленої сесії, локально виконувати командлети, що знаходяться на віддаленому комп'ютері.

Для прикладу беремо звичайну робочу станцію, без встановлених засобів віддаленого адміністрування. Створюємо віддалену сесію з контролером домену SRV4 і імпортуємо в цю сесію модуль Active Directory:

$ Session = New-PSSession -ComputerName SRV4
Invoke-Command (Import-Module ActiveDirectory) -Session $ session

Потім експортуємо з віддаленої сесії командлети Active Directory і поміщаємо їх в локальний модуль RemoteAD:

Export-PSSession -Session $ session -CommandName * -AD * -OutputModule RemoteAD`
-AllowClobber

Ця команда створить в папці WindowsPowerShell \ Modules \ RemoteAD новий модуль PowerShell. Завантажені будуть тільки командлети з іменами, відповідними шаблоном * -AD *. При цьому самі командлети чи не копіюються на локальний комп'ютер. Локальний модуль служить свого роду ярликом, а самі команди будуть виконуватися на віддаленому контролері домену.

Після створення модуля віддалену сесію можна закрити, вона більше не знадобиться.

Імпортуємо новий модуль в поточний сеанс (в PS 3.0 можна цей крок пропустити):

Import-Module RemoteAD

А тепер увага - ми не відкриваємо віддалену сесію з контролером домену, де розташовані командлети. Не потрібно явно запускати цей сеанс - це можна зробити неявно, Спробувавши виконати віддалені командлети:

New-ADUser -Name BillGates -Company Microsoft
Get-ADUser BillGates

При цьому буде відновлено віддалене підключення до контролера домену, після чого команда буде передана на контролер домену і там виконана. Результат виконання буде серіалізовані в XML і переданий по мережі на локальний комп'ютер, де буде виконана десеріалізацію в об'єкти, з якими може працювати PowerShell.

Віддалений сеанс буде активним до тих пір, поки ви не закриєте консоль або не видалите модуль RemoteAD.

Неявне віддалене управління дозволяє працювати з Командлети на віддаленому комп'ютері практично так само, як якщо б вони були встановлені на локальній машині. При цьому всі необхідні командлети завжди під рукою, що досить зручно.

На закінчення скажу, що на даний момент PowerShell Remoting є основним інструментом для віддаленого управління операційними системами Windows. Тому знати про його можливості і вміти ними користуватися просто необхідно будь-якому Windows-адміністратору.

У цій статті докладно пояснюється тема віддаленого взаємодії з використанням PowerShell 2.0. Насамперед нам необхідно запустити службу, за допомогою якої буде здійснюватися віддалене взаємодія.

Запускаємо службу WinRm
Для віддаленого взаємодії в PowerShell 2.0 використовується служба WinRM, яка за замовчуванням встановлена на Windows 7 і Windows 2008 R2. для більш ранніх версій операційної системиїї потрібно встановлювати додатково. Зазначена служба встановлюється на машину при установці PowerShell 2.0. Для того, щоб переконатися, в наявності WinRM, запустіть консоль PowerShell 2.0 і виконайте в ній команду:
Get-Service WinRm
Результат буде виглядати наступним чином:

Status Name DisplayName ------ ---- ----------- Stopped winrm Windows Remote Management (WS-Manag ...

Як бачимо - служба присутній, проте не запущена. Для того, щоб запустити WinRm, необхідно з правами адміністратора, з консолі PowerShell 2.0, виконати команду:
Enable-PSRemoting
На запит про підтвердження запуску служби, натискаємо кнопку «Y». Тепер службі WinRM призначений тип запуску «Автоматичний», тобто вона буде запускатися кожен раз при старті компьюрета. Команда Enable-PSRemoting не тільки запускає службу і змінює її тип запуску, але і налаштовує належним чином брандмауер, для її коректної роботи. Служба WinRm приймає запити з будь-якого IP-адреси.

Запитуємо імена всіх підключених провайдерів:
Get-PSProvider
Як бачимо, у нас тепер з'явився ще один провайдер під ім'ям WSMan.
Призначення довірених вузлів

В консолі PowerShell 2.0 запускаємо з правами адміністратора команди:

Set-Location -Path WSMan: Set-Location -Path localhost \ client Get-ChildItem

Примітка
Зверніть увагу на те, що в першій команді значення параметра -Path завершується двокрапкою, оскільки це провайдер.

На тому комп'ютері, з яким ви бажаєте віддалено працювати, слід вказати, яким серверам дозволено підключення до цієї машини. Такі сервери відомі як "довірені вузли". Таким чином, якщо ви перебуваєте на сервері "MyServer", то перш ніж ви зможете віддалено працювати з комп'ютером "MyComputer", слід налаштувати довірені вузли (TrustedHosts). Наведений нижче спосіб призначення довірених вузлів використовується в тому випадку, коли комп'ютер не входить до складу домену Active Directory. Якщо ж комп'ютер входить до складу домену Active Directory, то настройки TrustedHosts можна конфігурувати через групову політику (Group Policy).

Важливо!
Наведена нижче команда не буде працювати, якщо поточним каталогом не встановлено WSMan: \ localhost \ client (див. Виклик команд, виконаний нами вище).

Set-Item TrustedHosts *

Можна запустити команду з іншого каталогу, але тоді буде потрібно вказати повний шлях до TrustedHosts:

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

На запит про підтвердження тиснемо клавішу «Y».

Для того, щоб PowerShell побачив зміни, виконані нами в налаштуваннях TrustedHosts - необхідно перезапустити службу WSMan. Це робиться за допомогою наступної команди:
Restart-Service winrm

Аналогічну дію можна виконати з під DOS. Запустіть команду winrm - ?. Ви побачите загальну довідку по команді. Для того, щоб подивитися поточне значення TrustedHosts, слід виконати команду:

winrm get winrm / config / client

а для того, щоб встановити значення - слід виконати:

winrm set winrm / config / client / @ (TrustedHosts = "*")

У наведених вище командах, для TrustedHosts, як значення вказувався символ «*», однак, замість нього можна вказувати імена конкретних серверів. Управління TrustedHosts є класичним випадком, для застосування PowerShell-дієслів "Get" і "Set" в зв'язці: ви використовуєте Get-Item і Set-Item.
Створення та завершення віддаленого сеансу PowerShell 2.0
У наведених нижче командах, замість "IpAddress" слід вказувати потрібний IP-адреса, а замість "FQDN" - повністю визначене ім'я домену (Fully Qualified Domain Name):

Enter-PSSession IpAddress

Enter-PSSession FQDN

Для завершення сеансу віддаленої роботи, слід виконати команду:

Команді Enter-PSSession потрібно полностью.определённое.доменное.імя. Наприклад, в разі MyServer.domain.local, просте зазначення MyServer не спрацювало б, однак використання IP-адреси завжди добре працює в подібних ситуаціях. Альтернативний метод PSSession:

New-PSSession -computername testMachine2 Get-PSSession

Завершити роботу цієї сесії можна так:

Get-PSSession | remove-PSSession

Якщо ви хочете протестувати віддалену роботу, але не маєте другої машини, тоді створіть "віддалене підключення" вашого компьюетера до себе самого. Наприклад, якщо ваша машина називається "MyMachine", тоді спробуйте це:

New-PSSession -computername MyMachine

Можливо це здасться вам дивно і нелогічно, однак у такий спосіб ви все ж зможете випробувати віддалену роботу в PowerShell 2.0.

Робота в віддаленому сеансі PowerShell 2.0
Після створення віддаленого підключення, ви можете організовувати конвеєри команд, запускаючи їх в консолі PowerShell 2.0, але при цьому виконуватися вони будуть на віддаленій машині, як ніби ви знаходитесь за її клавіатурою і набираєте команди там, а не тут. Наприклад, запустіть таку команду і подивіться результат її роботи:

Set-Location c: \ | Get-childitem

Оскільки основне завдання даного навчального керівництва полягає в тому, щоб допомогти вам створити сесію віддаленого підключення PowerShell 2.0 і показати, як її закрити, то вам самим доведеться вирішувати, які операції ви бажаєте виконати в ході віддаленого підключення.

Примітка
Якщо вам здається, що сесії віддаленого підключення у вас не працює якась команда - протестуйте її спочатку на своїй локальній машині.

Як тільки віддалене підключення у вас запрацює, це відразу дає вам можливість використовувати PowerShell 2.0 для управління комп'ютерами, підключеними до вашої мережі. Тепер ви можете виконувати сценарії на інших машинах. У PowerShell 2.0 багато командлети підтримують параметр "-computerName", але віддалене підключення дозволяє вам використовувати команди сімейства PSSession, а так само викликати Invoke-Command (тобто ви можете робити все що завгодно).

Пошук і усунення проблем, що виникають в процесі віддаленої роботи PowerShell 2.0

Одна типова проблема - ПОМИЛКА «Access is denied» (доступ заборонений).

Рішення:
Запустіть PowerShell 2.0 з правами адміністратора. Спробуйте на обох машинах (на тій, з якої підключаєтеся, і на тій, до якої підключаєтеся) задати налаштування "TrustedHosts" значення * (зірочка). Тільки не забувайте, що такий варіант дозволяє підключення звідусіль.
Не забудьте перезапустити службу WinRm, інакше виконані вами для "TrustedHosts" зміни не вступлять в силу. Для перезапуску служби слід в консолі PowerShell 2.0 виконати команду: Restart-Service WinRm
Крім того, будьте уважніше і не плутайте ім'я провайдера WSMan з ім'ям служби WinRm.
Ще один дивний, але часом допомагає порада: Спробуйте повторити спробу віддаленого підключення. Дивно, але це може не спрацювати з першої спроби, але спрацювати з другої або третьої. Тобто вам потрібно повторно виконати команду: Enter-PSSession -computerName myOtherMachineName

Брандмауери, PowerShell 2.0 і «The rpc server is unavailable» (Сервер RPC недоступний)
Фахівці з безпеки в жаху піднімуть руки від такої пропозиції, проте в разі отримання зазначеної вище помилки, я пропоную вам відключити брандмауер на обох комп'ютерах. Якщо після відключення все запрацює - це добре, значить потрібно перевірити задіяність портів 135 і 445. Налаштуйте для цих портів виключення в брандмауерах - це дасть можливість PowerShell 2.0 працювати віддалено і при цьому брандмауер захистить комп'ютер від загроз.

P.S. я читав, що команда Enable-PSRemoting повинна брати на себе автоматичне внесення змін до настройки брандмауера, але з мого досвіду це не завжди так.
Про те, як за допомогою групової політики відключити брандмауер в Windowws 8, читайте.

Два типу, що використовуються для віддаленої роботи в PowerShell 2.0
Пора повідомити, що існують два варіанти віддаленої роботи в PowerShell 2.0.
Перший спосіб - це більш витончена варіація, в якій використовуються командлети, створюючи стійкий канал до другої машині. Імена таких команд містять в якості іменника слово "PSSession" (нагадую, що імена командлетів будуються за правилом "Дієслово-Іменник"). Отримати перелік цих командлет можна за допомогою такої команди:

Get-Command -noun PSSession

Другий спосіб - це так само більш канонічна форма віддаленої роботи PowerShell 2.0. даний спосібпросто розширює локальні команди, додаючи до них параметр "-computerName", за допомогою якого вказується віддалено розташований комп'ютер, на якому необхідно виконати операцію. В результаті, такі команди будуть запущені на іншій машині, що знаходиться в мережі:

Get-Process -computerName machine2

Перелік командлет, які можна використовувати таким простим способом(Тобто тих, що мають в своєму складі параметр "-computerName") можна отримати за допомогою такої команди:

Get-command | where ($ _. parameters.keys -contains "ComputerName")

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

Get-command | where ($ _. parameters.keys -contains "ComputerName" -and ($ _. parameters.keys -notContains "Session"))

Підводимо підсумок про віддаленій роботі в PowerShell 2.0
Секрет в тому, щоб віддалено працювати з допомогою PowerShell 2.0 в тому, що потрібно зрозуміти основні речі:
Слід встановити WinRm.
За допомогою команди Enable-PSRemoting необхідно дозволити віддалене взаємодія.
Потрібно виконати настройку TrustedHosts (наприклад задати їй в якості значення *).
У разі використання команди Enter-PSSession, слід не забувати вказувати повністю певне ім'я вузла або ж його IP-адресу.

Англомовний джерело викладеної і трохи переробленої мною інформації.

# Створюємо нову сесію підключення до віддаленої машині $ s = New-PSSession -computername TestComputer

# Виконуємо на віддаленій машині довільні дії, наприклад - дивимося вміст каталогу C:
Invoke-Command -Session $ s -ScriptBlock (ls c: \)

# Створюємо на віддаленій машині каталог "% ProgramFiles% \ MyCompany \ MySoft"
Invoke-Command -Session $ s -ScriptBlock (New-Item -Path "$ env: ProgramFiles \ MyCompany \ MySoft" -ItemType directory)

# Однак, набагато зручніше не вручну вбивати команди, а запускати на віддаленій машині вже готовий скрипт:
Invoke-Command -Session $ s -FilePath "\\ ServerDir \ Common Scripts \ MyScript.ps1"

# Завершуємо сесію
$ S | remove-PSSession

Tutorial

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

Найбільш простий шлях конфігурувати віддалене управління це виконати Enable-PSRemoting в оболонці powershell з правами адміністратора. При цьому відбудеться наступне:

запуститься служба WinRM (якщо запущена перезапуститься)
служба WinRM перейде в стан - автоматичний запуск при старті
буде створено прослуховувач WinRM для HTTPтрафіку на порту 5985 для всіх локальних IP адрес
буде створено правило файрволу для Прослуховувач WinRM. Увага, цей пункт завершиться з помилкою якщо будь-яка з мережевих карток має тип мережі «публічна», тому що відкривати порт на такій картці не хорошо. Якщо у вас при конфігуруванні вийшла така помилка змініть профіль це сетевушкі Командлети Set-NetConnectionProfile і після цього запустіть Enable-PSRemoting знову. Якщо вам потрібна мережева картка з профілем «Публічна мережа» запустіть Enable-PSRemoting з параметром -SkipNetworkProfileCheckв цьому випадку будуть створені правила файрвола тільки з локальної мережі.

Після цього потрібно дозволити підключатися до віддаленої машині з тієї машини з якої буде відбуватися управління. Зроблено це з метою безпеки для того щоб зменшити ризик злому сесії віддаленого управління або DNS з підстановкою себе замість віддаленої машини і запобігти виконанню скриптів на машинах які ви примусово не дозволили.

Для перевірки куди можна підключатися використовуємо:
get-item wsman: \ localhost \ Client \ TrustedHosts
для вирішення підключатися до всіх
set-item wsman: localhost \ client \ trustedhosts -value *
Якщо ви відкриваєте доступ для всіх вказавши * то WinRM буде підключатися до ВСІХ машинам без перевірки. Пам'ятайте, що ви відкриваєте самого себе для потенційного злому з локальної мережі. Краще вказувати адреси хостів куди вам потрібно підключиться, тоді WinRM буде відхиляти всі інші адреси або імена. Якщо машина з якої ведеться управління знаходиться в домені вона буде довіряти всім машинам цього домену. Якщо вона не в домені, або в іншому домені, то потрібно вказати в TrustedHosts адресу або ім'я машини на яку ми будемо підключатися. Додавати себе на машині до якої ми підключаємося не потрібно.

У хелпе вказані команди, я їх чуть чуть переробив в скрипт
################################################## #################################### # додає NewHost в список TrustedHost з фільтрацією якщо такий рядок уже є # можна смикати з командного рядкавказуючи параметр безпосередньо наприклад #. \ Add-TrustedHost.ps1 192.168.2.1 ################################### ################################################## # param ($ NewHost = "192.168.2.89") Write-Host "adding host: $ NewHost" $ prev = (get-item WSMan: \ localhost \ Client \ TrustedHosts) .value if (($ prev.Contains ($ NewHost )) -eq $ false) (if ($ prev -eq "") (set-item WSMan: \ localhost \ Client \ TrustedHosts -Value "(! LANG: $ NewHost" } else { set-item WSMan:\localhost\Client\TrustedHosts -Value "$ Prev, $ NewHost" } } Write-Host "" Write-Host "Now TrustedHosts contains:" (get-item WSMan:\localhost\Client\TrustedHosts).value !}
він перевіряє на є така запис, якщо немає то додає в список. Викликати можна з командного рядка вказавши адресу або ім'я.

Є різниця вказувати ім'я або адресу. Якщо в TrustedHosts буде тільки адреса то відкрити сесію по імені не вийде, і навпаки - якщо вказати ім'я то причепиться за адресою не вийде. Враховуйте це.

в чому ж різниця

Enable-PSRemoting робить більше дій ніж «winrm quickconfig». Командлет Set-WSManQuickConfig робить точно такі ж дії як «winrm quickconfig». Enable-PSRemoting запускає Set-WSManQuickConfig коли веде налаштування системи

Дистанційні підключення
1. Сесії 1-to-1
відкриваються командою
Enter-PSSession -ComputerName Test
Ви отримаєте оболонку на віддаленій машині. Підключитися можна до самого себе вказавши localhost. Альтернативні кредітали вказуються з параметром -Credential, Вихід відбувається Командлети Exit-PSSession

Обмеження такі:

не можна зробити другий стрибок - лише 1 сесія, всередині сесії підключитися далі не можна
ви не можете використовувати команди мають графічний інтерфейс. Якщо ви це зробите оболонка повисне, натисніть Ctrl + C щоб відвисла
ви не можете запускати команди мають свій власний йшов, наприклад nslookup, netsh
ви можете запускати скрипти якщо політика запуску на віддаленій машині дозволяє їх запускати
не можна причепиться до інтерактивної сесії, ви заходите як «network logon», Як ніби причепилися до мережевому диску. Тому не запустяться логон скрипти, і ви можете не отримати домашню папку на віддаленій машині (зайвий аргумент щоб не Мапа хом фолдери логон скриптами)
ви не зможете взаємодіяти з користувачем на віддаленій машині навіть якщо він туди залягання. Чи не вийде показати йому віконце або подрукуємо небудь йому.

цей спосіб найкраще для простих операцій, зайшов, посмикав сервер і відключився. Якщо потрібно утримати змінні в Скоп'є, потрібна тривала операція (багато годин або днів), потрібно більше можливостей по адмініструванню то потрібно використовувати техніку попродвінутее.

Коментар.
об'єкти передані по мережі обрізаються і перестають бути живими. У них видаляються методи, властивості залишаються. Витягнути об'єкт на свою машину, поворожити і засунути назад не вийде. Якщо потрібно більше пишіть, допишу окремо.

2. Сесії 1-to-many
Invoke-Command
визначаємо що будемо виконувати так:
$ Sb = (команди для віддаленої машини розділені крапкою з комою)
передаємо на віддалені машини Test1 і Test2
Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $ sb
за раз можна закинути на 32 машини. Якщо альтернативні кредітали то використовуємо параметр -Credential

Щоб передати цілком скрипт замість параметра -ScriptBlock пишемо -FilePath, віддаленій машині НЕ потрібно мати доступ до файлу, він буде розібраний на запчастини, переданий через HTTP і виконаний з того боку.

Запам'ятаємо що на тій стороні буде новий скопа, так що ваш скрипт не отримає значень з вашої консолі, а змінні скрипта можуть виявитися на тому боці порожніми. Тому передавайте відразу цілком готові інструкції та скрипти з параметрами.

для повноцінного використання Invoke-Command треба вміти перетворювати рядки в скрипт блоки. Наприклад у вас є команди які залежать від якогось списку, вам потрібно згенерувати рядок, перетворити її в ScriptBlock і відправити на віддалений комп:
$ Sb = :: Create ($ SomeString)

kuda78
У статті пропущений дуже важливий момент- передача параметрів в скрипт на віддаленій машині.
$ DeployRemote = (
param (
$ TargetEnvName,
$ TargetUsername)
$ Global: ErrorActionPreference = «Stop»
#…
}
Invoke-Command -Session $ session -ScriptBlock $ deployRemote -ArgumentList ($ targetEnvName, $ targetUsername)

Так дійсно пропущений. Зробив свідомо щоб не захаращувати огляд параметрами і описами. Спасибі. Параметр -ArgumentList працює як зі скрипт блоками так і зі сценаріями

3. Сесії
Це коли з того боку створюється копія пошіка постійно висить в пам'яті, і в неї відправляються команди. Як результат до неї можна перепідключитися, ченить довгий запустити на виконання, чіплятися з різних скриптів або різними користувачами. Наприклад у вас є набір скриптів вирішальних одну задачу по частинах, кожен з них по черзі може підключаться до однієї віддаленої сесії, бачити результати роботи попередніх команд, мати одні завантажені модулі, загальні змінні, загальне оточення, до тих пір поки сесія не буде примусово закрита.

Створення сесії відбувається Командлети New-PSSession, результат можна помістити в змінну
$ DC01 = New-PSSession -ComputerName DC01 $ Controllers = New-PSSession DC01, DC02, DC03
використовувати можна такі самі установки як в Invoke-Command

Як використовувати:
якщо 1-to-1
Enter-PSSession -Session $ DC01
якщо 1-to-many
Invoke-Command -Sessions $ Controllers -ScriptBlock (get-eventlog -logname security -newest 50)
подивитися які сесії відкриті можна за допомогою Get-PSSession, закрити Remove-PSSession
закрити взагалі всі сесії
Get-PSSession | Remove-PSSession
причепиться до сесії можна за допомогою Connect-PSSession, відключитися через Disconnect-PSSession

Invoke-Command може створити відразу disconnected сесію, він відправляє команди на виконання і відключаться, пізніше можна підключиться і вивантажити результати роботи. Робиться це параметром -Disconnected. Отримання результатів через командлет Recieve-PSSession.

Сесії мають дуже багато налаштувань, можливо навіть створення сесій з обрізанням набором команд, модулів і т.п. Називається custom endpoints