Windows To Go is a portable version of Windows booted from a USB device. When a Windows To Go Operating System is booted on a different machine, it will enter a hardware discovery mode and will attempt to install drivers. This process only occurs on the first boot on a new device - on subsequent (re)boots the hardware is remembered and the boot process is significantly faster. Officially only Windows 8/8.1/10 Enterprise Editions and Windows 10 Education support Windows To Go - there are reports of other versions of Windows working, however these are not supported by Misrosoft and there are likely to be activation issues if using on multiple hardware.
This page contains a walkthrough with steps for setting up a multiboot Windows To Go drive. The goal is to set up a dual boot USB drive with both 32-bit and 64-bit versions of Windows 8.1 Update 1 operating systems - bootable on both BIOS and UEFI firmware. There are no guarantees that this approach will work on all hardware. It's not the most detailed walkthrough, but does outline the steps required. A basic understanding of using command line tools and batch files is assumed.
Microsoft has only certified a very limited range of hardware for Windows To Go - see here. I have not had any difficulty booting Windows To Go on any of the external USB 2.0 Hard Disk Drives I've tested this feature on. I do not recommend attempting to install Windows To Go on USB 2.0 flash drives as the system can be frustratingly slow - it is however possible with Fixed Disk type USB 2.0 flash drives. There are reports of Windows To Go working on Removable Disk type USB flash drives - but only when Windows To Go is installed to a .vhd file.
For more information about Windows To Go see here.
figure 1.
The following files/tools/harware are required -
- wimlib-imagex - see website (here) for download details, instructions and a user forum. From website homepage - "...wimlib is an open source,cross-platform library for creating, extracting, and modifying Windows Imaging (WIM) archives.." wimlib-imagex is a windows binary and is a viable alternative to the Microsoft ImageX and DISM tools. wimlib-imagex is a command-line tool. Version 1.10.0 was used in testing.
- Windows 8.1 source files - obtain from Windows installation media. Windows 8.1 Update 1 was used in this walkthrough. Evaluation versions can be used - the evaluation versions are available here. Remember that 32-bit and 64-bit require seperate source files.
- Windows 7/8/8.1/10 - the steps in this walkthrough were completed on a Windows 8.1 (Update 1) host Operating System. It should also be possible to use WinPE.
- USB Hard Disk - a 160 GB Western Digital USB 2.0 external HDD was used in testing.
- Hardware capable of booting from USB device - BIOS/UEFI firmware support for booting the USB drive type being used is required. USB boot support is limited on some older hardware.
In this walkthrough a 160 GB Western Digital USB Hard Disk was used. I decided to partition it to keep the boot files and the 32-bit and 64-bit operating systems on seperate partitions - with an additional partition for data that can be accessed from either OS.
Partition structure -
| ----- |
| Partition # | Size | File System | Active | Purpose |
| 1 | 1 GB | FAT | * | Boot files |
| 2 | 50 GB | NTFS | | 32-bit Windows |
| 3 | 50 GB | NTFS | | 64-bit Windows |
| 4 | Remaining Space | NTFS | | Data |
There are various methods that can be used to prepare the disk drive - I recommend DiskPart as it's included in windows and can be scripted. Manually check the drive number as seen by Windows first to ensure that the correct hard disk drive is used - failure to do so may result in data loss (wiping the wrong drive!). In the script below disk drive 3 is the target drive - ensure that you edit the script as required (changing the first line to set the correct disk number - remember Windows numbers disks from 0).
Contents of Diskpart script (D:diskpart_script.txt) -
sel disk 3 clean create part pri size=1024 format fs=fat label=WD00 quick active create part pri size=51200 format fs=ntfs label=WD01 quick create part pri size=51200 format fs=ntfs label=WD02 quick create part pri format fs=ntfs label=WD03 quick exit
Run the following command from a command promt as an Administrator (this will execute the commands in the script D:diskpart_script.txt and will output to D:diskpart_script_log.txt)-
- DiskPart /S D:diskpart_script.txt > D:diskpart_script_log.txt
Assuming the USB drive has been prepared as per the instructions in this guide with seperate partitions for boot, Windows 8.1 (32-bit) and Windows 8.1 (64-bit) - check the mount points for each drive. The following mount points and source file paths were used in the instructions below -
- D:x86install.wim - Windows 8.1 (32-bit) Source file(s).
- D:x64install.wim - Windows 8.1 (64-bit) Source file(s).
- D:wimlib-imagex.exe - wimlib executable file.
- E: - USB drive partition 1 (for boot files).
- F: - USB drive partition 2 (for 32-bit Windows)
- G: - USB drive partition 3 (for 64-bit Windows)
Install 32-bit Windows 8.1 -
Step 1
Apply/extract 32-bit Windows 8.1 source files using wimlib-imagex -
- D:wimlib-imagex.exe apply D:x86install.wim 1 F:
Step 2
Create boot files for the 32-bit windows extracted in the preceeding step on partition E: (note the use of the /f ALL switch - this will create BCD stores for use on UEFI and BIOS systems) -
- bcdboot.exe F:windows /s E: /f ALL
Step 3
This step is optional. Use it to apply SanPolicy 4 to the Windows 32-bit files extracted to F: in step 1. SanPolicy 4 will result in any internal disks being offline when Windows To Go is booted - ensuring that data on any internal disks is protected (particularly useful if using Windows To Go for digital Forensic work). To do this the Windows To Go SYSTEM registry hive needs mounting, modifying and unmounting -
- reg.exe load HKLM_SYSTEM F:Windowssystem32configsystem
- reg.exe add HKLM_SYSTEMControlSet001ServicespartmgrParameters /v SanPolicy /t REG_DWORD /d 4 /f
- reg.exe add HKLM_SYSTEMControlSet001ServicesMountMgr /v NoAutoMount /t REG_DWORD /d 1 /f - (optional - for Windows Forensic application)
- reg.exe unload HKLM_SYSTEM
Or alternatively using a batch file -
@echo off reg.exe load HKLM_SYSTEM F:Windowssystem32configsystem reg.exe add HKLM_SYSTEMControlSet001ServicespartmgrParameters /v SanPolicy /t REG_DWORD /d 4 /f reg.exe add HKLM_SYSTEMControlSet001ServicesMountMgr /v NoAutoMount /t REG_DWORD /d 1 /f reg.exe unload HKLM_SYSTEM echo. echo. echo. pause
Step 4
Boot from the USB Drive and complete the 32-bit Windows 8.1 installation.
Step 5
This step is optional. To ensure that the Windows 32-bit operating system remains self contained and to reduce the risk of accidentally accessing or modifying the Windows 64-bit operating system we are going to install to Partition 3 of the USB disk drive, remove the mount point. This needs to be completed from the booted 32-bit Windows To Go system - e.g. start the Disk Management console, right-click on partition 3 on the USB disk drive and select "Change Drive Letter and Paths..." > click on the Remove button.
Install 64-bit Windows 8.1 -
Step 6
Apply/extract 64-bit Windows 8.1 source files using wimlib-imagex -
- D:wimlib-imagex.exe apply D:x64install.wim 1 G:
Step 7
Create boot files for the 64-bit windows extracted in the preceeding step (this will modify the exisitng BCD stores and will add any required boot files) -
- bcdboot.exe G:windows /s E: /f ALL
Step 8
This step is optional. Having modified the BCD store in step 7 there will now be two menu entries - with both entries stating Windows 8.1. These can be modifed to facilitate selecting the correct Operating System when the USB Disk Drive is booted - refer to Walkthrough - Part 3 for detailed instructions.
Step 9
This step is optional. Use it to apply SanPolicy 4 to the Windows 64-bit files extracted to G: in step 6. SanPolicy 4 will result in any internal disks being offline when Windows To Go is booted - refer to Step 3 for more information. Run a batch file with the following contents -
@echo off reg.exe load HKLM_SYSTEM G:Windowssystem32configsystem reg.exe add HKLM_SYSTEMControlSet001ServicespartmgrParameters /v SanPolicy /t REG_DWORD /d 4 /f reg.exe add HKLM_SYSTEMControlSet001ServicesMountMgr /v NoAutoMount /t REG_DWORD /d 1 /f reg.exe unload HKLM_SYSTEM echo. echo. echo. pause
Step 10
Boot from the USB Drive and complete the 64-bit Windows 8.1 installation.
Step 11
This step is optional. To ensure that the Windows 32-bit operating system remains self contained and to reduce the risk of accidentally accessing or modifying the Windows 64-bit operating system we are going to install to Partition 3 of the USB disk drive, remove the mount point. This needs to be completed from the booted 32-bit Windows To Go system - e.g. start the Disk Management console, right-click on partition 3 on the USB disk drive and select "Change Drive Letter and Paths..." > click on the Remove button.
The screenshot below was taken from the booted 64-bit Windows 8.1 Windows To Go installation. Note that Disk 0, the internal disk, is flagged as Offline - none of the partitions on this disk have been mounted.
figure 2.
Modify the BCD Store(s). Note that if the instructions above were followed there will be two BCD stores -
- E:bootBCD - loaded on BIOS Firmware
- E:EFImicrosoftbootBCD - loaded on UEFI Firmware
Each store will display seperate entries for the 32-bit and 64-bit operating systems - unfortunately both will be displayed as Windows 8.1 - making it difficult to identify the correct entry.
Step 12
The following command will copy the OSLOADER type menu entries contained in E:bootBCD to D:bcd_BIOS_entries.txt -
- bcdedit.exe /store E:bootBCD /enum osloader > D:bcd_BIOS_entries.txt
Contents of D:bcd_BIOS_entries.txt -
Windows Boot Loader ------------------- identifier {default} device partition=G: path windowssystem32winload.exe description Windows 8.1 locale en-us inherit {bootloadersettings} allowedinmemorysettings 0x15000075 osdevice partition=G: systemroot windows resumeobject {0ee7773b-94d2-11e6-9730-0016d3c48e5f} nx OptIn bootmenupolicy Standard detecthal Yes Windows Boot Loader ------------------- identifier {72b7be5e-9483-11e6-972f-0016d3c48e5f} device partition=F: path windowssystem32winload.exe description Windows 8.1 locale en-US inherit {bootloadersettings} recoverysequence {72b7be5f-9483-11e6-972f-0016d3c48e5f} recoveryenabled Yes allowedinmemorysettings 0x15000075 osdevice partition=F: systemroot windows resumeobject {72b7be5d-9483-11e6-972f-0016d3c48e5f} nx OptIn bootmenupolicy Standard
Step 13
Identify the GUIDs for the two Operating System entries using the output from Step 12. In this case -
- {default} - 64-bit Windows 8.1
- {72b7be5e-9483-11e6-972f-0016d3c48e5f} - 32-bit Windows 8.1
Step 14
Create and run a batch file to edit the descriptions in the BCD objects for the 32-bit and 64-bit Windows 8.1 menu entries. The batch file will change the descriptions to -
- Windows 8.1 (32-bit) - {72b7be5e-9483-11e6-972f-0016d3c48e5f} object
- Windows 8.1 (64-bit) - {default} object
Batch file contents - text may be "wrapped" -
@echo off bcdedit.exe /store E:bootBCD /set {72b7be5e-9483-11e6-972f-0016d3c48e5f} description "Windows 8.1 (32-bit)" bcdedit.exe /store E:bootBCD /set {default} description "Windows 8.1 (64-bit)" echo. echo. echo. pause
Step 15
The following command will copy the OSLOADER type menu entries contained in E:EFImicrosoftbootBCD to D:bcd_UEFI_entries.txt -
- bcdedit.exe /store E:EFImicrosoftbootBCD /enum osloader > D:bcd_UEFI_entries.txt
Contents of D:bcd_UEFI_entries.txt -
Windows Boot Loader ------------------- identifier {default} device partition=G: path windowssystem32winload.efi description Windows 8.1 locale en-us inherit {bootloadersettings} isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=G: systemroot windows resumeobject {13b42958-94d2-11e6-9730-0016d3c48e5f} nx OptIn bootmenupolicy Standard detecthal Yes Windows Boot Loader ------------------- identifier {769ab38d-9483-11e6-972f-0016d3c48e5f} device partition=F: path windowssystem32winload.efi description Windows 8.1 locale en-us inherit {bootloadersettings} isolatedcontext Yes allowedinmemorysettings 0x15000075 osdevice partition=F: systemroot windows resumeobject {769ab38c-9483-11e6-972f-0016d3c48e5f} nx OptIn bootmenupolicy Standard detecthal Yes
Step 16
Identify the GUIDs for the two Operating System entries using the output from Step 12. In this case -
- {default} - 64-bit Windows 8.1
- {769ab38d-9483-11e6-972f-0016d3c48e5f} - 32-bit Windows 8.1
Step 17
Create and run a batch file to edit the descriptions in the BCD objects for the 32-bit and 64-bit Windows 8.1 menu entries. The batch file will change the descriptions to -
- Windows 8.1 (32-bit) - {769ab38d-9483-11e6-972f-0016d3c48e5f} object
- Windows 8.1 (64-bit) - {default} object
Batch file contents - text may be "wrapped" -
@echo off bcdedit.exe /store E:EFImicrosoftbootBCD /set {769ab38d-9483-11e6-972f-0016d3c48e5f} description "Windows 8.1 (32-bit)" bcdedit.exe /store E:EFImicrosoftbootBCD /set {default} description "Windows 8.1 (64-bit)" echo. echo. echo. pause
Step 18
This step is optional. To display a text based boot menu, the operating system objects/entries in the BCD stores will need to have BOOTMENUPOLICY set to legacy (refer to figure 3. and figure 4. below).
Having identified the GUIDs in the E:bootBCD store in steps 12 to 13, create and run a batch file to set/change the BOOTMENUPOLICY. Batch file contents (text may be "wrapped") -
@echo off bcdedit.exe /store E:bootBCD /set {default} BOOTMENUPOLICY legacy bcdedit.exe /store E:bootBCD /set {72b7be5e-9483-11e6-972f-0016d3c48e5f} BOOTMENUPOLICY legacy echo. echo. echo. pause
And repeat for the E:EFImicrosoftbootBCD store (GUIDs identified in steps 15 to 16). Batch file contents (text may be "wrapped") -
@echo off bcdedit.exe /store E:EFImicrosoftbootBCD /set {default} BOOTMENUPOLICY legacy bcdedit.exe /store E:EFImicrosoftbootBCD /set {769ab38d-9483-11e6-972f-0016d3c48e5f} BOOTMENUPOLICY legacy echo. echo. echo. pause
BOOTMENUPOLICY standard
figure 3.
BOOTMENUPOLICY legacy
figure 4.
The ability to boot an Operating System in a Virtual Hard Disk (VHD) was introduced with Windows 7. It is also possible to boot Windows To Go using Native Boot VHD.
To demonstrate how to setup Windows To Go to boot from a VHD file, lets add a Windows 10 VHD to our USB Hard Disk Drive. For convenience it's easier to complete the initial stages on an internal drive, then copy the VHD file over to the USB Drive and complete setup. The following file paths will be used in this section of the walkthrough -
- D:Win10install.wim - Windows 10 source file(s).
- D:win10.2go.x64.vhd - path for VHD file - prior to copying it to the USB drive.
- D:wimlib-imagex.exe - wimlib executable file.
- H: - USB drive partition 4.
Step 19
First create D:win10.2go.x64.vhd by running a diskpart script D:diskpart_create_VHD.txt. Contents of D:diskpart_create_VHD.txt (this will create a 20 GB fixed size VHD file, partition and format with NTFS, and mount the single volume in the VHD file as drive S:) -
create vdisk file=D:win10.2go.x64.vhd maximum=20480 type=fixed select vdisk file=D:win10.2go.x64.vhd attach vdisk sel disk 1 clean create part pri format fs=ntfs label=win2go quick active assign letter=s exit
Run the following command from a command promt as an Administrator (this will execute the commands in the script D:diskpart_create_VHD.txt and will output to D:diskpart_create_VHD_log.txt)-
- DiskPart /S D:diskpart_create_VHD.txt > D:diskpart_create_VHD_log.txt
vhd_boot_initialization_failed - I initially attempted to setup Windows To Go on a dynamic type VHD file (a sparse file that expands up to the maximum size defined when it was created) - this resulted in a BSOD which displayed a vhd_boot_initialization_failed error. It's possible that this was related to other factors (including settings covered in Step 21, however using a Fixed disk resulted in a successful setup and boot. This requires further investigation.
Step 20
Apply/extract Windows 10 source files to the mounted VHD volume (S:) using wimlib-imagex -
- D:wimlib-imagex.exe apply D:win10install.wim 1 S:
Step 21
This step is optional. Use it to apply SanPolicy 4 to the Windows files extracted to drive S: in step 20. SanPolicy 4 will result in any internal disks being offline when Windows To Go is booted - refer to Step 3 for more information. Run a batch file with the following contents -
@echo off reg.exe load HKLM_SYSTEM S:Windowssystem32configsystem reg.exe add HKLM_SYSTEMControlSet001ServicespartmgrParameters /v SanPolicy /t REG_DWORD /d 4 /f reg.exe unload HKLM_SYSTEM echo. echo. echo. pause
Note that unlike in Step 3 the HKLM_SYSTEMControlSet001ServicesMountMgr key NoAutoMount value has not been added - during a test this might have been responsible for the VHD failing to boot (vhd_boot_initialization_failed) - this requires further investigation.
Step 22
Now detach the VHD file using the following diskpart script/commands -
select vdisk file=D:win10.2go.x64.vhd detach vdisk exit
Step 23
Copy D:win10.2go.x64.vhd to H:win10.2go.x64.vhd.
Step 24
Now attach the VHD file H:win10.2go.x64.vhd using the following diskpart script/commands (this should result in the partition in the VHD file being automatically mounted as Drive S: - assuming this was specified as the mount point in step 19) -
select vdisk file=H:win10.2go.x64.vhd attach vdisk exit
Step 25
Create boot files for H:win10.2go.x64.vhd - note that S:windows (the mounted VHD partition) is specified as source. Also note the use of the /f ALL switch used to create BCD store entries for use on UEFI and BIOS systems -
- bcdboot.exe S:windows /s E: /f ALL
Step 26
This step is optional. Walkthrough - Part 3 covers editing the text displayed in the boot menu and also BOOTMENUPOLICY options in detail. Step 25 should have added a menu option for the VHD based Windows To Go to both E:bootBCD (loaded on BIOS Firmware) and E:EFImicrosoftbootBCD (loaded on UEFI Firmware). As running the bcdboot command should have added the VHD based Windows To Go as the {default} guid, the following batch file can be used to change the text displayed in the boot menu and to change/set BOOTMENUPOLICY as legacy (significantly reducing the time it takes to display a boot menu) -
@echo off bcdedit.exe /store E:bootBCD /set {default} description "Windows 10 VHD (64-bit)" bcdedit.exe /store E:EFImicrosoftbootBCD /set {default} description "Windows 10 VHD (64-bit)" bcdedit.exe /store E:bootBCD /set {default} BOOTMENUPOLICY legacy bcdedit.exe /store E:EFImicrosoftbootBCD /set {default} BOOTMENUPOLICY legacy echo. echo. echo. pause
Step 27
Now detach the VHD file H:win10.2go.x64.vhd using the following diskpart script/commands -
select vdisk file=H:win10.2go.x64.vhd detach vdisk exit
Step 28
Boot from the USB Drive and complete the Windows 10 VHD installation.
figure 5.
Step 29
This step is optional. To ensure that the VHD based Windows To Go operating system remains self contained and to reduce the risk of accidentally accessing or modifying the operating systems on Partition 2 and Partition 3 of the USB disk drive, remove the mount point. This needs to be completed from the booted Windows To Go system - e.g. start the Disk Management console, right-click on partition 2 on the USB disk drive and select "Change Drive Letter and Paths..." > click on the Remove button.
The following information has been copied from here - "...Windows To Go drives can be booted on multiple computers. When a Windows To Go workspace is first booted on a host computer it will detect all hardware on the computer and install any needed drivers. When the Windows To Go workspace is subsequently booted on that host computer it will be able to identify the host computer and load the correct set of drivers automatically..."
The first boot on a new computer can take a while due to the delay in detecting hardware and loading drivers, however on subsequent boots Windows To Go will not need to go through this process again.
The following screeshots show this hardware discovery process on a Windows 10 based Windows To Go -
figure 6.
figure 7.
figure 8.
As Windows To Go is officially supported on Enterprise editions of Windows 8/8.1/10 it can be activated via KMS (Key Management Server) - activating Window To Go for 180 days of roaming. Windows To Go can then be reactivated using a Key Management Server whenever required - resetting the activation period for another 180 days.
Although non-Enterprise editions of Windows can be used to create an unofficial Windows To Go, these installations are likely to be locked to the hardware they were activated on - reducing the roaming potential.
Any third party software that is locked to hardware activation is unlikely to work if using Windows To Go on a different device.
The screenshots below were taken from a running Windows To Go activated via KMS - note that Windows remains activated despite running on two different devices -
figure 9.
figure 10.
