Software updates zijn het slagveld waar menig sysadmin zijn kalmte verliest. Je kent het wel: het tweede dinsdag van de maand nadert, de WSUS-synchronisatie loopt vast, en ergens in de organisatie staat een machine die al drie maanden geen updates heeft binnengekregen omdat hij toevallig in een verkeerde collection zat. Of erger: hij zat in de goede collection, maar de deployment stond op “Required” zonder maintenance window, en nu heeft een directeur om drie uur ‘s nachts een reboot gekregen. Welkom in de wereld van software update management met SCCM. Laten we er samen iets zinnigs van maken.
De basis: begrijp hoe SCCM updates verwerkt
Voordat je iets gaat deployen, is het handig om te snappen wat er achter de schermen gebeurt. SCCM haalt zijn updateinformatie op via synchronisatie met een Software Update Point (SUP), die op zijn beurt praat met WSUS. Die synchronisatie bepaalt welke updates er überhaupt beschikbaar zijn in je console. Als je updates ziet staan als “Not yet downloaded” of helemaal niet ziet, begin je troubleshooting dus altijd bij de SUP en de WSUS-synchronisatiestatus.
Na de synchronisatie doorloopt een update een paar statussen: van gesynchroniseerd naar gedownload naar gedeployed. Dat klinkt simpel, maar in de praktijk zijn er genoeg momenten waarop het ergens vastloopt. De WCM.log, WSUSCtrl.log en SUPSetup.log zijn je beste vrienden als je wilt begrijpen wat er misgaat. Ken je die logs nog niet uit je hoofd? Maak er een gewoonte van ze te openen als eerste stap bij elk update-probleem.
Een ding dat veel mensen vergeten: SCCM en WSUS zijn niet hetzelfde, maar ze zijn wel afhankelijk van elkaar. Als WSUS ziek is, is je update management ook ziek. Houd die relatie in de gaten.
Software Update Groups: de onbezongen helden
Een Software Update Group (SUG) is de container waarmee je updates bij elkaar pakt voor deployment. Je kunt hier creatief mee zijn, of je kunt het zo aanpakken dat je over zes maanden niet meer weet wat je aan het doen bent. Spoiler: de tweede optie is populairder dan je denkt.
Wat werkt goed? Maak een logische naamgeving die je over een jaar nog begrijpt. Denk aan iets als “Windows 10 – Security Updates – Q3” of “Server 2019 – Cumulative Updates – Productie”. Vermijd namen als “Test123” of “NieuweUpdates_definitief_v2”. Ja, ook al is het maar tijdelijk. Tijdelijk is in IT notoir permanent.
Houd je SUGs ook niet te groot. Een update group met driehonderd updates is moeilijk te beheren en troubleshooten. Splits ze op per producttype, per kwartaal, of per omgeving. Dat kost iets meer tijd bij het aanmaken, maar het scheelt enorm als je later wilt begrijpen waarom een specifieke machine een bepaalde update niet heeft gekregen.
- Gebruik consistente naamconventies voor SUGs
- Splits op per product of omgeving
- Archiveer oude SUGs in plaats van ze te verwijderen (je wilt de history bewaren)
- Koppel een SUG altijd aan maximaal één actieve deployment per omgeving
Maintenance Windows: jouw reddingslijn
Als er één ding is dat de relatie tussen sysadmin en eindgebruiker kan maken of breken, is het de maintenance window. Stel ze in, gebruik ze consequent, en communiceer erover. Klinkt simpel. Is het ook, als je het eenmaal goed hebt ingericht.
Een maintenance window geef je op collection-niveau. Dat betekent dat je goed moet nadenken over je collection-structuur. Heb je aparte collections voor servers, werkstations, laptops van de directie? Mooi. Geef ze elk hun eigen maintenance window die past bij de gebruikspatronen van die groep. Servers in productie raken liever ‘s nachts in het weekend. Werkstations van kantoorpersoneel kunnen overdag niet zomaar rebooten. Laptops van mensen die altijd onderweg zijn, zijn een verhaal apart — die zijn er nooit als je wilt, en altijd online als je ze even met rust wil laten.
Een veelgemaakte fout is het instellen van een maintenance window die te kort is. Als je window één uur is maar de updates plus reboot twee uur nodig hebben, gaat er niets geïnstalleerd worden. SCCM begint gewoon niet aan een installatie als hij inschat dat het niet past binnen het window. Controleer dus altijd of je window realistisch is voor de hoeveelheid updates die je deployt.
Nog een tip: maak onderscheid tussen maintenance windows voor software-installatie en voor updates. Je kunt in SCCM aangeven of een window geldt voor alle deployments, alleen voor software updates, of alleen voor task sequences. Gebruik dat onderscheid — dan voorkom je dat een grote applicatie-deployment toevallig in het midden van je update-window begint.
Deployment rings: niet iedereen tegelijk
Wie alles tegelijk uitrolt naar de hele organisatie, leeft gevaarlijk. Dat weet je. En toch gebeurt het. Misschien onder tijdsdruk, misschien omdat de collection-structuur er niet klaar voor is, misschien omdat iemand hoger in de hiërarchie denkt dat sneller altijd beter is. Maar een deployment die op vijfduizend machines tegelijk wordt uitgerold en dan problemen veroorzaakt, is een veel grotere crisis dan één die je in fases had uitgerold.
Werk met deployment rings. De klassieke opzet is drie lagen:
- Pilot: een kleine groep machines, bij voorkeur van mensen die snappen wat er kan gebeuren (of van jezelf)
- Breed: een grotere groep, maar niet alles — zeg twintig tot dertig procent van je omgeving
- Productie: de rest, uitgerold nadat de vorige ringen geen problemen hebben opgeleverd
Tussen die ringen bouw je tijd in. Minimaal een paar dagen, bij voorkeur een week. Dat geeft je de ruimte om compliance-rapporten te bekijken, problemen te signaleren en bij te sturen voordat het te laat is. Ja, dat betekent dat sommige machines langer wachten op updates. Dat is een bewuste afweging, geen falen.
Automatische deployment rules (ADR’s) zijn hier je bondgenoot. Je kunt ze zo instellen dat ze nieuwe updates automatisch toevoegen aan de juiste SUG en deployen naar de juiste collection. Met de juiste timing en een goede collection-structuur rolt je patch-cyclus dan bijna vanzelf. Bijna. Want WSUS.
Compliance monitoring: weet wat er écht gebeurt
Een deployment aanmaken is één ding. Weten of het ook werkt, is een ander. Compliance monitoring is het deel dat veel mensen overslaan tot er een audit aankomt of een incident waarbij iemand vraagt: “Maar was die machine wel up to date?” Dan wil je een antwoord hebben.
SCCM heeft ingebouwde rapporten voor software update compliance. Die zijn bruikbaar, maar niet altijd even intuïtief. De rapporten in de categorie “Software Updates – A Compliance” geven je een goed startpunt. Kijk naar compliance per collection, per update group, en per individuele update. Zo zie je snel of er patronen zijn — bepaalde machines die structureel achterblijven, bepaalde updates die nooit lijken aan te slaan.
Wat je ook wilt monitoren: de reden waarom een machine niet compliant is. Dat kan zijn omdat de update nog niet gedownload is, omdat er een reboot in de wacht staat, omdat de machine offline was tijdens het deployment window, of omdat er een echte fout is opgetreden. Die laatste categorie vraagt om actie. De rest vraagt om geduld of een betere maintenance window.
Stel een routine in: bekijk wekelijks je compliance-dashboards. Niet maandelijks, niet alleen als er brand is. Wekelijks. Dan zie je problemen aankomen voordat ze groot worden, en kun je bijsturen zonder crisismanagement.
Veelgemaakte fouten en hoe je ze voorkomt
Laten we eerlijk zijn: iedereen maakt fouten in SCCM. De kunst is om ze te herkennen, ervan te leren, en ze niet twee keer te maken. Hier zijn de klassiekers die je wilt vermijden.
Deployen zonder te testen. Altijd eerst naar je pilot collection. Altijd. Ook als de update “gewoon” een security patch is. Soms zitten er cumulatieve updates bij die gedrag veranderen.
Vergeten dat een ADR ook gewoon doorloopt als je op vakantie bent. Zet een collega als backup in, of pauzeer de ADR als je weet dat er niemand is om te monitoren.
Collections targeten op basis van verouderde queries. Als je collection-query niet meer klopt met je omgeving, target je de verkeerde machines. Controleer je dynamic collections regelmatig.
De deadline te strak zetten. Een deadline van “morgen” op een required deployment zonder maintenance window is een recept voor boze eindgebruikers en onverwachte reboots.
Nooit de logs lezen. UpdatesDeployment.log, UpdatesHandler.log, WindowsUpdate.log op de client — ze vertellen je precies wat er is misgegaan. Gebruik ze.
Software update management in SCCM is geen rocket science, maar het vraagt wel om structuur, discipline en een beetje gevoel voor wat er kan misgaan. Bouw die structuur op, houd je aan je eigen regels, en je zult merken dat patch Tuesday een stuk minder stressvol wordt. En als het toch misgaat? Dan weet je nu tenminste waar je moet kijken.