WSH – Windows Scripting Host
Ogni tanto, durante il mio lavoro, mi capita di dover utilizzare qualche riga di codice VBScript per automatizzare alcuni compiti amministrativi su Windows o su Active Driectory. Resto però sempre colpito dal fatto che buona parte degli amministratori di rete reagiscano con stupore vedendomi operare in questa maniera, per loro si tratta probabilmente di qualcosa che non hanno mai visto fare o di cui non hanno mai sentito parlare. A volte mi domando: è mai possibile che così poche persone sappiano dell'esistenza delle funzionalità WSH fornite dai sistemi operativi Windows? Eppure nei sistemi Linux l'automazione tramite perl script o shell script è una cosa all'ordine del giorno, possibile che siano così pochi gli amministratori di sistemi Windows che si sono chiesti come ottenere simili risultati anche su questa piattaforma?
Cos'è WSH?
Windows Scripting Host è un sistema di scripting indipendente dal linguaggio nato per le piattaforme Windows a 32bit, il fatto che sia indipendente dal linguaggio significa che questa funzionalità permette a Windows di interpretare ed eseguire svariati tipi di linguaggi di programmazione (nativamente però sono supportati soltanto VBScript e Javascript) al fine di poter compiere attività più o meno complesse all'interno del sistema.
La cosa veramente interessante di questo sistema è che è in grado di appoggiarsi agli oggetti WMI (Windows Media Instrumentation), che costituiscono una collezione di specifiche completamente integrate nel sistema operativo che mirano ad essere indipendenti dalla configurazione di quest'ultimo al fine di creare una metodologia che serva a gestire in maniera del tutto uniforme svariati sistemi eterogenei tra loro.
Immaginate per esempio di voler conoscere o cambiare la completa configurazione del protocollo TCP/IP di tutti i client del vostro Dominio Windows, oppure di voler disabilitare un servizio sui computer di una particolare unità organizzativa, o ancora di voler conoscere tutti gli utenti e i gruppi che hanno privilegi di amministrazione locale dei vari client della rete... e tutto questo senza mai dover mettere mano ad un singolo pc e senza interrompere il lavoro degli utenti. Non lo trovate interessante?
Cosa serve per poter utilizzare WSH?
A parte tanta buona volontà... nulla.
WSH è preinstallato e attivo in tutte le seguenti versioni di Windows:
- Windows 98
- Windows 2000 Professional
- Tutta la famiglia Windows 2000 Server
- Tutta la famiglia Windows XP
- Tutta la famiglia Windows 2003 Server
- Tutta la famiglia Windows Vista
- ...
WSH non è quindi preinstallato in Windows 95, Windows NT 4.0 e Windows NT 4.0 Server ma è comunque possibile scaricarne il componente dal sito Microsoft ed installarlo anche su questi sistemi.
Come funziona WSH?
Vediamo di capire come funziona WSH con un banale esempio pratico.
Inanzitutto, per facilitare il vostro lavoro, vi consiglio attivare la visualizzazione delle estensioni per i tipi di file conosciuti. Aprite quindi "Risorse del computer", andate nel menu Strumenti -> Opzioni cartella -> scheda visualizzazione -> scorrete verso il basso la lista delle varie opzioni fino a trovare la voce "Nascondi le estensioni per i tipi di file conosciuti" -> una volta trovata questa voce, assicuratevi che sia deselezionata. Premete il pulsante "Applica" e poi "OK" per chiudere.
Chiudete pure "Risorse del computer" e recatevi sul desktop, posizionate il puntatore del mouse in un punto vuoto qualsiasi del desktop e premete il pulsante destro. Si aprirà un menu contestuale nel quale potrete trovare la voce Nuovo -> "Documento di testo". Così facendo abbiamo creato sul vostro desktop un nuovo file di testo denominato probabilmente "Nuovo Documento di testo.txt" o qualcosa di molto simile, questo file sarà il nostro script WSH. Rinominate il "Nuovo Documento di testo.txt" in "Script.vbs". Una volta rinominato il file si verrà avvisati che modificando l'estensione del file quest'ultimo potrebbe divenire inutilizzabile, scegliete pure "Sì" per continuare.
Come risultato dell'operazione di ridenominazione del file, avendo apposto l'estensione VBS a quest'ultimo, il comune file di testo è diventato a tutti gli effetti uno script WSH e nello specifico un file di VBScript. Lo potete facilmente notare osservandone l'icona. L'estensione del file è fondamentale per il corretto funzionamento del sistema WSH in quanto quest'ultimo stabilirà l'interprete dei comandi da utilizzare basandosi su di essa.
Se al posto della sigla VBS avessimo utilizzato JS come estensione file avremmo ottenuto uno script che verrà interpretato da WSH come Javascript. Potete notare la differenza tra i due file semplicemente osservandone le differenti icone.
Ora però il nostro VBScript è totalmente vuoto, anche se lo mandassimo in esecuzione non compierebbe nessuna azione. Proviamo quindi ad inserire qualche riga di codice, facciamo tasto destro su "Script.vbs" e nel menu contestuale scegliamo la voce "Modifica".
Prima di proseguire con la scrittura del notro script voglio fare un piccolo appunto: vi consiglio vivamente di modificare le preferenze di Notepad abilitando la visualizzazione della barra di stato ed eliminando la funzionalità di "A Capo Automatico". La barra di stato ci aiuterà a capire su quale riga del file ci troviamo nel momento in cui clicchiamo una qualsiasi posizione all'interno del codice dello script, questa funzionalità renderà più agevole l'eventuale identificazione degli errori di codice poiché, nel caso in cui l'interprete vbscript identifichi un problema all'interno del nostro script, questo verrà identificato e segnalato soltanto in base al valore numerico della riga in cui è stato riscontrato.
Una volta entrati in modalità di modifica del file proviamo a scrivere:
msgbox("prova")
Salviamo, chiudiamo notepad e proviamo ad eseguire il file tramite doppio clic.
Il risultato sarà la comparsa di una finestra (messagebox) con la scritta "prova" ed un pulsante OK che una volta premuto causa la chiusura dello script. Il nostro script ha preso forma ed è stato eseguito con successo e senza errori.
Mi rendo perfettamente conto del fatto che questo script di esempio può essere considerato molto banale e forse anche piuttosto stupido ma non è certamente mia intenzione insegnarvi a programmare in vbscript, piuttosto vorrei analizzare con voi gli aspetti più "sistemistici" di quanto è appena accaduto.
Se proviamo ad osservare il Task Manager di Windows quando andiamo ad eseguire lo script, ci possiamo accorgere del fatto che in quel preciso istante viene avviato un nuovo processo che resterà in esecuzione fino al momento in cui non viene premuto il tasto OK causando la chiusura dello script. Questo processo è Wscript.exe, vediamo di capire meglio di cosa si tratta.
"Wscript.exe" costituisce il motore di WSH, è quel programma che si occupa di interfacciare con il sistema operativo le nostre righe di codice. Occorre però far presente che in realtà i motori di WSH sono due: uno è appunto "Wscript.exe" e l'altro invece si chiama "Cscript.exe". Entrambi i file appena menzionati si trovano in "Windows\System32" oppure "WINNT\System32"
Nello specifico: Wscript.exe è GUI-Based e quindi studiato per ricevere input e visualizzare output utilizzando una interfaccia grafica utente (finestre di dialogo, campi di inserimento testo, ...) mentre Cscript.exe è command-line e quindi studiato per essere utilizzato da riga di comando.
Per esempio, alcuni comandi come "Echo", forniranno un output in finestra nel caso in cui stessimo utilizzando Wscript.exe, e quindi avremmo una interazione con l'utente di tipo grafico, ed un output invece testuale in finestra "Prompt dei comandi" quando invece utilizziamo Cscript.exe.
Vi faccio notare anche che Cscript.exe è molto più adatto a pratiche come l'esecuzione remota degli script, ovvero l'upload e l'esecuzione di uno script su di un computer remoto, poiché risulta molto più trasparente all'utente e anche perché supporta l'aggiunta di alcuni parametri di esecuzione direttamente dalla riga di comando (come per esempio la possibilità di impostare la chiusura forzata dello script dopo una quantità di tempo specificata).
C'è da aggiungere infine che Wscript.exe è la versione di WSH che viene caricata in maniera predefinita nel momento in cui ci troviamo ad eseguire uno script tramite doppio clic su di esso (come abbiamo fatto nel nostro esempio), questo proprio perché Wscript, come è stato detto, mira ad essere GUI-based. In realtà il comportamento appena descritto può essere cambiato, se volessimo per esempio che tutti gli script vengano eseguiti da Cscript.exe (anche sul doppio clic) ci basterà eseguire in un prompt dei comandi il seguente comando:
cscript //h:cscript //s
per tornare invece ad avere Wscript.exe come motore predefinito basta eseguire:
cscript //h:wscript //s
Un help sui parametri supportati dalle due versioni di WSH lo potete trovare qui.
Le possibilità di WSH
Col tempo ho imparato che le possibilità offerte da WSH sono più di quante si possa immaginare, nel momento in cui se ne comprendono i limiti si inizia a rendersi conto che molti di essi possono essere bypassati utilizzando programmi di terze parti all'interno degli script. Mi spiego meglio... se vi capitasse per caso di voler lavorare sui permessi NTFS di file e cartelle, vi renderete presto conto che WSH non offre nativamente un grande supporto a questo tipo di attività; a quel punto vi basterà google per trovare in breve tempo programmi come SetACL che, una volta integrati nel vostro script, vi permetteranno di avere pieno controllo delle proprietà di protezione del filesystem in questione.
Per dare una rapidissima sbirciatina ad una parte delle informazioni che potrete manipolare utilizzando WSH vi consiglio di dare un occhiata a Scriptomatic 2.0 di Microsoft (non necessita di installazione, si tratta di un file autoestraente).
Grazie a questo programma possiamo scegliere uno spazio di nomi WMI (provate per esempio root\CIMV2) ed esplorarne tutte le classi predefinite stabilendo così quali potrebbero essere i dati ricavabili da esse. Le interrogazioni di estrapolazione dei dati, che sono prefabbricate ed eseguibili mediante la semplice pressione del tasto RUN, possono produrre un output in molti formati: HTML, PLAIN TEXT, COMMAND PROMPT, EXCEL, XML. Vi faccio notare che anche Scriptomatic è un programma WSH ed è scritto in vbscript, se provate ad aprirne l'eseguibile tramite notepad potrete osservarne il codice.
Altri progetti correlati allo scripting e al WSH
In materia di scripting in ambiente Microsoft esistono altri progetti a mio avviso correlati al WSH, penso sia importante citarne almeno tre:
- HTA: le applicazioni HTA (HTML Applications) sono costituite da righe di codice WSH unite all'HTML, lo scopo è quello di ottenere un semplice eseguibile che possa costituire una basilare applicazione ad interfaccia utente (il motore utilizzato è quello di Internet Explorer) per eseguire particolari attività scriptate all'interno dello stesso. Un esempio di applicazione HTA è Scriptomatic 2.0, al quale ho accennato poco fa; avrete sicuramente notato che il file "eseguibile" di scriptomatic ha come estensione ".HTA", se aprite questo file con notepad potrete visualizzarne il codice e constatare voi stessi quanto vi ho appena descritto. Un'altra applicazione HTA degna di nota è HelpHTA, si tratta di una interfaccia grafica che permette agli amministratori di rete di eseguire con pochissimi clic particolari attività come il listare e terminare i processi e servizi di un PC remoto oppure visualizzarne la completa configurazione e le applicazioni in esso installate.
- WSF: gli script WSF sono script WSH codificati in formato XML. Questo tipo di codifica offre numerosi vantaggi, tra questi: utilizzare diversi linguaggi di scripting all'interno dello stesso script, scrivere codice "riutilizzabile" e la possibilità di richiamare librerie esterne. La codifica di uno script in WSF permette inoltre di usufruire di funzionalità avanzate come la possibilità di renderlo interattivo utilizzando pochissimi tag XML, ovvero: tutti siamo abituati al fatto che i programmi utilizzabili da "prompt dei comandi" restituiscano determinati output informativi nel momento in cui dimentichiamo di inserire una variabile oppure quando digitiamo il carattere "?"; tramite la codifica in WSF è possibile fare in modo che sia il motore stesso ad occuparsi di eseguire questo tipo di controlli senza dover scrivere a mano complicate funzioni che se ne occupino.
- Windows PowerShell: Si tratta di un innovativo prompt dei comandi di Windows che costituisce a sua volta una tecnologia di scripting task-based. All'interno della powershell sono disponibili numerose utilità amministrative oltre che un nuovo motore di scripting, il suo scopo è quello di fornire agli amministratori di rete un potente e avanzato strumento di controllo ed automazione dei prodotti Microsoft. Possiamo considerare powershell come una valida alternativa al WSH, grazie ad essa le funzionalità messe a disposizione da quest'ultimo dovrebbero essere state migliorate; non bisogna però dimenticare il fatto che si tratta di un prodotto ben più complesso da gestire e che inoltre richiede l'installazione nel sistema di numerosi componenti aggiuntivi. E' interessante notare che Microsoft ha pubblicato all'interno della sua Script Repository numerose applicazioni powershell di esempio. Sono disponibili anche repository specifiche di scripts per Exchange 2007 e cmdlets per gestire IIS7, una risorsa interessante di scripts è costituita inoltre dal sito IIS.Net. Infine segnalo anche una guida alla powershell che comprende alcuni virtual labs e webcasts ed un libro (e-book) gratuito scaricabile dal sito Microsoft.
Risorse in rete
La principale risorsa per il WSH è sicuramente "Hey, Scripting Guy!" di Microsoft. Il sito in questione offre molti spunti, spiegazioni e soluzioni a problematiche comuni.
Pagina principale: http://www.microsoft.com/technet/scriptcenter/resources/qanda/default.mspx
Archivio degli scripts suddivisi per categoria: http://www.microsoft.com/technet/scriptcenter/hubs/default.mspx
Degni di nota sono anche due preziosissimi gruppi di discussione che costituiscono un fornitissimo archivio di scripts.
microsoft.public.scripting.vbscript
microsoft.public.scripting.wsh
A costituire un'altro importante archivio di utili scripts è il sito scriptinganswers.com, vi invito a sfogliarne lo ScriptVault.
Il più generico Script Center di Microsoft ci tiene invece informati su tutte le ultime "tendenze" in fatto di scripting in ambiente Windows.
Anche Vbshf.com possiede un forum ricco di spunti interessanti ed inoltre costituisce la homepage dell'utilissimo programma HelpHTA (secondo me è una applicazione che non dovrebbe mai mancare ad un amministratore di rete).
Vi invito infine a visitare la mia sezione scripts.
Autore
Mirko Iodice
mirko -at- notageek (.dot) it
Print This • Email this • Twit This! • Add to del.icio.us • Share on Facebook • Digg This! • Stumble It! • AddThis! • Share on Segnalo Alice • Share on OKNotizie
1 Giugno 2010 alle 9:16
sempre grazie per l'aiuto
non trovo il sw helpHTA se nonviè altro di meglio dove si può reperire?
sani
3 Giugno 2010 alle 20:11
@ diego
ho trovato un vecchio setup di HelpHTA, non so dirti però se sia una delle ultime versioni o meno. L'ho messo online, ecco il link per il download... è il massimo che posso fare.
Io comunque ti consiglio di utilizzare Windows PowerShell per svolgere questo genere di attività, qui sul mio blog puoi trovare della documentazione gratuita in merito all'argomento.
28 Luglio 2010 alle 20:47
ho una pagina asp con del codice vbscript,
funziona , ma su win 7 e ie8 non viene eseguito lo script e la pagina si blocca.
come posso risolvere il problema????
29 Luglio 2010 alle 6:09
@ domenico
Mi dispiace ma non so aiutarti per quanto riguarda l'ASP.
29 Luglio 2010 alle 6:39
secondo me non è un problema di asp ma di configurazione di win 7 o ie8.
è proprio win7 o ie8 a non eseguire gli script di vbscript
24 Gennaio 2012 alle 15:39
Ciao,
io ho un piccolo problema su uno dei miei server: tramite operazioni pianificate lancio un .vbs ogni minuto per fare una operazione ripetitiva all'interno del server.
Il problema è che a volte nel task manager noto un elenco di 50/60 wscript.exe e se provo a stopparli non vengono rilanciarti.
Riesco a terminarli solo quando apro internet exploer che mi richiede di ripristinare l'ultima pagina che ha causato errori, poi chiudo IE e mi fa terminare i processi wscript.exe
Avete suggerimenti da darmi?
Il file .vbs non fa altro che lanciare una richiesta HTTP, esempio:
Dim IE
Set IE = CreateObject("InternetExplorer.Application")
IE.Visible = False
IE.navigate("http://localhost/pagine.asp")
Set IE = Nothing
La mia impressione è che se la pagina genera un errore lo script non riesce mai a terminare il processo.
Grazie,
Matteo.