1. PsExec.exe
2. Windows Management Instrumentation (WMI)
3. WSH Remote Scripting
4. Планувальник завдань (Task Scheduler)
5. WinRM (WS-Management)
6. Windows PowerShell 2.0 Remoting
7. проксінг
8. ПОСИЛАННЯ

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

Так як завдання це популярна, то і способів її рішення існує безліч. Починаючи від групових політик (в яких можна застосовувати для цієї мети сценарії входу в систему або автозавантаження), і закінчуючи потужними системами управління, на зразок System Center Essentials або System Center Configuration Manager. Але я в цій статті хочу розглянути методи, які доступні відразу з командного рядка або файлів сценаріїв, а так само не вимагають попередньої установки агентів та іншої метушні. Втім, якісь попередні вимоги звичайно є. Наприклад, у вас повинні бути адміністративні повноваження на тому комп'ютері, на якому ви хочете виконати команду (за винятком сценарію з «проксінг», але про це пізніше).

PsExec.exe

Один з моїх улюблених способів для вирішення цього завдання це утиліта командного рядка 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)

Наступний спосіб реалізації цієї популярної завдання, про яке я хочу розповісти - використання Windows Management Instrumentation. WMI присутній у всіх операційних системах Microsoft, починаючи з Windows 2000, і навіть на Windows 9x його можна встановити з окремого пакета. WMI включений за замовчуванням, і не вимагає додаткової настройки. Для його використання досить адміністративних прав, і дозволеного на брандмауері протоколу DCOM. WMI надає величезні можливості для управління системами, але нас зараз цікавить лише одна з них.

Для запуску процесів нам потрібно метод Create класу Win32_Process. Використовувати його досить нескладно. У PowerShell це робиться в такий спосіб:

$ Computer = "main"
$ Command = "cmd.exe / c systeminfo.exe> ​​\\ server \ share \% computername% .txt"
([Wmiclass] "\\ $ Computer \ root \ cimv2: Win32_Process"). Create ($ Command)

Тут в якості запускається процесу я вказав cmd.exe, а вже йому, в якості аргументів передав потрібну команду. Це необхідно в разі якщо вам потрібно використовувати змінні оточення віддаленого комп'ютера або вбудовані оператори cmd.exe, такі як «>» для перенаправлення виводу в файл. Метод Create не чекає завершення процесу, і не повертає результатів, але зате повідомляє нам його ідентифікатор - ProcessID.

Якщо ви використовуєте комп'ютер, на якому поки не встановлено PowerShell, ви можете викликати цей метод WMI і зі сценарію на VBScript. Наприклад ось так:

Лістинг №1 - Запуск процесу використовуючи WMI (VBScript)

Computer = "PC3"
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)

Але набагато простіше скористатися утилітою командного рядка wmic.exe яка надає досить зручний інтерфейс для роботи з WMI і входить до складу операційних систем, починаючи з Windows XP. У ній щоб запустити, наприклад калькулятор на комп'ютері main досить виконати наступну команду:

wmic / node: main process call create calc.exe

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

WSH Remote Scripting

Так, як не дивно у Windows Script Host теж є можливість запуску сценаріїв на інших комп'ютерах. Правда ця функція не отримала велику популярність, і швидше за все через те що вимагає занадто багато підготовчих заходів, а натомість надає зовсім небагато можливостей. Але я все одно розповім про цей метод, так як і він може стати в нагоді.

Отже, для запуску сценарію на іншому комп'ютері за допомогою WSH нам знадобиться зробити наступне:

1. Права адміністратора на віддаленому комп'ютері. Це само собою зрозуміло, і потрібно майже для всіх інших методів запуску перерахованих в цій статті.

2. Дозволити WSH Remote Scripting створивши в системному реєстрі строкової параметр Remote рівний "1" в ключі реєстру HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows Script Host \ Settings

3. Через помилки описаної в статті бази знань Microsoft з номером 311269, на системах з Windows XP може знадобитися виконати команду wscript -regserver

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

5. У системах Windows XP з пакетом оновлень 2 і вище, необхідно змінити параметри безпеки DCOM. Це можна зробити за допомогою групової політики. У вузлі Computer Configuration \ Windows Settings \ Security Settings \ Local Policies \ Security Options слід встановити дозволу наступним чином:

   1. DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
      Видати групам Anonymous Logon і Everyone дозволу Allow Local і Allow Remote Access

   2. DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
      Видати групі Administrators дозволу Allow Local Launch, Allow Remote Launch, Allow Local Activation, Allow Remote Activation
      Групі Everyone - Allow Local Launch, Allow Local Activation

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

Приклад сценарію, який використовує цю технологію:

Лістинг №2 - WSH remote scripting (VBScript)

Set objController = CreateObject ( "WshController")
Set objRemoteScript = objController.CreateScript ( "C: \ test.vbs", "PC5") WScript.ConnectObject objRemoteScript, "remote_"
objRemoteScript.Execute
Do While objRemoteScript.Status <> 1
WScript.Sleep тисячі
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

На другий його рядку, в якості параметрів для функції CreateScript вказується шлях до файлу сценарію, який буде виконаний на віддаленому комп'ютері і власне ім'я цього комп'ютера.

Більш докладну статтю про цю технологію можна прочитати в статті Advanced VBScript for Microsoft Windows Administrators - Chapter 6: Remote Scripting (див. Посилання).

Планувальник завдань (Task Scheduler)

Планувальником завдань можна керувати з командного рядка використовуючи дві утиліти - 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
if exist "c: \ program files \ Windows Resource Kits \ Tools \ subinacl.exe" (
subinacl / tn Install_Subinacl / f
)

WinRM (WS-Management)

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. Він буде перехоплювати лише підключення призначені спеціально для нього.

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

1. Налаштувати службу WinRM (Windows Remote Management) на автоматичний запуск
2. Налаштувати елемент групової політики Computer Configuration \ Administrative Templates \ Windows Components \ Windows Remote Management (WinRM) \ WinRM Service \ Allow automatic configuration of listeners. Тут потрібно вказати діапазони IP-адрес з яких вирішуються підключення.
3. Зрозуміло, ще вам буде необхідно дозволити підключення на відповідні порти (за замовчуванням 80) в брандмауері Windows.

Незалежно від того чи використовується порт 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 2.0 Remoting

Хоча друга версія 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.

Оновлення: До моменту публікації статті на ItBand.ru, фінальні версії 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}
Invoke-Command -ComputerName Main, Server7, Replica -ScriptBlock $ Command

Як видно на, можна передавати відразу декілька команд в одному блоці, поміщати їх результати виконання на кількох комп'ютерах в змінну, а потім обробляти на робочої станції використовуючи можливості 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
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

Лістинг №5 - Action.cmd (Windows Batch)

for / f "skip = 4 tokens = 1" %% a in ( 'net files') do net files %% a / close
exit

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 (див. Посилання) і просто скопіювати на будь-який комп'ютер.

ПОСИЛАННЯ

PsExec.exe

Windows SysInternals

http://www.script-coding.info/WMI_Processes.html

BUG: You receive an "ActiveX component can not create object" error message when you Use Windows Script Host to execute remote script

Advanced VBScript for Microsoft Windows Administrators - Chapter 6: Remote Scripting

Ви все ще не використовуєте WMI? Частина 1

Ви все ще не використовуєте WMI? Частина 2

Дізнайся секрети WMI: події і провайдери

Дізнайся секрети WMI: події і провайдери

WS-Management v1.1 для Windows XP і Windows Server 2003

CPAU.exe

Windows PowerShell 1.0

Windows PowerShell 2.0 Community Technology Preview 3 -

WinRM 2.0 Community Technology Preview 3

Windows Server 2003 Resource Kit Tools

Раніше стаття була опублікована в журналі Windows IT Pro RE в №4 за 2009 рік.

Василь Гусєв

http://xaegr.wordpress.com/