„PowerShell“, WMI ir CIM pažangiai automatizacijai „Windows“ sistemose

Informatec Digital » Ištekliai » „PowerShell“, WMI ir CIM pažangiai automatizacijai „Windows“ sistemose

Jei dirbate administruodami „Windows“ sistemas, anksčiau ar vėliau susidursite su „PowerShell“, WMI ir pažangia automatizacija . Neužtenka tik žinoti, kaip vykdyti kelias komandas: kai valdote dešimtis ar šimtus serverių, jums reikia rimto, struktūrizuoto ir saugaus požiūrio į informacijos rinkimą, pakeitimų taikymą ir užduočių kartojimą, nepereinant iš proto... ir nieko nesugadinant.

Toliau ramiai, bet nuodugniai panagrinėsime, kaip panaudoti WMI, CIM ir „PowerShell“ nuotolinį ryšį , siekiant automatizuoti viską – nuo ​​paprastų užklausų iki sudėtingų infrastruktūros scenarijų. Taip pat pamatysime, kaip visa tai dera su moduliais, foninėmis užduotimis, „Azure“, „Microsoft 365“ ir kai kuriomis išplėstinėmis funkcijomis, kurios iš esmės pakeičia sistemos administratoriaus kasdienį darbą.

„PowerShell“ patobulinimai ir išplėstinės automatizacijos apžvalga

„Windows PowerShell“ nuo ankstyvųjų versijų labai vystėsi , ir didelė šios evoliucijos dalis įvyko su „Windows Server 2012“, kur buvo patobulintas nuotolinis ryšys, išplėstos galimos cmdlet'ų parinktys ir supaprastinti tokie dalykai kaip derinimas, foninės užduotys ir apriboti galiniai taškai, siekiant pagerinti saugumą.

Viena iš pagrindinių šios aplinkos idėjų yra ta, kad administratoriai gali kurti cmdlet tipo elgseną be ilgo programavimo , pasitelkdami pažangias funkcijas, pakartotinai naudojamus modulius ir išsamią pagalbos sistemą. Tai reiškia, kad užuot pasikliovę skirtingais grafiniais įrankiais, galite sukurti nuoseklų scenarijų ir modulių rinkinį, kuris automatizuoja serverių, tinklų, „Active Directory“, „Azure“ ar „Microsoft 365“ valdymo procesus.

Pažangios automatizacijos srityje išsiskiria tokios funkcijos kaip asinchroninis užduočių vykdymas, darbo eigos, konfigūracija pagrįstas administravimas naudojant „PowerShell DSC“ ir saugumo parinktys, tokios kaip JEA („Just Enough Administration“) arba „PowerShell Web Access“, leidžiančios išsamiai kontroliuoti, ką ir iš kur kiekvienas asmuo gali daryti.

Visa ši ekosistema ypač gerai dera su WMI ir CIM, nes operacinės sistemos teikiama valdymo informacija (aparatinė įranga, paslaugos, procesai , tinklo konfigūracija, įdiegta programinė įranga ir kt.) tampa objektų rinkiniu, kurį galite užklausti, filtruoti ir modifikuoti naudodami masiniam automatizavimui skirtas „PowerShell“ komandas.

WMI ir CIM: pagrindinės sąvokos ir praktiniai skirtumai

„Windows Management Instrumentation“, geriau žinoma kaip WMI, yra nuo „PowerShell“ nepriklausoma technologija, kuri jau daugelį metų yra „Windows“ dalis. Ji teikia valdymo informacijos apie operacinę sistemą, aparatinę įrangą ir daugelį programų saugyklą. Nors ji nepriklauso nuo „PowerShell“, „PowerShell“ plačiai ją naudoja užduotims automatizuoti.

Natūralus WMI įpėdinis „PowerShell“ ekosistemoje yra CIM (bendrojo informacijos modelio) cmdlet , pristatytos kartu su „PowerShell 3.0“. Šios cmdlet yra sugrupuotos „CimCmdlets“ modulyje ir apima tokias komandas kaip „Get-CimInstance“, „Get-CimClass“, „New-CimInstance“, „Invoke-CimMethod“, „Register-CimIndicationEvent“, „Set-CimInstance“ ir „Remove-CimInstance“.

Senesnėse „Windows PowerShell“ versijose, pvz., „Windows 10 PowerShell 5.1“ arba „Windows 11 PowerShell“, vis dar galite rasti klasikines WMI cmdlet komandas („Get-WmiObject“, „Invoke-WmiMethod“, „Register-WmiEvent“, „Remove-WmiObject“, „Set-WmiInstance“). Tačiau šios cmdlet komandos yra nebenaudojamos ir nebėra įtrauktos į „PowerShell 6“ ir naujesnes versijas, todėl jos svarbios tik palaikant senus scenarijus arba peržiūrint seną kodą.

Kai kas nors kalba apie „WMI užklausų teikimą naudojant CIM cmdlet“, tai nėra prieštaravimas: CIM cmdlet vis dar pasiekia WMI informaciją , tačiau tai daro naudodamos modernesnius protokolus, tokius kaip WSMan, ir nuoseklesnę API. Praktiškai, kuriant naujus sprendimus, reikėtų sutelkti dėmesį į CIM ir svarstyti WMI cmdlet tik tada, kai reikia perkelti arba suprasti senus scenarijus.

Anksčiau daugelis administratorių naudojo VBScript su WQL užklausų kalba, kad pateiktų užklausas WMI, pavyzdžiui, prisijungdami prie root\CIMV2 vardų srities ir pateikdami užklausas tokioms klasėms kaip Win32_BIOS. Tą pačią WQL užklausą šiandien galima pakartotinai panaudoti naudojant Get-CimInstance, perduodant parametrą -Query, kuris labai supaprastina perėjimą iš VBScript į PowerShell, nereikalaujant perrašyti logikos nuo nulio.

Praktinis „Get-CimInstance“ naudojimas ir efektyvios užklausos

Kasdieniam darbui natūraliausias būdas pateikti WMI užklausą naudojant „PowerShell“ yra naudoti „Get-CimInstance“ su „-ClassName“ parametru , o ne rašyti visas WQL užklausas. Pavyzdžiui, norėdami gauti BIOS informaciją, galite naudoti „Get-CimInstance -ClassName Win32_BIOS“ ir gausite objektą su tokiomis savybėmis kaip gamintojas, pavadinimas, serijos numeris arba SMBIOSBIOSVersion.

Kadangi viskas „PowerShell“ sistemoje yra objektas, labai lengva filtruoti ir pasirinkti tik tai, ko jums reikia . Jei jus domina tik serijos numeris, rezultatą galite nukreipti į `Select-Object -Property SerialNumber` arba naudoti `Select-Object -ExpandProperty SerialNumber`, kad išvestumėte paprastą eilutę, o ne objektą su savybe. Kitas įprastas variantas yra naudoti taškų sintaksę (`Get-CimInstance ...`).SerialNumber`), kad tiesiogiai pasiektumėte reikšmę.

Verta paminėti, kad pagal numatytuosius nustatymus WMI užklausos grąžina daugiau ypatybių, nei iš tikrųjų naudosite . Vietiniame kompiuteryje tai paprastai tinka, tačiau kai pradedate užklausas teikti daugeliui nuotolinių kompiuterių, tai reiškia papildomą apdorojimo laiką ir nereikalingą tinklo srautą. Čia praverčia `Get-CimInstance` parametras `-Property`, leidžiantis apriboti, kurios ypatybės gaunamos iš šaltinio.

Pavyzdžiui, nurodydami „-Property SerialNumber“, sumažinate perduodamų duomenų kiekį, todėl užklausa tampa greitesnė ir efektyvesnė, ypač dideliu mastu . Šis „klauskite tik to, ko jums reikia“ mentalitetas yra labai svarbus kuriant inventoriaus ar audito scenarijus, kurie veikia dešimtyse ar šimtuose mašinų.

Apibendrinant galima teigti, kad „Get-CimInstance“ siūlo puikų balansą tarp paprastumo (viena komandinė eilutė) ir lankstumo , nesvarbu, ar dirbate su konkrečiomis klasėmis, senosiomis WQL užklausomis, ar konkrečiomis savybėmis, kurias norite optimizuoti paieškai.

Nuotolinės konsultacijos naudojant CIM, sesijas ir WSMan/DCOM protokolus

Kai išeinate iš savo vietinio kompiuterio ir pradedate jungtis prie nuotolinių kompiuterių, atsiranda keletas veiksnių: leidimai, ryšio protokolas ir našumas . Nors daugelis žmonių „PowerShell“ laiko „pavojingu“, tiesa ta, kad jis nesuteikia jokių papildomų privilegijų: turite lygiai tokias pačias teises kaip ir naudodami grafinę sąsają ar bet kurį kitą įrankį – nei daugiau, nei mažiau.

Jei bandysite paleisti `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` neturėdami pakankamai teisių tame kompiuteryje, gausite klaidą „Prieiga denied“ . Taip nėra todėl, kad „PowerShell“ neveikia; tiesiog vartotojas, kurio vardu vykdote sesiją, neturi teisės pasiekti šios informacijos WMI. Žinoma, galite atidaryti konsolę kaip domeno administratorius, tačiau tai reiškia, kad bet kokia komanda bus vykdoma su šiomis teisėmis, o tai daugelyje aplinkų kelia nereikalingą riziką.

Rekomenduojama taikyti mažiausių privilegijų principą ir didinti privilegijas tik tada, kai to reikia . Komandinėse komandose, kurios palaiko parametrą „-Credential“, galite nurodyti alternatyvius kredencialus tik atitinkamai komandai. Tačiau „Get-CimInstance“ tiesiogiai nepriima parametro „-Credential“, ir čia elegantiškas sprendimas yra „CimSessions“.

„CimSession“ yra nuolatinis ryšys su nuotoliniu kompiuteriu, kurį galite sukurti naudodami „New-CimSession“, perduodami kompiuterio pavadinimą ir kredencialus (pvz., „New-CimSession -ComputerName dc01 -Credential (Get-Credential)“). Šis seansas saugomas kintamajame, pvz., „$CimSession“, o tada pakartotinai naudojamas su „Get-CimInstance“ naudojant parametrą „-CimSession“ vietoj parametro „-ComputerName“, taip sujungdami kelias užklausas į vieną ryšį.

Be kredencialų reikalavimo, „Get-CimInstance“ pagal numatytuosius nustatymus naudoja WSMan protokolą (pagrįstą „WinRM“) . Tai reiškia, kad nuotoliniame kompiuteryje turi būti įdiegta WSMan steko 3.0 arba naujesnė versija, paprastai randama „PowerShell 3.0“ ir naujesnėse versijose. Galite patikrinti WSMan steko versiją kompiuteryje naudodami „Test-WSMan -ComputerName RemoteComputer“ ir įsitikinti, kad „Stack“ reikšmė yra 3.0 arba naujesnė, kad būtų galima naudoti šį ryšio metodą.

CIM sesijos su DCOM ir atgaliniu suderinamumu

Senesnės WMI cmdlet, pagrįstos „Get-WmiObject“, remiasi DCOM protokolu, kurį vis dar palaiko senesnės „Windows“ versijos . Problema ta, kad modernesnėse sistemose užkardos dažnai pagal numatytuosius nustatymus blokuoja DCOM, todėl norint jį naudoti tokį, koks yra, reikia atidaryti konkrečius prievadus, o tai gali pažeisti jūsų organizacijos saugumo politiką.

CIM cmdlet siūlo veiksmingą kompromisą: galite kurti seanso parinktis naudodami „New-CimSessionOption -Protocol Dcom“ , išsaugoti jas kintamajame (pvz., „$DCOM“) ir sujungti su „New-CimSession“, kad sugeneruotumėte „CimSession“, kuris naudoja DCOM, o ne WSMan. Tai leidžia prisijungti prie labai senų serverių, net ir tų, kurie sukurti anksčiau nei „Windows Server 2000“, kur net neįdiegta „PowerShell“.

Paprastai domeno administratoriaus arba aukštesnio lygio paskyros kredencialus patogu saugoti kintamajame (pvz., $Cred = Get-Credential ), kad nereikėtų jų kaskart įvesti. Tada, naudodami kažką panašaus į New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, galite pradėti „CimSession“ per DCOM su senesniu serveriu, kuris nepalaiko WSMan, bet turi WMI.

Scenarijaus autoriaus požiūriu, pagrindinis privalumas yra tas, kad „Get-CimInstance“ išvestis nesikeičia priklausomai nuo protokolo : gaunate tuos pačius objektus ir ypatybes, nesvarbu, ar naudojate WSMan, ar DCOM. Tai labai supaprastina logiką, nes galite įtraukti tinkamo protokolo aptikimą į funkciją ir leisti likusiai kodo daliai visada veikti skaidriai su „CimSessions“.

Iš tiesų, gana įprasta kurti pasirinktines funkcijas, kurios testuoja WSMan naudojant Test-WSMan ir, jei jis nepasiekiamas, automatiškai patenka į DCOM naudojant New-CimSessionOption. Tai leidžia standartizuoti CimSession kūrimą mišriose aplinkose su moderniais ir senaisiais serveriais, nekopijuojant ryšio logikos visuose scenarijuose.

„CimSessions“ valdymas, sąrašų sudarymas ir valymas

Kai pradedate plačiai naudoti „CimSessions“, svarbu juos sekti, kad nesusikauptų nereikalingų ryšių. Naudodami „Get-CimSession“, galite išvardyti visus atidarytus seansus , pamatyti, į kurį kompiuterį jie nukreipia, ir patikrinti, kokį protokolą jie naudoja (WSMAN arba DCOM), o tai labai naudinga diagnozuojant ryšio ar autentifikavimo problemas.

Taip pat galite gauti tuos esamus seansus kintamajame, pvz. , $CimSession = Get-CimSession , ir naudoti juos vienoje komandoje Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS, kad vienu metu pateiktumėte užklausą keliems kompiuteriams, sujungdami WSMan ir DCOM seansus toje pačioje operacijoje.

Baigus analizuoti šią informaciją, rekomenduojama uždaryti seansus, kad ištekliai nebūtų be reikalo atidaryti. „ Get-CimSession | Remove-CimSession“ cmdlet vienu metu pašalina visas aktyvias „CimSession“ sesijas iš dabartinio profilio. Arba galite perduoti konkrečias sesijas „Remove-CimSession“ cmdlet, kad uždarytumėte tik kai kurias iš jų.

Toks veikimo būdas leidžia valdyti prisijungimo ir atjungimo ciklus , o tai labai rekomenduojama naudojant scenarijus suplanuotose užduotyse, automatizavimo vykdymo knygose arba nuolatiniuose integravimo srautuose, kurie gali užstrigti sesijose, jei aiškiai neplanuojate šio valymo.

„PowerShell“ kaip išsami automatizavimo kalba

Be WMI ir CIM, „PowerShell“ tapo bendrosios paskirties automatizavimo kalba , kuri gerokai pranoksta įprastą „Windows“ valdymo scenarijų. Yra knygų ir ištisų kursų, skirtų jos išplėstinėms galimybėms, apimančioms viską nuo diegimo „Linux“ ir „Windows“ sistemose iki platinamų modulių kūrimo naudojant „NuGet“ ir net šiuolaikinių kūrimo aplinkų, tokių kaip „Visual Studio Code“.

Įprasta pradžia – nuodugniai suprasti išplėstines „PowerShell“ funkcijas , kurios leidžia apibrėžti parametrus, atlikti patvirtinimą, generuoti struktūrizuotą išvestį ir pasiekti integruotą pagalbą beveik kaip gimtoji cmdlet. Toliau, kodo organizavimas į modulius palengvina bendradarbiavimą operacijų komandose, nes galite versuoti šiuos modulius ir publikuoti juos vidinėse arba viešose „NuGet“ pagrindu sukurtose saugyklose.

Darbas su pasirinktiniais objektais ir klasėmis taip pat yra labai svarbus , atveriantis duris į daug turtingesnius duomenų modelius nei įprasti linijiniai scenarijai. Tai leidžia jums apibendrinti verslo logiką, pakartotinai naudoti struktūras ir kurti vidines API savo valdymo komandai, visa tai naudojant „PowerShell“ variklį.

Pažangios automatizacijos srityje foninės užduotys ir darbo eigos vaidina lemiamą vaidmenį , nes leidžia valdyti asinchronines užduotis, vykdyti ilgas operacijas neužblokuojant konsolės ir organizuoti sudėtingas sekas keliuose įrenginiuose. Šios galimybės puikiai tinka masinėms užklausoms į WMI/CIM ir nuotolinio administravimo scenarijams, kai dažnai reikia laukti, kol sistemos įdiegs pakeitimus arba grąžins duomenis.

Kitas svarbus komponentas yra „PowerShell DSC“ (pageidaujama būsenos konfigūracija), leidžianti apibrėžti pageidaujamą infrastruktūros konfigūraciją (vaidmenis, funkcijas, paslaugas, failus, saugos parametrus ir kt.) ir pakartotinai taikyti tas būsenas. Kartu su informacija, gauta per WMI/CIM, galite aptikti nukrypimus, juos iš anksto ištaisyti ir palaikyti nuoseklią aplinką su mažesnėmis rankinėmis pastangomis.

Vietinis, nuotolinis ir debesies valdymas naudojant „PowerShell“

Vietiniu lygmeniu „PowerShell“ teikia cmdlet, skirtas „Active Directory“ domenų paslaugoms valdyti , tinklams konfigūruoti ir serveriams administruoti. „Windows 10“ ir naujesnėse versijose integracija yra dar gilesnė, leidžianti automatizuoti viską – nuo ​​svetainių kūrimo iki „Active Directory“ objektų valdymo ir tinklo adapterių konfigūravimo.

Mažiau žinomas, bet labai naudingas komponentas yra „PSProviders“ ir „PSDrives“ , kurie leidžia elgtis su skirtingomis saugojimo vietomis (failų sistema, registru, „Active Directory“ ir kt.) taip, lyg jos būtų naršomi diskai. Dėl to, pavyzdžiui, galite kurti „Active Directory“ grupes, registro raktus arba aplankų struktūras nuotoliniuose kompiuteriuose, naudodami tą pačią sintaksę, kurią naudotumėte naršydami standžiajame diske.

Kalbant apie nuotolinį administravimą, „PowerShell“ integruoja galingą funkcijų rinkinį, skirtą prisijungti prie vieno ar kelių kompiuterių ir vykdyti komandas jūsų vardu . Galite naudoti nuolatinius PSSession seansus, pažangius nuotolinio valdymo metodus, „vienas su daugeliu“ scenarijus (norint vienu metu valdyti kelis serverius) arba „vienas su vienu“ scenarijus, skirtus konkrečių atvejų derinimui. Visa tai, žinoma, atsižvelgiant į nuotolinės prieigos architektūrą ir saugumo modelį.

Debesis šiandien taip pat vaidina esminį vaidmenį. Naudodami „Azure PowerShell“ ir „Azure Cloud Shell“, galite valdyti virtualias mašinas, saugyklą ir prenumeratas tiesiai iš komandinės eilutės. „Azure PowerShell“ modulių diegimas ir susipažinimas su jais yra beveik privalomas, jei valdote hibridines arba visiškai „Azure“ talpinamas aplinkas.

Kita vertus, „PowerShell“ taip pat įsitvirtino kaip pagrindinė priemonė „Microsoft 365“ („Exchange Online“, „SharePoint Online“, „Teams“, vartotojams ir licencijoms valdyti). Nuo paskyrų kūrimo ir valdymo iki „Exchange Online“ išteklių, įskaitant grupes, „SharePoint“ svetaines ir „Microsoft Teams“, administravimo – viską galima valdyti naudojant scenarijus, kurie smarkiai sumažina rankinį darbą žiniatinklio portale.

Scenarijų rašymas, procesų kūrimas ir geriausia darbo praktika

Norint kuo geriau išnaudoti pažangią automatizaciją naudojant WMI ir CIM, būtina įvaldyti „PowerShell“ konvejerio modelį . Skirtingai nuo kitų apvalkalų, čia neperduodate paprasto teksto, o pilnus objektus, kurie leidžia labai tiksliai pasirinkti, rūšiuoti, matuoti, filtruoti, išvardyti ir transformuoti informaciją.

Mokymasis dirbti su srautais apima teisingą atrankos ir filtravimo cmdlet naudojimą , supratimą, kaip išvardyti sudėtingus objektus, ir išmokimą perduoti duomenis tarp komandų ir scenarijų neprarandant informacijos. Tai sustiprina organizuotas kintamųjų, masyvų ir maišos lentelių naudojimas, kurios veikia kaip laikinos duomenų struktūros, ant kurių galima kurti sudėtingesnę logiką.

Kitas žingsnis yra pats scenarijų rašymas: komandų pakavimas į daugkartinio naudojimo scenarijus su srauto valdymu (if, for, foreach), duomenų importavimas iš CSV failų ar kitų formatų, vartotojo įvesties tvarkymas, klaidų tvarkymas ir įvykių registravimas. Visa tai leidžia pereiti nuo izoliuotų komandų prie patikimesnių, integruotų įrankių.

Trikčių šalinimas ir klaidų tvarkymas yra ypač svarbūs didelio masto automatizavimo aplinkose su WMI/CIM, nes tinklo sutrikimas, netinkamai sukonfigūruotas leidimas arba trūkstama klasė gali sugadinti procesą, jei jis netinkamai valdomas. Naudodami bandymų/pagavimų blokus, konfigūruojamus klaidų veiksmus ir išsamų žurnalavimą, galite numatyti tokias situacijas ir efektyviau į jas reaguoti.

Galiausiai, viskas, kas susiję su funkcijomis ir moduliais, užbaigia ratą : pasirašote scenarijus, kad užtikrintumėte jų vientisumą, supakuojate funkcijas į modulius, platinate tuos modulius vidinėse arba viešose saugyklose ir sukuriate bendrinamų įrankių ekosistemą savo organizacijoje. Tokiu būdu bet koks naujas WMI, CIM ar nuotolinio valdymo kūrimas yra integruojamas į nuoseklų ir lengvai prižiūrimą rinkinį.

Sujungus visus aukščiau išvardintus elementus – WMI/CIM, nuotolinius seansus, scenarijų kūrimą, asinchronines užduotis, DSC, „Azure“ ir „Microsoft 365“, gaunama aplinka, kurioje pažangi automatizacija naudojant „PowerShell“ tampa administravimo pagrindu. Turėdami tvirtą geriausios praktikos pagrindą, išmanų „CimSessions“ naudojimą (su WSMan ir DCOM) ir modulinį scenarijų dizainą, galite nuosekliai, saugiai ir daug efektyviau valdyti nevienalytę infrastruktūrą, nei pasikliaudami vien grafiniais vedliais ar izoliuotais įrankiais.

Susijęs straipsnis:

Išplėstinė automatizacija sistemoje „Windows“ naudojant „PowerShell DSC“ ir „Ansible“