De Windows-werkplek standaardiseren

Wat variatie echt kost

Elk model dat je toevoegt brengt een eigen driverset mee, eigen dockinggedrag, een eigen firmwarecyclus en een eigen set eigenaardigheden die de desk moet leren. Twee modellen is te doen. Acht is een permanente heffing op elke supportmelding, want de eerste vraag wordt welke variant deze gebruiker heeft.

De besparing die de variatie veroorzaakte is vrijwel altijd kleiner dan de doorlopende kosten. Kopen wat dat kwartaal het goedkoopst was scheelt een paar procent bij aanschaf en voegt een supportlast toe die de hele levensduur van het apparaat meegaat.

Twee of drie profielen, geen acht modellen

Vier profielen van een fabrikant zijn veel makkelijker te draaien dan acht modellen van drie. De merkkeuze telt minder zwaar dan de discipline om een hele cyclus bij de profielen te blijven, en dat staat in Dell, HP of Lenovo.

Zero-touch aanmelden verandert de rekensom

Het klassieke model laat een apparaat bij IT aankomen, waar het uitgepakt, van een image voorzien, aangemeld, ingericht en daarna geleverd wordt. Dat is een tot drie uur per apparaat, en daarom worden uitrollen in weken gemeten.

Zero-touch aanmelden stuurt het apparaat vanaf de leverancier rechtstreeks naar de gebruiker, geregistreerd op jouw tenant. De gebruiker logt in en het apparaat richt zichzelf in: beleid, applicaties, beveiligingsinstellingen, printers. De engineer raakt het nooit aan.

Bij een uitrol van enige omvang is dat het verschil tussen een project en een leverschema. Het maakt ook een kapotte laptop vervangen triviaal, want een reserveapparaat uit de kast wordt een werkend apparaat in de tijd die inloggen kost.

Golden image of configuratie als beleid

De oudere aanpak bouwt een image met alles erin en zet die op elk apparaat. Dat is voorspelbaar en het verouderd slecht: de image moet opnieuw gebouwd worden zodra er iets verandert, en hij bindt je aan de hardware waarvoor hij gebouwd is.

De huidige aanpak laat het besturingssysteem staan zoals de fabrikant het leverde en zet al het andere als beleid erop, zodat de inrichting een definitie is en geen momentopname. Het kost meer tijd om op te zetten en aanzienlijk minder om te onderhouden, en het overleeft een hardwarewissel zonder herbouw.

Voor de meeste mid-market organisaties is de tweede inmiddels het juiste antwoord. De uitzondering is een zwaar aangepaste omgeving met applicaties die zich verzetten tegen installatie via beleid, en die zijn het waard om te herkennen voordat je je vastlegt.

Updateringen, geen updatechaos

Twee uitersten komen allebei veel voor en zijn allebei fout: updates die meteen naar iedereen gaan, of updates die eindeloos uitgesteld worden omdat een eerdere update iets brak.

Ringen lossen dat op. Een kleine pilotgroep krijgt updates als eerste, een bredere groep een week later, de rest een week daarna, met kritieke beveiligingsupdates op een kortere cyclus voor iedereen. Het vangt de slechte update op twintig machines in plaats van tweehonderd, en het maakt van de vraag wanneer updates komen een schema in plaats van een discussie.

Wat je als eerste standaardiseert

• Aanmelden. Een manier waarop apparaten binnenkomen. Al het andere hangt daaraan.
• Beveiligingsbasis. Schijfversleuteling, endpointbescherming, schermvergrendeling, lokale beheerdersrechten. Overal hetzelfde, geen uitzonderingen op basis van functie.
• Applicatie-uitrol. Een mechanisme. Geen mix van een portaal, een script en iemand die dingen met de hand installeert.
• Updateringen. Vastgestelde groepen met een vastgestelde vertraging.
• Daarna pas de profielen. Hardware standaardiseren volgt vanzelf zodra de laag eronder consistent is.

Hoe wij dit dagelijks draaien staat beschreven onder managed IT, en de levering van de apparaten zelf onder IT-lifecycle.