Good idea, sounds a lot like what I've been doing for a few years now. A golden (disk) image is pretty much impossible now, and always out of date. I keep the install.wim(s) updated, but beyond that, as clean as possible. I use PE for applying (learned a lot from JFX's "WinNTSetup", and now try to do most of that in my own messy Autohotkey code, great for simple GUIs, by the way). PE tries to recognize hardware (using BIOS "SystemInformation\BIOSversion"), applies the wim, add drivers, fix some minimal registry stuff (disable Defender, again: all JFX's findings), add unattend file, KMS or other, etc., then reboot. I never use standard Windows Setup.exe, only used it a handful of times in the beginning. So all this just to get a clean image, and to replace the process of making disk images with Acronis, Terabyte, etc. All the postinstall stuff is done with a separate tool (.ahk again), this time the unique PC is identified with its MAC address. Install basic productivity tools (still use Excel '97 all day every day, 16mb of files total, but that's a different story), tons of other audio/ video/ pdf/ system tools (the most basic and useful stuff I can find, usually pretty old, but still do the stuff I need perfectly). Then all the ini/ reg settings etc. OK, I'll stop there for now. The main thing is just to keep the apply "dynamic", and to keep all the PostInstall separate. Suffice to say: I like your idea, curious to see what your further ideas are.
That makes a lot of sense, your approach is actually very similar to how I used to handle things, especially keeping the WIM clean and pushing logic into WinPE. One thing that ended up changing my direction quite a bit was trying to make the whole process work over the network from the very beginning, not just the deployment itself, but also the bootstrapping part (PXE / HTTP Boot). Getting WinPE to run reliably once it's loaded is one thing, but getting to that point over the network across different hardware turned out to be a whole different challenge. Because of that, I started thinking of it less as just “deployment” and more as a full pipeline — from boot → WinPE → install → first boot. It’s still very much a work in progress, but that shift in scope is what led me down this path.
Not sure what to make of this. For one thing, I dislike youtube other than movies. Technical info is always troubling. The mouse moves around the screen way to fast, and the explanation is sparse. I'm old school, and prefer the written work that I can concentrate on. One thing of note. Your embedded youtube has no sound, even though my sound is not muted. That then makes this all the more reason I can't work with it. I don't know enough of what you trying to do to even reply sensibly. On the surface, it sounds very interesting.
That’s a very fair point, and I think the video doesn’t really do a good job explaining what’s actually happening. Let me try to describe the flow more clearly in text. The idea is to treat the whole process as a pipeline, starting from the network boot itself: 1. A small server is created on the host machine, which can serve PXE and HTTP Boot. In addition to that, it can also bring up a temporary Wi-Fi access point for cases where wired network isn’t available. 2. A client machine can then boot over HTTP (in some cases over Wi-Fi), which loads a WinPE environment. 3. Since standard WinPE doesn’t include WLAN support, one of the more experimental parts is restoring basic Wi-Fi functionality inside WinPE. This is done by preparing the required components from the original Windows ISO and combining them with the correct drivers for the target machine. 4. Once network connectivity is re-established inside WinPE, the system reconnects back to the server, loads any required storage drivers (RST/RAID), and proceeds with the installation automatically. So instead of focusing only on the image itself, I’m trying to make the whole chain, from bootstrapping to installation, more dynamic and less dependent on pre-built images. It’s definitely still a work in progress, and some parts (especially Wi-Fi in WinPE) are a bit fragile, but that’s the general direction I’m exploring. The demo video I embedded showcases the most challenging part I’ve managed to pull off: seamless HTTP Boot over wireless (on certain Dell notebooks). On top of that, you only need to run the program once as a server, and it can handle multiple boot methods at the same time, automatically delivering the correct bootloader for each client. For example, you can have different machines booting simultaneously using PXE Legacy, PXE UEFI, HTTP Boot over wired, and HTTP Boot over wireless, without needing to switch modes back and forth.
Yes, although it’s still about deploying Windows to client machines, my approach is simpler and designed to work on virtually any hardware configuration, with a strong focus on convenience and portability. You’re welcome to try it, and if you run into any difficulties, don’t hesitate to reach out to me. I’d be happy to help you step by step.
Well, consider using WinRE instead of WinPE. WinRE comes with native WiFi support! BTW, i don't reinstall things often, and i don't use backup & restore programs either. When necessary, i mostly use WinNTSetup from WinPE, apply some tweaks, connect to my softpack drive, and ready to go in no time! I only reinstall VMware since i'm intensively playing with WinPE stuff!
I use an approach (conceptually) similar to iVentoy: there is no need to modify anything inside the ISO or WIM files. The user simply copies or specifies the ISO file directly. The system then extracts only the specific components required during the boot process, not the entire ISO for purposes such as restoring WLANSVC functionality. So while relying on WinRE is a good direction, it becomes difficult to apply on a completely empty disk where the ISO file is the only available resource. On the other hand, building and maintaining a fixed custom WinPE/WinRE environment would require continuous packaging, updates, and long-term maintenance effort. I chose the current approach because although it is more difficult architecturally during development, it is much lighter to maintain in the long run and compatible with a much wider range of ISO types. May I ask what kind of work you do that requires deploying Windows so extensively in VMware environments?
1. .1 base build from uupdump 2. updates from overview post by ninja @Enthousiast 3. intel vmd drivers because fak selecting them manually every time 4. w10ui for updates and drivers integration 5. setupcomplete.cmd for directx and visual c++ repacks from @abbodi1406 and a couple of simple tweaks 6. unattend.xml for some slight automation, nothing too crazy
It sounds fascinating how you’ve assembled so many complex components together and prepared everything needed to smoothly support a wide variety of hardware configurations. So, what has been the most difficult part for you in building or preparing this entire process?
For me it's just the need to do it monthly because of cumulative updates. I perform multiple clean windows installs per day sometimes and I really can't afford waiting for some Celeron to install updates.
It seems like you work in an environment with a huge variety of computers, ranging from very old systems to the latest hardware.
Yup. Pre-2017 AMD hardware has almost vanished, can't remember the last non-Ryzen system i've had. Intel on the other hand is balls deep - mostly Skylake+, sometimes can go down to Nehalem, every now and then there's a Core 2 Duo machine which the person wasn't made aware how insufficient it is for their needs. So the images I make are, in my experience, 100% universal. Unless I run into some hard wall like cpu instruction sets.
From the way you describe your work with so many different types of hardware, and the way you talk about customers, I’m guessing we might actually be in the same industry. Do you work in a repair environment as well?
That’s really interesting. I’m also working in a repair environment like you, and I noticed that technicians spend a huge amount of time performing the same repetitive tasks over and over again. There’s a lot of downtime spent waiting, followed by a sequence of manual steps throughout the Windows deployment process. That became the main motivation for me to develop this project: to automate and standardize the workflow, while also eliminating much of the complicated preparation work involved.
WinRE is available in ALL Windows ISO's (all versions 7/8/8.1/10/11). (.\sources\install.wim\any-index\Windows\System32\Recovery\WinRE.wim) I meant i'm always trying to perfect my WinPE skills. Mostly developing mini PE shells, PE launchers, features implementation, etc...
This is truly valuable knowledge for me. If a service like WlanSvc were available in such a minimal environment, it would significantly reduce my maintenance workload. I am also experimenting with switching to winRE.wim instead of the current boot.wim. Thank you for giving me such a great idea. It’s truly great to have the opportunity to interact with experts like you who have deep, hands-on experience in the project I’m working on. Although AI is very helpful nowadays, practical experience like this is something AI can never truly replace.