deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-16 10:53:43 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

Update windows-to-go-frequently-asked-questions.yml

Browse Source 
Acro edits.
This commit is contained in:
Stephanie Savell
2023-04-03 13:04:28 -05:00
committed by GitHub
parent f587cb8ad3
commit 983e742c72
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
windows/deployment/planning/windows-to-go-frequently-asked-questions.yml
View File

@ -164,7 +164,7 @@ sections:
- question: |
Can the user self-provision Windows To Go?
answer: |
Yes, if the user has administrator permissions they can self-provision a Windows To Go drive using the Windows To Go Creator wizard which is included in Windows 10 Enterprise, Windows 10 Education and Windows 10 Professional. Additionally, Configuration Manager SP1 and later releases includes support for user self-provisioning of Windows To Go drives.
Yes, if the user has administrator permissions they can self-provision a Windows To Go drive using the Windows To Go Creator wizard which is included in Windows 10 Enterprise, Windows 10 Education and Windows 10 Professional. Additionally, Configuration Manager SP1 and later releases include support for user self-provisioning of Windows To Go drives.
- question: |
How can Windows To Go be managed in an organization?
@ -292,7 +292,7 @@ sections:
Windows To Go Creator and the recommended deployment steps for Windows To Go set SAN Policy 4 on Windows To Go drive. This policy prevents Windows from automatically mounting internal disk drives. That's why you can't see the internal hard drives of the host computer when you're booted into Windows To Go. This is done to prevent accidental data leakage between Windows To Go and the host system. This policy also prevents potential corruption on the host drives or data loss if the host operating system is in a hibernation state. If you really need to access the files on the internal hard drive, you can use diskmgmt.msc to mount the internal drive.
**Warning**
It is strongly recommended that you do not mount internal hard drives when booted into the Windows To Go workspace. If the internal drive contains a hibernated Windows 8 or later operating system, mounting the drive will lead to loss of hibernation state and therefor user state or any unsaved user data when the host operating system is booted. If the internal drive contains a hibernated Windows 7 or earlier operating system, mounting the drive will lead to corruption when the host operating system is booted.
It is strongly recommended that you do not mount internal hard drives when booted into the Windows To Go workspace. If the internal drive contains a hibernated Windows 8 or later operating system, mounting the drive will lead to loss of hibernation state and therefore user state or any unsaved user data when the host operating system is booted. If the internal drive contains a hibernated Windows 7 or earlier operating system, mounting the drive will lead to corruption when the host operating system is booted.
@ -324,7 +324,7 @@ sections:
- question: |
Do I need to activate Windows To Go every time I roam?
answer: |
No, Windows To Go requires volume activation; either using the [Key Management Service](/previous-versions/tn-archive/ff793434(v=technet.10)) (KMS) server in your organization or using [Active Directory](/previous-versions/windows/hh852637(v=win.10)) based volume activation. The Windows To Go workspace won't need to be reactivated every time you roam. KMS activates Windows on a local network, eliminating the need for individual computers to connect to Microsoft. To remain activated, KMS client computers must renew their activation by connecting to the KMS host on periodic basis. This typically occurs as soon as the user has access to the corporate network (either through a direct connection on-premises or a through remote connection using DirectAccess or a virtual private network connection), once activated the machine won't need to be activated again until the activation validity interval has passed. In a KMS configuration, the activation validity interval is 180 days.
No, Windows To Go requires volume activation; either using the [Key Management Service](/previous-versions/tn-archive/ff793434(v=technet.10)) (KMS) server in your organization or using [Active Directory](/previous-versions/windows/hh852637(v=win.10)) based volume activation. The Windows To Go workspace won't need to be reactivated every time you roam. KMS activates Windows on a local network, eliminating the need for individual computers to connect to Microsoft. To remain activated, KMS client computers must renew their activation by connecting to the KMS host on periodic basis. This typically occurs as soon as the user has access to the corporate network (either through a direct connection on-premises or through a remote connection using DirectAccess or a virtual private network connection), once activated the machine won't need to be activated again until the activation validity interval has passed. In a KMS configuration, the activation validity interval is 180 days.
- question: |
Can I use all Windows features on Windows To Go?
@ -433,7 +433,7 @@ sections:
answer: |
One of the challenges involved in moving the Windows To Go drive between PCs while seamlessly booting Windows with access to all of their applications and data is that for Windows to be fully functional, specific drivers need to be installed for the hardware in each machine that runs Windows. Windows 8 or later has a process called respecialize which will identify new drivers that need to be loaded for the new PC and disable drivers that aren't present on the new configuration. In general, this feature is reliable and efficient when roaming between PCs of widely varying hardware configurations.
In certain cases, third-party drivers for different hardware models or versions can reuse device ID's, driver file names, registry keys (or any other operating system constructs that don't support side-by-side storage) for similar hardware. For example, Touchpad drivers on different laptops often reuse the same device ID's, and video cards from the same manufacturer may often reuse service names. Windows handles these situations by marking the non-present device node with a flag that indicates the existing driver needs to be reinstalled before continuing to install the new driver.
In certain cases, third-party drivers for different hardware models or versions can reuse device IDs, driver file names, registry keys (or any other operating system constructs that don't support side-by-side storage) for similar hardware. For example, Touchpad drivers on different laptops often reuse the same device ID's, and video cards from the same manufacturer may often reuse service names. Windows handles these situations by marking the non-present device node with a flag that indicates the existing driver needs to be reinstalled before continuing to install the new driver.
This process will occur on any boot that a new driver is found and a driver conflict is detected. In some cases that will result in a respecialize progress message "Installing devices…" displaying every time that a Windows to Go drive is roamed between two PCs that require conflicting drivers.