Software updates beheren via SCCM is één van die taken die er op papier simpel uitziet, maar in de praktijk een eigen leven gaat leiden zodra je even niet oplet. Een vergeten deadline hier, een te brede collection daar — en voor je het weet bel je op vrijdagmiddag met een gebruiker wiens laptop halverwege een Teams-call besluit te rebooten. Dit artikel helpt je de grip te houden, van ADR tot maintenance window.
Begrijp Eerst Je Update Lifecycle
Voordat je ergens op klikt, is het goed om even stil te staan bij hoe SCCM updates eigenlijk verwerkt. Het begint bij de Software Update Point — de SUP — die synchroniseert met Microsoft Update. Wat die synchronisatie oplevert, belandt in je Software Updates node. Daarna bepaal jij wat er mee gebeurt.
De lifecycle ziet er globaal zo uit:
- Synchronisatie: SUP haalt metadata op van updates
- Compliance scan: clients rapporteren welke updates ze nodig hebben
- Deployment: jij pusht de updates naar een collection
- Installatie: de client installeert, al dan niet binnen een maintenance window
- Rapportage: je ziet of het gelukt is
Dat klinkt netjes en lineair. In werkelijkheid loopt stap drie en vier regelmatig door elkaar, zijn er clients die de compliance scan om mysterieuze redenen overslaan, en heb je altijd wel één machine die zijn eigen agenda volgt. Maar de structuur kennen helpt enorm bij troubleshooting.
Automatic Deployment Rules: Vriend én Vijand
ADR’s zijn het werkpaard van een goed ingericht patchproces. Je configureert ze één keer, en elke Patch Tuesday rolt er automatisch een nieuwe Software Update Group uit die wordt gedeployed naar je collection. Heerlijk. Tot het misgaat.
Het meest voorkomende probleem: een ADR die te breed filtert en ineens ook driver-updates of feature upgrades meepakt die je helemaal niet wilt uitrollen. Controleer daarom altijd je filterinstellingen:
- Stel Product en Classification nauwkeurig in — liever te smal dan te breed
- Gebruik Supersedence regels om verouderde updates buiten de deur te houden
- Zet een maximum runtime op je deployments, zodat een update die ineens drie uur duurt niet je hele maintenance window opeet
Een andere klassieker: de ADR draait, de Software Update Group wordt aangemaakt, maar er worden geen updates gedeployed. Negen van de tien keer is de collection leeg of heeft de evaluatie nog niet plaatsgevonden. Geef clients de tijd om hun hardware inventory en compliance scan te voltooien voor je conclusies trekt. SCCM is snel — maar niet altijd zo snel als jij wilt.
Collections Goed Inrichten Loont Altijd
Wie heeft er nou niet een keer een update gedeployed naar de verkeerde collection? Exact. Het is een rite of passage in de sysadmin-wereld. De oplossing is niet om minder te deployen, maar om je collection-structuur zo in te richten dat de kans op misclicks minimaal is.
Een paar principes die goed werken in de praktijk:
Gebruik een ring-model
Begin met een kleine pilotgroep — je eigen machines, een paar testgebruikers die je vertrouwt — en rol daarna geleidelijk uit naar bredere groepen. Zo vang je problemen op voordat ze de hele organisatie raken.
Sluit altijd uit wat je niet wilt raken
Servers in een aparte collection, kritieke systemen met een afwijkend patchschema, machines die in een speciale staat zitten — zet ze in een exclude collection en voeg die toe aan je deployment rules. Dat kost vijf minuten en bespaart je uren aan gedoe.
Benoem collections consistent
“Patch – Productie – Ring 2 – Werkstations” is een naam die voor zichzelf spreekt. “Tijdelijk test groep NIEUW” is een ramp die wacht om te gebeuren. Maak afspraken met je team en houd je eraan.
Maintenance Windows: De Kunst van het Plannen
Een maintenance window is je vangnet. Zonder maintenance windows kunnen updates op elk willekeurig moment installeren — inclusief dat ene moment dat een directeur midden in een presentatie zit. Met maintenance windows geef je de client een tijdslot waarbinnen updates mogen worden geïnstalleerd en de machine mag rebooten.
Klinkt eenvoudig. Maar er zijn een paar valkuilen:
Het maintenance window moet lang genoeg zijn. Als jij een window van één uur instelt maar je update package heeft een runtime van 90 minuten, gaat er niets installeren. SCCM checkt of de geschatte runtime past binnen het resterende window. Past het niet, dan wacht de client tot het volgende window. Dat kan een week later zijn.
Zorg ook dat je meerdere windows overweegt voor verschillende device-typen. Laptops die ‘s avonds niet aanstaan hebben niets aan een nachtelijk window. Overweeg een tweede window in de ochtend, of zorg dat je deadline-based deployments inzet zodat er een stok achter de deur zit.
En vergeet de reboot behavior niet. Je kunt instellen dat een client na installatie automatisch reboot, of dat de gebruiker zelf een moment kiest. In een omgeving met veel thuiswerkers is de tweede optie vaak vriendelijker — maar zorg dan wel dat je een maximale uitstelperiode instelt, anders schuiven mensen die reboot wekenlang voor zich uit.
Troubleshooting: Waar Kijk Je Eerst?
Updates deployen en dan niks zien gebeuren. Welkom in het dagelijks leven. Gelukkig is SCCM vrij goed in loggen — je moet alleen weten waar je moet kijken.
Op de client:
- WindowsUpdate.log — wat zegt Windows Update zelf?
- WUAHandler.log — hoe communiceert de SCCM client met de Windows Update Agent?
- UpdatesDeployment.log — is de deployment ontvangen en wat is de status?
- RebootCoordinator.log — als reboots niet plaatsvinden, kijk hier
Op de server:
- SUPSetup.log — problemen met de Software Update Point zelf
- WCM.log — configuratie van de SUP
- Wsyncmgr.log — synchronisatieproblemen met upstream
Een veelvoorkomend scenario: de update staat als “Required” in je dashboard, maar de client installeert niet. Controleer eerst of de client überhaupt een deployment heeft ontvangen via UpdatesDeployment.log. Staat er niets? Dan is de client waarschijnlijk niet in de juiste collection, of de collection-evaluatie is nog niet bijgewerkt. Forceer een Machine Policy Retrieval & Evaluation Cycle via de Configuration Manager applet op de client en wacht een paar minuten.
Staat er wél een deployment in de log maar gebeurt er niets? Kijk dan naar het maintenance window en de deadline. Misschien wacht de client gewoon netjes op het juiste moment.
Rapportage: Weet Wat Er Gaande Is
Een patchproces zonder rapportage is rijden zonder dashboard. Je weet pas dat er iets mis is als iemand belt. Dat is niet ideaal.
SCCM heeft ingebouwde rapporten voor software updates, en die zijn best bruikbaar als je weet welke je nodig hebt. De meest waardevolle:
- Compliance by collection: hoeveel procent van je machines heeft de updates geïnstalleerd?
- Computers with a specific update: handig als er een specifieke patch is die je wilt valideren
- Updates required but not deployed: updates die clients nodig hebben maar die jij nog niet hebt gedeployed — een mooi overzicht om gaten in je ADR te ontdekken
Wil je meer flexibiliteit? Dan is de combinatie van SCCM-data met een apart rapportagetool een logische stap. Maar zelfs met alleen de ingebouwde rapporten kom je een heel eind, zolang je ze ook daadwerkelijk bekijkt. Plan een wekelijks moment in om je compliance te checken, liefst de dag na je maintenance window. Dan weet je snel genoeg of er actie nodig is.
Tot Slot
Software updates in SCCM zijn nooit echt “klaar”. Het is een doorlopend proces van deployen, monitoren, troubleshooten en bijsturen. Maar als je je ADR’s goed hebt ingericht, je collections logisch zijn opgebouwd, je maintenance windows realistisch zijn en je weet waar je moet kijken als er iets misgaat — dan is het een beheersbaar proces in plaats van een wekelijkse stressbron.
En ja, er zal altijd een machine zijn die zich niet gedraagt. Eén laptop ergens in een vergeten OU die nooit synchroniseert, altijd non-compliant staat en niemand weet van wie hij is. Dat hoort erbij. De rest van je omgeving draait gewoon. En dat is precies goed genoeg.