PowerShell, WMI och CIM för avancerad automatisering i Windows-system

Informatec Digital » Resurser » PowerShell, WMI och CIM för avancerad automatisering i Windows-system

Om du arbetar med att administrera Windows-system kommer du förr eller senare att stöta på PowerShell, WMI och avancerad automatisering . Det handlar inte bara om att veta hur man kör några få kommandon: när du hanterar dussintals eller hundratals servrar behöver du en seriös, strukturerad och säker metod för att samla in information, tillämpa ändringar och upprepa uppgifter utan att bli galen ... eller att något går sönder.

I följande rader ska vi lugnt men grundligt utforska hur man kan utnyttja WMI, CIM och PowerShell-fjärrkommunikation för att automatisera allt från enkla frågor till komplexa infrastrukturscenarier. Vi ska också se hur allt detta passar ihop med moduler, bakgrundsuppgifter, Azure, Microsoft 365 och några avancerade funktioner som gör en verklig skillnad i en systemadministratörs dagliga arbete.

PowerShell-förbättringar och en översikt över avancerad automatisering

Windows PowerShell har utvecklats mycket sedan dess tidiga versioner, och en stor del av den utvecklingen kom med Windows Server 2012, där fjärrkommunikation förbättrades, tillgängliga cmdlets utökades och saker som felsökning, bakgrundsjobb och begränsade slutpunkter gjordes enklare för att förbättra säkerheten.

En av huvudidéerna bakom den här miljön är att administratörer kan skapa cmdlet-liknande beteenden utan omfattande kodning , genom att utnyttja avancerade funktioner, återanvändbara moduler och ett omfattande hjälpsystem. Det innebär att istället för att förlita sig på olika grafiska verktyg kan man bygga en sammanhängande uppsättning skript och moduler som automatiserar processer för att hantera servrar, nätverk, Active Directory, Azure eller Microsoft 365.

Inom området avancerad automatisering utmärker sig även funktioner som jobb för att utföra uppgifter asynkront, arbetsflöden, konfigurationsbaserad administration med PowerShell DSC och säkerhetsalternativ som JEA (Just Enough Administration) eller PowerShell Web Access, vilket möjliggör detaljerad kontroll över vad varje person kan göra och varifrån.

Hela detta ekosystem passar särskilt bra med WMI och CIM, eftersom hanteringsinformationen som exponeras av operativsystemet (hårdvara, tjänster, processer , nätverkskonfiguration, installerad programvara etc.) blir en uppsättning objekt som du kan fråga, filtrera och modifiera med PowerShell-kommandon som är utformade för massautomation.

WMI och CIM: Viktiga begrepp och praktiska skillnader

Windows Management Instrumentation, mer känt som WMI, är en PowerShell-oberoende teknik som har varit en del av Windows i åratal. Den exponerar ett arkiv med hanteringsinformation om operativsystemet, hårdvaran och många applikationer. Även om den inte är beroende av PowerShell, använder PowerShell den i stor utsträckning för att automatisera uppgifter.

Den naturliga efterföljaren till WMI i PowerShell-ekosystemet är CIM-cmdlets (Common Information Model) , som introducerades med PowerShell 3.0. Dessa cmdlets är grupperade i CimCmdlets-modulen och inkluderar kommandon som Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance och Remove-CimInstance, bland andra.

I äldre versioner av Windows PowerShell, som Windows 10 PowerShell 5.1 eller Windows 11 PowerShell, kan du fortfarande hitta de klassiska WMI-cmdlets (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Dessa cmdlets är dock föråldrade och ingår inte längre i PowerShell 6 och senare versioner, så de är endast relevanta för att underhålla äldre skript eller granska gammal kod.

När någon pratar om att "fråga WMI med CIM-cmdlets" är det inte motsägelsefullt: CIM-cmdlets kommer fortfarande åt WMI-information , men de gör det med modernare protokoll som WSMan och ett mer konsekvent API. Rent praktiskt bör du, för nya utvecklingar, fokusera på CIM och bara överväga WMI-cmdlets när du behöver migrera eller förstå äldre skript.

Historiskt sett använde många administratörer VBScript med frågespråket WQL för att fråga WMI, till exempel genom att ansluta till namnrymden root\CIMV2 och fråga klasser som Win32_BIOS. Samma WQL-fråga kan återanvändas idag med Get-CimInstance genom att skicka parametern -Query, vilket avsevärt förenklar övergången från VBScript till PowerShell utan att behöva skriva om logiken från grunden.

Praktisk användning av Get-CimInstance och effektiva frågor

För vardagligt arbete är det mest naturliga sättet att fråga WMI med PowerShell att använda Get-CimInstance med parametern -ClassName , snarare än att skriva fullständiga WQL-frågor. För att till exempel hämta BIOS-information kan du använda Get-CimInstance -ClassName Win32_BIOS och du får ett objekt med egenskaper som Tillverkare, Namn, Serienummer eller SMBIOSBIOSVersion.

Eftersom allt i PowerShell är ett objekt är det väldigt enkelt att filtrera och bara välja det du behöver . Om du bara är intresserad av serienumret kan du skicka resultatet till `Select-Object -Property SerialNumber`, eller använda `Select-Object -ExpandProperty SerialNumber` för att mata ut en enkel sträng istället för ett objekt med en egenskap. Ett annat vanligt alternativ är att använda punktsyntax (`Get-CimInstance ...`).SerialNumber` för att komma åt värdet direkt.

Det är värt att notera att WMI-frågor som standard returnerar fler egenskaper än du faktiskt kommer att använda . På en lokal maskin är detta vanligtvis okej, men när du börjar fråga många fjärrmaskiner leder det till ytterligare bearbetningstid och onödig nätverkstrafik. Det är här parametern `-Property` i `Get-CimInstance` kommer in i bilden, vilket gör att du kan begränsa vilka egenskaper som hämtas från källan.

Genom att till exempel ange -Property SerialNumber minskar du mängden data som överförs, vilket gör frågan snabbare och effektivare, särskilt i stor skala . Denna "fråga bara efter det du behöver"-mentalitet är nyckeln när man utformar inventerings- eller granskningsskript som körs på dussintals eller hundratals maskiner.

Sammanfattningsvis erbjuder Get-CimInstance en kraftfull balans mellan enkelhet (en kommandorad) och flexibilitet , oavsett om du arbetar med konkreta klasser, äldre WQL-frågor eller specifika egenskaper som du vill optimera för hämtning.

Distanskonsultationer med CIM, sessioner och WSMan/DCOM-protokoll

När du flyttar bort från din lokala maskin och börjar komma åt fjärrmaskiner spelar flera faktorer in: behörigheter, kommunikationsprotokoll och prestanda . Även om många ser PowerShell som "farligt" är sanningen att det inte ger dig några extra privilegier: du har exakt samma behörigheter som med det grafiska gränssnittet eller något annat verktyg, varken mer eller mindre.

Om du försöker köra `Get-CimInstance -ComputerName Server -ClassName Win32_BIOS` utan tillräckliga behörigheter på den maskinen får du felmeddelandet "Åtkomst nekad" . Detta beror inte på att PowerShell misslyckas; det är helt enkelt att användaren du kör sessionen som inte har rätt att komma åt den informationen i WMI. Du kan naturligtvis öppna en konsol som domänadministratör, men det betyder att alla kommandon kommer att köras med dessa behörigheter, vilket är en onödig risk i många miljöer.

Rekommendationen är att tillämpa principen om lägsta möjliga privilegier och endast höja privilegier när det är nödvändigt . I cmdlets som stöder parametern -Credential kan du ange alternativa autentiseringsuppgifter endast för kommandot i fråga. Get-CimInstance accepterar dock inte -Credential direkt, och det är här CimSessions kommer in som en elegant lösning.

En CimSession är en permanent anslutning till en fjärrdator som du kan skapa med New-CimSession, och skicka datornamnet och autentiseringsuppgifterna (till exempel New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Denna session lagras i en variabel, till exempel $CimSession, och återanvänds sedan med Get-CimInstance genom att använda parametern -CimSession istället för -ComputerName, vilket gör att du kan konsolidera flera frågor till en enda anslutning.

Utöver kravet på autentiseringsuppgifter använder Get-CimInstance WSMan-protokollet (baserat på WinRM) som standard . Det betyder att fjärrdatorn måste ha WSMan-stacken version 3.0 eller högre, vilket vanligtvis finns i PowerShell 3.0 och senare. Du kan kontrollera WSMan-stacken versionen på en dator med `Test-WSMan -ComputerName RemoteComputer` och verifiera att "Stack"-värdet är 3.0 eller högre för att använda den här anslutningsmetoden.

CIM-sessioner med DCOM och bakåtkompatibilitet

De äldre WMI-cmdlets som är baserade på Get-WmiObject förlitar sig på DCOM-protokollet, vilket fortfarande stöds av äldre versioner av Windows . Problemet är att brandväggar ofta blockerar DCOM som standard på modernare system, vilket kräver att du öppnar specifika portar för att använda det som det är, vilket kan bryta mot organisationens säkerhetspolicyer.

CIM-cmdlets erbjuder en kraftfull mellanväg: du kan skapa sessionsalternativ med `New-CimSessionOption -Protocol Dcom` , spara dem i en variabel (till exempel `$DCOM`) och sedan kombinera dem med `New-CimSession` för att generera en CimSession som använder DCOM istället för WSMan. Detta gör att du kan ansluta till mycket gamla servrar, även de som är äldre än Windows Server 2000, där PowerShell inte ens är installerat.

Det är oftast praktiskt att lagra domänadministratörsuppgifter eller uppgifter för ett utökat konto i en variabel (till exempel $Cred = Get-Credential ) för att undvika att behöva skriva in dem varje gång. Sedan, med något i stil med New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred, kan du starta en CimSession över DCOM till en äldre server som inte stöder WSMan men har WMI.

Ur manusförfattarens perspektiv är den största fördelen att utdata från `Get-CimInstance` inte ändras beroende på protokoll : du får samma objekt och egenskaper oavsett om du använder WSMan eller DCOM. Detta förenklar logiken avsevärt eftersom du kan inkapsla detekteringen av lämpligt protokoll i en funktion och låta resten av koden alltid fungera transparent med CimSessions.

Det är faktiskt ganska vanligt att skapa anpassade funktioner som testar WSMan med Test-WSMan och, om det inte är tillgängligt, automatiskt hamnar i DCOM med hjälp av New-CimSessionOption. Detta gör att du kan standardisera skapandet av CimSession i blandade miljöer med både moderna och äldre servrar, utan att replikera anslutningslogik i alla dina skript.

Hantering, listning och rensning av CimSessions

När du börjar använda CimSessions i stor utsträckning är det viktigt att hålla koll på dem för att undvika att onödiga anslutningar samlas. Med Get-CimSession kan du lista alla öppna sessioner , se vilken maskin de pekar på och kontrollera vilket protokoll de använder (WSMAN eller DCOM), vilket är mycket användbart för att diagnostisera anslutnings- eller autentiseringsproblem.

Du kan också hämta de befintliga sessionerna i en variabel, till exempel $CimSession = Get-CimSession , och använda dem i ett enda kommando Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS för att fråga flera datorer samtidigt, och kombinera WSMan- och DCOM-sessioner i samma operation.

När du har analyserat informationen är det en bra idé att stänga sessionerna för att undvika att lämna resurser öppna i onödan. Cmdlet:en Get-CimSession | Remove-CimSession tar bort alla aktiva CimSessions från den aktuella profilen på en gång. Alternativt kan du skicka specifika sessioner till cmdlet:en Remove-CimSession för att stänga endast några av dem.

Genom att arbeta på det här sättet kan du ha kontrollerade anslutnings- och frånkopplingscykler , vilket starkt rekommenderas när du använder skript inom schemalagda uppgifter, automatiserings-runbooks eller pipelines för kontinuerlig integration som kan få sessioner att hänga sig om du inte uttryckligen planerar för den rensningen.

PowerShell som ett omfattande automatiseringsspråk

Utöver WMI och CIM har PowerShell blivit ett generellt automatiseringsspråk som går långt utöver det typiska Windows-hanteringsskriptet. Det finns böcker och hela kurser dedikerade till dess avancerade funktioner, som täcker allt från installation på Linux och Windows till utveckling av distribuerbara moduler via NuGet, och till och med moderna utvecklingsmiljöer som Visual Studio Code.

En vanlig utgångspunkt är att noggrant förstå PowerShells avancerade funktioner , som låter dig definiera parametrar, utföra validering, generera strukturerad utdata och få tillgång till integrerad hjälp nästan på nivå med en inbyggd cmdlet. Därifrån underlättar organisering av kod i moduler samarbete inom driftsteam, eftersom du kan versionsgenerera och publicera dessa moduler till interna eller offentliga NuGet-baserade databaser.

Att arbeta med anpassade objekt och klasser är också viktigt , vilket öppnar dörren till mycket rikare datamodeller än typiska linjära skript. Detta gör att du kan inkapsla affärslogik, återanvända strukturer och designa interna API:er för ditt eget ledningsteam, allt drivet av PowerShell-motorn.

Inom avancerad automatisering spelar bakgrundsjobb och arbetsflöden en avgörande roll , vilket möjliggör hantering av asynkrona uppgifter, körning av långa operationer utan att blockera konsolen och orkestrering av komplexa sekvenser över flera maskiner. Dessa funktioner passar perfekt för massfrågor till WMI/CIM och fjärradministrationsscenarier, där det ofta är nödvändigt att vänta på att system ska implementera ändringar eller returnera data.

En annan viktig komponent är PowerShell DSC (Desired State Configuration), som låter dig definiera önskad konfiguration av en infrastruktur (roller, funktioner, tjänster, filer, säkerhetsinställningar etc.) och tillämpa dessa tillstånd upprepade gånger. Kombinerat med informationen du får via WMI/CIM kan du upptäcka avvikelser, proaktivt korrigera dem och upprätthålla konsekventa miljöer med mindre manuell ansträngning.

Lokal, fjärr- och molnhantering med PowerShell

På lokal nivå tillhandahåller PowerShell cmdlets för att hantera Active Directory Domain Services , konfigurera nätverk och administrera servrar. I Windows 10 och senare versioner är integrationen ännu djupare, vilket gör att du kan automatisera allt från att skapa webbplatser till att hantera Active Directory-objekt och konfigurera nätverkskort.

En mindre känd men mycket användbar komponent är PSProviders och PSDrives , som låter dig behandla olika lagringsplatser (filsystem, register, Active Directory, etc.) som om de vore navigerbara enheter. Tack vare detta kan du till exempel skapa Active Directory-grupper, registernycklar eller mappstrukturer på fjärrdatorer med samma syntax som du skulle använda för att navigera på hårddisken.

När det gäller fjärradministration integrerar PowerShell en kraftfull uppsättning funktioner för att ansluta till en eller flera datorer och utföra kommandon åt dig . Du kan använda ihållande PSSession-sessioner, avancerade fjärrstyrningstekniker, en-till-många-scenarier (för att hantera flera servrar samtidigt) eller en-till-en-scenarier för felsökning av specifika fall. Allt detta, naturligtvis, med respekt för arkitekturen och säkerhetsmodellen för fjärråtkomst.

Molnet spelar också en grundläggande roll idag. Med Azure PowerShell och Azure Cloud Shell kan du hantera virtuella maskiner, lagring och prenumerationer direkt från kommandoraden. Att installera Azure PowerShell-moduler och bekanta sig med dem är nästan obligatoriskt om du hanterar hybrid- eller helt Azure-hostade miljöer.

Å andra sidan har PowerShell också etablerat sig som ett självklart verktyg för att hantera Microsoft 365 (Exchange Online, SharePoint Online, Teams, användare och licenser). Från att skapa och hantera konton till att administrera Exchange Online-resurser, inklusive grupper, SharePoint-webbplatser och Microsoft Teams, kan allt orkestreras med skript som drastiskt minskar det manuella arbetet på webbportalen.

Skripting, pipelines och bästa arbetsmetoder

För att få ut det mesta av avancerad automatisering med WMI och CIM är det viktigt att behärska PowerShells pipeline-modell . Till skillnad från andra shell skickar du inte vanlig text här, utan snarare kompletta objekt, vilket gör att du kan välja, sortera, mäta, filtrera, räkna upp och transformera information med stor precision.

Att lära sig arbeta med pipelines innebär att använda urvals- och filtrerings-cmdlets korrekt , förstå hur man räknar upp komplexa objekt och hur man skickar data mellan kommandon och skript utan att förlora information. Detta förstärks av den organiserade användningen av variabler, arrayer och hashtabeller, som fungerar som tillfälliga datastrukturer att bygga mer avancerad logik på.

Nästa steg är själva skriptningen: paketera kommandon till återanvändbara skript med flödeskontroll (if, for, foreach), importera data från CSV-filer eller andra format, hantera användarinmatning, felhantering och händelseloggning. Allt detta gör att du kan gå från isolerade kommandon till mer robusta, inbyggda verktyg.

Felsökning och felhantering är särskilt viktigt i storskaliga automationsmiljöer med WMI/CIM, eftersom ett nätverksavbrott, en felkonfigurerad behörighet eller en saknad klass kan förstöra en process om den inte hanteras korrekt. Med try/catch-block, konfigurerbara felåtgärder och detaljerad loggning kan du förutse och reagera mer effektivt på dessa situationer.

Slutligen kompletterar allt som rör funktioner och moduler cirkeln : du signerar skript för att säkerställa deras integritet, paketerar funktioner i moduler, distribuerar dessa moduler i interna eller offentliga databaser och skapar ett ekosystem av delade verktyg inom din organisation. På så sätt integreras all ny utveckling av WMI, CIM eller fjärrstyrning i en sammanhängande och lättskött svit.

När du kombinerar allt ovanstående – WMI/CIM, fjärrsessioner, skript, asynkrona jobb, DSC, Azure och Microsoft 365 – får du en miljö där avancerad automatisering med PowerShell blir kärnan i administrationen. Med en solid grund av bästa praxis, intelligent användning av CimSessions (med både WSMan och DCOM) och en modulär skriptdesign kan du hantera heterogena infrastrukturer konsekvent, säkert och mycket mer effektivt än att enbart förlita dig på grafiska guider eller isolerade verktyg.