- Командлети CIM WMI та PowerShell дозволяють ефективно запитувати та змінювати локальну та віддалену інформацію про керування.
- CimSessions з WSMan або DCOM забезпечують безпечний та сумісний доступ до сучасного та застарілого мережевого обладнання.
- Використання розширених функцій, модулів, завдань та DSC перетворює PowerShell на повноцінну мову автоматизації інфраструктури.
- PowerShell інтегрує локальне, віддалене керування, керування Azure та Microsoft 365 в єдине середовище, зменшуючи повторювані ручні завдання.
Якщо ви працюєте адмініструванням систем Windows, рано чи пізно ви зіткнетеся з PowerShell, WMI та розширеною автоматизацією . Йдеться не лише про знання того, як виконати кілька команд: коли ви керуєте десятками чи сотнями серверів, вам потрібен серйозний, структурований та безпечний підхід до збору інформації, застосування змін та повторення завдань без божевілля… або будь-яких пошкоджень.
У наступних рядках ми спокійно, але ретельно розглянемо, як використовувати віддалений зв'язок WMI, CIM та PowerShell для автоматизації всього: від простих запитів до складних сценаріїв інфраструктури. Ми також побачимо, як усе це поєднується з модулями, фоновими завданнями, Azure, Microsoft 365 та деякими розширеними функціями, які дійсно впливають на щоденну роботу системного адміністратора.
Покращення PowerShell та огляд розширеної автоматизації
Windows PowerShell значно розвинувся з часів своїх ранніх версій, і значна частина цієї еволюції відбулася з Windows Server 2012, де було покращено віддалений зв'язок, розширено доступні командлети, а такі речі, як налагодження, фонові завдання та обмежені кінцеві точки, стали простішими для підвищення безпеки.
Одна з ключових ідей цього середовища полягає в тому, що адміністратори можуть створювати командлет-подібні моделі поведінки без складного кодування , використовуючи розширені функції, модулі багаторазового використання та комплексну систему довідки. Це означає, що замість того, щоб покладатися на різнорідні графічні інструменти, можна створити цілісний набір скриптів та модулів, які автоматизують процеси керування серверами, мережами, Active Directory, Azure або Microsoft 365.
У сфері розширеної автоматизації також виділяються такі функції, як завдання для асинхронного виконання завдань, робочі процеси, адміністрування на основі конфігурації за допомогою PowerShell DSC та параметри безпеки, такі як JEA (Just Enough Administration) або PowerShell Web Access, що дозволяють детально контролювати, що і звідки може робити кожна людина.
Вся ця екосистема особливо добре поєднується з WMI та CIM, оскільки інформація про управління, що надається операційною системою (апаратне забезпечення, служби, процеси , конфігурація мережі, встановлене програмне забезпечення тощо), стає набором об'єктів, які можна запитувати, фільтрувати та змінювати за допомогою команд PowerShell, призначених для масової автоматизації.
WMI та CIM: ключові концепції та практичні відмінності
Інструментарій керування Windows, більш відомий як WMI, — це технологія, незалежна від PowerShell, яка вже багато років є частиною Windows. Вона надає доступ до сховища інформації про управління операційною системою, обладнанням та багатьма програмами. Хоча вона не залежить від PowerShell, PowerShell широко використовує його для автоматизації завдань.
Природним наступником WMI в екосистемі PowerShell є командлети CIM (Common Information Model) , представлені в PowerShell 3.0. Ці командлети згруповані в модулі CimCmdlets і включають такі команди, як Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance та Remove-CimInstance, серед інших.
У старіших версіях Windows PowerShell, таких як Windows 10 PowerShell 5.1 або Windows 11 PowerShell, ви все ще можете знайти класичні командлети WMI (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Однак ці командлети застаріли та більше не включені до PowerShell 6 та пізніших версій, тому вони актуальні лише для підтримки застарілих скриптів або перегляду старого коду.
Коли хтось говорить про «запити WMI за допомогою командлетів CIM», це не суперечить: командлети CIM все ще отримують доступ до інформації WMI , але вони роблять це за допомогою сучасніших протоколів, таких як WSMan, та більш узгодженого API. На практиці, для нових розробок слід зосередитися на CIM та розглядати командлети WMI лише тоді, коли потрібно перенести дані або зрозуміти застарілі скрипти.
Історично багато адміністраторів використовували VBScript з мовою запитів WQL для запитів WMI, наприклад, підключаючись до простору імен root\CIMV2 та запитуючи класи, такі як Win32_BIOS. Той самий запит WQL можна повторно використовувати сьогодні за допомогою Get-CimInstance, передавши параметр -Query, що значно спрощує перехід від VBScript до PowerShell без необхідності переписувати логіку з нуля.
Практичне використання Get-CimInstance та ефективні запити
Для повсякденної роботи найприроднішим способом запиту WMI за допомогою PowerShell є використання Get-CimInstance з параметром -ClassName , а не написання повних WQL-запитів. Наприклад, щоб отримати інформацію про BIOS, можна використовувати Get-CimInstance -ClassName Win32_BIOS, і ви отримаєте об'єкт із такими властивостями, як Manufacturer, Name, SerialNumber або SMBIOSBIOSVersion.
Оскільки все в PowerShell є об'єктом, дуже легко фільтрувати та вибирати лише те, що вам потрібно . Якщо вас цікавить лише серійний номер, ви можете передати результат до `Select-Object -Property SerialNumber` або використати `Select-Object -ExpandProperty SerialNumber` для виведення простого рядка замість об'єкта з властивістю. Іншим поширеним варіантом є використання крапкового синтаксису (`Get-CimInstance ...`).SerialNumber` для безпосереднього доступу до значення.
Варто зазначити, що за замовчуванням запити WMI повертають більше властивостей, ніж ви фактично використовуватимете . На локальному комп'ютері це зазвичай нормально, але коли ви починаєте запитувати багато віддалених комп'ютерів, це призводить до додаткового часу обробки та непотрібного мережевого трафіку. Саме тут і стає в нагоді параметр `-Property` команди `Get-CimInstance`, який дозволяє обмежити, які властивості отримуються з джерела.
Наприклад, вказуючи -Property SerialNumber, ви зменшуєте обсяг даних, що передаються, що робить запит швидшим та ефективнішим, особливо у великих масштабах . Цей підхід «запитуйте лише те, що вам потрібно» є ключовим під час розробки сценаріїв інвентаризації або аудиту, які працюють на десятках або сотнях машин.
Підсумовуючи, Get-CimInstance пропонує потужний баланс між простотою (один командний рядок) та гнучкістю , незалежно від того, чи працюєте ви з конкретними класами, застарілими WQL-запитами чи певними властивостями, які потрібно оптимізувати для отримання.
Дистанційні консультації за допомогою CIM, сесій та протоколів WSMan/DCOM
Коли ви віддаляєтеся від своєї локальної машини та починаєте отримувати доступ до віддалених машин, в гру вступають кілька факторів: дозволи, протокол зв'язку та продуктивність . Хоча багато людей вважають PowerShell «небезпечним», правда полягає в тому, що він не надає вам жодних додаткових привілеїв: у вас є точно такі ж дозволи, як і з графічним інтерфейсом чи будь-яким іншим інструментом, ні більше, ні менше.
Якщо ви спробуєте запустити `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` без достатніх прав на цьому комп'ютері, ви отримаєте помилку "Доступ заборонено" . Це не тому, що PowerShell не працює; просто користувач, від імені якого ви запускаєте сеанс, не має права доступу до цієї інформації в WMI. Звичайно, ви можете відкрити консоль як адміністратор домену, але це означає, що будь-яка команда буде виконана з цими правами, що є зайвим ризиком у багатьох середовищах.
Рекомендується застосовувати принцип найменших привілеїв та підвищувати привілеї лише за необхідності . У командлетах, що підтримують параметр -Credential, можна вказати альтернативні облікові дані лише для відповідної команди. Однак Get-CimInstance не приймає -Credential безпосередньо, і саме тут CimSessions стає елегантним рішенням.
CimSession – це постійне підключення до віддаленого комп’ютера, яке можна створити за допомогою New-CimSession, передаючи ім’я комп’ютера та облікові дані (наприклад, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Цей сеанс зберігається у змінній, такій як $CimSession, а потім повторно використовується за допомогою Get-CimInstance за допомогою параметра -CimSession замість -ComputerName, що дозволяє об’єднати кілька запитів в одне підключення.
Окрім вимоги щодо облікових даних, Get-CimInstance за замовчуванням використовує протокол WSMan (на основі WinRM) . Це означає, що віддалений комп’ютер повинен мати стек WSMan версії 3.0 або вище, який зазвичай міститься в PowerShell 3.0 та пізніших версіях. Ви можете перевірити версію стека WSMan на комп’ютері за допомогою `Test-WSMan -ComputerName RemoteComputer` та переконатися, що значення "Stack" дорівнює 3.0 або вище, щоб використовувати цей метод підключення.
Сеанси CIM з DCOM та зворотною сумісністю
Старіші командлети WMI на основі Get-WmiObject покладаються на протокол DCOM, який досі підтримується старішими версіями Windows . Проблема полягає в тому, що в сучасніших системах брандмауери часто блокують DCOM за замовчуванням, вимагаючи від вас відкривати певні порти для його використання як є, що може порушувати політики безпеки вашої організації.
Командлети CIM пропонують потужний компроміс: ви можете створювати параметри сеансу за допомогою `New-CimSessionOption -Protocol Dcom` , зберігати їх у змінній (наприклад, `$DCOM`), а потім об'єднувати їх з `New-CimSession` для створення CimSession, який використовує DCOM замість WSMan. Це дозволяє підключатися до дуже старих серверів, навіть тих, що були випущені раніше Windows Server 2000, де PowerShell навіть не встановлено.
Зазвичай зручно зберігати облікові дані адміністратора домену або облікові дані для облікового запису з підвищеними правами у змінній (наприклад, $Cred = Get-Credential ), щоб уникнути необхідності вводити їх щоразу. Потім, за допомогою чогось на кшталт New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, можна розпочати CimSession через DCOM на старіший сервер, який не підтримує WSMan, але має WMI.
З точки зору автора скрипта, головною перевагою є те, що результат `Get-CimInstance` не змінюється залежно від протоколу : ви отримуєте ті самі об'єкти та властивості, незалежно від того, чи використовуєте ви WSMan, чи DCOM. Це значно спрощує логіку, оскільки ви можете інкапсулювати виявлення відповідного протоколу у функцію та дозволити решті коду завжди прозоро працювати з CimSessions.
Насправді, досить поширеною є створення користувацьких функцій, які тестують WSMan за допомогою Test-WSMan і, якщо він недоступний, автоматично переходять у DCOM за допомогою New-CimSessionOption. Це дозволяє стандартизувати створення CimSession у змішаних середовищах із сучасними та застарілими серверами, без копіювання логіки підключення у всіх ваших скриптах.
Керування, лістинг та очищення CimSessions
Коли ви починаєте інтенсивно використовувати CimSessions, важливо відстежувати їх, щоб уникнути накопичення непотрібних підключень. За допомогою Get-CimSession ви можете переглянути всі відкриті сесії , побачити, на яку машину вони вказують, і перевірити, який протокол вони використовують (WSMAN або DCOM), що дуже корисно для діагностики проблем із підключенням або автентифікацією.
Ви також можете отримати ці існуючі сесії у змінній, наприклад, $CimSession = Get-CimSession , та використовувати їх в одній команді Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS для одночасного запиту кількох комп'ютерів, об'єднуючи сесії WSMan та DCOM в одній операції.
Після завершення аналізу цієї інформації рекомендується закрити сеанси, щоб уникнути непотрібного залишення ресурсів відкритими. Командлет Get-CimSession | Remove-CimSession видаляє всі активні CimSession з поточного профілю одночасно. Або ж можна передати певні сеанси командлету Remove-CimSession, щоб закрити лише деякі з них.
Такий спосіб роботи дозволяє контролювати цикли підключення та відключення , що настійно рекомендується під час використання скриптів у запланованих завданнях, робочих книгах автоматизації або конвеєрах безперервної інтеграції, які можуть призвести до зависання сеансів, якщо ви явно не заплануєте це очищення.
PowerShell як комплексна мова автоматизації
Окрім WMI та CIM, PowerShell став універсальною мовою автоматизації , яка виходить далеко за рамки типового сценарію керування Windows. Існують книги та цілі курси, присвячені його розширеним можливостям, що охоплюють усе: від встановлення в Linux та Windows до розробки розповсюджуваних модулів через NuGet і навіть сучасних середовищ розробки, таких як Visual Studio Code.
Загальною відправною точкою є глибоке розуміння розширених функцій PowerShell , які дозволяють визначати параметри, виконувати перевірку, генерувати структурований вивід та отримувати доступ до інтегрованої довідки майже на рівні рідного командлета. Звідти, організація коду в модулі полегшує спільну роботу в операційних командах, оскільки ви можете створювати версії та публікувати ці модулі у внутрішніх або публічних репозиторіях на основі NuGet.
Робота з користувацькими об'єктами та класами також є ключовою , відкриваючи шлях до набагато багатших моделей даних, ніж типові лінійні скрипти. Це дозволяє інкапсулювати бізнес-логіку, повторно використовувати структури та розробляти внутрішні API для власної команди управління, і все це на базі рушія PowerShell.
У сфері розширеної автоматизації фонові завдання та робочі процеси відіграють вирішальну роль , дозволяючи керувати асинхронними завданнями, виконувати тривалі операції без блокування консолі та оркеструвати складні послідовності на кількох машинах. Ці можливості ідеально підходять для масових запитів до WMI/CIM та сценаріїв віддаленого адміністрування, де часто необхідно чекати, поки системи впровадять зміни або повернуть дані.
Ще одним ключовим компонентом є PowerShell DSC (Desired State Configuration), який дозволяє визначати бажану конфігурацію інфраструктури (ролі, функції, служби, файли, налаштування безпеки тощо) та застосовувати ці стани багаторазово. У поєднанні з інформацією, отриманою через WMI/CIM, ви можете виявляти відхилення, проактивно виправляти їх та підтримувати узгоджене середовище з меншими ручними зусиллями.
Локальне, віддалене та хмарне керування за допомогою PowerShell
На локальному рівні PowerShell надає командлети для керування службами доменів Active Directory , налаштування мереж та адміністрування серверів. У Windows 10 та пізніших версіях інтеграція ще глибша, що дозволяє автоматизувати все: від створення веб-сайтів до керування об'єктами Active Directory та налаштування мережевих адаптерів.
Менш відомим, але дуже корисним компонентом є PSProviders та PSDrives , які дозволяють обробляти різні місця зберігання (файлова система, реєстр, Active Directory тощо) так, ніби вони є навігаційними дисками. Завдяки цьому ви можете, наприклад, створювати групи Active Directory, розділи реєстру або структури папок на віддалених комп’ютерах, використовуючи той самий синтаксис, який ви використовували б для навігації по жорсткому диску.
Щодо віддаленого адміністрування, PowerShell інтегрує потужний набір функцій для підключення до одного або кількох комп'ютерів та виконання команд від вашого імені . Ви можете використовувати постійні сесії PSSession, розширені методи віддаленого доступу, сценарії «один до багатьох» (для одночасного керування кількома серверами) або сценарії «один до одного» для налагодження конкретних випадків. Все це, звичайно, з дотриманням архітектури та моделі безпеки віддаленого доступу.
Хмара також відіграє фундаментальну роль сьогодні. За допомогою Azure PowerShell та Azure Cloud Shell ви можете керувати віртуальними машинами, сховищами та підписками безпосередньо з командного рядка. Встановлення модулів Azure PowerShell та ознайомлення з ними майже обов'язкове, якщо ви керуєте гібридними або повністю розміщеними в Azure середовищами.
З іншого боку, PowerShell також зарекомендував себе як універсальний інструмент для керування Microsoft 365 (Exchange Online, SharePoint Online, Teams, користувачі та ліцензії). Від створення та керування обліковими записами до адміністрування ресурсів Exchange Online, включаючи групи, сайти SharePoint та Microsoft Teams, все можна керувати за допомогою скриптів, які значно скорочують ручну роботу на веб-порталі.
Скрипти, конвеєри та найкращі методи роботи
Щоб отримати максимальну віддачу від розширеної автоматизації за допомогою WMI та CIM, важливо опанувати модель конвеєра PowerShell . На відміну від інших оболонок, тут ви не передаєте звичайний текст, а скоріше повні об'єкти, що дозволяє вам вибирати, сортувати, вимірювати, фільтрувати, перераховувати та перетворювати інформацію з великою точністю.
Навчання роботі з конвеєрами включає правильне використання командлетів вибору та фільтрації , розуміння того, як перераховувати складні об'єкти, та навчання передачі даних між командами та скриптами без втрати інформації. Це підкріплюється організованим використанням змінних, масивів та хеш-таблиць, які діють як тимчасові структури даних, на яких можна будувати складнішу логіку.
Наступний крок – це власне написання скриптів: пакування команд у скрипти багаторазового використання з керуванням потоком (if, for, foreach), імпорт даних з CSV-файлів або інших форматів, обробка введених користувачем даних, обробка помилок та ведення журналу подій. Все це дозволяє перейти від ізольованих команд до більш потужних вбудованих інструментів.
Усунення несправностей та обробка помилок особливо важливі у масштабних середовищах автоматизації з WMI/CIM, оскільки збій мережі, неправильно налаштовані дозволи або відсутній клас можуть перервати процес, якщо ними не керувати належним чином. Завдяки блокам try/catch, налаштованим діям у разі помилок та детальному веденню журналу ви можете передбачати та ефективніше реагувати на ці ситуації.
Зрештою, все, що пов'язано з функціями та модулями, завершує коло : ви підписуєте скрипти для забезпечення їхньої цілісності, пакуєте функції в модулі, розповсюджуєте ці модулі у внутрішніх або публічних репозиторіях та створюєте екосистему спільних інструментів у вашій організації. Таким чином, будь-яка нова розробка WMI, CIM або віддаленої взаємодії інтегрується в цілісний та легко підтримуваний пакет.
Коли ви поєднуєте все вищезазначене — WMI/CIM, віддалені сеанси, сценарії, асинхронні завдання, DSC, Azure та Microsoft 365 — ви отримуєте середовище, де розширена автоматизація за допомогою PowerShell стає основою адміністрування. Завдяки міцній основі передових практик, інтелектуальному використанню CimSessions (як з WSMan, так і з DCOM) та модульній конструкції сценаріїв, ви можете керувати гетерогенними інфраструктурами послідовно, безпечно та набагато ефективніше, ніж покладаючись виключно на графічні майстри або ізольовані інструменти.
