Linux – Is it possible to specify an answer file when PXE booting windows using memdisk

linuxpxe-bootsyslinuxsysprepwindows

I'm able to PXE boot windows from my Linux server using memdisk to mount a winpe.iso that: mounts two samba share drives, one for the windows install disk, and another that has answer files (each answer file is in its own directory). Then it launches the setup.exe and specify the answer file to use as a parameter.

I feel this setup could be made scores better by taking the answer file specification out of the winpe.iso, because it's a bit buried and it means if I want to use a different answer files for different nodes I need to create a winpe.iso for each, and while the answer files can be changed easily enough it isn't readily apparent which answer file corresponds where. Ideally I'd like to have something like how Linux machines PXE boot with syslinux, by specifying a kickstart file in the append section in the pxelinux.cfg/default so it is obvious which is being used and it is simple to maintain.

I can live with a single winpe.iso with instructions to mount the share and install windows baked into it, but I'd like more freedom in the answer file used.

According to Microsoft AIK when installing windows it will search the root directory of each drive for Autounattended.xml to use as the answer file, if I could mount an iso that only contained the answer file alongside the winpe.iso that would be suitable enough, but I'm wondering if that's even possible (haven't found a definitive answer through searching).

The relevant section of my pxelinux.cfg/default:

LABEL Windows
  MENU LABEL Windows
   LINUX memdisk
   INITRD winpe.iso
   APPEND iso raw

Best Answer

  1. Using memdisk of course you cannot pass parameters to your winpe.iso
  2. if you decide to boot your Win PE "WDS style" (pxeboot.n12/bootmgr.exe/BCD etc) you also cannot pass unattended parameters to your winpe.wim

therefore you have only one choice: a custom application taking control right after winpe.wim is booted providing the freedom of retrieving (menu) and handling the needed Autounattended.xml before running Setup.exe