Дистанційне керування за допомогою PowerShell. Робота з віддаленими сесіями Powershell. Створення сеансів PowerShell
Резюме: Знайомство з віддаленим керуванняму 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 Оригінал:
Нещодавно довелося витратити трохи часу на налаштування віддаленого доступу через Powershell. Мені такий підхід здається дуже гарною альтернативною Remote Desktop Services у ряді випадків (перезапустити сервіс на віддаленому хостингу VDS, зробити резервні копії, переглянути стан системи тощо). Можливість створення віддалених сеансів Powershell з'явилася у версії 2. Для цього використовується командлет Enter-PSSession/Invoke-Command. Проте, перед використанням слід підготувати середовище. Що робимо на сервері: Крок 1:Відкриваємо консоль Powershell і дозволяємо віддалені сесії командлетом Enable-PSRemoting із ключем Force. Enable-PSRemoting -Force Крок 2:Переконуємось у тому, що служба WinRM запущена. Start-Service WinRM Крок 3:Налаштовуємо правила у брендмауері, щоб вхідні підключення були можливі. На комп'ютері, який використовуватиметься як клієнтськийтеж необхідно виконати кілька дій: Крок 1:Дозволити підключення до віддалених вузлів. Для доступу до будь-яких вузлів можна скористатися наступною конструкцією: Set-Item wsman:\localhost\client\trustedhosts * -Force Крок 2:Переконатись, що брендмауер не блокує вихідні з'єднання. Тепер для підключення до віддаленого вузла через Powershell можна здійснювати так: Enter-PSSession 192.168.1.160 - Credential VMNAME\User Значення 192.168.1.160 та VMNAME\User необхідно замінити адресою віддаленого вузла та ім'ям користувача Windows на сервері. Тепер віддалений доступ через Powershell працює. Проте є ще один нюанс. Можливо, хтось із вас користується профілями в Powershell. Профілі – це спеціальні скрипти, які запускаються під час запуску самої консолі. Тут, наприклад, можна визначити всі необхідні аліаси та виконати попередні дії. Проблема полягає в тому, що профілі не запускаються під час використання віддалених сеансів. Вирішити це можна за допомогою різних конфігурацій підключення. Для цього потрібно спочатку зареєструвати конфігурацію на віддаленому сервері. Зробити це можна шляхом виконання команди Register-PSSessionConfiguration . При цьому кожній конфігурації надається ім'я. Для кожної конфігурації можна встановити шлях до скрипта, який буде виконуватися при старті сесії. Register-PSSessionConfiguration -name Config1 -startupScript c:\scripts\Startup.ps1 Після цього, при підключенні до віддаленого вузла, при використанні команди Enter-PSSession слід вказати ім'я конфігурації. Enter-PSSession 192.168.1.160 -ConfigurationName Config1 - Credential VMNAME\User Тепер можна не витрачати ресурси сервера на створення сесії підключення через Remote Desktop Services і віддалено керувати сервером за допомогою Powershell. powershell віддалений запуск програми Запуск інтерактивного сеансу Щоб запустити інтерактивний сеанс із одним віддаленим комп'ютером, використовуйте командлет Enter-PSSession. Наприклад, щоб запустити інтерактивний сеанс із віддаленим комп'ютером Server01, введіть: Виконання віддаленої команди Використовуйте командлет Invoke-Command, щоб виконати будь-яку команду на одному або кількох віддалених комп'ютерах. Наприклад, щоб виконати команду Get-UICulture на віддалених комп'ютерах Server01 та Server02, введіть: Invoke-command -computername Server01, Server02 (get-UICulture) Встановлення постійного підключення Invoke-command -session $s ($h | where ($_.installedby -ne "NTAUTHORITY\SYSTEM") Все взято з https://technet.microsoft.com/ru-ru/library/dd819505.aspx Одне з найпопулярніших завдань у системних адміністраторів це запуск будь-якої команди на віддаленому комп'ютері, не встаючи зі свого місця. Це може бути необхідно для установки програми або утиліти, зміни будь-яких налаштувань, або навіщо ще. І звичайно, рідко йдеться лише про один комп'ютер, частіше команду потрібно виконати на багатьох робочих станціях або серверах. Оскільки завдання ця популярна, те й способів вирішення існує безліч. Починаючи від групових політик (у яких можна застосовувати для цієї мети сценарії входу в систему або автозавантаження) і закінчуючи потужними системами управління, на зразок System Center Essentials або System Center Configuration Manager. Але я в цій статті хочу розглянути методи, які доступні відразу з командного рядкаабо файлів сценаріїв, а так само не вимагають попередньої установки агентів та іншої метушні. Втім, якісь попередні вимоги, звичайно, є. Наприклад, у вас повинні бути адміністративні повноваження на тому комп'ютері, на якому ви хочете виконати команду (за винятком сценарію з проксуванням, але про це пізніше). Один з моїх улюблених способів для вирішення цього завдання це утиліта командного рядка PsExec.exe, написана Марком Руссиновичем, яку ви можете вільно завантажити з сайту Windows SysInternals. Посилання на неї можна знайти в кінці статті. Вона не вимагає установки в систему, ви можете просто скопіювати її в одну з папок, що містяться в змінному оточенні %path% і викликати будь-яку оболонку командного рядка: Cmd або PowerShell. Використання PsExec дуже просто. Наприклад, щоб виконати ipconfig /flushdns на комп'ютері main, достатньо запустити наступну команду: psexec \\main ipconfig /flushdns Команда ipconfig буде запущена на комп'ютері main під вашими обліковими даними. Після завершення роботи ipconfig весь текстовий висновок буде переданий на ваш комп'ютер, а також буде повернено код виходу команди (error code). У разі якщо команда виконалася успішно, він дорівнюватиме 0. Зрозуміло, що на цьому можливості PsExec не закінчуються. Викликавши утиліту без параметрів, можна переглянути інші доступні опції. Я зверну увагу лише на деякі з них. Ключ -dкаже PsExec, що не потрібно чекати виконання команди, а достатньо лише запустити її, і забути. У цьому випадку ми не отримаємо вихідних даних від консольної утиліти, але зможемо не чекаючи завершення попередньої команди запускати інші. Це дуже корисно, якщо вам необхідно запустити, наприклад, інсталятор програми на декількох комп'ютерах. За замовчуванням PsExec виконує команди в прихованому режимі, тобто на системі, де виконується команда, не будуть виводитися жодні вікна або діалоги. Однак є можливість змінити цю поведінку за допомогою ключа -i. Після нього можна вказати номер сесії, в якій виводити вікна, а можна і не вказувати, інтерфейс буде відображено в консольній сесії. Таким чином, щоб вивести вікно з інформацією про версію операційної системи на комп'ютері main, слід запустити PsExec таким чином: psexec -i \\main winver.exe Якщо ви хочете виконати команду відразу на декількох комп'ютерах, вам знадобиться прочитати їхні імена з текстового файлу списку. psexec @c:\comps.txt systeminfo.exe Ну і однією з найкорисніших здібностей PsExec є можливість інтерактивного перенаправлення введення/виводу між комп'ютерами, що дозволяє нам запустити, наприклад, cmd.exe на віддаленому сервері, а давати йому команди і отримувати результати на локальному комп'ютері. Як працює PsExec? Все геніальне просто. У ресурсах виконуваного файлу PsExec.exe знаходиться інший виконуваний файл - PSEXESVC, який є службою Windows. Перед виконанням команди, PsExec розпаковує цей ресурс на приховану адміністративну спільну папку віддаленого комп'ютера, файл: \\Ім'яКомп'ютера\Admin$\system32\psexesvc.exe. Якщо ви за допомогою ключа -c вказали, що необхідно скопіювати файли, що виконуються на цю систему, вони теж скопіюються в цю папку. Після завершення підготовчих дій PsExec встановлює та запускає службу, використовуючи API функції Windows для керування службами. Після того як PSEXESVC запуститься, між ним і PsExec створюється кілька каналів для передачі даних (введених команд, результатів і т.д.). Завершивши роботу, PsExec зупиняє службу та видаляє її з цільового комп'ютера. Наступний спосіб реалізації цієї популярної задачі, про яку я хочу розповісти - використання Windows Management Instrumentation. WMI є у всіх операційних системах Microsoft, починаючи з Windows 2000, і навіть на Windows 9x його можна встановити з окремого пакета. WMI увімкнено за замовчуванням і не потребує додаткового налаштування. Для його використання достатньо адміністративних прав та дозволеного на брандмауері протоколу DCOM. WMI надає величезні можливості для управління системами, але нас зараз цікавить лише одна з них. Для запуску процесів нам знадобиться метод Create класу Win32_Process. Використовувати його досить просто. У PowerShell це робиться так: $Computer = "main" Тут як процес, що запускається, я вказав cmd.exe, а вже йому, як аргументи, передав потрібну команду. Це необхідно, якщо вам потрібно використовувати змінні оточення віддаленого комп'ютера або вбудовані оператори cmd.exe, такі як « >
» для перенаправлення виведення файлу. Метод Create не чекає завершення процесу, і не повертає результатів, зате повідомляє нам його ідентифікатор – ProcessID. Якщо ви використовуєте комп'ютер, на якому поки не встановлено PowerShell, ви можете викликати цей метод WMI і зі сценарію VBScript. Наприклад, ось так: Лістинг №1 - Запуск процесу використовуючи WMI (VBScript) Computer = "PC3" Але набагато простіше скористатися утилітою командного рядка wmic.exe, яка надає досить зручний інтерфейс для роботи з WMI і входить до складу операційних систем, починаючи з Windows XP. У ній щоб запустити, наприклад калькулятор на комп'ютері main, достатньо виконати наступну команду: wmic /node:main process call create calc.exe Зрозуміло, можливості WMI не обмежуються лише запуском процесів. Якщо вам цікаво подальше вивчення цієї технології, я рекомендую ознайомитись зі статтями Костянтина Леонтьєва, присвяченими WMI, посилання на які ви можете знайти наприкінці статті. Так, як не дивно Windows Script Host теж є можливість запуску сценаріїв на інших комп'ютерах. Правда ця функція не набула великої популярності, і швидше за все через те, що вимагає дуже багато підготовчих заходів, а натомість надає зовсім небагато можливостей. Але я все одно розповім про цей метод, так як і він може стати у нагоді. Отже, для запуску сценарію на іншому комп'ютері за допомогою WSH нам знадобиться зробити таке: Права адміністратора на віддаленому комп'ютері. Це зрозуміло, і потрібно майже всім інших методів запуску перелічених у статті. Дозволити WSH Remote Scripting створивши в системному реєстрі рядковий параметр Remote рівний "1" у ключі реєстру HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings Через помилки описаної в статті бази знань Microsoft з номером 311269, на системах з Windows XP може знадобитися виконати команду wscript –regserver Якщо на комп'ютерах використовується брандмауер, необхідно дозволити звернення до DCOM. Причому зробити це треба не тільки на керованому комп'ютері, але й на тому, з якого ви хочете запускати сценарій. У системах Windows XP з пакетом оновлень 2 і вище необхідно змінити параметри безпеки DCOM. Це можна зробити за допомогою групової політики. У вузлі Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options слід встановити дозволи таким чином: DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax Ну і після всіх цих процедур можна спробувати запустити свій сценарій на іншому комп'ютері. Приклад сценарію, який використовує цю технологію: Лістинг №2 - WSH remote scripting (VBScript) Set objController = CreateObject("WshController") На другому рядку, в якості параметрів для функції CreateScript вказується шлях до файлу сценарію, який буде виконаний на віддаленому комп'ютері і власне ім'я цього комп'ютера. Докладнішу статтю про цю технологію можна прочитати у статті Advanced VBScript for Microsoft Windows Administrators – Chapter 6: Remote Scripting(Див. Посилання). Планувальником завдань можна управляти з командного рядка, використовуючи дві утиліти – at.exe та schtasks.exe. Обидві ці утиліти дозволяють вказати ім'я віддаленого комп'ютера створення завдання, і, отже, дозволяють вирішити наше завдання. Але докладно ми розглянемо лише schtasks.exe, оскільки вона надає набагато більше можливостей. Хоча виконання команд на інших комп'ютерах не є основним призначенням планувальника, він дозволяє реалізувати чимало цікавих сценаріїв. Наприклад, за його допомогою можна увімкнути установку програмного забезпеченняу період обідньої перерви. Або якщо ваші користувачі обідають у різний час, запуск можна виконувати після певного періоду бездіяльності комп'ютера. schtasks /create /s server6.td.local /tn install /tr \\main\data\install.cmd /sc once /st 13:00 /ru system Важливо розуміти від імені якого облікового запису виконуватиметься завдання. У цьому прикладі я вказав параметр /ru значення system, отже, для виконання установки облікового запису комп'ютера буде необхідний доступ на читання в мережеву папкуз дистрибутивом програми. Ще корисним рішенням, мені здається запланувати будь-яку дію, на щоденне виконання, і видаляти завдання лише за підтвердження його успіху. Тобто ви можете створити простий командний файл, який спочатку запускає установник програми, чекає на його завершення, і перевіряє – чи успішно встановилася програма. Якщо це так, він видаляє завдання з планувальника на цьому комп'ютері. Приклад такого файлу: Лістинг №3 – Встановлення програми з подальшим видаленням завдання (Windows Batch) msiexec /qn /package \server\share\subinacl.msi WinRM – це реалізація відкритого стандарту DMTF (Distributed Management Task Force) від Microsoft, що дозволяє керувати системами за допомогою веб-служб. Заглиблюватися в пристрій технології я не буду, лише коротко опишу, що необхідно для її використання. Версія WinRM 1 і вище входить до складу операційних систем, починаючи з Windows Vista та Windows Server 2008. Для Windows XP та Windows Server 2003 можна встановити WinRM як окремий пакет (див. посилання). Для того, щоб швидко налаштувати комп'ютер для підключень до нього використовуючи стандартні порти та дозволивши підключення адміністративним обліковим записам, достатньо виконати команду: winrm quickconfig Щоб winrm не запитував підтвердження, можна додати до дзвінка ключ -quiet. Дізнатися інформацію про більш тонку настройку можна переглянути вбудовану довідку winrm: winrm help config Якщо на керованому комп'ютері працює веб-сервер, WinRM ніяк йому не завадить, хоч і використовує стандартні порти HTTP. Він перехоплюватиме лише підключення, призначені спеціально для нього. Вочевидь необов'язково виконувати цю команду вручну, кожному комп'ютері яким ви хочете управляти. Усі необхідні налаштування легко зробити за допомогою групових політик. Для цього потрібно: Незалежно від того, чи використовується порт HTTP (80) або HTTPS (443) трафік переданий WinRM шифрується (якщо звичайно ви не відключите цю опцію). Для стандартної автентифікації використовується протокол Kerberos. Але вистачить про налаштування, краще перейдемо безпосередньо до використання. Хоча утиліта winrm дозволяє настроювати службу WinRM, а також виконувати наприклад WMI запити, нам цікавіша інша – winrs. Літери RS тут означають Remote Shell. WinRS працює дуже схоже на PsExec хоч і використовує технологію WinRM. Ім'я комп'ютера задається ключем -r, а після нього слід команда, яку потрібно виконати. Ось кілька прикладів: winrs -r:Core ver.exe Оскільки winrs і так використовує cmd.exe як віддалену оболонку, в командах можна легко звертатися до віддалених змінних оточення, або використовувати інші вбудовані команди cmd.exe: winrs -r:Core "dir c:\temp > c:\temp\list.txt" Як і PsExec, утиліта winrs дозволяє відкрити інтерактивний сеанс на віддаленому комп'ютері: winrs -r:main cmd.exe Ця функція аналогічна telnet сесії, але використання winrs однозначно краще за telnet і навіть PsExec, з точки зору безпеки. Незалежно від того, чи використовується порт HTTP (80) або HTTPS (443), трафік переданий WinRM шифрується (якщо звичайно ви не відключите цю опцію). Для стандартної автентифікації використовується протокол Kerberos. Хоча друга версія Windows PowerShell на момент написання статті знаходиться ще в стані бета тестування, про її можливості в області віддаленого виконання команд виразно варто розповісти вже зараз. Спробувати його своїми руками ви можете завантажити попередню версію (див. посилання) або у складі бета-версії Windows 7 або Windows Server 2008 R2. Інфраструктура PowerShell Remoting заснована на WinRM версії 2.0, і тому успадковує всі переваги цієї технології, такі як шифрування даних, що передаються, і можливість працювати за стандартними портами HTTP/HTTPS. Але завдяки багатим можливостям мови Windows PowerShell та його здібностям роботи з об'єктами ми отримуємо ще більші можливості. На даний момент пакет WinRM2.0 теж знаходиться в стані бета-тестування, і доступний для завантаження лише для Windows Vista і Windows 2008. системи Windows 7 та Windows Server 2008R2 він буде вбудований спочатку, як і PowerShell 2.0. Оновлення: До моменту публікації статті на сайт, фінальні версії PowerShell 2.0 і WinRM 2.0 доступні вже для всіх підтримуваних платформ. До складу Windows Server 2008R2 і Windows 7 вони вже включені як невід'ємні компоненти системи, а для Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 необхідні компонентиможна отримати у вигляді пакета званого Windows Management Framework. Перед тим як скористатися всіма цими перевагами, PowerShell Remoting необхідно активізувати на керуючому і керованих комп'ютерах. Зробити це просто, запустивши командлет ( команду Windows PowerShell) Enable-PSRemoting. Причому якщо додати ключ -Force, то жодних підтверджень не буде запрошено. Цей командлет при необхідності викличе winrs quickconfig, і створить винятки в брандмауері Windows, так що додаткових дій виконувати не потрібно. Після цього ви зможете легко виконувати команди на інших комп'ютерах, використовуючи командлет Invoke-Command (або його псевдонім icm): Invoke-Command -ComputerName Main -ScriptBlock (netsh interface dump > c:\ipconfig.txt) Зрозуміло, команду можна заздалегідь помістити в змінну, а для параметра -ComputerName вказати імена не одного, а відразу кількох комп'ютерів. Наступна послідовність дозволяє вивести версію файлу Explorer.exe з трьох комп'ютерів. $Command = ((get-item c:\Windows\explorer.exe).VersionInfo.FileVersion) Як видно, можна передавати відразу кілька команд в одному блоці, поміщати їх результати виконання на декількох комп'ютерах у змінну, а потім обробляти на робочій станції, використовуючи можливості Windows PowerShell по роботі з об'єктами. Втім, можливості PowerShell Remoting на цьому тільки починаються. За допомогою командлета Enter-PSSession ви можете увійти в інтерактивну сесію Windows PowerShell на віддаленому комп'ютері. Вийти з такого сеансу можна, використовуючи командлет Exit-PSSession, або просто exit. Командлет New-PSSession створює сесії на віддалених комп'ютерах, покажчики на які можна помістити в змінну, а потім передаючи її як аргумент для Invoke-Command виконувати команди відразу на кількох комп'ютерах, у постійному оточенні. Приклад можна побачити на скріншоті, де я виконую послідовність команд відразу на декількох комп'ютерах зі списку c:\computers.txt. Цей метод відрізняється від усіх перелічених вище, і служить зовсім для інших завдань, але не менш актуальний. Коли делегування повноважень неможливе, або надає надто великі можливості, він дозволяє дозволити звичайному користувачеві виконувати якусь команду, яка потребує адміністративних привілеїв, жодним чином не надаючи додаткових повноважень та не підставляючи під загрозу пароль адміністратора. Найчастіше такі проблеми люди вирішують за допомогою утиліт типу cpau.exe (див. посилання) які створюють файл із зашифрованим паролем адміністративного облікового запису, що дозволяє запускати певну програму. Проблема, однак, у тому, що хоч пароль і зашифрований, перед запуском програми утиліті доведеться його розшифрувати. А відповідно користувач може використовувати утиліту, що повторює алгоритм розшифровки пароля, і дізнатися його, щоб потім використовувати для запуску інших програм або отримання додаткових привілеїв. Практично це звичайно досить складно для звичайних користувачів, Що не володіють спеціальними знаннями, але, тим не менш, цілком можливо. Ще раз уточню, це не біда конкретної утиліти, а проблема такого підходу загалом. Ще може здатися, що для вирішення задачі підійде параметр / savecred утиліти runas. Але тут є дві проблеми. По-перше, як і вищеописаному випадку, пароль зберігається на комп'ютері користувача, а, отже, може бути розшифрований, хоча у випадку з runas для цього знадобляться права локального адміністратора. По-друге, runas зберігає облікові дані, не пов'язуючи їх із конкретною командою, отже, користувач зможе запустити із завищеними правами як ту команду, доступ до якої ви хотіли йому надати, а й будь-яку іншу. Щоб уникнути цих проблем, проте дозволити виконання конкретної команди, можна використовувати методику, яка називається "проксуванням". Працює вона в такий спосіб. На комп'ютері постійно працює сценарій із високими привілеями. Наприклад, у нашому випадку він буде запущений з-під облікового запису, який має права адміністратора на файловому сервері. За сигналом користувача він виконуватиме одну, наперед визначену команду. У цьому прикладі – закривати всі файли, відкриті через мережу. Для організації цієї системи ми помістимо на сервері, наприклад, у папці c:\scripts\ командні файли Server.cmd і Action.cmd . Лістинг №4 - Server.cmd (Windows Batch) set trigger=c:\commandShare\trigger.txt Лістинг №5 – Action.cmd (Windows Batch) for /f "skip=4 tokens=1" %%a у ('net files') do net files %%a /close Server.cmd чекатиме знака від користувача (створення файлу в певному місці), і отримавши його, запускатиме файл з командами – Action.cmd. Зрозуміло, у цій папці користувачі не повинні мати жодного доступу. Автоматичний запуск Server.cmd при запуску комп'ютера можна організувати, створивши відповідне завдання в планувальнику: schtasks /create /ru domain\administrator /rp /sc onstart /tn ProxyScript /tr c:\scripts\server.cmd Після параметра /ru вказується обліковий запис, під якою буде виконуватися сценарій (у нашому випадку вона має права адміністратора на сервері), тому що після параметра /rp пароль не вказано - він буде запитаний при створенні завдання. Параметр /sc дозволяє вказати момент запуску сценарію, у нашому випадку – увімкнення комп'ютера. Ну а /tn і /tr дозволяють вказати ім'я завдання, і файл, що виконується. Тепер, для того, щоб користувач міг подати сценарієм сигнал, ми створимо папку c:\commandShare і зробимо її доступною по мережі. Доступ до запису в цю папку повинен мати лише користувачі, які запускатимуть команду. Після цього достатньо буде помістити користувачеві на робочий стіл файл Run.cmd. Лістинг №6 - Run.cmd (Windows Batch) echo test > \\server\commandShare\trigger.txt При його виконанні від імені користувача буде створюватися файл \\server\commandShare\trigger.txt. Сценарій Server.cmd, помітивши його, запустить на виконання зі своїми привілеями файл Action.cmd, додасть запис до файлу c:\scripts\log.txt про поточний час, а потім видалить trigger.txt щоб не виконувати команду знову до наступного сигналу користувача . У сценарії Server.cmd використовується утиліта Sleep.exe, що дозволяє зробити паузу у виконанні сценарію на заданий проміжок часу. Вона не входить до складу операційної системи, але її можна взяти з набору Resource Kit Tools і просто скопіювати на будь-який комп'ютер. Тут мінімум теорії, переважно практична частина. Описується як настроїти WinRM, як змінити профіль мережевого адаптера, дається скрипт з додавання в TrustedHosts з фільтрацією, пояснюється навіщо потрібні довірені хости, і розглядаються поверхнево віддалені підключення так, щоб можна було сісти і відразу відмінити віддалені машини. Найпростіший шлях налаштувати віддалене управління це виконати Enable-PSRemoting
в оболонці живлення з правами адміністратора. При цьому станеться таке: Для перевірки куди можна підключатися використовуємо: У хелпі вказані команди, я їх трохи переробив у скрипт Є різниця вказувати ім'я чи адресу. Якщо в TrustedHosts буде тільки адреса, то відкрити сесію на ім'я не вийде, і навпаки - якщо вказати ім'я то причепиться за адресою не вийде. Зважайте на це. у чому ж різниця Enable-PSRemoting робить більше дій, ніж «winrm quickconfig». Командлет Set-WSManQuickConfig робить такі самі дії як «winrm quickconfig». Enable-PSRemoting запускає Set-WSManQuickConfig коли веде налаштування системи Видалені підключення Обмеження такі: 2. Сесії 1-to-many Щоб передати повністю скрипт замість параметра -ScriptBlock пишемо -FilePath, віддаленій машині НЕ потрібно мати доступ до файлу, він буде розібраний на запчастини, переданий через HTTP і виконаний з того боку. $deployRemote = ( Invoke-Command -Session $session -ScriptBlock $deployRemote -ArgumentList ($targetEnvName, $targetUsername) 3. Сесії Створення сесії відбувається командлетом New-PSSession, результат можна помістити у змінну Як використовувати: Invoke-Command може створити відразу disconnected сесію, він відправляє команди на виконання та відключаться, пізніше можна підключитися та завантажити результати роботи. Робиться це параметром -Disconnected. Отримання результатів через командлет Recieve-PSSession. Сесії мають багато налаштувань, можливо навіть створення сесій з обрізаним набором команд, модулів і т.п. Називається custom endpoints
enter-pssession Server01
У командному рядку відображається ім'я комп'ютера, до якого ви підключені. Надалі всі команди, введені в командному рядку, запускатимуться на віддаленому комп'ютері, а результати відобразяться на локальному комп'ютері.
Щоб завершити інтерактивний сеанс, введіть:
exit-psession
Вихідні дані будуть повернуті на ваш комп'ютер.
Щоб запустити сценарій на одному або кількох віддалених комп'ютерах, використовуйте параметр FilePath командлета Invoke-Command. Сценарій повинен бути увімкненим або доступним для локального комп'ютера. Результати буде повернено на локальний комп'ютер.
Наприклад, наступна команда виконує сценарій DiskCollect.ps1 на віддалених комп'ютерах Server01 та Server02.
invoke-command -computername Server01, Server02 -filepath c:\Scripts\DiskCollect.ps1
Щоб виконати ряд пов'язаних команд із загальними даними, створіть сеанс на віддаленому комп'ютері, а потім використовуйте командлет Invoke-Command для виконання команд у створеному сеансі. Щоб створити віддалений сеанс, використовуйте командлет New-PSSession.
Наприклад, наступна команда створює віддалений сеанс на комп'ютері Server01 та інший віддалений сеанс на комп'ютері Server02. Вона зберігає об'єкти сеансу змінної $s.
$s = new-pssession -computername Server01, Server02
Після встановлення сеансів можна виконати будь-яку команду. Оскільки сеанси є постійними, ви можете збирати дані в одній команді та використовувати їх у наступній.
Наприклад, наступна команда виконує команду Get-Hotfix у сеансах змінної $s і зберігає результати змінної $h. Змінна $h створюється в кожному сеансі $s, але вона не існує в локальному сеансі.
invoke-command -session $s ($h = get-hotfix)
Тепер дані змінної $h можна використовувати в наступних командах, таких як наступна. Результати з'являться на локальному комп'ютері.PsExec.exe
Windows Management Instrumentation (WMI)
$Command = "cmd.exe /c systeminfo.exe >
("\\$Computer\root\cimv2:Win32_Process").create($Command)
Command = "cmd.exe /c systeminfo.exe > \\server\share\%computername%.txt"
Set objWMIService = GetObject("winmgmts:\\" & Computer & "\root\cimv2:Win32_Process")
Result = objWMIService.Create("calc.exe", Null, Null, intProcessID) WSH Remote Scripting
Видати групам Anonymous Logon та Everyone дозволи Allow Local та Allow Remote Access
Видати групі Administrators дозволи Allow Local Launch, Allow Remote Launch, Allow Local Activation, Allow Remote Activation
Групі Everyone – Allow Local Launch, Allow Local Activation
Set objRemoteScript = objController.CreateScript("C:\test.vbs", "PC5")WScript.ConnectObject objRemoteScript, "remote_"
objRemoteScript.Execute
Do While objRemoteScript.Status<> 1
WScript.Sleep 1000
Loop
MsgBox "Script complete"
Sub remote_Error
Dim objError
Set objError = objRemoteScript.Error
WScript.Echo "Error – Line: " & objError.Line & _
", Char: " & objError.Character & vbCrLf & _
"Description: " & objError.Description
WScript.Quit -1
End Sub Планувальник завдань (Task Scheduler)
if exist "c:\program files\Windows Resource Kits\Tools\subinacl.exe" (
subinacl /tn Install_Subinacl /f WinRM (WS-Management)
Windows PowerShell 2.0 Remoting
Invoke-Command -ComputerName Main, Server7, Replica -ScriptBlock $Command 
Проксування
set action=c:\scripts\action.cmd
set log=c:\scripts\log.txt
:start
if exist %trigger% start %action% & echo %time% %date%>>%log% & del %trigger%
sleep.exe 5
goto start
exit
Після цього потрібно дозволити підключатися до віддаленої машини з тієї машини, з якою відбуватиметься управління. Зроблено це з метою безпеки для того, щоб зменшити ризик злому сесії віддаленого керування або 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
!}
він перевіряє чи є такий запис, якщо ні то додає до списку. Викликати можна з командного рядка, вказавши адресу або ім'я.
1. Сесії 1-to-1
відкриваються командою
Enter-PSSession -ComputerName Test
Ви отримаєте оболонку на віддаленій машині. Підключитися можна до себе вказавши localhost. Альтернативні кредитали зазначаються з параметром -Credential, вихід відбувається командлетом Exit-PSSession
цей спосіб найкраще для простих операцій, зайшов, поторгав сервер і відключився. Якщо потрібно утримати змінні в скопі, потрібна тривала операція (багато годин або днів), потрібно більше можливостей з адміністрування, то потрібно використовувати техніку попросунутіше. Коментар.
об'єкти передані через мережу обрізаються і перестають бути живими. Вони видаляються методи, властивості залишаються. Витягти об'єкт на свою машину, почаклувати і засунути назад не вдасться. Якщо потрібно більше пишіть, допишу окремо.
Invoke-Command
визначаємо що виконуватимемо так:
$sb = ( команди для віддаленої машини розділені крапкою з комою )
передаємо на віддалені машини Test1 та Test2
Invoke-Command -ComputerName Test1, Test2 -ScriptBlock $sb
за раз можна закинути на 32 машини. Якщо альтернативні кредитали, то використовуємо параметр -CredentialЗапам'ятаємо, що на тій стороні буде новий скоп, так що ваш скрипт не отримає значень з вашої консолі, а змінні скрипти можуть виявитися на тому боці порожніми. Тому передавайте відразу готові інструкції і скрипти з параметрами.
для повноцінного використання Invoke-Command треба вміти перетворювати рядки на скрипт блоки. Наприклад, у вас є команди які залежать від якогось списку, вам потрібно згенерувати рядок, перетворити його на ScriptBlock і відправити на віддалений комп:
$sb = ::Create($SomeString) kuda78
У статті пропущено дуже важливий момент- Передача параметрів у скрипт на віддаленій машині.
param(
$targetEnvName,
$targetUsername)
$Global:ErrorActionPreference = "Stop"
#…
}
Так справді пропущений. Зробив свідомо, щоб не захаращувати огляд параметрами та описами. Дякую. Параметр -ArgumentList працює як зі скрипт блоками, так і зі сценаріями
Це коли з того боку створюється копія вишику постійно висить у пам'яті, і до неї відправляються команди. Як результат до неї можна перепідключитися, ченити довге запустити на виконання, чіплятися з різних скриптів або різними користувачами. Наприклад, у вас є набір скриптів, що вирішують одне завдання по частинах, кожен з них по черзі може підключатися до однієї віддаленої сесії, бачити результати роботи попередніх команд, мати одні завантажені модулі, загальні змінні, загальне оточення, доки сесія не буде примусово закрита.
$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
