Patchmanagement voor MSP's: één patchbeleid voor al je klanten

Je runt een MSP. Met drie klanten is patchen een gewoonte op dinsdagavond: je weet welke server het boekhoudpakket draait, welke laptop van de zaakvoerder is en wie je belt als een update de printer platlegt. Bij klant nummer tien schaalt die gewoonte niet meer. Elke klant heeft zijn uitzonderingen, elke technieker keurt updates net iets anders goed, en als een klant vraagt "zijn we up-to-date?", kost het antwoord je een namiddag.

Dit artikel is voor zaakvoerders en technisch verantwoordelijken van MSP's die één patchbeleid willen dat ze bij al hun klanten kunnen toepassen: wat je automatisch goedkeurt, hoe je in ringen uitrolt, hoe je software van derden en servers aanpakt, en hoe je een klant toont waar hij staat. Op het einde lees je hoe we dat in Xcellerate RMM doen.

In het kort

• Schrijf het beleid één keer, per toesteltype: werkstations, servers en kritieke servers krijgen elk hun eigen wachttijd, installatievenster en herstartregel.
• Rol uit in ringen: eerst je eigen testtoestellen, dan je interne machines, dan pilootklanten, dan iedereen.
• Patch software van derden met dezelfde workflow als het besturingssysteem, en herstart een server nooit automatisch buiten een onderhoudsvenster.
• Geef elke klant een maandrapport: patchstatus per toestel, wat geïnstalleerd is, wat mislukte en wat je bewust uitstelde.

Waarom patchen vastloopt bij klant nummer tien

Patchen loopt zelden mis omdat een technieker niet weet hoe het moet. Het loopt mis omdat de regels in hoofden zitten. De ene technieker keurt alles goed op woensdag, de andere wacht een week, een derde slaat de server over van de klant die vorig jaar klaagde over een herstart. Niets staat op papier, dus niets is consequent, en niemand kan tonen wat er echt gebeurd is.

Een patchbeleid lost dat op. Het is een kort document, en liefst een instelling in je RMM, dat voor elk toestel vier vragen beantwoordt: welke updates worden automatisch goedgekeurd, na hoeveel dagen, in welk tijdvenster, en mag het toestel zelf herstarten? Staan die antwoorden op papier, dan wordt patchen een proces dat je kunt controleren in plaats van een gewoonte waarop je hoopt.

Het beleid in één tabel

Vertrek van toesteltypes, niet van klanten. De meeste MSP's hebben er drie nodig. De cijfers hieronder zijn een voorbeeld om aan te passen, geen regel:

Waarom een wachttijd? Een paar dagen geven de bredere community de tijd om een kapotte update te melden voor ze bij je klanten belandt. Waarom verschillende vensters? Werkstations patch je het best wanneer mensen pauze nemen, servers wanneer niemand werkt.

Voeg daarna uitzonderingen toe per klant, niet per toestel: een klant met nachtploegen krijgt een ander venster voor zijn werkstations; een klant met een gevoelige bedrijfsapplicatie krijgt zijn server in de kritieke klasse. Noteer elke uitzondering, met de reden erbij.

Ringen: laat je eigen toestellen eerst gaan

Een updatering is een groep toestellen die updates in dezelfde fase krijgt. Een eenvoudige opzet voor een MSP telt er vier:

1. Testring: een paar eigen toestellen die elke update als eerste krijgen.
2. Interne ring: de rest van je eigen kantoor.
3. Pilootring: een of twee klanten die wat verdragen, goed gedocumenteerd zijn en weten dat ze piloot zijn.
4. Brede ring: alle anderen.

Elke ring wacht op de vorige. Breekt een update iets in de test- of interne ring, dan blokkeer je ze voor ze bij een klant terechtkomt. Ringen geven je ook een helder antwoord als een klant vraagt waarom hij een update niet op dag één kreeg: dat is bewust.

Software van derden is het echte gat

Updates van het besturingssysteem zijn het makkelijke deel: Windows, macOS en Linux hebben elk hun eigen updatemechanisme, en de meeste RMM's kunnen ermee overweg. Het gat zit in al de rest: browsers, pdf-lezers, Java, Zoom en de andere applicaties die gebruikers installeren en die niemand bijwerkt.

Behandel ze zoals het besturingssysteem: dezelfde goedkeuringsregels, dezelfde ringen, dezelfde vensters. Houd per klant een lijst bij van de software van derden die je ondersteunt, en beslis wat er met de rest gebeurt (verwijderen, of met een schriftelijke notitie bij de klant laten).

Servers: nooit herstarten zonder venster

De snelste manier om het vertrouwen van een klant te verliezen, is een onverwachte herstart midden op de dag van de server waarop zijn bedrijfsapplicatie draait. Drie regels:

• Geen automatische herstarts op servers buiten een afgesproken onderhoudsvenster.
• Spreek het venster schriftelijk af met de klant, in de tijdzone van de klant.
• Zorg bij kritieke servers dat er tijdens het venster iemand beschikbaar is om de diensten achteraf te controleren.

Het bewijs: het rapport dat je klant ziet

Een beleid wekt pas vertrouwen als de klant ziet dat het werkt. Stuur elke klant één keer per maand een kort patchrapport:

• Patchstatus per toestel: het aandeel van de toepasselijke updates dat geïnstalleerd is.
• Wat er geïnstalleerd is in de voorbije maand, en wat mislukte.
• Wat je bewust hebt uitgesteld of geblokkeerd, en waarom.
• Toestellen die aandacht vragen: al weken offline, wachtend op een herstart of niet meer ondersteund.

Overloop het in je maandelijkse of driemaandelijkse opvolging. Zo wordt patchen geen onzichtbare kost meer, maar een dienst die de klant ziet.

Zo doen we het in Xcellerate RMM

Xcellerate RMM is onze RMM: source-available onder de FSL, op je eigen servers of in onze EU-cloud. Patchmanagement zit in de source-available kern. Zo vertaalt het beleid hierboven zich:

• Besturingssystemen en software van derden: Windows Update, apt/yum op Linux en softwareupdate op macOS, plus een catalogus van populaire applicaties van derden die dezelfde goedkeurings- en planningsworkflow volgen.
• Patchbeleid per groep: automatische goedkeuring, uitstelperiodes, onderhoudsvensters en herstartgedrag, één keer ingesteld en aan een groep gekoppeld. Patchstrategieën met een eigen naam, planning en regels koppel je aan elke agent of groep.
• Goedkeuren, uitstellen of blokkeren in batch: bekijk de openstaande patches over al je toestellen heen en wijzig hun status in één bewerking.
• Updateringen: kies per tenant welke updatering hij volgt, zodat vroege builds wegblijven van klanten in productie.
• Detail en historiek per toestel: wat er geïnstalleerd is, openstaat of mislukte op elk toestel, en een logboek van elke installatie met resultaat en tijdstip.
• Compliancescore en rapporten: het percentage geïnstalleerde toepasselijke patches per toestel of groep, een exporteerbaar compliance report om met de klant te delen, en een melding wanneer de score onder een drempel zakt die je zelf instelt.

De featurepagina over patchmanagement geeft het overzicht, en de documentatie over patchmanagement toont stap voor stap hoe je een beleid aanmaakt. Wil je het op je eigen servers draaien? De installatiegids beschrijft de self-hosted installatie.

Gebruik je naast je RMM ook een PSA? Xcellerate RMM en Xcellerate OPS zijn twee aparte producten, en een kant-en-klare koppeling tussen beide is er nog niet. Alles-in-één RMM + PSA of best-of-breed helpt je beslissen wat jouw stack nodig heeft.

Test het beleid op je eigen toestellen: voor altijd gratis op je eigen servers, of een Cloud-proefperiode van 14 dagen. Gratis starten