Windows Server domain controllers may stop, restart after recent updates Updates to Windows Server released as part of this month's Patch Tuesday onslaught might cause some domain controllers to stop working or automatically restart, according to Microsoft. The enterprise software behemoth said organizations installing KB5019966 or later updates on domain controllers (DCs) could see a memory leak …
If Microsoft can't even properly patch the OS on their Servers or Desktops (and this month is just the latest example of their poor QA process), why do we keep pushing this crap on our users? Anyone who has any say so in the future direction of their network infrastructure should be pushing for alternative OSes where applicable.
Why do MS keep pushing this crap on our users?
Because the users are like junkies in that they are hooked on the product.
Some of the more enlightened amongst us have thrown in the towel and stopped using any MS product. In my case, I've been MS-free for six years and two months. There is zero chance that I'm going back.
For me it is MacOS and Linux all the way.
Because the users are like junkies in that they are hooked on the product.
I was sys admin, and I gotta say, users had little input into the OS they were running, we tried to use the best OS for the task at hand. I supported macOS(writing this from macOS!), and Windows, if macOS covered the bases, they got that. If they needed a windows only app, then we would provide Windows.
As the arm chair sys admin(the only IT guy in the family) I tried in all cases to get macOS in their hands. But most opted for windows because of cost of the hardware and games...
users really don't care. Fanbois care.
There's just too much material here to work with, it's become onerous. I ditched my last 'Doze client in 2000, ain't looked back.
There's a difference between domestic and commercial use tho. For home use, yep, you can't change the anchoring bias. For business, no one ever got sacked for buying "IBM". Carry on as you like C-Suite, but I'm not helping you with that shit storm.
Ok, so it is the key subsystem for authenticating users, and they're so concerned about security of their systems and their customer's data that they tested it thoroughly before release as they usually do, eh?
Personally I'd take it as a final straw and bend over backwards to get away from Microsoft after this one, because it isn't "just this one" - it's a steady stream of screwups from Microsquishy. :(
Consider:
You have multiple domain controllers in an enterprise.
that if you update one domain controller with the november 8th patch, you *will* start running into problems with things like RDP from clients that use that domain controller for authentication to destinations that have not been patched yet.
They broke Kerberos with the nov 8th patch by telling it to start using AES as the default encryption type instead of RC4.
The november 17th OOB patch fixes that as well, but it's been a very frustrating couple weeks chasing that one down.
Hey, it looks like your DC are broken and users are crying to the Helldesk? How about you put that all behind you and play a rousing game of Minesweeper in Teams!
OTOH, could we run SAMBA under Microsoft's new Linux services store app? Maybe that would be more stable than the stuff Microsoft touches, because that's twice this month they've borked their own fucking server software with an "update". Christ on the Cross, is their development process really that broken internally?
There comes a time when you have to look at how and why you are "trimming the fat" and realise that you've trimmed not just the fat, but the muscle, too. In this case, QA testing.
Microsoft have been undermining faith in their own products since they changed their QA to save money some years back. The effect is slow, but eventually enough people will turn their backs on MS products in the enterprise sphere and when that happens the licensing revenue loss will hit home big time. Obvious, stupid and avoidable.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
