Overall Goals
Here are the steps in which we overcome multiple roadblocks.
A. Creation of autounattend.xml
B. Merging of autounattend.xml with iso-contents.
C. Creation of secure-boot=on, uefi-bootable installation medium.
D. Installation of a secure-boot=on, UEFI(GPT) Windows with minimal install questions.
The Answerfile
- Create a Windows 10 answerfile with Windows System Image Manager by following these steps at Windows Central.
- This is a very eloborate article, you can skip what is not relevant for you.
- For example, I skipped the creation of partitions, now during setup I select the correct drive and it auto-populates the correct UEFI partitions (4).
- It still skips language questions, product code, version selection and the out of the box experience and the security questions for a local account!
(A site exists which generates an answerfile (autounattend.xml), but it or it's syntax might become out of date. I had more success using the Windows System Image Manager tool to generate an answerfile.)
Tip if you cannot add a user in your answer file:
If you find yourself creating a local account during the installation, don't add a password so you will not be prompted for Security Questions. You can add a password later when in Windows.
First Roadblock - install.esd -> install.wim
A normal Windows installation .iso contains a sources\install.esd file - you can convert it to install.wim or use Rufus to download a version with a install.wim version as explained at the site. DISM-Conversion takes a few minutes, if you are in a hurry, use rufus. (Maybe somebody in the comments can let us know how we know that we can trust Rufus's image download source.)
Making the catelog file also takes time.
From my understanding, we need the install.wim because addding an autounattend.xml to an iso with install.esd will not work. Correct me in comments if I am wrong. This bring us to the next problem: an install.wim is bigger than 4GB.
--> The output of this section is an answerfile autounattend.xml to your specification.
Second Roadblock: install.wim's size & bootability.
In the meanwhile you must have an original windows installation .iso. You can extract the content with Winrar or 7Zip and add the autouanttend.xml and replace the install.esd with install.wim.
Now if you have IMGBurn and Rufus you can create a new iso or USB-bootable drive.
Problem: all images I create with IMGBurn are not bootable in a secure-boot, uefi context. I don't know why. Hyper-V does not like them.
A bootable drive is usually formatted in fat32, but because our fancy install.wim is bigger than 4GB we cannot format it that way; Rufus works it's magic and creates a bootable UEFI:NTFS drive. Great - but, to their credit, Microsoft is being not-so-nice, Rufus used a component making the output UEFI-bootable, but not with [Microsoft's] secure boot. I don't want to go into that issue here, I am just saying:
Remember that normal .iso you downloaded from microsoft with 100 install questions? It boots without any bios/uefi changes, I do not want to exchange my saved time with bios/uefi-setting-changes.
In essense I am asking Why can't we have nice things? - So even though it's not Rufus's fault Microsoft excludes the bootloader, we cannot boot rufus's UEFI:NTFS output without disabling Secure Boot (even if it is for installation phase only, it doesn't make sense for [my] unattended installs)
Solution?
This person: How to burn a USB stick for UEFI Windows 10 build when > 4 GB files are present
Let's split the install.wim into install.swm and install2.swm.
- Split install.wim into pieces with dism with admin powershell:
Dism /Split-Image /ImageFile:install.wim /SWMFile:install.swm /FileSize:4000
Move the big install.wim outside your extracted iso folder.
Verify your answerfile autounattend.xml is in the root of this folder.
If we make an iso now, it seems to be able to boot in non-secure-boot possible non-uefi context, but that is not what I want. Because the installation is automated, I don't want it to boot in anything else than UEFI.
Want to know why?
An installation without secure-boot could mean no UEFI (so no GPT by wininstaller?!) which means no complete TPM usage, which means no optimal Bitlocker and no (complete) Windows Hello so:
Rename the file 'bootmgr' to 'bootmgr_oldboot.off'. (bootmgr.efi remains.)Link (Besides enforcing booting the installation medium in UEFI mode, this will also enforce or contribute a GPT-style Windows installation.)
With IMGBurn create a Folder-to-ISO image with boot settings (bootable checkmark, bootimage to boot\etfsboot.com and the '8' for sectors to load. It will ask to add the content of your selected folder, answer yes.)
a. [When making installation medium for a VM/Hyper-V] Create a VHDX of - for example 6 GB static size - in Disk manager.
b. [When making installation medium for Real machine] Link a USB-pendrive to your pc.
Use Rufus to select the mounted vhdx or usb-pendrive if it didn't detect it already.
Select the new install.wsd-containing .iso from step 4. Notice that Filesystem field should change to fast32. If you select your downloaded iso with install.wim, you see Rufus switch to NTFS.
Create the bootable medium with Rufus. --> This output seems to have the right flags. (Datestamped: 2021-02-07)
a. [~ medium for a VM/Hyper-V] Finish? Unmount your vhdx from disk manager before you continue!
b. [~ medium for Real machine] Safe-remove pen-drive, if you want.
Tip: in hyper-v, add at least 2 CPU-cores and enable the Secure Boot
and TPM in the security tab of VM's settings to avoid requirement
blocks during installation for Win11. Though not a blocker for Win10,
I would set the same security settings.
a. [~ medium for a VM/Hyper-V] In Hyper-V you can boot a VM from a dvd-drive with an .iso, but also a harddisk. Add an extra hard drive and point to the unmounted vhdx file. It works the same.*
b. [~ medium for Real machine] Boot target machine from USB, secure-boot enabled.
Related material