Question about WIM structure, and Setup tags

M

Moriarty

New Member
Short version:
Question about minimal valid WIM Structure for setup.exe to recognize as a valid entry. Windows 10 latest version.
Niche use case. Setup.exe has to run. Period.

I would like to write most of the standard install.wim contents to the disk in advance. Before setup.exe runs. Then when setup runs it adds the most minimum ammount of data I can get away with. Setup then creates the registry and bcd entries. All that jazz written just before first reboot. Asuming the majority of the wim is already on the disk, what constitutes a complete wim image from the perspective of setup.exe ?

Longer version:
I have an iscsi/ipxe system that boots 15 diskless windows 10 machines. It's a classroom. The hardware is not identical. The server is using zfs providing block storage to iscsi. Which in turn provides an iscis target per client. And yes it works nearly as good as ssd native. Problem is the drive images are unique at block level and can't deduplicate. If the client iscsi volumes already contained the partition table and 99% of the install.wim. I could switch to snapshots per client. Instead of full images each client would just be it's drivers and user generated differences. Reducing about 400GB or more or precious fast storage.

Ramble and gotchas:
None of this would be needed if there was better documentation on the witchcraft dism does to force a network driver to boot_service_start type
in the system and software registry hives.
Don't believe me? dism /add-netadapter {nicguid} /bootdriver ms_tcpip that's why setup.exe has to run. See attached file. I don't see a working way to replicate that with a simple dism apply-image function.
Pagefile moved to a direct io that is incompatible with iscsi. Ok.

So I need your help ntlite forum, microsoft forums just don't apprecaite an insane setup like this. I figure this is the right place.
 

Attachments

  • iscsi_boot_net.log
    40.9 KB
This is definitely not an NTLite question. But here's my thoughts:

You're really talking about deploying a common sysprepped image, with pre-installed drivers. DISM mount that image on a VHD, and clone it 15x. Write a RunOnce script to clean up things after first boot (hostname, etc).

98% of block churn is the pagefile. If you migrated the clients' pagefile to another set of VHD's, then most of your Windows volume snapshots would be greatly reduced in size. Disabling hibernation, and installing Windows in CompactOS mode (compressed) will reduce the footprint. Not great, but you have 15 copies.

Sorry we're not the best place to figure this out.
 
Last edited:
First, thanks for your feedback. Allow me to clear up a few things. The block image backend is not the issue, I was trying to explain why I was trying to do setup this way. Just think of the installation process as it writes install.wim to the disk. I wish to write 99% of the install.wim to the disk before winpe/setup boots. But setup still has to run that last 1%, doing that boot critical hack it does for iscsi target installations. Again not the issue I need the assist with.

Just want to know the bare minimum a wim can be to not break setup.exe , but the rest of it will already be on the 'hard drive' from the perspective of setup.exe.

Sure most of the ntlite users have hacked down a wim or two, and the crazy ones trying to run those 500mb installs could perhaps give a few pointers of what not to remove.
 
Last edited:
Your idea is still confusing to me. There's no option to skip Setup from extracting the WIM.

I have seen custom solutions PXE-boot WinPE, format disks, DISM /apply-image to extract the WIM, and script the rest of boot and host setup.
Bypassing Setup entirely since everything's up-to-date in a captured image. You can find those examples online on OSD/SCCM websites.

The closest way of "cheating" and having Setup run to perform non-install tasks would be pre-applying the image (using DISM), and boot WinPE with intention of running an "upgrade". Setup realizes most of the target image matches the installed image, and skips package adds. Some users use this method to repair corrupted installs. This requires hacking WinPE to ignore the normal Setup and use a config file.

Whether the upgrade-only Setup performs the boot config steps, IDK. I'm sure other users have figured out the PXE/iSCSI problem, from a quick search of this topic.

The last question is easy. NTLite has four removal templates, one of which is a "Lite" build that's generally safe. But for a classroom setting, your requirements may vary.
 
The closest way of "cheating" and having Setup run to perform non-install tasks would be pre-applying the image (using DISM), and boot WinPE with intention of running an "upgrade". Setup realizes most of the target image matches the installed image, and skips package adds. Some users use this method to repair corrupted installs. This requires hacking WinPE to ignore the normal Setup and use a config file.
Click to expand...
Again thanks for the feedback. I have never attempted a windows upgrade in place. This will be same version to same version. If setup is literally skipping the file copy operation for preexisting files in this scenario. It is what I'm looking for. The rest of this post is to explain why I am looking for this niche install method.

What I'm trying to do something a bit crazy and I apologize for the confusion that creates. I have a working setup of 15 machines that boot diskless ipxe and pull thier os volumes from an iscis server (saturates 10Gbs ethernet and has ram for days). I got this idea to make the clasroom machines diskless AND stateless. Now iscis is unsupported for Windows 10 Pro clients. But this is NTlite. You guys don't care what MS thinks and I love that about you.

If you take all this backend stuff out of the equation, Imagine you used dism to apply an image to a hard drive. Then put that into a workstation. How could you ALSO run setup against that machine without needing to rewrite the entire disk again? That is the part that will let me use a single backend storage volume for all the clients. Each client would then only need the difference snapshot from the main image.

Current setup:
I have 15 machines in a classroom booting to ipxe then loading thier OS images from an iscis backend. I can snapshot the images and revert to clean state at will. That part is fantastic. Bad part is the snapshot management. Setup literally must run (Read below) for iscsi installs to work. So you get 15x ~18GB block images. Would like to partition and image most of the OS in advance. But still have setup do it's iscsi witchcraft while not writing an 18GB unique block image on my backend per client.

Even more background:
When you put windows on iscsi, setup detects the iscsi environment and promotes the network driver to boot_state_critical by (I hate you MS) an undocumented dism command. Something like dism /net-addadapter /bootdriver ms_tcpip. Now I can't replicate that in volume management using dism to make an image in advance. Or I wouldn't need to ask this. So because the first boot/setup.exe writes the image back to the iscsi back end and sets the registry. On the back end server these iscis block images are now unique images per client. Waste of space to the tune of about 300GBs. Now these are classroom machines. So we don't care about persistence. Each client gets a snapshot. But because it's backend is unique, I have 15 uh... (root disk images? my terminology fails me here) And once they get past oobe and setup they get another snapshot.

Anyway the server has an ancient optane card that if I can get the clients to use the same root image, I can squeeze it into the optane storage and put the differencing snapshots in ram. Mostly curious what the performance will be after. Or if all that differential branching will redline the cpu. Fun.
 
Last edited:
When you add a driver package to an offline image, it's either staged or reflected in the image:
  • Boot-critical driver packages are reflected. In other words, they are added to the Driver Store and then the files are copied into the image according to what's specified in the .inf file as the destination of the files. The system completes installation tasks during the initial boot, including updating the registry.
  • Driver packages that aren't boot critical are staged. In other words, they're added to the Driver Store. After Windows starts, PnP detects the device and installs the matching driver package from the Driver Store.
Click to expand...
Which means it's not up to DISM to decide. And gets back to my sysprep suggestion.

If you have a working generalized sysprep image (with all possible drivers for your different PC's), then you should be able to clone the one working image as multiple volume copies. Each clone is served to an unique desktop client. ZFS copy-on-write "does the right thing" so you shouldn't be worrying about disk space.

This eliminates the problem of running Setup 15X. All you need is a run-once boot script to assign hostnames based on the their DHCP reservations or another method. Assuming the boot script takes care of housekeeping, you can always revert to the golden snapshot.

One final note: you're reinventing Windows Server's iSCSI Target Server on a Linux back-end.
By using differencing virtual hard disks (VHDs), you can use a single operating system image (the "master image") to boot up to 256 computers. As an example, let's assume that you deployed Windows Server with an operating system image of approximately 20 GB, and you used two mirrored disk drives to act as the boot volume. You would have needed approximately 10 TB of storage for only the operating system image to boot 256 computers. With iSCSI Target Server, you will use 40 GB for the operating system base image, and 2 GB for differencing virtual hard disks per server instance, totaling 552 GB for the operating system images. This provides a savings of over 90% on storage for the operating system images alone.
Click to expand...
 
You must log in or register to reply here.
Back
Top