27Aug
WMI y su hermano más nuevo CIM se pueden usar para administrar las máquinas con Windows en su entorno.¿Pero sabes la diferencia entre ellos?Únete a nosotros mientras echamos un vistazo.
Asegúrese de leer los artículos anteriores de la serie:
- Aprenda a automatizar Windows con PowerShell
- Aprenda a usar los cmdlets en PowerShell
- Aprendizaje de cómo usar objetos en PowerShell
- Aprendizaje Formato, filtrado y comparación en PowerShell
- Aprenda a usar Remoting enPowerShell
Y estad atentos para el resto de la serie toda la semana.
Introducción
WMI significa Instrumental de administración de Windows. La palabra "Instrumentación" se refiere al hecho de que WMI le permite obtener información sobre el estado interno de su computadora, al igual que los instrumentos del tablero de su automóvil pueden recuperar y mostrar información sobre el estado de los componentes internos de su automóvil.
WMI consta de un repositorio que contiene clases que representan componentes que se podrían administrar dentro de su máquina. Con esto queremos decir simplemente porque WMI tiene una clase Win32_Battery no significa que su máquina contiene una batería. Estas clases pueden consultarse localmente o incluso a través de una red utilizando un lenguaje de consulta muy similar al SQL llamado WQL.Sin embargo, se sabe que WMI es muy poco confiable, principalmente debido a que está basado en RPC( Remote Procedure Calls), que hacen algunas cosas locas con los puertos en los que deciden comunicarse.
Comenzando con Windows 8 y Server 2012, WMI se está eliminando progresivamente a favor del Modelo de información común o CIM, para abreviar. La única diferencia entre WMI y CIM son los protocolos de transporte que usan. Mientras que WMI realiza consultas utilizando Llamadas de procedimiento remoto, CIM usa HTTP, lo que parece marcar una gran diferencia. En el back-end todavía están hablando con el mismo depósito de información.
Uso de WMI
La forma más rápida y sencilla de explorar la información disponible para usted a través de WMI es obtener una copia de cualquier buscador de objetos WMI.Nos gusta este. Una vez descargado, enciéndalo y tendrá una interfaz gráfica para navegar por las clases de WMI.
Si desea averiguar algo sobre la configuración del disco de una computadora, presione la combinación de teclas Ctrl + F para que aparezca un cuadro de búsqueda, luego escriba "logicaldisk" y presione enter.
Inmediatamente esto lo llevará a la clase Win32_LogicalDisk.
En la mitad inferior de la aplicación, puede ver que tenemos dos instancias de la clase.
Una vez que tenemos la clase que estamos buscando, consultarla desde PowerShell es sencillo.
Get-WmiObject -Query "SELECT * FROM Win32_LogicalDisk"
No he visto esa sintaxis por un tiempo, y la gente en estos días prefiere usar la nueva sintaxis parametrizada.
Get-WmiObject -Class Win32_LogicalDisk
Si desea obtener la información de otra computadora en su red, simplemente puede usar el parámetro ComputerName.
Get-WmiObject -Class Win32_LogicalDisk -ComputerName Viper -Credential viper \ administrator
Uso de CIM
Teniendo en cuenta que CIM solo está disponible en Windows 8 y Server 2012, este es definitivamente el camino a seguir.
Get-CimInstance -ClassName Win32_LogicalDisk
También se completó la tabulación para el parámetro -ClassName cuando se usa Get-CimInstance, lo que muestra que en el futuro es donde se centrarán los esfuerzos de Microsoft.
De hecho, WMI fue desarrollado por un equipo completamente separado dentro de Microsoft, pero luego fue asumido por las personas a cargo de PowerShell. Ellos fueron los que notaron que va a ser muy difícil limpiar el desastre que dejó WMI.En un intento de remediar la situación, intentan hacer que WMI y CIM estén más disponibles escribiendo cmdlets de envoltura que usan WMI y CIM debajo del capó.La única forma de comprobar si un cmdlet es un contenedor es mirando la documentación. Por ejemplo, el cmdlet Get-Hotfix es un contenedor para la clase Win32_QuickFixEngineering, como se ve en la documentación.
Eso significa que puede obtener las revisiones en máquinas remotas utilizando el cmdlet Get-HotFix en lugar de una consulta WMI.
Get-HotFix -ComputerName localhost
Así que ahí lo tiene. Solo recuerda que si hay un cmdlet dedicado, siempre querrás usarlo, seguido de CIM si no existiera un cmdlet. Finalmente, si todo lo demás falla, o si tiene máquinas más antiguas en su entorno, querrá usar WMI.Eso es todo lo que tengo para este momento. Nos vemos mañana para más diversión de PowerShell.