When Windows Server 2025 is delivered like it's 1999, nobody gets to party

What's the difference between a broken update system and a malware injection engine?

Opinion A seemingly simple, single mistake in metadata that auto-trashes a critical, major component in the Windows ecosystem sounds bad. And it is, in so many ways.

Let's start with Microsoft, which at the very least appears to have committed a self-induced supply chain attack on its own customers. The Windows Server 2025 complete OS upgrade was labeled as a security patch, the affected company claimed. People make mistakes, which is why you have automation that doesn't. Or you have people whose job it is to spot mistakes before pushing live. Or you have automation that spots mistakes before pushing live. Or, if you're a trillion-dollar company whose code runs quite a lot of the world, you have all three options.

Microsoft, one might assume, has none of these three options in place. You cut and paste the wrong data into the wrong field? Congratulations, you are today's Malware Emperor, and have just pushed the launch button on an intercontinental ballistic pain missile. Whoosh! Off it goes into the internet. Isn't it pretty?

There is still hope for humankind, still time to catch the mistake before it blossoms into calamity. It's a security update that's five fricking gigabytes? That expects to find 32 GB spare storage to land on? Mister, that's no security patch. What's the biggest security patch bundle that a Microsoft product has ever needed? Those who just shouted "Linux" can pop back to 2015 when that was still clever, but at the very, very least an "Are you sure?" query should go up somewhere a carbon-based life form has to see it.

Likewise, a patch that claimed to be for Windows 11 but had a Windows Server payload should require modern intervention. Nope, a third-party patch management service had been configured to auto-install anything labeled as a security fix, no matter how much evidence there was otherwise.

All along this particular trajectory of tragedy, automation was doing the wrong thing because humans had done the wrong thing. It doesn't help that Windows Update has its roots in computing's Imperial Age, where economies of distribution and the chokeholds on supply chains meant most updates were full OS installations arriving on fleets of physical media. The need for faster, finer-grained updates only arrived with the internet providing both the mechanism to deliver them and the security threat environment that made them necessary.

For an internet-native OS like Linux, there are no real lines between patches. Updates and upgrades are extremely fluid. There is no one right way to manage updates. In enterprises, sysadmins must simultaneously delay changes to critical systems until they are absolutely sure they are safe, while applying patches as quickly as possible to maintain maximum stability and security. That's a lot of work reading change logs, creating, maintaining, and running test systems, and keeping up with both big-picture and vendor-specific trends.

This is not the world Windows Update was designed for, though. Sanity checks, manifests of what's being altered where and why, detailed update process progress, and control options are not in its nature. The basic idea came in with Windows 9x, and it shows. The best you can hope for with Windows Update for Business is the chance to defer deployment for a while to run up test systems.

Closed source thinking means a legacy of secrecy and central control, where the end customer's knowledge of what's going on is a blue progress bar and a percentage completed count with as much connection to reality as Salvador Dali had to watchmaking.

There's no fundamental reason for update, patching, and upgrade mechanisms to be OS-specific at all. The job is the same, and interacts with running OS and app code in a limited way. From the system updater's point of view, target machines can be thought of as a database of static data that needs to be rewritten from time to time.

The rules for how and the metadata for what will vary, but the mechanism need not. An open framework that gives maintainers the roles for fine-tuning updates, and OS and app creators the ability to create a single unified ecosystem? Increased reliability, far better tools, and no loss of commercially important differentiation? It would be a properly designed supply chain for the most important part of the digital world, the code that makes it run.

It would also fix the dreadful discordant mess that is package management, a sin from which open source is most definitely not exempt. Which is not to say proprietary pond life isn't far uglier, where there's been no package management before the concept of the app store was kidnapped from mobile and roughly bolted in. Even Apple can't be bothered to put a proper package manager into its macOS CLI environment. Because there are no security or reliability implications in making the most powerful and system-intimate tool in the OS needlessly difficult to manage, right?

The whole business of patching, updating, and upgrading is criminally under-thought, under-invested, and under-appreciated across the board. This time, it was a single point of failure that automatically fried core services and reduced stocks of clean underwear.

What will it be next time? Because there will be a next time, and a time after that, until we stop patching and do the full upgrade we need. ®