Welke Logonscript software? (WSH? Powershell? CMD?)

[bitpixl]

Ik heb de twijfelachtige eer gekregen om voor ons netwerk een compleet nieuw logonscript te maken.

Even wat info:

- Het is een netwerk dat over europa verspreid is: (NL-UK-GE-FR)
- Alle (logon)Servers zijn minimaal Windows 2003 R1 en sommige R2
- Alle servers zijn engels, BEHALVE de Franse servers (uiteraard)
- Alle Clients zijn minimaal Windows 2000, maar merendeel XP (SP2)
- Alle clients zijn in de taal van het desbetreffende land.

Momenteel gebruik ik voor NL en GE een Kixtart logonscript wat naar behoren werkt,
maar MOET ik nu een andere "standaard" Microsoft oplossing gaan gebruiken.
(Ah, de keuzes van het management...)

De keuzes die ik nu heb zijn dan:

- CMD/Batch files
Voor mappings is dit natuurlijk voldoende, maar maakte ik met Kixtart gebruik van Registry
wijzigingen (bv. Word standaard "save" dir verwijzen naar <Homedir>\Mijn Documenten\Word)

- WSH (Windows Scripting Host)
Woei!, dat wordt studeren om dit onder de knie te krijgen, maar kan wel veel meer als een
.CMD script. Alleen, blijft WSH in toekomstige versies van Windows behouden?

- Powershell
Wordt dit nou een standaard of niet? Het ziet er makkelijker uit om te leren als WSH.
Alleen ben ik dus erg benieuwd of dit een 'blijfertje' is of niet.

Wat raden jullie mij nou aan?

[mutsje]

Ik zou overgaan op VBS. Hierin kun je ook registrykeys mee importeren etc. Lijkt ook veel op WSH. Je kunt op http://www.microsoft.com/technet/scriptcenter/default.mspx veel voorbeelden vinden.

[elevator]

PowerShell heeft als nadeel dat het niet op alle clients geinstalleerd zal zijn, hierdoor valt het op dit moment nog af in mijn ogen.

Met batchfiles kan je veel - zeker op XP en hoger, maar waarschijnlijk is VBScript inderdaad de meest interessante oplossing voor jou. Let je wel op dat je sommige dingen gewoon beter in policies kan regelen - bijvoorbeeld dat voorbeeld van die Word File Save directory is beter te doen in een policy dan in een logon script

[bitpixl]

@Elevator: Daar heb je idd wel gelijk in en ik heb ook al een hoop in policies gezet.

Ik heb volgens mij destijds die padverwijzingen bewust door KiXtart laten afhandelen omdat ik
2 (snelle) scripts laat draaien tijdens het aanloggen. Als er een verbinding is met de server waar de <homedir> van de user op staat, wordt via het script op de logonserver alles doorverwezen naar die <homedir>. Is de server waar de <homedir> op staat niet beschikbaar, of het netwerk ligt plat, dan draait er altijd nog een lokaal script met padverwijzingen naar de lokale HD. Voor laptops die niet verbonden zijn is zo'n lokaal script ook wel erg handig.

Ik heb trouwens aangekaart dat KiXtart ontwikkeld is door Ruud van Velsen (Microsoft NL) en dat KixTart ook in Resource Kits werd meegegeven, dus misschien kan ik alsnog bij KiXtart blijven

Dat neemt niet weg dat je met VB en WSH (en Powershell?) nog een heleboel andere leuke dingen kan doen. (automatisch aanmaken van users in AD bv).

[ Voor 5% gewijzigd door bitpixl op 07-09-2007 12:19 ]

[Pedr0]

Waarom geen KIXtart meer dan? Ik zit eigenlijk in precies dezelfde situatie.....

[Edit]Ow, ik had er overheen gelezen - Standaard MS oplossing!

Hier staat ook nog een 'project' open om te kijken naar een nieuw loginscript en eventueel in een andere taal.

Met name omdat we nu soms problemen hebben dat bepaalde zaken gewoon niet 'laden' tijdens het opstarten van Windows.

[ Voor 10% gewijzigd door Pedr0 op 07-09-2007 13:25 ]

[alt-92]

Skillz schreef op vrijdag 07 september 2007 @ 10:51:
Alleen, blijft WSH in toekomstige versies van Windows behouden?

Ja Al was het maar omdat heel veel managementtools (MOM, SystemCenter) bij ontbreken van PowerShell een graceful degrade pad met WMI/VBscript gebruiken

[powerboat]

ik gebruik AutoITscript op dit moment i.c.m. met Acces Database waar hij zijn settings per gebruiker/groep uithaalt. (volledige grafisch met progresbar O_) ). deze heb ik sinds kort omgeschreven naar ini file omdat dit sneller is voor mijn sites zonder DC deze zit momenteel in een testfase.

<reclame mode>
Ik wil dit straks gaan publiceren als zijnde opensource Logonscript Desktop Controlcenter

Wat kan het ?
- Personal settings aanmaken (Home Drive/Default Printer)
- Group Settings aanmaken (Network Shares/Network Printers/Snelkoppelingen aanmaken/Register Keys importeren/Commando's achteraf runnen (EXE/COM/BAT)
- User Settings aanmaken (Network Shares/Network Printers/Snelkoppelingen aanmaken/Register Keys importeren/Commando's achteraf runnen (EXE/COM/BAT)

Dit allemaal per site ingedeelt. Je krijg dus alleen de items te zien die voor de bepaalde site gelden (ook als je in die groep bent ingedeelt).

verder (ben ik nu mee bezig) grafische editor, komt dus geen gescript meer aan te pas alleen maar formulieertjes dus.

Dus mocht je interesse hebben en willen testen voor mij dan graag :-P
</End Reclame mode>

Maar het voordeel van AutoITscript is dat je het kunt compilen


--------------

Sorry Niet goed gelezen als je een standaard MS oplossing wil kies dan VBSCRIPT icm. XML (heb hier ook nog een script van liggen als je dat als voorbeeld wil. (is ook grafisch)

[ Voor 7% gewijzigd door powerboat op 12-09-2007 21:55 ]

[Thijs B]

ik zou dat autoit login script wel eens willen bekijken ?

Autoit is een heel leuk script taaltje, maar is het niet wat te log voor login scripts ? Zeker wanneer je remote moet in loggen over een vpn ofzo ?
Een beetje complex autoit script is toch al snel >300 kb.

een combinatie van vb en autoit kan natuurlijk ook prima.. Maarja helaas is het geen standaard ms oplossing.

Voor de topic starter wanneer je login script geheel opnieuw gaat maken is powershell toch wel erg mooi, alleen moet je dan weer een oplossing vinden om via policy/script eerst powershell op je clients te installeren.

vb script doet wat het moet doen maar vind het nog steeds geen prettig taaltje om mee te werken.
batch scriptjes lijkt me in zo'n omgeving 'not done'

[powerboat]

Thijs B schreef op woensdag 12 september 2007 @ 23:34:
ik zou dat autoit login script wel eens willen bekijken ?

Autoit is een heel leuk script taaltje, maar is het niet wat te log voor login scripts ? Zeker wanneer je remote moet in loggen over een vpn ofzo ?
Een beetje complex autoit script is toch al snel >300 kb.

een combinatie van vb en autoit kan natuurlijk ook prima.. Maarja helaas is het geen standaard ms oplossing.

Voor de topic starter wanneer je login script geheel opnieuw gaat maken is powershell toch wel erg mooi, alleen moet je dan weer een oplossing vinden om via policy/script eerst powershell op je clients te installeren.

vb script doet wat het moet doen maar vind het nog steeds geen prettig taaltje om mee te werken.
batch scriptjes lijkt me in zo'n omgeving 'not done'

Hee Thijs,

Ik zal vanavond linkjes posten, het script zelf is niet zo groot maar wel de gecompileerde versie. je kan ze seperate runnen als je dat wil.

op een Lan doet hij er net zo snel over als (de gecompileerde versie) als een batchh bestandje (10 a 20 sec. met alle settings die ik heb opgesteld). Op onze remote production site met een lijntje van 64kbit doetr hij er 2 tot max 3 min over. Ik vind dit nog redelijk acceptabel

Dus met VPN over DSL of Kabel etc... gaat het zeker sneller. Je kan ook het script lokaal op de computer/laptop zetten de settings haalt hij uit het ini bestand.

Maar inderdaad voor remote users ben ik nog aan het brainstormen.

[WaSteiL]

Ik maak zelf altijd gebruik van VBS. Zeer compleet waar echt alles mee mogelijk is.
Varierend van groeplidmaatschappen, register keys aanpassingen en zelfs het installeren van printers.

KiX is op zich erg fijn dat het aardig makkelijk is en goed leesbaar is voor mensen die nog nooit naar een script hebben gekeken. Nadeel vind ik alleen dat je weer gebruik moet maken van een externe tool om het script te laden.

[bitpixl]

Bedankt voor de antwoorden, best interessant om te zien welke oplossingen er allemaal zijn
en waarom je voor die oplossing kiest.

Ik heb dus voorgesteld om verder te gaan met KiXtart omdat ik dat al redelijk beheers
(gebruik het al jaren) en het toch wel naar mijn mening onder de noemer
"standaard MS oplossing" valt.

- ontwikkeld door MS medewerker
- (werd?) meegestuurd in Resource Kits.

Maar goed, tot nu toe nog geen accoord.
Heb inmiddels wel het KiXtart script aangepast.

MS Powershell lijkt mij een goede 2e keuze, ook al moet ik het eerst op alle clients zien te krijgen.
Misschien bestaat er een MSI package -> Policy push oplossing? Maar daar heb ik me verder nog niet mee bezig gehouden.

Verder vindt ik 10-20sec voor een loginscript wel erg lang en >300kb is ook (te?) groot.
Mijn script vanaf het netwerk is 13.5kb (encrypted) en het 2e script dat runt vanaf de hd is 4.16kb (ook encrypted).

[elevator]

Hoewel Windows Powershell een erg mooie oplossing is - zou ik het jou absoluut niet aanraden. Ten eerste is PowerShell niet beschikbaar voor Windows 2000, maar bovendien is het best een zware omgeving om te starten (als ik het hier op mijn PC start, duurt het 8 seconden voor ik een shell prompt heb!)

[powerboat]

Skillz schreef op donderdag 13 september 2007 @ 09:38:
Verder vindt ik 10-20sec voor een loginscript wel erg lang en >300kb is ook (te?) groot.
Mijn script vanaf het netwerk is 13.5kb (encrypted) en het 2e script dat runt vanaf de hd is 4.16kb (ook encrypted).

Skilzz 10 a 20 sec. is afhankelijk van de omgeving dit is bij ons met 11 printers, 4 shares, desktop/startmenu/programma's shortcuts, Registry Key's en Commando's erna.


Het script is 14kb alleen de gecompileerde versie is 200kb verder kun je het script ook runnen zoals je kix aanroept. (is zoiets als Res powerfuse maar die is alleen iets te duur)

Mijn oude KIX script deed er net zolang over met minder settings

(o ja en ben bezig met een GUI zodat je nietmeer hoeft te scripten voor de essentiele dingen)

[ Voor 6% gewijzigd door powerboat op 13-09-2007 10:25 ]

[bitpixl]

Mijn oude KIX script deed er net zolang over met minder settings

Ik weet niet wat de laatste Kix versie was waarmee jij gewerkt hebt,
maar Pre-Tokenized KiX scripts hebben de snelheid wel flink verbeterd.
(en het script is ook meteen onleesbaar voor de end user, wat ik ook wel een pluspunt vind.)

(o ja en ben bezig met een GUI zodat je nietmeer hoeft te scripten voor de essentiele dingen)

Ik denk dat vooral de GUI oplossing het voor de startende scripters een stuk aantrekkelijker zal maken. Ik heb wel respect voor wat je aan het doen bent hoor

Hoewel Windows Powershell een erg mooie oplossing is - zou ik het jou absoluut niet aanraden. Ten eerste is PowerShell niet beschikbaar voor Windows 2000, maar bovendien is het best een zware omgeving om te starten (als ik het hier op mijn PC start, duurt het 8 seconden voor ik een shell prompt heb!)

Hmmm die traagheid is zeker een groot minpunt.
Windows 2000 zou niet het probleem zijn. Alles is hier nu WinXP / Win2003 Svr.

[ Voor 29% gewijzigd door bitpixl op 13-09-2007 11:04 ]

[Verwijderd]

WaSteiL schreef op donderdag 13 september 2007 @ 09:25:
Ik maak zelf altijd gebruik van VBS. Zeer compleet waar echt alles mee mogelijk is.
Varierend van groeplidmaatschappen, register keys aanpassingen en zelfs het installeren van printers.

KiX is op zich erg fijn dat het aardig makkelijk is en goed leesbaar is voor mensen die nog nooit naar een script hebben gekeken. Nadeel vind ik alleen dat je weer gebruik moet maken van een externe tool om het script te laden.

/signed
cmd zou zelfs misschien al voldoende zijn. Alleen als je meer wilt doen dan een homedir mappenen een printertje dan zal je het beste naar vbs kunnen overstappen (reg keys zetten is met cmd niet echt een probleem, maar met cmd zal je vaak wel weer grijpen naar niet standaard geinstalleerde tool uit de supporttools (reg.exe) of reskit).

Hoewel Windows Powershell een erg mooie oplossing is - zou ik het jou absoluut niet aanraden. Ten eerste is PowerShell niet beschikbaar voor Windows 2000, maar bovendien is het best een zware omgeving om te starten (als ik het hier op mijn PC start, duurt het 8 seconden voor ik een shell prompt heb!)

voorlopig zie ik powershell nog niet echt als loginscript. Meer om installaties te scripten en repeterende handelingen te scripten. Misschien gaat dat veranderen als vista en server 2008 gemeengoed worden