PowerShell, WMI és CIM a Windows rendszerek fejlett automatizálásához

Informatec Digital » Erőforrás » PowerShell, WMI és CIM a Windows rendszerek fejlett automatizálásához

Ha Windows rendszereket adminisztrálsz, előbb-utóbb bele fogsz botlani a PowerShellbe, a WMI-be és a fejlett automatizálásba . Nem elég csak néhány parancs futtatásának ismerete: amikor több tucat vagy több száz szervert kezelsz, komoly, strukturált és biztonságos megközelítésre van szükséged az információk gyűjtéséhez, a változtatások alkalmazásához és a feladatok ismétléséhez anélkül, hogy megőrülnél... vagy bármit is elrontanál.

A következő sorokban nyugodtan, de alaposan megvizsgáljuk, hogyan lehet a WMI, a CIM és a PowerShell távoli kommunikációját kihasználni az egyszerű lekérdezésektől az összetett infrastrukturális forgatókönyvekig mindent automatizálni. Azt is megvizsgáljuk, hogyan illeszkedik mindez a modulokhoz, a háttérfeladatokhoz, az Azure-hoz, a Microsoft 365-höz és néhány olyan fejlett funkcióhoz, amelyek valódi különbséget jelentenek a rendszergazda napi munkájában.

PowerShell-fejlesztések és a fejlett automatizálás áttekintése

A Windows PowerShell sokat fejlődött a korai verziói óta, és ennek a fejlődésnek nagy része a Windows Server 2012-vel érkezett, ahol javult a távoli kommunikáció, bővült az elérhető parancsmagok köre, és olyan dolgok, mint a hibakeresés, a háttérfeladatok és a korlátozott végpontok, könnyebbé váltak a biztonság javítása érdekében.

A környezet egyik fő gondolata, hogy a rendszergazdák cmdlet-szerű viselkedéseket hozhatnak létre kiterjedt kódolás nélkül , kihasználva a fejlett funkciókat, az újrafelhasználható modulokat és az átfogó súgórendszert. Ez azt jelenti, hogy a különálló grafikus eszközökre való támaszkodás helyett összefüggő szkripteket és modulokat hozhatnak létre, amelyek automatizálják a szerverek, hálózatok, Active Directory, Azure vagy Microsoft 365 kezelésének folyamatait.

A fejlett automatizálás területén olyan funkciók is kiemelkednek, mint a feladatok aszinkron végrehajtását lehetővé tevő feladatok, a munkafolyamatok, a konfigurációalapú adminisztráció a PowerShell DSC-vel, valamint a biztonsági opciók, mint a JEA (Just Enough Administration) vagy a PowerShell Web Access, amelyek lehetővé teszik az egyes személyek általi műveletek részletes szabályozását és honnan történő végrehajtását.

Ez a teljes ökoszisztéma különösen jól illeszkedik a WMI-hez és a CIM-hez, mivel az operációs rendszer által elérhetővé tett felügyeleti információk (hardver, szolgáltatások, folyamatok , hálózati konfiguráció, telepített szoftverek stb.) olyan objektumok halmazává válnak, amelyeket tömeges automatizálásra tervezett PowerShell-parancsok segítségével lekérdezhet, szűrhet és módosíthat.

WMI és CIM: Kulcsfontosságú fogalmak és gyakorlati különbségek

A Windows Management Instrumentation, ismertebb nevén WMI, egy PowerShell-független technológia, amely évek óta a Windows része. Felügyeleti információkat tartalmaz az operációs rendszerről, a hardverről és számos alkalmazásról. Bár nem függ a PowerShelltől, a PowerShell széles körben kihasználja azt a feladatok automatizálásához.

A WMI természetes utódja a PowerShell ökoszisztémában a CIM (Common Information Model) parancsmagok , amelyeket a PowerShell 3.0-s verziójával vezettek be. Ezek a parancsmagok a CimCmdlets modulban vannak csoportosítva, és olyan parancsokat tartalmaznak, mint a Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance és Remove-CimInstance.

A Windows PowerShell régebbi verzióiban, például a Windows 10 PowerShell 5.1-ben vagy a Windows 11 PowerShellben továbbra is megtalálhatók a klasszikus WMI-parancsmagok (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Ezek a parancsmagok azonban elavultak, és már nem szerepelnek a PowerShell 6-os és újabb verzióiban, így csak a régi szkriptek karbantartásához vagy a régi kód áttekintéséhez relevánsak.

Amikor valaki a „WMI lekérdezéséről CIM-parancsmagokkal” beszél, az nem ellentmondásos: a CIM-parancsmagok továbbra is hozzáférnek a WMI-információkhoz , de ezt modernebb protokollok, például a WSMan és egy konzisztensebb API használatával teszik. A gyakorlatban az új fejlesztések esetében a CIM-re kell összpontosítani, és csak akkor érdemes WMI-parancsmagokat fontolóra venni, ha migrálni vagy megérteni kell a régi szkripteket.

Korábban sok rendszergazda a VBScriptet a WQL lekérdezési nyelvvel együtt használta a WMI lekérdezéséhez, például a root\CIMV2 névtérhez csatlakozva és olyan osztályokat lekérdezve, mint a Win32_BIOS. Ugyanez a WQL lekérdezés ma is újra felhasználható a Get-CimInstance segítségével a -Query paraméter átadásával, ami nagymértékben leegyszerűsíti a VBScriptről a PowerShellre való átmenetet anélkül, hogy a logikát a nulláról kellene újraírni.

A Get-CimInstance gyakorlati használata és hatékony lekérdezések

A mindennapi munkához a WMI PowerShell-lel történő lekérdezésének legtermészetesebb módja a Get-CimInstance metódus használata a -ClassName paraméterrel , a teljes WQL-lekérdezések írása helyett. Például a BIOS-információk lekéréséhez használhatja a Get-CimInstance -ClassName Win32_BIOS metódust, és egy olyan objektumot kap, amelynek tulajdonságai olyanok, mint a Gyártó, Név, Sorozatszám vagy SMBIOSBIOSVersion.

Mivel a PowerShellben minden objektum, nagyon könnyű szűrni és csak a szükséges elemeket kiválasztani . Ha csak a sorozatszám érdekel, az eredményt a `Select-Object -Property SerialNumber` függvénnyel továbbíthatod, vagy a `Select-Object -ExpandProperty SerialNumber` függvénnyel egy egyszerű karakterláncot adhatsz meg egy tulajdonsággal rendelkező objektum helyett. Egy másik gyakori lehetőség a pont szintaxis (`Get-CimInstance ...`).SerialNumber`) használata az érték közvetlen eléréséhez.

Érdemes megjegyezni, hogy alapértelmezés szerint a WMI-lekérdezések több tulajdonságot adnak vissza, mint amennyit valójában felhasználunk . Egy helyi gépen ez általában rendben van, de ha sok távoli gépet kezdünk el lekérdezni, az további feldolgozási időt és szükségtelen hálózati forgalmat eredményez. Itt jön képbe a `Get-CimInstance` `-Property` paramétere, amely lehetővé teszi, hogy korlátozzuk, mely tulajdonságokat kérjük le a forrásból.

A -Property SerialNumber megadásával például csökkenthető az átvitt adatmennyiség, így a lekérdezés gyorsabb és hatékonyabb, különösen nagy léptékben . Ez a „csak azt kérdezd, amire szükséged van” mentalitás kulcsfontosságú olyan leltár- vagy auditszkriptek tervezésekor, amelyek több tucat vagy több száz gépen futnak.

Összefoglalva, a Get-CimInstance hatékony egyensúlyt kínál az egyszerűség (egy parancssor) és a rugalmasság között , függetlenül attól, hogy konkrét osztályokkal, régi WQL lekérdezésekkel vagy a lekéréshez optimalizálni kívánt adott tulajdonságokkal dolgozik.

Távoli konzultációk CIM-mel, munkamenetekkel és WSMan/DCOM protokollokkal

Amikor eltávolodsz a helyi gépedtől, és elkezdesz hozzáférni a távoli gépekhez, számos tényező játszik szerepet: az engedélyek, a kommunikációs protokoll és a teljesítmény . Bár sokan „veszélyesnek” tartják a PowerShellt, az igazság az, hogy nem ad semmilyen extra jogosultságot: pontosan ugyanazokkal az engedélyekkel rendelkezel, mint a grafikus felülettel vagy bármely más eszközzel, nem többel és nem kevesebbel.

Ha a `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` parancsot megfelelő jogosultságok nélkül próbálod futtatni az adott gépen, akkor „Hozzáférés megtagadva” hibaüzenetet kapsz . Ez nem azért van, mert a PowerShell hibát jelez, hanem egyszerűen azért, mert a munkamenetet futtató felhasználónak nincs joga hozzáférni ezekhez az információkhoz a WMI-ben. Természetesen tartományi rendszergazdaként is megnyithatsz egy konzolt, de ez azt jelenti, hogy minden parancs ezekkel a jogosultságokkal lesz végrehajtva, ami sok környezetben szükségtelen kockázatot jelent.

A javaslat az, hogy a minimális jogosultságok elvét alkalmazzuk , és csak szükség esetén emeljük a jogosultságokat . A -Credential paramétert támogató cmdletekben csak a szóban forgó parancshoz adhatunk meg alternatív hitelesítő adatokat. A Get-CimInstance azonban nem fogadja el közvetlenül a -Credential paramétert, és itt jön képbe a CimSessions elegáns megoldásként.

A CimSession egy állandó kapcsolat egy távoli számítógéppel, amelyet a New-CimSession paranccsal hozhat létre, átadva a számítógép nevét és a hitelesítő adatokat (például New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Ezt a munkamenetet egy változóban, például a $CimSession változóban tárolja a rendszer, majd a Get-CimInstance paranccsal újra felhasználja a -CimSession paraméter használatával a -ComputerName paraméter helyett, így több lekérdezést egyetlen kapcsolattá egyesíthet.

A hitelesítő adatokra vonatkozó követelmény mellett a Get-CimInstance alapértelmezés szerint a WSMan protokollt használja (a WinRM alapján) . Ez azt jelenti, hogy a távoli gépen a WSMan verem 3.0-s vagy újabb verziójával kell rendelkeznie, amely jellemzően a PowerShell 3.0-s és újabb verzióiban található. A WSMan verem verzióját a `Test-WSMan -ComputerName RemoteComputer` paranccsal ellenőrizheti egy gépen, és ellenőrizheti, hogy a "Stack" értéke 3.0 vagy újabb-e ahhoz, hogy ezt a csatlakozási módszert használhassa.

CIM-munkamenetek DCOM-mal és visszafelé kompatibilitással

A Get-WmiObject alapú régebbi WMI-parancsmagok a DCOM protokollt használják, amelyet a Windows régebbi verziói továbbra is támogatnak . A probléma az, hogy a modernebb rendszereken a tűzfalak gyakran alapértelmezés szerint blokkolják a DCOM-ot, és megkövetelik, hogy bizonyos portokat megnyisson a DCOM használatához, ami sértheti a szervezet biztonsági szabályzatait.

A CIM cmdletek hatékony megoldást kínálnak: munkamenet-beállításokat hozhat létre a `New-CimSessionOption -Protocol Dcom` paranccsal , mentheti azokat egy változóba (például `$DCOM`), majd kombinálhatja őket a `New-CimSession` paranccsal, hogy olyan CimSessiont hozzon létre, amely DCOM-ot használ a WSMan helyett. Ez lehetővé teszi, hogy nagyon régi szerverekhez csatlakozzon, akár a Windows Server 2000 előttiekhez is, ahol a PowerShell még nincs telepítve.

Általában célszerű a tartományi rendszergazdai hitelesítő adatokat vagy egy emelt szintű fiók hitelesítő adatait egy változóban tárolni (például $Cred = Get-Credential ), hogy elkerüljük a minden alkalommal történő beírásukat. Ezután a New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred paranccsal CimSession-t indíthat DCOM-on keresztül egy régebbi, a WSMan-t nem támogató, de WMI-vel rendelkező szerverre.

A szkriptíró szempontjából a fő előny az, hogy a `Get-CimInstance` kimenete nem változik a protokolltól függően : ugyanazokat az objektumokat és tulajdonságokat kapjuk, akár WSMan-t, akár DCOM-ot használunk. Ez nagyban leegyszerűsíti a logikát, mivel a megfelelő protokoll észlelését egy függvénybe csomagolhatjuk, és a kód többi része mindig transzparens módon működhet a CimSessions segítségével.

Valójában elég gyakori, hogy olyan egyéni függvényeket hoznak létre, amelyek a Test-WSMan segítségével tesztelik a WSMan függvényt, és ha az nem érhető el, automatikusan a DCOM-ba kerülnek a New-CimSessionOption használatával. Ez lehetővé teszi a CimSession létrehozásának szabványosítását vegyes környezetekben, mind modern, mind régi szerverekkel, anélkül, hogy a kapcsolati logikát az összes szkriptben replikálni kellene.

CimSessions kezelése, listázása és tisztítása

Amikor széles körben elkezdjük használni a CimSessions-t, fontos nyomon követni őket, hogy elkerüljük a felesleges kapcsolatok felhalmozódását. A Get-CimSession segítségével listázhatjuk az összes megnyitott munkamenetet , láthatjuk, hogy melyik gépre mutatnak, és ellenőrizhetjük, hogy milyen protokollt használnak (WSMAN vagy DCOM), ami nagyon hasznos a csatlakozási vagy hitelesítési problémák diagnosztizálásához.

Ezeket a meglévő munkameneteket egy változóban is lekérheti, például a $CimSession = Get-CimSession paranccsal , és egyetlen parancsban, a Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS paranccsal több számítógépet kérdezhet le egyszerre, a WSMan és a DCOM munkameneteket egyetlen műveletben kombinálva.

Miután befejezte az információk elemzését, érdemes lezárni a munkameneteket, hogy elkerülje az erőforrások szükségtelen megnyitását. A Get-CimSession | Remove-CimSession parancsmag egyszerre eltávolítja az összes aktív CimSession munkamenetet az aktuális profilból. Alternatív megoldásként átadhat adott munkameneteket a Remove-CimSession parancsmagnak, hogy csak néhányat zárjon be közülük.

Ez a módszer lehetővé teszi a szabályozott csatlakozási és leválasztási ciklusok létrehozását , ami erősen ajánlott ütemezett feladatokon, automatizálási runbookokon vagy folyamatos integrációs folyamatokon belüli szkriptek használata esetén, amelyek lefagyó munkameneteket okozhatnak, ha nem tervezi kifejezetten ezt a tisztítást.

A PowerShell, mint átfogó automatizálási nyelv

A WMI-n és a CIM-en túl a PowerShell egy általános célú automatizálási nyelvvé vált , amely messze túlmutat a tipikus Windows-felügyeleti szkripteken. Könyvek és teljes tanfolyamok szenteltek a fejlett képességeinek, mindent lefedve a Linux és Windows rendszerekre történő telepítéstől a NuGet-en keresztül fejleszthető elosztható modulokig, sőt még a modern fejlesztői környezetekig, mint például a Visual Studio Code.

Egy gyakori kiindulópont a PowerShell speciális funkcióinak alapos megértése , amelyek lehetővé teszik a paraméterek definiálását, az érvényesítés végrehajtását, a strukturált kimenet generálását és az integrált súgó elérését szinte egy natív parancsmag szintjén. Innentől kezdve a kód modulokba rendezése megkönnyíti az együttműködést az operatív csapatokon belül, mivel ezeket a modulokat verziózhatja és közzéteheti belső vagy nyilvános NuGet-alapú adattárakban.

Az egyéni objektumokkal és osztályokkal való munka szintén kulcsfontosságú , mivel sokkal gazdagabb adatmodellekhez vezet, mint a tipikus lineáris szkriptek. Ez lehetővé teszi az üzleti logika beágyazását, a struktúrák újrafelhasználását és belső API-k tervezését a saját vezetői csapat számára, mindezt a PowerShell motor segítségével.

A fejlett automatizálás területén a háttérfeladatok és munkafolyamatok kulcsszerepet játszanak , lehetővé téve az aszinkron feladatok kezelését, a hosszadalmas műveletek végrehajtását a konzol blokkolása nélkül, valamint az összetett szekvenciák több gépen történő összehangolását. Ezek a képességek tökéletesen illeszkednek a WMI/CIM tömeges lekérdezéseihez és a távoli adminisztrációs forgatókönyvekhez, ahol gyakran meg kell várni, amíg a rendszerek végrehajtják a változtatásokat vagy visszaadják az adatokat.

Egy másik kulcsfontosságú összetevő a PowerShell DSC (kívánt állapotkonfiguráció), amely lehetővé teszi egy infrastruktúra kívánt konfigurációjának (szerepkörök, funkciók, szolgáltatások, fájlok, biztonsági beállítások stb.) meghatározását, és ezen állapotok ismételt alkalmazását. A WMI/CIM-en keresztül szerzett információkkal kombinálva észlelheti az eltéréseket, proaktívan kijavíthatja azokat, és kevesebb manuális erőfeszítéssel fenntarthatja a konzisztens környezeteket.

Helyi, távoli és felhőalapú felügyelet PowerShell-lel

Helyi szinten a PowerShell parancsmagokat biztosít az Active Directory tartományi szolgáltatások kezeléséhez , a hálózatok konfigurálásához és a szerverek adminisztrálásához. A Windows 10-es és újabb verziókban az integráció még mélyebb, lehetővé téve mindent automatizálni a webhelyek létrehozásától az Active Directory objektumok kezeléséig és a hálózati adapterek konfigurálásáig.

Egy kevésbé ismert, de nagyon hasznos komponens a PSProviders és a PSDrives , amelyek lehetővé teszik a különböző tárolási helyek (fájlrendszer, rendszerleíró adatbázis, Active Directory stb.) navigálható meghajtóként való kezelését. Ennek köszönhetően például Active Directory csoportokat, rendszerleíró kulcsokat vagy mappastruktúrákat hozhat létre távoli számítógépeken ugyanazzal a szintaxissal, amelyet a merevlemez navigálásához használna.

A távoli adminisztráció tekintetében a PowerShell hatékony funkciókat integrál, amelyekkel egy vagy több számítógéphez lehet csatlakozni, és parancsokat lehet végrehajtani a felhasználó nevében . Használhat állandó PSSession munkameneteket, fejlett távelérési technikákat, egy-a-többhöz forgatókönyveket (több szerver egyidejű kezeléséhez) vagy egy-az-egyhez forgatókönyveket adott esetek hibakereséséhez. Mindez természetesen a távoli hozzáférés architektúrájának és biztonsági modelljének tiszteletben tartása mellett.

A felhő ma már alapvető szerepet játszik. Az Azure PowerShell és az Azure Cloud Shell segítségével közvetlenül a parancssorból kezelheti a virtuális gépeket, a tárhelyet és az előfizetéseket. Az Azure PowerShell modulok telepítése és megismerése szinte kötelező, ha hibrid vagy teljes mértékben Azure-ban üzemeltetett környezeteket kezel.

Másrészről a PowerShell a Microsoft 365 (Exchange Online, SharePoint Online, Teams, felhasználók és licencek) kezelésének alapvető eszközévé is vált . A fiókok létrehozásától és kezelésétől az Exchange Online-erőforrások, beleértve a csoportokat, a SharePoint-webhelyeket és a Microsoft Teams adminisztrálásáig minden vezérelhető szkriptekkel, amelyek drasztikusan csökkentik a manuális munkát a webportálon.

Szkriptelés, folyamatok és ajánlott munkamódszerek

A WMI és CIM fejlett automatizálásának maximális kihasználásához elengedhetetlen a PowerShell folyamatmodelljének elsajátítása . Más shellekkel ellentétben itt nem sima szöveget, hanem teljes objektumokat adunk át, így nagy pontossággal választhatjuk ki, rendezhetjük, mérhetjük, szűrhetjük, listázhatjuk és átalakíthatjuk az információkat.

A folyamatok kezelésének elsajátítása magában foglalja a kijelölő és szűrő parancsmagok helyes használatát , az összetett objektumok felsorolásának megértését, valamint az adatok parancsok és szkriptek közötti információvesztés nélküli átadásának elsajátítását. Ezt erősíti a változók, tömbök és hash táblák szervezett használata, amelyek ideiglenes adatszerkezetekként működnek, amelyekre a fejlettebb logika építhető.

A következő lépés maga a szkriptelés: parancsok becsomagolása újrafelhasználható szkriptekbe folyamatvezérléssel (if, for, foreach), adatok importálása CSV-fájlokból vagy más formátumokból, felhasználói bevitel kezelése, hibakezelés és eseménynaplózás. Mindez lehetővé teszi az elszigetelt parancsokról a robusztusabb, beépített eszközökre való áttérést.

A hibaelhárítás és a hibakezelés különösen fontos a WMI/CIM-mel rendelkező nagyméretű automatizálási környezetekben, mivel egy hálózati kimaradás, egy rosszul konfigurált engedély vagy egy hiányzó osztály megszakíthatja a folyamatot, ha nem megfelelően kezelik. A try/catch blokkok, a konfigurálható hibaműveletek és a részletes naplózás segítségével hatékonyabban előre láthatja és reagálhat ezekre a helyzetekre.

Végül minden, ami a függvényekkel és modulokkal kapcsolatos, lezárja a kört : szkripteket írsz alá az integritásuk biztosítása érdekében, függvényeket csomagolsz modulokba, ezeket a modulokat belső vagy nyilvános adattárakban terjeszted, és megosztott eszközök ökoszisztémáját hozod létre a szervezeteden belül. Így minden új WMI, CIM vagy távoli hozzáférési fejlesztés egy koherens és könnyen karbantartható csomagba integrálódik.

Ha a fentieket – WMI/CIM, távoli munkamenetek, szkriptelés, aszinkron feladatok, DSC, Azure és Microsoft 365 – kombinálja, olyan környezetet kap, ahol a PowerShell-lel végzett fejlett automatizálás az adminisztráció középpontjába kerül. A legjobb gyakorlatok szilárd alapjaival, a CimSessions intelligens használatával (mind a WSMan, mind a DCOM használatával), valamint a moduláris szkripttervezéssel heterogén infrastruktúrákat kezelhet konzisztensen, biztonságosan és sokkal hatékonyabban, mint kizárólag grafikus varázslókra vagy elszigetelt eszközökre hagyatkozva.