Login scripts, GPO’s of zelf installeren?
Software deployment tools staan niet op zichzelf. Ze bouwen voort op tools en methoden uit het heden en verleden. Een overzichtje daarvan helpt straks bij het uitleggen van de functionaliteiten. We willen je er trouwens nog even eraan herinneren dat we het hier alleen over het uitrollen en beheren van Windows en Windows-software hebben. Maar dat is al uitdaging genoeg.
Dit is deel 3 in onze serie over software deployment. De andere afleveringen vind je hier:
Wat is software deployment? Deel 1 – Van mainframe tot internet
Wat is software deployment? Deel 2 – Op een slof en een ouwe sneaker
Wat is software deployment? Deel 4 – Software deployment tools
Centraal binnen Windows-omgevingen staat de Active Directory. Een database met alle computers, gebruikers, servers, printers, maar ook rechten voor gebruikers. De opsomming alleen al is een duidelijke aanwijzing dat we hier te maken hebben met een complex geheel. Maar voor organisaties met honderden computers en gebruikers (met Windows) kun je niet om AD heen.
Login scripts
De leercurve is stijl, maar wanneer je de basics van AD onder de knie hebt – volg vooral een officiële cursus, staat ook heel goed op je LinkedIn – dan ga je er veel plezier van hebben. Een van de handige dingen is het login script. Het is precies wat het zegt: de gebruiker logt in, vervolgens krijgt de computer een seintje van de server om een script af te werken. Bijvoorbeeld om een printer als standaard te verbinden, een verbinding te leggen met de gebruikersfolder op de server, maar ook – en daar komen we in de buurt – het configureren van software. Login scripts kunnen per gebruiker of per groep gebruikers worden gemaakt, en het neemt je veel werk uit handen.
Group Policies
Een volgende stap is om een ‘group policy object’ of GPO aan te maken die software beschikbaar stelt. Dit Active Directory beleidsobject geeft de gebruiker een seintje: er staat nieuwe software klaar, wil je die installeren? (Het kan trouwens ook dwingender; software wordt stilletjes geïnstalleerd en wanneer de gebruiker deze voor het eerst start, geconfigureerd.) Klinkt goed, maar er is een flinke beperking. Alleen software die verpakt is in een MSI-bestand kan via een GPO worden geïnstalleerd. Een ander nadeel is dat je volkomen blind bent: je weet niet bij wie het geïnstalleerd is, of het misschien bij iemand mislukt is, was er een foutmelding, zo ja, welke. Het is als met de ogen dicht schieten en hopen dat je iets raakt.
Centraal beschikbaar stellen
Misschien is het dan nog wel beter om te kiezen voor het centraal beschikbaar stellen van software en de gebruiker gewoon netjes te vragen of die wil installeren. Dan zet je de installatiebestanden op een netwerkschijf. Je hoeft er dan alleen voor te zorgen dat de software op die plek altijd up-to-date is. Maar ja, bij veel organisaties loop je dan tegen de beperking aan dat gebruikers niet de juiste rechten hebben om zelf software te installeren. Waar op zichzelf natuurlijk álles voor te zeggen is in het kader van de veiligheid op het bedrijfsnetwerk.
Virtualisatie
Even een zijsprongetje.
Je bent vast bekend met het fenomeen virtualisatie. Daarbij draait de computer het besturingssysteem niet lokaal, maar via een netwerkomgeving. Elke keer dat de gebruiker inlogt, start er een virtuele kopie op van een door jou vooraf ingestelde Windows-omgeving.
Dat is dan op het niveau van het besturingssysteem. Maar er bestaat ook zoiets als applicatie-virtualisatie. Het principe is vergelijkbaar: een gebruiker start een applicatie op – gewoon op zijn eigen pc met zijn eigen Windows – maar deze draait in feite op een virtuele server. De gebruiker ziet alleen de front-end: de gebruikersinterface. Alle interactie wordt afgevangen en afgehandeld door de server. De gebruiker merkt daar in principe niets van.
Groot voordeel voor de beheerder! Je hoeft een applicatie maar één keer te installeren. Alle gebruikers krijgen daarbij dezelfde ‘applicatie-omgeving’ voorgeschoteld. Update? No problem! Die rol je gewoon maar één keer uit. Trouwens als je wilt, kun je allerlei versies van een applicatie beschikbaar houden. Die zitten in hun eigen containertje en dus elkaar nooit in de weg. Ben je ook meteen van de ‘DLL-hel’ af, waar verschillende versies van een (runtime-)DLL in omloop zijn.
Maar helaas is virtualisatie nogal kostbaar, en alleen weggelegd voor organisaties van enterprise-omvang.
Software deployment tools
Daar zijn we dan eindelijk waar we naartoe willen. Naar tools die alles zoveel mogelijk automatisch voor je regelen. Een beetje login scripts, een beetje policy-instellingen, een beetje software beschikbaar stellen. Sommige beheertools hebben al een deel van deze functies ingebouwd. Bijvoorbeeld Microsoft Endpoint Manager (voorheen SCCM, en daar weer voor SMS). Maar wij mikken op tools die enkel en alleen bedoeld zijn voor het uitrollen, beheren en updaten van software.
Waar het daarbij vooral om gaat is dat je inzicht, controle en flexibiliteit hebt over wie, wat, wanneer installeert. De voordelen zijn legio en per product verschillend.
Gympen
We komen tóch nog even terug op het sneakernet. In sommige gevallen blijft het handig om de analoge manier te hanteren wanneer de digitale het laat afweten. Een netwerkverbinding ligt eruit en natuurlijk nét op het moment dat die belangrijke klant dat nieuwe stukje software nodig heeft.
In het volgende artikel gaan we het hebben over bekende en minder bekende software deployment tools. Over de functionaliteit, toepassingen en voor- en nadelen.