Apply Windows Image using DISM Instead of Clean Install  

@Kari @cereberus

I have two questions...

>> Why do you think applying the image is faster than the traditional USB method (via USB 2.0 or 3.0) -- just curious?

>> When creating the boot entry via "bcdboot G:\Windows" command, if the " /s " flag isn't used to designate where the boot files should be added too, does Windows automatically know which partition to add the boot entry too? What if there was another disk (such as Disk 1) or primary partition.

Windows just knows where the bcd is it seems. I am guessing dism has been updated to search for an existing EFI even in a winpe environment.

I am guessing here (@Kari may advise) that you would only need to use the /s if trying to create a fully bootable drive with its own EFI partition rather than modifying the exiting EFI partition.

This would only make sense if you wanted a fully independent drive to boot from selecting boot drive from bios.

I assume it is faster as dism is just more efficient, and cuts out all the internet, driver checking phases, multiple reboots etc.

KabyBlue said:

>> When creating the boot entry via "bcdboot G:\Windows" command, if the " /s " flag isn't used to designate where the boot files should be added too, does Windows automatically know which partition to add the boot entry too? What if there was another disk (such as Disk 1) or primary partition.

Installing on GPT disk on UEFI systems, boot records will be on C: drive by default. No need to use /s switch. On MBR disk / BIOS system, if the switch is not used, boot records will be stored on C: drive but using the switch you can store them on System Reserved (or another) partition.

Note that on MBR disk, you also need to mark partition containing boot records active with DISKPART after adding deployed Windows with BCDBOOT.

cereberus said:

I assume it is faster as dism is just more efficient, and cuts out all the internet, driver checking phases, multiple reboots etc.

Deploying with DISM does not decrease amount of reboots. The deployment phase has no reboots, the same when running a traditional clean installation until OOBE starts. The reboots will then occur when OOBE takes over from Windows installation, be it a deployment with DISM or running Windows Setup from install media.

Kari

Kari said:

Installing on GPT disk on UEFI systems, boot records will be on C: drive by default. No need to use /s switch. On MBR disk / BIOS system, if the switch is not used, boot records will be stored on C: drive but using the switch you can store them on System Reserved (or another) partition.

Note that on MBR disk, you also need to mark partition containing boot records active with DISKPART after adding deployed Windows with BCDBOOT.




Deploying with DISM does not decrease amount of reboots. The deployment phase has no reboots, the same when running a traditional clean installation until OOBE starts. The reboots will then occur when OOBE takes over from Windows installation, be it a deployment with DISM or running Windows Setup from install media.

Kari

Yeah of course you correct about reboots in deployment phase.

You would be better off deploying image to G. Then boot from a windows 10 installation drive, and just use bcdboot - as UEFI, you would not need the /s.

If you tried to do by booting from wintogo drive, you would have to use /s to ensure it correctly updated EFI on drive 0.

This Batch Fille will create an un-mounted Expandable (50GB max ) VHD
With a Drive letter of G when Mounted
Adjust " E:\TEST-WIN-OS.vhd " to assign vhd file location and name
Adjust Label to Display Drive label when mounted

Code:

create vdisk file="E:\TEST-WIN-OS.vhd" Maximum=51200 Type=Expandable
attach vdisk
automount disable
create partition primary
online volume
format quick fs=ntfs label="TEST-WIN-OS-VHD"
automount enable
assign letter=G
exit