Utilizando CIM y WMI con PowerShell

Si bien los cmdlets incorporados en PowerShell nos ofrecen la posibilidad de interactuar con multitud de aspectos de una máquina, hay veces que podemos necesitar consultar o modificar un determinado atributo y nos encontramos con que ningún cmdlet nos lo permite. En la entrada de hoy vamos a ver cómo utilizar CIM y WMI con PowerShell para intentar combatir estas situaciones.

¿Qué son CIM y WMI?

CIM (Common Information Model) es un estándar abierto creado por la organización DMTF orientado a proveer una definición común para el intercambio de información entre sistemas, redes, aplicaciones y servicios.

WMI (Windows Management Instrumentation) es la implementación de Microsoft de CIM, con la que se proveen métodos para consultar y modificar la configuración de una máquina Windows. Si bien el primer sistema operativo de Microsoft que traía WMI instalado fue Windows 2000 la simplificación de su uso vino con PowerShell donde desde la versión 1 se dispuso del primer cmdlet con el que consultar los métodos de una forma muy sencilla.

¿Cmdlets CIM o WMI?

Si bien no vamos a entrar al detalle existen dos juegos de cmdlets relacionados con CIM/WMI:

Los cmdlets Wmi fueron los que aparecieron primero* pero a partir de Windows PowerShell 3 fueron sustituidos por los CimCmdlets. Si bien estos cmdlets aún son accesibles se espera que tarde o temprano desaparezcan de PowerShell por lo que es mejor usar los “nuevos” **CimCmdlets**. Algunas de las mejoras incorporadas por los CimCmdlets son las siguientes:

• Utilizan WinRM (WS-Man) para la comunicación con máquinas remotas, un protocolo mucho más moderno y “Firewall friendly” que DCOM, utilizado por Wmi*.
• Permite el uso de sesiones mediante New-CimSession con el que poder invocar comandos remotos reutilizando dicha conexión.
• Mejoran la gestión de la información devuelta.

Un muy buen post sobre las diferencias entre ellos es este.

Cómo listar todas las clases disponibles de WMI con PowerShell

Una vez sabemos lo que es WMI/CIM y hemos visto las diferencias entre los cmdlets CIM* y WMI* podemos pasar de una vez a la acción (sí, en este post me he alargado bastante con los preliminares). Para listar todas las clases de WMI/CIM que tenemos disponibles podemos valernos del cmdlet Get-CimClass:

Como podemos ver por la salida del segundo comando existen en mi máquina 1202 clases disponibles con las que jugar.

Si vemos el detalle, por ejemplo, de Win32_OperatingSystem podemos ver que esta clase dispone de métodos que podemos invocar y propiedades que podemos consultar y en algunos casos modificar:

Consultando clases WMI con PowerShell

Siguiendo con el ejemplo de Win32_OperatingSystem vamos a instanciar la clase para ver qué información nos devuelve. Para instanciar una clase nos valdremos de Get-CimInstance:

(La salida del comando saca mucha más información, pero para la entrada con esto nos vale)

Como podemos ver en la captura el comando nos muestra mucha información que con cmdlets corrientes podría ser difícil o imposible de sacar, como la fecha de instalación del sistema operativo, y no solo eso, sino que además lo hace a gran velocidad.

Modificar propiedades WMI con PowerShell

Más allá de consultar las propiedades WMI de una máquina podemos, siempre y cuando dicha propiedad lo permita, modificar su valor utilizando el cmdlet Set-CimInstance.

Antes que nada buscaremos una propiedad que podamos escribir. Para ello volveremos a recurrir a Get-CimClass y veremos el detalle de las propiedades de Win32_UserAccount filtrando por las que no tienen el flag ReadOnly:

Como vemos disponemos de, por ejemplo, la propiedad FullName que utilizaremos para ver cómo realizar modificaciones con Set-CimInstance (deberemos abrir PowerShell como administrador):

Conclusión

Aprender a interactuar con WMI/CIM desde PowerShell** puede ayudarnos a multiplicar sustancialmente la cantidad de cosas que podemos realizar con nuestros sistemas operativos**, por lo que espero que os haya sido de utilidad esta entrada para ampliar aún más vuestras posibilidades con PowerShell.

En futuras entradas intentaremos sacar partido de esta interfaz y ahondaremos más en sus posibilidades.