DEV Community: TekDT

SEZOY: When Windows Installs and Linux Boot-Over-Network Become a One-Touch Experience - The "Never Touch the ISO" Philosophy

TekDT — Fri, 04 Sep 2026 05:01:48 +0000

SEZOY is closed-source (prebuilt installer, no code walkthrough) - this post focuses on operating experience and hands-on testing, not source internals.

TABLE OF CONTENTS

Why netboot still matters in 2026
Architecture from an operator's view
Preset / Profile Group / Catalog: the automation trio
Two DHCP modes and the coexistence problem
Windows: automatic yet controllable
Linux: multi-distro netboot + hardware diagnostics
Monitoring, backup, API: the dev part
Hands-on 1: test over the Internet without installing SEZOY
Hands-on 2: run your own server in 5 minutes
Requirements, ports, FAQ

Why netboot still matters in 2026

For devs and homelabbers the problem is never "install one machine" but "install many machines, many times, many configs, with minimal downtime." USB sticks + scattered scripts don't scale. Heavy stacks like WDS / MDT / SCCM work but cost setup and care.

SEZOY sits in the middle: one Windows PC as the deployment server, everything else network-boots. Web dashboard at https://localhost:5893, multi-language English / Vietnamese / Chinese / Japanese, tray icon. Clients are bare metal or VMs (VMware / Proxmox / Hyper-V / VirtualBox) doing Legacy / UEFI PXE, iPXE or wired / wireless HTTP Boot.

One rule throughout: ISOs stay pristine. New build = swapping one file. Everything else arrives at boot over HTTP.

Architecture from an operator's view

No source deep-dive, just the flow so you can picture it:

SEZOY SERVER (Windows)
├─ Web dashboard :5893 - templates, groups, catalog, logs, backup, API
├─ Boot HTTP :6824 - high-speed channel at deploy time
├─ Full DHCP / ProxyDHCP + smart filtering - coexist or self-serve
├─ TFTP tuned for LAN + VPN - small seed files only
├─ WiFi AP for wireless boot - Windows hotspot based
├─ Linux boot - distro detect, add-on packs, per-ISO menus
└─ Offline storage + API + backup + audit
│ L2: LAN / VLAN / VPN / WiFi AP
▼
PXE ROM => iPXE (signed if SecureBoot ON) => Menu => pick ISO/Profile
├─ Windows: install env => partition => load image => inject drivers
│ => apply unattend => OOBE => apps => desktop
└─ Linux: load kernel + system over net => merge add-on layer => live boot

Notable for infra folks: the server knows which stage each client is at and hands the right boot file per stage. Small seeds first, then straight to HTTP - no hangs on picky virtual NICs like vmxnet3, stable over long-distance VPN. A loop guard shows a help screen instead of retrying forever.

Preset / Profile Group / Catalog: the automation trio

Preset: one complete recipe + unique tag (LAB-ROOM-A): computer name (* random or LAB-A-* rules), key (empty = existing digital license), timezone, language / keyboard, domain join, welcome screens, accounts, auto-logon, first commands, privacy, 4-stage scripts (CMD / PowerShell / VBScript in the browser), apps to install, junk to remove, drivers / updates to load. Preview + pre-flight checks, full duplicate / load / delete / search.
Profile Group: rules mapping machines to templates by vendor, model, chip, boot style, RAM / disk, MAC prefix, parts, SecureBoot, NIC type… with priority and match-all / match-any. A simulator previews placement before real boot.
Catalog: the shared driver / patch / app / junkware store every template references. Fix once, benefit everywhere. Integrity-checked, logged. Windows app tab (search / download-for-offline) and Microsoft patch tab (filter by code, security / critical). Fully offline once downloaded.

One ISO serves many groups: accounting one template, lab another - ideal for mixed fleets.

Two DHCP modes and the coexistence problem

ProxyDHCP (default, recommended): shares the net with your router / pfSense / OPNsense. SEZOY only adds boot info, never fights for IPs.
Full DHCP: SEZOY owns client IPs, only for private nets (test VPN, back-to-back cable, VM lab over VPN, isolated VLAN). Editable in UI: server IP, netmask, gateway, DNS (default 8.8.8.8), pool (test server uses .200–.250).
Safety: exact-NIC binding, separate WiFi address, no leaked 169.254.x.x - lessons from long-distance VPN tests.
WiFi AP for Wireless HTTP Boot: prefers Windows Mobile Hotspot, detects capable cards, finds the gateway (usually 192.168.137.1). Editable SSID / password (default SEZOY_Boot / 00000000, 8-char minimum). SEZOY never owns WiFi IPs itself; Hotspot does, SEZOY only adds boot info. No capable card? Warning only; wired boot works.
Windows: automatic yet controllable

Two modes from one ISO: pre-selected edition => fully automatic; empty => stock Setup for manual pick; Linux ISO => always the automatic path. Multi-mode with automatic-first fallback supported.

Dynamic drivers: catalog-resident, injected at deploy time. Adding a driver = one catalog entry, ISO untouched. Update / feature packs pre-first-boot. Skipped (saving seconds per machine) when unneeded.
Realtime edition read: clicking an ISO lists Edition + Index + Arch + Language + Build instantly, no mount, no extraction. Optional keep-one-edition for lighter, faster, lower-RAM boot.
SecureBoot: signed Windows boot files (with revoked-build blocklist); per-family Linux signing. Unsigned ISOs get a clear reason screen instead of a hang.
OOBE / Privacy / Users / Scripts / Apps: slim 24H2+ welcome (no forced online account / WiFi / BitLocker), two-layer privacy + one-tap tweaks, multiple local accounts + post-install auto-demote, 4-stage scripts, silent per-app-reported installs, protected junk removal.
Watch and control: Full-HD screens in the browser, per-machine shots, continue / custom / shutdown / reboot, progress %, per-machine logs, 5-minute session expiry.

Linux: multi-distro netboot + hardware diagnostics

Ubuntu / Mint, Debian, Kali, Arch, CentOS / Rocky / Alma / Fedora, antiX, Deepin… auto-detected, boot entries auto-built, missing firmware fetched, compressed in-ISO systems handled.

Boot-time composition merges the stock system with add-on packs (drivers, firmware, WiFi, diagnostics, remote-control) into one working system - WiFi works, installable - original ISO untouched. 100% Ventoy / iVentoy-pack compatible. Built once per distro, faster later. HTTP + network-disk delivery.

Built-in live hardware-check ISO: graphical info, deep CPU / RAM / disk / memory tests, temps, risk score, report export, guided assistant - the "receive old box, check, then install Windows" flow.

Monitoring, backup, API: the dev part

Overview: machine totals, running jobs, health, CPU / RAM / disk bars.
Machines: MAC / hostname search, status / template / stage filters, details + history, last-seen.
Live: auto-refreshing online grid, large / fullscreen shots, shutdown / reboot / remote / commands, blinking control state.
Logs & reports: node / event / date filters, paging, export; CSV / HTML / PDF with size / date / download / delete.
Backup: encrypted on-box, one-click, restore with overwrite warning, daily / weekly / monthly schedule + time + retention + last / next display.
Accounts: password login (default-password warning), min-4-char change, remembered session.
API + docs: login / password, template and group CRUD, bulk CSV import, online + screenshots, remote deploy, logs / stats, reports, server status, machine-code management (shown-once, masked, enable / revoke, call examples in-page). Two layers: web session + per-machine boot code (expiry, granular build / fetch / report permissions, revoke / renew). Everything important logged. Enough for lab portals, per-class templates, bot / dashboard integrations.
First-run tool pack: genuine Microsoft fetcher + Server 2016 / 2022 / 2025 (multi-thread, resume), ISO open / split, offline Windows app store, driver packs with % / speed / ETA, self-update, one-tap installer build with pre-checks.
Hands-on 1: test over the Internet without installing SEZOY

Test server: machine B 192.168.2551.1, public VPN Hub. You are machine C, joining the same L2 over VPN and bridging your VM straight into the VPN NIC. Shared dashboard: https://192.168.251.1:5893.

Install SoftEther VPN Client (tick Client) => create SEZOY-VPN adapter => new connection: Host sezoyhost.vpnazure.net, port 443, Hub SEZOY.HUB, user / pass tester99, check the "No Adjustments of Routing Table" in "Advanced Settings..." => Connected. Errors 1 / 2 / 691 => recheck hub / user / port-443 firewall.
Install VMware Workstation Pro => Virtual Network Editor (Admin) => free VMnet (e.g. VMnet2, Bridged) => Bridged to = exactly the SoftEther NIC (never Automatic) => VM uses Custom VMnet2. VM: UEFI, ≥4GB RAM, ≥40GB disk, Network Boot first.
Power on => PXE => DHCP from 192.168.251.1 => menu in 5–15s => pick shared ISO + tester profile => deploy => record time, SecureBoot ON / OFF, Legacy / UEFI, errors + MAC + screenshots. Clean shutdown + Disconnect VPN when done.

Common: wrong bridge (straight to BIOS), TFTP timeout from MTU / firewall, slow HTTP from WAN jitter (don't reboot in loops), home IP from still-Automatic VMnet.

Shared-testing notes: modest box + WiFi + Internet, only ~50 IPs, one VM per person, light boot before full Windows, never stop the host Boot Server, report with config + screenshots + VN time, check maintenance notices first.

Hands-on 2: run your own server in 5 minutes

Open https://localhost:5893 => serving NIC (LAN / VPN, not WAN NAT), check the "SEZOY Service" firewall rule => add ISOs (copy in or fetch directly), click for live editions, pick an edition => automatic, leave empty => stock => build presets + groups (simulator first), pool / gateway / DNS / SSID => Start Boot Server (ProxyDHCP with DHCP present, Full on isolated nets, WiFi AP if wanted) => PXE-boot clients => pick ISO => auto-assigned template => auto install => screenshots / progress / reports. Enable auto backup.

Requirements, ports, FAQ

Server: Windows 10/11 x64 or Server 2022/2025, Admin, ≥8GB RAM (16GB+ for many machines), disk for ISOs (Windows 5–7GB each, Linux 2–4GB each), hotspot-capable WiFi card only for wireless boot. Client: physical / VM with PXE or HTTP Boot, ≥4GB RAM for the install env. Network: same L2, Internet once, fully offline after. Ports: 5893 dashboard HTTPS, 6824 boot HTTP, 67/68 addressing, 69 seeds, 10809 network disk if used.

FAQ: modify ISOs? No. SecureBoot off? No. Ventoy-compatible? Yes. Forgot a tag? Search or activity log. Own app? Bundled API docs + access code. Lost config? Restore from backup. Wireless needs? AP-capable server card + HTTP-Boot-capable client.

Tested via VPN? Leave VM config, distro / edition, SecureBoot, boot time and a menu screenshot so SEZOY can improve. Thanks dev.to!

Windows deployment isn’t hard — getting to it is

TekDT — Sat, 02 May 2026 14:40:07 +0000

I used to think Windows deployment was mostly an imaging problem.

You prepare a WIM, tweak WinPE, slipstream a few drivers, point everything at PXE, and the rest is just execution. That works well enough in controlled environments, and for a while I treated that as the normal way to do it.

But the longer I worked with different machines and less predictable networks, the more I realized something uncomfortable:

the hard part usually is not installing Windows.

It is getting the machine into a state where installation can even begin.

That is where the whole process starts to feel fragile. PXE depends on the network behaving. Wired infrastructure is not always available. Firmware does not always expose the same options. And WinPE, for all its usefulness, still assumes a very specific set of conditions once it boots.

At some point, I stopped seeing this as an image problem and started seeing it as a bootstrap problem.

The part that kept breaking

In the environments I kept running into, the same issues showed up again and again.

Sometimes the network was there, but I had no control over DHCP or the switches. Sometimes the machine had no convenient wired connection at all. Sometimes the firmware behaved differently depending on the model, or the boot method I thought would work just did not show up in the menu the way I expected.

And Wi-Fi made the whole thing even more awkward.

https://youtu.be/SwR87kjNSQs

We use wireless for almost everything now, but in Windows deployment workflows it still feels strangely off-limits. A stock WinPE environment does not give you usable Wi-Fi support out of the box. Even when a system firmware can boot over Wi-Fi, that only gets you so far. Once WinPE loads, the connection can disappear, and you are left trying to recover from a very small box with very few tools available.

That was the point where the workflow started to feel like it was built around the image, instead of around the actual deployment path.

Changing the question

So I started asking a different question.

Instead of: “How do I build the perfect image?”

I began asking: “How do I make the full path to installation resilient?”

That shift changed the way I approached the entire process.

Rather than relying on a fixed image and hoping the environment cooperates, I started treating deployment as a pipeline. The machine should be able to boot using whatever method it supports. The boot environment should be able to recover enough networking to continue. The install process should be able to adapt to the hardware it finds instead of assuming everything has already been baked in ahead of time.

That led me to a more dynamic design.

On the host side, I turned a single machine into a temporary deployment hub. Depending on what the client can use, it can serve PXE for both Legacy and UEFI systems, serve HTTP Boot over wired networking, and in some cases bring up a temporary Wi-Fi access point as well.

From the client side, the goal is simple: use whatever boot method is available and get into WinPE without needing to reconfigure the environment every time.

That part is already useful on its own, because it means the server is not tied to one exact boot path. Different machines can come in through different methods, and the same deployment flow can still continue.

But the real challenge was always WinPE.

What I tried inside WinPE

Once WinPE loads, most of the interesting assumptions collapse.

The environment is minimal by design, and that is usually a strength. But it also means that anything outside the expected path needs to be rebuilt carefully if you want it to work reliably.

So instead of building heavily customized WinPE images, I experimented with keeping the source clean and handling more of the logic at runtime. The idea was to use a standard Windows ISO as the base and reconstruct only what was needed when the target machine actually booted.

That includes the usual pieces people expect in deployment work, like storage drivers for RAID or RST systems. But the part that took the most experimentation was wireless recovery inside WinPE.

That was the hardest part of the whole project.

The approach I ended up exploring was to prepare the required components from the original Windows ISO, combine them with the correct Wi-Fi drivers for the target machine, and then restore just enough networking inside WinPE to reconnect back to the deployment host.

That means the boot process is not just “start WinPE and install Windows.” It becomes a chain:

boot the machine, enter WinPE, recover connectivity, reach back to the server, load the needed storage support, and continue the installation automatically.

When that works, the whole flow feels very different. It is less like maintaining an image and more like building a system that can assemble itself in real time.

Why I recorded a demo

I recorded a raw demo because this kind of project is easy to describe badly.

The interesting part is not the final install screen. It is everything that happens before it.

In the demo, I start the server in a few simple steps: select a network interface, choose a standard Windows 11 ISO, and start the service. From there, the system brings up the networking it needs on its own, including a temporary Wi-Fi access point alongside the wired boot services.

On the client side, I test one of the most difficult paths I could think of: booting over HTTP through that wireless connection. The machine connects, starts pulling the boot files, and enters a stock WinPE environment. As expected, the connection does not just magically stay alive there.

Then the recovery logic kicks in.

The WinPE environment reconnects, reaches back to the server, pulls what it needs, and continues the deployment. If storage support is required, it loads that too, and the installation proceeds without further interaction.

I did not record that demo because wireless boot is the normal case. I recorded it because it is a good stress test. If the pipeline can survive that, the more conventional paths are much easier to trust.

What this changed for me

The biggest change was not technical.

It was conceptual.

I stopped thinking of deployment as “image creation plus installation” and started thinking of it as a full bootstrap pipeline. That is a much more honest model of the real problem.

Images still matter. WinPE still matters. Drivers still matter. But none of those pieces matter if the machine cannot get far enough to use them.

That is why the first step matters so much, and why it is often the part people talk about the least.

In practice, I think that is where a lot of deployment pain comes from. We spend a lot of energy polishing the image, when the real instability lives one layer earlier.

What I am still figuring out

This is still an experiment, and the wireless path is definitely the most fragile part. Hardware differences matter. Firmware differences matter. Some systems are much more cooperative than others.

But that is also what makes the project interesting.

It gave me a way to think about deployment that is less dependent on a perfect lab environment and more focused on making the pipeline adapt to whatever it gets.

That does not solve every problem, but it changes the problem from “how do I maintain all these variations?” to “how do I make the boot path resilient enough to keep going?”

And that, for me, is the part worth exploring.

The takeaway

If there is one thing I have learned from this, it is that Windows deployment is rarely blocked by the installer itself.

It is blocked by everything that has to work before the installer can do anything useful.

That is the part I ended up building around.

And it is also the part I am most curious to hear other people’s experiences about: how do you handle the very first step when the network, the firmware, and the hardware all want to behave differently?