Answer file - wait for input if no disk 0?

Maybe this isn't the right subforum for this question, point me in the right direction if not.

Is there a way to make an autounattend file actually stop (without crashing) when there's no disk 0 to install on? Checking the 'On Error' flag still makes it throw an error and kill the entire installation process. I have to have two different unattend files for installion 10 and 11 (4 total) based on this. Yes, I know injecting drivers is a thing, but where I work I'm not really at that point yet, plus we have so much sprawl on laptops that it's usually not something I find out until I'm actively installing.

Can I replace the step in the answer file with a script that formats and partitions the drives, waits for user input if no disk exists to install on, then goes back to automating all of OOBE afterwards? Is that even possible? And again, yes, I know about MDT - I'm near the process of going down that road soon enough. But in the short term, this would be a nice thing to have fixed.


My .xml file for pre-OOBE.

Welcome to the forum. I can't answer your question but @hsehestedt might can. In the meantime review his "tricks" here to see if any address your question.

glasskuter said:

Welcome to the forum. I can't answer your question but @hsehestedt might can. In the meantime review his "tricks" here to see if any address your question.

For a Limited Audience: A Collection of Generic Answer Files, Each with a Different Purpose

This post is in response to another user who specifically requested sample unattended answer files. I thought that since I was going through this effort, I would simply share these publicly for anyone who might be interested. NOTE: YES - I know that the purpose for some of these answer files...

www.elevenforum.com

Click to expand...

Yes and no. It highlights that you can absolutely use a scripted methodology to setup the partitions for the boot drive, which I was fairly confident of already. But I'm still unsure if that implies you can set the entire thing wrapped in an if conditional for "if disk 0 cannot be found, end script and wait for user input (implicitly assumed based on no answer file steps for partitioning)". If that can be the case - that's exactly what I need.

I suppose maybe I can see what happens if I run his answer file on a VM with no VHD and see if it crashes, or it just does nothing when it hits the partitioning step.

I still hope @hsehestedt jumps in to advise you.

Setup has no allowance to restart Unattended installation after a disk provisioning error.

The root cause for your headache is the default Windows ISO is missing HW support for your PC's specific SATA or NVME controllers. Therefore no disks are reported found in WinPE. Without driver support, no scripting can find a missing disk.

Follow these steps to build an ISO which works on multiple PC models:

1. Collect all the different SATA or NVME boot drivers (sometimes referred to as "F6" drivers).
2. Extract the driver files to local folders, following the vendor's README or docs.
3. Mount boot.wim, using DISM /Add-Driver to add each driver's INF file, or an entire driver folder in turn.
4. Repeat /Add-Driver for all the different boot drivers your image has to support.
5. Commit the image, with DISM /Unmount /Commit
6. Repeat the previous 5 steps with the install.wim
7. Return to using your previous Unattended disk layout.

garlin said:

Setup has no allowance to restart Unattended installation after a disk provisioning error.

The root cause for your headache is the default Windows ISO is missing HW support for your PC's specific SATA or NVME controllers. Therefore no disks are reported found in WinPE. Without driver support, no scripting can find a missing disk.

Follow these steps to build an ISO which works on multiple PC models:

1. Collect all the different SATA or NVME boot drivers (sometimes referred to as "F6" drivers).
2. Extract the driver files to local folders, following the vendor's README or docs.
3. Mount boot.wim, using DISM /Add-Driver to add each driver's INF file, or an entire driver folder in turn.
4. Repeat /Add-Driver for all the different boot drivers your image has to support.
5. Commit the image, with DISM /Unmount /Commit
6. Repeat the previous 5 steps with the install.wim
7. Return to using your previous Unattended disk layout.

Add and Remove Driver packages to an Offline Windows Image

Add and Remove Driver packages to an Offline Windows Image

learn.microsoft.com

Click to expand...

I'm after of the lack of drivers, yeah. Is there any downside so to speak of adding superfluous drivers to an installation? Or since the driver isn't applicable to anything on the system, it just won't ever be used, and is simply benign and, at worst, bloat?

Disk controller drivers tend to be compact, so bloating from those drivers doesn't add much space. It tends to be a major issue for graphics and audio drivers, which bundle bulky libraries with them. After post-insrallation, you can run "pnpuntil -d" to purge any unused drivers.

There's always a tradeoff. To keep a minimalist install image, you would have to maintain several parallel ISO's -- one for each family of PC models. Or bite the bullet and keep a larger generic image, but only have to update it once in a while. The decision usually comes down to how many similar PC models you can group together into one shareable image.

garlin said:

After post-insrallation, you can run "pnpuntil -d" to purge any unused drivers.

Click to expand...

Huh, now this I didn't know. Very interesting. Guess I can add this to my post-install script and just throw the boot drivers into the image, then. Right now I have maybe 3-4 from what I've encountered and it's just 22MB.

E: Running it in a sandbox to test, there are no drivers in a sandbox I guess. Does -d just automatically remove any unused drivers? /enum-drivers doesn't have a flag for if its used or not, so I can't iterate over them based on that.

The cheesy but common hack is to either:
1. Brute-force cycle through a range of [0...N] filenames, using "pnputil -d oem[N].inf"
2. pnputil -e (to enumerate), and try deleting every reported oem.INF.

Because pnputil won't allow you to delete a loaded (and in-use) driver, it's the lazy person's way to clean up unused drivers. You can't test this behavior in a sandbox, just bring up a low-end VM instance.

garlin said:

The cheesy but common hack is to either:
1. Brute-force cycle through a range of [0...N] filenames, using "pnputil -d oem[N].inf"
2. pnputil -e (to enumerate), and try deleting every reported oem.INF.

Because pnputil won't allow you to delete a loaded (and in-use) driver, it's the lazy person's way to clean up unused drivers. You can't test this behavior in a sandbox, just bring up a low-end VM instance.

Click to expand...

I take it if this method is used, that there is no middle ground of 'used but not currently in use so Windows would allow me to delete it', where you'd risk deleting something important? A driver is either installed and directly attached to some sort of hardware process and cannot be removed regardless of it being actively used at that very moment (IE, like how a printer driver won't let you remove it until you remove the printer first), or is installed and attached to nothing whatsoever?

HW drivers are loaded at boot time, based on detected HW ID's. Once loaded, driver files are locked by active processes. Anything that's inactive (unloaded) doesn't share the protections and pnputil can remove them. It's not pretty, but everyone's done this for years.

garlin said:

HW drivers are loaded at boot time, based on detected HW ID's. Once loaded, driver files are locked by active processes. Anything that's inactive (unloaded) doesn't share the protections and pnputil can remove them. It's not pretty, but everyone's done this for years.

Click to expand...

While it's probably overthinking from just inexperience, I like to ask questions as is. Are there any weird fringe cases I should be aware of doing this that I might remove something I don't want to remove? Obviously not like I'm going to hot-swap the CPU and brick a laptop, but any other 'hardware' that could technically be ephemeral between boots? I'd only be running this script post-provision immediately after install, so I assume no.

E: I suppose I could just keep a record of which boot drivers I'd be plugging into the .wim and then make a pnputil -e script that foreachs them and attempts to remove them, which would make me feel a lot safer than just going whole hog on the returned array.

Jalopy said:

Is there a way to make an autounattend file actually stop (without crashing) when there's no disk 0 to install on?

Click to expand...

Sorry for being so slow to respond. I've been offline a few days.

Let me ask if this would be an acceptable solution for you:

It is possible to create an answer file that performs a fully unattended installation of Windows EXCEPT that it pauses at the screen in the installation where you would normally select the disk to which Windows should be installed. By doing this, you can visually see if Windows is detecting your drive(s) or not. You can also manually load any drivers if needed at this time. Once you then load any drivers needed and select the location to which Windows should be installed, the installation will proceed fully unattended.

Another advantage to this configuration is that the very same answer file can be used for Legacy BIOS systems using MBR and for UEFI based systems using GPT. Another advantage is that using this method creates the Recovery Tools partition AFTER the Windows partition as Microsoft recommends. Normally, an installation using unattended setup is forced to create the Recovery Tools partition BEFORE the Windows partition. For this reason alone, I actually prefer this method over a 100% unattended installation.

If this is of interest to you, please let me know and I'll provide details.

If I'm misunderstanding the situation at all, please let me know!