Forord
Baggrund
Via mit daglige arbejde med IT-drift har vi flere gange haft behov for at kunne automatisere i Windows-systemer.
Det gør vi allerede på andre platforme med værktøjer som ca7, unicenter og REXX.
Med version 5.6 af Windows Scripting Host (WSH) er der kommet rigtig gode muligheder for automatisering, hvilket er baggrunden for vores øget fokus på WSH og Visual Basic Scripting Edition (VBScript) samt emnevalget, hvor jeg gerne vil se på mulighederne med og anvendeligheden af VBScript.
Afgrænsning
VBScript kan bruges til mange forskellige opgavetyper, for eksempel System Management.
I dén sammenhæng er det specielt Windows Management Instrumentation (WMI), der er interessant.
WMI tilgåes ved hjælp af Common Object Model (COM). COM kan også bruges til at tilgå Active Directory Service Interface (ADSI), men det vil jeg ikke behandle i denne tekst, da jeg ikke har erfaring med Active Directory.
Generelt har jeg koncentreret mig om triumviratet WSH, VBScript og WMI.
Visual Basic Scripting Edition (VBScript)
Kort beskrivelse
VBScript er et scriptsprog, der kan anvendes i flere forskellige Microsoft miljøer som for eksempel Windows, Internet Explorer og Internet Information Server.
Som andre scriptsprog har VBScript nogle umiddelbare fordele:
- Et script kan skrives på få minutter.
- Et script kan skives med ikke andet end en basal teksteditor, for eksempel NotePad. Selv foretrækker jeg UltraEdit.
- Et script kan skrives uden brug af header-filer, oversættere og andre udviklingsspecifikke værktøjer.
Syntaksen til VBScript ligner meget andre former for Visual Basic, specielt Visual Basic for Applications (VBA), så indlæringskurven kan blive ret stejl, blandt andet fordi erfaringer nemt kan overføres.
Sammenligning med andre udgaver af Visual Basic
- VBScript håndterer ikke forskellige datatyper: Alt er af typen Variant.
- VBScript er ikke oversat. Dette er generelt for scriptsprog.
- VBScript understøtter ikke tidlig bind. Da sproget er et rent fortolkersprog, er alle bindinger sene (late-bound). Dette giver en noget lavere ydelse end for eksempel Visual Basic (VB) eller C#.
- VBScript kan ikke modtage navngivne parametre. Dog er det muligt at scripts lavet i VBScript kan modtage navngivne parametre.
- VBScript har ikke noget integreret udviklingsmiljø (IDE). Der bruges en almindelig teksteditor som for eksempel Notepad eller UltraEdit til at skrive scriptet i.
Sammenligning med Microsoft kommandolinje–miljøer
Til og med Windows Me var kommandolinje-miljøet command.com, hvor man enten afvikler kommandoer og programmer direkte eller i .bat-filer.
Med Windows NT 3.51 kom muligheden for at afvikle .bat-filer og command.com via Virtual Dos Machine (VDM) eller afvikle .cmd-scripts direkte til Windows NT ved hjælp af cmd.exe - der er fuldt kompatibel bagud med command.com.
Til og med Windows NT 4.0 indeholdt standardinstallationen en komplet filsamling fra MS-DOS 6.22. Som regel blev systemet sat op til at afvikle .bat-filer med cmd.exe på grund af mere stabil afvikling af scripts og højere hastighed.
Med Windows 2000 og den nye Windows NT 5.0 kerne forsvandt command.com og antallet af kommandoer i cmd.com blev udvidet markant. Men stadig er der meget langt op til mulighederne i VBScript — på den anden side har vi (som mange andre Windows–miljøer) mange cmd-scripts, der på fuldt tilfredsstillende vis løser konkrete opgaver. Disse cmd-scripts kan stadig benyttes, også med VBScript ved hjælp af WSH WshShell-metoden Exec.
Overførsel af værdier
Almindeligvis overføres argumenter til funktioner og procedurer (sub) ved reference, men det er muligt at forcere en overførsel ved værdi.
Dette kan (ligesom ved andre programmeringssprog) bruges til at returnerer flere værdier fra en funktion, eventuelt altid lade funktionens returværdi være en fejlkode (ErrorNumber), men det er sjældent brugt.
Oversigt over teknologier
Windows Script Host (WSH)
WSH
er et adminstrativt værktøj fra Microsoft der giver et miljø for hosting scripts.
Forudsætningen for at kunne fremstille og afvikle anvendelige scripts på Windows-platformen er en opdateret WSH installeret på den enkelte maskine.
Der findes andre script hosts end WSH i Windows–miljøet, for eksempel Internet Explorer, Internet Information Server (IIS) ved Active Server Pages (ASP), Windows shell ved cmd.exe eller tredieparts hosts som ObjectREXX eller ActivePerl.
Graden af integration til Windows og specielt mulighederne for at koble op mod WMI er meget forskellige – men i forbindelse med denne tekst har jeg koncentreret mig om VBScript.
Figur 1. Grundlæggende komponenter i Windows Script Host miljøet [Scripting Team].
Filtyper for scripts er typisk:
- .vbs = enkelt VBScript script uden import.
- .js = enkelt JScript script uden import.
- .wsh = egenskaber for en script fil.
- .wsf = Windows Script File. Script project formateret med Extensible Markup Language (XML) med mulighed for import, flere script engines, type libraries og flere jobs i samme fil.
- .inc = import-fil (include).
- .wsc = Windows Script Component. Common Object Model (COM)-komponent skrevet i XML-format. COM er nærmere beskrevet senere.
- .tlb = Script Component Type Library. Indeholde oplysninger om et script komponent interfaces og medlemmer (members).
Et Type library er oftest nødvendigt for at kunne tilføje hændelser (events) til et script komponent.
- .hta = HTML Applikation. Script formateret med XML til kørsel med Internet Explorer (IE) men i en anden proces (Mshta.exe) som ligger uden for IE's sikkerhed. Det giver nogle muligheder, for eksempel at afvikle WMI kald uden at blive spurgt om det er i orden.
Et script oversættes af:
- CScript.exe = afvikling af script i kommandolinje-miljø.
- Wscript.exe = afvikling af script i Windows-miljø.
Det mest almindelige er .vbs-scripts der som standard i Windows afvikles ved hjælp af Wscript.exe. Selve logikken og afviklingen håndteres af WSH.
Figur 2. WSH Object Model Diagram [Scripting Team].
Hvert af de tre objekter WshController, WshNetwork og WshShell har deres egen objekt model med objekter, metoder, attributter (properties) og hændelser (events).
Sikkerhed
Med version 5.6 af WSH blev det muligt at signere scripts, og sikre at kun korrekt signeret script bliver afviklet. Dette kræver en enkelt ændring i registreringsdatabasen på de maskiner scripts skal afvikles på.
Desuden er det muligt at begrænse afviklingen af script ved at ændre registreringsdatabasen for filtyperne til WSH scripts. Dette er dog noget risikabelt, og skal gøres efter en del overvejelser og med stor omhu.
Common Object Model (COM)
Der findes to former for implementering af en COM-server:
-
Out-of-process: Typisk en .exe-fil som kører i en anden proces end scriptet, for eksempel Word i Winword.exe. Dette gør det også muligt at gemme data ved hjælp af Data Access Objects (DAO), der giver adgang til data i Microsoft Access databaser.
-
In-process: Typisk en .dll- eller .ocx-fil som kører i samme proces som scriptet, for eksempel FileSystemObject i Scrrun.dll eller WshNetwork i wshom.ocx.
VBScript kan kun bruge COM-komponenter der er et Automation objekt, det vil sige komponenter der har et Idispatch interface. Selve tilgangen sker som regel med et Intelligent Name, også kaldet en moniker, via interfacet IMoniker:
Dim objExcel
Set objExcel = CreateObject("Excel.Application")
På jævnt dansk oprettes der et midlertidigt objekt.
Figur 3. Klienter og objekter kalder altid In-process. COM styrer det underliggende gennemsigtlige Remote Procedure Call (RPC) [Scripting Team].
Det skal lige bemærkes at „Nothing“ kun fjerner referencen til et objekt, men ikke nedlægger objektet hvis det er eksternt (Out-of-process). Dette kan give Out-of-process objekter uden reference. For eksempel vil dette script fejle og afslutte, men processen WINWORD.EXE findes stadig:
Dim objWord
Set objWord = CreateObject("Word.Application")
Set objWord = Nothing
objWord.Quit
Hvis der er tale om et In-process objekt, vil det sjældent give andet end en smule fri hukommelse et par millisekunder før tid, da objektet automatisk nedlægges når scriptet og dermed processen afsluttes:
Dim objFileSystem
Set objFileSystem = CreateObject("Scripting.FileSystemObject")
Set objFileSystem = Nothing
Et script eller dele af et script kan afvikles på andre maskiner end dén scriptet startes på. Det sker i praksis via WSH's WshController (WshCon.dll), som benytter COM's mulighed for distribution af kald.
Figur 4. Oversigt over komponenterne i COM's distribuerede arkitektur [Scripting Team].
Det er muligt at lave COM-komponenter i VBScript, men det er en anden historie…
Windows Management Instrumentation (WMI)
WMI
er Microsofts implementering af den web-baseret managementplatform Web-Based Enterprise Management
(WBEM)
fra Distributed Management Task Force
(DMTF).
Grundlæggende består WMI af tre ting:
- Common Information Model Object Manager (CIMON), i Windows kaldet WMI Service.
-
Common Information Model repository (CIM), i Windows kaldet WMI repository. Typisk indeholder CIM repository ingen data, men formidler aktuelle forespørgsler og data.
- WMI provider.
Figur 5. WMI Architecture [Scripting Team].
Disse ting bruger VBScript ved hjælp af COM-teknologien til at læse og skrive oplysninger meget langt ind i systemet ved hjælp af WMI Query Language (WQL), som er en begrænset (minimal) implementering af Structured Query Language (SQL).
Dette eksempel stopper servicen IISadmin:
Dim objWMIService, strComputer, colServiceList, objService, errReturn
Set objWMIService = GetObject("winmgmts:")
strComputer = "."
Set colServiceList = objWMIService.ExecQuery _
("SELECT * FROM Win32_Service WHERE Name='iisadmin'")
For Each objService in colServiceList
errReturn = objService.StopService()
Next
Common Information Model (CIM)
Industriorganisationen Distributed Management Task Force (DMTF) har udarbejdet en samling standarder kaldet Web-Based Enterprice Management (WBEM) som blandt andet indeholder Common Information Model (CIM).
Noget af kommunikationen foregår over Hypertext Transfer Protocol (HTTP) ved hjælp af Transmission Control Protocol (TCP), men som regel forbindes system management med Management Information Base (MIB) over Simple Network Management Protocol (SNMP) ved hjælp af User Datagram Protocol (UDP).
MIB–informationerne mellem Managers og Agents samles i Protocol Data Units (PDU), der er data-delen af de fleste SNMP-beskeder.
Dette er af Microsoft implementeret i WMI, primært ved at anvende Windows Driver Model (WDM).
Figur 6. WMI arkitektur [WMI White Paper].
For at få det til at virke skal der være to filer:
- En DLL-fil (dynamic-link library) til provideren, som giver WMI forespørgsler adgang til resursens API.
- En MOF-fil (Managed Object Format) som beskriver hvad provideren kan. MOF er for WMI hvad MIB er for SNMP.
I praksis kigger man andre steder for at få at vide hvad kilderne til de ønskede oplysninger hedder:
- WMI Tester (Wbemtest.exe) er et standard værktøj i enhver WMI-installation, og giver en grafisk adgang til WMI infrastrukturen.
- Object Browser følger med WMI SDK [msdn] og giver mange af de muligheder som WMI Tester, bare med en mere tilgængelig web-baseret brugergrænseflade.
- CIM Studio følger også med WMI SDK og WMI Administrative Tools [msdn] og via en web-baseret brugergrænseflade overblik og adgang til relationer og associationer i CIM schema.
- Andre scripts, for eksempel fra Resource Kits eller Scripting Guide [Scripting Team].
Sikkerhed
WMI har sit eget sikkerhedssystem, der er en tilføjelse til Windows' sikkerhed. WMI's sikkerhed består af:
-
WMI namespace sikkerhed. Før en bruger får lov til at forbinde sig til WMI, bliver brugeren valideret af op mod de rettigheder, der er gemt i CIM repository. Typisk er det default namespace 'root\cimv2'.
-
Distribueret COM (DCOM) sikkerhed. Da WMI benyttes via DCOM, giver det mulighed for at anvende funktionaliteten Impersonation, hvor brugeroplysninger gives videre til andre DCOM baserede services.Det anbefales at Impersonation sættes til Impersonate, der kun giver rettigheder til single-hop impersonation - modsat Delegation, der giver mulighed for multiple-hop impersonation. Desuden er det muligt at sætte Impersonation til Anonymous eller til Identify. Den sidste mulighed giver objekter mulighed for at spørge hvem der kalder.
-
Standard Windows operativsystem sikkerhed. For eksempel vil NTFS-rettighederne på en folder være bestemmende for om en WMI-operation kan afvikles.
De sidste ord
Praktisk erfaring
I forskellige sammenhænge har jeg blandt andet arbejdet med automatisering i Registreringsbatabasen, netværksprintere og -drev, håndtering og kontrol af processer og services samt filhåndtering ved hjælp af WSH, VBScript og WMI. Ved flere af vores daglige opgaver indenfor sikkerhedsadministration, serverhåndtering, storage management eller driftsplanlægning anvender vi miljøerne.
Selv mere komplekse opgaver som for eksempel oprettelse og tilpasning af instanser til IBM DB2 UDB for Windows er det muligt at automatisere med et script :-)
Programstruktur
De fleste scripts bliver skrevet proceduralt, men det er muligt at skrive objektorienteret eller til hændelser (events). Hvis koden skal genbruges eller segmenteres, er det oftest en fordel at skrive koden objekt-orienteret.
Om at skrive lister eller log
Det er min erfaring at det mest anvendelige er at skrive lister eller log i en Tab Separeted Value (TSV) fil af typen .tsv modsat en Comma Separeted Value (CSV) fil af typen .csv, for det er nemmest af behandle i Office programmer på grund af sprogindstillingernes forskellige tegn ("," eller ".") til decimaler. En anden mulighed er at formattere outputtet i XML, så det kan behandles eller vises efterfølgende af flere forskellige programmer med et mere nuanceret resultat. Det er dog noget mere omstændeligt at holde en korrekt XML-formattering i en log-fil, hvor der løbende bliver tilføjet indlæg.
JScript
WSH kan også håndtere scripts skrevet i JScript (se Figur 1). JScript er Microsofts udgave af
ECMAScript,
som også Netscape har implementeret ved JavaScript.
Da JScript ikke kan håndterer samlinger (collections), kan det i praksis ikke bruges sammen med WMI, da WMI ofte svarer med en samling. Ellers giver JScript stort set de samme muligheder som VBScript. En af de største forskelle er at JScript kan håndtere fejl–håndtering ved hjælp af try-catch strukturer.
Perspektiver
Med WSH og VBScript givet en del muligheder for for eksempel en script samling, central schedulering, automatisk fejlsøgning og -retning samt afvikling af et decideret batchflow. Microsoft har en øget opmærksomhed på automatisering, så der er mange - og anvendelige — eksempler på deres hjemmesider.
Hvis man laver en søgning på en almindelig Windows server efter .vbs- og .js-filer, kan man se at der ligger fra Microsofts side en del i systemfolderne - og der kommer flere på serveren hvis man installerer for eksempel SQL Server.
Litteratur
[Childs et al] Matt Childs, Paul Lomax og Ron Petrusha:
VBScript in a Nutshell
(2000, O'Reily & Associates, ISBN 1-56592-720-6)
[Scripting Team] The Microsoft Windows Resource Kit Scripting Team:
Microsoft Windows 2000 Scripting Guide
(2002, Microsoft Press, ISBN 0-7356-1867-4)
[WMI White Paper] Microsoft Corporation
Windows Management Instrumentation: Background and overview
(1999, Microsoft Corporation)
[msdn] Microsoft Developers Network
msdn.microsoft.com, specielt Library
[Technet] Microsoft Technet
www.microsoft.com/technet, specielt Script Center
[Osterloh] Heather Osterloh:
TCP/IP Primer Plus
(2002, Sams Publishing, ISBN 0-672-32208-0)
Kapitel 17. Simple Network Management Protocol (SNMP)