Дистанційне керування за допомогою 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 .
Слід пам'ятати про те, що під час роботи у фоновому режимі 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
Ще один варіант використання відключених сесій – запуск тривалих за часом завдань. Наприклад відкриємо сесію з ім'ям 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
Ця команда створить новий модуль PowerShell у папці WindowsPowerShell\Modules\RemoteAD. Завантажені будуть лише командлети з іменами, що відповідають шаблону *-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 має брати на себе автоматичне внесеннязмін у налаштування брандмауера, але на мій досвід це не завжди так.
Про те, як за допомогою групової політикивідключити брандмауер у Windows 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
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, Нью-Мехіко
- Tutorial
Тут мінімум теорії, переважно практична частина. Описується як настроїти WinRM, як змінити профіль мережевого адаптера, дається скрипт з додавання в TrustedHosts з фільтрацією, пояснюється навіщо потрібні довірені хости, і розглядаються поверхнево віддалені підключеннятак що можна було сісти і відразу відмінити віддалені машини.
Найпростіший шлях конфігурувати віддалене управління це виконати Enable-PSRemoting в оболонці живлення з правами адміністратора. При цьому станеться таке:
- запуститься служба WinRM (якщо запущена перезапуститься)
- служба WinRM перейде в стан – автоматичний запуск при старті
- буде створено прослуховувач WinRM для HTTPтрафіку на порту 5985 для всіх локальних IP адрес
- буде створено правило файрвол для прослуховувача WinRM. Увага, цей пункт завершиться помилково якщо будь-яка з мережевих карток має тип мережі «публічна», т.к. відкривати порт на такій картці не добре. Якщо у вас при конфігуруванні вийшла така помилка зміните профіль це сітки командлетом Set-NetConnectionProfile і потім запустіть Enable-PSRemoting знову. Якщо вам потрібна мережева картка із профілем «Публічна мережа» запустіть Enable-PSRemoting із параметром -SkipNetworkProfileCheckу цьому випадку будуть створені правила файрволу лише з локальної мережі.
Для перевірки куди можна підключатися використовуємо:
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
Резюме: Ознайомлення з віддаленим керуванням у Windows PowerShell.
Weekend Scripter: Включаємо дистанційне керування Windows.
Microsoft Scripting Guy, Ed Wilson на зв'язку. Сьогодні я збираюся опублікувати уривок з моєї нової книги Windows PowerShell 3.0 Step by Step, що видається Microsoft Press. Зараз ця книга є доступною для попереднього замовлення.
WinRM – Віддалене керування Windows
У Windows Server 2012 WinRM запущено за замовчуванням для підтримки виконання віддалених команд Windows PowerShell. WinRM – це імплементація корпорацією Microsoft промислового стандарту WS-Management Protocol. Тому WinRM надає зручний спосіб доступу до віддалених систем з погляду вимог до налаштування файрвола. Це той механізм, який використовують нові команди CIM. Таким чином, ви можете будь-коли підключитися до працюючої машини на Windows Server 2012 для запуску команд або відкриття інтерактивної консолі Windows PowerShell. На Windows 8, з іншого боку, WinRM за замовчуванням вимкнено. Це означає, що перше, що потрібно зробити, це запустити командлет Enable-PSRemoting. При запуску цього командлету відбуваються такі кроки:
1. Запуск або перезапуск служби WinRM.
2. Тип запуску служби WinRM встановлюється автоматично.
3. Створюється прослуховувач (listener) для прийому підключень за всіма IP-адресами.
4. Вмикається виключення брандмауера для трафіку WS-Man.
5. Увімкнено конфігурацію Microsoft.powershell
6. Увімкнено конфігурацію Microsoft.powershell.workflow
7. Увімкнено конфігурацію Microsoft.powershell32
Протягом цього процесу, функція запитує підтвердження виконання кожного з дій. Якщо ви знайомі з діями, що виконуються функцією і не збираєтеся вносити до неї будь-які зміни, ви можете запустити цю команду з ключем -Forceі в цьому випадку запити підтверджень не виводитимуться. Синтаксис цієї команди наведено нижче.
Enable-PSRemoting –Force
Тепер наведемо приклад використання функції Enable-PSRemoting в інтерактивному режимі, включаючи всю інформацію, що виводиться.
PS C:\> Enable-PSRemoting
WinRM Quick Configuration
Натискання кнопки «Set-WSManQuickConfig» для забезпечення ефективного управління цією програмою за допомогою Windows Remote Management (WinRM) Service. This includes:
1. Starting or restarting (іf already started) the WinRM service
2. Setting the WinRM service startup type to Automatic
3. Creating a listener to accept requests on any IP address
4. Enabling Windows Firewall впорядковані правила exceptions для WS-Management traffic (for http only).
Do you want to continue?
WinRM має бути updated to receive requests.
WinRM Service типу змінюється успішно.
WinRM Service started.
WinRM має бути updated for remote management.
Created a WinRM listener on HTTP://* для WS-Man requests to any IP on this machine.
WinRM Firewall exception enabled.
microsoft.powershell SDDL:
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»):y
Are you sure you want to perform this action?
Performing operation "Set-PSSessionConfiguration" on Target "Name:
microsoft.powershell.workflow SDDL:
O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;; WD). This will
allow selected users to remotely run Windows PowerShell commands on this computer».
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»):y
Are you sure you want to perform this action?
Performing operation "Set-PSSessionConfiguration" on Target "Name:
microsoft.powershell32 SDDL:
O:NSG:BAD:P(A;;GA;;;BA)(A;;GA;;;RM)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;; WD). This will
allow selected users to remotely run Windows PowerShell commands on this computer».
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is «Y»):y
Після того як конфігурацію виконано, можна перевірити працездатність WinRM за допомогою командлета Test-WSMan. Якщо система налаштована правильно, виводиться інформація, подібна до наступної.
PS C:\> Test-WSMan -ComputerName w8c504
ProductVersion: OS: 0.0.0 SP: 0.0 Stack: 3.0
Цей командлет також працює з комп'ютерами Windows PowerShell 2.0. Наведений нижче приклад ілюструє запит до контролера домену на Windows Server 2008 з встановленим Windows PowerShell 2.0, на якому було налаштовано WinRM.
PS C:\> Test-WSMan -ComputerName dc1
wsmid: http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion: http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor: Microsoft Corporation
ProductVersion: OS: 0.0.0 SP: 0.0 Stack: 2.0
Якщо WinRM не налаштовано, буде повернено повідомлення про помилку. У випадку з операційною системою Windows 8, повідомлення буде наступним.
PS C:\> Test-WSMan -ComputerName w8c10
Test-WSMan: xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859046" Machine="w8c504.iammred.net">WinRM може не забути. Verify that the specified computer name є valid, that the computer is accessible over the network, and that a firewall exception for the WinRM service is enabled and allows access from this computer. By default, the WinRM Firewall exception for public Profiles limits access to remote computers within the same local subnet. At line:1 char:1 Test-WSMan -ComputerName w8c10 + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ CategoryInfo: InvalidOperation: (w8c10:String) , InvalidOperationException FullyQualifiedErrorId: WsManError,Microsoft.WSMan.Management.TestWSManCommand Варто пам'ятати про те, що включення віддаленого керування командлетом Enable-PSRemoting не активує виключення файрвола Remote Management, тому спроба пропінгувати машину з Windows 8 не увінчається успіхом. PS C:\> ping w8c504 Pinging w8c504.iammred.net with 32 bytes of data: Request timed out. Request timed out. Request timed out. Request timed out. Ping statistics for 192.168.0.56: Packets: Sent = 4, Received = 0, Lost = 4 (100% loss). У випадку з Windows Server 2012 все працює. PS C:\> ping w8s504 Pinging w8s504.iammred.net with 32 bytes of data: <1ms TTL=128 Reply from 192.168.0.57: bytes=32 time<1ms TTL=128 Reply from 192.168.0.57: bytes=32 time<1ms TTL=128 Reply from 192.168.0.57: bytes=32 time<1ms TTL=128 Ping statistics for 192.168.0.57: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times в літній час: Minimum = 0ms, Maximum = 0ms, Average = 0ms Це все, що стосується увімкнення WinRM. Ed Wilson, Microsoft Scripting Guy Оригінал:
