WSH – Windows Scripting Host
(Tratto da: http://www.notageek.it/wsh-windows-scripting-host.html di Marco Iodice)


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:

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

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”.

Se al posto della sigla VBS avessimo utilizzato JS come estensione del file avremmo ottenuto uno script che verrà interpretato da WSH come Javascript.

Ora però il nostro VBScript è totalmente vuoto quindi se lo mandassimo in esecuzione non compirebbe nessuna azione. Proviamo quindi ad inserire qualche riga di codice: facciamo tasto destro su “Script.vbs” e nel menu contestuale scegliamo la voce “Modifica”.

Una volta entrati in modalità di modifica del file proviamo a scrivere:

 
msgbox("prova")

Salviamo, chiudiamo il notepad e proviamo ad eseguire il file tramite un 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.

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.

I motori di WSH sono due: uno è “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 è Windows-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 Windows-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 correlati al WSH. Ne elenchiamo tre: