PowerShell, WMI og CIM til avanceret automatisering i Windows-systemer

Informatic Digital » Recursos » PowerShell, WMI og CIM til avanceret automatisering i Windows-systemer

Hvis du arbejder med at administrere Windows-systemer, vil du før eller siden støde på PowerShell, WMI og avanceret automatisering . Det handler ikke kun om at vide, hvordan man kører et par kommandoer: Når du administrerer snesevis eller hundredvis af servere, har du brug for en seriøs, struktureret og sikker tilgang til at indsamle information, anvende ændringer og gentage opgaver uden at gå amok ... eller ødelægge noget.

I de følgende linjer vil vi roligt, men grundigt, udforske, hvordan man kan udnytte WMI, CIM og PowerShell fjernkommunikation til at automatisere alt fra simple forespørgsler til komplekse infrastrukturscenarier. Vi vil også se, hvordan alt dette passer sammen med moduler, baggrundsopgaver, Azure, Microsoft 365 og nogle avancerede funktioner, der gør en reel forskel i en systemadministrators daglige arbejde.

PowerShell-forbedringer og en oversigt over avanceret automatisering

Windows PowerShell har udviklet sig meget siden de tidlige versioner, og en stor del af denne udvikling kom med Windows Server 2012, hvor fjernkommunikation blev forbedret, de tilgængelige cmdlets blev udvidet, og ting som fejlfinding, baggrundsjob og begrænsede slutpunkter blev gjort nemmere for at forbedre sikkerheden.

En af hovedidéerne bag dette miljø er, at administratorer kan oprette cmdlet-lignende adfærd uden omfattende kodning , udnytte avancerede funktioner, genanvendelige moduler og et omfattende hjælpesystem. Det betyder, at i stedet for at stole på forskellige grafiske værktøjer, kan man opbygge et sammenhængende sæt af scripts og moduler, der automatiserer processer til administration af servere, netværk, Active Directory, Azure eller Microsoft 365.

Inden for avanceret automatisering skiller funktioner som job til at udføre opgaver asynkront, arbejdsgange, konfigurationsbaseret administration med PowerShell DSC og sikkerhedsmuligheder som JEA (Just Enough Administration) eller PowerShell Web Access sig også ud, hvilket giver mulighed for detaljeret kontrol over, hvad hver person kan gøre, og hvorfra.

Hele dette økosystem passer særligt godt sammen med WMI og CIM, da de administrationsoplysninger, der eksponeres af operativsystemet (hardware, tjenester, processer , netværkskonfiguration, installeret software osv.), bliver et sæt objekter, som du kan forespørge på, filtrere og ændre ved hjælp af PowerShell-kommandoer designet til masseautomatisering.

WMI og CIM: Nøglebegreber og praktiske forskelle

Windows Management Instrumentation, bedre kendt som WMI, er en PowerShell-uafhængig teknologi , der har været en del af Windows i årevis. Den eksponerer et lager af administrationsoplysninger om operativsystemet, hardware og mange applikationer. Selvom den ikke er afhængig af PowerShell, udnytter PowerShell den i vid udstrækning til at automatisere opgaver.

Den naturlige efterfølger til WMI i PowerShell-økosystemet er CIM (Common Information Model) cmdlets , der blev introduceret med PowerShell 3.0. Disse cmdlets er grupperet i CimCmdlets-modulet og inkluderer kommandoer som Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance og Remove-CimInstance, blandt andre.

I ældre versioner af Windows PowerShell, såsom Windows 10 PowerShell 5.1 eller Windows 11 PowerShell, kan du stadig finde de klassiske WMI-cmdlets (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Disse cmdlets er dog forældede og ikke længere inkluderet i PowerShell 6 og nyere versioner, så de er kun relevante for vedligeholdelse af ældre scripts eller gennemgang af gammel kode.

Når nogen taler om at "forespørge WMI med CIM-cmdlets", er det ikke modstridende: CIM-cmdlets tilgår stadig WMI-oplysninger , men de gør det ved hjælp af mere moderne protokoller som WSMan og en mere konsistent API. I praksis bør du i forbindelse med nye udviklinger fokusere på CIM og kun overveje WMI-cmdlets, når du har brug for at migrere eller forstå ældre scripts.

Historisk set brugte mange administratorer VBScript med WQL-forespørgselssproget til at forespørge på WMI, for eksempel ved at oprette forbindelse til navneområdet root\CIMV2 og forespørge på klasser som Win32_BIOS. Den samme WQL-forespørgsel kan genbruges i dag med Get-CimInstance ved at overføre parameteren -Query, hvilket i høj grad forenkler overgangen fra VBScript til PowerShell uden at skulle omskrive logikken fra bunden.

Praktisk brug af Get-CimInstance og effektive forespørgsler

Til det daglige arbejde er den mest naturlige måde at forespørge WMI med PowerShell at bruge Get-CimInstance med parameteren -ClassName i stedet for at skrive fulde WQL-forespørgsler. For eksempel kan du bruge Get-CimInstance -ClassName Win32_BIOS for at få BIOS-oplysninger, og du vil modtage et objekt med egenskaber som Manufacturer, Name, SerialNumber eller SMBIOSBIOSVersion.

Da alt i PowerShell er et objekt, er det meget nemt at filtrere og kun vælge det, du har brug for . Hvis du kun er interesseret i serienummeret, kan du sende resultatet til `Select-Object -Property SerialNumber` eller bruge `Select-Object -ExpandProperty SerialNumber` til at udskrive en simpel streng i stedet for et objekt med en egenskab. En anden almindelig mulighed er at bruge punktumsyntaks (`Get-CimInstance ...`).SerialNumber` for at få direkte adgang til værdien.

Det er værd at bemærke, at WMI-forespørgsler som standard returnerer flere egenskaber, end du rent faktisk bruger . På en lokal maskine er dette normalt fint, men når du begynder at forespørge på mange eksterne maskiner, resulterer det i ekstra behandlingstid og unødvendig netværkstrafik. Det er her, parameteren `-Property` i `Get-CimInstance` kommer ind i billedet, så du kan begrænse, hvilke egenskaber der hentes fra kilden.

Ved at angive -Property SerialNumber reducerer du for eksempel mængden af ​​overførte data, hvilket gør forespørgslen hurtigere og mere effektiv, især i stor skala . Denne "spørg kun om det, du har brug for"-mentalitet er nøglen, når man designer lager- eller revisionsscripts, der kører på snesevis eller hundredvis af maskiner.

Kort sagt tilbyder Get-CimInstance en stærk balance mellem enkelhed (én kommandolinje) og fleksibilitet , uanset om du arbejder med konkrete klasser, ældre WQL-forespørgsler eller specifikke egenskaber, du vil optimere til hentning.

Fjernkonsultationer med CIM, sessioner og WSMan/DCOM-protokoller

Når du flytter væk fra din lokale maskine og begynder at tilgå eksterne maskiner, spiller flere faktorer ind: tilladelser, kommunikationsprotokol og ydeevne . Selvom mange mennesker ser PowerShell som "farlig", er sandheden, at det ikke giver dig nogen ekstra privilegier: du har præcis de samme tilladelser som med den grafiske brugerflade eller ethvert andet værktøj, hverken mere eller mindre.

Hvis du forsøger at køre `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` uden tilstrækkelige rettigheder på den pågældende maskine, får du fejlen "Adgang nægtet" . Dette skyldes ikke, at PowerShell fejler; det er simpelthen, at den bruger, du kører sessionen som, ikke har ret til at få adgang til disse oplysninger i WMI. Du kan selvfølgelig åbne en konsol som domæneadministrator, men det betyder, at enhver kommando vil blive udført med disse rettigheder, hvilket er en unødvendig risiko i mange miljøer.

Anbefalingen er at anvende princippet om færrest rettigheder og kun øge rettigheder, når det er nødvendigt . I cmdlets, der understøtter parameteren -Credential, kan du angive alternative legitimationsoplysninger kun for den pågældende kommando. Get-CimInstance accepterer dog ikke direkte -Credential, og det er her, CimSessions kommer ind i billedet som en elegant løsning.

En CimSession er en vedvarende forbindelse til en fjerncomputer, som du kan oprette med New-CimSession, hvor computernavnet og legitimationsoplysningerne videregives (f.eks. New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Denne session gemmes i en variabel, f.eks. $CimSession, og genbruges derefter med Get-CimInstance ved at bruge parameteren -CimSession i stedet for -ComputerName, hvilket giver dig mulighed for at konsolidere flere forespørgsler i en enkelt forbindelse.

Ud over kravet om legitimationsoplysninger bruger Get-CimInstance som standard WSMan-protokollen (baseret på WinRM) . Det betyder, at den eksterne maskine skal have WSMan-stakversionen 3.0 eller højere, som typisk findes i PowerShell 3.0 og nyere. Du kan kontrollere WSMan-stakversionen på en maskine med `Test-WSMan -ComputerName RemoteComputer` og bekræfte, at "Stack"-værdien er 3.0 eller højere for at bruge denne forbindelsesmetode.

CIM-sessioner med DCOM og bagudkompatibilitet

De ældre WMI-cmdlets baseret på Get-WmiObject er afhængige af DCOM-protokollen, som stadig understøttes af ældre versioner af Windows . Problemet er, at firewalls på mere moderne systemer ofte blokerer DCOM som standard, hvilket kræver, at du åbner specifikke porte for at bruge den, som den er, hvilket kan overtræde din organisations sikkerhedspolitikker.

CIM-cmdlet'erne tilbyder en effektiv mellemvej: du kan oprette sessionsindstillinger med `New-CimSessionOption -Protocol Dcom` , gemme dem i en variabel (f.eks. `$DCOM`) og derefter kombinere dem med `New-CimSession` for at generere en CimSession, der bruger DCOM i stedet for WSMan. Dette giver dig mulighed for at oprette forbindelse til meget gamle servere, selv dem før Windows Server 2000, hvor PowerShell ikke engang er installeret.

Det er normalt praktisk at gemme domæneadministratoroplysninger eller legitimationsoplysninger for en forhøjet konto i en variabel (f.eks. $Cred = Get-Credential ) for at undgå at skulle skrive dem hver gang. Derefter kan du med noget i retning af New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred starte en CimSession over DCOM til en ældre server, der ikke understøtter WSMan, men som har WMI.

Fra manuskriptforfatterens perspektiv er den største fordel, at outputtet fra `Get-CimInstance` ikke ændrer sig afhængigt af protokollen : du får de samme objekter og egenskaber, uanset om du bruger WSMan eller DCOM. Dette forenkler logikken betydeligt, fordi du kan indkapsle detekteringen af ​​den relevante protokol i en funktion og lade resten af ​​koden altid fungere transparent med CimSessions.

Faktisk er det ret almindeligt at oprette brugerdefinerede funktioner, der tester WSMan med Test-WSMan, og hvis det ikke er tilgængeligt, automatisk falder ind i DCOM ved hjælp af New-CimSessionOption. Dette giver dig mulighed for at standardisere oprettelsen af ​​CimSession på tværs af blandede miljøer med både moderne og ældre servere uden at replikere forbindelseslogik i alle dine scripts.

Administration, liste og oprydning af CimSessions

Når du begynder at bruge CimSessions i vid udstrækning, er det vigtigt at holde styr på dem for at undgå at ophobe unødvendige forbindelser. Med Get-CimSession kan du liste alle åbne sessioner , se hvilken maskine de peger på, og kontrollere hvilken protokol de bruger (WSMAN eller DCOM), hvilket er meget nyttigt til at diagnosticere forbindelses- eller godkendelsesproblemer.

Du kan også hente disse eksisterende sessioner i en variabel, for eksempel $CimSession = Get-CimSession , og bruge dem i en enkelt kommando Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS til at forespørge flere computere på én gang og kombinere WSMan- og DCOM-sessioner i samme handling.

Når du er færdig med at analysere disse oplysninger, er det en god idé at lukke sessionerne for at undgå at lade ressourcer stå unødvendigt åbne. Cmdlet'en Get-CimSession | Remove-CimSession fjerner alle aktive CimSessions fra den aktuelle profil på én gang. Alternativt kan du overføre specifikke sessioner til cmdlet'en Remove-CimSession for kun at lukke nogle af dem.

Ved at arbejde på denne måde kan du have kontrollerede forbindelses- og afbrydelsescyklusser , hvilket anbefales kraftigt, når du bruger scripts i planlagte opgaver, automatiserings-runbooks eller pipelines til kontinuerlig integration, der kan få sessioner til at hænge, ​​hvis du ikke eksplicit planlægger denne oprydning.

PowerShell som et omfattende automatiseringssprog

Ud over WMI og CIM er PowerShell blevet et generelt automatiseringssprog , der går langt ud over det typiske Windows-administrationsscript. Der findes bøger og hele kurser dedikeret til dets avancerede funktioner, der dækker alt fra installation på Linux og Windows til udvikling af distribuerbare moduler via NuGet og endda moderne udviklingsmiljøer som Visual Studio Code.

Et almindeligt udgangspunkt er at have en grundig forståelse af PowerShells avancerede funktioner , som giver dig mulighed for at definere parametre, udføre validering, generere struktureret output og få adgang til integreret hjælp næsten på niveau med en native cmdlet. Derfra letter organisering af kode i moduler samarbejdet inden for driftsteams, da du kan versionere og udgive disse moduler til interne eller offentlige NuGet-baserede lagre.

Det er også vigtigt at arbejde med brugerdefinerede objekter og klasser , da det åbner døren til langt rigere datamodeller end typiske lineære scripts. Dette giver dig mulighed for at indkapsle forretningslogik, genbruge strukturer og designe interne API'er til dit eget ledelsesteam, alt sammen drevet af PowerShell-motoren.

Inden for avanceret automatisering spiller baggrundsjob og arbejdsgange en afgørende rolle , da de muliggør styring af asynkrone opgaver, udførelse af langvarige operationer uden at blokere konsollen og orkestrering af komplekse sekvenser på tværs af flere maskiner. Disse funktioner er perfekte til masseforespørgsler til WMI/CIM og fjernadministrationsscenarier, hvor det ofte er nødvendigt at vente på, at systemer implementerer ændringer eller returnerer data.

En anden nøglekomponent er PowerShell DSC (Desired State Configuration), som giver dig mulighed for at definere den ønskede konfiguration af en infrastruktur (roller, funktioner, tjenester, filer, sikkerhedsindstillinger osv.) og anvende disse tilstande gentagne gange. Kombineret med de oplysninger, du får via WMI/CIM, kan du registrere afvigelser, proaktivt rette dem og opretholde ensartede miljøer med mindre manuel indsats.

Lokal, fjern- og cloud-administration med PowerShell

På lokalt niveau leverer PowerShell cmdlets til administration af Active Directory Domain Services , konfiguration af netværk og administration af servere. I Windows 10 og nyere versioner er integrationen endnu dybere, hvilket giver dig mulighed for at automatisere alt fra oprettelse af websteder til administration af Active Directory-objekter og konfiguration af netværkskort.

En mindre kendt, men meget nyttig komponent er PSProviders og PSDrives , som giver dig mulighed for at behandle forskellige lagerplaceringer (filsystem, registreringsdatabase, Active Directory osv.), som om de var navigerbare drev. Takket være dette kan du f.eks. oprette Active Directory-grupper, registreringsdatabasenøgler eller mappestrukturer på eksterne computere ved hjælp af den samme syntaks, som du ville bruge til at navigere på harddisken.

Med hensyn til fjernadministration integrerer PowerShell et kraftfuldt sæt funktioner til at oprette forbindelse til en eller flere computere og udføre kommandoer på dine vegne . Du kan bruge vedvarende PSSession-sessioner, avancerede fjernstyringsteknikker, en-til-mange-scenarier (til at administrere flere servere samtidigt) eller en-til-en-scenarier til fejlfinding af specifikke tilfælde. Alt dette, selvfølgelig med respekt for arkitekturen og sikkerhedsmodellen for fjernadgang.

Skyen spiller også en fundamental rolle i dag. Med Azure PowerShell og Azure Cloud Shell kan du administrere virtuelle maskiner, lagerplads og abonnementer direkte fra kommandolinjen. Installation af Azure PowerShell-moduler og at blive fortrolig med dem er næsten obligatorisk, hvis du administrerer hybride eller fuldt Azure-hostede miljøer.

På den anden side har PowerShell også etableret sig som et oplagt værktøj til administration af Microsoft 365 (Exchange Online, SharePoint Online, Teams, brugere og licenser). Fra oprettelse og administration af konti til administration af Exchange Online-ressourcer, herunder grupper, SharePoint-websteder og Microsoft Teams, kan alt orkestreres med scripts, der drastisk reducerer det manuelle arbejde på webportalen.

Scripting, pipelines og bedste arbejdspraksis

For at få mest muligt ud af avanceret automatisering med WMI og CIM er det vigtigt at mestre PowerShells pipeline-model . I modsætning til andre shells sender du ikke almindelig tekst her, men snarere komplette objekter, hvilket giver dig mulighed for at vælge, sortere, måle, filtrere, opregne og transformere information med stor præcision.

At lære at arbejde med pipelines involverer korrekt brug af selektion- og filtrerings-cmdlets , forståelse af, hvordan man opregner komplekse objekter, og hvordan man overfører data mellem kommandoer og scripts uden at miste information. Dette forstærkes af den organiserede brug af variabler, arrays og hashtabeller, der fungerer som midlertidige datastrukturer, som mere avanceret logik kan bygges på.

Det næste trin er selve scriptingen: pakning af kommandoer til genanvendelige scripts med flowkontrol (if, for, foreach), import af data fra CSV-filer eller andre formater, håndtering af brugerinput, fejlhåndtering og hændelseslogning. Alt dette giver dig mulighed for at gå fra isolerede kommandoer til mere robuste, indbyggede værktøjer.

Fejlfinding og fejlhåndtering er særligt vigtigt i store automatiseringsmiljøer med WMI/CIM, da et netværksafbrydelse, en forkert konfigureret tilladelse eller en manglende klasse kan afbryde en proces, hvis den ikke håndteres korrekt. Med try/catch-blokke, konfigurerbare fejlhandlinger og detaljeret logføring kan du forudse og reagere mere effektivt på disse situationer.

Endelig fuldender alt relateret til funktioner og moduler cirklen : du signerer scripts for at sikre deres integritet, pakker funktioner i moduler, distribuerer disse moduler i interne eller offentlige arkiver og skaber et økosystem af delte værktøjer i din organisation. På denne måde integreres enhver ny udvikling på WMI, CIM eller fjernstyring i en sammenhængende og let vedligeholdelig suite.

Når du kombinerer alt ovenstående – WMI/CIM, fjernsessioner, scripting, asynkrone job, DSC, Azure og Microsoft 365 – får du et miljø, hvor avanceret automatisering med PowerShell bliver kernen i administrationen. Med et solidt fundament af bedste praksis, intelligent brug af CimSessions (med både WSMan og DCOM) og et modulært scriptdesign kan du administrere heterogene infrastrukturer konsekvent, sikkert og langt mere effektivt end ved udelukkende at stole på grafiske guider eller isolerede værktøjer.