“Deze klanten hoefden niet te wachten tot er een nieuwe functie werd uitgebracht. Ze gebruikten de tools die NinjaOne al biedt – scripting, API, aangepaste velden, Dynamic Policies – en bouwden precies wat hun omgeving nodig had. Dat is de kracht van een platform dat is ontworpen om uitgebreid te worden: als u iets specifieks nodig hebt, hebt u de bouwstenen om het nu te realiseren, niet volgend kwartaal.”
Voor de meeste organisaties is Patching geen eenvoudig proces. Ze hebben change advisory boards, gefaseerde uitrol, CMDB-gestuurde onderhoudsvensters, jaarlijkse freeze-periodes en compliance-kalenders waardoor Patch Tuesday schromelijk tekortschiet. Als hun tools dat niet kunnen bijbenen, eindigen IT-teams met spreadsheets die aan handmatige processen hangen en hopen ze dat er niets tussendoor glipt.
NinjaOne werkt samen met enterprise-klanten die dat compromis weigerden te accepteren. In plaats van te wachten op een feature request gebruikten ze de scriptingengine, API, aangepaste velden en Dynamic Policies van NinjaOne om precies de patching-workflows te bouwen die ze nodig hadden. Hier zijn twee van die verhalen.
Een beter patchingscript bouwen met NinjaOne
Een grote onderneming draaide al jaren op een verouderd configuratiemanagementplatform. Het werkte, maar de infrastructuurkosten waren enorm: dedicated servers, distributiepunten, databasebackends en VPN-afhankelijkheden voor apparaten op afstand.
Het bedrijf wilde overstappen naar NinjaOne, maar dacht dat hun patchingproces een onoverkomelijk obstakel voor die overstap zou vormen. Ze hadden een gefaseerd uitrolmodel gebouwd waarbij patches in etappes door de organisatie stroomden. Ze begonnen met een kleine testgroep, breidden uit naar early adopters, rolden daarna uit naar de kantoren en patchten weken later pas de buitenlocaties. Elke fase had een specifieke vertraging die gekoppeld was aan het moment waarop Microsoft patches uitbrengt en sommige fases mochten alleen tijdens nachtelijke onderhoudsvensters installeren om de bedrijfsvoering niet te verstoren.
Dat soort “releasedag plus N dagen”-logica bestaat van nature niet in de meeste tools voor endpoint management. Hij bestond ook niet in de laatste drie platforms die ze vóór NinjaOne hadden beoordeeld.
Eenvoudiger Patching zonder de overhead
Met de scriptingengine van NinjaOne maakte de klant een gating-script dat automatisch draait vóór elke patchcyclus. Het doet de datumberekening, bepaalt het releaseanker van de huidige maand, telt de juiste vertraging voor de fase van dat device erbij op en beslist of vandaag de juiste dag is. Zo ja, dan gaat de Patching door. Zo nee, dan vertelt het script NinjaOne de cyclus netjes over te slaan en het de volgende keer opnieuw te proberen.
Het script maakte het eenvoudig voor het team dat Patching dagelijks beheert. Beheerders hoeven geen code aan te raken. Ze kiezen simpelweg hun uitrolfase uit een dropdownmenu in NinjaOne en het script doet de rest. Besluit de organisatie de vertraging voor een bepaalde groep aan te passen, dan hoeven ze maar één dropdownwaarde te wijzigen. Meer niet.
Vandaag heeft dit bedrijf zijn verouderde patchinginfrastructuur volledig buiten gebruik gesteld. Geen dedicated servers meer. Geen VPN-vereisten meer voor laptops op afstand. Hun hele wagenpark patcht rechtstreeks bij de leverancier via internet en ze hebben nog altijd dezelfde discipline van gefaseerde uitrol waarop ze altijd hebben vertrouwd – alleen zonder de overhead
Een CMDB koppelen aan NinjaOne zodat Patching zichzelf uitvoert
Een grote onderneming beheert een serverpark verspreid over meerdere besturingssystemen. Elke server in hun omgeving heeft een onderhoudsvenster dat in hun CMDB is vastgelegd. Dat onderhoudsvenster is een record dat het omgevingstype, de dag van de week en het tijdvenster aangeeft waarin Patching is toegestaan. Over het hele serverpark van de organisatie levert dat tientallen unieke combinaties van onderhoudsvensters op.
Een extra complicatie is dat hun patchingkalender niet op terugkerende patronen is gebaseerd. Ze patchen elke maand op specifieke data, een jaar vooruit gepland. Ook hanteren ze een jaarlijkse freeze-periode tijdens hun drukste seizoen waarin geen enkele patch de productieomgeving raakt. Afzonderlijke servers dragen hun eigen vlaggen: sommige mogen tijdens Patching niet opnieuw worden opgestart, sommige krijgen alleen een reboot zonder patches en sommige vereisen volledig handmatig ingrijpen.
Vóór NinjaOne beheerde het IT-team dit allemaal handmatig. Spreadsheets hielden bij welke servers op welk moment gepatcht waren. Kennis die alleen in hoofden zat, vulde de gaten op. Sommige devices glipten ertussendoor. Patches werden gemist.
NinjaOne nam al die complexiteit weg door hun CMDB rechtstreeks te koppelen aan de policy-engine van NinjaOne met drie lagen automatisering:
- Geautomatiseerde synchronisatie: Een script draait volgens een schema, leest het onderhoudsvenster van elke server uit de CMDB en schrijft de relevante gegevens weg naar aangepaste velden op het bijbehorende NinjaOne-device. Verandert het venster van een server in de CMDB, dan pikt NinjaOne dat automatisch op. Niemand hoeft handmatig beleid opnieuw toe te wijzen.
- Kalenderpoort: Eenmaal per jaar voert een beheerder de startdata van de patchcycli van elke maand in de aangepaste velden van NinjaOne in. Een dagelijks script controleert de datum aan de hand van die velden en stelt één waarde in die bepaalt of de patch doorgaat of niet. Is het een patchweek voor non-productie, dan komen alleen non-productieservers in aanmerking. Is het een productieweek, dan komen alleen productieservers in aanmerking. Is het een freeze of een week zonder Patching, dan blijft alles stil. Eén waarde bestuurt de hele omgeving.
- Dynamic Policies met gelaagde targeting: Elk uniek onderhoudsvenster krijgt zijn eigen Dynamic Policy. De policies gebruiken meerdere targetingvoorwaarden: de omgeving van het device, de toegewezen dag, het toegewezen tijdstip en de huidige kalenderstatus. Die moeten allemaal op één lijn liggen voordat een device matcht. Staat de kalenderpoort dicht, dan matcht geen enkel device met welke policy dan ook. Gaat hij open, dan lichten alleen de juiste servers op.
Met deze automatiseringen kan de organisatie haar hele serverpark op de juiste datum, op het juiste tijdstip en in de juiste volgorde patchen – automatisch. De CMDB blijft de belangrijkste autoriteit voor onderhoudsvensters en NinjaOne voert daarop uit zonder handmatig ingrijpen. Wat vroeger spreadsheets en afstemmingsgesprekken kostte, loopt nu vanzelf.
Het grotere plaatje
Geen van beide klanten vroeg NinjaOne om een nieuwe functie te bouwen. Ze dienden geen verzoek in en wachtten niet op een release. Ze keken naar de tools die NinjaOne al biedt – scripting, API, aangepaste velden, Dynamic Policies – en bouwden de scripts die hun omgeving nodig had.
Dat is het verschil tussen een tool en een platform. Een tool doet waarvoor hij is ontworpen. Met een platform bouwt u wat u nodig hebt.
Voor bedrijfs-IT-teams die te maken hebben met complexe patchingkalenders, CMDB-integraties, gefaseerde uitrol en operationele beperkingen die niet netjes in een dropdownmenu passen, geeft NinjaOne u de bouwstenen om het werkend te krijgen. Niet ooit. Vandaag.
Lees meer op NinjaOne.com/patch-management
