Windows PowerShellLa conexión WMI

Don Jones

Una de las tecnologías con la que en gran medida pude contar en el mundo de VBScript fue el instrumental de administración de Windows, o WMI. Curiosamente, Windows PowerShell tiene fuertes conexiones con WMI, y no sólo en un sentido técnico. Jeffrey Snover, quién diseño Windows PowerShell, también fue un integrante clave en la creación de

Wmic.exe, una herramienta de línea de comandos de la época de Windows Server® 2003 usada para trabajar con WMI. En muchos aspectos, Wmic.exe anunció Windows PowerShell™ ya que funcionó en una forma algo similar. (Para obtener más información sobre WMIC, consulte el artículo de John Kelbley en el número de septiembre de 2006 de TechNet Magazine, disponible en línea en microsoft.com/technet/technetmag/issues/2006/09/WMIData).

Windows PowerShell es compatible con WMI que se entrega de la misma manera, coherente y basada en objetos que obtiene con el resto de las capacidades del shell. Esto hace que WMI sea infinitamente más fácil de aprender y usar, especialmente en situaciones ad hoc, que tecnologías anteriores, como VBScript.

Conceptos básicos de WMI

Si lee libros y artículos sobre secuencias de comandos, es muy difícil no ver a WMI mencionado. Sin embargo, es fácil quedar atascado en el uso de WMI y olvidar cómo está construido por dentro; y saber cómo está construido es especialmente importante para entender cómo funciona en Windows PowerShell.

WMI es principalmente un sistema de clases organizadas que representan la información de administración del sistema operativo Windows® y de otros productos de hardware y software basados en Windows. Una clase en realidad no es nada más que una descripción abstracta de las propiedades y capacidades que poseen algunos componentes de software o hardware determinados. Por ejemplo, es posible que la clase de un disco lógico describa un dispositivo que tiene un número de serie, una capacidad fija de almacenamiento, una cantidad de espacio disponible, etcétera. Mientras tanto, es posible que una clase que describe un servicio de Windows especifique que el servicio tiene un nombre, que se puede iniciar y detener, su estado actual, etc.

En WMI, las clases representan todas las cosas que esa WMI puede administrar. Si WMI no tiene una clase para algo, no puede administrar ese componente. Microsoft documenta las clases centrales de Windows WMI en msdn2.microsoft.com/aa394554.aspx; otros productos, como por ejemplo, Internet Information Services y SQL Server™, documentan sus clases WMI por separado.

Debido a que existen tantas clases, WMI las organiza en una jerarquía de espacios de nombres. Por ejemplo, el espacio de nombres que contiene las clases centrales del sistema operativo Windows se llama root\cimv2, mientras que Microsoft IIS 6.0 almacena sus clases en root\Microsoft­IISv2. Afortunadamente, el espacio nombres de root\cimv2 es también el espacio de nombres predeterminado de WMI, una configuración compartida por Windows PowerShell, lo que facilita el trabajo con estas clases centrales.

Una "instancia" es una aparición real de una clase. Si, por ejemplo, el equipo tiene dos discos lógicos, tendrá dos instancias de la clase Win32_LogicalDisk. Si en el equipo se ejecutan 50 servicios, WMI verá 50 instancias de la clase Win32_Service. El trabajo con WMI es esencialmente una cuestión de pedir a WMI que ofrezca una o más instancias y, a continuación, examinar sus propiedades en búsqueda de la información de administración que se necesita o para ejecutar los métodos de esas instancias para hacer cambios de administración, como por ejemplo iniciar o detener un servicio.

WMI usa una arquitectura cliente-servidor. Cada versión de Windows desde Windows 2000 incluyó WMI integrado (las versiones posteriores han ampliado el número de clases disponibles), lo que significa que se dispone con facilidad de software cliente y software servidor de WMI. Al usar WMI, envía en realidad una solicitud al servicio WMI que se ejecuta en cualquier equipo deseado. Ese servicio WMI recupera las instancias WMI que especifica y las devuelve para que pueda trabajar con ellas. Es allí donde Windows PowerShell entra en escena, simplifica el proceso de solicitar instancias, recuperarlas y trabajar con ellas.

Obtención de un objeto WMI

Generalmente, a las instancias de una clase WMI se les denomina objetos, de modo que tiene sentido que la manera de recuperar esas instancias en Windows PowerShell sea el cmdlet Get-WMIObject. Este cmdlet tiene un alias más cómodo, gwmi, que usaré en la mayor parte de mis ejemplos. En su forma más simple, especifica sólo el nombre de la clase WMI que desea recuperar y, a continuación, se relaja y analiza los resultados (consulte la figura 1). Cuando ejecuté gwmi win32_service, Windows PowerShell se conectó al servicio WMI en el equipo local (debido a que no especifiqué otro equipo) y se conectó al espacio de nombres root\cimv2 (porque no especifiqué un espacio de nombres diferente). Windows PowerShell recuperó todas las instancias de la clase especificada y, como no le indiqué que hiciera algo más con ellas, las convirtió en una representación textual. En otras palabras, Windows PowerShell tomó esos objetos y produjo un texto para que yo, como mero ser humano, los pudiera leer.

Figura 1** Al ejecutar gwmi win32_service, Windows PowerShell devuelve todas las instancias de la clase especificada en un formato legible de texto **

Específicamente, Windows PowerShell convierte objetos WMI en texto cuando lee y muestra los nombres y valores de las propiedades de la clase seleccionada. Para la clase Win32_Service, seleccionó un conjunto de seis propiedades.

En realidad, Windows PowerShell convierte cualquier objeto a texto de este modo. La mayoría de las veces, las propiedades que elige mostrar se definen en un conjunto de archivos .format.ps1xml que se encuentran en la carpeta de instalación de Windows PowerShell. Estos archivos de definición de formato llevan la firma digital de Microsoft. Se recomienda no cambiar estos archivos, aunque puede proporcionar sus propios archivos de formato. (Este es un tema que analizaré con más detalle en una futura columna).

El cmdlet gwmi puede ayudarle a explorar el equipo para averiguar qué clases están disponibles. Por ejemplo, al ejecutar gwmi –namespace "root\cimv2" –list, se puede obtener una lista completa de clases en ese espacio de nombres. No obstante, recuerde que las clases en el equipo sólo son importantes cuando se administra el equipo; si administra un equipo remoto, querrá conocer las clases disponibles en ese sistema. Para ello, puede usar el parámetro -computer de gwmi para conectarse a un equipo remoto. Por ejemplo, gwmi –namespace "root\cimv2" –list –computer ServerA incluirá una lista de todas las clases en el espacio de nombres root\cimv2 del equipo remoto denominado ServerA.

WMI remoto

En la versión 1.0 de Windows PowerShell, gwmi es prácticamente el único cmdlet que admite directamente la administración remota. Esto se debe principalmente al hecho de que ese control remoto está integrado en la arquitectura WMI subyacente. Y como Windows PowerShell usa la arquitectura existente, está sujeto a las características de seguridad de esa arquitectura. A continuación se muestra un ejemplo:

C:\> gwmi -namespace “root\cimv2” -computer
mediaserver -list
Get-WmiObject : Access is denied. (Exception
from HRESULT: 0x80070005 (E_ACCESSDENIED))
At line:1 char:5
+ gwmi <<<< -namespace “root\cimv2” -computer
mediaserver -list
PS C:\>

En esta instancia, intento conectarme a un equipo remoto llamado Media-Server para el que no tengo permiso de acceso. Como administrador, debería tener permiso para trabajar con el servicio WMI de este equipo, pero es probable que mis credenciales de la estación de trabajo local no sean suficientes. Por ejemplo, es posible que haya iniciado sesión en un dominio diferente que no sea de confianza o iniciado sesión con una cuenta con menos privilegios. Afortunadamente, gwmi es compatible con el parámetro -credential que permite especificar un conjunto alternativo de credenciales de usuario para la conexión de WMI. A continuación, puede ver un ejemplo muy sencillo:

gwmi win32_service –credential mydomain\administrator –computer mediaserver

Mi credencial, más concretamente, mi nombre de usuario, se proporciona en el formato Dominio\Nombre de usuario.

Tenga en cuenta que no existe ningún lugar donde pueda escribir una contraseña, Windows PowerShell me la solicitará. En forma intencional, Windows PowerShell no ofrece una manera de escribir una contraseña en la línea de comandos porque de esa manera permitiría codificar contraseñas en archivos de secuencias de comandos, lo cual es un riesgo de seguridad absoluto. Sin embargo, existe otra manera de trabajar con el parámetro -credential; crear con antelación una especie de objeto de credencial, llamado PSCredential. La clave es el cmdlet Get-Credential:

$cred = get-credential mydomain\administrator

Cuando lo ejecuto, todavía me solicita la contraseña de confirmación. Sin embargo, esta vez el objeto de credencial que se crea se almacena en la variable $cred. Si miro el contenido de $cred, podré ver el nombre pero no la contraseña:

PS C:\> $cred

UserName
--------
mydomain\adminstrator

De esta manera puedo volver a usar ese objeto de credencial todas las veces que desee:

gwmi win32_service –credential $cred –computer mediaserver

Esto simplifica las conexiones repetidas de WMI a un equipo remoto al predefinir un objeto de credencial que se puede volver a usar. Cabe destacar, no obstante, que actualmente el cmdlet Get-WMIObject no es compatible con la especificación de niveles de autenticación (también conocidos como suplantación) de la misma manera que VBScript la admite. Consulte msdn2.microsoft.com/aa389290.aspx para obtener información adicional.

Detección automática

Para mí, uno de los aspectos favoritos de Windows PowerShell es que no baja el nivel de las cosas. Le mostré cómo Windows PowerShell seleccionó sólo un conjunto de propiedades de la clase Win32_Service que consulté. No obstante, el shell todavía tiene acceso a todas las propiedades, e incluso puede indicarle cuáles son. Para ello, simplemente canalice el objeto (o los objetos) al cmdlet Get-Member (o a su alias, gm), tal como se muestra en la figura 2.

Figura 2**  Canalizar un objeto al cmdlet Get-Member le indica a qué métodos y propiedades puede usted tener acceso. **(Hacer clic en la imagen para ampliarla)

Además de propiedades, el shell también muestra los métodos disponibles, lo que significa que no se requiere necesariamente la documentación para averiguar lo que una clase es capaz de hacer. Puedo observar que la clase en sí misma ofrece los medios para cambiar una configuración de la instancia, poner en pausa un servicio, detener un servicio, etc.

Para usar estos métodos o mostrar otras propiedades, a menudo es más fácil poner las instancias en una variable:

$server = gwmi win32_operatingsystem
$server.reboot()

Este ejemplo recupera la única instancia disponible de la clase Win32_Operating­System (esta clase sólo tiene una instancia por equipo) y la guarda en la variable $server. A continuación, usará la variable $server para tener acceso al método Reboot de la instancia, reiniciando el equipo. ¡Cuidado con esto!

Lenguaje enriquecido para consultas

Si usa WMI con VBScript u otra tecnología, probablemente está acostumbrado a recuperar instancias de la clase WMI con una consulta escrita en WQL, el lenguaje de consulta de WMI. Su sintaxis parecida a SQL hace que sea más fácil recuperar instancias específicas (por ejemplo, un servicio específico) en lugar de todas las instancias de una clase dada. Afortunadamente, gwmi también permite especificar una consulta, de la siguiente manera:

gwmi –query “select * from win32_service where name=’alerter’”

Esta sintaxis de gwmi, que se agregó poco antes que Windows PowerShell se lanzara oficialmente al mercado, es increíblemente útil y hace muy pero muy fácil la tarea de migrar consultas complejas de WMI que posiblemente haya desarrollado para otros propósitos. Y, como siempre, Windows PowerShell devolverá objetos enriquecidos con sus propias propiedades y métodos, permitiéndole tener un acceso total al poder de administración de WMI.

Adelantándose con WMI

WMI continúa su desarrollo para futuras versiones de Windows, agregando nuevas clases y capacidades. Además, se continúa incorporando a los nuevos productos de Microsoft. Aunque la mayoría de los productos de Microsoft todavía no han lanzado al mercado versiones específicamente integradas con Windows PowerShell, uno de sus beneficios más grandes es la capacidad de conectarse a WMI, que hoy lo hacen tan útil.

Hablé superficialmente de lo que WMI es capaz de hacer. Aún así espero que le inspire para explorar Windows PowerShell y descubrir por su cuenta qué capacidades están disponibles.

Don Jones es director de proyectos y servicios de SAPIEN Technologies y coautor de Windows PowerShell: TFM (SAPIEN Press). Póngase en contacto con Don a través de su sitio web en la dirección www.ScriptingAnswers.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.