Windows PowerShell La connessione WMI

Don Jones

Una delle tecnologie alle quali mi affidavo maggiormente nel mondo di VBScript era Strumentazione gestione Windows, o WMI. In modo interessante, Windows PowerShell ha forti relazioni con WMI, e non solo in senso tecnico. Jeffrey Snover, che ha sviluppato l'architettura Windows PowerShell, è stato anche un principale collaboratore nella creazione di

Wmic.exe, un'utilità da riga di comando Windows Server® 2003 utilizzata per lavorare con WMI. Sotto molti aspetti, Wmic.exe aveva prefigurato Windows PowerShell™ in quanto lavorava in modo simile. Per ulteriori informazioni su WMIC, vedere l'articolo di John Kelbley dell'edizione di settembre 2006 TechNet Magazine, disponibile in linea all'indirizzo microsoft.com/technet/technetmag/issues/2006/09/WMIData.

Windows PowerShell fornisce il supporto per WMI in modo conforme e basato sugli oggetti come il resto delle funzionalità della shell. Ciò rende WMI molto più facile da imparare ed utilizzare, soprattutto in situazioni ad hoc, rispetto alle precedenti tecnologie, come VBScript.

Panoramica su WMI

Leggendo i libri e gli articoli sugli script, è quasi impossibile non vedere menzionato WMI. Tuttavia, è così facile utilizzare effettivamente WMI da dimenticare come è la sua struttura all'interno del sistema, che è importante soprattutto per il funzionamento in Windows PowerShell.

WMI è principalmente un sistema di classi organizzate che rappresentano le informazioni di gestione dal sistema operativo Windows® e altri prodotti hardware e software basati su Windows. Una classe non è che una descrizione astratta delle proprietà e delle funzionalità possedute da un dato componente software o hardware. Ad esempio, una classe di disco logico potrebbe descrivere una periferica che ha un numero di serie, una capacità di archiviazione fissa, una quantità di capacità disponibile, e così via. Nel frattempo, una classe che descrive un servizio Windows potrebbe specificare che il servizio ha un nome, che è in grado di avviarsi e arrestarsi, il suo stato corrente, e così via.

In WMI, le classi rappresentano tutto ciò che WMI può gestire. Se WMI non ha una classe per qualcosa, non può gestire tale componente. Microsoft documenta le classi principali di Windows WMI alla pagina msdn2.microsoft.com/aa394554.aspx; altri prodotti, come Internet Information Services, SQL Server™, documentano le loro classi di WMI separatamente.

Poiché le classi sono così tante, in WMI sono organizzate in una gerarchia di spazi dei nomi. Ad esempio, lo spazio dei nomi contenente le classi principali del sistema operativo Windows è denominato root\cimv2, mentre Microsoft IIS 6.0 memorizza le classi in root\Microsoft­IISv2. Per convenienza, lo spazio dei nomi root\cimv2 è lo spazio dei nomi WMI predefinito, un'impostazione condivisa da Windows PowerShell, che facilita il lavoro con le classi principali.

Una "istanza" è un'occorrenza reale di una classe. Se, ad esempio, il computer ha due dischi logici, si otterranno due istanze della classe del Win32_LogicalDisk. Se ci sono 50 servizi in esecuzione sul computer, WMI vedrà 50 istanze della classe Win32_Service. Lavorare con WMI significa essenzialmente chiedere a WMI di fornire una o più istanze, e poi esaminare le proprietà di quelle istanze per trovare le informazioni di gestione necessarie o eseguire i metodi di quelle istanze per apportare modifiche alla gestione, come ad esempio avviare o arrestare un servizio.

WMI utilizza un'architettura client-server. A partire da Windows 2000, in ogni versione di Windows è integrata WMI (le versioni successive hanno esteso il numero di classi disponibili), quindi il client di WMI e il software di server di WMI sono facilmente disponibili. Quando si utilizza WMI, si invia in realtà una richiesta al Servizio WMI in esecuzione su qualsiasi computer interessato. Quel Servizio WMI recupera le istanze WMI specificate e le restituisce affinché sia possibile lavorare con esse. Qui entra in gioco Windows PowerShell, che semplifica il processo di richiesta delle istanze, le ottiene e lavora con esse.

Ottenere un oggetto WMI

Dal momento che ci si riferisce genericamente alle istanze di classe di WMI come ad oggetti, ha senso recuperare quelle istanze in Windows PowerShell tramite il cmdlet Get-WMIObject. Questo cmdlet ha un alias conveniente, gwmi, che utilizzerò per la maggior parte dei miei esempi. Nella sua forma più semplice, si specifica semplicemente il nome della classe di WMI da recuperare e poi si guardano i risultati (vedere la Figura 1). Quando ho eseguito gwmi win32_service, Windows PowerShell si è connesso al servizio di WMI sul mio computer locale (poiché non avevo specificato un altro computer) e allo spazio dei nomi root\cimv2 (poiché non avevo specificato uno spazio dei nomi diverso). Windows PowerShell ha recuperato tutte le istanze della classe specificata e, poiché non dato altre istruzioni, ha convertito queste istanze in una rappresentazione testuale. In altre parole, Windows PowerShell ha preso gli oggetti e ha prodotto del testo che un essere umano è in grado di leggere.

Figura 1** Quando si esegue gwmi win32_service, Windows PowerShell restituisce tutte le istanze della classe specificata in un formato di testo leggibile **

Specificatamente, Windows PowerShell converte in testo gli oggetti di WMI leggendo e visualizzando i nomi e i valori delle proprietà di classe selezionate. Per la classe Win32_Service, sceglie una serie di sei proprietà.

In realtà, in questo modo Windows PowerShell converte qualunque oggetto in testo. Le proprietà che sceglie di visualizzare sono, per la maggior parte, definite in una serie di file format.ps1xml localizzati nella cartella di installazione di Windows PowerShell. Questi file di definizione formato hanno la firma digitale di Microsoft. Si sconsiglia di modificare questi file, anche se è possibile fornire i propri file di formattazione. Non è purtroppo questa la sede adatta per trattare di questo argomento, che verrà sviluppato in seguito.

Il cmdlet gwmi può aiutare ad esplorare il proprio computer per scoprire quali classi sono disponibili. Eseguendo gwmi –namespace "root\cimv2" –list, ad esempio, si ottiene un elenco completo di classi in quello spazio dei nomi. Ricordare, tuttavia, che le classi sul proprio computer sono pertinenti soltanto se si gestisce il proprio computer; per un computer remoto, si devono scoprire le classi disponibili su quel sistema. Per questo, si utilizzerà il parametro di computer gwmi per connettersi a un computer remoto. Ad esempio, gwmi –namespace "root\cimv2" –list –computer ServerA elencherà tutte le classi nello spazio dei nomi root\cimv2 sul computer remoto denominato ServerA.

Strumentazione gestione Windows (WMI) remota

Nella versione 1.0 di Windows PowerShell, gwmi riguarda il solo cmdlet che supporta direttamente la gestione remota. Ciò è dovuto principalmente al fatto che quel controllo remoto è creato nell'architettura di WMI sottostante. E, perché Windows PowerShell utilizza semplicemente quell'architettura esistente, è soggetto alle funzionalità di sicurezza di quell'architettura. Di seguito viene riportato un esempio:

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:\>

In quest'istanza, ho cercato di connettermi ad un computer remoto, denominato Media Server, per il quale non ho l'autorizzazione per l'accesso. Come amministratore, è necessario avere l'autorizzazione per lavorare con questo servizio WMI del computer, ma è probabile che le mie credenziali di workstation locale non siano sufficienti. Potrei, ad esempio, accedere a un dominio diverso, non trusted, o potrei avere accesso a un account con meno privilegi. Fortunatamente, gwmi supporta un parametro credenziale che mi consente di specificare una serie alternata di credenziali utente per la mia connessione WMI. Di seguito, è riportato un esempio molto semplice:

gwmi win32_service –credential mydomain\administrator –computer mediaserver

La mia credenziale, più specificatamente, il mio nome utente, è fornito nel formato DOMAIN\Username.

Notare che non è possibile inserire una password in nessun campo, me la richiederà Windows PowerShell. Deliberatamente, Windows PowerShell non fornisce un modo per inserire una password sulla riga di comando perché così facendo permetterebbe di impostare le password come hardcoded nei file script, che è un rischio di protezione assoluto. Esiste, tuttavia, un altro metodo con il quale è possibile lavorare al parametro credenziale, e cioè creando una specie di oggetto credenziale, denominato PSCredential, in anticipo. La chiave è il cmdlet Get-Credential:

$cred = get-credential mydomain\administrator

Quando lo eseguo, mi viene ancora richiesta la password corrispondente. Questa volta, tuttavia, l'oggetto credenziale creato è memorizzato nella variabile $cred. Se si guarda il contenuto di $cred, si vede il nome ma non la password:

PS C:\> $cred

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

Posso riutilizzare poi quell'oggetto credenziale quanto voglio:

gwmi win32_service –credential $cred –computer mediaserver

Ciò semplifica le connessioni WMI ripetute a un computer remoto predefinendo un oggetto riutilizzabile credenziale. Si noti comunque che il cmdlet Get-WMIObject non supporta attualmente i livelli di specificazione di autenticazione (altrimenti conosciuti come rappresentazione) nello stesso modo supportato da VBScript. Consultare msdn2.microsoft.com/aa389290.aspx per ulteriori informazioni.

Individuazione automatica

Una delle caratteristiche che preferisco di Windows PowerShell è che non volgarizza niente. Ho illustrato come Windows PowerShell ha selezionato soltanto una serie di proprietà per la classe Win32_Service che ho richiesto. La shell ha comunque accesso a tutte le proprietà, tuttavia, e può anche dire quali sono. Per farlo, basta inviare l'oggetto (o gli oggetti) al cmdlet Get-Member (o il suo alias, gm), come illustrato nella Figura 2.

Figura 2**  Inviando un oggetto al cmdlet Get-Member, la shell dice a quali metodi e proprietà è possibile accedere **(Fare clic sull'immagine per ingrandirla)

Oltre alle proprietà, la shell elenca anche i metodi disponibili, così non è necessaria la documentazione per scoprire ciò che la classe può fare. È possibile vedere che la classe fornisce i mezzi per modificare una configurazione dell'istanza, sospende un servizio, arresta un servizio, e così via.

Per utilizzare questi metodi o visualizzare altre proprietà, è spesso più semplice mettere le istanze in una variabile:

$server = gwmi win32_operatingsystem
$server.reboot()

Questo campione recupererà la sola istanza disponibile della classe Win32_Oper­a­ting­System (quella classe ha soltanto un'istanza per computer) e lo salva nella variabile $server. Utilizzerà poi la variabile $server per accedere al metodo di riavvio dell'istanza, riavviando il computer. È necessario essere prudenti.

Rich Query Language

Se si utilizza WMI con VBScript o un'altra tecnologia, probabilmente si è abituati a recuperare istanze di classe WMI utilizzando una query scritta in WQL, il linguaggio di query WMI. La sintassi di tipo SQL rende più facile recuperare le istanze specifiche, come un servizio specifico, piuttosto che tutte le istanze di una data classe. Fortunatamente, gwmi consente anche di specificare una query così:

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

Questa sintassi di gwmi (che è stata aggiunta appena prima che Windows PowerShell fosse ufficialmente rilasciato) è incredibilmente utile e semplifica molto la migrazione delle query WMI complicate che è possibile avere sviluppato per altri scopi. Come sempre, Windows PowerShell restituirà gli oggetti completi con le loro proprietà e i loro metodi, offrendo un accesso completo alla gestione WMI.

Guardare avanti con WMI

WMI continua ad essere sviluppato per le versioni future di Windows, aggiungendo nuove classi e funzionalità. E continua ad essere aggiunto ai nuovi prodotti di Microsoft. Mentre per la maggior parte dei prodotti di Microsoft non sono state ancora rilasciate versioni create specificatamente per Windows PowerShell, la capacità di Windows PowerShell di connettersi a WMI è uno dei benefici più grandi che lo rendono utile anche oggi.

Ho soltanto fatto un breve accenno a WMI. Spero di avere stimolato la curiosità e spinto a esplorare Windows PowerShell per scoprire le funzionalità disponibili.

Don Jones è responsabile progetti e servizi di SAPIEN Technologies e coautore di Windows PowerShell: TFM (SAPIEN Press). Contattare Don tramite il suo sito Web all'indirizzo www.ScriptingAnswers.com.

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