Windows Server-update veroorzaakt bootloop domeincontrollers en Hyper V-probleem

Updates van Windows Server-versies veroorzaken spontane reboots en bootloops van domeincontrollers. Daarnaast melden Windows-beheerders dat Hyper-V niet meer start na het doorvoeren van een Windows Server-update.

De problemen doen zich in ieder geval voor bij Windows Server 2012 R2, Windows Server 2019 en Windows Server 2022, blijkt uit meldingen die BornCity ontving en uit berichten op Reddit. De problemen zouden zijn ontstaan na het verschijnen van de updates KB5009624, KB5009557 en KB5009555 voor de respectievelijke Windows Server-versies.

De updates moeten een probleem verhelpen waarbij Active Directory-kenmerken niet correct werden geschreven tijdens een LDAP-bewerking, maar Windows-beheerders melden met continue reboots te maken te hebben na het doorvoeren. Op Reddit wordt vermoed dat de oorzaak bij lsass-crashes ligt. Lsass staat voor Local Security Authority Subsystem Service en deze beheert het beveiligingsbeleid op een systeem.

Tegelijkertijd zijn er meldingen dat Hyper-V niet meer start op Windows Server-systemen. De meldingen betreffen met name Windows Server 2012 R2, aldus Bleeping Computer, maar ook nieuwe versies kunnen getroffen zijn. De site legt de link met fixes voor vier Hyper-V-kwetsbaarheden die deze week verschenen zijn. Ten slotte zijn er meldingen dat ReFS-volumes niet meer benaderbaar zijn na het doorvoeren van de updates. Het de-installeren van de updates zou een oplossing zijn, maar aangezien het cumulatieve updates betreffen, wordt hiermee ook de installatie van beveiligingspatches ongedaan gemaakt.

Reacties (131)

[Dennisb1]

Bij ons was KB5009546 de oorzaak van de problemen, deze mis ik in het artikel.
Is voor Windows Server 2016, die is net zo hard getroffen.

Bron:
Dennisb1 in 'nieuws: Microsoft dicht aantal ernstige kwetsbaarheden in Window...
AskWoody

[Reactie gewijzigd door Dennisb1 op 22 juli 2024 22:27]

[digital8]

Hier vannacht ook twee Server 2016 DC VM's die in de bootloop vast zaten, de oplossing is dan misschien vrij simpel maar het is wel tijdrovend als je DC's plat liggen.

In ons geval hebben we de servers herstart naar safemode en daarna in een elevated CMD het onderstaande uitgevoerd.

wusa /uninstall /kb:5009546

Dit duurt bijna een uur, daarna een herstart en de server lijkt weer goed te werken.

[themadone]

Waar baseer je dat op? Ik heb al een aantal 2016 machines gepatcht inclusief DC's en deze issues komen bij ons niet voor.

Wij pakken bij het updaten altijd 2 kleine kantoortjes die kunnen uitwijken naar HQ bij problemen met de patches, scheelt weer een otap straat.

[DiGiDoG]

Raar is dat het niet alle DC's betreft. Hier ook een aantal W2016 DC's gepatched met de genoemde kb en ook geen issues

[themadone]

Ja volg het ook niet helemaal, wij draaien ze allemaal op vmware, misschien maakt dat verschil. Las in de comments dat een hyperv host op Dell hardware stuk ging maar bij HP niet.

[blouweKip]

Wij hebben juist problemen gehad met servers die Windows 2016 op bare metal draaien, al onze vm's (2012r2/2019 mix) hadden nergens last van (op xen).

Het is wel iedere keer weer een crapshoot, windows update is al enorm lang een puinzoo en Microsoft doet er helemaal niets aani, je zou toch iets beters mogen verwachten van een (server) OS waar je zoveel voor betaald.

[Dennisb1]

Je zou bijna denken dat ze je proberen indirect te pushen naar de cloud

[Dennisb1]

Hier hebben wij wel VMware met dit probleem, ook de terminal servers hebben er last van.

[Dennisb1]

Bron bijgevoegd maar ook eigen ervaring.
Andere machines waar de DC rol niet op staat hebben geen hinder van deze patch gehad hier.

[Reactie gewijzigd door Dennisb1 op 22 juli 2024 22:27]

[Steven Hoogslag]

Ook hier ging het mis na de update. Onze servers draaien zonder domein. Na de update ontbrak de optie Hyper-Threading Technology in de Gigabyte A370 BIOS (met Intel I5 CPU). De fysieke Server2012R2 server startte wel maar de Hyper-V server bleef staan in saved state. Gelukkig herkende een collega het probleem van deze update.

De update stond al een poosje klaar voor een herstart, hopelijk is hij inmiddels teruggetrokken maar er is weinig te vinden op Internet. Hier staat het nieuws gelukkig wel!
De oplossing is om de optionele(!) vervolg-update te downloaden en draaien.

[beerse]

Het was mij ook al opgevallen dat w2016 ergens tussendoor zwijnde...

Over jou kleine kantoortjes: Ik zou ze 'test' en 'acceptatie' noemen. Dan heb je daar je otap-straat. Scheelt weer veel in het opzetten van zo iets en kan je het invoeren van de patch-otap-straat ook weer als succes opleveren aan het management.

[ftpfreak]

Ik had inderdaad dezelfde problemen op Server 2016 DC's met KB5009546, maar dan alleen op de DC met de PDC FSMO role.

[Dennisb1]

Bij ons maakte dit geen verschil. Zowel de PDC als de SDC hadden er last van helaas.
Ze gingen vanochtend ook tegelijk in de reboot, gaf een leuk effect op de Exchange o.a. als je complete domain offline is.

[Reactie gewijzigd door Dennisb1 op 22 juli 2024 22:27]

[virtualpimp]

Wat voor FSMO rol is een SDC?

[the_stickie]

geen.
Vroegah had je een échte "primary domain controller". De andere was dan vanzelfsprekend secondary.
Sinds Active Directory zijn alle dc's 'hetzelfde' en is er een fsmo 'PDC emulator'

Ik neem aan dat Dennisb1 dus gewoon zijn tweede DC bedoelt

[4Lph4Num3r1c]

Klopt, 2016 was hier ook steeds aan het herstarten. Volgens reddit was inderdaad KB5009546 de oorzaak op 2016.

Even je NIC uitschakelen, daarna stopt het rebooten, dan heb je de tijd om de 2022-01 update te de-installeren.

Overigens heb ik het gevoel, dat Microsoft de updates heeft teruggetrokken, als ik nu servers (2016) of desktops laat zoeken (W10, gewoon via internet, geen WSUS) staat hij er niet meer tussen.

[Reactie gewijzigd door 4Lph4Num3r1c op 22 juli 2024 22:27]

[mr.DJ95]

Vergeet ook niet Update KB5009624 die ReFS support verwijderd van Server 2012 R2 en KB5009566 voor Windows 11 + KB5009543 voor Windows 10 20H2 – 21H2 die L2TP over IPSEC problemen veroorzaken.

Dit is overigens wel de reden waarom je als bedrijf altijd een afkoel periode wilt hebben na het uitbrengen van een update.

#happypatching

Edit: REFS is vermeld in het artikel

[Reactie gewijzigd door mr.DJ95 op 22 juli 2024 22:27]

[Quad]

L2TP VPN is hier ook bekend, vrij storend.

[De Vliegmieren]

Is er tegenwoordig nog een reden om L2TP/IPSEC te gebruiken ipv. SSL VPN of IKE2 ?

[SmokingCrop]

Firewall die het niet ondersteund is een reden

[De Vliegmieren]

Bij SSL VPN hoe je toch slechts één poort te openen?

[SmokingCrop]

VPN die op de firewall/router zelf geconfigureerd wordt, doelde ik op. Geen aparte box die de VPN verzorgd.

[Reactie gewijzigd door SmokingCrop op 22 juli 2024 22:27]

[De Vliegmieren]

Wat heeft Microsoft hier dan nog mee te maken?
Ik ging er vanuit dat de L2TP/IPsec implementatie in Windows Server niet goed werkte na deze patches.

[SmokingCrop]

Ah zo. Het is een algemeen probleem van de client (windows 10&11), niet van de VPN server.

Als je de update verwijderd op de client, dan werkt de L2TP verbinding onmiddellijk terug.

Ongeacht waar de vpn server op draait. Unifi FW, sonicwall, cisco.. Allemaal hetzelfde issue.

Command line/powershell met admin rechten:
Windows 10:     
wusa /uninstall /kb:5009543
Windows 11:      
wusa /uninstall /kb:5009566

[Reactie gewijzigd door SmokingCrop op 22 juli 2024 22:27]

[Anoniem: 25604]

Ooit beheerder geweest. WSUS was er toch voor bedoeld om dit soort "omvallertjes"te detecteren in de OTA-straat, voordat de patches in Productie worden uitgerold?

[DominAbbus]

Elk bedrijf heeft een test-omgeven.
Sommige bedrijven hebben ook een apart ingerichte produktie-omgeving

[Sandor_Clegane]

Behalve MS zelf lijkt het. Die heeft de teststraat bij de klant de laatste paar jaren lijkt het.

[SmokingCrop]

Elke bedrijf heeft beide, meestal zijn ze dezelfde

[Anoniem: 1532362]

Haha de test omgeving is meestal de productie server maar dan buiten kantoortijd. Wat redelijk kan als het een VM is en je een snapshot maakt. Tot je de bug pas de volgende dag om 3 uur s'middags ondervind.

[Reactie gewijzigd door Anoniem: 1532362 op 22 juli 2024 22:27]

[tc982]

Welke SMB/KMO heeft dat? Ik ken er niet veel hoor.

[The Zep Man]

Nog steeds, via WSUS of andere kanalen.

Zoals @vanquisher99 ook al noemt is OTA echter maar duur. Het 'gaat toch altijd goed'? Microsoft werkt immers ook zo.

Wat Microsoft in werkelijkheid heeft gedaan is het testen crowd/outsourcen naar de klanten. Daardoor zie je vaak dit soort zaken in het nieuws. Ervaren organisaties balanceren het geheel door snel genoeg te updaten, maar niet de eerste te zijn.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 22:27]

[Anoniem: 25604]

Ja... een virtueel servertje in de OTA-straat kost wel €200 bij een leverancier zoals Capgemini per maand. Een alternatieve procedure om een tijdelijke VM (Vmware, HyperV of Azure) op te tuigen op basis van een snapshot/-clone documenteren en wat patches uitrollen is inderdaad ook teveel geld. Het wegvallen van je domaincontrollers is inderdaad een stuk goedkoper. De leidingevenden moeten wel elke maand hun €6000 op de rekening geschreven krijgen he? Ik begrijp het helemaal.

[Blokker_1999]

Als jij voor 200 euro per maand alles geregeld krijgt wil ik je direct een contractje voorschotelen om alles te testen voor ons ...

Was het allemaal maar zo eenvoudig. Het installeren van je test updates op een VM is stap 1 van een hele lange lijst aan stappen die je moet doorlopen. En natuurlijk niet enkel voor je domeincontroller maar voor zovele servers die je hebt draaien. Of het nu een DC, je fileserver, printserver, DHCP server, terminal server, ... of 1 van de 1000 andere servers is die wij hebben draaien. Je moet wel alles testen natuurlijk.

Dat is niet gedaan met ergens 1 servertje op te zetten en die apart, sneller zijn updates te geven. Je moet een hele testprocedure hebben voor alles, je hebt mensen die daar bijna continue mee bezig zullen zijn in iets of wat grotere ondernemingen. En je komt er niet met een paar honderd euro voor wat servertjes.

[Anoniem: 25604]

Het was met een lichte ironische ondertoon, mijn reactie. De kern is, dat het inrichten van een kleine testserver of acceptatieserver - als je al geen OTA-straat wil of kan inrichten - helemaal niet zo overdreven duur hoeft te zijn voor een bedrijf. Een bedrijf hoeft niet standaard machines aan te hebben staan in een datacenter zoals vroeger vaak wel het geval was. Met een goed plan kunnen er best test-machines met standaard (bijgewerkte) templates worden aangemaakt in bijvoorbeeld Azure, die voor de duur van een goed voorbereid testscenario in de lucht moeten zijn en daarna uit worden gezet. Ik wil geen reclame maken voor Azure of AWS of whatever, maar heb je de prijzen wel eens gezien van wat een virtuele cloud machine kost? Link
In Azure heb je ook nog goedkopere opties, puur voor development doeleinden. AWS ken ik zo niet.

[Reactie gewijzigd door Anoniem: 25604 op 22 juli 2024 22:27]

[Supermuskusrat]

Maar let op dat kleine MKB bedrijven met 20 werknemers ook DC's hebben. Als er misschien 1 persoon zit met IT in het portfolio en de rest van de IT zit bij een MSP, dan is €200,- maand al snel een boel geld. De grote multinationals met een stapel IT'ers en andere technici redden zich wel. Maar het zijn de kleintjes die dit érg lastig vinden.

[Anoniem: 25604]

Natuurlijk. Maar er zijn genoeg alternatieven om niet ervoor te kiezen om helemaal niks te doen. En het begint met het controleren van wat een patch doet en hoe het jouw organisatie kan raken. Nooit klakkeloos maar Next --> Next --> Finish.

[Supermuskusrat]

Iets met automatische updates, wat bij veel MKB bedrijven aan staat. 1x in de week 's nachts automatisch herstarten. Inderdaad recipe for disaster maar dat is nou eenmaal de gang van zaken in bedrijven waar geen dedicated IT is.

[Recklezz]

Of waar wel dedicated IT is, maar niet genoeg om alle updates te testen. Vaak wordt er dan een delay van 1 of 2 weken ingesteld voordat een update auto-approved wordt.

[_JGC_]

Die strategie volg ik over het algemeen, maar als er een patchronde is met 80 zeroday lekken waarvan geroepen wordt dat je die NU DIRECT moet patchen...

Want dat is wat Microsoft de laatste tijd doet. Exchange, Windows... het is zo lek als een mandje en lekken worden op moment dat de patch bekend is al actief uitgebuit.

Je gaat er ook vanuit dat als advies is om NU DIRECT te patchen, dat het ook gewoon werkt, en dat is de laatste tijd gewoon niet het geval bij MS.

[Polderviking]

Een goede teststraat hebben die wat waard is echt wel wat bewerkelijker dan ergens een virtueel servertje afnemen.
Als je op een random VPS die verder niet op je productie lijkt een Windows update installeert weet je nogsteeds niks.

[PolarBear]

Precies dat, een OTAP straat inrichten betekend dat je 4 straten in precies dezelfde conditie moet onderhouden. Anders heb je er weinig aan. Kost je wel meer dan een virtueel servertje.

[The Zep Man]

IT (en beveiliging) worden helaas maar al te vaak gezien als zaken die enkel geld kosten en niets opleveren.

[well0549]

Als ze hun werk goed doen kosten ze inderdaad alleen maar geld.

En zijn ze minder kosten krijgt aan hacks etc.

Maar security heeft nog nooit geld op geleverd

[DigitalExorcist]

Dat laatste is onzin natuurlijk. Kijk wat het kost om te herstellen van een ransomware-aanval bijvoorbeeld. Dat geld had je makkelijk kunnen besparen.

Security kan je juist geld ópleveren: als klanten zien dat jij je security goed op orde hebt en serieus neemt, zijn ze mogelijk éérder geneigd om zaken met jou te doen.

[Scriptkid]

Opleveren != besparen

[DigitalExorcist]

Precies. daarom zeg ik ook opleveren Lees die laatste zin even.

Het kan geld besparen én opleveren.

[Reactie gewijzigd door DigitalExorcist op 22 juli 2024 22:27]

[Kevinns]

Ik ben bang dat dat tegenvalt... In de IT wereld vast, maar alles daarbuiten hebben inkopers (B2B) of particuliere klanten écht geen weet van dit alles. Zij zijn met een beetje geluk goed geïnformeerd over het product dat ze kopen maar hoe het IT landschap van hun leverancier er uitziet zal ze over het algemeen aan hun reet roesten.

Als ik een paar staalplaten inkoop van Tatasteel dan boeit het mij niet hoe ze het voor elkaar krijgen, als de prijs, kwaliteit en levertijd maar goed is. Natuurlijk moeten bedrijven hun IT op orde hebben maar dat is toch echt voor 99% om hun eigen hachje te redden. Geweldig veilige IT kan je bedrijf van de ondergang redden maar je zal er nooit rijk van worden.

[DigitalExorcist]

Dan beschouw je jezelf als áfnemer van Tata Steel. Dat was niet helemaal wat ik bedoelde

Eind 2001 hadden we te maken met de 11-september aanslagen in New York (en de crash in Pennsylvania en bij het Pentagon). Kort daarop besloot de Amerikaanse overheid dat als jij als bedrijf zaken deed met Amerika, maakt niet uit wat, jij als bedrijf aan bepaalde voorwaarden moest voldoen. 'We" moesten ineens extra hekken, bewaking, procedures en protocollen in het leven roepen omdat 'we' een product leverde aan Amerikaanse klanten. Anders werd je van de lijst geschrapt en kwam je er niet meer op. True story. Ik zal in het midden laten voor welke multinational ik werkte destijds maar heb het van héél dichtbij meegemaakt.

Zoiets kun je nu natuurlijk ook doortrekken: ik wil als bedrijf geen zaken doen met bedrijven die hun veiligheid (en dus impliciet ook de mijne!) doen. Dat doen we nu ook al dagelijks: kijk naar Facebook en toko's die hun beveiliging écht niet goed op orde hadden. Dat heeft wel degelijk klanten, en dus omzet, gekost. Als je nu als bedrijf kan claimen dat jouw beveiliging, en dat van de data van jouw klanten, goed op orde is dan straal je daar een vertrouwen mee uit wat iemand best als pluspunt kan zien om zaken met jou te doen.

Ok, het is geen businessmodel an sich en rijk wordt je er niet van, maar het kan wel degelijk iets opleveren op die manier.

[The Zep Man]

Zoiets kun je nu natuurlijk ook doortrekken: ik wil als bedrijf geen zaken doen met bedrijven die hun veiligheid (en dus impliciet ook de mijne!) doen.

Jij niet, veel van jouw concurrenten wel. Die kunnen vervolgens goedkoper hun producten of diensten aan de klanten aanbieden die ze bij jou wegsnoepen.

De meeste mensen hebben geen tijd/zin/gelegenheid over voor beveiliging. Het enige dat zaken als beveiliging en privacy afdwingt is een gereguleerde markt. Overheden moeten dus eisen opleggen, want dan is voor iedereen het speelveld gelijk.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 22:27]

[DigitalExorcist]

Nja in zekere zin zijn er wel standaarden, afhankelijk welke industrie je in werkzaam bent. Maar denk bijv. alleen al aan GDPR/AVG, dat blijkt al lastig zat om daar aan te 'voldoen'.

En die concurrenten komen zichzelf vast nog wel tegen. "Joh je bestelt al jaren bij ons maar deze week liggen we plat vanwege een cyberaanval, ja vette pech, ja ik snap dat je project nu stil ligt, maar hey, wij gebruikten graag de gratis Avast antivirus en dachten echt dat dat genoeg was he".

Nee ik ben van mening (en velen met mij, gelukkig) dat IT security ook een management probleem is en niet alléén een IT-probleem. Het gaat om de instelling van je werknemers in het magazijn tot aan de bestuursvoorzitter. Wil je goed, veilig en zeker werken? Prima. Dat kan. En ja dat kost geld, maar niet zoveel geld als een onverwachte aanval, datalek, crash en het herstellen daarvan.

Als je iets verkoopt in de IT, zoals security, moet je je klant altijd 3 keuzes bieden:

* Het kan goed
* Het kan snel
* Het kan goedkoop

En je klant mag er twéé van kiezen.

[well0549]

Ja maar als je een ransomware anaal hebt, hebben ze hun werk dus niet goed gedaan.........

Exactly my point

[mjz2cool]

En zijn ze minder kosten krijgt aan hacks etc.

Daarmee levert het toch geld op?

[Anoniem: 421923]

nee, het kost ze minder reparatiekosten maar als de storing/hack er niet was geweest was het geld ook niet uitgegeven. Onvoorziene kosten die lager uitvallen zijn nog steeds kosten.

Maar goed als je onvoorziene kosten voor bijv. een hack budgetteert heb je inderdaad een meevaller.
Zijn nog steeds uitgaven die je als zijnde 'kwijt' had geraamd.

[Reactie gewijzigd door Anoniem: 421923 op 22 juli 2024 22:27]

[vanquisher99]

Welke ota straat? Testen Op Productie is de TOP manier

[michielRB]

Back in the days, werden patches op minder cruciale servers getest met gebroken RAID1. Als die uitrol zonder problemen verliep, werd de RAID na een weekend draaien weer opgebouwd door de disk in het draaiende systeem terug te plaatsen en werd de rebuild van de RAID1 gestart.
Een week later werd de rest van het serverpark gepatched. (een 100-tal servers) Dat betekende ook dat het een maandelijks 'feestje' was om op vrijdag over te werken.
Tegenwoordig gaat dat met snapshots. Maar destijds bestond dat nog niet. (NT4/W2000 tijdperk)

[Zwelgje]

held! zo deed ik dat inderdaad ook met Citrix bakken (jaja fysiek op DL360 dozen) disk eruit, updates doen en als het goed was de disk terug.

zo niet: disk eruit, spare disk erin en booten en opnieuw proberen

'back in the days' inderdaad

[Amasik]

Zo heb ik een keer op een draaiend Windows cluster met 2 nodes een nieuwe cluster installatie gedaan.

Backup van de oude nodes op de disken uit een raid 1 set en dan op de andere disk een nieuwe cluster installatie doen. Alleen voor de cluster joint moest het systeem heel even een kwartiertje offline maar de complete applicatie en database installatie kon ik op de backup node doen en als er iets mis was gegaan met de primaire node kon ik in 5 minuten de originele disk uit de raid config terugplaatsen.

Mijn toenmalige manager snapte maar niet hoe ik het ging doen maar uiteindelijk heeft hij toen denk ik geaccepteerd dat hij al lang genoeg manager was en zijn eigen oude IT kennis was weggezakt.

[psy]

Ik dacht serieus dat je een grapje maakte. Maar dat is dus niet zo?

[_Thanatos_]

Je mag ook gewoon verwachten dat de updates van zo'n duur product goed getest worden...

[TheVMaster]

Ze zullen updates ook ongetwijfeld goed testen, maar het is natuurlijk onmogelijk om elke specifieke configuratie (hardware/software) te testen. Het issue komt (blijkbaar) niet bij iedereen voor.

[Arfman]

Je kunt ophouden MS te verdedigen hoor. Dit is een wereldwijd probleem en het komt bijna in elke situatie voor. Collega beheerders melden hetzelfde gedrag.

[TheVMaster]

Tja, je kunt ook op elke slak zout leggen Arfman. Dat het wereldwijd voorkomt en dat er veel (wat is veel?) klanten van MS last van hebben betekend niet automatisch dat er niet goed getest zou worden natuurlijk.

Dat was waar ik een opmerking over maakte. Neemt niet weg dat het onmogelijk is om voor 100% van de scenario's te testen. En het is natuurlijk ook niet echt verstandig om updates zelf eerst in een OTAP straat te testen, of op een sub set van je servers, maar goed. Dat hoef ik jou natuurlijk ook niet te vertellen, want jij draait volgens mij ook al een tijdje mee in IT land.

[Reactie gewijzigd door TheVMaster op 22 juli 2024 22:27]

[R4gnax]

Via ex-werknemers van MS, voorheen werkzaam als voornamelijk test-engineers, weten we dat MS ergens omstreeks 2015 vrijwel hun volledige afdeling dedicated manual testing de laan uit heeft gestuurd en hun hardwarepark aan gediversificeerde hardware en software omgevingen afgerangeerd heeft.

De huidige norm is dat alles op virtual machines getest wordt die bij lange niet het brede spectrum aan hardware kunnen emuleren dat eerst fysiek aanwezig was en waarmee het vrijwel onmogelijk is om vroegtijdig allerlei race condities en andere timing gerelateerde zaken op te sporen in zaken die dicht tegen hardware aanliggen, zoals drivers; CPU-schedulers; etc.

Het uitvoeren van tests op deze machines gebeurt scripted: automated tests geschreven door de ontwikkelaars zelfs. ("Wij van WC-eend..." dus.)

Om te compenseren voor het gebrek aan dedicated hardware testing maakt men nu gebruik van de Windows Insiders build en telemetry die vanuit daar terug komt. Waar diverse ontwikkelaars binnen Microsoft ook over hebben gehekeld, omdat het geen helder beeld geeft over wat er exact waar fout gaat en het onmogelijk maakt om een machine verder te instrumenteren en tot de bron van de fout terug te gaan.

Daarnaast heeft men het ontwikkelproces voor Windows als product aangepast. Het proces is nu expliciet een twee-fasen 'ping-pong' proces. Tijdens de 'ping' ontwikkelt men enkel nieuwe features. Geen bugfixes. Het wordt aangemoedigd om zo snel als kan alles klaargestoomd te krijgen en werkend of niet naar de development trunks ingemerged te krijgen. Daarna wordt in de 'pong' fase gekeken om alles op te lappen en tot volledig werkend niveau te krijgen.

Het resultaat is dat je een letterlijke lappendeken aan half-afgestopte gaten krijgt omdat features in een half-gebroken staat al geland zijn en voor de deadline af moeten. Dus half-bakken, slecht geteste patch er tegenaan en gaan.

Letterlijk: gooi alles maar tegen de muur, en kijk maar wat er blijft plakken.

Dat het wereldwijd voorkomt en dat er veel (wat is veel?) klanten van MS last van hebben betekend niet automatisch dat er niet goed getest zou worden natuurlijk.

Betekent bovenstaande dan misschien wel voor je dat er niet goed genoeg getest wordt?
Voor mij wel, namelijk. Het is ronduit schandalig.

[Blokker_1999]

Dus jij neemt een verklaring van ondertussen 7 jaar terug van mensen die ontslagen zijn als een goede bron om te zeggen dat MS geen testing meer doet? Heb je dat verhaal ooit opgevolgd?

Nee, de huidige norm is helemaal niet dat alles op VMs gebeurd. Binnen MS zelf wordt er door de devs en eindgebruikers veel meer getest op de eigen systemen en je hebt daarnaast ook de enorm diverse hardware van insider builds. Miljoenen mensen hebben zichzelf op die insider builds gezet waardoor er net op veel meer diverse hardware getest kan worden dan ooit voorheen.

En ook QA testers volgden over het algemeen gewoon scripts en tests die door mensen bedacht werden. Je zit daar opnieuw niet met de spontane problemen die zich voordoen of die je vandaag vanuit de insiders krijgt waar mensen hun systeem wel gewoon voor dagelijks gebruik inzetten.

Welke oplossing is beter? Dat durf ik niet zeggen. Natuurlijk gaat een QA tester die ontslagen wordt zeggen dat het nu slechter gaat. Maar komt dat omdat het slechter gaat of is dat vooral omdat deze persoon zijn baan verloren ziet gaan? Is de kwaliteit echt zoveel slechter geworden? Ik denk het niet.

Het is niet alsof we in de tijd van QA teams geen grote problemen zagen die vele systemen konden treffen. Toen gebeurde dat even goed.

[Iblies]

Miljoenen mensen hebben zichzelf op die insider builds gezet waardoor er net op veel meer diverse hardware getest kan worden dan ooit voorheen.

Heb je hier een bron voor?
Iedereen die beetje serieuze beheerder is kent een adagium,
laat anderen voorgaan 🤡


Het probleem met al die insider builds is dat je geen representatieve groep hebt. Je gaat het risico niet lopen 1000 pc’s een update geven als je niet 100% zeker weet dat het feilloos zal gebeuren maar ook dat wanneer er iets gebeurt je tijdig een rollback kunt doen.


En dat het vroeger ook wel eens mis ging is geen argument. Je hebt nu veel meer mogelijkheden om te testen waaronder VM,
alleen die VM’s blijven onrealistische situatie simuleren en dan ben je er niet eens.

De resultaten van de VM’s, daar worden weer AI mee getraind waardoor je GIGO krijgt,
Garbage In, Garbage Out.


Dat je op een gegeven moment in de knoei komt laat Apple zien met hun recente “fix” van meer 700MB dat kan oplopen tot +900MB.
downloads: Apple iOS 15.2.1
15.0 wat een major update was, was ongeveer 2,2GB.


Daar waar jaren al wordt gevraagd de boel uit elkaar te vissen,
zie oude internet explorer,
zie je nog steeds dat alles op een dusdanige manier met elkaar verweven is, dat er een domino-effect ontstaat. Je “fixed” het een, en vervolgens ontstaat er verderop weer een of twee problemen bij.

[R4gnax]

Dus jij neemt een verklaring van ondertussen 7 jaar terug van mensen die ontslagen zijn als een goede bron om te zeggen dat MS geen testing meer doet? Heb je dat verhaal ooit opgevolgd?

Ik heb hier de links naar de artikelen niet meer.
Maar wat ik schreef is niet een enkel verhaal uit één bron. Het zijn zaken die los van elkaar, uitgesmeerd over een periode vanuit verschillende bronnen in en rondom Microsoft naar voren gekomen zijn en het is ook op diverse goed gecrediteerde sites zoals Ars Technica ter sprake gekomen, waar de redactie er ook achter heen is gegaan en aan bronverificatie heeft gedaan.

[Reactie gewijzigd door R4gnax op 22 juli 2024 22:27]

[GeroldM]

Leer 1 goede les: de ontwikkelaar die een stuk software schrijft zou nooit en te nimmer een test voor dat stuk software mogen schrijven.Om 1 simpele reden. Deze ontwikkelaar kent zijn/haar code te goed en schrijft een test die zijn/haar bias volgt. Dat moet de ontwikkelaar niet kwalijk genomen worden, die kan daar namelijk niets aan doen.

Het ideale scenario is: specificatie is gemaakt. De ontwikkelaar van de code leest het door en schrijft zijn code. Een andere ontwikkelaar leest de spec ook door en schrijft zijn unit test(s). Een tester leest de spec ook en verifieert of de code en unit test(s) goed zijn uitgevoerd.

En ja, het ontgaat mij dus niet dat dit allemaal soepel geautomatiseerd zou moeten werken. Praktijk is helaas anders. Efficientie is het doel van automatizatie, maar er komen nog altijd tevel fouten in de omloop en men krijgt een valse vorm van efficientie, rolt software uit die niet goed genoeg is getest en wie weet hoeveel uren in verloren productiviteit deze ongein kost. Het kost Microsoft een stuk minder dan het bedrijfsleven dat gebruik maakt van hun tools. Dat is wel duidelijk.

Natuurlijk, vroeger ging het ook redelijk vaak fout, want er zijn nou eenmaal zoveel verschillende configuraties op net zoveel verschillende hardware mogelijk.

Toch heb ik het idee dat dit tegenwoordig een heel wat minder groot probleem is dan in de pre-WIndows 7 tijd. Hardware en drivers moeten sinds Wndows Vista/Windows 7 namelijk aan heel veel regels voldoen. En dat is ondertussen al een lange periode waar hardware fabrikanten drivers moeten schrijven en die doen dat dan liever in 1 keer goed voor een grotere serie hardware in hun assortiment, want dat is voor hen een stuk goedkoper. Oftewel, gelijkheid blijheid.

Dat was voor Windows 7 behoorlijk anders. En daar zaten vroeger de meeste grote fouten in. Maar nu het allemaal toch heel wat strikter in het geheel is gaan lopen, doet het argument 'zoveel verschillende hardware, zoveel verschillende configuraties' minder ter zake dan de meeste mensen zullen verwachten.

Dit soort fouten die Windows Servers omleggen, die zouden niet voor moeten komen. Het is tenslotte zo dat een beetje degelijke Windows Server minstens 10.000 Euro aan licenties per jaar kost. Daarvoor mag je toch echt wel een degelijker test systeem bij Microsoft voor verwachten. Het is namelijk echt niet zo dat zij dit niet kunnen bekostigen. Maar Microsoft geeft tegenwoordig meer de indruk dat ze veel te weinig aan testen doen, terwijl de tarieven alleen maar omhoog gaan.

Het zal echter allemaal wel bij een 'master-plan' horen, waarbij fouten als deze hun Azure omgeving in een goed daglicht laat verschijnen en ze weer wat extra abonnementjes kunnen wegzetten. Misschien wat cynisch van mijn kant, maar niet onwaar.

[RefriedNoodle]

Leer 1 goede les: de ontwikkelaar die een stuk software schrijft zou nooit en te nimmer een test voor dat stuk software mogen schrijven.Om 1 simpele reden. Deze ontwikkelaar kent zijn/haar code te goed en schrijft een test die zijn/haar bias volgt. Dat moet de ontwikkelaar niet kwalijk genomen worden, die kan daar namelijk niets aan doen.

Het scheelt al enorm als je de tests schrijft, vóórdat je de code schrijft.

[Arfman]

Elke slak zout leggen? Ik ken instellingen die hier echt serieus last van hebben gehad en niet hebben kunnen werken. Dit soort botched updates zijn echt onvergeeflijk, heb ik het nog niet eens over de L2TP VPN verbindingen die ook niet meer werken.

Of zijn we PrintNightmare ook alweer vergeten? MS maakt er een zooitje van.

[TheVMaster]

Het ging erom dat ik reageerde op 'Je mag ook gewoon verwachten dat de updates van zo'n duur product goed getest worden.'.

Je kunt niet elke configuratie/situatie testen. Snap dat jij 100% garanties verwacht, dat updates never nooit problemen gaan geven. Dat is misschien in een perfecte wereld mogelijk, maar daar leven wij (helaas) niet in.

Voor de rest kan ik mij wel aansluiten bij de reactie van @Blokker_1999 :-)

[Arfman]

Er zijn problemen met DC's die in een bootloop raken op fysieke hardware, op allerlei versies van VMware vSphere, Hyper-V .. je maakt mij niet wijs dat MS zoiets simpels niet kan testen.

[Eochaidh]

Alle DC's zijn hier voorzien van de updates en geen enkele bootloop. Dus het testen van MS was voor ons voldoende. Dus dat zooitje mag best wat genuanceerder denk ik. Neemt niet weg dat het erg vervelend is dat je aan de bak moet als je wel tegen problemen aan loopt.

[Arfman]

Ik spreek je over 24 uur wel opnieuw

[Eochaidh]

De DC’s zijn dinsdagavond rond 23:00 van de updates voorzien. Dus die 24 uur is ruim verstreken.

[Arfman]

https://www.bleepingcompu...tes-due-to-critical-bugs/

[Eochaidh]

Onderdaan zelf gepost in deze thread

[Luchtbakker]

Je mag ook gewoon verwachten dat de updates van zo'n duur product goed getest worden...

Volgens mij draai je updates altijd in een acceptatie omgeving voordat je naar je productie omgeving gaat. Bij kleine locaties is dat wat minder het geval, maar grotere locaties met kritieke systemen doen dat absoluut wel.

[gimbal]

Ik ga er zomaar vanuit dat er goed getest wordt. Ja echt wel.

Maar nog niet goed genoeg.

[The Zep Man]

Het is tongue-in-cheek. Testen op productie (als in: niet testen, of gefaseerd uitrollen in productie) wordt daadwerkelijk gedaan. De Test Op Productie (Test On Production) titel is een sarcastische manier om ernaar te refereren, want het is natuurlijk allesbehalve 'top'.

[psy]

Dat wist ik niet.
Kwam ook daadwerkelijk artikelen tegen, zoals op Computable.
https://www.computable.nl...eit-of-fictie-deel-1.html

Maar bij ons in een SAP omgeving is dit (nog) niet aan de orde. Lijkt mij best lastig, je draait niet zomaar zaken terug die fout zijn gelopen.

[Anoniem: 25604]

Okee okee... ik kom duidelijk uit de 1832, toen Napoleon het Kadaster oprichtte.

[DigitalExorcist]

Toen de Batavieren nog met z'n vijfen waren?

[beerse]

En de Russen ook niet met vier.

[Jay-v]

Nu is Active Directory meestal wel een service waar OTA (als die er al is) significant afwijkt van P.

[beerse]

Hoezo? Met een beetje omgeving heb je meerdere domaincontrollers.
En als het goed is heb je voor patchen van alle varianten van jou machines in ieder geval machines aangewezen die als eerste gepatcht gaan worden en hopelijk daarna alsnog in 2 of 3 golven.
Dus eigenlijk een otap straat voor patchen. Maar dan hopelijk dwars op de otap-straat voor je eigen producten.

En ja, ik zou 1 van de domaincontrollers aanwijzen als 1 van de machines om als eerste te patchen. Voor domaincontrollers geldt voor mij het zelfde als voor nodes van een cluster. 1 kan mee met de eerste patch golf.

[Bramzie]

Vaak wordt hier op Tweakers wel vergeten dat voor een hoop kleinere organisaties het gewoon niet praktisch is om een gehele tweede omgeving te draaien waarin je kan testen. Daarnaast is het zo dat er vaak helemaal geen vaste IT-er is waardoor zaken in "eigen" beheer zijn.

Dan is uitrollen en hopen op het beste de enige oplossing.

[Ooyevaar]

Klopt, maar niet iedere organisatie heeft het budget voor zo'n omgeving en de mankracht die daar bij hoort.
Dat is dan elke keer weer schipperen tussen wachten totdat anderen de kinderziektes gevonden hebben of hopen dat niet updaten geen beveiligingsgat slaat.

[Arfman]

Wat er gebeurde was dat er zulke kritieke lekken werden gedicht met deze patches, dat veel mensen ervoor kozen om ze in hoog tempo door de OTA straat te duwen. De meeste DC's beginnen pas na een paar uur met rebooten en tegen die tijd ben je al bezig in PROD omdat er CVSS scores van 9.8 te zien waren.

[Nyarlathotep]

Ja?
Maar dat lost het probleem niet op. Omvallen is omvallen, of dit nou op test of produktie gebeurt staat daar los van.

[Anoniem: 25604]

Als je ooit met WSUS hebt gewerkt en het patch-traject daarin serieus neemt, dan ontdek je best wel wanneer een update jouw machines en/of omgeving pijn gaat doen. Je hoeft een patch niet naar Productie door te zetten als blijkt dat ontwikkelaars of testers niet meer kunnen inloggen in jouw integratie- of acceptatiedomein.

[CopyCatz]

Hier nog een hoop dev collega's die enorm salty zijn. En ik vermoed gisteren alle treinreizigers in noord Nederland ook salty vanwege de NS security afdeling..

[beerse]

Dan de machines waar zij op werken als eerste en unattended met automatic reboot.

[Simon Weel]

Ik ben beheerder van een kleine omgeving. En nee, patches worden niet ala-minute geïnstalleerd. Ik raadpleeg het MS-Defcon systeem van Suzan Bradley

[Blokker_1999]

Leuk, maar aan de andere kant heb je bugs met een CVE score 9.8 die gepatched worden vanwege RCE. Dan moet je dus ook niet afgaan op zoiets maar vooral wat selectiever durven zijn. Als het probleem beperkt is tot DCs, patch dan je DCs niet maar de rest wel.

[Simon Weel]

Klopt. Het is ook niet alleen een MS-Defcon die ze afgeeft; daar komt een onderbouwing bij.
Maar het blijft een zelf te maken afweging.

[DDX]

Wat er vooral misgaat is dat Microsoft gewoon rustig paar dagen in winterslaap blijft voordat ze extra info bekend maken.
Zo ook de exchange yk22 bug van 1 januari, pas op zondag kwam Microsoft met een kb artikel/oplossing.

En ondertussen allemaal forums/blogs met info dat patches niet goed zijn.

[Reactie gewijzigd door DDX op 22 juli 2024 22:27]

[HADES2001]

Gisteren was het uitgebreide bericht dat sommige gebruikers sommige dingen in 365 services niet konden. Gewoon letterlijk dat kwa info, niet welke services niet wat voor gebruikers maar gewoon "sommige mensen kunnen sommige dingen niet"
De communicatie is echt bedroevend en merk ook dat sinds de hele corona start en iedereen thuiswerkt er bijna geen enkele dag is dat alles werkt. Elke dag in de health pagina is er wel een service die eruit ligt

[LCP]

De problemen doen zich in ieder geval voor bij Windows Server 2012 R2, Windows Server 2019 en Windows Server 2022

Waar is 2016 gebleven?

[HADES2001]

Misschien heeft die het issue niet? moment ik heb er 4 draaien in productie las hierboven de TOP tactiek ik druk even op update en laat het je weten

[Dennisb1]

Jawel die heeft ook het probleem.

Dennisb1 in 'nieuws: Windows Server-update veroorzaakt bootloop domeincontrol...

[brinkie2004]

Het probleem is dat het artikel twee patches op een hoop gooit. Het probleem met Hyper-V doet zich op Windows Server 2012 R2 wel voor, maar op Windows Server 2016 bijvoorbeeld niet (uit eigen ervaring helaas).

[Gupje360]

Heb hier last van gehad gister, maar probleem is eigenlijk niet meer terug gekomen.

[Barryke]

Dit is erg vervelend natuurlijk, maar eerlijk gezegd moest ik wel lachen bij deze headline.
Iedereen leunt op dezelfde giganten, en struikelt tegelijk als deze peiler wat gebeurt.

Voor standaard problemen zijn gelukkig standaard oplossingen, met ook weer standaard problemen uiteraard.

[well0549]

Was bij log4j niet anders, wordt nog steeds continu gepatched, een nog steeds zijn niet alle systemen op de juiste versie

[Anoniem: 1322]

Haha, nou ik kan je vertellen dat er ook genoeg organisaties zijn die de ellende al Microsoft al jaren geleden zat waren en vertrokken zijn. Vooral hier in Nederland is men heel erg 'microsoft minded' en praat men de marketing brochures graag na.

Maar zelfs dan, als je Microsoft's advies had gevolgd van de laatste 10 jaar dan had je ook al geen on-premise servers meer gehad.

Geen centje pijn dan ook aan deze kant. Ik lees deze artikelen altijd met een glimlach dat we toen toch de goede richting hebben gekozen.

[jvalks]

Wat is 'genoeg organisaties'? Wat is een betere tegenhanger die ook een goede integratie hebben met andere soortgelijke software pakketten?

[Anoniem: 1322]

Wat is 'genoeg organisaties'?
Nou, de meeste 'nieuwe' organisaties hebben niet de afhankelijkheid van Windows dus die beginnen daar ook niet aan. Ik zit zelf veel in de zorg en die stapt massaal over naar Google Workspace.

Wat is een betere tegenhanger die ook een goede integratie hebben met andere soortgelijke software pakketten?
Je bekijkt het van de verkeerde kant, iets dat veel gebeurd. Iedereen is op zoek naar een tegenhanger maar de echte vraag die je moet stellen is: waarom ben ik afhankelijk van Windows?
En het antwoord is altijd de applicaties die je draait.

Als je oude applicaties vervangt voor moderne varianten (die vrijwel altijd webbased zijn) dan maakt het niet meer uit welk platform je draait. Ik gebruik zelf MacOS maar ook Linux. Ik kan mijn werk op iedere werkplek of locatie uitvoeren. Moderne applicaties hebben ook een open API waardoor integratie met andere software pakketten (die ook weer een open api hebben) eenvoudig en robuust is.

Het probleem is wel, dat inzicht moet er zijn en vaak is het een meerjarenplan.

[jvalks]

Ja ok, dan is de doelgroep inderdaad kleiner. Gelukkig kunnen veel applicaties ook via SaaS worden afgenomen, dan is de noodzaak voor een Windows OS ook kleiner in veel gevallen.

[Anoniem: 1322]

Ja ok, dan is de doelgroep inderdaad kleiner.
Valt wel mee, ik werk bij organisaties van 1000 tot 5000 medewerkers. Het is enkel een kwestie van tijd voordat organisatie de realisatie hebben dat ze gegijzeld zijn door hun eigen applicaties. Kosten van IT lopen enorm uit de klauwen


Gelukkig kunnen veel applicaties ook via SaaS worden afgenomen, dan is de noodzaak voor een Windows OS ook kleiner in veel gevallen.
Inderdaad, het is onvermijdelijk dat men hier naar toe gaat. Microsoft weet dit ook al 10 jaar en promoot dit actief (met eigen web based applications) Het draait hier dan ook helemaal niet om Windows ofzo. Een medewerker mag het van mij ook prima draaien als ze dat willen.

[beuki]

Is er wellicht al meer informatie vanuit Microsoft? Hebben ze al bevestigd dat er een fout in zit en wellicht aangegeven wanneer ze dit opgelost hebben in een nieuwe update ? Ik kan zo snel nog niets hierover vinden.

[saucemarocain]

Ja op de update pagina van Msoft

“We are presently investigating and will provide an update in an upcoming release“

Zo lijkt het wel of ze zich niet meteen gehaast voelen en er pas bij de cumulative update van februari een fix komt…

[gjaltz]

1 hyper-v server van dell werkte hyper-v niet meer de hp machines hadden geen probleem.