Changing Disk Enumeration Order for Windows Setup  

This issue could be considered a Windows installation issue or a hardware issue (involving MB BIOS).

I've done a LOT of work to setup all sorts of Windows unattended installations. I also have a number of scrips used during the actual installation of Windows. All of this work uses the assumption that Windows will be installed to the first disk it enumerates (disk 0).

However, I just built a brand new system for myself which currently has both multiple NVMe SSD drives and ye old fashioned spinning HDDs. Windows is installed on an NVMe SSD, however, with this MB the HDDs are enumerated before the NVMe drives. As a result, during setup, the OS drive is not disk 0 (it's disk 2 in my case).

Is anyone aware a BIOS setting that can alter this behavior that would allow NVMe drives to be enumerated before SATA ports?

NOTE: This is an ASUS Prime Z590-A MB. It's the first ASUS MB I've had in at least a dozen years. Maybe someone more familiar with typical modern ASUS UEFI firmware would have some thoughts on this.

I could modify my unattended setup scripts and other scripts, it would simply be so much easier to maintain if everything was the same

I believe it is windows pnp enumeration, so not sure a bios setting will help.

Maybe better to use a script that detects ssd. It doesn't specifically mention win10 and nvme, but I haven't seen any other documentation

There is no direct relationship between the BIOS order, and the order in which Windows numbers the disks.

https://support.microsoft.com/en-us/...d-359be0a6d546

I have ran into this myself. The solution for me was to have only the OS M.2 drive installed during Windows installation then, after installation was complete attaching the rest of the disks which then would enumerate in sata port order. The issue here is that if your board is like most, SATA ports begin with 0 which of course now becomes disk 1.

This has everything to do with Intel and the use of PCIe/SATA port mapping of M.2 hardware. For advanced enthusiasts their implementation does not work for us. So what used to be a quick process is now cumbersome and time consuming when using a mix of multiple drives.

Thanks, Railtech. In the meantime I've made a simple mod to my unattended installation scripts. They now stop to ask what drive and partition to install to, but after that proceed completely unattended.

That's good enough most of the time except that I had some scripts that also do customized partitioning which requires files to be injected into the Windows image. So in that instance, it's not as simple as changing my unattended installation script.

Yeah, you can workaround some things but not all of it. I have an older board that i commissioned as workstation that has an onboard PCIe chip (PEX) which provides for an additional 32 lanes. I am running 2 M.2 disks in adapters on those respective PCIe ports on the board one of which is used for the OS. So in this case with the addition of each disk the OS disk would be moved up in disk number sequence. In the end that OS disk is now number 10. This was forced by how the enumeration sequence works on this particular board with respect to this additional PCIe onboard chip.

You can also run into issues if using M.2 slots when there are multiples available on the board. What I have found is that the closest slot to the PCH controller will generally give you the lowest disk number. I think where possible it is better to use disk or partition UUID numbers which are static whereas disk numbers may not be.

Ghot said:

Is there a way to have the unattended installation script look for the Disk with the "highest number, instead.
Iirc, I read somewhere that M.2 port(s) are always enumerated after the SATA ports are enumerated.

No, there is not, however, you got me thinking now. I wonder if there are any related settings such as the type of interface (SCSI, SATA, NVMe, etc.). I rather doubt it but I'm going to investigate.

UPDATE: Just looked the tree in Windows System Image Manager and see no such options. It's not really that big a deal. I have several ways I could workaround this.

There is no device manager. Remember, we're talking about the time during Windows setup. In fact, extremely early in setup before any files are copied to disk.

Doh! Just dawned on me that there is another solution. Before starting Windows installation, temporarily disconnect any SATA drives (or disable SATA in BIOS). Now the NVMe will be enumerated first and existing setup scripts will work without modification.

No idea why why my old brain cells didn't realize that earlier.