mirror of
https://github.com/MicrosoftDocs/windows-itpro-docs.git
synced 2025-05-12 21:37:22 +00:00
Acrolinx fixes
This commit is contained in:
Alekhya Jupudi
parent
b6b1ba0aff
commit
c489de57b5
@ -13,11 +13,12 @@ ms.custom: seo-marvel-apr2020
|
||||
# Deploy Windows To Go in your organization
|
||||
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
|
||||
This topic helps you to deploy Windows To Go in your organization. Before you begin deployment, make sure that you have reviewed the topics [Windows To Go: feature overview](planning/windows-to-go-overview.md) and [Prepare your organization for Windows To Go](planning/prepare-your-organization-for-windows-to-go.md) to ensure that you have the correct hardware and are prepared to complete the deployment. You can then use the steps in this topic to start your Windows To Go deployment.
|
||||
This topic helps you to deploy Windows To Go in your organization. Before you begin deployment, make sure that you've reviewed the topics [Windows To Go: feature overview](planning/windows-to-go-overview.md) and [Prepare your organization for Windows To Go](planning/prepare-your-organization-for-windows-to-go.md) to ensure that you have the correct hardware and are prepared to complete the deployment. You can then use the steps in this topic to start your Windows To Go deployment.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Windows To Go is removed in Windows 10, version 2004 and later operating systems. The feature does not support feature updates and therefore does not enable you to stay current. It also requires a specific type of USB that is no longer supported by many OEMs.
|
||||
@ -26,7 +27,7 @@ This topic helps you to deploy Windows To Go in your organization. Before you be
|
||||
|
||||
The following is a list of items that you should be aware of before you start the deployment process:
|
||||
|
||||
* Only use recommended USB drives for Windows To Go. Use of other drives is not supported. Check the list at [Windows To Go: feature overview](planning/windows-to-go-overview.md) for the latest USB drives certified for use as Windows To Go drives.
|
||||
* Only use recommended USB drives for Windows To Go. Use of other drives isn't supported. Check the list at [Windows To Go: feature overview](planning/windows-to-go-overview.md) for the latest USB drives certified for use as Windows To Go drives.
|
||||
|
||||
* After you provision a new workspace, always eject a Windows To Go drive using the **Safely Remove Hardware and Eject Media** control that can be found in the notification area or in Windows Explorer. Removing the drive from the USB port without ejecting it first can cause the drive to become corrupted.
|
||||
|
||||
@ -34,20 +35,20 @@ The following is a list of items that you should be aware of before you start th
|
||||
|
||||
* Configuration Manager SP1 and later includes support for user self-provisioning of Windows To Go drives. You can download Configuration Manager for evaluation from the [Microsoft TechNet Evaluation Center](https://go.microsoft.com/fwlink/p/?LinkId=618746). For more information on this deployment option, see [How to Provision Windows To Go in Configuration Manager](/previous-versions/system-center/system-center-2012-R2/jj651035(v=technet.10)).
|
||||
|
||||
* If you are planning on using a USB drive duplicator to duplicate Windows To Go drives, do not configure offline domain join or BitLocker on the drive.
|
||||
* If you're planning on using a USB drive duplicator to duplicate Windows To Go drives, don't configure offline domain join or BitLocker on the drive.
|
||||
|
||||
## Basic deployment steps
|
||||
|
||||
Unless you are using a customized operating system image, your initial Windows To Go workspace will not be domain joined and will not contain applications. This is exactly like a new installation of Windows on a desktop or laptop computer. When planning your deployment, you should develop methods to join Windows to Go drives to the domain and install the standard applications that users in your organization require. These methods probably will be similar to the ones used for setting up desktop and laptop computers with domain privileges and applications. This section describes the instructions for creating the correct disk layout on the USB drive, applying the operating system image and the core Windows To Go specific configurations to the drive. The following steps are used in both small-scale and large-scale Windows To Go deployment scenarios.
|
||||
Unless you're using a customized operating system image, your initial Windows To Go workspace won't be domain joined and won't contain applications. This is exactly like a new installation of Windows on a desktop or laptop computer. When planning your deployment, you should develop methods to join Windows to Go drives to the domain and install the standard applications that users in your organization require. These methods probably will be similar to the ones used for setting up desktop and laptop computers with domain privileges and applications. This section describes the instructions for creating the correct disk layout on the USB drive, applying the operating system image and the core Windows To Go specific configurations to the drive. The following steps are used in both small-scale and large-scale Windows To Go deployment scenarios.
|
||||
|
||||
Completing these steps will give you a generic Windows To Go drive that can be distributed to your users and then customized for their usage as needed. This drive is also appropriate for use with USB drive duplicators. Your specific deployment scenarios will involve more than just these basic steps but these additional deployment considerations are similar to traditional PC deployment and can be incorporated into your Windows To Go deployment plan. For additional information, see [Windows Deployment Options](/previous-versions/windows/it-pro/windows-8.1-and-8/hh825230(v=win.10)).
|
||||
Completing these steps will give you a generic Windows To Go drive that can be distributed to your users and then customized for their usage as needed. This drive is also appropriate for use with USB drive duplicators. Your specific deployment scenarios will involve more than just these basic steps but these additional deployment considerations are similar to traditional PC deployment and can be incorporated into your Windows To Go deployment plan. For more information, see [Windows Deployment Options](/previous-versions/windows/it-pro/windows-8.1-and-8/hh825230(v=win.10)).
|
||||
|
||||
>[!WARNING]
|
||||
>If you plan to use the generic Windows To Go drive as the master drive in a USB duplicator, the drive should not be booted. If the drive has been booted inadvertently it should be reprovisioned prior to duplication.
|
||||
|
||||
### Create the Windows To Go workspace
|
||||
|
||||
In this step we are creating the operating system image that will be used on the Windows To Go drives. You can use the Windows To Go Creator Wizard or you can [do this manually](/previous-versions/windows/it-pro/windows-8.1-and-8/jj721578(v=ws.11)) using a combination of Windows PowerShell and command-line tools.
|
||||
In this step we're creating the operating system image that will be used on the Windows To Go drives. You can use the Windows To Go Creator Wizard or you can [do this manually](/previous-versions/windows/it-pro/windows-8.1-and-8/jj721578(v=ws.11)) using a combination of Windows PowerShell and command-line tools.
|
||||
|
||||
>[!WARNING]
|
||||
>The preferred method to create a single Windows To Go drive is to use the Windows To Go Creator Wizard included in Windows 10 Enterprise and Windows 10 Education.
|
||||
@ -69,7 +70,7 @@ In this step we are creating the operating system image that will be used on the
|
||||
|
||||
6. On the **Choose a Windows image** page, click **Add Search Location** and then navigate to the .wim file location and click select folder. The wizard will display the installable images present in the folder; select the Windows 10 Enterprise or Windows 10 Education image you wish to use and then click **Next**.
|
||||
|
||||
7. (Optional) On the **Set a BitLocker password (optional)** page, you can select **Use BitLocker with my Windows To Go Workspace** to encrypt your Windows To Go drive. If you do not wish to encrypt the drive at this time, click **Skip**. If you decide you want to add BitLocker protection later, see [Enable BitLocker protection for your Windows To Go drive](/previous-versions/windows/it-pro/windows-8.1-and-8/jj721578(v=ws.11)) for instructions.
|
||||
7. (Optional) On the **Set a BitLocker password (optional)** page, you can select **Use BitLocker with my Windows To Go Workspace** to encrypt your Windows To Go drive. If you don't wish to encrypt the drive at this time, click **Skip**. If you decide you want to add BitLocker protection later, see [Enable BitLocker protection for your Windows To Go drive](/previous-versions/windows/it-pro/windows-8.1-and-8/jj721578(v=ws.11)) for instructions.
|
||||
r
|
||||
|
||||
>[!WARNING]
|
||||
@ -77,7 +78,7 @@ r
|
||||
|
||||
If you choose to encrypt the Windows To Go drive now:
|
||||
|
||||
- Type a password that is at least eight characters long and conforms to your organizations password complexity policy. This password will be provided before the operating system is started so any characters you use must be able to be interpreted by the firmware. Some firmware does not support non-ASCII characters.
|
||||
- Type a password that is at least eight characters long and conforms to your organizations password complexity policy. This password will be provided before the operating system is started so any characters you use must be able to be interpreted by the firmware. Some firmware doesn't support non-ASCII characters.
|
||||
|
||||
|
||||
~~~
|
||||
@ -100,7 +101,7 @@ The following Windows PowerShell cmdlet or cmdlets perform the same function as
|
||||
|
||||
1. Using Cortana, search for **powershell**, right-click **Windows PowerShell**, and then select **Run as administrator**.
|
||||
|
||||
2. In the Windows PowerShell session type the following commands to partition a master boot record (MBR) disk for use with a FAT32 system partition and an NTFS-formatted operating system partition. This disk layout can support computers that use either UEFI or BIOS firmware:
|
||||
2. In the Windows PowerShell session type, the following commands to partition a master boot record (MBR) disk for use with a FAT32 system partition and an NTFS-formatted operating system partition. This disk layout can support computers that use either UEFI or BIOS firmware:
|
||||
|
||||
```
|
||||
# The following command will set $Disk to all USB drives with >20 GB of storage
|
||||
|
||||
@ -12,7 +12,6 @@ ms.custom: seo-marvel-apr2020
|
||||
|
||||
# Deployment considerations for Windows To Go
|
||||
|
||||
|
||||
**Applies to**
|
||||
|
||||
- Windows 10
|
||||
@ -42,7 +41,7 @@ The following diagrams illustrate the two different methods you could use to pro
|
||||
|
||||
|
||||
|
||||
When a Windows To Go workspace is first used at the workplace, the Windows To Go workspace can be joined to the domain through the normal procedures that occur when a new computer is introduced. It obtains a lease, applicable policies are applied and set, and user account tokens are placed appropriately. BitLocker protection can be applied and the BitLocker recovery key automatically stored in Active Directory Domain Services. The user can access network resources to install software and get access to data sources. When the workspace is subsequently booted at a different location either on or off premises, the configuration required for it to connect back to the work network using either DirectAccess or a virtual private network connection can be configured. It is not necessary to configure the workspace for offline domain join. DirectAccess can make connecting to organizational resources easier, but is not required.
|
||||
When a Windows To Go workspace is first used at the workplace, the Windows To Go workspace can be joined to the domain through the normal procedures that occur when a new computer is introduced. It obtains a lease, applicable policies are applied and set, and user account tokens are placed appropriately. BitLocker protection can be applied and the BitLocker recovery key automatically stored in Active Directory Domain Services. The user can access network resources to install software and get access to data sources. When the workspace is subsequently booted at a different location either on or off premises, the configuration required for it to connect back to the work network using either DirectAccess or a virtual private network connection can be configured. It isn't necessary to configure the workspace for offline domain join. DirectAccess can make connecting to organizational resources easier, but isn't required.
|
||||
|
||||
|
||||
|
||||
@ -51,7 +50,7 @@ When the Windows To Go workspace is going to be used first on an off-premises co
|
||||
> [!TIP]
|
||||
> Applying BitLocker Drive Encryption to the drives before provisioning is a much faster process than encrypting the drives after data has already been stored on them due to a new feature called used-disk space only encryption. For more information, see [What's New in BitLocker](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn306081(v=ws.11)).
|
||||
|
||||
DirectAccess can be used to ensure that the user can log in with their domain credentials without needing a local account. For instructions on setting up a DirectAccess solution, for a small pilot deployment see [Deploy a Single Remote Access Server using the Getting Started Wizard](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831520(v=ws.11)) for a larger scale deployment, see [Deploy Remote Access in an Enterprise](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj134200(v=ws.11)). If you do not want to use DirectAccess as an alternative user could log on using a local user account on the Windows To Go workspace and then use a virtual private network for remote access to your organizational network.
|
||||
DirectAccess can be used to ensure that the user can log in with their domain credentials without needing a local account. For instructions on setting up a DirectAccess solution, for a small pilot deployment see [Deploy a Single Remote Access Server using the Getting Started Wizard](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831520(v=ws.11)) for a larger scale deployment, see [Deploy Remote Access in an Enterprise](/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/jj134200(v=ws.11)). If you don't want to use DirectAccess as an alternative user could log on using a local user account on the Windows To Go workspace and then use a virtual private network for remote access to your organizational network.
|
||||
|
||||
### <a href="" id="wtg-imagedep"></a>Image deployment and drive provisioning considerations
|
||||
|
||||
@ -59,18 +58,18 @@ The Image Deployment process can be accomplished either by a centralized IT proc
|
||||
|
||||
|
||||
|
||||
The simplest way to provision a Windows To Go drive is to use the Windows To Go Creator. After a single Windows To Go workspace has been created, it can be duplicated as many times as necessary using widely available USB duplicator products as long as the device has not been booted. After the Windows To Go drive is initialized, it should not be duplicated. Alternatively, Windows To Go Workspace Creator can be run multiple times to create multiple Windows To Go drives.
|
||||
The simplest way to provision a Windows To Go drive is to use the Windows To Go Creator. After a single Windows To Go workspace has been created, it can be duplicated as many times as necessary using widely available USB duplicator products as long as the device hasn't been booted. After the Windows To Go drive is initialized, it shouldn't be duplicated. Alternatively, Windows To Go Workspace Creator can be run multiple times to create multiple Windows To Go drives.
|
||||
|
||||
> [!TIP]
|
||||
> When you create your Windows To Go image use sysprep /generalize, just as you do when you deploy Windows 10 to a standard PC. In fact, if appropriate, use the same image for both deployments.
|
||||
|
||||
**Driver considerations**
|
||||
|
||||
Windows includes most of the drivers that you will need to support a wide variety of host computers. However, you will occasionally need to download drivers from Windows Update to take advantage of the full functionality of a device. If you are using Windows To Go on a set of known host computers, you can add any additional drivers to the image used on Windows To Go to make Windows To Go drives more quickly usable by your employees. Especially ensure that network drivers are available so that the user can connect to Windows Update to get additional drivers if necessary.
|
||||
Windows includes most of the drivers that you'll need to support a wide variety of host computers. However, you'll occasionally need to download drivers from Windows Update to take advantage of the full functionality of a device. If you're using Windows To Go on a set of known host computers, you can add any more drivers to the image used on Windows To Go to make Windows To Go drives more quickly usable by your employees. Especially ensure that network drivers are available so that the user can connect to Windows Update to get more drivers if necessary.
|
||||
|
||||
Wi-Fi network adapter drivers are one of the most important drivers to make sure that you include in your standard image so that users can easily connect to the internet for any additional updates. IT administrators that are attempting to build Windows 10 images for use with Windows To Go should consider adding additional Wi-Fi drivers to their image to ensure that their users have the best chance of still having basic network connectivity when roaming between systems.
|
||||
|
||||
The following list of commonly used Wi-Fi network adapters that are not supported by the default drivers provided with Windows 10 is provided to help you ascertain whether or not you need to add drivers to your image.
|
||||
The following list of commonly used Wi-Fi network adapters that aren't supported by the default drivers provided with Windows 10 is provided to help you ascertain whether or not you need to add drivers to your image.
|
||||
|
||||
|Vendor name|Product description|HWID|Windows Update availability|
|
||||
|--- |--- |--- |--- |
|
||||
@ -94,11 +93,11 @@ The following list of commonly used Wi-Fi network adapters that are not supporte
|
||||
|Ralink|Wireless LAN Card V1|pci\ven_1814&dev_0302&subsys_3a711186&rev_00|[32-bit driver](https://go.microsoft.com/fwlink/p/?LinkId=619097)<p>[64-bit driver](https://go.microsoft.com/fwlink/p/?LinkId=619098)|
|
||||
|Ralink|D-Link AirPlus G DWL-G510 Wireless PCI Adapter(rev.C)|pci\ven_1814&dev_0302&subsys_3c091186&rev_00|[32-bit driver](https://go.microsoft.com/fwlink/p/?LinkId=619099)<p>[64-bit driver](https://go.microsoft.com/fwlink/p/?LinkId=619100)|
|
||||
|
||||
IT administrators that want to target Windows To Go images for specific systems should test their images to ensure that the necessary system drivers are in the image, especially for critical functionality like Wi-Fi that is not supported by class drivers. Some consumer devices require OEM-specific driver packages, which may not be available on Windows Update. For more information on how to add a driver to a Windows Image, please refer to the [Basic Windows Deployment Step-by-Step Guide](/previous-versions/windows/it-pro/windows-8.1-and-8/hh825212(v=win.10)).
|
||||
IT administrators that want to target Windows To Go images for specific systems should test their images to ensure that the necessary system drivers are in the image, especially for critical functionality like Wi-Fi that isn't supported by class drivers. Some consumer devices require OEM-specific driver packages, which may not be available on Windows Update. For more information on how to add a driver to a Windows Image, please refer to the [Basic Windows Deployment Step-by-Step Guide](/previous-versions/windows/it-pro/windows-8.1-and-8/hh825212(v=win.10)).
|
||||
|
||||
### <a href="" id="wtg-appinstall"></a>Application installation and domain join
|
||||
|
||||
Unless you are using a customized Windows image that includes unattended installation settings, the initial Windows To Go workspace will not be domain joined and will not contain applications. This is exactly like a new installation of Windows on a desktop or laptop computer. When planning your deployment, you should develop methods to join Windows to Go drives to the domain and install the standard applications that users in your organization require. These methods probably will be similar to the ones used for setting up desktop and laptop computers with domain privileges and applications
|
||||
Unless you're using a customized Windows image that includes unattended installation settings, the initial Windows To Go workspace won't be domain joined and won't contain applications. This is exactly like a new installation of Windows on a desktop or laptop computer. When planning your deployment, you should develop methods to join Windows to Go drives to the domain and install the standard applications that users in your organization require. These methods probably will be similar to the ones used for setting up desktop and laptop computers with domain privileges and applications
|
||||
|
||||
### <a href="" id="bkmk-wtggp"></a>Management of Windows To Go using Group Policy
|
||||
|
||||
@ -110,20 +109,20 @@ The use of the Store on Windows To Go workspaces that are running Windows 8 can
|
||||
|
||||
- **Allow hibernate (S4) when started from a Windows To Go workspace**
|
||||
|
||||
This policy setting specifies whether the PC can use the hibernation sleep state (S4) when started from a Windows To Go workspace. By default, hibernation is disabled when using Windows To Go workspace, so enabling this setting explicitly turns this ability back on. When a computer enters hibernation, the contents of memory are written to disk. When the disk is resumed, it is important that the hardware attached to the system, as well as the disk itself, are unchanged. This is inherently incompatible with roaming between PC hosts. Hibernation should only be used when the Windows To Go workspace is not being used to roam between host PCs.
|
||||
This policy setting specifies whether the PC can use the hibernation sleep state (S4) when started from a Windows To Go workspace. By default, hibernation is disabled when using Windows To Go workspace, so enabling this setting explicitly turns this ability back on. When a computer enters hibernation, the contents of memory are written to disk. When the disk is resumed, it's important that the hardware attached to the system, and the disk itself, are unchanged. This is inherently incompatible with roaming between PC hosts. Hibernation should only be used when the Windows To Go workspace isn't being used to roam between host PCs.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> For the host-PC to resume correctly when hibernation is enabled the Windows To Go workspace must continue to use the same USB port.
|
||||
|
||||
- **Disallow standby sleep states (S1-S3) when starting from a Windows To Go workspace**
|
||||
|
||||
This policy setting specifies whether the PC can use standby sleep states (S1–S3) when started from a Windows To Go workspace. The Sleep state also presents a unique challenge to Windows To Go users. When a computer goes to sleep, it appears as if it is shut down. It could be very easy for a user to think that a Windows To Go workspace in sleep mode was actually shut down and they could remove the Windows To Go drive and take it home. Removing the Windows To Go drive in this scenario is equivalent to an unclean shutdown, which may result in the loss of unsaved user data or the corruption on the drive. Moreover, if the user now boots the drive on another PC and brings it back to the first PC, which still happens to be in the sleep state, it will lead to an arbitrary crash and eventually corruption of the drive and result in the workspace becoming unusable. If you enable this policy setting, the Windows To Go workspace cannot use the standby states to cause the PC to enter sleep mode. If you disable or do not configure this policy setting, the Windows To Go workspace can place the PC in sleep mode.
|
||||
This policy setting specifies whether the PC can use standby sleep states (S1–S3) when started from a Windows To Go workspace. The Sleep state also presents a unique challenge to Windows To Go users. When a computer goes to sleep, it appears as if it's shut down. It could be easy for a user to think that a Windows To Go workspace in sleep mode was actually shut down and they could remove the Windows To Go drive and take it home. Removing the Windows To Go drive in this scenario is equivalent to an unclean shutdown, which may result in the loss of unsaved user data or the corruption on the drive. Moreover, if the user now boots the drive on another PC and brings it back to the first PC, which still happens to be in the sleep state, it will lead to an arbitrary crash and eventually corruption of the drive and result in the workspace becoming unusable. If you enable this policy setting, the Windows To Go workspace can't use the standby states to cause the PC to enter sleep mode. If you disable or don't configure this policy setting, the Windows To Go workspace can place the PC in sleep mode.
|
||||
|
||||
**Settings for host PCs**
|
||||
|
||||
- **Windows To Go Default Startup Options**
|
||||
|
||||
This policy setting controls whether the host computer will boot to Windows To Go if a USB device containing a Windows To Go workspace is connected, and controls whether users can make changes using the **Windows To Go Startup Options** settings dialog. If you enable this policy setting, booting to Windows To Go when a USB device is connected will be enabled and users will not be able to make changes using the **Windows To Go Startup Options** settings dialog. If you disable this policy setting, booting to Windows To Go when a USB device is connected will not be enabled unless a user configures the option manually in the firmware. If you do not configure this policy setting, users who are members of the local Administrators group can enable or disable booting from USB using the **Windows To Go Startup Options** settings dialog.
|
||||
This policy setting controls whether the host computer will boot to Windows To Go if a USB device containing a Windows To Go workspace is connected, and controls whether users can make changes using the **Windows To Go Startup Options** settings dialog. If you enable this policy setting, booting to Windows To Go when a USB device is connected will be enabled and users won't be able to make changes using the **Windows To Go Startup Options** settings dialog. If you disable this policy setting, booting to Windows To Go when a USB device is connected won't be enabled unless a user configures the option manually in the firmware. If you don't configure this policy setting, users who are members of the local Administrators group can enable or disable booting from USB using the **Windows To Go Startup Options** settings dialog.
|
||||
|
||||
> [!IMPORTANT]
|
||||
> Enabling this policy setting will cause PCs running Windows to attempt to boot from any USB device that is inserted into the PC before it is started.
|
||||
@ -135,7 +134,7 @@ The biggest hurdle for a user wanting to use Windows To Go is configuring their
|
||||
> [!NOTE]
|
||||
> Enabling a system to always boot from USB first has implications that you should consider. For example, a USB device that includes malware could be booted inadvertently to compromise the system, or multiple USB drives could be plugged in to cause a boot conflict. For this reason, the Windows To Go startup options are disabled by default. In addition, administrator privileges are required to configure Windows To Go startup options.
|
||||
|
||||
If you are going to be using a Windows 7 computer as a host-PC, see the wiki article [Tips for configuring your BIOS settings to work with Windows To Go](https://go.microsoft.com/fwlink/p/?LinkID=618951).
|
||||
If you're going to be using a Windows 7 computer as a host-PC, see the wiki article [Tips for configuring your BIOS settings to work with Windows To Go](https://go.microsoft.com/fwlink/p/?LinkID=618951).
|
||||
|
||||
### <a href="" id="stg-firmware"></a>Roaming between different firmware types
|
||||
|
||||
@ -143,9 +142,9 @@ Windows supports two types of PC firmware: Unified Extensible Firmware Interface
|
||||
|
||||
|
||||
|
||||
This presented a unique challenge for Windows To Go because the firmware type is not easily determined by end users—a UEFI computer looks just like a legacy BIOS computer and Windows To Go must boot on both types of firmware.
|
||||
This presented a unique challenge for Windows To Go because the firmware type isn't easily determined by end users—a UEFI computer looks just like a legacy BIOS computer and Windows To Go must boot on both types of firmware.
|
||||
|
||||
To enable booting Windows To Go on both types of firmware, a new disk layout is provided for Windows 8 or later that contains both sets of boot components on a FAT32 system partition and a new command-line option was added to bcdboot.exe to support this configuration. The **/f** option is used with the **bcdboot /s** command to specify the firmware type of the target system partition by appending either **UEFI**, **BIOS** or **ALL**. When creating Windows To Go drives manually you must use the **ALL** parameter to provide the Windows To Go drive the ability to boot on both types of firmware. For example, on volume H: (your Windows To Go USB drive letter), you would use the command **bcdboot C:\\windows /s H: /f ALL**. The following diagram illustrates the disk layout that results from that command:
|
||||
To enable booting Windows To Go on both types of firmware, a new disk layout is provided for Windows 8 or later that contains both sets of boot components on a FAT32 system partition and a new command-line option was added to bcdboot.exe to support this configuration. The **/f** option is used with the **bcdboot /s** command to specify the firmware type of the target system partition by appending either **UEFI**, **BIOS** or **ALL**. When creating Windows To Go drives manually, you must use the **ALL** parameter to provide the Windows To Go drive the ability to boot on both types of firmware. For example, on volume H: (your Windows To Go USB drive letter), you would use the command **bcdboot C:\\windows /s H: /f ALL**. The following diagram illustrates the disk layout that results from that command:
|
||||
|
||||
|
||||
|
||||
@ -153,7 +152,7 @@ This is the only supported disk configuration for Windows To Go. With this disk
|
||||
|
||||
### <a href="" id="wtg-startup"></a>Configure Windows To Go startup options
|
||||
|
||||
Windows To Go Startup Options is a setting available on Windows 10-based PCs that enables the computer to be booted from a USB without manually changing the firmware settings of the PC. To configure Windows To Go Startup Options you must have administrative rights on the computer and the **Windows To Go Default Startup Options** Group Policy setting must not be configured.
|
||||
Windows To Go Startup Options is a setting available on Windows 10-based PCs that enables the computer to be booted from a USB without manually changing the firmware settings of the PC. To configure Windows To Go Startup Options, you must have administrative rights on the computer and the **Windows To Go Default Startup Options** Group Policy setting must not be configured.
|
||||
|
||||
**To configure Windows To Go startup options**
|
||||
|
||||
@ -170,7 +169,7 @@ Windows To Go Startup Options is a setting available on Windows 10-based PCs tha
|
||||
|
||||
### <a href="" id="wtg-changefirmware"></a>Change firmware settings
|
||||
|
||||
If you choose to not use the Windows To Go startup options or are using a PC running Windows 7 as your host computer you will need to manually configure the firmware settings. The process used to accomplish this will depend on the firmware type and manufacturer. If your host computer is protected by BitLocker and running Windows 7 you should suspend BitLocker before making the change to the firmware settings. After the firmware settings have been successfully reconfigured, resume BitLocker protection. If you do not suspend BitLocker first, BitLocker will assume that the computer has been tampered with and will boot into BitLocker recovery mode.
|
||||
If you choose to not use the Windows To Go startup options or are using a PC running Windows 7 as your host computer, you'll need to manually configure the firmware settings. The process used to accomplish this will depend on the firmware type and manufacturer. If your host computer is protected by BitLocker and running Windows 7, you should suspend BitLocker before making the change to the firmware settings. After the firmware settings have been successfully reconfigured, resume BitLocker protection. If you don't suspend BitLocker first, BitLocker will assume that the computer has been tampered with and will boot into BitLocker recovery mode.
|
||||
|
||||
## Related topics
|
||||
|
||||
|
||||
@ -12,6 +12,7 @@ ms.topic: article
|
||||
|
||||
# WaaSDeploymentStatus
|
||||
|
||||
|
||||
WaaSDeploymentStatus records track a specific update's installation progress on a specific device. Multiple WaaSDeploymentStatus records can exist simultaneously for a given device, as each record is specific to a given update and its type. For example, a device can have both a WaaSDeploymentStatus tracking a Windows Feature Update, and one tracking a Windows Quality Update, at the same time.
|
||||
|
||||
|Field |Type |Example |Description |
|
||||
@ -19,10 +20,10 @@ WaaSDeploymentStatus records track a specific update's installation progress on
|
||||
|**Computer** |[string](/azure/kusto/query/scalar-data-types/string) |`JohnPC-Contoso` |User or Organization-provided device name. If this appears as '#', then Device Name may not be sent through telemetry. To enable Device Name to be sent with telemetry, see [Enroll devices in Update Compliance](update-compliance-get-started.md#enroll-devices-in-update-compliance). |
|
||||
|**ComputerID** |[string](/azure/kusto/query/scalar-data-types/string) |`g:6755412281299915` |Microsoft Global Device Identifier. This is an internal identifier used by Microsoft. A connection to the end-user managed service account is required for this identifier to be populated; no device data will be present in Update Compliance without this identifier. |
|
||||
|**DeferralDays** |[int](/azure/kusto/query/scalar-data-types/int) |`0` |The deferral policy for this content type or `UpdateCategory` (Windows `Feature` or `Quality`). |
|
||||
|**DeploymentError** |[string](/azure/kusto/query/scalar-data-types/string) |`Disk Error` |A readable string describing the error, if any. If empty, there is either no string matching the error or there is no error. |
|
||||
|**DeploymentErrorCode** |[int](/azure/kusto/query/scalar-data-types/int) |`8003001E` |Microsoft internal error code for the error, if any. If empty, there is either no error or there is *no error code*, meaning that the issue raised does not correspond to an error, but some inferred issue. |
|
||||
|**DeploymentStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Failed` |The high-level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Canceled**: The update was canceled.<li> **Blocked**: There is a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update.<li> **Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that have not sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.|
|
||||
|**DetailedStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Reboot required` |A detailed status for the installation of this update on this device. Possible values are:<br><li> **Not Started**: Update hasn't started because the device is not targeting the latest 2 builds<li> **Update deferred**: When a device's Windows Update for Business policy dictates the update is deferred.<li> **Update paused**: The device's Windows Update for Business policy dictates the update is paused from being offered.<li> **Update offered**: The device has been offered the update, but has not begun downloading it.<li> **Pre-Download tasks passed**: The device has finished all necessary tasks prior to downloading the update.<li> **Compatibility hold**: The device has been placed under a *compatibility hold* to ensure a smooth feature update experience and will not resume the update until the hold has been cleared. For more information, see [Feature Update Status report](update-compliance-feature-update-status.md#safeguard-holds).<li> **Download started**: The update has begun downloading on the device.<li> **Download Succeeded**: The update has successfully completed downloading. <li> **Pre-Install Tasks Passed**: Tasks that must be completed prior to installing the update have been completed.<li> **Install Started**: Installation of the update has begun.<li> **Reboot Required**: The device has finished installing the update, and a reboot is required before the update can be completed.<li> **Reboot Pending**: The device has a scheduled reboot to apply the update.<li> **Reboot Initiated**: The scheduled reboot has been initiated.<li> **Commit**: Changes are being committed post-reboot. This is another step of the installation process.<li> **Update Completed**: The update has successfully installed.|
|
||||
|**DeploymentError** |[string](/azure/kusto/query/scalar-data-types/string) |`Disk Error` |A readable string describing the error, if any. If empty, there's either no string matching the error or there's no error. |
|
||||
|**DeploymentErrorCode** |[int](/azure/kusto/query/scalar-data-types/int) |`8003001E` |Microsoft internal error code for the error, if any. If empty, there's either no error or there's *no error code*, meaning that the issue raised doesn't correspond to an error, but some inferred issue. |
|
||||
|**DeploymentStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Failed` |The high-level status of installing this update on this device. Possible values are:<br><li> **Update completed**: Device has completed the update installation.<li> **In Progress**: Device is in one of the various stages of installing an update, detailed in `DetailedStatus`.<li> **Deferred**: A device's deferral policy is preventing the update from being offered by Windows Update.<li> **Canceled**: The update was canceled.<li> **Blocked**: There's a hard block on the update being completed. This could be that another update must be completed before this one, or some other task is blocking the installation of the update.<li> **Unknown**: Update Compliance generated WaaSDeploymentStatus records for devices as soon as it detects an update newer than the one installed on the device. Devices that haven't sent any deployment data for that update will have the status `Unknown`.<li> **Update paused**: Devices are paused via Windows Update for Business Pause policies, preventing the update from being offered by Windows Update. <li> **Failed**: Device encountered a failure in the update process, preventing it from installing the update. This may result in an automatic retry in the case of Windows Update, unless the `DeploymentError` indicates the issue requires action before the update can continue.|
|
||||
|**DetailedStatus** |[string](/azure/kusto/query/scalar-data-types/string) |`Reboot required` |A detailed status for the installation of this update on this device. Possible values are:<br><li> **Not Started**: Update hasn't started because the device isn't targeting the latest 2 builds<li> **Update deferred**: When a device's Windows Update for Business policy dictates the update is deferred.<li> **Update paused**: The device's Windows Update for Business policy dictates the update is paused from being offered.<li> **Update offered**: The device has been offered the update, but hasn't begun downloading it.<li> **Pre-Download tasks passed**: The device has finished all necessary tasks prior to downloading the update.<li> **Compatibility hold**: The device has been placed under a *compatibility hold* to ensure a smooth feature update experience and won't resume the update until the hold has been cleared. For more information, see [Feature Update Status report](update-compliance-feature-update-status.md#safeguard-holds).<li> **Download started**: The update has begun downloading on the device.<li> **Download Succeeded**: The update has successfully completed downloading. <li> **Pre-Install Tasks Passed**: Tasks that must be completed prior to installing the update have been completed.<li> **Install Started**: Installation of the update has begun.<li> **Reboot Required**: The device has finished installing the update, and a reboot is required before the update can be completed.<li> **Reboot Pending**: The device has a scheduled reboot to apply the update.<li> **Reboot Initiated**: The scheduled reboot has been initiated.<li> **Commit**: Changes are being committed post-reboot. This is another step of the installation process.<li> **Update Completed**: The update has successfully installed.|
|
||||
|**ExpectedInstallDate** |[datetime](/azure/kusto/query/scalar-data-types/datetime)|`3/28/2020, 1:00:01.318 PM`|Rather than the expected date this update will be installed, this should be interpreted as the minimum date Windows Update will make the update available for the device. This takes into account Deferrals. |
|
||||
|**LastScan** |[datetime](/azure/kusto/query/scalar-data-types/datetime)|`3/22/2020, 1:00:01.318 PM`|The last point in time that this device sent Update Session data. |
|
||||
|**OriginBuild** |[string](/azure/kusto/query/scalar-data-types/string) |`18363.719` |The build originally installed on the device when this Update Session began. |
|
||||
@ -30,7 +31,7 @@ WaaSDeploymentStatus records track a specific update's installation progress on
|
||||
|**OSRevisionNumber** |[int](/azure/kusto/query/scalar-data-types/int) |`719` |The revision of the OSBuild installed on the device. |
|
||||
|**OSServicingBranch** |[string](/azure/kusto/query/scalar-data-types/string) |`Semi-Annual` |The Servicing Branch or [Servicing Channel](./waas-overview.md#servicing-channels) the device is on. Dictates which Windows updates the device receives and the cadence of those updates. |
|
||||
|**OSVersion** |[string](/azure/kusto/query/scalar-data-types/string) |`1909` |The version of Windows 10. This typically is of the format of the year of the version's release, following the month. In this example, `1909` corresponds to 2019-09 (September). This maps to the `Major` portion of OSBuild. |
|
||||
|**PauseState** |[string](/azure/kusto/query/scalar-data-types/string) |`NotConfigured` |The on-client Windows Update for Business Pause state. Reflects whether or not a device has paused Feature Updates.<br><li> **Expired**: The pause period has expired.<li> **NotConfigured**: Pause is not configured.<li> **Paused**: The device was last reported to be pausing this content type.<li> **NotPaused**: The device was last reported to not have any pause on this content type. |
|
||||
|**PauseState** |[string](/azure/kusto/query/scalar-data-types/string) |`NotConfigured` |The on-client Windows Update for Business Pause state. Reflects whether or not a device has paused Feature Updates.<br><li> **Expired**: The pause period has expired.<li> **NotConfigured**: Pause isn't configured.<li> **Paused**: The device was last reported to be pausing this content type.<li> **NotPaused**: The device was last reported to not have any pause on this content type. |
|
||||
|**RecommendedAction** |[string](/azure/kusto/query/scalar-data-types/string) | |The recommended action to take in the event this device needs attention, if any. |
|
||||
|**ReleaseName** |[string](/azure/kusto/query/scalar-data-types/string) |`KB4551762` |The KB Article corresponding to the TargetOSRevision, if any. |
|
||||
|**TargetBuild** |[string](/azure/kusto/query/scalar-data-types/string) |`18363.720` |The target OSBuild, the update being installed or considered as part of this WaaSDeploymentStatus record. |
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user