Personalization possible pre-activation in VMware, not Hyper-V. Why?

Type 1 Hypervisors like Hyper-V must be started before operating system is loaded. Even the host OS runs then on top of the Hypervisor, using physical hardware devices. Virtual machines run then on top of the OS using emulated, virtual hardware devices.

Type 2 Hypervisors like VMware Workstation and Oracle VirtualBox do not need an underlying hardware Hypervisor. Hypervisor runs on top of OS, and virtual machines on top of OS.

(Image from Wikipedia article Hypervisor.)

This allows Type 2 Hypervisors more direct contact to physical hardware.

Windows works slightly differently on emulated hardware in Hyper-V, most notable difference being what you've noticed: even when installed without network connection, Windows will be not activated by default until the virtual machine has a network connection and has been properly activated. This prevents personalization.

Virtual machines on Type 2 Hypervisors, as well as physical machines act in an exact opposite way: They are kind of "pseudo-activated" until the machine has a network connection, at which point if no digital license is found their status will change to not activated.

This allows physical Windows installations, and those on Type 2 Hypervisor virtual machines to be personalized as long as Windows has been installed without network connection, and machines remain without connection.

A simple workaround I often use when creating new Generation 2 Hyper-V VM is to first deploy Windows to a virtual hard disk, then boot natively to it. This way, the VHD acts like a physical Windows installation, directly using host's physical hardware devices. You can personalize it, even in Audit Mode, then restart the host, and use the VHD as existing disk when setting up a new VM in Hyper-V.

Quoting instructions from Ten Forums video thread:

Kari said:

New video: Dual Boot - The Easy Way



The easiest possible method to dual boot. No partitioning, no virtualization required. Deploy Windows 10 on a virtual hard disk VHD or VHDX file, add it to boot menu. When done, when you no longer want to dual boot, just delete the VHD file.

   Note

When creating VHD file to be used in native boot, always use MBR partitioning! To upgrade Windows on native boot VHD, it must be temporarily attached to a virtual machine. An MBR partitioned VHD is easy to attach to VM, it only needs Windows partition to be marked active, whereas a GPT partitioned VHD with only a single partition for Windows requires manually creating system partitions before it can be used on VM.

If you for any reason want to use a GPT partitioned VHD in native boot (can't think any valid reason!), it is better and recommended that you first create a Generation 2 VM in Hyper-V, installing Windows 10 on it. This takes care of the partitioning, doing it correctly. The VHD can then be used as native boot VHD, or on a VM.

See this tutorial for more information: Native boot Virtual Hard Disk - How to upgrade Windows

The DISKPART script and deployment batch from video:

DISKPART scripts are normal text files with extension .txt. To run a DISKPART script, enter following command:

diskpart /s DRIVE:\FOLDER\SCRIPT.TXT

Here's the script used in video:

Code:

create vdisk file=F:\W10PRO.vhdx maximum=51200 type=expandable
attach vdisk
create part primary
format quick label="Windows"
assign letter=W
exit

Save script as VHDConfig.txt

Above script creates a dynamically expanding MBR partitioned 50 GB (51,200 MB) VHDX file (you can use .vhd or .vhdx) named W10PRO.vhdx in root of drive F:, labels it Windows and assigns it a temporary drive letter W:. Edit script to meet your needs, be sure the drive you create VHD has double the free storage than the size of VHD; if you will create a 100 GB VHD file to be used in dual boot, the drive where it will be created needs 200 GB free.

Also, be sure to assign an unused drive letter! I always use W: which I have reserved for this purpose, never assigning it to anything else. In any case the drive letter will only be needed for deployment, it will be freed when VHD will be unmounted.

The deployment batch is really simple, too. It just runs DISKPART script to set up VHD, deploys Windows on it with DISM, adds it to host boot menu and finally changes the boot menu entry to something more descriptive:

Code:

start /wait diskpart /s E:\Users\Kari\Scripts\VHDConfig.txt
start /wait dism /apply-image /imagefile:I:\sources\install.wim /index:8 /applydir:W:\
start /wait bcdboot W:\Windows
start /wait bcdedit /set {default} description "W10 PRO EN-GB (VHD)"
cls
@echo off
echo. 
echo Windows deployed to VHD file
echo and added to host boot menu.
echo.
pause
exit

Save batch file as VHDBoot.bat

Again, edit the batch to meet your needs. Be sure path to DISKPART script is correct, and that path to install.wim (or in case of MCT ISO install.esd) is correct in DISM command. Select correct index value. Check that BCDBOOT will add Windows to boot menu from correct disk, the drive letter here must be the same DISKPART script assigned to VHD.

Notice that the above quote shows Windows deployment to an MBR VHD, which can only be used on Hyper-V Generation 1 virtual machines.

Below the VHDConfig.txt DISKPART script to create a GPT VHD, which can be used on Hyper-V Generation 2 virtual machines. It creates UEFI system partitions and Windows partition:

Code:

create vdisk file=F:\W10PRO.vhdx maximum=51200 type=expandable
attach vdisk
convert gpt
create partition efi size=100
format quick fs=fat32 label="System"
create partition msr size=128
create partition primary
shrink minimum=500
format quick fs=ntfs label="Windows"
assign letter="W"
create partition primary
format quick fs=ntfs label="WinRE"
set id="de94bba4-06d1-4d40-a16a-bfd50179d6ac"
exit

Kari

hsehestedt said:

This one has been a mystery to me for quite a while, so it's great to finally understand this.

It is a not too well documented fact, that even the host OS when Hypervisor is enabled (requirement for Hyper-V to function) is kind of virtual, running on top of the Hypervisor.

This is not an issue, though. Host OS running on top of the Hypervisor does not cause any delays or lack in its functionality. However, it causes some minor issues like the one you've noticed, when a guest OS on a VM is run.

Kari

In addition to what has been said:

Let's see Device Manager on a host OS when Hypervisor is enabled. In this example, here are the network devices:



Then, a typical Hyper-V VM on that host:



And last, when the VHD of the same VM is used as native boot VHD, or on Type 2 Hypervisor:



Looking at these screenshots, it is obvious that having Hypervisor enabled makes a big difference. The difference in how a a VM sees the hardware, depending on if Type 1 or Type 2 Hypervisor is used, is the culprit for different functionality.

Really short: Virtual machines running on Type 1 Hypervisor behave slightly differently than those running on Type 2 Hypervisors, only because they see the hardware setup differently.

Kari

hsehestedt said:

Let's say that my Windows partition is encrypted with bitlocker. Will this still be able to add a menu option to allow booting from a VHD or will bitlocker present a problem?

No, no problem at all. Windows installation on a VHD is a totally different entity, it does not inherit BitLocker or any other behaviour from the host OS.

Just one note: If you use a native boot VHD to setup Windows on a virtual hard disk, then use the said VHD on a new Hyper-V VM, it does not boot because the VM has no boot records.

To resolve this, boot the new VM first from Windows install media (ISO), press SHIFT + F10 on region selection screen to open Command Prompt, run DISKPART to check the drive letter of Windows partition (#1 & #2 in screenshot), confirm the Windows partition letter (#3), exit DISKPART (#4), and use BCDBOOT command to create boot records (#5) for the VM:



Kari

hsehestedt said:

I have not yet tried to follow the instructions to attach the VHD to a VM. That may have to wait since I use VMware workstation and I'm simply not feeling like reconfiguring for Hyper-V at the moment and since I have complete faith in your instructions

I am running Hyper-V, VMware and VirtualBox on the same machine without any issues. See this tutorial: Run Hyper-V, VirtualBox and VMware on same Computer

hsehestedt said:

Finally, in case you are interested, here is a tweaked version of the batch file.

The idea when making a tutorial or a video is to make it so simple that any newbie can follow the given instructions. That's why scripts and batches are simplified, only the basics. As such, they'll do what they are supposed to do. A fact is that some users not too familiar with a method told in a tut or video will lose interest if it looks too complicated.

In my own use, I then use more complicated versions of the same scripts and batches. What in a script in a tutorial or a video takes just a few lines of code, might (and often do) take in my own version 100+ lines.

Your code is nice, I will for sure check it, and after my edits, use it. Thanks.

hsehestedt said:

Question 1: There was one point in your instructions that I am not fully understaning. You note that the preference is to create a VHD with an MBR disk. If I'm going to boot this VHD not from a physical machine that is UEFI based, wouldn't I want to create this as a GPT disk instead? On my system, which is UEFI based, I'm finding that creating the VHD as GPT is working fine, but creating it as MBR causes Windows setup on the VHD to hang.

The only benefit of using GPT on native boot VHD is to be able to use a VHD larger than 2 TB, the MBR size limit. As no sane person will need a VHD bigger than that, the VHD can be MBR. That is my recommendation.

The situation changes only if the VHD is planned to be used on Generation 2 Hyper-V VM, then the VHD must be GPT.

You can run MBR native boot VHDs on a GPT system, as well as GPT native boot VHDs on an MBR system. Nothing prevents that. Why your MBR VHD hangs is a mystery to me. I have EN-GB Windows 10 on all my machines, all UEFI / GPT, running other language versions (FIN, SWE and GER) from MBR native boot VHDs without any issues.

hsehestedt said:

Question 2: I know that I'm pushing my luck here, but is there any way that I can safely deploy an unattended installation to that VHD? I know that if I simply take an autounattend.xml that wipes disk 0 it's going to wipe my physical disk 0. I'm curious if there is some way to determine in advance what disk number the VHD is going to be.

Short: not possible.

A bit longer: DISM requires an existing volume to apply Windows image. There's no way to integrate partitioning in an answer file to that process.

However, what I always do when setting up Windows on native boot VHD is to mount the image I will be deploying and apply an unattend.xml answer file to it for my customizations. See the tutorial: Apply unattended answer file to Windows 10 install media

jimbo45 said:

Thanks for all the good work you do around here !!!!

Thanks for really nice feedback, Jimbo!

Kari