• Artículo

Utility SpotlightCmdlets de SMS para Windows PowerShell

Don Brown

Descargar el código de este artículo: Utility2007_11.exe (1211KB)

Anteriormente no era posible administrar los clientes de Microsoft System Management Server (SMS) 2003 desde la línea de comandos. Por suerte, entre las muchas importantes tecnologías que han surgido últimamente para ayudar a los administradores a administrar la complejidad, cambios y configuración, se presentó Windows PowerShell para resolver ese problema.

Para aprovechar esta situación, creé una pequeña "utilidad", SMS2003PowerShellSnapinSample (que puede encontrar en la descarga de código que acompaña esta columna, disponible en línea en technetmagazine.com/code07.aspx). La utilidad es en realidad una recopilación de seis cmdlets fusionados en un solo componente de Windows PowerShellTM. Mediante estos cmdlets, es posible configurar una directiva local de cliente de SMS desde Windows PowerShell para el equipo local o grupos de equipos remotos.

Cuanto más jugaba con la directiva local de cliente de SMS, más sentido adquiría lo que hacía. Como ventaja adicional, llegué a comprender más detalles sobre el funcionamiento de SMS. Aprendí que a través de la aplicación cuidadosa de la directiva local de cliente de SMS, éste podía controlarse de una manera totalmente nueva: los equipos que pertenecen al mismo sitio no tienen porqué configurarse del mismo modo. Las ideas comenzaron a fluir, desde la configuración de ciertos equipos para que no se requiriera permiso para controlar el equipo remotamente, al cambio de la frecuencia con la que el cliente comprueba si hay nuevas directivas, o la deshabilitación de componentes específicos a varias horas del día, ya no hay límites a la hora de usar la directiva local de cliente de SMS. Echemos un vistazo más detenido.

Acerca de la directiva local de cliente avanzado de SMS

Programación de recursos

Todos los clientes avanzados y funcionales de SMS 2003 tienen una directiva de configuración, que fundamentalmente es una lista de configuración que dirige sus distintos componentes. En estas directivas de configuración se incluyen todos los clientes, recopilaciones de inventario y configuraciones de distribución de software (entre otros). Las propias directivas se crean en el servidor del sitio y se ofrecen al cliente avanzado a través del punto de administración de SMS.

El cuerpo en sí de una directiva de SMS se parece a un archivo Managed Object Format (MOF) en que contiene un conjunto de instancias que se compilarán en los espacios de nombres \\.\root\CCM WMI (Instrumental de administración de Windows®) en el cliente avanzado. El resto de agentes leerán, a continuación, estas configuraciones, que se encuentran en el espacio de nombres \\.\root\ccm\policy\machine\requestedconfig. No obstante, al aplicar la directiva local a través de MOF, sólo puede compilar un MOF en un solo equipo y debe ejecutarse de manera local (o cuando haya iniciado sesión directamente en la máquina). Sin embargo WMI, debido a su naturaleza distribuida, es accesible tanto de manera local como remota, lo que ofrece un amplia gama de opciones para ayudar a los administradores de SMS. Esto significa que puede conectarse a WMI en un equipo remoto con la misma facilidad que desde su equipo local, siempre que se den los derechos administrativos apropiados.

La directiva de cliente de SMS consiste en opciones de configuración para los distintos componentes de cliente, pero también puede incluir las instrucciones para ejecutar el contenido del paquete de software. Al igual que con la directiva de grupo de Active Directory®, la directiva de cliente avanzado de SMS 2003 obtenida desde un punto de administración de SMS puede invalidarse con la directiva de cliente local de SMS. No es posible invalidar todas las partes de una directiva, pero algunas propiedades realmente interesantes sí que pueden invalidarse. Esto ofrece a los administradores de SMS un mayor grado de control sobre la configuración y operaciones del cliente de SMS porque permite las excepciones a la configuración estándar aplicada en el sitio de SMS.

Tome como ejemplo un entorno seguro y consolidado, donde los administradores de SMS administran los servidores y las estaciones de trabajo como clientes de un solo sitio principal de SMS. En este entorno imaginario, una directiva de seguridad puede indicar que se pida permiso al usuario antes de que los técnicos del servicio de asistencia puedan obtener el control remoto sobre el equipo. Esto obviamente resulta un problema si los técnicos del servicio de asistencia desean usar el control remoto para asociarse a los servidores: normalmente, ningún usuario inicia sesión en los servidores, por lo que nadie puede otorgar el permiso de control remoto. Sin embargo, gracias a la cuidadosa aplicación de la directiva local, el requisito del permiso del usuario puede invalidarse en clientes específicos. Probablemente, puede imaginarse muchas otras circunstancias en las que puede resultar práctico conceder una excepción a la directiva local de SMS para la configuración de un agente de cliente de SMS particular.

Dentro del componente de Windows PowerShell

Una vez que adquiera cierta familiaridad con los principios básicos de Windows PowerShell, puede usar el código fuente de ejemplo que ofrece esta columna para ampliar lo que puede hacer a la directiva local de cliente de SMS desde la línea de comandos. Hay atributos específicos que deben aplicarse a una clase antes de exponerla en Windows PowerShell. Necesita decidir a qué hace referencia el cmdlet y qué acción debe llevarse a cabo. A esto se le denomina emparejamiento "verbo-nombre". Algunos verbos comunes que verá en Windows PowerShell son Add, Get y Set. La parte del sustantivo describe el objeto sobre el que desea actuar. Los cmdlets normalmente tienen parámetros, que se declaran en una clase de Cmdlet como las propiedades públicas de varios tipos. Por último, la función ProcessRecord es el lugar principal donde llevará a cabo la mayor parte de su trabajo. La figura 1 muestra una plantilla genérica que puede usar para cmdlets propios.

Figure 1 Plantilla de Cmdlet

[Cmdlet( "Verb", "Noun", SupportsShouldProcess = true )]
public class Verb_Noun : PSCmdlet
{
    [Parameter( ValueFromPipeline = true, ValueFromPipelineByPropertyName = true, 
        HelpMessage = "Parameter" )]
    [ValidateNotNullOrEmpty]
    [Alias( "param" )]
    public string Parameter
    {
        get { return MyParameter; }
        set { MyParameter = value; }
    }
    private string MyParameter;

    protected override void ProcessRecord( )
    {
        //Do your stuff here!
    }
}

Una vez que ha compilado su componente, lo registra con Windows PowerShell e incluye una clase en su proyecto que tenga establecido el atributo RunInstaller y unas pocas propiedades específicas definidas. Consulte el código fuente que acompaña a este artículo para obtener información más específica. Para registrar su componente, necesitará usar la herramienta InstallUtil.exe que se incluye en Microsoft® .NET Framework. La figura 2 muestra la sintaxis que debe usar para registrar su componente. Tenga en cuenta que en Windows Vista® es una operación que requiere la elevación de privilegios, por lo que deseará abrir Windows PowerShell con la opción "Abrir como administrador" o usar Script Elevation PowerToys para Windows Vista (que puede descargar en technetmagazine.com/issues/2007/06/UtilitySpotlight).

Figure 2 Cómo instalar el componente desde Windows PowerShell

PS> set-alias installutil $env:windir\Microsoft.NET\Framework\v2.0.50727\installutil 
PS> installutil C:\MySMSTools\SMS2003PowerShellSnapinSample.dll 
Microsoft (R) .NET Framework Installation utility Version 2.0.50727.42 
Copyright (C) Microsoft Corporation. All rights reserved. 
Running a transacted installation. 
... 
The transacted install has completed.

El paso siguiente consiste en averiguar si Windows PowerShell reconoce el componente. Use el cmdlet Get-PSsnapin con el parámetro Registered para que Windows PowerShell resuma los componentes cargados actualmente, seguido de una lista de componentes registrados que se pueden agregar. Su componente debe encontrarse en esta lista:

PS> Get-PSsnapin -registered

Ahora puede agregar el componente de Windows PowerShell al shell mediante el cmdlet Add-PSsnapin, del siguiente modo:

PS> add-pssnapin SMS2003PowerShellSnapinSample

Si la operación se realiza correctamente, debe poder ejecutar los cmdlets en el componente de Windows PowerShell.

Para consultar todos los cmdlets disponibles a través de cualquier componente de Windows PowerShell, sólo tiene que especificar el componente en particular con el cmdlet Get-Command, incluido el nombre de su componente como valor para el parámetro PSsnapin. El componente de ejemplo que acompaña esta columna muestra seis cmdlets, incluida la plantilla de Cmdlet verbo-nombre, como se muestra en la figura 3.

Figura 3 Visualización de los cmdlets de un componente

Figura 3** Visualización de los cmdlets de un componente **(Hacer clic en la imagen para ampliarla)

En el código fuente de ejemplo, sólo he escrito ayuda para el cmdlet Get-SMSServerConnection para demostrar cómo se ha creado. Si desea ampliar la ayuda, tendrá un ejemplo sobre el que basarse en el archivo XML. La figura 4 muestra el resultado de la ayuda.

Figure 4 Resultado del ejemplo Get-Help

PS > get-help Get-SMSServerConnection

NAME
    Get-SMSServerConnection

SYNOPSIS
    This cmdlet establishes a connection to the specified SMS primary site server using your current credentials. An object of type "SMSProvider" is returned through the pipeline.

SYNTAX
    Get-SMSServerConnection [-SMSServerName] [<string>] [<CommonParameters>]

DETAILED DESCRIPTION
    This Cmdlet makes a connection to the specified SMS primary site server.  An object of type "SMSProvider" is returned. The "SMSProvider" object is not serializable and is used only to forward on through the pipeline to other cmdlets.

RELATED LINKS

Ahora que ya sabe cómo instalar el componente de Windows PowerShell, cómo averiguar qué comandos están presentes en el componente y cómo obtener ayuda en un cmdlet típico, comencemos a usar los cmdlets. Para mostrar una lista de todas las recopilaciones en un servidor de sitio principal de SMS, puede usar el siguiente comando:

PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | Format-Table Name

Tenga en cuenta la canalización. Esta es una parte fundamental del funcionamiento de Windows PowerShell y es una herramienta muy eficaz. Es posible hacer casi cualquier cosa en Windows PowerShell en una línea. El cmdlet Get-SMSServerConnection establece una conexión con el servidor SMS. Puesto que el cmdlet Get-Collections tiene un solo parámetro de entrada del tipo devuelto por Get-SMSServerConnection, puede pasar simplemente el resultado desde el cmdlet Get-SMSServerConnection al cmdlet Get-Collections. Así es cómo funciona la canalización, se trata de un buen ejemplo sobre cómo transmitir objetos complejos de un cmdlet a otro. También puede almacenar objetos en variables y si ya lo hacía en un script de Windows PowerShell, puede que tenga el siguiente aspecto:

$SMS = Get-SMSServerConnection 
     -server MYSMSSERVER
Get-Collections -SMSServerProvider $SMS

El resultado puede ser un poco difícil de leer si la salida no tiene formato, ya que Get-Collections devuelve un objeto del tipo SMSCollections (que es básicamente una matriz de objetos del tipo SMSCollection). En resumen, la visualización no es muy agradable hasta que elimine las recopilaciones que no le interese ver o dé formato al resultado en una tabla que sólo contenga las propiedades que le interesan. Esto se consigue pasando el resultado del cmdlet Get-Collections a través de la canalización al cmdlet Format-Table, que sólo puede mostrar las propiedades que especifique. Por ejemplo, puede anexar | Format-Table Name, Members.

Pero hay una mejor manera de mostrar todos los miembros de una recopilación determinada y en este ejemplo es Get-CollectionMembers. Este cmdlet devuelve una matriz de cadenas, que representan el nombre de cada miembro de la recopilación. Tal como habrá adivinado, se trata de un estupendo candidato para transmitir la canalización al próximo cmdlet.

Hasta este punto, no ha habido directiva local de cliente avanzado de SMS, sólo conexiones al servidor del sitio principal de SMS y enumeraciones de recopilaciones y miembros de recopilaciones. En este componente de ejemplo de Windows PowerShell hay dos últimos cmdlets, denominados Enable-SoftwareDistribution y Disable-SoftwareDistribution respectivamente. Aquí es donde entra en juego la directiva local de cliente de SMS. Estos dos últimos cmdlets manipulan la directiva local de cliente de SMS para el componente del agente del cliente de distribución de software en el cliente avanzado de SMS. Tal como habrá adivinado por la parte del verbo del cmdlet, Disable coloca una invalidación de la directiva local de cliente que especifica que el Agente del cliente de distribución de software también debe deshabilitarse. Del mismo modo, el verbo Enable elimina todas las invalidaciones de directivas locales de cliente, devolviendo el Agente del cliente de distribución de software a su estado normal, que se define por la directiva de SMS transmitida a través del punto de administración de SMS. La figura 5 muestra un ejemplo del aspecto que podría tener una línea de Windows PowerShell que coloca una invalidación de directiva local de cliente de SMS en el Agente del cliente de distribución de software y lo fuerza a ser deshabilitado para todos miembros de la recopilación personalizada de los sistemas Windows Server 2003. La línea para quitar todas las invalidaciones de directivas locales de cliente de SMS para el Agente del cliente de distribución de software también se incluye en esa misma recopilación. Los cmdlets Disable-SoftwareDistribution y Enable-SoftwareDistribution pueden usarse también individualmente, si sólo tiene unos pocos equipos en los desea manipular la directiva local de cliente de SMS.

Figure 5 Cómo ensamblar los cmdlets, ejemplos

PS >Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Disable-SoftwareDistribution 
PS >
PS > Get-SMSServerConnection -server MYSMSSERVER | Get-Collections | where-object {$_.Name -eq "Windows Server 2003 Systems"} | Get-CollectionMembers | Enable-SoftwareDistribution
PS >
PS >Disable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3
PS >
PS >Enable-SoftwareDistribution –hosts SMSCLIENT1, SMSCLIENT2, SMSCLIENT3

Pasos siguientes

El código fuente de ejemplo que viene con este artículo puede proporcionar un buen punto de partida para aplicar las invalidaciones de las directivas locales de cliente de SMS a los grupos de equipos. El ejemplo actual sólo cubre el Agente del cliente de distribución de software y por tanto sólo la propiedad Enabled. Los otros agentes de cliente tienen muchas más propiedades a las que puede aplicar invalidaciones de la misma manera. Ahora que ya dispone de un punto de partida común, el siguiente paso lógico es observar otras partes de la directiva local de cliente de SMS. Piense en grupos de sistemas administrados que puedan ser buenos candidatos para las invalidaciones de directivas locales de cliente de SMS y qué reemplazo de directiva local tiene sentido que use. Nota final: Es aconsejable conocer siempre de antemano las repercusiones de estas actuaciones, así que debe probar todo con detenimiento en un entorno de laboratorio.

Don Brown es un Ingeniero de campo principal en Microsoft y ha trabajado y prestado asistencia técnica para SMS (es decir, SCCM) durante muchísimo tiempo. Póngase en contacto con él en donbrown@microsoft.com.

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