The thing about network printers is they expose a particular kind of vendor logic — which is that the driver team is a Windows team that occasionally ports to Linux, not the other way around.
Daniel's been staring at this exact problem. Here's what he wrote to us — and I'm going to read it pretty much in full because he packed a lot into this one.
"We mentioned before Windows Server, and it's one of those products that has a certain majority. The server world is dominated by Linux, but there are certain things that work on a Windows server only. Sometimes, if you're trying to set up a network printer, the drivers for Windows are more frequently updated, or the manufacturer makes firmware update utilities that can only be used via Windows. If you're in a Linux-first household, then this is one reason why having a Windows VM on an Ubuntu host on the network, especially if you can set up a virtual desktop, might be worth doing."
He goes on — "However, if you're not planning on actually using the graphical environment, it often seems like setting up a Windows 10 ISO is the wrong move. I've heard about some sort of miniaturized versions of Windows that really strip it down to the kernel or something that will be recognizable as a Windows OS to overlying hardware, without even having the bloat of a full Windows server on top. What are the actual options available to users looking to run a very minimal Windows environment on the network for this specific purpose?"
So he's asking: what's the smallest Windows that a printer driver or firmware flasher will still recognize as Windows, and does a kernel-only option actually exist.
And the short answer to that last part is no — but the longer answer is more interesting, because Microsoft does offer things that get surprisingly close, and the community has filled in some gaps. We dug into what's actually available, what each option strips out, and where they all break down.
Let's start with what Daniel's really asking for. He wants a Windows that's essentially a driver-hosting stub — no Start menu, no Candy Crush, no telemetry dashboard, just enough of the OS that a printer utility sees "ah, Windows" and runs. The question is whether that exists as a product or whether you have to hack your way there.
Right, and the reason this is even a question is that the driver model forces it. A Windows driver isn't a standalone file you can just point CUPS at — it expects the Windows kernel, the hardware abstraction layer, the plug-and-play manager, the whole stack. You can't extract the driver and run it on Linux. So you need an actual Windows instance. The only question is how much Windows.
And Daniel's instinct that a full Windows 10 ISO feels like overkill — he's right. A default Windows 10 install will eat somewhere between two and four gigs of RAM just sitting there, and twenty to thirty gigs of disk. For something that's going to wake up once a month to flash a printer firmware, that's absurd.
So the real categories we're looking at are three. Microsoft's own stripped-down builds — that's Windows Server Core and Windows IoT Enterprise. Community-shrunk ISOs — the most prominent being Tiny11. And then the baseline option of just running a full Windows ten or eleven VM and living with the bloat, which is sometimes actually the right answer.
Let's start with the one that sounds closest to what Daniel described — Server Core.
Windows Server Core is Microsoft's official minimal installation option for Windows Server. It's been around since Server two thousand eight, and the idea is exactly what Daniel's reaching for — strip out the graphical shell, strip out File Explorer, strip out Internet Explorer and the Start menu and most of the desktop experience, and leave you with a headless Windows that you manage through PowerShell, through remote server administration tools, or through Windows Admin Center.
So what's actually left under the hood?
The full NT kernel, the complete driver stack, the hardware abstraction layer, Hyper-V if you want it, and storage services. What's gone is the entire Desktop Experience — no GUI shell, no browser, no Windows Explorer. When you boot Server Core, you get a command prompt. That's it.
Which sounds perfect for Daniel's use case until you hit the catch.
The catch is that most printer firmware utilities and consumer hardware updaters are GUI applications. They launch a wizard, they show a progress bar, they want you to click "Next" three times. Server Core can technically run some GUI applications — if they don't depend on the Explorer shell or certain GUI frameworks — but in practice, a Brother firmware update exe that opens a windowed wizard is going to fail.
So Server Core recognizes the hardware, loads the driver, but then the utility itself can't present its interface.
The driver layer works fine. The application layer breaks. If the firmware update or driver install can be triggered entirely from the command line or via PowerShell, Server Core is ideal — it boots with about eight hundred megabytes of RAM usage and takes around four gigs of disk. That's genuinely lean. But if the utility demands a GUI, you're stuck.
And most consumer printer utilities demand a GUI.
Almost all of them. I don't know of a single consumer printer vendor that ships a PowerShell module for firmware updates. Enterprise printers, sure — some of the big managed print services have command-line tools. But the Brother HL-L2370DW sitting in someone's home office? That firmware updater is a point-and-click exe.
So Server Core saves resources but loses on compatibility. What's the next rung up?
Windows IoT Enterprise. And I want to sit with this one for a minute because it's the option that most people in Daniel's situation have never heard of, and it's probably the actual right answer.
IoT Enterprise sounds like something you'd run on a factory sensor, not a print server.
That's the branding problem. Microsoft positions it for fixed-purpose devices — ATMs, kiosks, medical devices, digital signage. But "fixed-purpose device" is exactly what a dedicated print-server VM is. It does one thing, it runs headless most of the time, and it needs full Windows driver compatibility.
What's actually in it?
It's a full Windows desktop — with the GUI, with the shell, with everything — but licensed and configured for small-footprint embedded scenarios. Microsoft's documentation says it can run on as little as two gigabytes of RAM and sixteen gigs of storage. It uses the same driver model as Windows ten and eleven Enterprise, so any driver that works on a full Windows desktop works here. No compatibility questions.
And the resource usage in practice?
With the GUI running, it sits around one and a half gigs of RAM and about ten gigs of disk. That's roughly double Server Core's footprint, but still half of what a bloated full Windows ten install would use. And critically — you get the GUI. That Brother firmware wizard runs. The Synology firmware flasher runs. The UPS management tool runs.
So the tradeoff is: you pay a licensing cost and you use a bit more RAM, but everything just works.
Right. IoT Enterprise isn't free — it's licensed per device, typically somewhere in the thirty to fifty dollar range depending on the channel. For a hobbyist, that's a real cost. For someone who just wants their network printer to stop being a weekly headache, it might be worth it.
And the licensing model is different from regular Windows?
It's embedded OEM licensing, which means you're supposed to get it through a distributor or as part of a device build. It's not something you walk into a store and buy off the shelf. That's a friction point. But for a home lab, there are legitimate ways to get evaluation copies and there are resellers who will sell single-unit licenses. It's not as straightforward as downloading a Windows ten ISO, but it's not impossible either.
So we've got Server Core — lean, officially supported, but no GUI. IoT Enterprise — GUI, officially supported, smaller than full Windows, but costs money and has licensing friction. What about the community option?
That's Tiny11. And this is where we need to address the "miniaturized kernel" idea directly, because Tiny11 is not that — and nothing actually is that.
Say more.
Tiny11 is a project by a developer who goes by NTDEV — the repository is tiny11builder on GitHub. It's a PowerShell script that takes a standard Windows eleven ISO and strips components out. It removes Edge, OneDrive, Windows Defender, a bunch of preinstalled apps, and some system components. What you get at the end is still Windows eleven with the full NT kernel — it's just a heavily debloated Windows eleven.
So it's not a custom build of Windows. It's Windows minus the stuff you don't want.
And that's an important distinction because it means the driver model is fully intact. Any hardware that works on Windows eleven works on Tiny11. The script isn't touching the kernel or the HAL — it's removing userland components.
What's the resource footprint?
It can run in about two gigs of RAM and eight gigs of disk. That puts it right in the same ballpark as IoT Enterprise, maybe a bit leaner on disk. It boots faster than a stock Windows eleven install because it's not loading all the background services and telemetry and widget panels.
And the downsides?
Several. First, it's unsupported — Microsoft isn't going to help you if something breaks. Second, Windows Update can be unpredictable — some updates will reinstall components that Tiny11 removed, some will fail because they expect components that aren't there. Third, if you strip too aggressively, you can break things you didn't expect to break. There are reports of firmware utilities crashing because Tiny11 had removed a Visual C plus plus redistributable that the utility depended on.
So you save disk space and you trade it for stability risk.
For a tinkerer who enjoys troubleshooting and wants to minimize resource usage, Tiny11 is a interesting option. The builder script is open source, you can customize what gets removed, and the community around it is active. But if this VM is going to sit in the corner and you need it to just work when you need to update a printer firmware six months from now, Tiny11 might not be the right call.
Let's talk about the thing Daniel specifically asked about that doesn't exist — the "miniaturized kernel" version.
There is no Windows kernel-only build that third-party drivers will recognize. The closest thing Microsoft ships is Windows PE — the Preinstallation Environment. It's a lightweight Win32 environment used for deployment and recovery. It boots fast, it's small, it can load drivers. But it's not designed for persistent use — it resets on reboot. It's a ramdisk-based environment meant for installing Windows or running recovery tools, not for hosting a print server indefinitely.
So you could technically boot WinPE, load a driver, flash firmware, and shut down — but you'd have to do that whole dance every time.
And you'd have to rebuild the environment each boot because it doesn't persist state. It's not practical. The fundamental issue is that the Windows driver model expects the full kernel and HAL to be present. You can strip the GUI, you can strip the apps, you can strip the services — but you cannot strip the kernel and still have Windows drivers load. The "bloat" Daniel's talking about isn't in the kernel. It's in everything Microsoft layers on top.
Which is actually a useful reframing of the whole problem. The question isn't "how do I get a smaller Windows kernel" — it's "how do I get a Windows that has the smallest possible userland while still running the utilities I need."
And once you frame it that way, the decision tree becomes much clearer. Step one: can your target utility run from the command line or via PowerShell? If yes, Server Core is your answer — it's the leanest, most stable, officially supported option. If no, you need a GUI, and then you're choosing between IoT Enterprise for stability and support, Tiny11 for resource efficiency and zero cost, or a full Windows VM for maximum compatibility and minimum hassle.
Let's put some concrete numbers on that decision. You mentioned Server Core at about eight hundred megs of RAM and four gigs of disk. IoT Enterprise at one point five gigs of RAM and ten gigs of disk. What's a full Windows ten VM actually look like in practice?
A clean Windows ten install with nothing stripped will idle around two gigs of RAM, but once you add driver packages and let it run for a while, it tends to settle between two and a half and four gigs. Disk usage is usually twenty to thirty gigs after updates. Windows eleven is similar, maybe a bit heavier on both counts.
So the jump from IoT Enterprise to full Windows ten is roughly another gig of RAM and another ten to twenty gigs of disk. That's not nothing, but on a modern Ubuntu host with thirty-two gigs of RAM and a terabyte of storage, it's also not catastrophic.
That's the second-order point that I think a lot of people miss. If you need the GUI anyway — because your firmware utility demands it — the resource difference between IoT Enterprise and a full Windows ten VM is modest enough that the full VM might actually be the simpler path. You download the ISO from Microsoft, you install it, it works, Windows Update runs without surprises, and you never think about it again.
The "it just works" tax is about a gig of RAM and fifteen gigs of disk.
For a lot of people, that's a reasonable tax. Especially if this VM is running on a host that's already doing other things and has resources to spare.
But Daniel's framing suggests he's trying to be deliberate about this — he doesn't want to throw a full Windows install at a problem that should need a fraction of that.
I respect that. So let's walk through what I think the actual setup looks like for a Linux-first household that wants to do this cleanly.
Go on.
You've got an Ubuntu host on the network. You install your hypervisor of choice — KVM, VirtualBox, whatever you're comfortable with. You create a Windows VM using either Server Core or IoT Enterprise, depending on whether your utilities need a GUI. You configure the VM to start automatically when the host boots. You pass through the USB port if the printer needs direct USB access for firmware updates, or you connect over the network if it's a network printer. Then you expose the printer to the rest of your Linux machines via Samba or IPP.
The Windows VM becomes a dedicated print server appliance, and the rest of the network never touches Windows.
The Windows dependency is contained in one VM that does one thing. Everything else stays Linux-native. If the VM breaks, your network still works — you just can't print or update firmware until you fix it.
If you went the Server Core route, how would you actually install a printer driver without a GUI?
PowerShell. You'd use the Add-PrinterDriver cmdlet to install the driver, then Add-Printer to create the printer, then set up sharing. It's scriptable, it's repeatable, and you can save the script so that if you ever need to rebuild the VM, you just run the script and you're done.
But that only works if the driver package itself can be installed silently from the command line.
Right. Some driver installers are just exe wrappers that extract an inf file — those you can usually handle. Some are full GUI wizards that don't offer a silent install switch. Those are the ones that force you into IoT Enterprise or a full Windows VM.
What about the firmware update scenario specifically? Daniel mentioned manufacturer firmware utilities that only run on Windows.
That's the harder case because firmware updaters are almost never scriptable. They're one-off utilities that the hardware vendor builds for Windows and never ports. A Synology NAS firmware flasher, a UPS battery management firmware tool, a monitor firmware updater — these are all GUI exes that expect a full Windows desktop.
For the firmware update use case, Server Core is basically off the table.
In most cases, yes. Which means you're choosing between IoT Enterprise and a full Windows VM. And at that point, the resource savings of IoT Enterprise — about a gig of RAM and ten to fifteen gigs of disk — might not be worth the licensing friction.
Unless you're running multiple VMs or your host is resource-constrained.
Sure. If you're on an older machine with sixteen gigs of RAM and you're already running several services, shaving a gig off the Windows VM matters. Or if you're running this on a low-power device like an Intel NUC with limited storage, ten gigs versus twenty-five gigs is meaningful.
The decision tree branches based on your hardware, not just your software needs.
Which is why I can't give a single answer that works for everyone. But I can give a framework. Test your utilities first — find out if they need a GUI. If they don't, Server Core. If they do, check your host's available resources. If resources are tight, IoT Enterprise or Tiny11. If resources are plentiful, a full Windows ten or eleven VM is the path of least resistance.
Let's talk about Tiny11 in that framework. Where does it actually fit?
Tiny11 is for the person who looks at IoT Enterprise and says "I don't want to deal with embedded licensing, and I don't want to pay thirty to fifty dollars, and I'm willing to accept that this thing might break after a Windows Update." It's the hobbyist option. The tinkerer option. If your home lab is a playground where you enjoy fixing things, Tiny11 is fun to work with.
If your home lab is infrastructure you depend on?
Then pay the thirty dollars for IoT Enterprise or just use a full Windows VM. The time you'll spend debugging a broken Tiny11 install after an update will cost you more than thirty dollars worth of your evening.
There's a case study I want to put on the table because I think it crystallizes the tradeoff. You're setting up a print server on Ubuntu. You create a Windows VM specifically to host the printer drivers. With Server Core, you write a PowerShell script to handle driver installation and sharing — it works, it's lean, but it took you an afternoon to get the script right. With IoT Enterprise, you point and click through the driver installer, you're done in ten minutes, but the VM uses an extra seven hundred megs of RAM.
With Tiny11, you spend an evening running the builder script, customizing what gets stripped, then you install the driver and it crashes because the utility needed a runtime that got removed. You spend another hour tracking down the missing dependency. It works eventually, and it uses less disk than IoT Enterprise, but you've now invested multiple evenings.
The resource efficiency of Tiny11 comes at the cost of time. The question is which one you have more of to spare.
That's exactly the right way to think about it. And it's why I keep coming back to IoT Enterprise as the unsung hero here. It's officially supported, it's designed for exactly this use case — a fixed-purpose device running a single workload — and it saves enough resources over a full Windows install to be worth the effort for people who care about that. The licensing friction is real, but once it's set up, it just works.
What about Windows ten versus Windows eleven for any of these options?
For this use case, it barely matters. The driver model is the same. The resource usage difference is small. If you're building a new VM today, I'd probably go with Windows eleven just because it'll be supported longer, but if you have a Windows ten license sitting around, it'll work fine. The IoT Enterprise LTSC releases — Long-Term Servicing Channel — are actually ideal for this because they get security updates for ten years and don't get feature updates that might break your setup.
LTSC is the one that doesn't get the twice-yearly feature updates.
Right. It's the "set it and forget it" version of Windows. For a print server VM that you want to configure once and never think about again, LTSC is perfect. It gets security patches, it doesn't get new features, and it doesn't suddenly decide to upgrade itself to the next version of Windows.
That's the IoT Enterprise LTSC specifically?
Yes. Windows ten IoT Enterprise LTSC twenty twenty-one is the current long-term servicing release, and Windows eleven IoT Enterprise LTSC twenty twenty-four is the newer one. Both are supported for ten years from release. For Daniel's use case, either would work.
We've covered the Microsoft options and the community option. Let's pull this together into something actionable.
The framework I'd give someone in Daniel's position is three questions. One: does your utility need a GUI? Two: how resource-constrained is your host? Three: how much do you value stability versus cost savings?
The answers map to specific recommendations.
If no GUI needed: Server Core. It's free with a Windows Server license, it's officially supported, it uses the least resources, and it's the most stable option. If GUI needed and resources are tight: IoT Enterprise, with the LTSC version if you can get it. If GUI needed and you don't want to pay: Tiny11, with the understanding that you're trading stability for cost savings. If GUI needed and you just want it to work: full Windows ten or eleven VM, accept the resource usage, move on with your life.
The full VM option feels like admitting defeat, but sometimes it's actually the most rational choice.
It's not defeat if it solves the problem and you never have to think about it again. The goal isn't to minimize Windows — the goal is to make your printer work without Windows taking over your life. If a full Windows VM in the corner achieves that, it's a win.
There's one more angle I want to touch on before we wrap — the long-term trend. Daniel's question exists because of a specific market failure: hardware vendors treat Linux drivers as an afterthought. Is that changing?
Slowly. More enterprise hardware is shipping with Linux support as a first-class option. Web-based firmware updates are becoming more common — you visit a web interface, upload the firmware file, done, no OS-specific utility needed. But consumer printers and small-office hardware are still overwhelmingly Windows-first. The Brother laser printer in someone's home office is going to have a Windows firmware updater for the foreseeable future.
The Windows VM isn't going away anytime soon.
Not for this specific use case. The need might shrink over time as vendors adopt web-based tools and improve Linux support, but for now, if you've got a Linux-first household and a printer or a NAS or a UPS that only speaks Windows, you need a Windows VM. The question is just how small you can make it.
The answer is: smaller than a full desktop install, but not as small as a kernel-only build, because that doesn't exist.
That's the episode.
If you take one thing from this, it's that the Windows you need isn't defined by the kernel — it's defined by whether your utilities need a GUI. Figure that out first, and the rest of the decision writes itself.
The second thing — which is really the same thing from the other direction — is that IoT Enterprise exists. Most people in Daniel's position have never heard of it, and it's probably the closest official answer to what he's actually asking for.
The question that sticks with me is what happens when Microsoft eventually sunsets Windows ten IoT Enterprise. The LTSC releases have long support windows, but they do end. If Linux driver support hasn't caught up by then for these niche hardware utilities, the community options like Tiny11 become a lot more important.
Or the hardware vendors finally get pushed into providing OS-agnostic firmware update tools. Web-based updaters, bootable USB images, something that doesn't depend on a specific version of Windows. The pressure is building, but it's building slowly.
If you're listening to this and you've got a weird Windows dependency in your Linux lab that we didn't cover — some exotic hardware or a bizarre driver situation — send it to us. The email is show at my weird prompts dot com. We might build a whole episode around your specific setup.
Thanks to our producer Hilbert Flumingtop for keeping this show running.
This has been My Weird Prompts. We'll be back soon.
