Create media for automated unattended install of Windows 10  

hsehestedt said:

LOL. I had the same question recently. I just built a new computer a few weeks ago that has two NVMe drives and 2 SATA drives. The system insists on enumerating the SATA disks first.

As far as I have been able to determine, there is no way around this. However, there are simple workarounds.

Option 1: First, there is the solution that you already noted of disconnecting the SATA drives during the installation so that disk 0 will be your NVMe drive. Personally, I'm not a huge fan of having to tear open my machine to disconnect a drive to force Windows to install where I want it.

Option 2: You could simply modify your unattended install script so that the disk that you are partitioning and installing to is NOT disk 0, but rather, disk 1, disk 2, or whatever that disk happens to be in your system. The downside of this method is that you end up maintaining more than one answer file and you have to be careful to use the right one with the correct system. Let's see, for system 1, I need this answer file, for systems 2 and 3 I need this one. Yuck.

Option 3: Somewhat similar to option 2, but you could simply modify the answer file to not specify what disk to install on at all. The result is that the installation will pause, you will be presented the screen asking what drive you wish to install to, you make your selection, and then setup continues completely unattended.

You also asked about placing a script in your Windows installation - the simple answer is: Yes! You can do this. However, it's not a task for the faint of heart. In fact, johngalt and I had a discussion about this probably something like six months back (or maybe even longer ago, I loose track of time).

I've perfected a method to do this, but it would normally take a lot of work. I ended up writing a program for myself to automate the whole procedure. If this is something you are really interested in, let me know and I'll provide all the gory details to you and can make the program available as well.

As for what you actually put in such a script, I'd have to think about that one a bit. Again, if you an interest in pursuing that angle, I'd be happy to help and I can describe my purpose for wanting to run a script during installation as well. I won't bore you with those details now as it may put you to sleep (possible cure for insomnia).

Personally, I like option #3 because I can use that same answer file on all systems without fear of accidentally running a wrong answer file that wipes the wrong disk in a system

If you have any further questions or concerns, just shout. I would be happy to help.

I do remember that. I also remembered that I think I might have accidentally sparked it by suggesting the use of VolID or UUID of the disk to force install directly to the selected disk, based upon a (scipted) means of obtaining ssaid **IDs" in the first place.

This is usually not a problem when you have only one drive type installed - it's easy to pick the drive based upon which slot it is in / which SATA port it is connected to - the hardware will poll and assign volume info in a roughly normal manner.

But when you start mixing and matching, then you get all sorts of fun.

My previous rig, the one with the Core i7 965, had regular SATA II ports and a pair of SATA III (not true 6.0 Gbps ports as they were controlled by a 3 party controller, Marvell), and these were not enumerated correctly whenever the hardware was polled, causing the SATA II drives to all be assigned Volume info prior to the SATA III drives - every single time - it's one of the reasons I never really went forward with this tutorial because there was not reliable way to make it fully automated - I *had* to jump in there to make it work, either by disconnecting the SATA II drives (easily done, as the drive bays were hot swap / hot-remove bays) or by using diskpart manually during install.

Now, with my new machine, I have NVMe and SATA III drives - and sure enough, the system assigns volume info to SATA before NVMe.

*Sigh*

This is much harder to deal with because there is no easy, reliable way to disconnect the SATA drives anymore like in the old rig. And I have a triplet of NVMe drives, so I always have to be sure I'm picking the right one (one of the reason I pre-delete the partition on the intended system drive)

it's a major PITA, indeed.

Drwaffles90 said:

It's a royal PITA lol.
Would be nice if we could tell it to install on the highest drive number possible (if exists Drive 6, else drive 5 else drive 4.. etc)

Sadly that's not possible in my particular instance as we're installing them without monitors connected.. The machines I'm doing are just the tower and it does basically everything itself including benchmarking/stability testing without any input.

Certainly sounds interesting.. I'd be curious about what your solution was.
Programming is far from my strong point though.. I'm determined but without google I could barely put together a batchfile that achieves much more than moving a file lol.

Programming option is the best for my use case.
Option 1 is easy enough for me because the side panels are still off the case after assembly for cable management.
It's just annoying that I have to re-boot the system just to get it to recognise the drive.. It'd be so much nicer is the install did everything itself once it started and sysprep'd after x time.

If you've got the time, PM me because I'd like to at least try and make it work :)

If you can get this worked out, or all of you collectively can, then I'll defeinitely be testing

hdmi said:

I prefer Option 4: Customize the WinPE by using WinRAR for extracting the boot.wim file that can be found in the sources folder in the Windows 10 Installation ISO (or just mount the ISO to grab the boot.wim that way... it doesn't factually matter which way). After mounting the boot.wim file with Dism /Mount-Image /ImageFile:boot.wim /Index:1 /MountDir:C:\test\offline, open the file C:\test\offline\Windows\System32\startnet.cmd with notepad and then add diskpart above the line that reads wpeinit. (Add cmd /k below diskpart if you need to type in additional commands.) Save the file in notepad to your desktop, then copy it to the C:\test\offline\Windows\System32 folder and confirm when you get prompted. Commit changes to and unmount the boot.wim with Dism /Unmount-image /MountDir:C:\test\offline /Commit and then finally overwrite the original file that's inside the ISO.

The benefit of going this route is that you immediately get to diskpart before it goes to load up Windows Setup. (If you added the cmd /k you will need to type in exit to let it continue to Setup.) It's been way more than a decade since the last time when I futzed around with the installation in this manner. I was on Win7 x64 Ult back then so, this little trick is pretty old now... please don't shoot me if I missed a step.

Brilliant! Only I'd use 7-ZIP for extraction versus WinRAR (though I have a WinRAR License, not everyone will). Good job on pointing this out!

Drwaffles90 said:

That sounds extremely promising.
7-zip seems to provide the goods in terms of extracting the file.

So does that basically run a batch script before windows?
i.e

Startnet.cmd - edit'd to say
"diskpart
cmd /k
select drive 0
clean
exit
wpeinit
"
in this instance would automatically clean drive 0 before starting the install?

If so the following question is how do I get it to set drive 0 as the smallest capacity drive (Or nvme interface)
Possibly disable the larger drive? and re-enable/format it on bootup?
Set it to read-only?

hdmi said:

@hsehestedt

Well shoot. I feel so gosh darn old and nostalgic now!
https://social.technet.microsoft.com...winserversetup

- - - Updated - - -

Force OS on NvMe drive during OSD. : SCCM

- - - Updated - - -
@Drwaffles90

See above. You can't put diskpart commands directly in a batch script because diskpart opens in a separate window and it uses its own unique set of commands that are not batch commands. You can work around this by piping the output of a block of echo commands into diskpart like @hsehestedt has done or put the diskpart commands in a separate textfile for the sake of readability and/or for future upgrading your script (e.g., writing an additional script that autogenerates the textfile dynamically on-the-fly before it will then be read by diskpart, etc.) like shown in the ancient Technet discussion topic I linked above. Also note that adding the /s parameter to diskpart causes diskpart to run in silent script mode so that redirecting the output from diskpart to nul with >nul will no longer be needed. The second link I gave above points to a discussion on Reddit where various people chimed in about things like how PowerShell can also be used to set a variable to store disk number:
https://docs.microsoft.com/en-us/mem...re-disk-number
...and to set the NVMe as disk 0, like you were asking:
Force OS on NvMe drive during OSD. : SCCM

- - - Updated - - -

Also note that wpeinit can accept a parameter to let you specify the answer file:
https://docs.microsoft.com/en-us/win...d-line-options

- - - Updated - - -

How to edit the Winpeshl.ini file that was mentioned in the old discussion topic on Technet I linked above:
https://docs.microsoft.com/en-us/win...n-winpe-starts

hsehestedt said:

Thanks, hdmi. That provides a lot to perform some testing on.

Yup. My trivia contest was last weekend - I'll have plenty of time to play this weekend.

Kari said:

Thanks!




Honestly, it took closer to 30 hours to write, excluding test installs but including about six hours to try to find what caused this error when I thought I was ready and tested the install media:
Attachment 161194

That error message when you get it after running Sysprep means installation has gone beyond salvation, you must start from scratch. At the end I found out, as so often before, that the error was due a stupid newbie mistake I had done.

In addition, it took a bottle and a half cheap supermarket whisky, two frozen microwave pizzas and about quarter of kilo dark roasted espresso.

Kari

Hello,

I have followed this guide, but just end up with this error message every time relating to the unattend.xml
No matter what I do I get the same error, I have tried using your exact unattend.xml to see if mine was the issue but I still get this error.

You say that this means the installation has gone beyond salvation, you must start from scratch - does this mean rebuild the image from step 1 and start the process again? Or that I need to fix the unattend and then sysprep again as I have a checkpoint prior to sysprep.

Any help would be very much appreciated :)


Edit:
As a test I setup a new VM in hyper-v, installed Windows then into Audit mode once I got to the OOBE stage.
All I did was copy and paste the example unattend.xml from this guide into the sysprep folder, then sysprep(generalized) and reboot to allow the VM to run the unattend.xml as a test.

I get the same error that Windows could not parse or process the unattend file.
Can anyone tell me what is going on here? I would of thought a clean unmodified install with a working unattend.xml would have been fine.

- - - Updated - - -

ITguy123 said:

Hello,

I have followed this guide, but just end up with this error message every time relating to the unattend.xml
No matter what I do I get the same error, I have tried using your exact unattend.xml to see if mine was the issue but I still get this error.

You say that this means the installation has gone beyond salvation, you must start from scratch - does this mean rebuild the image from step 1 and start the process again? Or that I need to fix the unattend and then sysprep again as I have a checkpoint prior to sysprep.

Any help would be very much appreciated :)


Edit:
As a test I setup a new VM in hyper-v, installed Windows then into Audit mode once I got to the OOBE stage.
All I did was copy and paste the example unattend.xml from this guide into the sysprep folder, then sysprep(generalized) and reboot to allow the VM to run the unattend.xml as a test.

I get the same error that Windows could not parse or process the unattend file.
Can anyone tell me what is going on here? I would of thought a clean unmodified install with a working unattend.xml would have been fine.

Ignore this guys, I fixed it :)

Mind letting us know what the problem was so that others in the future can avoid it?

Makes perfect sense, and thanks for both explaining it as well as being patient with my seeming impatience

Drwaffles90 said:

When using an unattended on a system with 2 drives (Say 1x NVME and 1x Sata 2.5" SSD)
The MB seems to typically assign the sata drive as drive 0.. So naturally the system installs on that as per the answer file.
It's a small annoyance, but having windows not on the fastest drive seems silly..

hsehestedt said:

LOL. I had the same question recently. I just built a new computer a few weeks ago that has two NVMe drives and 2 SATA drives. The system insists on enumerating the SATA disks first.

Answer files do pretty much everything you ask them to do. You simply define the disk and partition where you want Windows to be installed in WSIM.

Extract from my normal autounattend.xml file, installing Windows to Disk 1, Partition 3:


Screenshots from WSIM:




Kari

Did you try adding the username and password fields to the file but leaving the actual data in them blank?

Something like this:

Code:

<ImageInstall>
    <OSImage>
        <InstallFrom>
            <Credentials>
                <Domain></Domain>
                <Password></Password>
                <Username></Username>
            </Credentials>