- 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 Management Instrumentation, по-известен като 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 cmdlets (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Тези cmdlets обаче са остарели и вече не са включени в 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 премахва всички активни CimSessions от текущия профил наведнъж. Като алтернатива, можете да предадете конкретни сесии на командлета Remove-CimSession, за да затворите само някои от тях.
Работата по този начин ви позволява да имате контролирани цикли на свързване и прекъсване , което е силно препоръчително, когато използвате скриптове в рамките на планирани задачи, автоматизирани runbooks или непрекъснати интеграционни канали, които могат да доведат до увисване на сесиите, ако не планирате изрично това почистване.
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) и модулен дизайн на скриптове, можете да управлявате хетерогенни инфраструктури последователно, сигурно и много по-ефективно, отколкото като разчитате единствено на графични помощници или изолирани инструменти.
