PowerShell WMI i CIM per a una automatització avançada en sistemes Windows

Informatec Digital » Recursos » PowerShell WMI i CIM per a una automatització avançada en sistemes Windows

Si treballeu administrant sistemes Windows, tard o d'hora acabeu xocant amb PowerShell, WMI i l'automatització avançada . No és només qüestió de saber llançar quatre ordres: quan gestiones dotzenes o centenars de servidors, necessites un enfocament seriós, estructurat i segur per obtenir informació, aplicar canvis i repetir tasques sense tornar-te boig… ni trencar res.

A les properes línies recorrerem, amb calma però en profunditat, com aprofitar WMI, CIM i la comunicació remota de PowerShell per automatitzar des de consultes senzilles fins a escenaris d'infraestructura complexos. A més, veurem com encaixa tot això amb mòduls, feines en segon pla, Azure, Microsoft 365 i algunes funcions avançades que marquen la diferència en el dia a dia d'un administrador de sistemes.

Millores de PowerShell i visió general de l'automatització avançada

Windows PowerShell ha evolucionat moltíssim des de les primeres versions, i gran part d'aquesta evolució va arribar amb Windows Server 2012, on es va millorar la comunicació remota, es van ampliar els cmdlets disponibles i es van facilitar coses com la depuració, els treballs en segon pla o els punts de connexió restringits per millorar la seguretat.

Una de les idees clau daquest entorn és que els administradors poden crear comportaments similars a cmdlets sense programar en profunditat , recolzant-se en funcions avançades, mòduls reutilitzables i un sistema dajuda molt complet. Això significa que, en lloc de dependre d'eines gràfiques disperses, podeu construir un conjunt coherent de scripts i mòduls que automatitzen processos d'administració de servidors, xarxes, Active Directory, Azure o Microsoft 365.

Al terreny de l' automatització avançada també destaquen característiques com els treballs (jobs) per executar tasques de forma asíncrona, els workflows, l'administració basada en configuració amb PowerShell DSC i opcions de seguretat com JEA (Just Enough Administration) o PowerShell Web Access, que permeten controlar amb molt de detall què pot fer cada persona i des d'on.

Tot aquest ecosistema encaixa especialment bé amb WMI i CIM, ja que la informació d'administració exposada pel sistema operatiu (hardware, serveis, processos , configuració de xarxa, programari instal·lat, etc.) es converteix en un conjunt d'objectes que podeu consultar, filtrar i modificar mitjançant ordres de PowerShell pensats per automatitzar en massa.

WMI i CIM: conceptes clau i diferències pràctiques

Windows Management Instrumentation, més conegut com a WMI, és una tecnologia independent de PowerShell que porta anys a Windows i que exposa un repositori d'informació d'administració sobre el sistema operatiu, el maquinari i moltes aplicacions. No depèn de PowerShell, però el PowerShell l'aprofita a fons per automatitzar tasques.

El successor natural de WMI a l'ecosistema de PowerShell són els cmdlets Common Information Model (CIM) introduïts a partir de PowerShell 3.0. Aquests cmdlets s'agrupen al mòdul CimCmdlets i inclouen ordres com Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance o Remove-CimInstance, entre d'altres.

En versions antigues de Windows PowerShell, com la 5.1 de Windows 10 o Windows 11, encara trobes els cmdlets WMI clàssics (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Aquests cmdlets, però, estan en desús i ja no s'inclouen a PowerShell 6 i versions posteriors, per la qual cosa només són rellevants per mantenir scripts heretats o revisar codi antic.

Que algú parli de “consultar WMI amb cmdlets CIM” no és contradictori: els cmdlets CIM segueixen accedint a la informació de WMI , però ho fan usant protocols més moderns com WSMan i una API més coherent. A efectes pràctics, per a nous desenvolupaments hauries de centrar-te en CIM i considerar els cmdlets WMI únicament quan hagis de migrar o entendre scripts antics.

Històricament, molts administradors feien servir VBScript amb el llenguatge de consultes WQL per interrogar WMI, per exemple connectant-se a l'espai de noms root\CIMV2 i consultant classes com Win32_BIOS. Aquesta mateixa consulta WQL es pot reutilitzar avui dia amb Get-CimInstance passant el paràmetre -Query, cosa que facilita força la transició de scripts de VBScript a PowerShell sense necessitat de reescriure la lògica des de zero.

Ús pràctic de Get-CimInstance i consultes eficients

Per a la tasca diària, la manera més natural d'interrogar WMI amb PowerShell és utilitzar Get-CimInstance amb el paràmetre -ClassName , en lloc d'escriure consultes WQL completes. Per exemple, per obtenir la informació del BIOS pots utilitzar Get-CimInstance -ClassName Win32_BIOS i rebràs un objecte amb propietats com Manufacturer, Name, SerialNumber o SMBIOSBIOSVersion.

Com que tot a PowerShell són objectes, és molt senzill filtrar i seleccionar només el que necessites . Si us interessa únicament el número de sèrie, podeu canalitzar el resultat a Select-Object -Property SerialNumber, o bé utilitzar Select-Object -ExpandProperty SerialNumber perquè la sortida sigui una cadena simple i no un objecte amb una propietat. Una altra opció molt habitual és utilitzar la sintaxi de punt (Get-CimInstance…). SerialNumber per accedir directament al valor.

Convé tenir en compte que, per defecte, les consultes a WMI tornen més propietats de les que realment utilitzaràs . En un equip local normalment no passa res, però quan comences a consultar molts equips remots, això es tradueix en temps de processament addicional i trànsit innecessari per la xarxa. Aquí entra en joc el paràmetre -Property de Get-CimInstance, que permet limitar quines propietats es recuperen des de l'origen.

En indicar -Property SerialNumber, per exemple, reduïu la quantitat d'informació transferida, la qual cosa fa que la consulta sigui més ràpida i eficient, sobretot a escala . Aquesta mentalitat de demanar només el que necessito és clau quan dissenyes scripts d'inventari o auditoria que s'executen sobre dotzenes o centenars de màquines.

En resum, Get-CimInstance t'ofereix un equilibri molt potent entre simplicitat (una línia de comanda) i flexibilitat , ja sigui treballant amb classes concretes, consultes WQL heretades o propietats específiques que vulguis optimitzar per recuperar-les.

Consultes remotes amb CIM, sessions i protocols WSMan/DCOM

Quan surts de l'equip local i comences a consultar màquines remotes, entren en joc diversos factors: permisos, protocol de comunicació i rendiment . Encara que molta gent vegi PowerShell com una cosa “perillosa”, la veritat és que no t'atorga privilegis extra: tens exactament els mateixos permisos que amb la interfície gràfica o qualsevol altra eina, ni més ni menys.

Si intentes executar Get-CimInstance -ComputerName Servidor -ClassName Win32_BIOS sense tenir privilegis suficients sobre aquest equip, rebràs un error de “Access is denied” . No és que PowerShell falli, és simplement que l'usuari amb qui estàs executant la sessió no té dret a accedir a aquesta informació al WMI. Pots obrir una consola com a administrador de domini, és clar, però això suposa que qualsevol ordre s'executarà amb aquests privilegis, cosa que és un risc innecessari en molts entorns.

La recomanació és aplicar el principi de privilegis mínims i elevar només quan calgui . Als cmdlets que admeten el paràmetre -Credential, podeu especificar credencials alternatives únicament per a l'ordre en qüestió. Get-CimInstance, però, no accepta -Credential directament, i aquí és on entren les CimSessions com a solució elegant.

Una CimSession és una connexió persistent a un equip remot que podeu crear amb New-CimSession, passant el nom de l'equip i unes credencials (per exemple, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Aquesta sessió es desa en una variable, com ara $CimSession, i després es reutilitza amb Get-CimInstance mitjançant el paràmetre -CimSession en lloc de -ComputerName, cosa que et permet concentrar en una sola connexió múltiples consultes.

A més de la qüestió de credencials, Get-CimInstance utilitza per defecte el protocol WSMan (basat en WinRM) , la qual cosa implica que l'equip remot ha de tenir la pila WSMan en versió 3.0 o superior, típica de PowerShell 3.0 en endavant. Pots comprovar la versió de pila WSMan en un equip amb Test-WSMan -ComputerName EquipRemoto i verificar que el valor de “Stack” és 3.0 o més per poder aprofitar aquest mode de connexió.

Sessions CIM amb DCOM i compatibilitat amb sistemes antics

Els antics cmdlets WMI basats en Get-WmiObject es recolzen en el protocol DCOM, que segueix sent compatible amb versions velles de Windows . El problema és que, en sistemes més moderns, el tallafocs sol bloquejar DCOM per defecte i cal obrir ports específics si vols fer-lo servir tal qual, la qual cosa pot anar contra les polítiques de seguretat de l'organització.

Els cmdlets CIM ofereixen una via intermèdia molt potent: podeu crear opcions de sessió amb New-CimSessionOption -Protocol Dcom , desar-les en una variable (per exemple, $DCOM) i després combinar-les amb New-CimSession per generar una CimSession que utilitzi DCOM en lloc de WSMan. Això us permet connectar amb servidors molt antics, fins i tot anteriors a Windows Server 2000, on PowerShell ni tan sols està instal·lat.

Normalment resulta còmode desar les credencials d'administrador de domini o d'un compte amb privilegis elevats en una variable (per exemple, $Cred = Get-Credential ) per evitar haver-les d'escriure cada vegada. Després, amb alguna cosa com New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred pots aixecar una CimSession sobre DCOM cap a un servidor vell que no suporta WSMan però que sí que té WMI.

Des del punt de vista de qui escriu l'script, el gran avantatge és que la sortida de Get-CimInstance no canvia en funció del protocol : obtens els mateixos objectes i propietats, ja facis servir WSMan o DCOM. Això simplifica molt la lògica perquè pots encapsular la detecció del protocol adequat en una funció i deixar que la resta del codi treballi sempre amb CimSessions transparentment.

De fet, és força habitual crear funcions personalitzades que provin WSMan amb Test-WSMan i, si no està disponible, caiguin automàticament a DCOM usant New-CimSessionOption. Així pots estandarditzar la creació de CimSessions en entorns mixtos amb servidors moderns i heretats, sense replicar lògica de connexió a tots els teus scripts.

Gestió, llista i neteja de CimSessions

Quan comences a fer servir CimSessions de manera intensiva, és important portar cert control per no acumular connexions innecessàries. Amb Get-CimSession pots llistar totes les sessions obertes , veure a quin equip apunten i comprovar quin protocol utilitzen (WSMAN o DCOM), cosa molt útil per diagnosticar problemes de connectivitat o autenticació.

També podeu recuperar aquestes sessions existents en una variable, per exemple $CimSession = Get-CimSession , i utilitzar-les en una única ordre Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS per consultar diversos equips d'una tacada, combinant sessions WSMan i DCOM en una mateixa operació.

Un cop has acabat d'explotar aquesta informació, convé tancar les sessions per no deixar recursos oberts sense necessitat. Amb Get-CimSession | Remove-CimSession elimines de cop totes les CimSessions actives del perfil actual. Si ho prefereixes, també pots passar sessions concretes al cmdlet Remove-CimSession per tancar-ne només algunes.

Treballar d'aquesta manera et permet tenir cicles de connexió i desconnexió controlats , una cosa molt recomanable quan utilitzes scripts dins de tasques programades, runbooks d'automatització o pipelins d'integració contínua que poden deixar sessions penjant si no planifiques aquesta neteja explícitament.

PowerShell com a llenguatge d'automatització integral

Més enllà de WMI i CIM, PowerShell ha esdevingut un llenguatge d'automatització de propòsit general que va molt més enllà del típic script d'administració de Windows. Hi ha llibres i cursos complets dedicats a les seves capacitats avançades, cobrint des de la instal·lació a Linux i Windows fins al desenvolupament de mòduls distribuïbles via NuGet, passant per entorns de desenvolupament moderns com Visual Studio Code.

Un punt de partida habitual és entendre bé les funcions avançades de PowerShell , que us deixen definir paràmetres, validació, sortida estructurada i ajuda integrada gairebé al nivell d'un cmdlet nadiu. A partir d´aquí, l´organització del codi en mòduls facilita el treball col·laboratiu en equips d´operacions, ja que pots versionar i publicar aquests mòduls en repositoris interns o públics basats en NuGet.

També resulta clau el treball amb objectes personalitzats i classes , que obre la porta a models de dades molt més rics que els típics scripts lineals. Això permet encapsular lògica de negoci, reutilitzar estructures i dissenyar APIs internes per al teu propi equip d'administració, tot recolzat en el motor de PowerShell.

En l'àmbit de l'automatització avançada tenen un paper important els jobs en segon pla i els workflows , que permeten gestionar tasques asíncrones, llançar operacions llargues sense bloquejar la consola i orquestrar seqüències complexes a diversos equips. Aquestes capacitats encaixen com un guant amb les consultes massives a WMI/CIM i amb escenaris d'administració remota, on moltes vegades cal esperar que els sistemes executin canvis o tornin dades.

Una altra peça clau és PowerShell DSC (Desired State Configuration), que et deixa definir la configuració desitjada d'una infraestructura (rols, característiques, serveis, fitxers, ajustaments de seguretat…) i aplicar aquests estats de forma repetible. Combinat amb la informació que obtens via WMI/CIM, pots detectar desviacions, corregir-les de manera proactiva i mantenir entorns consistents amb menys esforç manual.

Gestió local, remota i al núvol amb PowerShell

Al terreny purament local, PowerShell aporta cmdlets per a l' administració d'Active Directory Domain Services , la configuració de xarxa i la gestió de servidors. A Windows 10 i versions posteriors, la integració és encara més profunda, cosa que us permet automatitzar des de la creació de llocs web fins a la gestió d'objectes d'Active Directory o la configuració d'adaptadors de xarxa.

Una peça menys coneguda però molt útil són els PSProviders i PSDrives , que et permeten tractar diferents magatzems (sistema de fitxers, registre, Active Directory, etc.) com si fossin unitats navegables. Gràcies a això pots, per exemple, crear grups d'Active Directory, claus de registre o estructures de carpetes en equips remots utilitzant la mateixa sintaxi que faries servir per moure't pel disc dur.

Pel que fa a l'administració remota, PowerShell integra un conjunt molt potent de funcions per connectar-te a un o més equips i executar ordres en nom teu . Pots utilitzar sessions PSSession persistents, tècniques avançades de remoting, escenaris un-a-molts (per gestionar diversos servidors de cop) o un-a-un per depurar casos concrets. Tot això, sens dubte, respectant l'arquitectura i el model de seguretat de l'accés remot.

El núvol també té un paper fonamental avui dia. Amb Azure PowerShell i Azure Cloud Shell podeu gestionar màquines virtuals, emmagatzematge i subscripcions directament des de la línia d'ordres. Instal·lar els mòduls d'Azure PowerShell i acostumar-te a treballar-hi és gairebé obligatori si administres entorns híbrids o completament allotjats a Azure.

D'altra banda, PowerShell també s'ha consolidat com a eina de referència per administrar Microsoft 365 (Exchange Online, SharePoint Online, Teams, usuaris i llicències). Des de la creació i gestió de comptes fins a l'administració de recursos de l'Exchange Online, passant per grups, llocs de SharePoint o equips de Microsoft Teams, tot es pot orquestrar amb scripts que redueixen dràsticament el treball manual al portal web.

Scripting, canalització i bones pràctiques de treball

Per treure tot el partit a l'automatització avançada amb WMI i CIM és essencial dominar el model de canalització (pipeline) de PowerShell . A diferència d'altres shells, aquí no vas passant text pla sinó objectes complets, cosa que et permet seleccionar, ordenar, mesurar, filtrar, enumerar i transformar informació amb molta precisió.

Aprendre a treballar amb la canalització implica utilitzar correctament els cmdlets de selecció i filtratge , conèixer com s'enumeren objectes complexos, i entendre com passar dades entre ordres i scripts sense perdre informació. Això es veu reforçat per l'ús ordenat de variables, arrays i taules hash, que actuen com a estructures de dades temporals sobre les quals construir lògica més avançada.

El graó següent és l' scripting com a tal: empaquetar ordres en scripts reutilitzables , amb control de flux (if, for, foreach), importació de dades des de fitxers CSV o altres formats, maneig de l'entrada de l'usuari, tractament d'errors i registre d'esdeveniments. Tot això et permet passar de comandes soltes a eines internes més robustes.

La resolució de problemes i el maneig derrors és especialment important en entorns dautomatització massiva amb WMI/CIM, ja que una caiguda de xarxa, un permís mal configurat o una classe inexistent poden trencar un procés si no el controles adequadament. Amb try/catch, accions d'error configurables i logging detallat pots anticipar-te i reaccionar millor davant d'aquests casos.

Finalment, tot allò relatiu a funcions i mòduls tanca el cercle : signatures scripts per garantir la seva integritat, empaquetes funcions en mòduls, distribueixes aquests mòduls en repositoris interns o públics i crees un ecosistema d'eines compartides dins de la teva organització. Així, qualsevol nou desenvolupament sobre WMI, CIM o remoting s'integra en un conjunt coherent i fàcil de mantenir.

Quan sumes tot això -WMI/CIM, sessions remotes, scripting, treballs asíncrons, DSC, Azure i Microsoft 365- obtens un entorn on l'automatització avançada amb PowerShell es converteix en l'eix central de l'administració. Amb una bona base de pràctiques recomanades, un ús intel·ligent de les CimSessions (tant amb WSMan com amb DCOM) i un disseny modular d'scripts, pots gestionar infraestructures heterogènies de forma coherent, segura i molt més eficient que només fent servir assistents gràfics o eines aïllades.