PowerShell, WMI ja CIM edistyneeseen automatisointiin Windows-järjestelmissä

Informatec Digital » Resurssit » PowerShell, WMI ja CIM edistyneeseen automatisointiin Windows-järjestelmissä

Jos työskentelet Windows-järjestelmien hallinnoinnin parissa, törmäät ennemmin tai myöhemmin PowerShelliin, WMI:hin ja edistyneeseen automaatioon . Kyse ei ole vain muutaman komennon suorittamisen osaamisesta: kun hallinnoit kymmeniä tai satoja palvelimia, tarvitset vakavasti otettavan, jäsennellyn ja turvallisen lähestymistavan tiedon keräämiseen, muutosten tekemiseen ja tehtävien toistamiseen menemättä hulluksi... tai rikkomatta mitään.

Seuraavissa riveissä tutkimme rauhallisesti mutta perusteellisesti, miten WMI:tä, CIM:iä ja PowerShell-etäviestintää voidaan hyödyntää kaiken automatisoimiseksi yksinkertaisista kyselyistä monimutkaisiin infrastruktuuriskenaarioihin. Näemme myös, miten kaikki tämä sopii yhteen moduulien, taustatehtävien, Azuren, Microsoft 365:n ja joidenkin edistyneiden ominaisuuksien kanssa, jotka tekevät todellisen eron järjestelmänvalvojan päivittäisessä työssä.

PowerShell-parannukset ja yleiskatsaus edistyneeseen automaatioon

Windows PowerShell on kehittynyt paljon varhaisista versioistaan, ja suuri osa tästä kehityksestä tuli Windows Server 2012:n myötä, jossa etäviestintää parannettiin, käytettävissä olevia cmdlet-komentoja laajennettiin ja esimerkiksi virheenkorjausta, taustatöitä ja rajoitettuja päätepisteitä helpotettiin tietoturvan parantamiseksi.

Yksi tämän ympäristön keskeisistä ideoista on, että järjestelmänvalvojat voivat luoda cmdlet-tyyppisiä toimintoja ilman laajaa koodausta hyödyntäen edistyneitä ominaisuuksia, uudelleenkäytettäviä moduuleja ja kattavaa ohjejärjestelmää. Tämä tarkoittaa, että erillisten graafisten työkalujen sijaan voidaan rakentaa yhtenäinen joukko skriptejä ja moduuleja, jotka automatisoivat palvelimien, verkkojen, Active Directoryn, Azuren tai Microsoft 365:n hallintaprosesseja.

Edistyneen automaation alalla erottuvat myös ominaisuudet, kuten tehtävien asynkroninen suorittaminen, työnkulut, konfiguraatioon perustuva hallinta PowerShell DSC:llä ja suojausvaihtoehdot, kuten JEA (Just Enough Administration) tai PowerShell Web Access, jotka mahdollistavat yksityiskohtaisen hallinnan siitä, mitä kukin henkilö voi tehdä ja mistä.

Koko tämä ekosysteemi sopii erityisen hyvin yhteen WMI:n ja CIM:n kanssa, koska käyttöjärjestelmän paljastamat hallintatiedot (laitteisto, palvelut, prosessit , verkkokokoonpano, asennetut ohjelmistot jne.) muodostavat joukon objekteja, joita voidaan kysellä, suodattaa ja muokata massaautomaatioon suunnitelluilla PowerShell-komennoilla.

WMI ja CIM: Keskeiset käsitteet ja käytännön erot

Windows Management Instrumentation, joka tunnetaan paremmin nimellä WMI, on PowerShellistä riippumaton tekniikka , joka on ollut osa Windowsia vuosia. Se tarjoaa hallintatietojen tietovaraston käyttöjärjestelmästä, laitteistosta ja monista sovelluksista. Vaikka se ei ole riippuvainen PowerShellistä, PowerShell hyödyntää sitä laajasti tehtävien automatisointiin.

WMI:n luonnollinen seuraaja PowerShell-ekosysteemissä on CIM (Common Information Model) -cmdlet-komennot , jotka esiteltiin PowerShell 3.0:n myötä. Nämä cmdlet-komennot on ryhmitelty CimCmdlets-moduuliin ja ne sisältävät muun muassa komentoja Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance ja Remove-CimInstance.

Vanhemmissa Windows PowerShell -versioissa, kuten Windows 10 PowerShell 5.1:ssä tai Windows 11 PowerShellissä, on edelleen klassiset WMI-cmdlet-komennot (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Nämä cmdlet-komennot ovat kuitenkin vanhentuneita, eivätkä ne enää sisälly PowerShell 6:een ja uudempiin versioihin, joten ne ovat merkityksellisiä vain vanhojen komentosarjojen ylläpidossa tai vanhan koodin tarkistamisessa.

Kun joku puhuu "WMI:n kyselystä CIM-cmdlet-komennoilla", se ei ole ristiriitaista: CIM-cmdlet-komennot käyttävät edelleen WMI-tietoja , mutta ne tekevät sen käyttämällä nykyaikaisempia protokollia, kuten WSMan, ja yhtenäisempää API:a. Käytännössä uusien kehityshankkeiden kohdalla kannattaa keskittyä CIM:ään ja harkita WMI-cmdlet-komennoja vain silloin, kun sinun on siirrettävä tai ymmärrettävä vanhoja skriptejä.

Historiallisesti monet järjestelmänvalvojat käyttivät VBScriptiä WQL-kyselykielellä WMI-kyselyihin esimerkiksi muodostamalla yhteyden root\CIMV2- nimiavaruuteen ja kyselemällä luokkia, kuten Win32_BIOS. Samaa WQL-kyselyä voidaan käyttää uudelleen nykyään Get-CimInstance-funktiolla antamalla -Query-parametri, mikä yksinkertaistaa huomattavasti siirtymistä VBScriptistä PowerShelliin ilman, että logiikkaa tarvitsee kirjoittaa uudelleen alusta alkaen.

Get-CimInstancen käytännön käyttö ja tehokkaat kyselyt

Arkipäiväisessä työssä luonnollisin tapa tehdä WMI-kyselyitä PowerShellin avulla on käyttää Get-CimInstance-metodia ja -ClassName-parametria kokonaisten WQL-kyselyiden kirjoittamisen sijaan. Esimerkiksi BIOS-tietojen hakemiseen voit käyttää Get-CimInstance -ClassName Win32_BIOS -metodia, jolloin saat objektin, jolla on ominaisuuksia, kuten Valmistaja, Nimi, Sarjanumero tai SMBIOSBIOSVersion.

Koska kaikki PowerShellissä on objekteja, on erittäin helppo suodattaa ja valita vain tarvitsemasi tiedot . Jos olet kiinnostunut vain sarjanumerosta, voit ohjata tuloksen `Select-Object -Property SerialNumber`-funktioon tai käyttää `Select-Object -ExpandProperty SerialNumber`-funktiota yksinkertaisen merkkijonon luomiseen ominaisuudella varustetun objektin sijaan. Toinen yleinen vaihtoehto on käyttää pistesyntaksia (`Get-CimInstance ...`).SerialNumber` arvon suoraan käyttämiseksi.

On syytä huomata, että oletusarvoisesti WMI-kyselyt palauttavat enemmän ominaisuuksia kuin todellisuudessa käytät . Paikallisella koneella tämä on yleensä hyvä, mutta kun alat tehdä kyselyitä useille etäkoneille, se tarkoittaa ylimääräistä käsittelyaikaa ja tarpeetonta verkkoliikennettä. Tässä kohtaa `Get-CimInstance`-funktion `-Property`-parametri tulee mukaan kuvaan, jonka avulla voit rajoittaa lähteestä noudettavien ominaisuuksien määrää.

Määrittämällä esimerkiksi -Property SerialNumber voit vähentää siirrettävän datan määrää, mikä tekee kyselystä nopeamman ja tehokkaamman, erityisesti skaalautuvasti . Tämä "kysy vain mitä tarvitset" -mentaliteetti on avainasemassa suunniteltaessa inventaario- tai auditointiskriptejä, jotka toimivat kymmenillä tai sadoilla koneilla.

Yhteenvetona voidaan todeta, että Get-CimInstance tarjoaa tehokkaan tasapainon yksinkertaisuuden (yksi komentorivi) ja joustavuuden välillä , työskentelitpä sitten konkreettisten luokkien, vanhojen WQL-kyselyiden tai tiettyjen ominaisuuksien kanssa, jotka haluat optimoida hakua varten.

Etäkonsultaatiot CIM:n, istuntojen ja WSMan/DCOM-protokollien avulla

Kun siirryt pois paikalliselta koneeltasi ja alat käyttää etäkoneita, useita tekijöitä tulee mukaan: käyttöoikeudet, tietoliikenneprotokolla ja suorituskyky . Vaikka monet ihmiset pitävät PowerShelliä "vaarallisena", totuus on, että se ei anna sinulle mitään lisäoikeuksia: sinulla on täsmälleen samat oikeudet kuin graafisella käyttöliittymällä tai millä tahansa muulla työkalulla, ei enempää eikä vähempää.

Jos yrität suorittaa komennon `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` ilman riittäviä käyttöoikeuksia kyseiseen koneeseen, saat virheilmoituksen "Access is denied" (Käyttöoikeus estetty) . Tämä ei johdu PowerShellin epäonnistumisesta, vaan käyttäjällä, jolla suoritat istuntoa, ei ole oikeutta käyttää näitä tietoja WMI:ssä. Voit tietenkin avata konsolin toimialueen järjestelmänvalvojana, mutta se tarkoittaa, että kaikki komennot suoritetaan näillä oikeuksilla, mikä on tarpeeton riski monissa ympäristöissä.

Suosituksena on soveltaa pienimpien oikeuksien periaatetta ja nostaa oikeuksia vain tarvittaessa . Cmdleteissä, jotka tukevat -Credential-parametria, voit määrittää vaihtoehtoiset tunnistetiedot vain kyseiselle komennolle. Get-CimInstance ei kuitenkaan hyväksy suoraan -Credential-parametria, ja tässä CimSessions tulee mukaan eleganttina ratkaisuna.

CimSession on pysyvä yhteys etätietokoneeseen, jonka voit luoda New-CimSession-metodilla välittämällä tietokoneen nimen ja tunnistetiedot (esimerkiksi New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Tämä istunto tallennetaan muuttujaan, kuten $CimSession, ja sitä käytetään sitten uudelleen Get-CimInstance-metodin kanssa käyttämällä -CimSession-parametria -ComputerName-parametrin sijaan, jolloin voit yhdistää useita kyselyitä yhdeksi yhteydeksi.

Tunnistetietovaatimusten lisäksi Get-CimInstance käyttää oletusarvoisesti WSMan-protokollaa (WinRM:n pohjalta) . Tämä tarkoittaa, että etäkoneella on oltava WSMan-pinon versio 3.0 tai uudempi, joka yleensä löytyy PowerShell 3.0:sta ja uudemmista. Voit tarkistaa WSMan-pinon version koneella komennolla `Test-WSMan -ComputerName RemoteComputer` ja varmistaa, että "Stack"-arvo on 3.0 tai uudempi, jotta tätä yhteysmenetelmää voidaan käyttää.

CIM-istunnot DCOMin ja taaksepäin yhteensopivuuden avulla

Vanhemmat Get-WmiObject-metodiin perustuvat WMI-cmdlet-komennot käyttävät DCOM-protokollaa, jota vanhemmat Windows-versiot edelleen tukevat . Ongelmana on, että uudemmissa järjestelmissä palomuurit usein estävät DCOMin oletusarvoisesti, jolloin sinun on avattava tiettyjä portteja sen käyttämiseksi sellaisenaan. Tämä voi rikkoa organisaatiosi suojauskäytäntöjä.

CIM-cmdletit tarjoavat tehokkaan kompromissin: voit luoda istuntoasetuksia `New-CimSessionOption -Protocol Dcom` -metodilla , tallentaa ne muuttujaan (esimerkiksi `$DCOM`) ja yhdistää ne sitten `New-CimSession`-metodin kanssa luodaksesi CimSessionin, joka käyttää DCOMia WSManin sijaan. Näin voit muodostaa yhteyden hyvin vanhoihin palvelimiin, jopa sellaisiin, jotka ovat vanhempia kuin Windows Server 2000, ja joihin PowerShelliä ei ole edes asennettu.

Yleensä on kätevää tallentaa toimialueen järjestelmänvalvojan tunnistetiedot tai laajennetun tilin tunnistetiedot muuttujaan (esimerkiksi $Cred = Get-Credential ), jotta niitä ei tarvitse kirjoittaa joka kerta. Sitten voit aloittaa CimSessionin DCOMin kautta vanhemmalle palvelimelle, joka ei tue WSMania, mutta jossa on WMI, esimerkiksi komennolla New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred.

Skriptin kirjoittajan näkökulmasta `Get-CimInstance`-funktion suurin etu on se, että se ei muutu protokollan mukaan : saat samat objektit ja ominaisuudet riippumatta siitä, käytätkö WSMania vai DCOMia. Tämä yksinkertaistaa logiikkaa huomattavasti, koska voit kapseloida sopivan protokollan havaitsemisen funktioon ja antaa muun koodin toimia aina läpinäkyvästi CimSessionsien kanssa.

Itse asiassa on melko yleistä luoda mukautettuja funktioita, jotka testaavat WSMania Test-WSMan-metodilla ja, jos se ei ole käytettävissä, siirtyvät automaattisesti DCOMiin New-CimSessionOption-metodilla. Näin voit standardoida CimSession-luonnin sekaympäristöissä , joissa on sekä moderneja että vanhoja palvelimia, ilman että yhteyslogiikkaa tarvitsee replikoida kaikissa komentosarjoissa.

CimSessionsien hallinta, listaus ja puhdistus

Kun alat käyttää CimSessionseja laajasti, on tärkeää pitää niistä kirjaa tarpeettomien yhteyksien kertymisen välttämiseksi. Get-CimSession-metodilla voit listata kaikki avoimet istunnot , nähdä, mihin koneeseen ne osoittavat, ja tarkistaa, mitä protokollaa ne käyttävät (WSMAN tai DCOM), mikä on erittäin hyödyllistä yhteys- tai todennusongelmien diagnosoinnissa.

Voit myös hakea kyseiset olemassa olevat istunnot muuttujan avulla, esimerkiksi $CimSession = Get-CimSession , ja käyttää niitä yhdessä komennossa Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS useiden tietokoneiden samanaikaiseen kyselyyn yhdistämällä WSMan- ja DCOM-istunnot samaan toimintoon.

Kun olet analysoinut tiedot, on hyvä sulkea istunnot, jotta resursseja ei jätetä tarpeettomasti auki. Get-CimSession | Remove-CimSession -cmdlet poistaa kaikki aktiiviset CimSessionit nykyisestä profiilista kerralla. Vaihtoehtoisesti voit siirtää tietyt istunnot Remove-CimSession-cmdlet-komennolle sulkeaksesi vain osan niistä.

Tällä tavalla toimiminen mahdollistaa hallitut yhteys- ja katkaisusyklit , mikä on erittäin suositeltavaa käytettäessä skriptejä ajoitettujen tehtävien, automaatiorunbookien tai jatkuvien integraatioputkien sisällä, jotka voivat jättää istunnot jumiin, jos et suunnittele tätä siivousta erikseen.

PowerShell kattavana automaatiokielenä

WMI:n ja CIM:n lisäksi PowerShellistä on tullut yleiskäyttöinen automaatiokieli , joka menee paljon tyypillisen Windows-hallintakomentosarjan ulkopuolelle. Sen edistyneille ominaisuuksille on omistettu kirjoja ja kokonaisia ​​kursseja, jotka kattavat kaiken asennuksesta Linuxiin ja Windowsiin jaettavien moduulien kehittämiseen NuGetin kautta ja jopa moderneihin kehitysympäristöihin, kuten Visual Studio Codeen.

Yleinen lähtökohta on ymmärtää perusteellisesti PowerShellin edistyneet ominaisuudet , joiden avulla voit määrittää parametreja, suorittaa validointeja, luoda jäsenneltyä tulostetta ja käyttää integroitua ohjetta lähes natiivin cmdlet-tason tasolla. Siitä eteenpäin koodin järjestäminen moduuleiksi helpottaa yhteistyötä operatiivisten tiimien sisällä, koska voit versioida ja julkaista näitä moduuleja sisäisiin tai julkisiin NuGet-pohjaisiin tietovarastoihin.

Myös mukautettujen objektien ja luokkien kanssa työskentely on avainasemassa , sillä se avaa oven paljon rikkaampiin tietomalleihin kuin tyypilliset lineaariset skriptit. Tämä mahdollistaa liiketoimintalogiikan kapseloinnin, rakenteiden uudelleenkäytön ja sisäisten API-rajapintojen suunnittelun omalle johtotiimille – kaikki tämä PowerShell-moottorin avulla.

Edistyneen automaation alueella taustalla suoritettavilla töillä ja työnkuluilla on ratkaiseva rooli , sillä ne mahdollistavat asynkronisten tehtävien hallinnan, pitkien toimintojen suorittamisen konsolia estämättä ja monimutkaisten sekvenssien organisoinnin useissa koneissa. Nämä ominaisuudet sopivat täydellisesti WMI/CIM-joukkokyselyihin ja etähallintatilanteisiin, joissa on usein tarpeen odottaa, että järjestelmät toteuttavat muutokset tai palauttavat tietoja.

Toinen keskeinen komponentti on PowerShell DSC (Desired State Configuration), jonka avulla voit määrittää infrastruktuurin halutun kokoonpanon (roolit, ominaisuudet, palvelut, tiedostot, suojausasetukset jne.) ja käyttää näitä tiloja toistuvasti. Yhdessä WMI/CIM:n kautta saamiesi tietojen kanssa voit havaita poikkeamat, korjata ne ennakoivasti ja ylläpitää yhtenäisiä ympäristöjä vähemmällä manuaalisella työllä.

Paikallinen, etä- ja pilvihallinta PowerShellin avulla

Paikallisella tasolla PowerShell tarjoaa cmdlet-komentoja Active Directory -toimialuepalveluiden hallintaan , verkkojen konfigurointiin ja palvelimien ylläpitoon. Windows 10:ssä ja uudemmissa versioissa integraatio on vieläkin syvempi, ja sen avulla voit automatisoida kaiken verkkosivustojen luomisesta Active Directory -objektien hallintaan ja verkkosovittimien konfigurointiin.

Vähemmän tunnettu mutta erittäin hyödyllinen komponentti on PSProviders ja PSDrives , joiden avulla voit käsitellä eri tallennussijainteja (tiedostojärjestelmä, rekisteri, Active Directory jne.) ikään kuin ne olisivat navigoitavia asemia. Tämän ansiosta voit esimerkiksi luoda Active Directory -ryhmiä, rekisteriavaimia tai kansiorakenteita etätietokoneille käyttämällä samaa syntaksia, jota käyttäisit kiintolevyn selaamiseen.

Etähallinnan osalta PowerShell sisältää tehokkaan joukon ominaisuuksia yhteyden muodostamiseen yhteen tai useampaan tietokoneeseen ja komentojen suorittamiseen puolestasi . Voit käyttää pysyviä PSSession-istuntoja, edistyneitä etäkäyttötekniikoita, yksi-moneen-skenaarioita (useiden palvelimien samanaikaiseen hallintaan) tai yksi-moneen-skenaarioita tiettyjen tapausten virheenkorjaukseen. Kaikki tämä tietenkin etäkäytön arkkitehtuuria ja suojausmallia kunnioittaen.

Myös pilvipalveluilla on nykyään keskeinen rooli. Azure PowerShellin ja Azure Cloud Shellin avulla voit hallita virtuaalikoneita, tallennustilaa ja tilauksia suoraan komentoriviltä. Azure PowerShell -moduulien asentaminen ja niihin tutustuminen on lähes välttämätöntä, jos hallitset hybridi- tai täysin Azuren isännöimiä ympäristöjä.

Toisaalta PowerShell on myös vakiinnuttanut asemansa ensisijaisena työkaluna Microsoft 365:n (Exchange Online, SharePoint Online, Teams, käyttäjät ja lisenssit) hallintaan. Tilien luomisesta ja hallinnasta Exchange Online -resurssien, kuten ryhmien, SharePoint-sivustojen ja Microsoft Teamsin, hallintaan, kaikkea voidaan hallita skripteillä, jotka vähentävät merkittävästi manuaalista työtä verkkoportaalissa.

Skriptaus, prosessit ja parhaat työkäytännöt

Jotta saat kaiken irti edistyneestä automaatiosta WMI:n ja CIM:n avulla, on tärkeää hallita PowerShellin putkimalli . Toisin kuin muissa komentotulkeissa, tässä ei välitetä pelkkää tekstiä, vaan kokonaisia ​​objekteja, joiden avulla voit valita, lajitella, mitata, suodattaa, luetteloida ja muuntaa tietoja erittäin tarkasti.

Putkilinjojen kanssa työskentelyn oppiminen edellyttää valinta- ja suodatuskomentojen oikeaa käyttöä , monimutkaisten objektien luetteloinnin ymmärtämistä ja tiedon siirtämisen oppimista komentojen ja komentosarjojen välillä menettämättä tietoja. Tätä vahvistetaan muuttujien, taulukoiden ja hajautustaulukoiden järjestelmällisellä käytöllä, jotka toimivat väliaikaisina tietorakenteina, joille voidaan rakentaa edistyneempää logiikkaa.

Seuraava vaihe on itse skriptaaminen: komentojen pakkaaminen uudelleenkäytettäviksi skripteiksi, joissa on virtauksenohjaus (if, for, foreach), datan tuominen CSV-tiedostoista tai muista muodoista, käyttäjän syötteen käsittely, virheiden käsittely ja tapahtumien kirjaaminen. Kaikki tämä mahdollistaa siirtymisen erillisistä komennoista tehokkaampiin, sisäänrakennettuihin työkaluihin.

Vianmääritys ja virheiden käsittely ovat erityisen tärkeitä laajoissa automaatioympäristöissä, joissa käytetään WMI/CIM:iä, sillä verkkokatkos, väärin määritetty käyttöoikeus tai puuttuva luokka voivat rikkoa prosessin, jos sitä ei hallita oikein. Try/catch-lohkojen, konfiguroitavien virhetoimintojen ja yksityiskohtaisen lokikirjauksen avulla voit ennakoida ja reagoida näihin tilanteisiin tehokkaammin.

Lopuksi kaikki funktioihin ja moduuleihin liittyvä täydentää ympyrän : allekirjoitat skriptit varmistaaksesi niiden eheyden, pakkaat funktiot moduuleiksi, jaat nämä moduulit sisäisiin tai julkisiin tietovarastoihin ja luot organisaatiollesi jaettujen työkalujen ekosysteemin. Tällä tavoin kaikki uusi kehitys WMI:ssä, CIM:ssä tai etäkäytössä integroidaan yhtenäiseksi ja helposti ylläpidettäväksi kokonaisuudeksi.

Kun yhdistät kaikki edellä mainitut – WMI/CIM, etäistunnot, komentosarjat, asynkroniset työt, DSC:n, Azuren ja Microsoft 365:n – saat ympäristön, jossa PowerShellin avulla toteutettu edistynyt automaatio on hallinnan ydin. Vankan parhaiden käytäntöjen pohjan, CimSessionsien älykkään käytön (sekä WSManin että DCOMin kanssa) ja modulaarisen komentosarjarakenteen avulla voit hallita heterogeenisiä infrastruktuureja johdonmukaisesti, turvallisesti ja paljon tehokkaammin kuin pelkästään graafisten ohjattujen toimintojen tai erillisten työkalujen avulla.