Patchtool upgradet per ongeluk servers naar Windows Server 2025 zonder licentie

De serverpatchtool van Heimdal heeft per ongeluk servers met Windows Server geüpgraded naar Windows Server 2025, terwijl die servers daar geen licentie voor hadden. Volgens Heimdal kwam dat door een fout van Microsoft. Het is niet bekend hoe groot het probleem is.

Een medewerker van een Brits bedrijf meldde eerder deze week op Reddit dat de Windows Server 2022-servers geüpgraded waren naar Windows Server 2025, zonder dat hiervoor toestemming was gegeven of de servers de benodigde licenties hadden. Dit kan betekenen dat de servers niet langer op de juiste manier werken. Dit bedrijf gebruikt de Patch Management Software van Heimdal, een Deens securitybedrijf.

Een Heimdal-werknemer bevestigt dat de patchtool de upgrade doorvoerde, maar zegt dat de oorzaak bij Microsoft ligt. Microsoft zou de Windows Server 2025-update als KB5044284-Windows 11-beveiligingsupdate hebben gelabeld. De Heimdal-tool zag de upgrade daardoor aan als beveiligingsupdate en voerde deze door naar de servers.

Meerdere admins geven op Reddit aan last van het probleem te hebben. Heimdal zegt dat ongeveer zeven procent van zijn klanten is getroffen, maar het is niet duidelijk om hoeveel bedrijven het dan gaat. Het securitybedrijf zegt de update vooralsnog te hebben geblokkeerd. Het is niet duidelijk of andere patchtools door dit probleem zijn getroffen. Microsoft bracht Windows Server 2025 eerder deze week uit.

Reacties (93)

[Kenhas]

En hoe zou het dan komen dat dit enkel gebeurd is bij die specifieke software? Er zijn talloze Patch Management Systemen en ook daar zal het dan met de verkeerde naam zijn aangeduid. Waarom is het daar dan niet mislopen?

[Christoxz]

Denk dat het eerder is dat de eerste klacht kwam van iemand die Heimdal gebruikt, en Heimdal dit dus heeft op gepakt en het op deze manier nu in de media wordt gebruikt.

Nergens is duidelijk of dit alleen is gebeurd via Heimdal, als de conclusie van Heimdal correct is, is het dus ook met andere software gebeurd.

[Magnix]

Dit inderdaad, wij patchen zonder deze tool en ook hier is die er hier en daar doorheen geglipt, in windows zie je gewoon staan dat het een beveiligingsupdate is vervolgens download/installeer je die en wordt je begroet met de Windows11/2025 omgeving, terugzetten is ook niet even makkelijk en voor zover wij nu zien enkel te doen met een backup.

[Blokker_1999]

Nee, want zoiets zou gewoon te lang duren. Anderen kunnen blijkbaar beter selecteren. Het kan zijn dat MS een foutje in de metadata had zitten, maar er zijn dus blijkbaar meer controles die uitgevoerd kunnen worden.

[Die_ene_gast]

Magnix in 'Patchtool upgradet per ongeluk servers naar Windows Server 2025 zonder licentie'

[rko4u]

De uitleg staat gewoon in het artikel. Door de naam van de update, zag de tool deze als beveiligingsupdate. Blijkbaar hebben ze dit geautomatiseerd en heeft Microsoft het bestand een misleidende naam gegeven.

[dasiro]

lijkt me vreemd dat zo'n tool de naam als basis zou gebruiken, want Server 2022 is ook niet Windows 11.
Als je in de microsoft update catalog zoekt dan komt deze als 2024-10 Cumulative Update for Microsoft server operating system version 24H2 for x64-based Systems (KB5044284) en staat er:
Classification: Security Updates
Supported products: Microsoft Server Operating System-24H2
met een size van 836.6 MB lijkt het me nog veel onwaarschijnlijker dat deze effectief je OS upgrade ipv update.

[Powermage]

Hoe onwaarschijnlijk je het vind, die update KB5044284 upgrade echt je OS.
ik vermoed dat die 836MB gewoon de installer is, waarna die vervolgens weet ik veel hoeveel GB binnen hengelt om de daadwerkelijke update uit te voeren.

[fakier073]

Grappig, ik moest je bericht 2x lezen om te begrijpen dat je 836MB schijnbaar weinig vindt. Ik vind dat juist best veel. Zegt wat over m'n leeftijd (toen stond je OS nog op 2 floppy's).

[Blokker_1999]

Het lijkt erop dat MS de update een verkeerd nummer heeft gegeven en dat Heimdal aan de hand van dat nummer gaat opzoeken in de catalogus wat de classificatie van de update is zonder verdere metadata te analyseren zoals het target OS want het feit dat 24H2 de enige ondersteunde versie van deze update is had weg moeten geven dat dat het nummer van een security update voor Server 2025 was.

[LOTG]

Ik heb het idee dat Heimdal alleen oppervlakkige informatie van de patches gebruikt.

Our Analysis and Fix:
Our team discovered this discrepancy in our patching repository, as the GUID for the Windows Server 2025 upgrade does not match the usual entries for KB5044284 associated with Windows 11. This appears to be an error on Microsoft's side, affecting both the speed of release and the classification of the update. After cross-checking with Microsoft’s KB repository, we confirmed that the KB number indeed references Windows 11, not Windows Server 2025.

Met hun eigen analyse vind ik wel dat het makkelijk is om Microsoft de schuld te geven aangezien het issue niet verder verspreid lijkt dan Heimdal en anderen op Reddit ook aangeven dat hun RMM de updates wel correct identificeert. Gezien de informatie verwacht ik dat ze standaard doen wat Heimdal nu achteraf gedaan heeft en ze niet puur op de patch file informatie vertrouwen maar de KB repository op zijn minst cross referencen.

[wiseger]

Microsoft maakt een fout maar het is dan niet de schuld van Microsoft want de klant moet Microsoft niet zomaar vertrouwen en de informatie dubbel checken voordat deze gebruikt wordt?

[Blokker_1999]

Alleen is Heomdal in dit geval geen klant. Had de klant namelijk de management tools van Microsoft gebruikt, of een andere leverancier, dan was dit niet gebeurd.

Blijkbaar hebben zij ervoor gekozen om enkel de meest eenvoudige controle uit te voeren en al de rest te negeren.

[Powermage]

De Heimdall gebruiker (en andere RMM en patch tool gebruikers) hebben een policy ingesteld waarbij ze security updates snel geinstalleerd willen hebben, en de patch tools hebben dit ook gewoon goed naar wens gedaan.

Je kan discussieren of je dat compleet automatisch wel of niet zou moeten doen, maar alles is een keuze met eventuele financiele consequenties of cybersecurity risico's,
Maar dat doet er niets aan af dat MS een enorme faal heeft gemaakt door een server update als security update te classificeren.

[Sandor_Clegane]

Damned if you do, damned if you don't.

[Die_ene_gast]

Gewoon niet in gesprek gaan met cultisten.

[Powermage]

Het is ook bij andere software "misgelopen" alleen in dit geval op Reddit wordt Heimdal genoemd, maar heel veel software heeft hier last van gehad.

De KB5044284 was gelabeld als een Feature update en Critical en is gewoon op patch tuesday gereleased.

Als je een RMM of patchmanagement tool hebt die als policy gewoon "Critical updates" installeert meteen na patch tuesday dan ging de tool KB installeren die vervolgens gewoon vrolijk je server upgraden naar server 2025.

[n9iels]

Zou kunnen dat MS dit ook snel doorhad en het effectief maar korte tijd online heeft gestaan.

[RonR]

Zoals al door anderen aangegeven heeft ook andere patch software hier last van.

Acronis meldt ook een critical alert:

Critica! Alert: Unexpected Windows Server 2025 Upgrades Reported after
installing KB5044284
Recent reports from multiple third-party sources have identified a critical issue where Windows
Server 2022 systems are inadvertently upgrading to Windows Server 2025
following installation of update KB5044284.
What can you do?
Use Automatic Patch approval and testing option: carefully examine all pending updates,
especially those related to Windows Server 2022 and avoid automatic installation if uncertain.

[Neus]

Backup terugzetten en klaar. Big whoop.

[YellowCube]

ik weet er volgens mij net genoeg van dat je als bedrijf niet heel blij wordt als je server zomaar opeens een hele major versie omhoog gaat en dat je vervolgens moet hopen dat alles gewoon blijft werken.

[Neus]

Uiteraard maar daar ga je dan ook niet op wachten want hopen dat alles blijft werken is natuurlijk not done.

NU de backup terugzetten en die paar uur tijdsverlies maar accepteren. Zo kan de IT afdeling Windows Server 2025 rustig testen, maar niet op een live-omgeving.

[vrow]

Als het een domaincontroller is, is het helemaal niet zomaar mogelijk om terug te gaan naar een backup.
Dat kan wel goed als de server ontploft, maar niet als hij weer gewoon up komt en verder gaat met werken, clients zich aanmelden etc etc.
Als 80-100% van alles werkt, kan het best uren duren voordat je doorhebt dat een server zo’n upgrade heeft gehad.

[Blokker_1999]

Domain controllers zal je snel even nieuwe voor moeten opzetten. Gelukkig zijn domain controllers zowat de eenvoudigste service om op te zetten op een Windows server. Maar je wil inderdaad liefst nooit terug met een domain controller, alleen maar vooruit. Ook al zien we daar steeds meer en betere oplossingen voor komen.

[YellowCube]

Mijn punt was ook niet dat je gaat afwachten of alles werkt. Uiteraard draai/val je terug, maar "een paar uur tijdsverlies" kan in heel veel takken van sport een groot probleem zijn.

[Remzi1993]

Dat heb je meestal niet als je upgrade proces goed in elkaar zit waarbij die server wordt gekloond tijdelijk naar een andere server request tijdelijk naar die server gaat (door dat in de load balancer te veranderen of iets dergelijks) en dan haal je die andere offline en upgrade je die server en zet je de bestanden en instellingen terug. Dit is wat grote professionele bedrijven doen waardoor je 0 downtijd hebt.

[bzzzt]

Precies. "Servers are cattle, not pets". Gewoon nieuwe opspinnen aan de hand van configuratiescripts en de oude weggooien. Als je server een uniek beestje is wat vertroeteld moet worden en/of je helemaal geen redundante hardware hebt heb je feitelijk al verloren maar het nog niet door.
Niet dat dit geen stomme fout is, en het kost vast een paar uur extra beheer maar dit is dus een van de risico's waartegen een serieus bedrijf zich allang had moeten indekken.

[Remzi1993]

Inderdaad, en vaak gaat het verder en zijn het virtuele servers, nog makkelijker want je kan die image gewoon ergens helemaal testen op andere hardware of vergelijkbaar hardware en dan deployen.

Op production zet je natuurlijke alle automatische updates van alles helemaal uit en zorg je ervoor dat dit niet kan. En rouleer je met beveiligingsupdates en dergelijke met servers die niet in gebruik zijn.

[Blokker_1999]

En dat wil ik je nu eens zien doen met een fileserver van meer dan 10TB of een databaseserver. Er is een reden dat heel wat bedrijven gewoon gaan patchen in het weekend en dan alsnog in de nachten, op de momenten dat er zo min mogelijk mensen last van hebben.

Wat je omschrijft is geen slechte strategie, maar zeker niet toepasbaar op alle services.

[Remzi1993]

Meestal heb je kritieke data in RAID staan dat het gedupliceerd wordt. Dit is letterlijk basis ICT. Dat sommige bedrijven goedkoop te werk willen gaan en niet dubbel zo veel SSD's willen kopen is hun probleem.

[Leon Straathof]

Als je niet van te voren een strategie hebt bedacht bij de opzet van je servers voor dit soort scenario's dan is dat al de eerste fout. Of je nou vertrouwd op backups en accepteerd dat je wat data verlies hebt van de laatste uren na je laatste backup of configuratie scripts die de server exclusief data opnieuw op kunnen bouwen. Dit soort dingen bedenk je bij design niet achteraf als er al stront aan de knikker is. En ja dat soort designs bestaan voor grote SQL clusters of file servers ook.

[jozuf]

Maar wat was je punt dan wel uit je oorspronkelijke bericht?
Het enige wat je op je originele bericht kan zeggen is de reactie die eronder staat.

Wat je hier vervolgens typt heeft eigenlijk niets te maken met je oorspronkelijke bericht [me confused]

[Reactie gewijzigd door jozuf op 6 november 2024 16:07]

[Remzi1993]

Sowieso doe je al geen upgrade bij een server die in production draait, die worden tijdelijk gekopieerd naar een andere server (de bestanden en instellingen en dergelijk of een kloon als het een virtuele server is), de load balancer intern verwijzen tijdelijke naar die andere server en dan wordt het geüpgraded.

[ibmpc]

Welk dataverlies? In de legacy werkplek heb je altijd een aparte partitie voor je data. Dus snapshot maken, backup terugzetten van je OS drive en gaan met die banaan (en je data partitie dus intact laten, NTFS ACLs worden immers niet gewijzigd door een upgrade).

[Reactie gewijzigd door ibmpc op 6 november 2024 17:08]

[wiseger]

Je zal toch eerst moeten detecteren dat niet alles werkt. En dat kan best wel eventjes duren, want er moet dan eerst een incident zijn waarbij iets niet goed werkt en applicatie support moet dan wel doorhebben dat het nu een Windows 2025 server is terwijl het Windows 2022 had moeten zijn.

Pas daarna kan je gaan kijken wat de beste oplossing is, afhankelijk van de impact van het incident. Nu meteen urenlang downtime accepteren of kijken of kan door hobbelen om later buiten kantoortijden de zaak op te lossen?

Zo makkelijk is het dus allemaal nog niet.

[mathijst]

Naast het feit van de 'Major', kan het zomaar ook flink in de papieren lopen als je een hele berg server2025 licenties moet gaan aanschaffen.
#nowhoop

[wiseger]

Dat valt wel mee, als de update probleemloos is gegaan en je er dus achter komt dat je prima kan werken onder Windows 2025, dan spaar je ook een heel duur migratie traject uit. De kosten van een server upgrade zitten hem zelden in de licenties, het migratie traject met alle testen is vaak veel duurder.

[ArnoldSmit]

Je reactie is sprekend voor iemand die niet bekend is met grote complexe omgevingen.
Even een backup terugzetten, is in veel gevallen niet even.
Je heb downtime, als bepaalde servers zoals bijvoorbeeld domein controleres mutaties hebben gehad, is even een backup herstellen ook niet zomaar aan de orde.
(Normaal moet je handmatig stappen doorlopen voor je kan updaten, echter gezien dat de upgrade naar 2025 is uitgerold als een update weet je ook niet of dit zo is)
Als meerdere servers zijn geupdate die onderdeel zijn van een cluster, kan downgraden ook nog al een hoofdbrekens zijn.

[Reactie gewijzigd door ArnoldSmit op 6 november 2024 15:30]

[Neus]

Je hebt geen idee wat voor ervaring ik heb maar ik snap je reactie wel. Een enkele server kan je nog wel doen, maar als Heimdal alle servers heeft geupgrade naar 2025 in een omgeving waar je niet weer of je applicaties 2025 ondersteunen of niet, dan MOET je gewoon terug - om gezeik te voorkomen.

En complexe omgevingen draaien (in mijn ervaring) bijna allemaal op hypervisors en daardoor zou een grootschalige restore toch niet zo moeilijk zijn met producten zoals Veeam etc.

[Leon Straathof]

Op zich heb je gelijk hoor, wat echter vaak in de praktijk het probleem is is dat er bij design bezuiningd is en er dus als er al restore of herbouw mogelijkheden zijn deze langere downtime als gevolg kunnen hebben. Vaak zie je dan dat de leiding van organisaties extreme druk uitoefend op IT en verwacht dat die wonderen verrichten in plaats van dat ze toegeven dat ze meer budget voor disaster recovery hadden moeten uitgeven.

[anboni]

Ja, leuk als je domain controllers zijn geupgrade....

[ibmpc]

In de legacy werkplek is een domain controller vaak zo ingericht dat je binnen een paar minuten een volledige herinstallatie kunt doen. Hoewel je wel backups hebt van je DC, is de preferred method gewoon een herinstall. Het gaat vaak mis bij domain controllers die nog meer rollen hebben dan alleen een domain controller role. Je moet niet alleen alle DCs tegelijkertijd herinstalleren, want dan ben je je NTDS.DIT kwijt. De domain controller zal de minste zorg zijn, applicatieservers kunnen soms uitdagend zijn

[Reactie gewijzigd door ibmpc op 6 november 2024 17:12]

[kftnl]

Wat bedoel je precies met legacy werkplek?

[Dennisb1]

Hij bedoeld denk ik vooral de EntraID oftewel je AD in de cloud plat gezegd als modern.
Ik noem de on premises eigenlijk zeker geen legacy, gewoon andere manier van werken, deze gebruik je vaak ook gewoon in combinatie met de hybride omgeving.

[Reactie gewijzigd door Dennisb1 op 6 november 2024 18:30]

[Blokker_1999]

Ik zal on-prem nog niet snel legacy gaan noemen. Klopt gewoonweg niet. Zolang je on-prem servers hebt draaien, en de meeste bedrijven hebben dat, hang je nu eenmaal vast aan die on-prem domain controllers daar MS je wel toestaat om je clients volledig in de cloud te beheren met Azure en Intune maar je niet dezelfde opties biedt voor je servers.

[ibmpc]

Zonder Entra ID. Maar zelfs in een Hybrid werkplek kun je je DCs gewoon herstellen met andere DCs. Sterker nog, hoewel niet aangeraden maar uit de praktijk weet ik dat je gewoon een oude DC van een maand terug gewoon kunt terugzetten en Entra Connect weer kunt starten, dus ook in de moderne werkplek kun je DCs nog herstellen met andere DCs, als je ze nog hebt.

[kozue]

Wat hij bedoelt is dat hij zo iemand is die altijd maar blind meegaat met wat de tech industrie hem aan probeert te smeren en alles wat ouder/andere is, afdoet als “ouderwets”, daarbij compleet vergetend dat die nieuwe methodes juist gepushed worden omdat de aanbieder daar profijt van heeft.

Er is niks “legacy” aan on-prem, dat is de standaard voor bedrijven die zichzelf niet compleet vast willen zetten in een MS-only cloud-afhankelijke omgeving. De voornaamste reden voor het bestaan van Entra ID is vendor lock-in en maandelijkse abo’s. Bedrijven zijn gek op abo’s, dat is een veel voorspelbaardere inkomstenstroom dan eenmalige licenties verkopen en hopen dat ze de volgende versie ook kopen.

[Dick Ravestein]

Maar dan niet vergeten auto-update ff uit te zetten!

[Seal64]

Wat hier geen bal uit maakt aangezien er een third party tool werd gebruikt om patches te managen. Dan acht ik de kans vrijwel 100% dat die auto-update ook inderdaad uit gestaan heeft, want anders zou het probleem veel groter zijn, en niet enkel bij gebruikers van die tool optreden...

[Blokker_1999]

Backups zijn er voor disaster recovery, dit is niet noodzakelijk een ramp. Als het hier om bijvoorbeeld file- of databaseservers gaat dan wil je niet zomaar snel even terug.

[Powermage]

Tuurlijk
Maar dit gebeurde vaak in de nacht, mensen zijn alweer aan het werk, dus je data is weer veranderd etc etc.
je moet dus maintenance windows gaan plannen, je moet een plannetje maken, een fallback bedenken, en je moet het gaan uitvoeren....

[PD2JK]

Die 'gratis' upgrade naar 2025 hebben ze veel te makkelijk gemaakt als je het mij vraagt. Niets is gratis.

https://gathering.tweaker...message/80612754#80612754

[LOTG]

Als je daar op klinkt krijg je eerst een scherm wat je uitgebreid er op wijst dat die niet gratis is er licenties nodig zijn.

[oef!]

Ik heb hier thuis een 2022 Datacenter editie draaien, de update wordt daarop in ieder geval niet aangeboden.

[Blokker_1999]

Al maar goed dat het upgraden op zich relatief eenvoudig kan. Stel je eens voor dat je duizenden servers moet upgraden en overal door een complexe, manuele routine moet gaan. Wat ga je dan doen?

[Pwigle]

Kun je ook als kans zien, als alles blijft werken heb je een migratie minder!

[batjes]

De toekomstvoorspellende poortwachter van de goden doet de naam niet echt eer aan.

[YGDRASSIL]

Waarom draait heimdal een 'windows 11' gelabelde update op een windows 2022 server?

[TeddyB26]

Idd 🤔🙂

[Blokker_1999]

Onder diezelfde KB nummer vind je ook een server editie van die update voor Server 2025. De vraag is dan vooral: waarom keurt men een update goed die zegt voor Server 24H2 te zijn wanneer je op 21H2 draait?

[Powermage]

Omdat hetzelfde KB nummer OOK voor een windows server update is uitgebracht om het makkelijk te maken.

[Rabb]

Klinkt alsof Heimdal deze update dus niet van te voren heeft getest, lijkt mij dat het hele doel van een tool als deze is dat zij het eerst testen voordat ze de boel pushen.

[Blokker_1999]

En wat zouden ze moeten testen? Hoe zouden ze moeten testen? Er zijn miljoenen configuraties, allemaal anders. De testing gebeurt door Microsoft. Het is MS dat instaat voor de kwaliteit van de patch, Heimdal biedt o.a. patch management aan. En het is bij dat management dat het is misgelopen.

[NathanVerkerk]

Het is meer dat dit voor het eerst is gemeld door een gebruiker van Heimdal.
De update is vanuit microsoft uitgevoerd naar iedereen, en meerdere RMM's (zoals NinjaOne) melden ook dat de update geexclude moet worden. Volgens mij is dit geen fout van Heimdal.

[grimlock]

Dit is voor mij al een reden om NOOIT voor dit product te kiezen, zeker nu ze public maken dat ze op deze manier werken. Blijkbaar is hun enige verificatie de naam van de patch en dat het dan klakkeloos doorgevoerd wordt. Ik ben geen expert maar ik verwacht dat er een verificatie is t.a.v. minimaal een hash van de patch tegen het OS en de actuele status ervan. Hoe makkelijk kan een MitM attack plaatsvinden en ervoor zorgen dat heel je systeem om zeep raakt of nog veel erger omdat het als een legitieme patch doorgevoerd wordt?

[Powermage]

Nee, je hebt het probleem niet goed begrepen.

MS heeft een KB uitgebracht, KB5044284, deze is een feature update met het kenmerk security update.

Tools als Heimdal (en andere RMM en patch tools) downloaden de tool niet maar lezen je windows-update als het ware uit en geven opdrachten om een patch uit te voeren (of niet) beetje af hankelijk van je policy.

Had je nu dus een policy actief waarbij je security updates wil laten installeren ging je eigen windows update dus heel vrolijk een KB update installeren die stiekem een windows server upgrade was.

[mr.DJ95]

Ha leuk om mijn getipte bericht op de frontpage terug te zien.

Naast de onverwachte upgrade naar Server 2025 vanaf Server 2019 en 2022 zorgt deze update ook voor de nodige Blue-screens tijdens de update cyclus.

Overigens is het zo maar installeren van zo'n upgrade naar Server 2025 erg groot risico. Daarnaast ben ik nooit fan geweest van inplace upgrades maar dat komt door meest gekke problemen die je naderhand tegenkomt. Moet wel bekennen dat mijn ervaring stamt uit het server 2012 tijdperk.

Als je dan toch besluit een inplace upgrade te doen doe je dit eerst op een test machine nadat je een snapshot hebt gemaakt en natuurlijk nadat je uitvoerig de known issues https://learn.microsoft.c...tatus-windows-server-2025 en comptabiliteit hebt gecheckt met je software leverancier.

[gimbal]

Naast de onverwachte upgrade naar Server 2025 vanaf Server 2019 en 2022 zorgt deze update ook voor de nodige Blue-screens tijdens de update cyclus.

Juist. Ik vond het bij het lezen wel erg stoer dat een third party patch tool het eventjes voor elkaar kreeg om foutloos het hele server OS op te krikken. Maar blijkbaar is het toch niet zo mooi als dat het klinkt.

[mr.DJ95]

Servers welke beheerd worden door NinjaOne en Azure patch management heb ik gezien dat de optionele updates om wat voor reden dan ook werd aangemerkt als verplichte kost waardoor de update al was geïnstalleerd en en in sommige gevallen de servers zelfs al was gereboot met het nieuwe OS met alle gevolgen van dien.

[WhiteDog]

Gevalletje CrowdStrike, je fundamentals uitbesteden aan dé experts...

[xiam]

Vraagje: als dit soort dingen geautomatiseerd zijn kunnen kleine foutjes grote gevolgen hebben. Want software werkt niet zoals het moet. Dat kan dus ook bij ziekenhuizen en vliegvelden of Tesla OTU. Je bent na zo'n update niet zeker of de auto of ziekenhuis goed functioneert. Dat maakt het minder zeker als je 's ochtends met een geüpdate auto de weg opgaat...

[mr.DJ95]

Dat is correct, daarom heb je een test, acceptatie en productie omgeving die idealiter zijn gescheiden.
Geautomatiseerde tooling zoals Azure patch management, SCCM, en RMM tools zijn onmisbaar in elke IT omgeving. We hebben het vaak over tientallen tot honderden servers.

[Powermage]

In de ideale wereld heb je idd een OTAP straatje staan ja... alleen is voor t gemiddelde MKB een otap straat niet te betalen....

[Blokker_1999]

Daar is niets vreemd aan. Het is een in-line upgrade zoals zovele consumenten ook doen wanneer ze hun Windows een versienummer hoger tillen, en in de meeste gevallen duurt het gewoon een heel stuk langer voordat je herstart is doorgevoerd, maar kan je daarna zonder problemen verder. Bij servers is het niet anders.

[Powermage]

Ja, dat is wel vreemd, want dit is bij windows server nog nooit gedeployd.
Ja, er waren in-place upgrade mogelijkheden, maar MS raadde deze eigenlijk altijd af te gebruiken.

[wiseger]

In-place upgrades worden zelden tot nooit gedaan. De omgeving wordt op een nieuwe virtuele server opgebouwd en door getest. De daadwerkelijke migratie is het routeren van de applicatie requests van de oude virtuele server naar de nieuwe virtuele server.

Pas als je er helemaal zeker van bent dat alles goed werkt, wordt de oude virtuele server enige tijd later verwijderd.

[kozue]

Dat is leuk als je een simpele omgeving hebt met 1 server. Als je er een heleboel hebt is het niet te doen om ze een voor een te gaan vervangen. Dan doe je er 1 als test (of zet je er nog een naast) met behulp van je configuratie management tool, en wanneer die alles netjes doet kun je de rest gefaseerd upgraden. Als er problemen optreden kun je die analyseren en je config management aanpassen om het probleem te verhelpen. Die config management doet daarna de rest.

Als je een heel serverpark hebt is een degelijke config manager echt nodig voor consistentie tussen instances en reproductie van bestaande systemen als er een problemen heeft. Iets als puppet, chef, ansible, terraform, whatever. En ja, met zoiets is het inderdaad ook een stuk makkelijker om nieuwe servers met het nieuwe OS uit te rollen, maar dat blijft toch altijd meer werk dan gewoon de oude geautomatiseerd laten upgraden met alle juiste instellingen er op. Ik denk zelf dat het gros van degenen die zweren bij “doe nooit een in-place upgrade” vooral degenen zijn die alles nog steeds handmatig doen door in een interface dingen bij elkaar te klikken (🙄).

[wiseger]

Zo doe je het ook in een omgeving met duizenden servers verspreid over tientallen data centers wereldwijd.

Het vervangen van het OS door een nieuwe versie kan een behoorlijke impact op je business applicaties hebben. Het doortesten van de nieuwe omgevingen is een project dat makkelijk maanden in beslag neemt, met name de acceptatie testen van de business nemen heel veel tijd in beslag.

Al die tijd zal je naast je bestaande omgevingen die dagelijks gebruikt worden voor productie, support en releases toch echt een parallelle omgevingen nodig hebben om dit werk allemaal uit te voeren.

En niet te vergeten, je wilt kunnen terugvallen op de oude omgeving als je tijdens de go-live toch nog onverwachts gedrag tegen komt.

[Reactie gewijzigd door wiseger op 7 november 2024 10:28]