Maintenance windows. Die kleine instelling in je collection properties die je misschien ooit hebt aangemaakt, daarna nooit meer hebt aangeraakt, en waarvan je stiekem hoopt dat ze gewoon doen wat ze moeten doen. Spoiler: ze doen dat vaak niet, en dat is bijna altijd jouw schuld. Niet die van Microsoft. Van jou. Maar geen zorgen — we lopen er samen doorheen.
Wat een Maintenance Window Eigenlijk Doet (en Niet Doet)
Een maintenance window vertelt SCCM wanneer het deployment-activiteiten mag uitvoeren op de machines in een collection. Software installaties, task sequences, software updates — ze wachten allemaal netjes tot het raam opengaat. Klinkt simpel. Is het ook, in theorie.
Het probleem zit hem in wat mensen verwachten versus wat er werkelijk gebeurt. Een maintenance window is geen garantie dat een deployment ook daadwerkelijk wordt uitgevoerd. Het is een toestemmingsvenster, geen planningsgarantie. Als de client net een herstartcyclus mist, of de deployment deadline valt buiten het raam, dan gebeurt er gewoon niets. En dan sta je maandagochtend te kijken naar een rapport vol machines die de patch van vrijdagnacht niet hebben gekregen.
De Meest Gemaakte Fout: Overlappende Windows
Hier gaat het klassiek mis. Je hebt een collection voor servers, een voor werkstations, en misschien nog een voor die ene afdeling die altijd speciale behandeling nodig heeft. Elke collection heeft zijn eigen maintenance window. Tot zover prima.
Maar dan: een machine zit in meerdere collections. En elke collection heeft een ander raam. Wat doet SCCM? Het neemt de union van alle actieve windows. Dat betekent dat als één van die collections een raam heeft van 23:00 tot 01:00 en een andere van 06:00 tot 08:00, de machine in principe op beide momenten updates kan ontvangen. Is dat wat je wilt voor je productieserver? Waarschijnlijk niet.
De oplossing is simpel maar vraagt discipline:
- Gebruik dedicated collections voor maintenance windows, niet je bestaande deployment collections
- Documenteer welke machines in welke window-collections zitten
- Controleer regelmatig op onbedoelde overlap via queries
Software Updates vs. All Deployments: Ken Het Verschil
Dit is er eentje die mensen regelmatig verrast. Wanneer je een maintenance window aanmaakt, kies je een type: All deployments of Software updates only. Lijkt logisch. Is het ook. Maar de implicaties zijn groter dan je denkt.
Als je een window hebt van het type Software updates only, dan vallen task sequences en applicatie-deployments daar buiten. Die worden pas uitgevoerd als er een All deployments window actief is. Heb je die niet ingesteld? Dan wacht je deployment tot sint-juttemis. En dan bel je de servicedesk, en de servicedesk belt jou, en niemand is blij.
Gebruik Software updates only windows specifiek voor je patching, en zorg dat je altijd ook een All deployments window hebt voor overige deployments. Zelfs als die twee qua tijd overlappen — dat is prima. SCCM is slim genoeg om beide te respecteren.
Hoe Je Controleert of Je Windows Werken
Vertrouwen is goed, controle is beter. Zeker als het om maintenance windows gaat. Er zijn een paar manieren om te checken of je configuratie doet wat je denkt dat hij doet.
Op de client zelf is de execmgr.log je beste vriend. Daarin zie je letterlijk terug of een deployment is uitgesteld vanwege een maintenance window, en wanneer de volgende poging gepland staat. Zoek op “maintenance window” in die log en je weet binnen dertig seconden wat er speelt.
Op de server kant kun je via de console — collection properties — de geconfigureerde windows inzien, maar voor een overzicht over meerdere collections heen is een WMI-query of een PowerShell-script handiger. Iets als het opvragen van SMS_ServiceWindow via WMI geeft je snel inzicht in wat er allemaal geconfigureerd staat, zonder dat je elke collection handmatig moet openen.
Wanneer Je Géén Maintenance Window Moet Gebruiken
Ja, dit is ook een optie. Niet elke collection heeft een maintenance window nodig. Voor testomgevingen, pilotgroepen of je eigen beheermachines kan het juist handig zijn om géén window in te stellen, zodat deployments zo snel mogelijk worden uitgevoerd.
Het gevaar is dat je als reflex overal maintenance windows instelt omdat het “professioneel” voelt. Maar een window die te smal is, of die verkeerd is geconfigureerd, zorgt voor meer problemen dan helemaal geen window. Begin met de collections waar het écht uitmaakt — productieservers, kritieke werkstations — en bouw van daaruit.
Maintenance windows zijn een krachtig mechanisme, maar ze vragen om onderhoud. Ironisch, voor iets dat zelf over onderhoud gaat. Check je configuratie regelmatig, test met een kleine groep machines voor je breed uitrolt, en vertrouw nooit blind op wat je ooit hebt ingesteld. Want SCCM onthoudt alles. Jij vergeet het. Dat is het echte probleem.