Windows PowerShellApprofondimenti
Don Jones
In Windows PowerShell è disponibile una gamma completa di funzionalità, che vengono spesso trascurate dalla maggior parte degli amministratori. Tuttavia, a un'analisi più approfondita, risulterà chiaro come alcune funzionalità siano davvero interessanti. Infatti, mi è capitato spesso di scoprire nuove funzionalità associate a uno specifico cmdlet che pensavo di conoscere già.
Quando tengo i miei corsi su Windows PowerShellTM, consiglio sempre agli amministratori di creare un calendario con il cmdlet del giorno, simile al calendario con la parola del giorno. In tal modo, ogni mattina (esclusi i weekend naturalmente), possono dedicare alcuni minuti ad approfondire la conoscenza delle funzionalità complete di un cmdlet. Windows PowerShell comprende circa 130 cmdlet, il che implica che, seguendo pedissequamente il calendario, sarà possibile arrivare a conoscere praticamente tutte le funzionalità di Windows PowerShell in soli sei mesi. A quel punto, si sarà pronti per utilizzare tutti i cmdlet di Exchange Server 2007.
Nell'articolo di questo mese verranno forniti alcuni esempi delle potenzialità che è possibile scoprire e dei risultati che si possono ottenere dedicando alcuni minuti all'esplorazione delle funzionalità più nascoste di diversi cmdlet.
Report HTML dall'aspetto più accattivante
Un cmdlet non utilizzato di frequente è ConvertTo-HTML. Questo cmdlet è in grado di accettare un insieme di oggetti di input, ovvero servizi, processi, oggetti di Windows® Management Instrumentation (WMI) e così via, e di convertirli in una tabella HTML. È possibile quindi inviare la tabella HTML a Out-File ottenendo, in tal modo, una pagina HTML adatta per la pubblicazione su un server Web Intranet. È possibile, ad esempio, configurare la semplice riga di codice riportata di seguito in modo che venga eseguita ogni mattina:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML | Out-File C:\ServiceAlert.html
Si creerà così un report HTML, come quello illustrato nella Figura 1, dei servizi che devono essere avviati automaticamente ma che non sono in esecuzione.
Figura 1** Report HTML dei servizi non eseguiti **(Fare clic sull'immagine per ingrandirla)
È possibile, ovviamente, che si desideri creare un report dall'aspetto più accattivante. Per fortuna, il cmdlet ConvertTo-HTML cmdlet produce un report HTML pulito, ovvero non incorpora alcuna formattazione nel codice HTML creato. In base alle regole HTML, è preferibile evitare di inserire un'eccessiva formattazione nel codice HTML. È consigliabile invece inserire la formattazione in un foglio di stile CSS esterno e collegare CSS al report HTML. Si può creare tale collegamento mediante il cmdlet ConvertTo-HTML.
Il foglio di stile CSS viene collegato alla sezione <HEAD> di un file HTML. Esaminando le informazioni della Guida relative al cmdlet ConvertTo-HTML, si noterà che la sintassi include alcuni parametri che potrebbero essere stati trascurati:
ConvertTo-Html [[-property] <Object[]>]
[-inputObject <psobject>] [-body <string[]>]
[-head <string[]>] [-title <string>] [<CommonParameters>]
Il parametro –head consente di specificare codice HTML aggiuntivo da inserire nella sezione <HEAD> dello script. A questo punto, è possibile modificare facilmente la singola riga di codice sopra illustrata, in modo che venga collegata a un file CSS esistente che contiene la formattazione da applicare alla tabella HTML:
Gwmi Win32_Service | Where { $_.StartMode
–eq "Auto" –and $_.State –ne "Running" } |
ConvertTo-HTML -title "Services" -head "<link
rel='stylesheet' href='styles.css' type='text/
css' />" | Out-File C:\ServiceAlert.html
In questo caso il parametro –head viene utilizzato per inserire un collegamento a un file CSS che si trova nella stessa cartella del file HTML di output. Viene inoltre utilizzato il parametro –title per impostare il titolo della pagina Web. Il risultato è illustrato nella Figura 2. Il testo del file Style.CSS utilizzato è simile al seguente:
Figura 2** Report HTML formattato con un file CSS **(Fare clic sull'immagine per ingrandirla)
body { background-color:#EEEEEE; }
body,table,td,th { font-family:Tahoma; color:Black; Font-Size:10pt }
th { font-weight:bold; background-color:#CCCCCC; }
td { background-color:white; }
Filtraggio semplificato
Cmdlet del mese
Questo mese si esamineranno due cmdlet: Start-Transcript e Stop-Transcript. Entrambi i cmdlet vengono utilizzati per controllare la registrazione delle trascrizioni di Windows PowerShell, che prevede la scrittura in un file di testo specificato di tutte le informazioni presenti nella finestra della console. Si tratta di un'operazione piuttosto semplice. Innanzitutto, eseguire il cmdlet Start-Transcript e assegnargli un nome. Eseguire quindi Stop-Transcript per terminare la registrazione e chiudere il file. Questo è un metodo efficace per passare dall'utilizzo di shell ad-hoc all'esecuzione di script formali: quando si iniziano a utilizzare singole righe di comando nella shell, è possibile copiarle e incollarle dal file delle trascrizioni creato. È possibile ovviamente modificare la trascrizione nello script effettivo. Jeffery Hicks, un Microsoft MVP, ha scritto uno script che consente di analizzare le trascrizioni e di convertirle in file PS1 di Windows PowerShell. Questo script è disponibile all'indirizzo blog.sapien.com/current/2006/11/28/powershell-transcripts.html.
Ecco ora il cmdlet Get-WMIObject. La sintassi di questo cmdlet, riportata nella Guida incorporata di Windows PowerShell, fa riferimento a funzionalità finora ignorate:
Get-WmiObject [-class] <string> [[-property]
<string[]>] [-namespace <string>]
[-computerName <string[]>] [-filter <string>]
[-credential <PSCredential>]
[<CommonParameters>]
Un errore comune che i nuovi utenti di Windows PowerShell commettono, consiste nell'eseguire una riga di comando WMI simile alla seguente:
Gwmi Win32_NTLogEvent –comp Server2
Questo comando consente di recuperare le voci del registro eventi da Server2, ovvero tutte le voci del registro eventi. Tuttavia, se si utilizza questo comando, il processo di elaborazione e trasmissione delle voci del registro eventi da parte di Server2 e l'utilizzo in Windows PowerShell di un numero così elevato di eventi potrebbero richiedere molto tempo.
Un approccio più efficace consiste nel configurare Server2 in modo che vengano individuati e inviati solo gli eventi a cui si è effettivamente interessati. A tal fine, è possibile utilizzare una query WQL (WMI Query Language, linguaggio di query WMI). Alcuni considerano la sintassi di questa query piuttosto difficoltosa, ma Windows PowerShell consente di specificare solo la parte di una query WQL relativa all'applicazione di filtri, utilizzando il parametro –filter:
Gwmi Win32_NTLogEvent –comp Server2 –filter "EventIdentifier=1024"
Questo parametro consente di recuperare tutti gli eventi, da qualsiasi registro, con l'ID evento 1024. Si noti come i criteri di filtro prevedano l'utilizzo dell'operatore di confronto = anziché dell'operatore –eq di Windows PowerShell. questo avviene perché il filtro viene passato al servizio WMI del computer remoto per l'elaborazione e, pertanto, è necessario che i criteri utilizzino la sintassi WMI, non la sintassi di Windows PowerShell.
Un parametro –filter è disponibile anche in altri cmdlet, come Get-ChildItem, il cmdlet a cui sono associati alias come Dir e Ls. Nella maggior parte dei casi il parametro –filter passa i criteri di filtro direttamente alla tecnologia sottostante, dando luogo al cosiddetto filtro all'origine, un'operazione in genere molto più rapida rispetto al processo che prevede la raccolta di tutti gli oggetti e l'esecuzione di tali oggetti tramite il cmdlet Where-Object, in modo da filtrare quelli non ritenuti necessari.
Cmdlet trascurati
Questo approccio all'esplorazione dei cmdlet che prevede l'analisi delle funzionalità di un cmdlet al giorno consentirà senza dubbio di approfondire la conoscenza dei cmdlet con cui si ha già una certa dimestichezza. Tuttavia, un'altra ragione valida per creare un calendario con il cmdlet del giorno è evitare di trascurare completamente cmdlet che non si conoscono affatto. Uno dei miei preferiti è il cmdlet Resolve-Path. Dato un percorso con caratteri jolly, questo cmdlet restituisce un insieme di nomi di file e cartelle che corrispondono al percorso. È simile al cmdlet Get-ChildItem (meglio noto con l'alias Dir o Ls) ma, anziché restituire tutti gli oggetti di un file o una cartella, restituisce semplici stringhe che possono essere trasmesse ad altri cmdlet per un ulteriore filtraggio o elaborazione. L'utilizzo di questo cmdlet è piuttosto semplice:
Resolve-Path C:\P*
In questa semplice riga vengono restituiti percorsi come C:\Program Files, C:\Processes.txt e così via. Nella Figura 3 vengono illustrati due esempi di utilizzo di questo cmdlet.
Figura 3** Utilizzo di Resolve-Path, un cmdlet utile ma trascurato **(Fare clic sull'immagine per ingrandirla)
Punto di partenza
Una volta individuato il cmdlet del giorno da esplorare, eseguire Gcm, un alias per Get-Command. Verrà restituito un elenco di tutti i cmdlet disponibili in Windows PowerShell, inclusi quelli aggiunti tramite gli snap-in, come Exchange Server 2007 Management Shell, PowerShell Community Extensions e così via. Selezionare il primo cmdlet dell'elenco, nel caso dell'esempio Add-Content, e accedere alle informazioni della Guida disponibili per il cmdlet in questione:
Help Add-Content –full
È opportuno leggere la Guida completa, anziché quella predefinita, che è molto più sintetica, in modo da ottenere una descrizione dettagliata delle funzioni di ciascun parametro, visualizzare alcuni esempi di utilizzo dei cmdlet e individuare altre utili informazioni. Dedicare un po' di tempo all'utilizzo del cmdlet. È consigliabile evitare di esercitarsi nell'ambiente di produzione e utilizzare magari un computer virtuale. È opportuno riservare all'esplorazione dei cmdlet 10 minuti al giorno, preferibilmente alla stessa ora ogni giorno in modo che diventi un'abitudine. Nel giro di pochissimo tempo, si acquisirà una conoscenza approfondita di tutte le funzionalità offerte da Windows PowerShell.
Don Jones è il guru degli script di SAPIEN Technologies e coautore di Windows PowerShell: TFM (SAPIEN Press, 2007). È possibile contattarlo all'indirizzo www.ScriptingAnswers.com.
© 2008 Microsoft Corporation e CMP Media, LLC. Tutti i diritti riservati. È vietata la riproduzione completa o parziale senza autorizzazione.