10 minuten

Je hebt een virtuele werkplekomgeving. Meerdere servers of desktops, een aantal images, honderden gebruikers. En elke keer als er iets moet worden aangepast, begint hetzelfde ritueel: inloggen op een machine, de wijziging doorvoeren, hopen dat je het niet vergeet op de andere machines, en weken later ontdekken dat de productieomgeving afwijkt van wat je verwacht.

Dit speelt in elke omgeving waar virtuele desktops of applicaties worden aangeboden. Of je nu werkt met Citrix, Microsoft Azure Virtual Desktop, Parallels of Remote Desktop Services. De technologie verschilt, de pijn is hetzelfde.

En die pijn is groter dan hij lijkt.

Hoe imagebeheer in de praktijk werkt en waarom dat problemen geeft

In de meeste organisaties is imagebeheer iets wat is gegroeid, niet ontworpen. Er is een image gemaakt, ooit. Dat image is door de jaren heen aangepast. Software erbij gezet, software verwijderd, updates doorgevoerd, instellingen gewijzigd. Het resultaat is een image dat de volledige geschiedenis draagt van alles wat er ooit op is gedaan.

Dat klinkt onschuldig, maar het is een sluipend probleem. Verwijderde software laat resten achter. Applicaties die zijn bijgewerkt maar nooit schoon zijn herinstalleerd, gedragen zich net iets anders dan ze zouden moeten. Instellingen die ooit zijn aangepast maar nooit teruggezet, zorgen voor onverwacht gedrag.

Dit noemen we imagevervuiling. Het is niet zichtbaar, maar je merkt het wel. In incidenten die je niet kunt verklaren. In gedrag dat afwijkt van wat je verwacht. In een omgeving die steeds moeilijker te troubleshooten is.

Gartner schat dat meer dan 60% van de IT-storingen in enterprise-omgevingen terug te leiden zijn naar configuratiefouten of ongeplande wijzigingen. Een vervuild image is een structurele bron van precies dat soort fouten.

Hoe verschilt dit per platform?

Niet elk platform gaat op dezelfde manier om met images. Dat bepaalt hoe groot de impact van slecht imagebeheer is.

Citrix, AVD en Parallels: een gedeeld image voor de hele pool

Bij Citrix Virtual Apps and Desktops, Azure Virtual Desktop en Parallels RAS kun je werken met een gedeeld image voor een groep virtuele machines. Je past het image aan, en de hele pool krijgt die aanpassing. Dat is een groot voordeel, maar het maakt de kwaliteit van dat ene image bepalend voor wat al je gebruikers elke dag meemaken.

Als dat image vervuild is, of als wijzigingen niet consistent worden bijgehouden, werkt de hele pool suboptimaal. En als je direct wijzigingen aanbrengt op het lopende image zonder het opnieuw op te bouwen, stapelt de vervuiling zich op met elke aanpassing.

RDS: elke server apart bijwerken

Bij Remote Desktop Services is er geen gedeeld imagemodel. Elke RDS-server is een zelfstandige machine. Een wijziging die je wilt doorvoeren, moet je op elke server apart uitvoeren. Bij vijf servers is dat nog te overzien. Bij twintig servers is het tijdrovend, foutgevoelig handwerk.

In de praktijk leidt dit ertoe dat servers na verloop van tijd van elkaar gaan afwijken. De ene server heeft een applicatie in versie 3.2, de andere nog in 3.0. Patches zijn op sommige machines uitgerold, op andere niet. Gebruikers krijgen een andere ervaring afhankelijk van op welke server ze landen. Dit heet configuration drift, en het is in RDS-omgevingen bijzonder lastig te beheersen zonder geautomatiseerde tooling.

Het probleem met bijwerken in plaats van opnieuw opbouwen

Stel: je werkt al drie jaar met hetzelfde basisimage. In die drie jaar zijn er tientallen updates doorgevoerd. Applicaties zijn bijgewerkt. Sommige zijn verwijderd. Er zijn drivers geinstalleerd en vervangen. Instellingen zijn aangepast.

Dat image is niet meer wat het ooit was. Het is een optelsom van alle wijzigingen die er ooit op zijn uitgevoerd. En elke wijziging die niet schoon is doorgevoerd, laat een spoor achter.

Denk aan:

• Software die is verwijderd maar registervermeldingen of restbestanden heeft achtergelaten
• Applicaties die zijn bijgewerkt via een installer die de vorige versie niet volledig heeft opgeruimd
• Diensten die zijn uitgeschakeld maar niet verwijderd
• Drivers die zijn vervangen terwijl de vorige versie nog in de driver store staat
• Configuratiebestanden die ooit zijn aangepast en nooit zijn teruggezet naar een bekende goede staat

Het gevolg is een image dat steeds zwaarder wordt, steeds meer ruis bevat en steeds moeilijker te doorgronden is. En als er dan iets misgaat, weet je niet meer waar je moet beginnen.

De oplossing is niet beter bijhouden. De oplossing is opnieuw opbouwen.

Bijkomend voordeel: makkelijker wisselen van hypervisor of platform

Een onderschat voordeel van werken met IaC is de vrijheid die het je geeft als je wilt migreren. Wie ooit een omgeving heeft verplaatst van VMware naar Citrix Hypervisor, of van on-premises naar de cloud, weet hoe lastig dat is als je image is opgebouwd met platform-specifieke tools.

Denk aan VMware Tools die diep verweven zijn met het image, of aan configuraties die specifiek zijn voor de onderliggende hypervisor. Bij een migratie moet je die tools verwijderen, de nieuwe tools installeren, en hopen dat er niets overblijft wat voor problemen zorgt. In een image dat jarenlang handmatig is bijgehouden, is dat een riskante operatie.

Met IaC bouw je het image opnieuw op voor de nieuwe omgeving. Je past het configuratiescript aan, je specificeert welke tools en drivers nodig zijn voor het nieuwe platform, en je start de build. Het resultaat is een schoon image, specifiek gebouwd voor de nieuwe omgeving, zonder resten van het oude platform.

Dat maakt migraties aanzienlijk eenvoudiger en minder riskant. Of je nu gaat van:

• VMware naar XenServer of Citrix Hypervisor
• On-premises naar Azure, AWS of een andere cloudprovider
• De ene versie van Windows Server naar de volgende
• Citrix naar AVD, of andersom

In al deze gevallen is een schoon, reproduceerbaar image je beste vertrekpunt. En IaC zorgt ervoor dat je dat altijd hebt.

Wat is Infrastructure as Code en wat lost het op?

Infrastructure as Code is een aanpak waarbij je je image niet bijhoudt, maar opnieuw opbouwt. Je beschrijft in code of een configuratiebestand wat er op het image moet staan: welke software, welke versies, welke instellingen. En elke keer dat je een nieuw image wilt, bouw je het op vanaf een schone basis.

Geen accumulatie van wijzigingen. Geen resten van oude software. Geen onverklaarbaar gedrag. Elke build is een schone start, met een volledig gedocumenteerde inhoud.

Het buildproces in de praktijk

Een IaC-gebaseerde imagepipeline werkt kort gezegd zo:

• Start met een schoon basisimage, Windows Server of Windows 11
• Configuratiescript installeert alle gewenste software in de juiste versies
• Windows-updates worden geintegreerd
• De juiste agent wordt geinstalleerd, voor Citrix, AVD, RDS of Parallels
• Applicatiespecifieke instellingen worden geconfigureerd
• Het image wordt gevalideerd en vrijgegeven voor uitrol

Elke stap is vastgelegd in de code. Elke versie van elke applicatie is gedocumenteerd. Je kunt altijd terug naar een eerdere build, en je kunt altijd precies zien wat er in het huidige image zit.

Hoe New Yard dit voor je regelt

Bij New Yard leveren we IaC-gebaseerd imagebeheer als doorlopende dienst. Dat betekent dat we op vaste momenten een nieuw image voor je bouwen, met alle updates en wijzigingen verwerkt, zonder dat jij of je team daarvoor handmatig aan de slag moet. Je betaalt een vast maandelijks bedrag en weet wat je krijgt.

Vaste buildmomenten, afgestemd op jouw omgeving

We bouwen standaard een nieuw image na elke Patch Tuesday, de maandelijkse Microsoft-updatecyclus. Maar we kunnen ook meerdere keren per maand een nieuw image maken. Applicaties als Microsoft Edge, Google Chrome en Adobe Reader krijgen regelmatig updates buiten de maandelijkse cyclus. Als je wilt dat die altijd actueel zijn in je omgeving, stemmen we de buildfrequentie daarop af.

Onbeperkt wijzigingen aanvragen

Je kunt onbeperkt wijzigingen aanvragen per image. Nieuwe applicatie erbij, een bestaande vervangen, een instelling aanpassen. Wij verwerken de wijziging in de code en bouwen daarna het image opnieuw op. Geen handmatig werk op de machines, geen risico op incomplete uitrol.

Gedetailleerd buildrapport na elke build

Na elke build ontvang je een volledig overzicht van alle geinstalleerde software, inclusief versienummers. Dat maakt het eenvoudig om de nieuwe build te vergelijken met de vorige. Je ziet precies welke applicaties zijn bijgewerkt, welke nieuw zijn toegevoegd en of je volledig up to date bent. Dat is niet alleen handig voor dagelijks beheer, maar ook waardevol voor compliance en audits.

De risico’s van doorgaan zoals je nu werkt

Onherleidbare incidenten

Als je omgeving niet consistent is, kost troubleshooting onevenredig veel tijd. Je weet niet of het probleem zit in de configuratie van die specifieke machine, in een update die ergens half is doorgevoerd, of in iets anders. Zonder reproduceerbare basis heb je geen referentiepunt om van te werken.

Securitygaten door incomplete patching

Patches die handmatig worden uitgerold, komen niet altijd op alle machines terecht. Dat levert inconsistente patchniveaus op. Microsoft-data laat zien dat meer dan 80% van succesvolle cyberaanvallen misbruik maakt van bekende kwetsbaarheden waarvoor patches beschikbaar waren. Een geautomatiseerde buildcyclus na Patch Tuesday sluit dat risico structureel af.

Afhankelijkheid van individuele kennis

Als de beheerder die weet hoe de omgeving in elkaar zit vertrekt of ziek is, sta je stil. Wat er precies op welke machine staat, is niet vastgelegd, of in elk geval niet actueel. Bij IaC is de code de documentatie. Altijd actueel, altijd inzichtelijk.

Schaalbaarheid

Groeit je omgeving? Dan schalen de problemen mee. Wat bij vijf machines te overzien is, wordt bij vijftig een beheerslast. IaC is van nature schaalbaar: je voegt een parameter toe en het buildproces regelt de rest.

Veelvoorkomende bezwaren en eerlijke antwoorden

‘We hebben al een golden image, dat werkt prima'

Een golden image is een goed vertrekpunt. Maar als je dat image al jaren bijhoudt met losse aanpassingen, stapelt de vervuiling zich op. IaC bouwt het image opnieuw op, schoon, elke keer. Dat is fundamenteel anders dan bijhouden.

‘Dit klinkt complex, wij hebben daar de kennis niet voor'

Die kennis hoef je ook niet in huis te hebben. Wij implementeren de pipeline en beheren die voor je. Jij geeft aan wat er moet veranderen, wij zorgen dat het correct in het image terechtkomt en dat de build klopt.

‘We zijn bezig met een platformmigratie'

Dan is dit het juiste moment. Met IaC bouw je een schoon image voor het nieuwe platform, zonder rommel van het oude. Of je nu van VMware naar XenServer gaat, of van on-premises naar de cloud, je vertrekt met een solide basis.

‘Dit kost nu meer tijd dan we hebben'

De implementatie vraagt een eenmalige investering. Maar kijk eens hoeveel tijd er nu maandelijks gaat in handmatig patchen, uitrollen van updates en oplossen van incidenten door inconsistente omgevingen. Die tijd verdien je terug.

Praktische checklist: waar sta jij nu?

• Zijn alle wijzigingen aan je images gedocumenteerd en reproduceerbaar?
• Kun je op dit moment een compleet nieuw image bouwen zonder handmatige stappen?
• Zijn alle machines in je pool op hetzelfde patchniveau?
• Heb je een actueel overzicht van alle geinstalleerde software inclusief versies?
• Kun je de huidige build vergelijken met de vorige om te zien wat er is veranderd?
• Is er een vaste cyclus voor het bijwerken van je image na Patch Tuesday?
• Kun je bij een platformmigratie een schoon image bouwen zonder resten van de oude omgeving?

Hoe meer keer je ‘nee' antwoordt, hoe groter de kans dat je imageomgeving stilletjes vervuilt en aan kwaliteit inboet.

Klaar om je imagebeheer te stroomlijnen?

Als je herkent wat in dit artikel wordt beschreven, is een vrijblijvend gesprek de logische volgende stap. We kijken samen naar je huidige omgeving, brengen de risico’s in kaart en laten zien hoe een geautomatiseerde imagepipeline er voor jouw situatie uitziet.

Plan een gratis adviesgesprek via newyard.nl. Geen verplichtingen, wel concrete inzichten.