PowerShell, WMI și CIM pentru automatizare avansată în sistemele Windows

Informatec Digital » Recursos » PowerShell, WMI și CIM pentru automatizare avansată în sistemele Windows

Dacă lucrezi administrând sisteme Windows, mai devreme sau mai târziu vei da peste PowerShell, WMI și automatizare avansată . Nu este vorba doar de a ști cum să execuți câteva comenzi: atunci când gestionezi zeci sau sute de servere, ai nevoie de o abordare serioasă, structurată și sigură pentru colectarea de informații, aplicarea modificărilor și repetarea sarcinilor fără a exagera... sau a strica ceva.

În rândurile următoare, vom explora, cu calm, dar în detaliu, cum să folosim comunicarea la distanță prin WMI, CIM și PowerShell pentru a automatiza totul, de la interogări simple până la scenarii complexe de infrastructură. Vom vedea, de asemenea, cum toate acestea se îmbină cu module, activități în fundal, Azure, Microsoft 365 și câteva funcții avansate care fac o diferență reală în munca zilnică a unui administrator de sistem.

Îmbunătățiri PowerShell și o prezentare generală a automatizării avansate

Windows PowerShell a evoluat foarte mult de la primele sale versiuni, iar o mare parte a acestei evoluții a venit odată cu Windows Server 2012, unde comunicarea la distanță a fost îmbunătățită, cmdlet-urile disponibile au fost extinse și aspecte precum depanarea, joburile în fundal și endpoint-urile restricționate au fost simplificate pentru a îmbunătăți securitatea.

Una dintre ideile cheie din spatele acestui mediu este că administratorii pot crea comportamente asemănătoare cmdlet-urilor fără codare extinsă , utilizând funcții avansate, module reutilizabile și un sistem de ajutor cuprinzător. Aceasta înseamnă că, în loc să vă bazați pe instrumente grafice disparate, puteți construi un set coerent de scripturi și module care automatizează procesele de gestionare a serverelor, rețelelor, Active Directory, Azure sau Microsoft 365.

În domeniul automatizării avansate, se remarcă și funcții precum joburi pentru executarea asincronă a sarcinilor, fluxuri de lucru, administrare bazată pe configurare cu PowerShell DSC și opțiuni de securitate precum JEA (Just Enough Administration) sau PowerShell Web Access, permițând un control detaliat asupra a ceea ce poate face fiecare persoană și de unde.

Întregul ecosistem se potrivește deosebit de bine cu WMI și CIM, deoarece informațiile de gestionare expuse de sistemul de operare (hardware, servicii, procese , configurația rețelei, software instalat etc.) devin un set de obiecte pe care le puteți interoga, filtra și modifica folosind comenzi PowerShell concepute pentru automatizare în masă.

WMI și CIM: Concepte cheie și diferențe practice

Instrumentația de administrare Windows, mai cunoscută sub numele de WMI, este o tehnologie independentă de PowerShell , care face parte din Windows de ani de zile. Aceasta expune un depozit de informații de administrare despre sistemul de operare, hardware și multe aplicații. Deși nu depinde de PowerShell, PowerShell îl utilizează extensiv pentru a automatiza sarcinile.

Succesorul natural al WMI în ecosistemul PowerShell sunt cmdlet-urile CIM (Common Information Model) , introduse odată cu PowerShell 3.0. Aceste cmdlet-uri sunt grupate în modulul CimCmdlets și includ comenzi precum Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance și Remove-CimInstance, printre altele.

În versiunile mai vechi de Windows PowerShell, cum ar fi Windows 10 PowerShell 5.1 sau Windows 11 PowerShell, puteți găsi în continuare cmdlet-urile WMI clasice (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Aceste cmdlet-uri, însă, sunt depreciate și nu mai sunt incluse în PowerShell 6 și versiunile ulterioare, deci sunt relevante doar pentru întreținerea scripturilor moștenite sau revizuirea codului vechi.

Când cineva vorbește despre „interogarea WMI cu cmdlet-uri CIM”, nu este o contradicție: cmdlet-urile CIM accesează în continuare informațiile WMI , dar o fac folosind protocoale mai moderne, cum ar fi WSMan, și o API mai consistentă. În practică, pentru noile dezvoltări, ar trebui să vă concentrați pe CIM și să luați în considerare cmdlet-urile WMI doar atunci când trebuie să migrați sau să înțelegeți scripturi vechi.

Din punct de vedere istoric, mulți administratori au folosit VBScript cu limbajul de interogare WQL pentru a interoga WMI, de exemplu, prin conectarea la spațiul de nume root\CIMV2 și interogarea claselor precum Win32_BIOS. Aceeași interogare WQL poate fi reutilizată astăzi cu Get-CimInstance prin transmiterea parametrului -Query, ceea ce simplifică foarte mult tranziția de la VBScript la PowerShell fără a fi nevoie să rescrieți logica de la zero.

Utilizarea practică a Get-CimInstance și a interogărilor eficiente

Pentru munca de zi cu zi, cea mai naturală modalitate de a interoga WMI cu PowerShell este să utilizați Get-CimInstance cu parametrul -ClassName , în loc să scrieți interogări WQL complete. De exemplu, pentru a obține informații despre BIOS, puteți utiliza Get-CimInstance -ClassName Win32_BIOS și veți primi un obiect cu proprietăți precum Manufacturer, Name, SerialNumber sau SMBIOSBIOSVersion.

Deoarece totul în PowerShell este un obiect, este foarte ușor să filtrați și să selectați doar ceea ce aveți nevoie . Dacă sunteți interesat doar de numărul de serie, puteți redirecționa rezultatul către `Select-Object -Property SerialNumber` sau puteți utiliza `Select-Object -ExpandProperty SerialNumber` pentru a genera un șir simplu în loc de un obiect cu o proprietate. O altă opțiune comună este utilizarea sintaxei punct (`Get-CimInstance ...`).SerialNumber` pentru a accesa direct valoarea.

Este demn de remarcat faptul că, în mod implicit, interogările WMI returnează mai multe proprietăți decât veți utiliza în realitate . Pe o mașină locală, acest lucru este de obicei în regulă, dar atunci când începeți să interogați mai multe mașini la distanță, acest lucru se traduce prin timp de procesare suplimentar și trafic de rețea inutil. Aici intervine parametrul `-Property` din `Get-CimInstance`, permițându-vă să limitați proprietățile care sunt preluate de la sursă.

Prin specificarea -Property SerialNumber, de exemplu, reduceți cantitatea de date transferate, ceea ce face ca interogarea să fie mai rapidă și mai eficientă, în special la scară largă . Această mentalitate de „cere doar ceea ce ai nevoie” este esențială atunci când se proiectează scripturi de inventar sau audit care rulează pe zeci sau sute de mașini.

În concluzie, Get-CimInstance oferă un echilibru puternic între simplitate (o singură linie de comandă) și flexibilitate , indiferent dacă lucrați cu clase concrete, interogări WQL vechi sau proprietăți specifice pe care doriți să le optimizați pentru regăsire.

Consultații la distanță cu CIM, sesiuni și protocoale WSMan/DCOM

Când te îndepărtezi de mașina locală și începi să accesezi mașini la distanță, intră în joc mai mulți factori: permisiunile, protocolul de comunicare și performanța . Deși mulți oameni consideră PowerShell „periculos”, adevărul este că nu îți acordă privilegii suplimentare: ai exact aceleași permisiuni ca și în cazul interfeței grafice sau al oricărui alt instrument, nici mai mult, nici mai puțin.

Dacă încercați să rulați `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` fără privilegii suficiente pe acea mașină, veți primi o eroare „Accesul este refuzat” . Acest lucru nu se datorează faptului că PowerShell eșuează; pur și simplu, utilizatorul cu care rulați sesiunea nu are dreptul de a accesa acele informații în WMI. Puteți deschide o consolă ca administrator de domeniu, desigur, dar asta înseamnă că orice comandă va fi executată cu aceste privilegii, ceea ce reprezintă un risc inutil în multe medii.

Recomandarea este să aplicați principiul privilegiilor minime și să ridicați privilegiile doar atunci când este necesar . În cmdlet-urile care acceptă parametrul -Credential, puteți specifica acreditări alternative doar pentru comanda în cauză. Get-CimInstance, însă, nu acceptă direct -Credential, iar aici intervine CimSessions ca o soluție elegantă.

O CimSession este o conexiune persistentă la un computer la distanță pe care o puteți crea cu New-CimSession, transmițând numele computerului și acreditările (de exemplu, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Această sesiune este stocată într-o variabilă, cum ar fi $CimSession, și apoi reutilizată cu Get-CimInstance utilizând parametrul -CimSession în loc de -ComputerName, permițându-vă să consolidați mai multe interogări într-o singură conexiune.

Pe lângă cerința de acreditări, Get-CimInstance utilizează protocolul WSMan (bazat pe WinRM) în mod implicit . Aceasta înseamnă că mașina la distanță trebuie să aibă versiunea 3.0 sau o versiune ulterioară a stivei WSMan, care se găsește de obicei în PowerShell 3.0 și versiunile ulterioare. Puteți verifica versiunea stivei WSMan pe o mașină cu `Test-WSMan -ComputerNameRemoteComputer` și verifica dacă valoarea „Stack” este 3.0 sau o versiune ulterioară pentru a utiliza această metodă de conectare.

Sesiuni CIM cu DCOM și compatibilitate inversă

Cmdlet-urile WMI mai vechi bazate pe Get-WmiObject se bazează pe protocolul DCOM, care este încă acceptat de versiunile mai vechi de Windows . Problema este că, pe sistemele mai moderne, firewall-urile blochează adesea DCOM în mod implicit, necesitând deschiderea anumitor porturi pentru a-l utiliza așa cum este, ceea ce poate încălca politicile de securitate ale organizației.

Cmdlet-urile CIM oferă o soluție intermediară puternică: puteți crea opțiuni de sesiune cu `New-CimSessionOption -Protocol Dcom` , le puteți salva într-o variabilă (de exemplu, `$DCOM`) și apoi le puteți combina cu `New-CimSession` pentru a genera o CimSession care utilizează DCOM în loc de WSMan. Acest lucru vă permite să vă conectați la servere foarte vechi, chiar și la cele anterioare Windows Server 2000, unde PowerShell nici măcar nu este instalat.

De obicei, este convenabil să stocați acreditările de administrator de domeniu sau acreditările pentru un cont cu privilegii ridicate într-o variabilă (de exemplu, $Cred = Get-Credential ) pentru a evita să le tastați de fiecare dată. Apoi, cu ceva de genul New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, puteți porni o CimSession peste DCOM către un server mai vechi care nu acceptă WSMan, dar are WMI.

Din perspectiva scriitorului de scenarii, principalul avantaj este că rezultatul comenzii `Get-CimInstance` nu se modifică în funcție de protocol : obțineți aceleași obiecte și proprietăți indiferent dacă utilizați WSMan sau DCOM. Acest lucru simplifică foarte mult logica, deoarece puteți încapsula detectarea protocolului corespunzător într-o funcție și puteți lăsa restul codului să funcționeze întotdeauna transparent cu CimSessions.

De fapt, este destul de comun să se creeze funcții personalizate care testează WSMan cu Test-WSMan și, dacă nu este disponibil, intră automat în DCOM folosind New-CimSessionOption. Acest lucru vă permite să standardizați crearea CimSession în medii mixte, atât cu servere moderne, cât și cu servere vechi, fără a replica logica conexiunii în toate scripturile.

Gestionarea, listarea și curățarea CimSessions

Când începeți să utilizați CimSessions pe scară largă, este important să le urmăriți pentru a evita acumularea de conexiuni inutile. Cu Get-CimSession, puteți lista toate sesiunile deschise , puteți vedea la ce mașină indică și puteți verifica ce protocol utilizează (WSMAN sau DCOM), ceea ce este foarte util pentru diagnosticarea problemelor de conectivitate sau autentificare.

De asemenea, puteți recupera acele sesiuni existente într-o variabilă, de exemplu $CimSession = Get-CimSession și le puteți utiliza într-o singură comandă Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS pentru a interoga mai multe computere simultan, combinând sesiunile WSMan și DCOM în aceeași operațiune.

După ce ați terminat de analizat aceste informații, este o idee bună să închideți sesiunile pentru a evita lăsarea resurselor deschise inutil. Cmdletul Get-CimSession | Remove-CimSession elimină simultan toate sesiunile CimSession active din profilul curent. Alternativ, puteți transmite sesiuni specifice cmdletului Remove-CimSession pentru a închide doar unele dintre ele.

Lucrul în acest mod vă permite să aveți cicluri controlate de conectare și deconectare , ceea ce este foarte recomandat atunci când utilizați scripturi în cadrul activităților programate, al registrelor de automatizare sau al conductelor de integrare continuă care pot lăsa sesiunile suspendate dacă nu planificați în mod explicit curățarea respectivă.

PowerShell ca limbaj de automatizare cuprinzător

Dincolo de WMI și CIM, PowerShell a devenit un limbaj de automatizare de uz general care depășește cu mult scriptul tipic de administrare Windows. Există cărți și cursuri întregi dedicate capabilităților sale avansate, acoperind totul, de la instalarea pe Linux și Windows până la dezvoltarea de module distribuibile prin NuGet și chiar medii de dezvoltare moderne precum Visual Studio Code.

Un punct de plecare obișnuit este înțelegerea temeinică a funcțiilor avansate ale PowerShell , care vă permit să definiți parametri, să efectuați validare, să generați rezultate structurate și să accesați ajutor integrat aproape la nivelul unui cmdlet nativ. De acolo, organizarea codului în module facilitează munca în colaborare în cadrul echipelor de operațiuni, deoarece puteți versiona și publica aceste module în repozitorii interne sau publice bazate pe NuGet.

Lucrul cu obiecte și clase personalizate este, de asemenea, esențial , deschizând calea către modele de date mult mai bogate decât scripturile liniare tipice. Acest lucru vă permite să încapsulați logica de business, să reutilizați structuri și să proiectați API-uri interne pentru propria echipă de management, toate bazate pe motorul PowerShell.

În domeniul automatizării avansate, joburile și fluxurile de lucru în fundal joacă un rol crucial , permițând gestionarea sarcinilor asincrone, executarea operațiunilor lungi fără a bloca consola și orchestrarea secvențelor complexe pe mai multe mașini. Aceste capabilități sunt perfecte pentru interogările în bloc către WMI/CIM și scenariile de administrare la distanță, unde este adesea necesar să se aștepte ca sistemele să implementeze modificări sau să returneze date.

O altă componentă cheie este PowerShell DSC (Desired State Configuration), care vă permite să definiți configurația dorită a unei infrastructuri (roluri, caracteristici, servicii, fișiere, setări de securitate etc.) și să aplicați aceste stări în mod repetat. Combinate cu informațiile obținute prin WMI/CIM, puteți detecta abateri, le puteți corecta proactiv și puteți menține medii consistente cu mai puțin efort manual.

Gestionare locală, la distanță și în cloud cu PowerShell

La nivel local, PowerShell oferă cmdlet-uri pentru gestionarea serviciilor de domeniu Active Directory , configurarea rețelelor și administrarea serverelor. În Windows 10 și versiunile ulterioare, integrarea este și mai profundă, permițându-vă să automatizați totul, de la crearea de site-uri web la gestionarea obiectelor Active Directory și configurarea adaptoarelor de rețea.

O componentă mai puțin cunoscută, dar foarte utilă, este PSProviders și PSDrives , care vă permit să tratați diferite locații de stocare (sistem de fișiere, registry, Active Directory etc.) ca și cum ar fi unități navigabile. Datorită acestui fapt, puteți, de exemplu, să creați grupuri Active Directory, chei de registry sau structuri de foldere pe computere la distanță folosind aceeași sintaxă pe care ați folosi-o pentru a naviga pe hard disk.

În ceea ce privește administrarea la distanță, PowerShell integrează un set puternic de funcții pentru conectarea la unul sau mai multe computere și executarea comenzilor în numele dumneavoastră . Puteți utiliza sesiuni PSSession persistente, tehnici avansate de remote, scenarii unu-la-mulți (pentru a gestiona mai multe servere simultan) sau scenarii unu-la-unu pentru depanarea cazurilor specifice. Toate acestea, desigur, respectând arhitectura și modelul de securitate al accesului la distanță.

Cloudul joacă, de asemenea, un rol fundamental astăzi. Cu Azure PowerShell și Azure Cloud Shell, puteți gestiona mașini virtuale, stocare și abonamente direct din linia de comandă. Instalarea modulelor Azure PowerShell și familiarizarea cu acestea sunt aproape obligatorii dacă gestionați medii hibride sau complet găzduite în Azure.

Pe de altă parte, PowerShell s-a impus și ca un instrument de referință pentru gestionarea Microsoft 365 (Exchange Online, SharePoint Online, Teams, utilizatori și licențe). De la crearea și gestionarea conturilor până la administrarea resurselor Exchange Online, inclusiv grupuri, site-uri SharePoint și Microsoft Teams, totul poate fi orchestrat cu scripturi care reduc drastic munca manuală pe portalul web.

Scriptare, conducte și cele mai bune practici de lucru

Pentru a profita la maximum de automatizarea avansată cu WMI și CIM, este esențial să stăpâniți modelul de conducte PowerShell . Spre deosebire de alte shell-uri, nu transmiteți text simplu, ci obiecte complete, permițându-vă să selectați, sortați, măsurați, filtrați, enumerați și transformați informații cu mare precizie.

Învățarea lucrului cu conducte implică utilizarea corectă a cmdlet-urilor de selecție și filtrare , înțelegerea modului de enumerare a obiectelor complexe și învățarea modului de transmitere a datelor între comenzi și scripturi fără a pierde informații. Acest lucru este întărit de utilizarea organizată a variabilelor, matricelor și tabelelor hash, care acționează ca structuri de date temporare pe care se construiește o logică mai avansată.

Următorul pas este scriptarea în sine: împachetarea comenzilor în scripturi reutilizabile cu control al fluxului (if, for, foreach), importul datelor din fișiere CSV sau alte formate, gestionarea datelor introduse de utilizator, gestionarea erorilor și înregistrarea evenimentelor. Toate acestea vă permit să treceți de la comenzi izolate la instrumente integrate mai robuste.

Depanarea și gestionarea erorilor sunt deosebit de importante în mediile de automatizare la scară largă cu WMI/CIM, deoarece o întrerupere a rețelei, o permisiune configurată greșit sau o clasă lipsă pot întrerupe un proces dacă nu sunt gestionate corespunzător. Cu blocuri try/catch, acțiuni de eroare configurabile și înregistrare detaliată a datelor, puteți anticipa și reacționa mai eficient la aceste situații.

În cele din urmă, tot ce ține de funcții și module completează cercul : semnați scripturi pentru a le asigura integritatea, împachetați funcțiile în module, distribuiți aceste module în depozite interne sau publice și creați un ecosistem de instrumente partajate în cadrul organizației dumneavoastră. În acest fel, orice dezvoltare nouă pe WMI, CIM sau remote este integrată într-o suită coerentă și ușor de întreținut.

Când combinați toate cele de mai sus — WMI/CIM, sesiuni la distanță, scripting, joburi asincrone, DSC, Azure și Microsoft 365 — obțineți un mediu în care automatizarea avansată cu PowerShell devine nucleul administrării. Cu o bază solidă de bune practici, utilizarea inteligentă a CimSessions (atât cu WSMan, cât și cu DCOM) și un design modular al scripturilor, puteți gestiona infrastructuri eterogene în mod consecvent, sigur și mult mai eficient decât bazându-vă exclusiv pe experți grafici sau instrumente izolate.