It's possible that CrowdStrike heavily incentivises being left to update itself.
Removing the features that would allow sysadmins to actually do it automatically, even via the installer itself- would definitely be one way, but another one could be aggressive focus-stealing nags (similar to Windows' own nags) which in a server environment can actually cause some major issues, especially when automating processes in Windows (as you need to close the program when updating).
I think it's easy to blame the sysadmins, but I would also be remiss if I didn't point out that in the Windows world we have been slowly accepting these automatic dark patterns and alternative (more controlled) mechanisms have been removed over time.
I almost don't recognise the deployment environment today as to what it was in 2004; and yes, 20 years is a long time, but the total loss of control over what a computer is doing is only going to make issues like this significantly more common.
They say it was caused by a faulty channel file. I don't know what a channel file is, and they claim to not rely on virus signatures, but typically anti virus product need the latest signatures all the time and poll them probably once an hour or so. So I'm not surprised that an anti virus product wants to stay hyper updated and updates are rolled out immediately to everyone globally.
No, I'm not surprised either. But if you're operating at this kind of scale and with this level of immediate roll-out, what I would expect are:
* A staggered process for the roll-out, so that machines that are updated check-in with some metrics that say "this new version is OK" (aka "canary deployment") and that the update is paused/rolled back if not.
* Basic smoke testing of the files before they're pushed to any customers
* Validation that the file is OK before accepting an update (via a checksum or whatever, matched against the "this update works" automated test checksums)
* Fuzz tests that broken files don't brick the machine
Literally any of the above would have saved millions and millions of dollars today.
In any kind of serious environment the admin should not have any interaction with any system's screen when performing any kind of configuration change. If it can't be applied in a GPO without any interaction it has no business being in a datacenter.
There are situations where you will interact with the desktop, for debugging reasons not-withstanding. Saying anything else is hopelessly naive. For example: how do you know if your program didn't start due to missing DLL dependencies? There is no automated way: you must check the desktop because Windows itself only shows a popup.
2) What displays on the screen is absolutely material to the functioning of the operating system.
The windows shell (UI) is intertwined intrinsically with the NT kernel, there have been attempts to create headless systems with it (Windows Core etc;) however in those circumstances if there is a popup: that UI prompt can crash the process because it does not have dependencies to show the pop-up.
If you're in a situation where you're running windows core, and a program crashes if auto-updates are not enabled... well, you're more likely than not to enable updates to avoid the crash, after all, whats the harm.
Elsewise you will be aware that when a program has a UI (windows console) the execution speed of the process will be linked to the draw rate of the screen, so having a faster draw rate or fewer things on screen can actually affect performance.
Those that write Linux programs are aware that this is also true for linux (write to STDOUT is blocking), however you can't put I/O on another thread in the same way on Windows.
Anyway, all this to say: it's clear you've never worked in a serious windows environment. I've deployed many thousands of bare-metal windows machines across the world and of course it was automated, from PXE/BIOS to application serving on the internet, the whole 9 yards, but believing that the UI has no effect or no effectiveness of administration is just absurd.
Removing the features that would allow sysadmins to actually do it automatically, even via the installer itself- would definitely be one way, but another one could be aggressive focus-stealing nags (similar to Windows' own nags) which in a server environment can actually cause some major issues, especially when automating processes in Windows (as you need to close the program when updating).
I think it's easy to blame the sysadmins, but I would also be remiss if I didn't point out that in the Windows world we have been slowly accepting these automatic dark patterns and alternative (more controlled) mechanisms have been removed over time.
I almost don't recognise the deployment environment today as to what it was in 2004; and yes, 20 years is a long time, but the total loss of control over what a computer is doing is only going to make issues like this significantly more common.