Stel je voor: het is vrijdagmiddag, de helpdesk gaat om vijf uur dicht, en dan begint SCCM rustig aan een reeks software-updates te pushen naar de laptops van je salesteam. Feestje. Maintenance windows zijn er precies voor bedoeld om dit soort taferelen te voorkomen — maar ze worden vaker verkeerd geconfigureerd dan je zou denken. Tijd om dat recht te zetten.
Wat is een Maintenance Window eigenlijk?
Een maintenance window is in de kern een tijdsvenster dat je koppelt aan een device collection. Binnen dat venster mag SCCM acties uitvoeren: software installeren, updates deployen, task sequences starten. Buiten dat venster? Niets. De client wacht netjes tot het venster open is.
Dat klinkt simpel, en in theorie is het dat ook. Maar de nuances zitten in de details — en die details bijten. Een maintenance window heeft een beginttijd, een eindtijd, een recurrencepatroon en een type. Dat type is meteen al een struikelblok waar veel beheerders overheen lezen.
De drie typen en waarom het type ertoe doet
SCCM kent drie smaken maintenance windows:
- All deployments — alles mag, software én updates
- Software Updates — alleen update-deployments
- Task Sequences — alleen task sequences
Als je een collection hebt met zowel een “All deployments”-window als een “Software Updates”-window, dan gelden ze naast elkaar. Een software update kijkt naar het meest restrictieve venster dat van toepassing is. Nee, wacht — dat is precies andersom dan je intuïtief denkt. Een update mag draaien als er een geldig venster is van het type “Software Updates” óf “All deployments”. Ze concurreren niet, ze vullen aan.
Dit is het moment waarop veel mensen hun eerste grijs haar krijgen. Want wie heeft er nou niet een keer een collection geconfigureerd met alleen een “Software Updates”-window, en zich daarna afgevraagd waarom die applicatie-deployment gewoon niet uitrolde? Het antwoord is simpel: applicaties vallen onder “All deployments”, en als dat type window er niet is, rijdt de deployment nergens naartoe.
Recurrence: wekelijks, maandelijks of eenmalig?
Je kunt een maintenance window instellen als eenmalig event, wekelijks terugkerend of maandelijks. Voor patchcycli kies je bijna altijd maandelijks, maar let op hoe je dat configureert. Je hebt de keuze tussen een vaste datum (“de 15e van de maand”) of een relatieve dag (“de derde dinsdag van de maand”). Die tweede optie is bijna altijd wat je wilt, want Patch Tuesday valt altijd op de tweede dinsdag — en je wilt je maintenance window daar een paar dagen achteraan laten lopen.
Een veelgemaakte fout is het instellen van een vaste datum die soms niet bestaat. Februari heeft geen 31e. SCCM is daar niet altijd even vriendelijk in, en het window valt dan gewoon weg die maand. Gebruik dus altijd relatieve dag-instellingen voor maandelijkse windows. Dat scheelt je een hoop “waarom zijn de updates niet uitgerold deze maand”-tickets.
Wekelijkse windows zijn handig voor servers die elke week een korte onderhoudsperiode hebben, of voor testgroepen waar je snel wil kunnen itereren. Eenmalige windows gebruik je voor ad-hoc situaties — een grote migratie, een noodpatch, dat soort dingen.
Overlappende windows en de valkuil van meerdere collections
Devices kunnen lid zijn van meerdere collections. En elke collection kan zijn eigen maintenance windows hebben. SCCM combineert die windows: als een device in twee collections zit die elk hun eigen window hebben, dan heeft dat device de unie van alle windows beschikbaar.
Dat is handig, maar het kan ook voor verrassingen zorgen. Stel dat je een strikt nachtelijk window hebt ingesteld voor een gevoelige servergroep, maar die servers zitten ook in een generieke “All Servers”-collection met een ruimer dagvenster. Dan heb je feitelijk een groter venster dan je dacht. Updates kunnen overdag uitrollen terwijl jij ervan uitging dat dat niet kon.
De oplossing is simpel maar vraagt discipline: houd je collections schoon en overzichtelijk, en documenteer welke windows waar op zitten. Gebruik limiting collections verstandig. En controleer regelmatig in de client-instellingen of de windows op een device kloppen via de Configuration Manager-applet in het configuratiescherm — daar zie je onder “Maintenance Windows” precies welke vensters een client ziet.
Wat gebeurt er als een deployment buiten het window valt?
De client heeft een deployment ontvangen, maar er is geen geldig maintenance window actief. Wat doet SCCM dan? Het hangt af van hoe de deployment is geconfigureerd.
Als de deployment verplicht is (required) en de deadline is verstreken, wacht de client op het eerstvolgende geldige window. De installatie wordt niet geforceerd buiten het window — tenzij je de optie “Allow clients to install software outside of maintenance windows” hebt aangevinkt in de deployment-instellingen. Die optie bestaat echt, en hij doet precies wat hij zegt: hij negeert het window volledig. Handig voor noodgevallen, gevaarlijk als standaard.
Voor beschikbare deployments (available) is het nog eenvoudiger: de gebruiker kan zelf installeren via Software Center, maar de automatische installatie wacht op het window. Geen window, geen automatische actie.
Een deadline die valt binnen een window is het ideaalscenario. De client pakt de installatie op zodra het window opengaat, mits de deadline al verstreken is of binnen het window valt. Plan je deadlines dus bewust: zet ze op het begin van je maintenance window, of iets ervoor, zodat de client meteen aan de slag gaat als het venster opent.
Maintenance windows en herstarts: de combinatie die altijd pijn doet
Software-updates vereisen vaak een herstart. En herstarts buiten kantooruren zijn precies waarom maintenance windows bestaan. Maar hier zit een subtiliteit die regelmatig misgaat.
Als een update is geïnstalleerd maar de herstart nog niet heeft plaatsgevonden, en het maintenance window sluit voordat de herstart kan worden afgerond — dan wacht SCCM op het volgende window voor de herstart. Dat is het gewenste gedrag. Maar als je window te kort is om zowel de installatie als de herstart te voltooien, eindig je met een systeem dat half gepatcht is en wacht op een reboot die pas over een week komt.
Vuistregel: maak je windows ruim genoeg. Een uur voor een handjevol updates is aan de krappe kant. Twee uur is comfortabeler. En voor servers met zware patching of meerdere updates achter elkaar: drie uur of meer. Reken ook de reboot-tijd mee — een server die lang nodig heeft om op te starten, telt mee in je window.
Er is ook een instelling op collection-niveau die bepaalt of SCCM een herstart mag forceren buiten het maintenance window als die herstart dringend is. Die instelling staat standaard uit, en dat is maar goed ook. Zet hem alleen aan als je heel goed weet wat je doet en waarom.
Troubleshooting: waarom doet mijn window het niet?
Je hebt een window geconfigureerd, de deadline is verstreken, maar er gebeurt niets. Herkenbaar. Hier is een checklist die je in de meeste gevallen verder helpt:
- Controleer het window-type: is het “All deployments” of “Software Updates”? En wat is het type van je deployment?
- Controleer de tijdzone: maintenance windows worden opgeslagen in de tijdzone van de siteserver. De client converteert dat naar zijn lokale tijd. Als je siteserver in UTC staat en je client in UTC+2, kan het window twee uur verschoven zijn ten opzichte van wat je verwacht.
- Controleer of het device in de juiste collection zit: klinkt basaal, maar collection membership evalueert niet altijd direct. Forceer een machine policy refresh en een collection membership evaluation als je twijfelt.
- Kijk in de CAS.log of UpdatesDeployment.log op de client: daar zie je exact waarom een installatie wel of niet wordt gestart, inclusief meldingen over maintenance windows.
- Controleer of er conflicterende windows zijn: meerdere windows van hetzelfde type op dezelfde collection kunnen soms voor verwarring zorgen, al lost SCCM dat normaal gesproken netjes op.
De tijdzone-valkuil is verreweg de meest voorkomende oorzaak van “het window werkt niet”-klachten. Zeker in omgevingen met servers in meerdere regio’s. Documenteer je tijdzone-aanpak en wees consistent.
Een schone aanpak voor de lange termijn
Maintenance windows zijn geen set-and-forget configuratie. Ze verdienen periodieke aandacht. Klopt de patchcyclus nog? Zijn er nieuwe servergroepen bijgekomen die een eigen window nodig hebben? Zijn er windows die overlappen op een manier die je niet meer wilt?
Een goede aanpak is om maintenance windows te beheren vanuit een klein aantal goed gedocumenteerde collections, met duidelijke naamgevingsconventies. Iets als “MW_Servers_NachtelijkPatch_Maandelijks” is een stuk begrijpelijker dan “Collection 47” als je om twee uur ‘s nachts in een incident zit. En geloof me, dat moment komt.
Koppel je windows aan je CMDB of documentatiesysteem zodat je altijd weet welk device welk window heeft. Dat is misschien wat extra werk aan de voorkant, maar het scheelt je een hoop zoekwerk op het moment dat het er écht toe doet — namelijk als er iets misgaat en je moet bewijzen dat de patch wél of juist niet had mogen uitrollen.
Maintenance windows zijn een van die SCCM-functies die je pas echt leert waarderen als je ze een keer verkeerd hebt gehad. En dan wil je ze nooit meer missen.