Scripts kunnen we op twee manieren implementeren. De eerste is de aloude methode die we nog kennen vanuit Windows NT. Hierbij geven we in de account eigenschappen een loginscript op wat zich bevind in de share NETLOGON van de domain controller. Tijdens het aanmelden wordt deze uitgevoerd in het proces van de gebruiker. Meerdere scripts kunnen alleen gestart worden vanuit het eerst gestarte script. Bij het aanmaken van een gebruikersaccount moeten de accounteigenschappen goed zijn ingevuld anders functioneert het script niet.
Nieuw met de introductie van Windows 2000 is de mogelijkheid scripts te starten vanuit een Group policy. Elke group policy kent 4 mogelijkheden:
- Computer startup script
- Computer shutdown script
- User login script
- User logout script

Elk onderdeel kan één of meerdere scripts al dan niet met opstart parameters starten. User scripts worden zoals vanouds in een gebruikers context uitgevoerd maar we kunnen nu ook afsluit scripts instellen. Hierin kunnen we nog acties uitvoeren alvorens de gebruiker wordt afgemeld.
Computer scripts zijn een nieuwigheid. Deze scripts worden uitgevoerd als de computer start of stopt en worden uitgevoerd met systeem privileges. Dit schept een aantal interessante mogelijkheden. We kunnen niet alleen de desktop van de gebruiker configureren maar ook de machine waar de gebruiker mee werkt.

Het implementeren van een standaard policy is feitelijk heel eenvoudig. Men maakt een policy, koppelt deze aan een Organizational Unit (OU), vinkt de gewenste aanpassingen aan en klaar. Een wijziging uitvoeren met een script betekent uitzoekwerk, ontwikkelen en testen, testen, testen. Computer scripts moeten volledig zelfstandig kunnen werken en vragen daarom extra aandacht, vragen om input van de ‘gebruiker’ is er immers niet bij. Ondanks al het werk dat we moeten verzetten voor een goed script zijn er echter interessante toepassingen mee te maken.

Om u op weg te helpen behandelen we in dit artikel een computer script en een loginscript. Het computer script gebruiken we onder andere om sites- en computer specifieke informatie te verzamelen en in de registry weg te schrijven. Het loginscript bevat een aantal standaard elementen die in de praktijk vaak worden gebruikt.
Beide voorbeelden demonstreren het gebruik van scripts om computers en gebruikeromgevingen te beïnvloeden.

Het computer startup script demonstreert een aantal aspecten die interessant zijn voor een gestandaardiseerde omgeving.
- Het beïnvloeden van systeemonderdelen zoals het bestandsysteem en de registry
- Aanpassen van het systeem aan de omgeving

Het probleem van een loginscript is dat dit in de context van de gebruiker wordt uitgevoerd. We kunnen dan niet bij bepaalde delen van het systeem komen. Dat is natuurlijk nogal hinderlijk. We kunnen de gebruiker meer privileges geven maar dat heeft weer als nadeel dat de machine gevoeliger wordt voor virussen en onoordeelkundig gebruik (of zelfs malafide acties).
Met een computer startup/shutdown script lossen we dit probleem op. Deze draait in de context van het systeem en heeft daardoor toegang tot alle lokale resources. Hierdoor kunnen we alle systeemonderdelen bereiken, programma’s installeren of andere activiteiten ondernemen. Het voorbeeld script voert 3 handelingen uit.
- Het verwijderen van een snelkoppeling uit het ‘all users’ profiel.
- Het aanpassen van de tijdzone instelling
- Op basis van de AD site een systeem variabele instellen.

Het aanpassen van het profiel is een standaard script handeling. We verwijderen met een delete commando een snelkoppeling uit ‘all users’ waarmee deze ook voor elke gebruiker verdwijnt.

De tweede handeling betreft vooral uitzoekwerk waarbij we eerst moeten achterhalen wat nu eigenlijk de gewenste registersleutel is die moet worden aangepast. Eenmaal gevonden kunnen we vrij eenvoudig de gewenste handeling uitvoeren.
Belangrijk is om het script te beginnen met een ‘on error resume next’. Weliswaar zijn de handelingen eenvoudig maar we moeten voorkomen dat de gebruiker tijdens het opstarten wordt geconfronteerd met een scriptfout. Computer scripts moeten daarom ook goed worden getest.

De laatste handeling is de meest interessante. Wanneer we een Active Directory forest omgeving beheren met meerdere sites en we hebben roaming profiles toegepast. Gebruikers die roamen zullen hun profiel over de WAN verbinding ophalen bij inloggen wat het aanmeld proces aanzienlijk vertraagd. Alternatief kunnen we per locatie een profiel aanhouden waardoor we binnen een locatie roaming kunnen aanbieden maar niet over locaties heen. We maken hier gebruik van de eigenschap van het profiel veld in Active Directory (Figuur 1). In dit veld staat het pad naar het profiel wat mag bestaan uit Windows environment variabelen. Meestal %username% om de naam van de gebruiker in te vullen. Een ander standaard aanwezige waarde is %logonserver%. In ons computer startup script leiden we de site waar we ons bevinden af en kennen we toe aan de environment variabele ‘%profileserver%’. Hierdoor kunnen we vaststellen waar het profile zal worden uitgelezen en dit zal worden bepaald door de locatie van de pc. Het gevolg hiervan is dat het profiel zal worden geladen van de server genoemd in de variabele.

Figuur 1 : Met filesecurity kan toegang worden beperkt

Startup script
----------------------------
on error resume next
Dim owSHShell
Set WshShell = CreateObject("WScript.Shell")
Set FSO = CreateObject("Scripting.FileSystemObject")

FSO.DeleteFile "C:\Documents and Settings\All Users\Bureaublad\MSN Explorer.lnk"

'daylight savings
WshShell.RegDelete "HKLM\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\DisableAutoDaylightTimeSet"

‘Site info
Set objSysInfo = CreateObject("ADSystemInfo")
Set WshSystemEnv = WshShell.Environment("SYSTEM")
select case objSysInfo.SiteName
case "hoofdkantoor" strServer="\\server01"
case "bijkantoor" strServer="\\server02"
end select
WshSystemEnv("ProfileServer") = strServer
-------------------------------------------

Loginscripts worden uitgevoerd in de context van de gebruiker maar gegeven de beperkingen die dat kent zijn deze uitstekend geschikt om een gebruikersomgeving helemaal naar de behoeftes van de eindgebruiker te configureren. Zeker in vergrendelde omgevingen moet dit vaak voor de eindgebruiker worden gedaan omdat deze niet eens in staat is dit zelf te doen door de opgelegde beperkingen middels group policies.
We behandelen een loginscript dat de meest voor de hand liggende functies bezit. Een goed loginscript moet in elk geval in staat zijn tot:
- Het maken van netwerk verbindingen
- Het creëren of verwijderen van snelkoppelingen of andere bestanden
- Het aanpassen van het register
- Kunnen plegen van wijzigingen op basis van groepslidmaatschap
- De activiteiten op duidelijke wijze aan de gebruiker te communiceren.

In het voorbeeld loginscript (zie ook het einde van dit artikel) maken we gebruik van internet explorer om de weergave te verzorgen. De standaard mogelijkheden van vbscript zijn namelijk vrij beperkt maar door Internet explorer te gebruiken zijn er ruim voldoende mogelijkheden om een nette representatie te verzorgen.
Het geheim zit hem in dit commando:

Set oMSIE = CreateObject("InternetExplorer.Application")

Hiermee starten we een internet explorer instantie waar we meldingen bestemd voor de gebruiker in kunnen weergeven. Dit doen we door gebruik van een method die het oMSIE object voor ons ontsluit:

oMSIE.Document.Write strOutput & "
"

Naast het kunnen weergeven is het erg belangrijk om groepslidmaatschappen te kunnen achterhalen. We moeten immers de omgeving zoveel mogelijk kunnen toespitsen op de gebruiker. Vbscript kan hier standaard niet mee omgaan daarom maken we gebruik van ADSI (Active Directory Services Interface) om alsnog de benodigde informatie te bemachtigen. De functie ‘getgroups’ vraagt aan AD welke groepen de gebruiker lid van is en slaat deze op. De functie ‘memberof’ controleert vervolgens of de gebruiker lid is van een bepaalde groep. Hierdoor kunnen we commando’s in het loginscript maken zoals deze:

if memberof("Sales") then

Zo kunnen we eenvoudig afleiden wat de groepslidmaatschappen van de gebruiker zijn en daarop inspelen.

Het tweede scriptvoorbeeld laat het ‘body’ gedeelte van het script zien. We maken een schijfverbinding, een printerverbinding en bereiden een applicatie voor gebruik voor, hierbij maken we een snelkoppeling aan en voegen een waarde toe aan de registry. Sommige applicaties zijn niet geheel correct ontworpen en vereisen bepaalde waardes in het gebruikers deel van de registry, wanneer de gebruiker de applicatie niet zelf installeert is dat niet mogelijk en hebben we het loginscript nodig om deze situatie op te lossen.

De schijf en printer verbindingen zijn onderdeel van het WshNetwork object, een standaard onderdeel van Windows scripting. Een schijfverbinding maken we bijvoorbeeld met het commando:

Set oWSHNetwork = CreateObject("WScript.Network")
oWSHNetwork.MapNetworkDrive strDrive,strShare,bPersistent

Snelkoppelingen en andere bestandsacties maken gebruik van het Shell en filesystem object:

set oShell = oWshShell.CreateShortcut(strShortCut)

Doordat we alles in aparte functies hebben gestopt kan het hart van het script er leesbaar uit blijven zien. Door het gebruik van groepen kunnen we vanaf één script voor het overgrote deel van de gebruikers de benodigde functionaliteit leveren. Slechts in een uitzondering zullen we extra scripts moeten schrijven.

Scripting is niet een van de meest eenvoudige technieken maar bezit wel de flexibiliteit die we niet vinden in de het group policy systeem. Door de juiste mix van group policies en computer of user scripts kunnen we een krachtige combinatie maken.

De complete voorbeelden zijn hier te downloaden:
http://www.win2kwereld.nl/apps/files.asp?task=single&ID=31&download=1

** Dit artikel verscheen eerder in IT-Beheer magazine **

© 2004 Wim Verveen en namens deze © 2004 Win2K Wereld
De informatie in dit document mag uitsluitend met voorafgaande schriftelijke toestemming worden gepubliceerd.
Het is niet toegestaan dit document op het internet aan te bieden al dan niet in gewijzigde vorm