Windows PowerShellAnteprima della versione 2.0 di Gestione remota

Don Jones (in inglese)

L'articolo è basato sulla versione non definitiva di Windows PowerShell. Le informazioni riportate sono soggette a modifiche.

Indice

Due tipi di servizio remoto
Sincrono contro asincrono
Spazi di esecuzione riutilizzabili
Servizio remoto fan-in
L'applicazione killer nella versione 2.0

Vi è mai capitato di sperimentare l'ultima CTP (Community Technology Preview) di Windows PowerShell 2.0? L'ultima versione, CTP2, dispone di una gestione remota più raffinata e questo è il momento giusto per iniziare a familiarizzare con le nuove funzionalità che offre. Prima di leggere l'articolo, prendetevi qualche minuto per

scaricarla dal sito Web all'indirizzo go.microsoft.com/fwlink/?LinkID=119707.

Innanzitutto, vorrei chiarire un paio di punti importanti. Una CTP è un codice pre-beta che Microsoft fornisce per dare agli utenti impazienti come me, un'idea della direzione intrapresa con la versione successiva di un'applicazione. Ogni attività cardine o "drop" (come da definizione del settore) della CTP potrebbe essere completamente diversa rispetto alle precedenti, perché il team di sviluppo raccoglie commenti e suggerimenti da parte degli utenti, li esamina attentamente per poi modificare l'applicazione sulla base degli stessi. Tale metodologia introduce un grande vantaggio, ma ci dà anche un avvertimento importante sull'uso della CTP.

Il vantaggio è che quando si utilizza la CTP, è possibile inviare commenti e suggerimenti (attraverso il sito Web connect.microsoft.com) sul prodotto, proprio nel momento in cui il team di sviluppo è in grado di metterli in pratica. Se si aspetta la beta o, peggio ancora, la fase della versione finale candidata, è più difficile integrare i commenti e i suggerimenti dell'utente. Durante la CTP può succedere di tutto ed il team può apportare modifiche profonde e radicali.

Ciò mi spinge a darvi l'avvertimento accennato prima: la CTP non è pronta per la produzione. Certo, la CTP2 di Windows PowerShell™ 2.0 potrebbe essere una delle parti più stabili mai viste della versione preliminare del codice, ma bisogna ricordarsi che la prossima "drop" della CTP potrebbe rivelarsi un'applicazione completamente diversa. Per cui, non fate troppo affidamento sulla CTP2 perché la versione successiva potrebbe farvi ricominciare daccapo.

Si noti che la CTP non può essere installata in parallelo con Windows PowerShell 1.0. Per un'installazione ideale, il sistema dovrebbe disporre anche di Microsoft® .NET Framework 3.5 per poter attivare tutte le funzionalità disponibili; in caso contrario, alcune di esse saranno limitate.

Inoltre, poiché la CTP è un codice preliminare, fino ad ora Microsoft ha posto molta enfasi sull'uso dell'applicazione negli ultimi sistemi operativi, cioè Windows Vista® e Windows Server® 2008. Di conseguenza, la compatibilità del sistema operativo attuale non è indicativa della compatibilità del sistema operativo che ci si può aspettare al momento del rilascio del codice finale. Il backporting verrà trattato successivamente nella parte relativa al ciclo di sviluppo.

Due tipi di servizio remoto

Nel mondo della gestione remota, si trovano di solito due tipi di servizio remoto: fan-in e fan-out. Il servizio remoto fan-in coinvolge più amministratori che creano connessioni basate su shell sicure ad un server unico. Windows PowerShell è progettato per attivare questo sistema in modo sicuro, effettuando una partizione dei dati, in modo che, ad esempio, un Exchange Server che ospita l'azienda può fornire ai propri clienti l'accesso amministrativo alle proprie parti di un server. Con il servizio remoto fan-in, si ottiene l'accesso remoto protetto e interattivo alla copia di Windows PowerShell (solo alla versione 2.0) installata su un server remoto.

Il servizio remoto fan-out consiste nell'inviare simultaneamente una serie di comandi a un intero gruppo di server remoti. I comandi effettuano il fan out dalla propria workstation al gruppo di server in parallelo. I comandi vengono eseguiti su ogni server e i risultati, sotto forma di oggetti di Windows PowerShell, vengono restituiti alla propria workstation così è possibile riesaminarli e lavorarci. Windows PowerShell supporta due tecnologie principali per il servizio remoto fan-out, Strumentazione gestione Windows® (WMI) e Gestione remota Windows, che inizialmente sono state fornite con Windows Server 2008 ed aggiornate successivamente nella CTP di Windows PowerShell 2.0.

Sincrono contro asincrono

In realtà, anche Windows PowerShell 1.0 disponeva di alcune funzionalità fan-out di base, legate a WMI. Ad esempio, era possibile creare facilmente un array di nomi computer e recuperare successivamente una classe di WMI da ognuno:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem 
    –computer $names

I metodi di esecuzione, quali il riavvio del computer, richiedevano un po' più di lavoro poiché la versione 1.0 non offriva nessuna funzione di massa per eseguire i metodi WMI. Ciò è stato modificato nella CTP in versione 2.0, grazie al cmdlet Invoke-WmiMethod:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names | `
 Invoke-WmiMethod Reboot

Tuttavia, questa tecnica pone un problema; si tratta di un metodo sincrono, il che significa che viene contattato un computer per volta e che bisogna aspettare che ognuno finisca prima di poter eseguire altri comandi. La CTP introduce però un concetto nuovo, i processi in background, che consente ai comandi come questo di essere eseguiti in background. Più semplicemente, è possibile eseguire un comando WMI in background, aggiungendo il parametro AsJob:

$names = @("server1","server2","server2")
Get-WmiObject Win32_OperatingSystem     –computer $names -asjob

Si può riesaminare lo stato del lavoro risultante eseguendo Get-PSJob ed visualizzare i risultati finali del processo eseguendo Receive-PSJob. (Tratterò maggiormente i dettagli riguardo alla gestione del processo in un articolo futuro). Tuttavia, il cmdlet Invoke-Command fornisce modi anche migliori per eseguire comandi in background, come il seguente:

$command = { Get-WmiObject     Win32_OperatingSystem }
$names = @("server1","server2","server2")
Invoke-Command –command $command     –computer $names –asjob

Questo fa azionare il comando di Get-WmiObject in ogni computer specificato e vien eseguito localmente in un secondo momento. In genere, viene eseguito molto più velocemente e senza doversi affidare alle connessioni della RPC (Remote Procedure Call) di WMI. Al contrario, Invoke-Command utilizza Gestione remota Windows, che per impostazione predefinita si serve delle porte 80 o 443, le quali rendono più facile sfogliare i firewall e sono interamente configurabili. Invoke-Command supporta anche parametri aggiuntivi per alternare le credenziali e le limitazioni, consentendo all'utente di scegliere come destinazione centinaia di computer ma di averne solo un piccolo gruppo in esecuzione in parallelo. Ciò permette di evitare la congestione e il sovraccarico in eccesso.

Spazi di esecuzione riutilizzabili

Se si vuole gestire in modalità remota un determinato gruppo di computer più di una volta, è necessario prendere in considerazione l'utilizzo di spazi di esecuzione piuttosto che di semplici elenchi di nomi computer. In Windows PowerShell, uno spazio di esecuzione è semplicemente un'istanza del motore della shell, sia che l'esecuzione avvenga localmente sul proprio computer come finestra di dialogo della console della shell, sia che avvenga in background su un computer remoto. L'avvio di uno spazio di esecuzione remoto è semplice:

$names = @("server1","server2","server2")
New-RunSpace –computer $names

Poiché gli spazi di esecuzione utilizzano anche Gestione remota Windows, si servono anche della porta 80 (o 443, se viene specificato il parametro UseSSL) per impostazione predefinita. Possono anche accettare credenziali alternative e così via. Se vengono recuperati gli oggetti dello spazio di esecuzione risultanti, è possibile passarli a Invoke-Command e Windows PowerShell invierà il comando ai computer su cui esistono quegli spazi di memoria:

$command = { Get-WmiObject     Win32_OperatingSystem }
$rs = Get-Runspace
Invoke-Command –command $command     –runspace $rs –asjob

Il vantaggio è che, in questo caso, gli spazi di esecuzione rimangono attivi fino a quando la shell è aperta, quindi si possono riutilizzare per comandi aggiuntivi.

Servizio remoto fan-in

Gli spazi di esecuzione rappresentano anche la chiave del servizio remoto fan-in. Ad esempio, la Figura 1 mostra che è stato creato un spazio di esecuzione su un computer remoto, è stato recuperato un riferimento a quello spazio di esecuzione ed è stato utilizzato successivamente il cmdlet Push-Runspace per attivare lo spazio di esecuzione. A questo punto, si eseguono dei comandi sul computer remoto, tipo quelli consentiti dal protocollo SSH o da altre utilità di shell remota. L'esecuzione di Pop-Runspace restituisce il proprio spazio di esecuzione "locale" originale, mentre il prompt della shell aiuta a tenere traccia del punto in cui si è arrivati in qualsiasi momento.

Figura 1 Utilizzo di spazio di esecuzione per eseguire comandi su un computer remoto (fare clic sull'immagine per ingrandirla)

L'esatta sequenza di comandi eseguita è questa:

PS C:\>new-runspace -computer     "WIN-YFZXQMHXAWM"
PS C:\>$server2 = get-runspace -sessionid 2
PS C:\>push-runspace $server2
[win-yfzxqmhxawm]: PS C:\Windows\System32>    pop-runspace
PS C:\>

Tale tecnica è denominata fan-in perché più amministratori possono aprire spazi di esecuzione interattivi remoti sullo stesso server, nello stesso momento: le operazioni si "aprono a ventaglio" dalle singole workstation al server. Un nuovo modello di protezione in Windows PowerShell 2.0 consente di creare shell e cmdlet in numero limitato, impedendo così ad ogni amministratore di apportare modifiche globali e limitandone l'azione alla propria area della shell. (Queste nuove tecniche di protezione richiedono una certa personalizzazione nello sviluppo del software, in un linguaggio destinato a .NET Framework. Ciò va al di là dell'ambito della rubrica di Windows PowerShell, ma è bello sapere che tali funzionalità esistono).

L'applicazione killer nella versione 2.0

La CTP di Windows PowerShell 2.0 ha un elenco di nuove funzionalità sorprendentemente lungo. A mio avviso, l'applicazione rivoluzionaria è il servizio remoto. Tutti gli amministratori, in quasi tutti gli ambienti, possono trarne vantaggio.

Anche voi dovreste familiarizzare con queste funzionalità, in modo da poter offrire i vostri suggerimenti al team responsabile del prodotto. Volete che le porte predefinite di Gestione remota Windows vengano gestite attraverso i Criteri di gruppo? I cmdlet dovrebbero funzionare diversamente? Ci sono problemi a livello di prestazioni? Gestione remota Windows è abbastanza facile da configurare? Potrete svolgere un ruolo attivo inviando i vostri suggerimenti a connect.microsoft.com o condividere commenti e suggerimenti con i vincitori del premio Microsoft MVP, compreso me (per contattarmi, utilizzate i forum su ScriptingAnswers.com). Quindi, lasciatevi coinvolgere e date il vostro contributo per creare l'applicazione killer della prossima generazione di Windows PowerShell!

Cmdlet del mese: Select-Object

Provate questo: Get-Service | ConvertTo-HTML | Out-File Services.htm. Adesso esaminate il file HTML prodotto nel vostro browser Web. Ci sono un bel po' di informazioni, non è vero? Se solo ci fosse un modo per ridurle selezionando le informazioni che ci interessano! Il modo c'è ed è proprio questa la funzione di Select-Object. Ad esempio, poniamo che si voglia solo un elenco di nomi dei servizi ed il relativo stato corrente. Si può utilizzare questo: Get-Service | Select Name,Status | ConvertTo-HTML | Out-File Services.htm.

Una cosa da ricordare è che Select-Object scarta l'oggetto originale (i servizi, in questo caso) e produce un oggetto personalizzato (letteralmente, un oggetto di tipo PSCustom) che contiene solo le proprietà specificate. Tutte le funzionalità dell'oggetto originale non sono più accessibili, quindi probabilmente si vorrà tenere Select-Object alla fine della pipeline, lavorando con l'oggetto originale fino a quando è possibile farlo.

Don Jones è coautore di Windows PowerShell v2.0: TFM e l'istruttore del corso di formazione in aula "Forze speciali" di ScriptingAnswers.com (scriptinganswers.com/training.asp). È possibile contattarlo all'indirizzo jeepdon@mac.com.

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