Daniel sent us this one, and it hits on something I've wondered about plenty of times myself. He's been on Linux for over twenty years on the desktop, so whenever he spins up a server, Linux is the obvious pick. The only time Windows Server ever enters the picture is inside a VM, and only when some specific program demands it. His question is basically: who's actually running Windows Server, why, and is anyone still doing it on bare metal, or is it all just VMs for one or two stubborn workloads? Given that hypervisors mostly run on Linux now, where does Windows Server still earn its keep?
It's a sharper question than most people realize, because the vibes say Linux owns the server world entirely, containers ate the monolith, everything's cloud-native, move along. But the numbers tell a different story. IDC's first-quarter report this year shows Windows Server still holds roughly thirty-two percent of x86 server operating system shipments. That's down from forty-eight percent in twenty twenty, so the trend is real, but thirty-two percent is not a rounding error. That's tens of billions of dollars of deployments.
Thirty-two percent. So for every three servers running Linux out there, there's roughly one running Windows Server. That's way higher than I would have guessed from reading tech blogs alone. And I think what makes it invisible to a lot of us is that these aren't the servers being discussed at KubeCon. Nobody's giving a keynote about their Windows Server migration story unless it's a eulogy.
And that gap between the conversation and the reality is the whole show today. We're not asking whether Windows Server is good or bad. We're asking where it's actually the rational choice, where people are spending real money on it in twenty twenty-six, and whether the bare-metal Windows Server still exists as something other than a historical artifact.
I think there are really three buckets here. There's the legacy app compatibility bucket, where some piece of software was written twenty years ago and nobody's rewriting it. There's the Active Directory identity lock-in bucket, which is huge and we need to dig into. And then there's the specialized hardware bucket, NVRs, medical imaging, industrial control systems where the vendor just refuses to support anything else. Let me float a fourth though, before we dive in. What about the org chart bucket? The one where the Windows admin team has been there since the George W. Bush administration and they have zero incentive to learn something new, and management has zero appetite for the political fight?
That's absolutely a factor and it's the one that never shows up in the architecture diagrams. You can't draw a Visio shape for "Terry has been managing these boxes for seventeen years and will make your life difficult if you try to change his stack." But it's real. I've walked into mid-market companies where the entire IT department's identity is built around Microsoft certifications. Asking them to adopt Linux isn't a technical conversation, it's a career conversation.
So let's break down where Windows Server actually shows up, starting with the biggest anchor of all, Active Directory. Because AD is not just a directory service, it's the identity, authentication, policy, and management backbone for entire enterprises, and it's been accumulating dependencies for twenty-five years now.
To really understand why AD is such a gravity well, you have to look at what it actually touches in a typical organization. I did a count once for a manufacturing company with about two thousand employees. Their Active Directory was the authentication source for: Windows workstations obviously, but also the VPN, the Wi-Fi network via RADIUS, the badge access control system, the payroll application, the ERP system, three different internal web apps, the print servers, the file shares with their impossibly complex NTFS permission trees, and the building management system that controlled HVAC. That's thirteen distinct systems, each with its own integration, its own service account, its own expectation of how AD behaves.
The thing about Active Directory is it's like the foundation of a house that's had five additions built on top of it. You don't replace the foundation without rebuilding the house. You can't swap it out for something else without rethinking every system that authenticates against it. And here's the part that doesn't get said enough: most of those integrations weren't built by a central architecture team. They were built by some sysadmin in two thousand and eight who needed the HVAC system to authenticate and found a way to make it talk LDAP to a domain controller. That person is long gone. The documentation is a sticky note on a monitor that got recycled in twenty fifteen.
The replacement conversation is where so much analysis goes wrong, because people say look, Samba Four can act as a domain controller and FreeIPA can handle identity management. Technically true, and technically leaving out the entire ecosystem that has grown around AD. Group Policy alone, the ability to push configuration to thousands of machines down to the registry key level, that's not something you replicate with Ansible in a weekend. There are compliance regimes, think finance, healthcare, defense, where auditors expect to see specific Group Policy objects configured in specific ways. I talked to a CISO at a regional bank who told me their auditors have a checklist that literally references Group Policy object GUIDs. Not the policy intent, not the security outcome. The actual GUID string. If they move to a different policy engine, they have to renegotiate the entire audit framework with regulators who have no incentive to move quickly.
It's not just technical lock-in, it's audit-and-compliance lock-in too. And the GUID thing is wild, but it makes perfect sense when you think about it from the auditor's perspective. They've been trained on what a compliant Windows environment looks like. They can walk in, run a script, check the GUIDs, and sign off. You're asking them to learn an entirely new stack just so you can save on Windows licenses? That's not their problem.
And here's where the timing of Daniel's question is interesting. Microsoft released Entra ID, which used to be called Azure AD, and they've been pushing hybrid identity for years. You'd think that would be killing on-prem AD. But Microsoft's own documentation from January this year shows forty percent of Exchange organizations still run hybrid deployments. Hybrid means you still have on-prem Exchange servers, which means you still have on-prem Windows Server. The cloud has not vacuumed up the identity layer the way everyone expected.
Forty percent of Exchange orgs still hybrid. That's the Exchange trap. Even if you want to be fully in Exchange Online, Microsoft's supported path to manage recipient attributes and certain mail flow rules still goes through an on-prem Exchange server. You're required to keep a Windows Server box running, often just for the Exchange management tools. And I want to pause on this because it's such a perfect example of how architectural dependency sneaks up on you. These organizations made the decision to go to the cloud. They signed the contract. They migrated the mailboxes. They did everything right according to the Microsoft playbook. And at the end of that journey, they still have a Windows Server sitting there, not because they wanted it, not because they forgot about it, but because Microsoft's own architecture says you must.
They've been promising to close that gap since twenty-nineteen. Promised again in twenty twenty-three. And in their last update they basically said "we're working on it, please keep your Exchange server patched." The tone was almost apologetic. So you've got entire organizations that are committed to Microsoft three sixty-five, fully cloud in their messaging, and yet there is a Windows Server running in a corner of the data center specifically because Microsoft requires it. That is not legacy. That's current architectural dependency. That server was probably deployed in twenty twenty-two specifically to satisfy the hybrid requirement.
It's the longest tail in enterprise software. And Exchange is just one example. What about SQL Server? Because that's where I see a lot of shops that are otherwise Linux-everywhere still running Windows.
SQL Server's an even better case study because it actually does run on Linux. SQL Server twenty twenty-two has full Linux support, and it works well. I've run it. It's not a second-class citizen in terms of the core database engine. But here's the asterisk. SSIS, that's Integration Services, the main data extraction, transformation, and loading tool, is still Windows-only as of Cumulative Update twelve from last year. Reporting Services, same deal. Failover clustering with Availability Groups in the configuration most DBAs trust for high availability, Windows only. And the tooling, SQL Server Management Studio and SQL Server Agent for job scheduling, are either Windows-only or just more battle-tested on Windows. Most enterprise DBAs are an extremely conservative species, and I say that with deep affection.
I've met DBAs. The affection is debatable.
They've been managing SQL Server the same way for fifteen years, and when you tell them SQL Server on Linux is ready, they ask three questions. One, does the third-party backup software support it the same way? Two, does our monitoring stack, SolarWinds, DataDog, whatever, see Linux SQL the same way it sees Windows SQL? Three, what happens at three AM when it breaks?
The answer to question three is you spend a lot of time on a Red Hat support call that might not understand SQL Server internals the way Microsoft support does on Windows. That's the dread that keeps SQL Server on Windows for a lot of shops. The DBA's nightmare scenario is a Severity twenty-one error at two in the morning, the database is down, the trading desk is calling, and you're on the phone with a support engineer who's reading the Linux troubleshooting script for the first time because their expertise is the Windows kernel. Even if that scenario is unlikely, the fact that it's possible is enough to kill the migration conversation.
Right, and here's a concrete case study I want to lay out because it probably represents thousands of organizations. Mid-sized bank, about six hundred employees, somewhere in the Midwest. They're running twelve Windows Server twenty twenty-two VMs. Ten of them exist solely for Active Directory, Group Policy, DNS integrated with AD, and a single line-of-business dot net app that was written in twenty twelve and handles loan origination. The rewrite is scheduled for twenty twenty-eight. They know, intellectually, that Linux would be cheaper, Samba might work, but the dollar cost of the Windows licenses does not come close to the cost and risk of touching the identity architecture. The CIO is not making a technical decision. He's making an insurance decision.
The cost-benefit calculation for license avoidance versus migration risk. And when you amortize the real cost of potential downtime across however many billion dollars in assets that bank manages, the Windows license fee disappears. It's airline peanuts on the balance sheet. Let's actually put numbers on that. A Windows Server Datacenter license for a sixteen-core host is what, around six thousand dollars retail? That bank's loan portfolio is probably north of two billion. One hour of downtime during business hours, if it affects loan officers who can't process applications, could cost them more in lost business than a decade of Windows Server licensing. The math isn't even close.
But what's more interesting is that same bank could probably run those twelve VMs on a Linux hypervisor, Proxmox or whatever, tomorrow. The VMs are agnostic. But they might not even do that because their IT team knows Hyper-V, they've got failover clusters set up, and Hyper-V is still a significant player. Statista's report from last year has Hyper-V at eighteen percent of the hypervisor market. Eighteen percent in a world where ESXi was given away free for years and KVM ships with every Linux kernel.
Which is a level of market inertia that feels almost gravitational. But that VMWare comparison brings up an interesting recent twist. After the Broadcom acquisition, when per-core licensing shot up, there were a lot of organizations that were very happy they'd stuck with, or were already on, Hyper-V for their Windows workloads. They sidestepped a whole procurement nightmare by just keeping the Windows license they were already paying for.
Which is an angle I hadn't considered, the Broadcom-VMWare pricing chaos actually made Hyper-V look more attractive as a bundle. We pay for Windows Server Datacenter anyway, we get unlimited Hyper-V guests on that host, we're already licensed. The hypervisor is functionally free at point of use. And I've talked to shops that were in the middle of evaluating a VMWare-to-something-else migration when Broadcom dropped the new pricing, and the Hyper-V option went from "we should look at this" to "we're doing this" in about two weeks. It wasn't about Hyper-V being technically superior. It was about the licensing math suddenly making the bundled option the path of least resistance.
That covers the software lock-in. But what about the hardware side? Where does Windows Server still run on bare metal, and why?
Right, and this transitions perfectly into the specialized hardware workloads Daniel mentioned, starting with NVRs. The network video recorder space, surveillance cameras, is dominated by three companies basically. Milestone, Genetec, and Avigilon. Genetec Security Center six point zero, released this year, still lists Windows Server twenty twenty-two as the only supported server operating system.
The only one. When a vendor says "only," they're not saying "we recommend." They're saying "if you call support and the server isn't running Windows, we will not help you." That's a completely different category of lock-in.
And walk through what that means in practice. You've got a hospital or a university campus. They have four hundred cameras. The Genetec server is doing real-time video ingestion, motion detection, storage management. That's a heavy server workload, often with GPU acceleration for video analytics. And despite the vendor being a company that absolutely has the engineering resources to support Linux, they haven't. The entire application stack, including the database connector, the web server, the archive management, everything, is built on dot net and expects Windows Server.
The architectural assumption is baked in so deep that it's less a porting project than a burial and a resurrection in a new faith. And think about who's buying these systems. It's not the IT department running the RFP. It's the facilities or security team. They're buying a solution to a physical security problem. The server is a component, like a power supply in a rack. They don't care what OS it runs any more than they care what firmware their desk phone uses.
Why would Genetec do that? Because their customer base, security integrators and facilities managers, runs one server per deployment, buys the server hardware preconfigured from Dell or HPE, installs whatever OS the application demands, and never looks at it again until something beeps. The market has signaled they don't care about the OS. So Genetec spends its engineering budget on features that actually sell licenses, better analytics, better mobile clients, better integrations with access control systems. Porting to Linux doesn't move the revenue needle.
Lava tube ecosystems of the IT world. Whole complex systems operating in environmental isolation and nobody serious about exploring them. Which, there's our fact-like object for the day.
Nice try, but no. Hilbert gets his standard moment. You don't get to poach his lane.
But before we get to my curated non-cameo offering, the NVR story leads to the medical imaging angle. Because it's the same dynamic but with the stakes turned up to eleven.
PACS, picture archiving and communication systems, is exactly the same story. Radiology departments running millions of dollars of imaging equipment. The PACS server from GE or Philips or Siemens runs on Windows Server. Not mostly, completely. The DICOM routers, the study management, the workstation integration. Linux has way better throughput for huge file transfers, which radiology images absolutely are, and yet. The vendors certified on Windows Server twenty nineteen, now on twenty twenty-two, and you buy the server bundled with the million-dollar MRI machine and nobody in procurement questions the OS. The server is a line item on an eight-figure capital equipment purchase. It might as well be a printer cable.
But I want to dig into the regulatory angle because it's even more locked down than you might think.
And the deeper lock-in is regulatory. When the FDA clears a medical device, they're not clearing the hardware in isolation, they're clearing an entire system including the server and the OS configuration. The PACS is a cleared medical device system. Changing the operating system isn't a software upgrade. It's a re-certification that could take years and millions of dollars. And here's the kicker: the re-certification doesn't just cost money. It introduces clinical risk. If the new configuration has a bug that causes image corruption, even once in a million studies, that's a patient safety issue. No hospital administrator is going to sign off on that risk just to get off Windows Server.
That is in a class of "none of this will ever change" that people outside regulated industries really underestimate. I remember a guy telling me ten years ago that Linux was absolutely going to replace Windows in hospitals within five years, because it was obviously better for handling patient data. It cost him nothing to say. He didn't have to sit in a meeting with a hospital's general counsel explaining why they should voluntarily trigger an FDA re-certification process for a system that's currently working fine. That conversation lasts about ninety seconds and ends with "thank you for your input, we'll take it under advisement.
Let's talk about the bare metal versus virtualized question specifically, because part of Daniel's prompt is wondering if anyone even puts Windows Server on bare metal anymore. Short answer, yes and for defensible reasons.
Hyper-V clusters for one, but I already want to put that aside. The more interesting cases. High frequency trading. Financial firms running Windows Server on bare metal because the hypervisor adds consistent latency that their trading algorithms can't tolerate at very tight timeframes.
How much latency are we talking about?
At the extreme end, you're looking at the difference between single-digit microseconds and maybe ten to fifteen microseconds. Trades are already measured in nanoseconds across a network. If a bare-metal kernel call takes seven microseconds but adding a type-two hypervisor adds three more on every context switch, multiplied by thousands of operations to process an order, you're losing the race consistently over a trading day. Nobody runs containers for HFT. Nobody virtualizes HFT on the critical path. Yes, the really serious trading firms use FPGAs mostly, but for anything sitting on general-purpose processors, bare metal is non-negotiable. The interesting question is why Windows Server specifically in some of these shops, and the answer usually traces back to the trading application itself. A lot of these platforms were built in the early two thousands in C-sharp or C++ with heavy Windows API dependencies. Rewriting them in a Linux-native language isn't a weekend project, and while you're rewriting, your competitors are trading.
Bare metal Windows Server is niche elite here. It's not the majority of HFT, but it's a real thing that exists in production right now. And it's not going anywhere because the cost of rewriting the stack exceeds the latency savings of moving to Linux, assuming there even are latency savings once you factor in the maturity of the Windows network stack for that specific workload.
Very niche, and it's only going to exist where latency eats cost or where regulation forbids the complexity of a hypervisor layer. For the second one, here's an extremely concrete example. The US Department of Defense issued a mandate last year that classified networks must run Windows Server twenty twenty-five because Windows Server twenty twenty-five achieved Common Criteria certification at Evaluation Assurance Level four plus with specific protection profiles that most Linux distributions haven't met for those classified environments.
Common Criteria certification is a beautiful lever bar if most Linux distros currently haven't met what the DoD requires for a certain classification level. And this is the kind of thing that sounds absurd from the outside. "You're telling me the DoD is mandating a specific OS because of a certification checklist?That's exactly what's happening. And if you've ever worked with government procurement, you know that the checklist is the entire game. You don't get to argue that your system is more secure in practice. You have to show the cert.
Worth saying it's not that RHEL or Ubuntu can't meet EAL four plus, it's that certifying against a particular protection profile is a multi-year compliance project that distros just don't cheaply get to skip in government contexts where buyers require boxes to be checked for specific systems a certain way. Red Hat publishes their certifications and pushes hard on government, but the DoD had a specific complex set of profiles and features where the available Windows build got there faster. Once it's in the procurement pipeline, the momentum is enormous. The next solicitation references the certification from the last one, and suddenly Windows Server is the de facto standard for that entire category of deployment.
The scenario-locker element yet again tied to public procurement. And it creates this cascading effect. Once the DoD certifies on Windows Server for classified networks, the defense contractors standardize on it too, because they're building systems that have to deploy into those environments. Then the subcontractors standardize on it. Then the adjacent industries that serve defense, aerospace, critical infrastructure, they all drift toward the same stack because that's where the talent pool and the certified configurations already exist.
SCADA is the third example where bare metal stays on purpose, and it's arguably the most entrenched of all.
Factories, water treatment systems, energy pipeline control. The software from Honeywell and Siemens, especially older releases, relies on Windows because the operator displays require low-latency rendering and the hardware detection often depends on proprietary kernel drivers that were written for Windows NT and have been carried forward through compatibility shims for two decades. You're talking about systems where the control loop is measuring flow rates in hundredths of a second, and a timing hiccup means you might over-pressurize a pipeline. These are environments where "if it works, don't touch it" isn't laziness, it's safety policy. I've heard stories of chemical plants running Windows Server two thousand three on bare metal, air-gapped from the internet, because the control software was validated against that specific OS service pack and re-validation would require shutting down the plant for testing that costs millions per day.
That gets enormous the narrower the moment becomes. You're talking about systems where the last engineer who understood the integration between the PLC firmware and the Windows driver retired in twenty eleven. The vendor that wrote the control software was acquired twice and the current parent company doesn't even know they own the product. There are three people in the country who can touch that system without breaking it, and two of them are consulting at rates that would make a partner at McKinsey blush. At that point, you don't have a server. You have an archaeological site that happens to be controlling a municipal water supply.
The observability problem makes it worse. These systems weren't built with modern monitoring in mind. You can't just slap a DataDog agent on a Windows Server two thousand three box running a SCADA stack from nineteen ninety-eight. The entire detection chain, fire suppression, water treatment, municipal loads, it's all running on assumptions about timing and process behavior that were never documented. Upgrading means potentially introducing a twelve-hour downtime window while you figure out why the new OS handles serial port buffering differently than the old one. And if you're the person who proposed that upgrade and it goes wrong, you become a local political candidate in the worst possible way. Nobody gets approving.
Which brings us to an interesting question. Given everything we've just laid out, the identity lock-in, the regulatory certification pipeline, the bare-metal latency requirements, the SCADA systems that might outlive us all, what does this mean for someone who's actually planning a deployment today? If you're not trapped by legacy, if you're making a greenfield decision, where does Windows Server still make sense?
That's the right way to frame it, because so much of this conversation gets stuck in "what should we do about the thing we already have" versus "what should we build with today." And I think the answer is: Windows Server is the rational choice when you need something from the Microsoft ecosystem that doesn't have a viable alternative, and you need it on a timeline where building that alternative would cost more than the licensing. Active Directory is the obvious one. If you're building a new organization that needs group policy, integrated DNS, Kerberos authentication, and you need it working next month, you're deploying Windows Server. Not because it's the only way, but because it's the fastest path to a known-good configuration that every Windows admin already understands.
The counterpoint is: if you're building a new service that's containerized from day one, that's designed to run on Kubernetes, that doesn't need anything from the Windows ecosystem, then deploying Windows Server is almost certainly the wrong call. You'd be adding licensing costs and operational complexity for no benefit. The Linux container ecosystem is just more mature, better documented, and cheaper to run at scale. But notice how specific that answer is. It's not "Linux always" or "Windows never." It's "what does this specific workload actually need?
The other place where Windows Server still makes greenfield sense is in that mid-market space where the IT team is Microsoft-native and the applications are off-the-shelf dot net or SQL Server workloads. If you're a two-hundred-person company with three IT staff who all have MCSE certifications, and you need to stand up a line-of-business application, the rational choice is probably Windows Server. Not because it's technically superior, but because it's what your team can operate confidently at three AM. The cost of retraining the team or hiring Linux admins dwarfs the licensing cost.
The planning takeaway is: map your dependencies before you map your OS. If you need Active Directory, if you need a Windows-only vendor application, if you need a certification that only Windows has achieved for your regulated environment, then Windows Server is on the table and probably the right answer. If none of those apply, you're almost certainly better off with Linux. And the hybrid reality is that most organizations will have some of both for the foreseeable future.
I think the thing to watch over the next five years is whether Microsoft can make the case for Windows Server in the edge and IoT space. They've got Windows Server IoT edition, they've got Azure Arc for managing on-prem Windows servers from the cloud, they're building out the hybrid management story. The question is whether that's enough to keep Windows Server relevant as a deployment target for new workloads, or whether it gradually becomes a legacy-support platform that shrinks every year but never quite reaches zero.
The indefinite tail. It'll be around long enough that someone listening to this podcast in twenty forty will still have a Windows Server box humming in a closet somewhere, doing something critical that nobody remembers how to migrate.
On that note, I believe we owe the audience something.
Hilbert's daily fun fact has been threatened and must be delivered.
Hilbert: In some Cape Verde lava tube ecosystems during the early medieval period, colonies of blind isopod crustaceans developed a "grazing line" behavior: long after their surface food sources disappeared, entire packs spiral continuously in single file until the last individual starves, effectively continuing as if food were still abundant due purely to motion-generated local pressure waves combined with deeply stereotyped satiety cues. The behavior persisted for centuries because the environmental stability of the lava tubes provided no selection pressure against it. The isopods maintained a complex social feeding behavior in complete absence of its original function, a biological analog to the Windows Server sitting in the corner running Exchange management tools because Microsoft hasn't finished the migration path.
...right. That actually circled back disturbingly well.
It's almost like he plans these.
Don't encourage him.
This has been My Weird Prompts. Find show notes and subscribe links at myweirdprompts dot com. We'll be back with more questions you didn't know you needed answered. Until then, keep your servers patched and your dependencies mapped.
