• Articolo

Utilità in primo pianoCmdlet SMS per Windows PowerShell

Don Brown

Scarica il codice per questo articolo: Utility2007_11.exe (1211KB)

In passato non era possibile gestire i client di Microsoft System Management Server (SMS) 2003 dalla riga di comando. Questo problema è stato risolto da Windows PowerShell, una delle eccezionali tecnologie sviluppate di recente per semplificare agli amministratori la gestione delle complessità, delle modifiche e della configurazione.

Per sfruttare i vantaggi di questa soluzione, ho creato una piccola "utilità", SMS2003PowerShellSnapinSample, inclusa nel download di codice di questo articolo e disponibile in linea all'indirizzo technetmagazine.com/code07.aspx. L'utilità include in un unico snap-in di Windows PowerShellTM una raccolta di sei cmdlet, che consentono di configurare i criteri locali del client SMS per il computer locale o per gruppi di computer remoti tramite Windows PowerShell.

Dopo aver eseguito numerosi test sui criteri locali del client SMS, questa soluzione mi è sembrata la più appropriata. In questo modo, ho potuto anche approfondire le mie conoscenze sul funzionamento di SMS. Ho imparato che applicando accuratamente i criteri locali è possibile gestire il client SMS in un modo completamente nuovo: non è necessario che i computer in cui vengono generati report per lo stesso sito siano configurati in modo identico. Ho iniziato a elaborare diverse soluzioni, ad esempio l'impostazione di determinati computer in modo da non richiedere l'autorizzazione per il controllo remoto, la modifica della frequenza con cui il client verifica la presenza di nuovi criteri e la disabilitazione di componenti specifici in diverse ore del giorno. I criteri locali del client SMS offrono infinite possibilità. Esaminiamole nei dettagli.

Informazioni sui criteri locali del client avanzato SMS

Risorse di programmazione

In tutti i client avanzati di SMS 2003 sono presenti determinati criteri di configurazione, ovvero un elenco di impostazioni che regolano il funzionamento dei diversi componenti. Tutte le impostazioni relative alla distribuzione software, alla raccolta dell'inventario e al client sono incluse in questi criteri di configurazione. I criteri stessi vengono creati sul server del sito e passati al client avanzato tramite il punto di gestione SMS.

L'effettiva struttura di un criterio SMS è analoga a quella di un file MOF, poiché contiene una serie di istanze che verranno compilate nello spazio dei nomi di Strumentazione gestione Windows® (WMI) \\.\root\CCM sul client avanzato. Gli altri agenti leggeranno quindi tali impostazioni dallo spazio dei nomi \\.\root\ccm\policy\machine\requestedconfig. Se i criteri locali vengono applicati tramite file MOF, tuttavia, occorre considerare che è possibile compilare un file MOF su un unico computer ed eseguirlo localmente (ovvero quando si è connessi direttamente al computer). La natura distribuita di WMI, invece, consente l'accesso sia in locale che in remoto, pertanto offre una gamma più ampia di opzioni per gli amministratori di SMS. Ciò significa che è possibile connettersi facilmente a WMI sia su un computer remoto che sul computer locale, a condizione che si disponga dei diritti amministrativi appropriati.

I criteri client SMS sono costituiti dalle impostazioni di configurazione dei diversi componenti client, tuttavia possono includere anche istruzioni per l'esecuzione dei contenuti del pacchetto software. Analogamente ai Criteri di gruppo di Active Directory®, i criteri locali del client SMS possono avere la precedenza sui criteri del client avanzato di SMS 2003 ottenuti da un punto di gestione SMS. Anche se non è possibile sostituire tutti i componenti di un criterio, è possibile sostituire alcune proprietà interessanti. Ciò fornisce agli amministratori di SMS un livello di controllo superiore sulla configurazione e sulle operazioni del client SMS, poiché consente la presenza di eccezioni nella configurazione standard del sito SMS.

Si consideri, ad esempio, un ambiente consolidato e protetto in cui gli amministratori di SMS gestiscono sia i server che le workstation come client di un unico sito primario di SMS. In questo ambiente fittizio, un criterio di protezione potrebbe imporre che venga richiesta un'autorizzazione prima che i tecnici dell'assistenza possano ottenere il controllo remoto del computer. Tale criterio rappresenterebbe un problema, se i tecnici dell'assistenza volessero connettersi ai server utilizzando il controllo remoto: in genere, nessun utente è connesso ai server, pertanto non è necessaria alcuna autorizzazione per il controllo remoto. Ciononostante, se i criteri locali vengono applicati in modo appropriato, è possibile sostituire il requisito relativo all'autorizzazione utente su determinati client. Esistono molte altre circostanze in cui i criteri locali di SMS possono risultare utili per garantire la possibilità di un'eccezione nella configurazione di un agente specifico del client SMS.

Analisi dello snap-in di Windows PowerShell

Una volta acquisita dimestichezza con le nozioni di base di Windows PowerShell, è possibile applicarle al codice sorgente di esempio fornito in questo articolo per aumentare le operazioni che è possibile eseguire con i criteri locali del client SMS dalla riga di comando. Prima di esporre una classe a Windows PowerShell, è necessario applicarvi determinati attributi e stabilire quale funzione deve essere assegnata al cmdlet. Tale operazione è nota come coppia di verbo e sostantivo. Alcuni verbi comunemente utilizzati in Windows PowerShell includono Add, Get e Set. Nella parte relativa al sostantivo viene descritto l'oggetto su cui deve essere eseguita l'azione. In genere, i cmdlet includono parametri che vengono dichiarati in una classe Cmdlet come proprietà pubbliche di diversi tipi. La funzione ProcessRecord, infine, è il componente principale in cui verranno eseguite le operazioni. Nella Figura 1 viene illustrato un modello generico che può essere utilizzato per creare cmdlet personalizzati.

Figure 1 Modello di 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!
    }
}

Dopo aver compilato lo snap-in, è necessario registrarlo con Windows PowerShell includendo nel progetto una classe in cui sia impostato l'attributo RunInstaller e siano definite alcune proprietà specifiche. Per informazioni dettagliate, vedere il codice sorgente fornito in questo articolo. Per registrare lo snap-in, è necessario utilizzare lo strumento InstallUtil.exe disponibile con Microsoft® .NET Framework. Nella Figura 2 viene illustrata la sintassi necessaria per registrare lo snap-in. In Windows Vista®, questa operazione richiede un processo di elevazione dei privilegi, pertanto sarà necessario accedere a Windows PowerShell come amministratore oppure utilizzare i PowerToy per l'elevazione dei privilegi degli script in Windows Vista (scaricabili all'indirizzo technetmagazine.com/issues/2007/06/UtilitySpotlight).

Figure 2 Installazione dello snap-in di 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.

Il passaggio successivo consiste nel verificare che il proprio snap-in venga riconosciuto da Windows PowerShell. A tal fine, è necessario utilizzare il cmdlet Get-PSsnapin con il parametro Registered. In Windows PowerShell verrà fornito un riepilogo degli snap-in attualmente caricati, seguito da un elenco di quelli registrati, che dovrebbe includere il proprio snap-in:

PS> Get-PSsnapin -registered

Sarà quindi possibile aggiungere alla shell lo snap-in di Windows PowerShell utilizzando il cmdlet Add-PSsnapin, come indicato di seguito:

PS> add-pssnapin SMS2003PowerShellSnapinSample

Se l'operazione viene eseguita correttamente, i cmdlet potranno essere eseguiti nello snap-in di Windows PowerShell.

Per visualizzare tutti i cmdlet disponibili in uno snap-in di Windows PowerShell, è sufficiente indicare lo snap-in specifico con il cmdlet Get-Command e passare il relativo nome come valore per il parametro PSsnapin. Nello snap-in di esempio fornito in questo articolo vengono visualizzati sei cmdlet, incluso il modello di cmdlet Verb-Noun, come illustrato nella Figura 3.

Figura 3 Visualizzazione dei cmdlet in uno snap-in

Figura 3** Visualizzazione dei cmdlet in uno snap-in **(Fare clic sull'immagine per ingrandirla)

Nel codice sorgente di esempio, ho fornito le istruzioni solo per il cmdlet Get-SMSServerConnection, per illustrare come viene creato. Se si desidera approfondire l'argomento, verrà fornito un esempio nel file XML. Nella Figura 4 viene illustrato l'output delle istruzioni.

Figure 4 Output di esempio di 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

Dopo aver esaminato come installare lo snap-in di Windows PowerShell, individuare i comandi presenti nello snap-in e ottenere istruzioni su un cmdlet tipico, verrà illustrato come utilizzare i cmdlet. Per visualizzare un elenco di tutte le raccolte disponibili su un server del sito primario di SMS, è possibile utilizzare il seguente comando:

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

Si osservi la pipeline, che è uno strumento molto potente, nonché un componente essenziale del funzionamento di Windows PowerShell. In Windows PowerShell è possibile impostare l'esecuzione di qualsiasi operazione in una singola riga. Il cmdlet Get-SMSServerConnection consente di stabilire una connessione con il server SMS. Poiché il cmdlet Get-Collections presenta un unico parametro di input analogo a quello restituito da Get-SMSServerConnection, è possibile passare semplicemente l'output dal cmdlet Get-SMSServerConnection al cmdlet Get-Collections. Questo passaggio di oggetti complessi tra i cmdlet è esemplificativo del funzionamento della pipeline. È anche possibile archiviare oggetti all'interno di variabili, come illustrato nel seguente script di esempio di Windows PowerShell:

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

L'output potrebbe risultare di difficile lettura in quanto privo di formattazione chiara, poiché il cmdlet Get-Collections restituisce un oggetto di tipo SMSCollections, ovvero una serie di oggetti di tipo SMSCollection. In pratica, la visualizzazione risulterà poco chiara, a meno che non venga applicato un filtro alle raccolte da visualizzare oppure non venga formattata la visualizzazione in una tabella che contiene solo le proprietà rilevanti. A tal fine, è necessario passare l'output attraverso la pipeline dal cmdlet Get-Collections al cmdlet Format-Table, che è in grado di visualizzare solo le proprietà specificate. Ad esempio, è possibile aggiungere | Format-Table Name, Members.

Tuttavia, per visualizzare tutti i membri di una determinata raccolta, la soluzione migliore è utilizzare il cmdlet Get-CollectionMembers, che restituisce una serie di stringhe indicanti il nome di ogni membro della raccolta. Come si può immaginare, questo cmdlet è un ottimo candidato per passare la pipeline al cmdlet successivo.

Finora, sono state fornite informazioni sulle connessioni al server del sito primario di SMS, sull'enumerazione delle raccolte e sui relativi membri, ma non sono ancora stati utilizzati i criteri locali del client avanzato SMS. In questo snap-in di esempio di Windows PowerShell sono inclusi altri due cmdlet, denominati rispettivamente Enable-SoftwareDistribution e Disable-SoftwareDistribution. A questo punto entrano in gioco i criteri locali del client SMS. Questi due ultimi cmdlet consentono di modificare i criteri locali del client SMS per il componente Software Distribution Client Agent nel client avanzato SMS. La sezione del cmdlet relativa al verbo, Disable, prevede la sostituzione di un criterio locale del client, nel caso specifico la disabilitazione di Software Distribution Client Agent. Analogamente, il verbo Enable prevede la rimozione di tutte le sostituzioni dei criteri locali del client, ripristinando il normale stato di Software Distribution Client Agent, come definito nei criteri SMS passati dal punto di gestione SMS. Nella Figura 5 viene illustrato un esempio di una singola riga di codice in Windows PowerShell, che prevede la sostituzione di un criterio locale del client in Software Distribution Client Agent e ne impone la disabilitazione per tutti i membri della raccolta personalizzata dei sistemi Windows Server 2003. Viene fornita inoltre la riga di codice che consente di rimuovere tutte le sostituzioni dei criteri locali del client SMS per Software Distribution Client Agent in tale raccolta. I cmdlet Disable-SoftwareDistribution ed Enable-SoftwareDistribution possono anche essere utilizzati individualmente, se si desidera modificare i criteri locali del client SMS solo in alcuni computer.

Figure 5 Esempi di assemblaggio di cmdlet

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

Passaggi successivi

Il codice sorgente di esempio fornito in questo articolo offre un ottimo punto di partenza per applicare sostituzioni dei criteri locali del client SMS a gruppi di computer. Questo esempio riguarda solo Software Distribution Client Agent di SMS, in particolare la proprietà Enabled. Gli altri agenti client presentano molte altre proprietà a cui è possibile applicare sostituzioni in modo analogo. Dopo aver fornito un punto di partenza comune, il passaggio logico successivo consiste nell'esaminare altri componenti dei criteri locali del client SMS. Si considerino, ad esempio, i gruppi di sistemi gestiti a cui potrebbero essere applicate determinate sostituzioni di criteri locali del client SMS e le sostituzioni adeguate alle proprie esigenze. Infine, è utile valutare quali potrebbero essere i risultati delle proprie operazioni, verificandole accuratamente in un ambiente di lavoro.

Don Brown è Senior Premier Field Engineer presso Microsoft e da tempo offre collaborazione e supporto allo sviluppo della nuova versione di System Manager Server (SMS), ovvero System Center Configuration Manager (SCCM). È possibile contattarlo all'indirizzo donbrown@microsoft.com.

© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.