New
#1
Cart/Horse problem. Injecting drivers as boot critical.
Windows 10 Version 1909. Latest Public ADK a/o this post date.
In addition to the standard method of using dism to inject drivers to sysprep'd image, how does one 'promote' that driver to early boot or what MS used to call boot critical?
This for an iscsi project where I am attempting to patch and boot a sysprep'd image on unfamiliar hardware as an iscsi target. When I first boot a machine it loads generic ipxe driver stack to push winpe into ram (pixe/wimboot can inject drivers). Simultaneously the target iscsi image is available for dism edits by the winpe. I can in push network drivers to the iscsi mounted image but I don't understand how to promote them to early boot process.
Please feel free to correct terminology and dump lots of tech references with hyperlinks to MS training material. I am not asking for someone to do the work, I'm asking where to learn how to fix this.
--Below is just back story, it gets a bit rambly--
Before you say it's not possible, it is already possible in a round about ineffiecent way.
Presently I can boot a machine diskless to ipxe, load winpe, mount smb share, load windows 1909(if the winpe driver network driver patch worked). The problem here is the server is loading data from the server back to the server. So 16GB uniqe vhds per client machine. I get diskless clients but at an unoptimized storage cost.
If I can get this to work with sysprep'd vhd's as the base for my snapshots, I can save a ton of data. Each diskless client's vhd will only be the computer specific drivers etc existing as a differencing snapshot of the original.
Gotchas:
using ipxe with the wimboot module alllows me to dynamically alter the winpe on the fly. Scripts, drivers, it's awesome.
My dhcp server runs a script that per new client for this network it makes a new vhd, maps new vhd to iscsi iqn based on mac of client machine. The drive images are thin-provisioned so if they don't get used they take little space. However this system will run out of IQNs at 256 clients. Not that this server wouldn't implode from that kind of load, more like a reminder to clean out the fridge of old IQN targets and 1mb disk images never used. But this is assuming network isolation from production etc.