Windows PowerShellPotenza dei profili

Don Jones

Indice

Shell, host e profili
Utilizzo del proprio profilo?
Creazione di una console personalizzata
Ulteriori suggerimenti sui profili
Attenzione al profilo!

Chi legge regolarmente questa rubrica ormai sa che Windows PowerShell supporta un sistema di profili. Essenzialmente, si tratta di script della shell, con estensione .ps1, che vengono eseguiti automaticamente quando la shell è in funzione. Ad esempio, sono molto utili per la definizione di alias personalizzati. Il profilo può essere impostato in modo che definisca automaticamente gli alias quando la shell è in esecuzione, rendendoli disponibili a ogni utilizzo.

La shell definisce i quattro profili seguenti:

• un profilo applicabile a tutte le shell e a tutti gli utenti del computer;
• un profilo applicabile a tutti gli utenti, ma solo alla shell Microsoft PowerShell;
• un profilo applicabile all'utente corrente e a tutte le shell;
• un profilo applicabile all'utente corrente e solo alla shell Microsoft PowerShell.

Il concetto "tutte le shell" può creare confusione, poiché la terminologia si riferisce a idee relative alle prime fasi di sviluppo di Windows PowerShell non inserite nel prodotto finale. Attualmente, il termine più appropriato è probabilmente "tutti gli host".

Shell, host e profili

Windows PowerShell è una serie di assembly di Microsoft .NET Framework. Di solito definisco questa parte della shell come il motore di Windows PowerShell, poiché contiene la funzionalità che di solito si associa a Windows PowerShell. Non esiste, però, una funzionalità incorporata che consenta agli esseri umani di interagire con il motore: per utilizzare effettivamente la shell, il motore deve essere caricato su un'applicazione host (o sull'host).

L'applicazione powershell.exe che viene eseguita di solito è un host, così come l'applicazione gpowershell.exe inclusa nella Windows PowerShell 2.0 Community Technology Preview (CTP). In realtà, la relazione tra host e shell non è così immediata come viene descritta in questo articolo, ma si tratta comunque di una spiegazione semplificata che ne descrive il funzionamento.

È importante capire che, quando si interagisce con la shell mediante un'interfaccia testuale a riga di comando, si sta probabilmente utilizzando l'host powershell.exe. Ciò accade anche quando si avvia la shell con un collegamento installato da un'altra applicazione, come Exchange Management Shell. Exchange Management Shell non è una shell o una applicazione host diversa, ma semplicemente l'host powershell.exe avviato utilizzando un collegamento che specifica una serie di snap-in e script da precaricare. Gli snap-in attivano la funzionalità di Exchange Management Shell all'interno della shell, ma la shell utilizzata è sempre la stessa.

I percorsi (in Windows Vista) dei profili per l'host powershell.exe sono i seguenti:

• %windir%\system32\Windows­PowerShell\v1.0\profile.ps1: per tutti gli utenti del computer e per tutte le shell;
• %windir%\system32\Windows­PowerShell\v1.0\Microsoft.Power­Shell_profile.ps1: per tutti gli utenti del computer, ma solo per la shell Microsoft PowerShell;
• %UserProfile%\Documents\Windows­PowerShell\profile.ps1: solo per l'utente corrente, ma per tutte le shell;
• %UserProfile%\Documents\WindowsPowerShell\Micro­soft.PowerShell_profile.ps1: solo per l'utente corrente e per la shell Microsoft PowerShell.

I profili non sono predefiniti ed esistono solo se vengono creati.

Ciascuna applicazione host deve caricare ed eseguire il profilo corretto. Se una particolare applicazione host "decide" di non caricare alcun profilo è perché, in realtà, non deve: Il profilo, infatti, non viene eseguito automaticamente dal motore di Windows PowerShell.

Per controllare i profili, il metodo più semplice è aprire la shell, digitare $profile e premere Invio. In questo modo si visualizza il percorso completo che la shell tenta di utilizzare per quello che si può intendere come profilo "principale" (il profilo per il singolo utente e specifico per la shell). È possibile creare e modificare lo script da eseguire a ogni avvio della shell.

Utilizzo del proprio profilo

Come suggerito in precedenza, un utilizzo diffuso del profilo è la definizione di alias personalizzati o l'aggiunta di PSDrive personalizzati (unità connesse che esistono interamente all'interno di Windows PowerShell). Un utilizzo meno comune è la creazione di un tipo di super-shell che può svolgere qualsiasi attività di gestione necessaria, in base ai prodotti software utilizzati nell'ambiente. Per spiegare con precisione il concetto di super-shell, sono necessarie alcune informazioni di carattere generale.

Il gruppo di sviluppo di Microsoft che produce Windows PowerShell si occupa di molte altre tecnologie core di gestione, tra cui Microsoft Management Console (MMC). MMC fornisce un'analogia adatta a spiegare il funzionamento di Windows PowerShell. All'avvio di mmc.exe, viene visualizzata una console vuota che non è molto utile, infatti per creare una console funzionale si aggiungono snap-in di MMC.

Una volta configurata la console nel modo desiderato, è possibile salvarla in un file con estensione .msc, grazie il quale si può ricaricare velocemente la console personalizzata in qualsiasi momento.

Molti amministratori utilizzano le console installate con i prodotti che gestiscono, anziché console MMC personalizzate. Exchange Server, ad esempio, crea una console che contiene solo lo snap-in Exchange Server. Utenti e computer di Active Directory è un'altra console creata in precedenza che contiene un singolo snap-in.

Windows PowerShell funziona secondo lo stesso principio. L'icona di Exchange Management Shell installata con gli strumenti di gestione di Exchange Server 2007 è in realtà un collegamento a powershell.exe con le istruzioni per il caricamento di un file di console. I file di console della shell hanno estensione .psc1 e contengono un elenco di snap-in da precaricare (più o meno come un file .msc contiene un elenco di snap-in che vengono precaricati da MMC). Tuttavia, non si è obbligati a utilizzare le console già esistenti della shell, ma si possono creare console personalizzate (proprio come in MMC) da utilizzare per qualsiasi attività di gestione. I profili assumono un ruolo fondamentale in questa operazione.

Creazione di una console personalizzata

Il primo passo per la creazione di una console personalizzata è l'individuazione del nome completo di ogni snap-in su cui si intende lavorare. Accertarsi che tutti gli strumenti di gestione necessari siano installati sul computer. In seguito, in Windows PowerShell, eseguire il comando Get-PSSnapin –registered per ottenere un elenco di tutti gli snap-in registrati disponibili, ma ancora non caricati e creare o modificare il profilo appropriato di Windows Power­Shell. Inserire i comandi Add-PS­Snapin per caricare gli snap-in che si desidera siano sempre disponibili: si possono includere snap-in per Exchange Server, prodotti System Center e snap-in di terze parti, come PowerShell Community Extensions. A questo punto, salvare il profilo (ricordarsi di aggiungere la firma digitale al profilo, se i criteri di esecuzione di Windows PowerShell lo richiedono) e chiudere la shell. Quando si riapre la shell, vengono caricati automaticamente tutti gli snap-in elencati nel profilo.

Un'altra tecnica consiste nel caricare tutti gli snap-in nella shell (utilizzando Add-PSSnapin e i nomi degli snap-in), quindi eseguire Export-Console per creare un file di console .psc1 con tutti gli snap-in utilizzati attualmente. Questo file può essere quindi utilizzato per creare un nuovo collegamento di Windows PowerShell che specifica il parametro PSConsole­File e il file .psc1 personalizzato. Mediante il collegamento, la console caricherà automaticamente tutti gli snap-in specificati.

Ulteriori suggerimenti sui profili

Io utilizzo un profilo personalizzato di Windows PowerShell per eseguire molte altre attività utili a ogni avvio della shell. Ecco alcuni esempi di ciò accade all'avvio della shell nel mio sistema:

1. Eseguendo il comando Get-Credential per l'account di amministratore di dominio, i risultati vengono memorizzati in una variabile denominata $cred che viene resa disponibile nella shell. In seguito la variabile viene passata al parametro -credential di vari cmdlet, come il cmdlet Get-WmiObject e, poiché $cred memorizza la password, i cmdlet in questione possono essere utilizzati senza che venga richiesto l'inserimento di una password.
2. Eseguendo il comando Cd C:\, la shell si avvia nella directory principale dell'unità C: del computer.
3. Eseguendo il comando New-Alias per Out-File per creare un alias denominato "of", si può utilizzare "of" al posto di "Out-file". Utilizzo spesso questa tecnica, perché è pratico avere un alias breve definito.

Se nel tentativo di creare una chiave di prova nell'unità HKLM: della shell, che rappresenta la porzione HKEY_LOCALE_MACHINE del registro di sistema, si verifica un errore, significa che la shell è stata avviata senza privilegi elevati. Di solito richiedo privilegi elevati per il lavoro che svolgo e questo è un modo rapido per sapere se li ho ottenuti prima di cominciare a lavorare seriamente.

Si può definire una funzione personalizzata denominata Ping-Address che accetta il nome di un computer o un indirizzo IP e restituisce un valore True o False, a seconda che sia possibile eseguire il ping del computer o meno. Nel mio lavoro utilizzo spesso questa funzione, quindi definendola nel mio profilo, diventa disponibile globalmente nella shell.

Cmdlet del mese: Get-WmiObject

Agli osservatori più attenti non sarà sfuggito il fatto che mi sto occupando di un cmdlet che ho trattato in precedenza, ma ora intendo illustrare una caratteristica estremamente utile che esso offre. Spesso gli amministratori tentano di recuperare le informazioni di Strumentazione gestione Windows (WMI) da più computer, i cui nomi sono elencati in un file di testo, utilizzando questa tecnica:

Get-Content c:\computers.txt | ForEach-Object 
  { Get-WmiObject Win32_Service –comp $_ }

Questa tecnica funziona, ma in realtà non è necessaria, in quanto il cmdlet Get-WmiObject accetta un array di nomi di computer per il parametro -computerName. Per ottenere lo stesso risultato, si può quindi utilizzare la tecnica seguente:

Get-WmiObject Win32_Service –comp (Get-Content
  c:\computers.txt)

Se si colloca il comando Get-Content fra parentesi, si obbliga la shell a eseguirlo e a inserire i risultati (un array di nomi di computer) nel parametro -computerName.

Attenzione al profilo!

Powershell.exe non è la sola applicazione che carica profili Microsoft.PowerShell o profili applicabili a tutte le shell. Anche molti ambienti di sviluppo integrati (IDE), che forniscono il supporto per Windows PowerShell (tra cui PrimalScript di SAPIEN Technologies, PowerGUI di Quest Software e PowerShell Plus di ShellTools), caricano gli stessi profili per offrire un'esperienza analoga all'host di powershell.exe.

Un profilo di grandi dimensioni che carica molti snap-in potrebbe causare un avvio più lento di queste applicazioni, perché sono presenti molte istruzioni per il motore Windows PowerShell da eseguire prima che sia pronto per l'applicazione host. Infatti, perfino powershell.exe può impiegare molto tempo ad avviarsi se deve eseguire uno script del profilo molto esteso.

Inoltre, gli snap-in che definiscono cmdlet con nomi identici possono causare conflitti, ad esempio, se due snap-in definiscono un cmdlet denominato Get-User, Windows PowerShell non eseguirà i cmdlet finché non si utilizza il nome completo del cmdlet per specificare quale si intende usare. Il nome completo può creare problemi, poiché i nomi degli snap-in possono essere piuttosto lunghi. In genere, quando si verificano questi errori, evito di far caricare contemporaneamente i due snap-in, caricando solo quello che utilizzo più spesso nel mio profilo e, se necessario, utilizzando una shell separata per caricare l'altro.

I profili di Windows PowerShell possono aggiungere molti vantaggi alla shell ma, se modificati in modo dannoso da malware, possono provocare seri danni. Si può proteggere il proprio profilo aggiungendo una firma digitale e configurando i criteri di esecuzione di Windows PowerShell su AllSigned oppure modificando tutti i permessi del file NTFS, per evitare che un account utente normale possa modificarli.

Don Jones è l'autore di Windows PowerShell: TFM and VBScript, WMI, and ADSI Unleashed. È possibile contattarlo tramite il sito Web PowerShellCommunity.org.