Je hebt een mooie deployment klaarstaan. Software getest, collection goed ingericht, deadline ingesteld. En dan belt iemand van de helpdesk dat er midden in een presentatie voor de directie toch echt een reboot is uitgevoerd op de laptop van de CFO. Welkom bij het leven zonder goed geconfigureerde maintenance windows. Het is een van die dingen die je maar één keer meemaakt voordat je besluit dat je dit voortaan echt serieus gaat aanpakken.
Maintenance windows zijn in SCCM een van de meest krachtige — en tegelijk meest onderschatte — mechanismen die je tot je beschikking hebt. Ze bepalen wanneer clients bepaalde acties mogen uitvoeren: software installeren, updates toepassen, task sequences draaien. Geen window, geen actie. Zo simpel is het in theorie. In de praktijk zit er wat meer nuance in, en die nuance wil je begrijpen voordat je ze klakkeloos uitrolt.
Wat Maintenance Windows Precies Doen (En Wat Niet)
Een maintenance window is gekoppeld aan een collection. Je definieert een tijdsvenster — zeg, elke dinsdagavond van 22:00 tot 02:00 — en de clients in die collection mogen alleen binnen dat venster bepaalde acties uitvoeren. Dat klinkt waterdicht, maar er zijn een paar dingen die beginners regelmatig verrassen.
Ten eerste: maintenance windows blokkeren niet alles. Ze zijn van toepassing op software deployments, software updates en task sequences — maar alleen als die deployment ook zo geconfigureerd is dat hij rekening houdt met het window. Een deployment die je instelt op “zo snel mogelijk installeren, negeer maintenance windows” trekt zich er gewoon niets van aan. Dat is een bewuste keuze die je per deployment maakt, en het is precies de reden waarom je die instelling altijd even dubbelcheckt voordat je op Deploy klikt.
Ten tweede: een client kan lid zijn van meerdere collections, en dus ook meerdere maintenance windows hebben. SCCM combineert die windows. Als collection A een window heeft van 22:00 tot 23:00 en collection B een window van 23:00 tot 00:00, dan heeft de client die in beide collections zit effectief twee uur beschikbaar. Dat is handig als je flexibiliteit wilt opbouwen, maar het kan ook onverwachte effecten hebben als je niet precies weet welke collections een device in zit.
- Software deployments: worden uitgesteld tot het eerstvolgende window
- Software updates: zelfde verhaal, tenzij een deadline is overschreden en je dat zo hebt ingesteld
- Task sequences: wachten braaf op hun beurt
- Scripts en CMPivot: die trekken zich er niets van aan — die zijn real-time
Verschillende Window Types en Wanneer Je Welke Gebruikt
SCCM kent drie typen maintenance windows, en het onderscheid is relevanter dan het op het eerste gezicht lijkt.
Het algemene maintenance window is het standaard type. Dit geldt voor alle activiteiten die windows respecteren: software deployments, updates, task sequences. Als je maar één type window gebruikt, is dit het.
Dan heb je het software updates maintenance window. Dit geldt uitsluitend voor software updates — Patch Tuesday-deployments, cumulative updates, dat soort werk. Het slimme hieraan is dat je hiermee een apart venster kunt definiëren voor updates, los van je algemene deployments. Praktisch voorbeeld: je wilt dat applicatie-deployments overdag mogen plaatsvinden (want die zijn getest en veilig), maar dat patches alleen ‘s nachts worden gerold. Je maakt dan een algemeen window voor overdag en een software updates window voor de nacht. Beide bestaan naast elkaar zonder dat ze in conflict komen.
Tot slot is er het task sequence maintenance window. Dat geldt alleen voor task sequences. Handig als je OS-deployments of grote migraties wilt scheiden van je reguliere patch- en applicatiewerk.
Waarom is dit onderscheid belangrijk? Omdat je anders in de situatie terechtkomt dat een kritieke patch niet wordt geïnstalleerd omdat er geen geldig software updates window beschikbaar is — ook al is er wel een algemeen window. SCCM is hier vrij strikt in. Als een deployment een specifiek windowtype verwacht en dat type is niet beschikbaar, wacht hij. Punt.
Een paar praktische richtlijnen die je jezelf wat hoofdpijn besparen:
- Gebruik beschrijvende namen voor je windows, zodat je over zes maanden nog weet wat wat is
- Documenteer welke collections welke windows hebben — klinkt saai, is goud waard
- Test altijd met een kleine pilot-collection voordat je windows uitrolt naar productie
- Vergeet niet dat clients hun windowinformatie ophalen via policy — een client die al een tijdje offline is geweest, heeft mogelijk verouderde windowinformatie
Troubleshooting: Waarom Installeert Die Deployment Niet?
Dit is het moment waarop maintenance windows van “handig mechanisme” veranderen in “mysterieuze blokkade”. Je deployment staat klaar, de deadline is verstreken, en toch gebeurt er niets op de client. De eerste vraag die je jezelf moet stellen: heeft deze client überhaupt een geldig maintenance window, en valt de huidige tijd daarbinnen?
Kijk op de client zelf in het Software Center. Onder het tabblad voor de betreffende applicatie of update zie je wanneer de volgende installatie is gepland. Als daar een tijdstip staat dat ver in de toekomst ligt, weet je genoeg: de client wacht op zijn window.
Voor dieper graven ga je naar de logbestanden. AppEnforce.log en UpdatesDeployment.log zijn je vrienden hier. Zoek naar meldingen over maintenance windows — je zult termen tegenkomen als “outside maintenance window” of “no maintenance window available”. Dat vertelt je precies waarom er niets gebeurt.
Een veelvoorkomende situatie: een device zit in een collection met een maintenance window, maar dat window is inmiddels verlopen en het volgende is pas over vijf dagen. De deployment heeft een deadline van gisteren. Resultaat: de client wacht braaf op het volgende window, terwijl jij je afvraagt waarom er niets gebeurt. Oplossing: controleer of de deployment zo is ingesteld dat hij buiten het window mag installeren als de deadline is overschreden — dat is een aparte checkbox die je bewust aan moet zetten.
Nog een klassieke valkuil: de client heeft helemaal geen maintenance window, maar de deployment is ingesteld op “alleen installeren tijdens maintenance window”. Dan gebeurt er simpelweg niets. Nooit. De client wacht op iets wat nooit komt. Controleer dus altijd of de collection waar je op deployt ook daadwerkelijk een window heeft, of zet de deployment zo in dat hij ook zonder window mag draaien als dat de bedoeling is.
Maintenance windows zijn geen magie, maar ze vragen wel om een beetje discipline in je inrichting. Als je die discipline hebt, heb je een systeem dat precies doet wat jij wilt — en bel je niet meer de helpdesk om uit te leggen waarom de CFO midden in zijn presentatie een reboot kreeg.