Dit artikel is eerder verschenen in 'Windows en Netwerken', editie oktober 2000
De Windows Script Host – baas boven batch
Om
een systeem fatsoenlijk te kunnen beheren is het nodig om allerlei aspecten op simpele wijze te kunnen automatiseren. Systemen als Unix, VMS, MVS, OS/2, enz. hebben hier van oudsher geen problemen mee gehad, maar de Microsoft
systemen hebben het moeten doen met het van DOS meegekregen Batch. Hoewel geschikt voor de wat meer simpele taken heeft Batch niet de tand des tijds weerstaan. Batch bezit een aantal belangrijke tekortkomen die in de laatste
versies van Windows NT wel enigszins zijn ondervangen maar dit blijft toch een (spreekwoordelijk) doekje voor het bloeden. Batch blijft beperkt tot simpele scripts waar niet al te veel intelligentie in gebouwd hoeft te worden. Dit
is jammer omdat, zeker voor beheerders scripting van onschatbare waarde is gebleken. Microsoft heeft de toepassing van scriptalen altijd onderschat waardoor er al jaren door bedrijven of open source organisaties aan alternatieven
wordt gesleuteld. Voorbeelden hiervan zijn winbatch, Perl en Kixtart. Waarom is scripting zo belangrijk zult u zeggen, je kunt toch altijd een programma schrijven? Het schrijven van programma's heeft echter een aantal nadelen : Ze
zijn niet in leesbare vorm aanwezig zijn op de productie systemen zodat je ze niet op werking kunt controleren. Het langer duurt om aanpassingen door te voeren omdat de toepassingen speciaal gecompileerd moeten worden en de
gebruikte programmeertaal – zoals C++ – leent zich vaak niet optimaal voor beheerstoepassingen. Scripts daarentegen zijn direct en ter plekke aan zijn te passen, en de gebruikte scripttaal is beter geschikt voor
beheerstoepassingen, zoals bijvoorbeeld het aanmaken van een netwerkdrive. Voordelen van Scripting zijn vooral te vinden in het snel kunnen creëren en makkelijk aan kunnen passen als wel het hergebruiken van code. Toepassing
hiervan vind je dan ook veel in:
De laatste tijd is de houding Microsoft richting scripting van beleid veranderd, wat geleid heeft tot de ontwikkeling van Windows Scripting Host (WSH). De basis van hiervan is terug te leiden tot Internet Explorer 3. Het
gaat hier om ActiveX scripting,, een interface waarmee diverse scriptalen kunnen communiceren met applicaties. Van oorsprong was dit internet explorer waarmee vanuit een DHTML pagina code uitgevoerd kon worden in de browser van een
client en later ook in Internet Information Server. De architectuur van systeem beperkte de scripts wel in hun mogelijkheden, met name omdat internet explorer scripts maar beperkte interactie kunnen hebben met het systeem.
Om als een vervanging van Batch te kunnen dienen moesten scripts in staat zijn om ook interactiever te worden anders zijn ze nutteloos voor de toepassingen waar Batch nu juist voor bedoeld is. Door nu WSH te ontwikkelen als
applicatie die activeX scripting ondersteund werd er een wereld aan mogelijkheden ontsloten voor de scriptalen die ActiveX ondersteunen. In eerste instantie begonnen als add-on applicaties zijn de scripting interfaces nu een
geïntegreerd onderdeel van het operating system. De WSH komt standaard mee in alle versies van Windows 2000, Windows 98 en ME en is ook als update voor Windows 95 en Windows NT4 gratis de dowloaden bij Microsoft.
Het gereedmaken van clientcomputers voor gebruikt, drivemappings maken, installaties uitvoeren en andere aanpassingen aan de werkomgeving maken.
Automatisch genereren van accounts, bijvoorbeeld aan de hand van de personeelsdatabase. Automatiseren van processen zoals Backups.
Figuur 1: De scriptinterfaces in windows
Standaard levert microsoft twee talen die ActiveX ondersteunen, VBScript en JScript. Het is echter zonder meer mogelijk om andere talen te gebruiken, zoals bijvoorbeeld Perl, Python of Rexx.
Eén van de belangrijkste ActiveX scripting engines is VBScript. VBScript is afgeleid
van Visual Basic en is in feite een soort 'baby basic'met slechts een deel van de functionaliteit van VB. Dit heeft ook alles met het design van ActiveX scripting te maken. Het is ontworpen om te draaien vanuit
een webbrowser en is daardoor beperkt in zijn methoden om interactie met de buitenwereld aan te gaan, het genereren van een simpel piepje uit de PC speaker kan al een behoorlijk karwei betekenen. Dat wil echter niet zeggen dat
VBScript niet krachtig zou zijn, doordat in principe van alle ActiveX componenten gebruik gemaakt kan worden en door WSH beschikbaar gestelde interfaces kunnen behoorlijk geavanceerde scripts worden gegenereerd. Het is
de moeite waard om de systeem interactie die door WSH mogelijk wordt gemaakt nader te belichten. Er zijn verschillende objecten –providers – die aspecten van het systeem vertegenwoordigen. Neem bijvoorbeeld de Active
Directory Services Interface (ADSI) provider, die de verbinding met alle directory services mogelijk maakt. Dit zijn natuurlijk Microsoft's eigen Active Directory en Windows NT, maar ook Novell's NDS of Lotus Notes. Alle objecten
die door deze directory services geexporteerd worden zijn te benaderen met ADSI. Denk aan accounts, mailboxen, AD details etc. Het is bijvoorbeeld prima mogelijk om met ADSI een server tot Domain Controler te promoveren. Naast de
ADSI provider is ook de WMI provider erg interessant. Deze provider verzorgt de toegang tot eigenschappen van allerlei systeem objecten zoals drivers, harddisks, processen, etc. Dit is natuurlijk heel krachtig voor systems
management activiteiten, en WMI wordt en zal ook steeds meer ingebouwd worden in producten zoals HP openview, Tivoli en SMS. De meest gebruikte provider echter is de standaard Script Host provider. Deze geeft toegang tot het
filesysteem, register, de commandline, etc. Ook is toegang tot alle op het systeem aanwezige applicaties mogelijk, zolang deze tenminste COM-enabled zijn. Dit betreft vrijwel alle grote en veel kleinere applicaties zoals Office,
Explorer, Notepad, etc. Deze applicaties zijn dan aan te roepen alsof het extensies van de WSH zijn. Een simpel voorbeeld zou kunnen zijn om een inventarisatie met WMI te maken, en Word te gebruiken om er een net document van te
maken het te printen. Als de bestaande functionaliteit niet voldoende is dan kan deze onbeperkt uitgebreid worden met zelf ontwikkelde COM objecten. COM objecten zijn niet afhankelijk van programmeertaal, en kunnen zelfs met de WSH
zelf gemaakt worden. Windows Script Host bestaat in twee vormen, cscript.exe en wscript.exe. Ze zijn functioneel equivalent, maar cscript.exe is commandline georiënteerd en geeft zijn uitvoer naar een shell window, en
wscript.exe geeft zijn uitvoer in popup windows. WSH scripts hebben geregistreerde extensies zoals .vbs voor VBScript, .js voor JavaScript, etc. Deze extensies zijn standaard verbonden met wscript.exe. Dus als een script wordt
gestart door te dubbelklikken zal wscript.exe gebruikt worden om het script uit te voeren. Een andere interessante functionaliteit van de WSH is de mogelijkheid om scripts te versleutelen. Dit kan prettig zijn wanneer er
gevoelige informatie in een script zichtbaar is of in een klant-leverancier relatie waarbij de broncode niet wordt overgedragen. Wanneer de versleutelde code wordt uitgevoerd zal WSH de file eerst intern decoderen voordat hij aan
de eigenlijke VBScript interpreter wordt aangeboden. Let wel, er is hier geen sprake van echte encryptie. Iemand met diepgaande kennis van zaken is in staat een versleuteld script te decoderen. Om de kracht van
scripting te demonstreren zullen we U een aantal voorbeelden laten zien wat sleutelelementen van scripting inzichtelijk maakt. In figuur 2 ziet u een eenvoudig loginscript wat een aantal netwerkverbindingen aanlegt en controleert
of deze zijn gelukt. Een aantal belangrijke elementen komt hier gelijk naar voren die het verschil tussen WSH en Batch gelijk duidelijk maken. We zien het gebruik van een subroutine, het creëren van een object en de afhandeling van
mogelijke fouten. Dit zijn nu precies een aantal beperkingen waar een batchprogrammeur tegen aanloopt.
Const ERR_DRIVE_IN_USE = -2147024811`
'We gaan nu een aantal netwerkverbindingen maken waarbij we een subroutine inschakelen
Maakschijf "H:", "
Maakschijf "I:", "\\Server01\Data"
'De nu volgende subroutine maakt de netwerkverbinding aan
Sub Maakschijf (Schijf,Pad)
'Hieronder creeeren we het object wat we nodig hebben voor netwerktoegang.
Dim Netwerk,, bericht, shell
Set Netwerk = wscript.Createobject("wscript.network")
'Neem de foutcontrole over
On error resume next
Netwerk.mapnetworkdrive schijf, pad
If Err.number <> 0 then
If Err.Number = ERR_DRIVE_IN_USE Then
Bericht = "Schijf"& Schijf & " " & "kon niet verbinden met " & Pad & " omdat er al een verbinding was"
Else
Bericht = "Schijf"& Schijf & " " & "kon niet verbinden met " & Pad & " vanwege fout: " & Err.Description
End if
Set shell = wscript.createobject ("Wscript.shell")
Shell.popup Bericht
End if
End sub
figuur 2, login.vbs
