SEZOY - Multi‑boot USB + PXE/HTTP + Windows install
▲ 28 r/SysAdminBlogs+1 crossposts

SEZOY - Multi‑boot USB + PXE/HTTP + Windows install

Hey folks,

This tool called SEZOY and figured it's worth sharing. It's basically a boot utility that does USB, PXE, and HTTP booting, but the main selling point is that it can install Windows completely hands‑off. No clicking through language settings, disk selection, partition deletion, or messing with RST drivers. It just figures everything out on its own based on whatever hardware it detects. You don't need to pre‑load storage drivers, wipe old partitions manually, or babysit the installer.

Here's what it does:

· USB boot works like the usual multi‑ISO approach, copy your ISOs to the drive and boot straight from them. No burning, no reformatting for each ISO, no manual menu editing. Simple. Just keep in mind that this mode needs SecureBoot turned off.

· Network boot supports both PXE and HTTP at the same time. No toggling between modes. If you run a shop with mixed clients, this saves a lot of headache.

· SecureBoot works fine if you're booting over the network, as long as the OS itself supports it. Most mainstream ones do Windows, Ubuntu, Mint, Fedora, and their derivatives.

· There's a web dashboard you can access from any device on the same network. Lets you check on clients remotely during installation, kind of like TeamViewer but lighter. You can step in without walking over to the machine.

· After Windows is done, you can set it to automatically install additional software. Pick whatever apps you want during setup, and it'll handle the rest.

Still has a bunch of other stuff I haven't listed yet.

If you've got a spare moment, grab it from the links below and let me know what you think.

One thing to be clear about, this tool doesn't bundle any cracks or keys. It just creates the boot environment. Anything that needs activation afterward is on you to handle legitimately.

Download: https://tekdt.xyz/en/download

Docs: https://tekdt.xyz/en/docs

u/TekDT — 4 days ago

Tìm kiếm hướng đi mới

Xin chào mọi người!

Mình viết bài này có 2 lý do:

- Một là, tìm kiếm lời khuyên và nhận xét từ những người đi trước, có kinh nghiệm trong lĩnh vực này để có hướng đi tiếp theo.

- Hai là, tìm kiếm đồng đội yêu thích dự án và đóng góp cùng.

Thông tin:

Dự án này là niềm đam mê của mình từ rất lâu về việc cài đặt Windows tự động hoàn toàn 100% (zero-touch), từ khi chọn ở Menu Boot. Hoàn toàn đáp ứng được Secure Boot, không cần sửa ISO, hỗ trợ cùng lúc nhiều phương pháp boot (PXE/HTTP BOOT, kể cả Wifi boot), tự động cài đặt phần mềm theo danh sách chọn trước, tự động áp dụng các post-script để tùy biến Windows, hỗ trợ boot nhiều distro Linux (không cài đặt tự động, chỉ boot). Về luồng hoạt động boot, thì nó tương tự như triết lý của iVentoy, tức là vẫn hỗ trợ Multi ISO boot, không sửa ISO, chỉ copy và chạy. Nhưng phần khác bên trong là nó không dùng bootloader tùy chỉnh (không hỗ trợ Secure Boot), mà sử dụng chính các thành phần của ISO để đạt được điều đó.

Dự án này được thiết kế chuyên sâu để thực hiện boot mạng, mặc dù vẫn có chức năng hỗ trợ tạo USB BOOT (Ventoy sẽ đảm nhiệm nhiệm vụ boot, còn phần tự động cài đặt vẫn là module riêng sử dụng cơ chế injection của Ventoy).

Dự án sẽ tập trung vào tính đơn giản, để từ người không rành về kỹ thuật vẫn làm được, và đến cả những chuyên gia về Quản trị hệ thống vẫn có những tuy chọn chuyên sâu hơn.

Dự kiến thêm tính năng:

Tính năng về triển khai quản lý hệ điều hành theo dạng tập trung như MDT hay FOG project đang làm. Thêm nhiều tùy chỉnh, phân loại cài đặt, cấu hình

Tính năng quản lý toàn bộ vòng đời của các máy khách (đã triển khai). Truy cập hỗ trợ lỗi từ xa mà không cần đến máy khách thông qua giao diện dashboard được tích hợp sẵn (hiện tại chỉ mới hỗ trợ trong quá trình cài đặt Windows trong WinPE)

Tính năng tạo báo cáo, lưu mọi log về máy chủ đã thiết lập cho máy khách

Phân quyền tài khoản để SysAdmin nào có thể thao tác với nhóm máy khách nào, tài khoản SysAdmin nào thì không

-> Toàn bộ những tính năng bên trên là dự án đã đạt được, và các bước tiếp theo cần triển khai theo nhu cầu của các SysAdmin, các kỹ thuật viên có nhu cầu như thế nào ở phần Dự Kiến. Vì kiến thức của mình có hạn, môi trường làm việc của mình cũng khác với mọi người, nên luôn mong nhận được đóng góp ý kiến của cộng đồng, để cải thiện dự án này hơn.

Dự án này nói không với kích hoạt hay cờ-rách, luôn tôn trọng bản quyền các bên.

reddit.com
u/TekDT — 14 days ago
▲ 0 r/SCCM

SEZOY – a RAM-only, stateless deployment tool in beta. What do you think about its potential?

I am building a Windows deployment tool called SEZOY, currently in beta, and I am looking for feedback from experienced administrators. I would like to share some of its design choices and hear your thoughts on where this project could go.

One core principle is that everything runs in RAM (still have somethings are extracted to temp dir, but will be deleted after exiting). SEZOY never writes any changes back to ISO or WIM files. Once you reboot the server or client, all temporary modifications are gone. This stateless approach means no image drift and no persistent changes to your original files.

Another key feature is that SEZOY runs multiple boot protocols simultaneously on a single server instance without needing to restart the software. You get PXE Boot for both Legacy and UEFI, HTTP Boot over wired Ethernet, and HTTP Boot over Wi‑Fi all at the same time. No service restarts, no manual switching. This is particularly useful in environments with mixed hardware or where technicians need flexibility.

Secure Boot is also supported. SEZOY can boot any ISO that is compatible with Secure Boot enabled. However, if you use custom or modified ISOs, there is no guarantee they will pass Secure Boot verification even though the tool supports the mechanism. For pure Microsoft signed images or properly signed ones, it works fine.

The deployment engine does not rely on the traditional setup.exe with an unattend.xml file. Instead, it uses a real time configuration system. What you set on the server gets pushed to the client during installation. The tool includes an extensible structure based on unattend_controls.json, allowing you to add any custom scripts or registry tweaks. You are not limited to predefined options.

For drivers, SEZOY uses DriverPack sources but applies a ranking algorithm to extract only the specific drivers a machine actually needs. It does not dump a huge driver pack onto the client.

Regarding security, the initial boot phase uses HTTP, but once the client loads into the WinPE environment, all communication switches to HTTPS with TLSv3 using self signed certificates, plus random seed validation per packet.

SEZOY also supports booting Linux distributions. Currently, Ubuntu, Debian, and ASMI Linux work well. Fedora support is still under development and not yet fully functional. There is also a built in hardware diagnostic environment based on Linux called tekdt hwdiag. Full zero touch automation is only for Windows.

The tool runs on any ordinary Windows 10 or 11 64 bit machine. A single administrator can handle more than twenty client machines simultaneously. It remembers settings across sessions and works offline once all required ISOs, drivers, and software packages are downloaded.

Right now, SEZOY is in beta and I am actively looking for users to test it and provide feedback. It is not meant to compete with enterprise platforms like SCCM. Instead, it is a lightweight alternative for smaller environments or specific tasks.

My question to this community is: where do you see a tool like this heading? Could it become useful for certain scenarios such as repair centers, rapid deployment tasks, or lab environments? What features would you want to see added? I would really appreciate your honest opinions.

u/TekDT — 1 month ago

SEZOY - Zero-touch, RAM-only Windows Deployment Server with 3-Step iPXE/HTTP Boot and Dynamic Driver Injection

Hi everyone, I wanted to share a project I’ve been developing called Sezoy. It is a lightweight, standalone Windows application designed specifically for IT technicians, system administrators, and field deployment guys who are tired of the traditional, tedious headaches of installing Windows across various hardware setups. Instead of wrestling with complex enterprise deployment servers or manually prepping dozens of individual USB drives, Sezoy turns any standard 64-bit Windows 10 or Windows 11 machine into a powerful, automated deployment server instantly.

The biggest game-changer with Sezoy is that it operates completely in RAM. Unlike traditional tools that force you to permanently modify or slipstream drivers into your Windows ISO or WIM files on the hard drive, Sezoy leaves your original image files completely untouched. Everything it does to patch the environment, inject drivers, and run scripts happens entirely on the fly in the system memory during the boot phase. The moment the machine reboots, absolutely no footprint is left behind, ensuring 100% clean installations every single time.

For field technicians, flexibility is everything, so I designed Sezoy with two powerful deployment modes. If you prefer physical media, Sezoy integrates directly with Ventoy to handle the USB boot side seamlessly. But where the app truly shines is its standalone network boot mode. I wrote a completely custom server backend from scratch utilizing the iPXE bootloader, meaning it has zero dependencies on third-party software or external server tools. Through a super simple 3-step setup wizard, you can launch a local deployment server that supports both PXE BOOT and HTTP BOOT simultaneously. You don't even need to worry about what boot architecture your client machines are using because the iPXE engine automatically detects the hardware type on the fly and serves the exact right bootloader. Multiple different machines can network boot using completely different methods at the exact same time, and you never have to deal with annoying configuration files or keep restarting the server to change settings.

To completely eliminate the need for manual interaction during setup, Sezoy includes an automated deployment flow that natively solves the infamous missing storage driver issue. If you’ve ever had a Windows installation grind to a halt because it couldn't see an NVMe drive, you know how annoying it is to manually load Intel RST or RAID drivers. Sezoy allows you to pack these drivers right into the configuration interface so they are dynamically injected directly into the Windows installation environment without any manual prompting. Combined with support for custom post-install scripts and unattended answer files, you can literally turn on an entire room of computers, boot them from the network, and walk away. The app automates the entire setup from start to finish, partitioning the drives, installing the operating system, applying hardware drivers, and booting straight to a fully configured, ready-to-use desktop.

If you want to see the full technical architecture, detailed deployment workflows, and step-by-step guides on how Sezoy manages this RAM-only automation, you can check out the official project documentation page at https://tekdt.xyz/en/docs. I’d love to hear your thoughts, feedback, or any feature requests you guys might have to make field deployments even easier.

u/TekDT — 2 months ago

No more "Next, Next, Next" or missing NVMe drivers. Here’s how I automated my entire field deployment workflow using RAM-only injection

I feel your pain. Anyone who has ever worked field IT support or deployment for a managed service provider knows the absolute nightmare of a "simple Windows rollout." You get told you need to image ten, twenty, or fifty machines at a client site, and you just know your week is ruined. You show up and every single machine has a completely different hardware configuration. One has an older Intel chip, the next has a brand new platform that requires you to hunt down specific Intel RST or RAID drivers just so the Windows installer can even see the NVMe drive. So you're sitting there with five different USB drives jangling in your pocket, burning your thumb driving from desk to desk, manually loading drivers, clicking "Next, Next, Next," and waiting for progress bars to fill up. Even if you get smart and build an unattended answer file, you still get tripped up by missing storage drivers at the very beginning of the Windows setup GUI, forcing you to manually intervene anyway. It’s a massive waste of time, you’re constantly babysitting machines, and it’s completely exhausting.

I got so sick of this exact grind that I decided to build a tool to fix it once and for all, which is how I created Sezoy. I needed something that would let me inject drivers, run custom scripts, and completely automate the installation without me having to touch a single thing after starting the process. The best part about how Sezoy works is that it doesn't touch or alter your original Windows ISO or WIM files on the hard drive at all. Everything it does to patch and inject drivers happens purely in the RAM during the boot phase, so the second you reboot the machine, it leaves absolutely no footprint behind.

To make it super versatile, I built it with two distinct modes. If you want to use a USB, Sezoy integrates directly with Ventoy to handle the USB boot side of things. But if you have to do mass deployments and carrying around multiple USB sticks is still annoying, I built full network deployment right into it too. For the network boot mode, I wrote a completely custom server backend flow utilizing the iPXE bootloader, so it is fully standalone and doesn't depend on any third-party software or external tools to run. Sezoy supports both PXE BOOT and HTTP BOOT, meaning you can deploy to an entire room of computers simultaneously without using a single USB drive. All the client machines just need to be on the same local network. You don't even have to worry about what boot method each specific client machine uses because the custom iPXE server backend automatically detects and serves the correct bootloader type on the fly. It supports multiple different boot methods from various client machines at the exact same time, and you don't have to deal with complex configurations or keep restarting the server just to change settings. Best of all, Sezoy can run on literally any standard Windows 10 or Windows 11 64-bit computer, making it incredibly lightweight and convenient for field technicians who just need to turn their own laptop into a deployment server instantly.

The core of Sezoy is all about giving IT tech guys their time back. Instead of managing a dozen different USB sticks or wrestling with complicated enterprise server setups, Sezoy lets you centralize everything through a super simple 3-step interface. It modifies the boot process on the fly so you can dynamically inject those annoying storage drivers, like Intel RST, directly into the installation phase without manual prompting. If you want to see exactly how it hooks into the Windows deployment flow to automate these steps and how the network booting works, you can check out the documentation and architecture layout I put together on the project page at https://tekdt.xyz/en/docs.

Basically, you configure your deployment settings through that quick 3-step wizard, throw your drivers and post-install scripts into the configuration, and Sezoy handles the rest over the network or via Ventoy USB. It bypasses the manual driver-loading headache and automates the Windows setup from start to finish. You can literally just turn on the client machines, network boot them, and walk away to grab a coffee or work on another ticket while all the machines completely configure themselves, install the necessary hardware drivers, and boot straight to a ready-to-use desktop. It completely changed how I handle field deployments, saving me hours of staring at setup screens, and I really hope it saves some of you guys from the same field support burnout I went through.

I'm also looking for more users to help test this software on a broader scale. I welcome anyone from around the world to participate. I truly appreciate any feedback or bug reports, as they will help me further improve the software.

u/TekDT — 2 months ago
▲ 26 r/linux

Linux booting over HTTP Boot Wireless

I have been working on a multi boot deployment engine for a while, mostly for Windows at first, and one of the hardest things I wanted to prove to myself was whether I could make wireless HTTP Boot actually work on a real machine, not just in theory.

Recently I got that working on a few Dell notebook models using Linux ISOs, specifically ASMI Linux 25.10 and Ubuntu 24.04 LTS. The interesting part is that the same boot flow I had already built for Windows still applies here too. The machine can be started from a single server that serves PXE UEFI, PXE Legacy, HTTP Boot wired, and HTTP Boot wireless without me having to switch modes back and forth.

The flow starts the same way. I launch the program, start the server, and the client can either see the server over the network through PXE or wired HTTP Boot, or connect to a special Wi Fi AP that the program creates. The server then gives the right bootloader depending on what the machine supports, so Legacy gets the original iPXE PXE binary and UEFI gets the iPXE shim. After that the client gets a multiboot menu and I can choose which ISO to start.

The wireless path was the part that took the most time and the most failed attempts. If the client is using HTTP Boot Wireless, the server has to pull Wi Fi firmware directly from the ISO itself and load it early in stage1 so the machine can reconnect to the special AP again. After that it can fetch the extra files it needs into RAM and continue. If the machine is using wired PXE or wired HTTP Boot, then none of that Wi Fi handling is needed and it just uses the active network interface.

For Linux I have not finished full automatic installation to disk yet like I have for Windows, so right now the main milestone is successful boot. But even that took a surprising amount of work because I had to stay in Ubuntu stage1 for more than two weeks just to figure out how to make it believe it was booting from a media device in a very limited environment.

That meant building custom scripts before initrd, adjusting the early boot flow, and making sure everything Ubuntu needed was already sitting in RAM by the time it started. Once that finally clicked, the machine booted cleanly.

Secure Boot is still not supported for Linux in this path yet, even though it works fine for Windows when using the original iPXE bootloaders. My guess is that the Linux distros I tested do not have the same certificate situation available in the firmware chain I am using.

At this point I am mostly just curious whether this approach is interesting to anyone else, or whether there is a cleaner way to handle the same problem. For me it was mainly a personal challenge, but getting Linux to boot this way felt like a pretty big milestone.

I also upload a video demo at here

reddit.com
u/TekDT — 2 months ago
▲ 5 r/Ubuntu

Booting Ubuntu over HTTP Boot Wireless

I spent the last couple of weeks stuck in Ubuntu stage1 trying to do something that sounded simple at first: get Ubuntu to boot over HTTP Boot Wireless on a supported Dell notebook, while still keeping my deployment flow flexible enough to handle PXE and wired HTTP Boot too.

The project started as a Windows deployment engine, but I wanted to see how far the same boot pipeline could be pushed with Linux. The answer turned out to be much harder than I thought. I can now start a single server that serves PXE UEFI, PXE Legacy, HTTP Boot wired, and HTTP Boot wireless at the same time, and the client can pick whichever path the firmware supports without me changing modes.

For the Linux test I used ASMI Linux 25.10 and Ubuntu 24.04 LTS. The boot flow starts when I launch the program and bring up the server. A client machine can then either boot through the network in the normal wired way or connect to a special Wi Fi AP that the program creates for the wireless path. The server returns the proper bootloader depending on the boot mode, so Legacy gets the original iPXE PXE binary and UEFI gets the iPXE shim.

After that the machine reaches a multiboot menu and I can choose an ISO. The difficult part comes if the client is using HTTP Boot Wireless. In that case the server has to extract Wi Fi firmware directly from the ISO itself and load it early in stage1 so the machine can reconnect to the AP again. Once that happens, it can pull the extra pieces it needs into RAM and keep going.

That early boot work was the real pain point. I had to build custom scripts that run before initrd and make Ubuntu accept the environment as if it were booting from a media device. That took more trial and error than anything else in the project so far. Once I finally got it right, the boot completed cleanly.

At the moment I have only proven boot success, not full automatic disk installation yet. With Windows I already have the fully automated path, but for Linux this is still the first milestone. My feeling is that it should be workable because everything Ubuntu needs is already in RAM by the time it gets past the hardest stage, but I have not finished the install path yet.

Secure Boot is still not supported for the Linux side of this path. Windows works with Secure Boot in my setup because I am using the original iPXE bootloaders, but for Linux I still need to figure out whether the distro certificates or the firmware chain I am using can be made to line up properly.

I am mostly sharing this because it felt like a real milestone after being stuck in early userspace for so long. If anyone has worked with this kind of stage1 bootstrapping in Ubuntu, I would be very interested to hear whether there is a cleaner approach.

I also upload a video demo at here

reddit.com
u/TekDT — 2 months ago

​

I’ve been working on Windows deployment for a while, and I keep running into the same issue: installing Windows is actually the easy part.

The difficult part is getting a machine to the point where it can even start installing.

In theory, we have all these options: Legacy PXE, UEFI PXE, HTTP Boot over wired networks, and on some newer Dell machines, even HTTP Boot over Wi-Fi. But in practice, every environment and every device seems to support a slightly different subset, and the usual workflow tends to break the moment one assumption is wrong.

For a long time, I tried to solve this by modifying images. Custom WinPE, rebuilt ISOs, injected drivers… the usual cycle. It worked, but it never felt stable. Every small change meant rebuilding something again.

So I switched approach and started treating this as a bootstrap problem instead of an imaging problem.

I’ve been building a small engine that keeps the original Windows ISO/WIM untouched, and instead adapts at runtime depending on what the machine actually supports. Whether it’s PXE, HTTP Boot over LAN, or (in some rare cases) wireless boot on supported hardware, the goal is to let the entry point vary without breaking the rest of the process.

The most interesting part for me was pushing the edge case: a fully wireless path on machines that actually support it. Not because it’s common, but because it’s the easiest way to expose how fragile the early boot stage really is.

I recorded a raw video demo of that scenario, no edits, no narration, just to show the full flow from boot to installation.

Curious how others here approach this, do you still treat deployment mainly as an imaging problem, or have you run into the same “first step is the real problem” situation?

u/TekDT — 2 months ago
▲ 18 r/Dell

Hey everyone, I’ve been using Dell laptops for years, and this whole thing actually started from something pretty simple: I just wanted an easier way to reinstall Windows without dealing with USBs, drivers, and all the usual friction.

At first, I was only building a USB boot solution based on Ventoy. I managed to get it to automatically pick the correct RST/RAID drivers inside WinPE so the disk would show up properly, and from there I built a zero-touch Windows deployment flow. You boot, walk away, and it just installs everything on its own. That alone already felt like a big quality-of-life improvement.

But then I started wondering if I could take it further. I got into PXE boot, made it work with both UEFI and Legacy, and integrated that into the same system. That was already useful, but what really changed things for me was when I realized that newer Dell laptops actually support HTTP Boot, not just over Ethernet but even over Wi-Fi in some cases.

That’s when things got interesting.

I ended up turning the whole thing into more of an engine than just a tool. It now has two modes: one is still USB boot, but the other is what I call Server Boot. When that mode is enabled, it doesn’t just do one thing, it listens across the network and simultaneously supports PXE (UEFI and Legacy) and HTTP Boot, both wired and wireless. There’s no need to preconfigure what kind of client you’re dealing with. The server just detects incoming requests and hands out the right bootloader automatically.

The Wi-Fi part was the trickiest, but also the most fun to figure out. I basically reuse the same idea from earlier: grab the correct Wi-Fi drivers ahead of time, prepare connectivity as early as possible, and then once control is handed over to the WinPE kernel, the connection gets restored so the machine can reconnect back to the server. From that point on, it behaves exactly like PX, drivers like RST/RAID are fetched dynamically and the Windows deployment continues fully automated.

What I like most is that everything inside WinPE is actually the same regardless of how you booted. The only difference is the preparation phase before it gets there.

Another thing I really wanted to keep is a clean source image. The engine doesn’t modify the ISO or WIM at all, not even a single bit. Everything runs in RAM on top of a completely untouched WinPE from the original image, and it still works fine with Secure Boot enabled.

The whole setup is also intentionally simple. It runs on any Windows 10/11 64-bit machine, no need for a complex server, and if you happen to have a Wi-Fi card you can even enable HTTP Boot over wireless. If not, it still works perfectly with PXE and wired HTTP Boot. The interface is just a few steps, no need to know in advance what kind of client is going to connect.

I’ve been testing this mostly on Dell laptops and honestly didn’t expect HTTP Boot over Wi-Fi to be this usable in practice. I’m curious if anyone here has played with that feature before, or if most people are still sticking with USB and traditional PXE setups.

Would love to hear your thoughts, or if this is something you’d actually try in your own setup.

u/TekDT — 2 months ago