PowerShell WMI y CIM para una automatización avanzada en sistemas Windows

Informatec Digital » Recursos » PowerShell WMI y CIM para una automatización avanzada en sistemas Windows

Si trabajas administrando sistemas Windows, tarde o temprano acabas chocando con PowerShell, WMI y la automatización avanzada. No es solo cuestión de saber lanzar cuatro comandos: cuando gestionas docenas o cientos de servidores, necesitas un enfoque serio, estructurado y seguro para obtener información, aplicar cambios y repetir tareas sin volverte loco… ni romper nada.

En las próximas líneas vamos a recorrer, con calma pero en profundidad, cómo aprovechar WMI, CIM y la comunicación remota de PowerShell para automatizar desde consultas sencillas hasta escenarios de infraestructura complejos. Además, veremos cómo encaja todo esto con módulos, trabajos en segundo plano, Azure, Microsoft 365 y algunas funciones avanzadas que marcan la diferencia en el día a día de un administrador de sistemas.

Mejoras de PowerShell y visión general de la automatización avanzada

Windows PowerShell ha evolucionado muchísimo desde sus primeras versiones, y una gran parte de esa evolución llegó con Windows Server 2012, donde se mejoró la comunicación remota, se ampliaron los cmdlets disponibles y se facilitaron cosas como la depuración, los trabajos en segundo plano o los puntos de conexión restringidos para mejorar la seguridad.

Una de las ideas clave de este entorno es que los administradores pueden crear comportamientos similares a cmdlets sin programar en profundidad, apoyándose en funciones avanzadas, módulos reutilizables y un sistema de ayuda muy completo. Eso significa que, en lugar de depender de herramientas gráficas dispersas, puedes construir un conjunto coherente de scripts y módulos que automatizan procesos de administración de servidores, redes, Active Directory, Azure o Microsoft 365.

En el terreno de la automatización avanzada también destacan características como los trabajos (jobs) para ejecutar tareas de forma asíncrona, los workflows, la administración basada en configuración con PowerShell DSC y opciones de seguridad como JEA (Just Enough Administration) o PowerShell Web Access, que permiten controlar con mucho detalle qué puede hacer cada persona y desde dónde.

Todo este ecosistema encaja especialmente bien con WMI y CIM, ya que la información de administración expuesta por el sistema operativo (hardware, servicios, procesos, configuración de red, software instalado, etc.) se convierte en un conjunto de objetos que puedes consultar, filtrar y modificar mediante comandos de PowerShell pensados para automatizar en masa.

WMI y CIM: conceptos clave y diferencias prácticas

Windows Management Instrumentation, más conocido como WMI, es una tecnología independiente de PowerShell que lleva años en Windows y que expone un repositorio de información de administración sobre el sistema operativo, el hardware y muchas aplicaciones. No depende de PowerShell, pero PowerShell la aprovecha a fondo para automatizar tareas.

El sucesor natural de WMI en el ecosistema de PowerShell son los cmdlets CIM (Common Information Model), introducidos a partir de PowerShell 3.0. Estos cmdlets se agrupan en el módulo CimCmdlets e incluyen comandos como Get-CimInstance, Get-CimClass, New-CimInstance, Invoke-CimMethod, Register-CimIndicationEvent, Set-CimInstance o Remove-CimInstance, entre otros.

En versiones antiguas de Windows PowerShell, como la 5.1 de Windows 10 o Windows 11, todavía encuentras los cmdlets WMI clásicos (Get-WmiObject, Invoke-WmiMethod, Register-WmiEvent, Remove-WmiObject, Set-WmiInstance). Estos cmdlets, sin embargo, están en desuso y ya no se incluyen en PowerShell 6 y versiones posteriores, por lo que solo son relevantes para mantener scripts heredados o revisar código antiguo.

Que alguien hable de “consultar WMI con cmdlets CIM” no es contradictorio: los cmdlets CIM siguen accediendo a la información de WMI, pero lo hacen usando protocolos más modernos como WSMan y una API más coherente. A efectos prácticos, para nuevos desarrollos deberías centrarte en CIM y considerar los cmdlets WMI únicamente cuando tengas que migrar o entender scripts antiguos.

Históricamente, muchos administradores usaban VBScript con el lenguaje de consultas WQL para interrogar WMI, por ejemplo conectándose al espacio de nombres root\CIMV2 y consultando clases como Win32_BIOS. Esa misma consulta WQL se puede reutilizar hoy en día con Get-CimInstance pasando el parámetro -Query, lo que facilita bastante la transición de scripts de VBScript a PowerShell sin necesidad de reescribir la lógica desde cero.

Uso práctico de Get-CimInstance y consultas eficientes

Para el trabajo diario, la forma más natural de interrogar WMI con PowerShell es utilizar Get-CimInstance con el parámetro -ClassName, en lugar de escribir consultas WQL completas. Por ejemplo, para obtener la información del BIOS puedes usar Get-CimInstance -ClassName Win32_BIOS y recibirás un objeto con propiedades como Manufacturer, Name, SerialNumber o SMBIOSBIOSVersion.

Como todo en PowerShell son objetos, es muy sencillo filtrar y seleccionar solo lo que necesitas. Si te interesa únicamente el número de serie, puedes canalizar el resultado a Select-Object -Property SerialNumber, o bien usar Select-Object -ExpandProperty SerialNumber para que la salida sea una cadena simple y no un objeto con una propiedad. Otra opción muy habitual es utilizar la sintaxis de punto (Get-CimInstance …).SerialNumber para acceder directamente al valor.

Conviene tener en cuenta que, por defecto, las consultas a WMI devuelven más propiedades de las que realmente vas a usar. En un equipo local normalmente no pasa nada, pero cuando empiezas a consultar muchos equipos remotos eso se traduce en tiempo de procesamiento adicional y tráfico innecesario por la red. Aquí entra en juego el parámetro -Property de Get-CimInstance, que te permite limitar qué propiedades se recuperan desde el origen.

Al indicar -Property SerialNumber, por ejemplo, reduces la cantidad de información transferida, lo que hace que la consulta sea más rápida y eficiente, sobre todo a escala. Esta mentalidad de “pedir solo lo que necesito” es clave cuando diseñas scripts de inventario o auditoría que se ejecutan sobre docenas o cientos de máquinas.

En resumen, Get-CimInstance te ofrece un equilibrio muy potente entre simplicidad (una línea de comando) y flexibilidad, ya sea trabajando con clases concretas, consultas WQL heredadas o propiedades específicas que quieras optimizar para su recuperación.

Consultas remotas con CIM, sesiones y protocolos WSMan/DCOM

Cuando sales del equipo local y empiezas a consultar máquinas remotas, entran en juego varios factores: permisos, protocolo de comunicación y rendimiento. Aunque mucha gente vea PowerShell como algo “peligroso”, lo cierto es que no te otorga privilegios extra: tienes exactamente los mismos permisos que con la interfaz gráfica o cualquier otra herramienta, ni más ni menos.

Si intentas ejecutar Get-CimInstance -ComputerName Servidor -ClassName Win32_BIOS sin tener privilegios suficientes sobre ese equipo, recibirás un error de “Access is denied”. No es que PowerShell falle, es simplemente que el usuario con el que estás ejecutando la sesión no tiene derecho a acceder a esa información en WMI. Puedes abrir una consola como administrador de dominio, claro, pero eso supone que cualquier comando se ejecutará con esos privilegios, lo cual es un riesgo innecesario en muchos entornos.

La recomendación es aplicar el principio de privilegios mínimos y elevar solo cuando haga falta. En los cmdlets que admiten el parámetro -Credential, puedes especificar credenciales alternativas únicamente para el comando en cuestión. Get-CimInstance, sin embargo, no acepta -Credential directamente, y aquí es donde entran las CimSessions como solución elegante.

Una CimSession es una conexión persistente a un equipo remoto que puedes crear con New-CimSession, pasando el nombre del equipo y unas credenciales (por ejemplo, New-CimSession -ComputerName dc01 -Credential (Get-Credential)). Esa sesión se guarda en una variable, como $CimSession, y luego se reutiliza con Get-CimInstance mediante el parámetro -CimSession en lugar de -ComputerName, lo que te permite concentrar en una sola conexión múltiples consultas.

Además de la cuestión de credenciales, Get-CimInstance utiliza por defecto el protocolo WSMan (basado en WinRM), lo que implica que el equipo remoto debe tener la pila WSMan en versión 3.0 o superior, típica de PowerShell 3.0 en adelante. Puedes comprobar la versión de pila WSMan en un equipo con Test-WSMan -ComputerName EquipoRemoto y verificar que el valor de “Stack” es 3.0 o mayor para poder aprovechar este modo de conexión.

Sesiones CIM con DCOM y compatibilidad con sistemas antiguos

Los antiguos cmdlets WMI basados en Get-WmiObject se apoyan en el protocolo DCOM, que sigue siendo compatible con versiones viejas de Windows. El problema es que, en sistemas más modernos, el firewall suele bloquear DCOM por defecto y hay que abrir puertos específicos si quieres usarlo tal cual, lo cual puede ir contra las políticas de seguridad de la organización.

Los cmdlets CIM ofrecen una vía intermedia muy potente: puedes crear opciones de sesión con New-CimSessionOption -Protocol Dcom, guardarlas en una variable (por ejemplo, $DCOM) y luego combinarlas con New-CimSession para generar una CimSession que utilice DCOM en lugar de WSMan. Esto te permite conectar con servidores muy antiguos, incluso anteriores a Windows Server 2000, donde PowerShell ni siquiera está instalado.

Normalmente resulta cómodo guardar las credenciales de administrador de dominio o de una cuenta con privilegios elevados en una variable (por ejemplo $Cred = Get-Credential) para evitar tener que escribirlas cada vez. Después, con algo como New-CimSession -ComputerName sql03 -SessionOption $DCOM -Credential $Cred puedes levantar una CimSession sobre DCOM hacia un servidor viejito que no soporta WSMan pero que sí tiene WMI.

Desde el punto de vista de quien escribe el script, la gran ventaja es que la salida de Get-CimInstance no cambia en función del protocolo: obtienes los mismos objetos y propiedades, ya uses WSMan o DCOM. Eso simplifica mucho la lógica porque puedes encapsular la detección del protocolo adecuado en una función y dejar que el resto del código trabaje siempre con CimSessions transparentamente.

De hecho, es bastante habitual crear funciones personalizadas que prueben WSMan con Test-WSMan y, si no está disponible, caigan automáticamente en DCOM usando New-CimSessionOption. Así puedes estandarizar la creación de CimSessions en entornos mixtos con servidores modernos y heredados, sin replicar lógica de conexión en todos tus scripts.

Gestión, listado y limpieza de CimSessions

Cuando empiezas a usar CimSessions de manera intensiva, es importante llevar cierto control para no acumular conexiones innecesarias. Con Get-CimSession puedes listar todas las sesiones abiertas, ver a qué equipo apuntan y comprobar qué protocolo utilizan (WSMAN o DCOM), algo muy útil para diagnosticar problemas de conectividad o autenticación.

También puedes recuperar esas sesiones existentes en una variable, por ejemplo $CimSession = Get-CimSession, y usarlas en un único comando Get-CimInstance -CimSession $CimSession -ClassName Win32_BIOS para consultar varios equipos de una tacada, combinando sesiones WSMan y DCOM en una misma operación.

Una vez que has terminado de explotar esa información, conviene cerrar las sesiones para no dejar recursos abiertos sin necesidad. Con Get-CimSession | Remove-CimSession eliminas de golpe todas las CimSessions activas del perfil actual. Si lo prefieres, también puedes pasar sesiones concretas al cmdlet Remove-CimSession para cerrar solo algunas.

Trabajar de esta manera te permite tener ciclos de conexión y desconexión controlados, algo muy recomendable cuando usas scripts dentro de tareas programadas, runbooks de automatización o pipelines de integración continua que pueden dejar sesiones colgando si no planificas esa limpieza explícitamente.

PowerShell como lenguaje de automatización integral

Más allá de WMI y CIM, PowerShell se ha convertido en un lenguaje de automatización de propósito general que va mucho más allá del típico script de administración de Windows. Existen libros y cursos completos dedicados a sus capacidades avanzadas, cubriendo desde la instalación en Linux y Windows hasta el desarrollo de módulos distribuibles vía NuGet, pasando por entornos de desarrollo modernos como Visual Studio Code.

Un punto de partida habitual es entender bien las funciones avanzadas de PowerShell, que te dejan definir parámetros, validación, salida estructurada y ayuda integrada casi al nivel de un cmdlet nativo. A partir de ahí, la organización del código en módulos facilita el trabajo colaborativo en equipos de operaciones, ya que puedes versionar y publicar esos módulos en repositorios internos o públicos basados en NuGet.

También resulta clave el trabajo con objetos personalizados y clases, que abre la puerta a modelos de datos mucho más ricos que los típicos scripts lineales. Esto te permite encapsular lógica de negocio, reutilizar estructuras y diseñar APIs internas para tu propio equipo de administración, todo ello apoyado en el motor de PowerShell.

En el ámbito de la automatización avanzada tienen un papel importante los jobs en segundo plano y los workflows, que permiten gestionar tareas asíncronas, lanzar operaciones largas sin bloquear la consola y orquestar secuencias complejas en varios equipos. Estas capacidades encajan como un guante con las consultas masivas a WMI/CIM y con escenarios de administración remota, donde muchas veces hay que esperar a que los sistemas ejecuten cambios o devuelvan datos.

Otra pieza clave es PowerShell DSC (Desired State Configuration), que te deja definir la configuración deseada de una infraestructura (roles, características, servicios, archivos, ajustes de seguridad…) y aplicar esos estados de forma repetible. Combinado con la información que obtienes vía WMI/CIM, puedes detectar desviaciones, corregirlas de forma proactiva y mantener entornos consistentes con menos esfuerzo manual.

Gestión local, remota y en la nube con PowerShell

En el terreno puramente local, PowerShell aporta cmdlets para la administración de Active Directory Domain Services, la configuración de red y la gestión de servidores. En Windows 10 y versiones posteriores, la integración es todavía más profunda, lo que te permite automatizar desde la creación de sitios web hasta la gestión de objetos de Active Directory o la configuración de adaptadores de red.

Una pieza menos conocida pero muy útil son los PSProviders y PSDrives, que te permiten tratar distintos almacenes (sistema de archivos, registro, Active Directory, etc.) como si fueran unidades navegables. Gracias a ello puedes, por ejemplo, crear grupos de Active Directory, claves de registro o estructuras de carpetas en equipos remotos utilizando la misma sintaxis que usarías para moverte por el disco duro.

En cuanto a la administración remota, PowerShell integra un conjunto muy potente de funciones para conectarte a uno o varios equipos y ejecutar comandos en tu nombre. Puedes usar sesiones PSSession persistentes, técnicas avanzadas de remoting, escenarios uno-a-muchos (para gestionar varios servidores de golpe) o uno-a-uno para depurar casos concretos. Todo ello, por supuesto, respetando la arquitectura y el modelo de seguridad del acceso remoto.

La nube también tiene un papel fundamental hoy en día. Con Azure PowerShell y Azure Cloud Shell puedes gestionar máquinas virtuales, almacenamiento y suscripciones directamente desde la línea de comandos. Instalar los módulos de Azure PowerShell y acostumbrarte a trabajar con ellos es casi obligatorio si administras entornos híbridos o completamente alojados en Azure.

Por otro lado, PowerShell también se ha consolidado como herramienta de referencia para administrar Microsoft 365 (Exchange Online, SharePoint Online, Teams, usuarios y licencias). Desde la creación y gestión de cuentas hasta la administración de recursos de Exchange Online, pasando por grupos, sitios de SharePoint o equipos de Microsoft Teams, todo se puede orquestar con scripts que reducen drásticamente el trabajo manual en el portal web.

Scripting, canalización y buenas prácticas de trabajo

Para sacar todo el partido a la automatización avanzada con WMI y CIM es esencial dominar el modelo de canalización (pipeline) de PowerShell. A diferencia de otros shells, aquí no vas pasando texto plano sino objetos completos, lo que te permite seleccionar, ordenar, medir, filtrar, enumerar y transformar información con mucha precisión.

Aprender a trabajar con la canalización implica usar correctamente los cmdlets de selección y filtrado, conocer cómo se enumeran objetos complejos, y entender cómo pasar datos entre comandos y scripts sin perder información. Esto se ve reforzado por el uso ordenado de variables, arrays y tablas hash, que actúan como estructuras de datos temporales sobre las que construir lógica más avanzada.

El siguiente escalón es el scripting como tal: empaquetar comandos en scripts reutilizables, con control de flujo (if, for, foreach), importación de datos desde ficheros CSV u otros formatos, manejo de la entrada del usuario, tratamiento de errores y registro de eventos. Todo esto te permite pasar de comandos sueltos a herramientas internas más robustas.

La resolución de problemas y el manejo de errores es especialmente importante en entornos de automatización masiva con WMI/CIM, ya que una caída de red, un permiso mal configurado o una clase inexistente pueden romper un proceso si no lo controlas adecuadamente. Con try/catch, acciones de error configurables y logging detallado puedes anticiparte y reaccionar mejor ante estos casos.

Por último, todo lo relativo a funciones y módulos cierra el círculo: firmas scripts para garantizar su integridad, empaquetas funciones en módulos, distribuyes esos módulos en repositorios internos o públicos y creas un ecosistema de herramientas compartidas dentro de tu organización. Así, cualquier nuevo desarrollo sobre WMI, CIM o remoting se integra en un conjunto coherente y fácil de mantener.

Cuando sumas todo lo anterior —WMI/CIM, sesiones remotas, scripting, trabajos asíncronos, DSC, Azure y Microsoft 365— obtienes un entorno donde la automatización avanzada con PowerShell se convierte en el eje central de la administración. Con una buena base de prácticas recomendadas, un uso inteligente de las CimSessions (tanto con WSMan como con DCOM) y un diseño modular de scripts, puedes gestionar infraestructuras heterogéneas de forma coherente, segura y mucho más eficiente que tirando solo de asistentes gráficos o herramientas aisladas.