Configurazione dell’oggetto WSHRemote in Windows 7/2008 R2.
Salve a tutti.
Mi sono imbattuto in questi giorni in un caso un pò particolare. Ho deciso di riportare la mia esperienza per salvare la giornata di qualcuno che si imbattesse in questo, visto che mi è costato ore di tracing e prove.
Il Windows Scripting Host, dalla versione 5.6 in poi, contiene una piccola e quasi sconosciuta feature, che permette l’esecuzione di script su macchine remote.
Il tutto avviene utilizzando DCOM. La macchina client, crea un oggetto di tipo WSHRemote, che si collega via DCOM alla macchina server e là crea una istanza di se stesso, e sempre via DCOM ritorna sulla macchina client (o va su una share di rete) a leggere lo script da eseguire sul server.
Su XP funziona sempre al primo colpo, ma se il server è una macchina Windows 2008 R2 e il client WIndows 7, ci sono un pò di passi di configurazione da fare, in quanto di default questi sistemi hanno più restrizioni di sicurezza.
Procedura passo passo.
1) l’oggetto WSHRemote deve essere registrato nel sistema per poter essere usato. Quindi primo passo:
Wscript.exe /regserver
C’era anche un BUG su XP..
311269 BUG: You receive an "ActiveX component can't create object" error message when you Use Windows Script Host to execute remote script
http://support.microsoft.com/default.aspx?scid=kb;EN-US;311269
2) L’oggetto WSHRemote va abilitato sia localmente che remotamente, in quanto deve essere istanziato su entrambe le macchine da remoto. Questo si fa nel registry. Bisogna creare un nuovo valore di tipo String sotto la chiave:
HKLM\Software\Microsoft\Windows Script Host\Settings
Il nuovo valore deve chiamaris “Remote” e deve essere impostato a “1”.
3) Configurazione DCOM.
Gli oggetti registrati in DCOM possono avere una loro impostazione specifica di sicurezza, oppure possono usare i Default del sistema. Quindi dobbiamo verificare la configurazione per li nostro oggetto WSHRemote e anche i valori di default. Considerato che l’esecuzione di script remoti su un altra macchina è da ritenersi un compito amministrativo, è corretto dare solo ai Domain Admins questo privilegio, oppure a specifici account usati per la gestione della rete.
Lanciamo quindi DCOMCNFG e andiamo a controllare le Security permisison dell’oggetto WSHRemote.
Se è tutto impostato a Use Default, dobbiamo controllare i system default della macchina. In particolare, verifichiamo che Access Permission e Launch and Activation Permission, siano impostati a Allow per Remote Access, Remote Activation e Remote Launch per gli appertenenti al gruppo Administrators
Ovviamente DCOM deve essere abilitato sulla macchina, quindi verifichiamo anche, oltre alla COM Security, le Default Properties.
Questa configurazione deve essere fatta sia sul client che sul server.
4)Firewall. Il Windows Scripting Host deve essere abilitato a passare dal Firewall. Quindi aggiungiamolo alle eccezioni.
Aggiungete wscript.exe alle eccezioni sia sul client che sul server.
5)Group Policy.
Questa è la parte forse meno documentata ed è stata infatti quella che ha risolto effettivamente il problema. Non basta configurare DCOM sulle macchine con il DCOMCNFG. Esistono anche due policy che vanno configurate:
DCOM: Machine Access Restrictions in Security Descriptor Definition Language (SDDL) syntax
DCOM: Machine Launch Restrictions in Security Descriptor Definition Language (SDDL) syntax
Lanciate GPEDIT.MSC e navigate l’albero alla sinistra fino a Computer Configuration, Windows Settings, Security Settings, Local Policies, Security Options.
Qui trovate le due Policy riguardanti DCOM. La più importante delle due è DCOM: Machine Access Restrictions.
Quando l’oggetto WSHRemote viene creato sulla macchina remota, quello tenta di accedere indietro sulla macchina da cui è stato creato, ma si presenta evidentemente con l’account della macchina remota, che viene percepito come Anonymous dalla macchina client. Bisogna quindi abilitare Remote Access per l’Anonymous Logon. Questo potrebbe essere un problema di sicurezza, quindi valutate attentamente i benefici che vi da la possibilità di eseguire script remotamente contro i rischi di sicurezza che ne derivano.
Script di esempio.
'Remote.wsf
'==========
<package>
<job>
<script language="VBScript">
set oController = CreateObject("WSHController")
set oProcess = oController.CreateScript("beenhere.wsf", "Your_Server_Name")
oProcess.Execute
While oProcess.Status <> 2
WScript.Sleep 100
WEnd
WScript.Echo "Done"
</script>
</job>
</package>
'BeenHere.wsf
'============
<package>
<job>
<script language="VBScript">
set fso = CreateObject("Scripting.FileSystemObject")
set fout = fso.CreateTextFile("c:\beenhere.txt", true)
fout.WriteLine Now
fout.Close
</script>
</job>
</package>
Salvate i due script nella stessa cartella ed esguite Remote.wsf. Se tutto funziona, dovreste trovare sul disco C della machcina remota un file chiamato beenhere.txt contenente l’ora e il giorno in cui avete eseguito questo script.
Conclusioni.
Valutate bene pro e contro soprattutto legati alla sicurezza prima di utilizzare l’oggetto WSHRemote. Se ritenete che l’esecuzione di script remoti sia una cosa che può portarvi dei benefici, che vi da quindi un valore aggiunto, quelli sopra riportati sono i passi di configurazione necessari per Windows 7/2008 R2.
Alla prossima!
Senior Support Engineer
Platform Development Support Team