Merge branch 'master' of https://github.com/Microsoft/win-cpub-itpro-docs into VSTS8867491

devices/surface-hub/device-reset-surface-hub.md

@@ -30,7 +30,7 @@ Initiating a reset will return the device to the last cumulative Windows update,
 -   Local admins on the device
 -   Configurations from MDM or the Settings app
 
-**To reset a Surface Hub**
+**To reset a Surface Hub from Settings**</br>
 1.	On your Surface Hub, open **Settings**. 
 
     ![Image showing Settings app for Surface Hub.](images/sh-settings.png)
@@ -43,8 +43,18 @@ Initiating a reset will return the device to the last cumulative Windows update,
 
     ![Image showing Reset device option in Settings app for Surface Hub.](images/sh-settings-reset-device.png) 
 
+**To reset a Surface Hub from Windows Recovery Environment**</br>
+On rare occasions, a Surface Hub may encounter an error while cleaning up user and app data at the end of a session. When this happens, the device will automatically reboot and try again. But if this operation fails repeatedly, the device will be automatically locked to protect user data. To unlock it, you must reset the device from [Windows Recovery Environment](https://technet.microsoft.com/en-us/library/cc765966(v=ws.10).aspx) (Windows RE).
+
+To reset a Surface Hub from Windows RE:
+
+1.  From the welcome screen, toggle the Surface Hub's power switch 3 times. Wait a few seconds between each toggle. See the [Surface Hub Site Readiness Guide](https://www.microsoft.com/surface/support/surface-hub/surface-hub-site-readiness-guide) for help with locating the power switch.
+2.  The device should automatically boot into Windows RE. Select **Advanced Repair**.
+3.  Select **Reset**.
+4.  If prompted, enter your device's BitLocker key.
+
 **Important Note**</br>
-Performing a device reset may take up to 6 hours. Do not interrupt the reset process. Interrupting the process will render the device inoperable, requiring warranty service to return to normal functionality.
+Performing a device reset may take up to 2 hours. Do not interrupt the reset process. Interrupting the process will render the device inoperable, requiring warranty service to return to normal functionality.
 
 After the reset, Surface Hub restarts the [first run program](first-run-program-surface-hub.md) again. 
 

windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md

@@ -16,7 +16,7 @@ author: brianlic-msft
 
 This topic provides a roadmap for planning and getting started on the Device Guard deployment process, with links to topics that provide additional detail. Planning for Device Guard deployment involves looking at both the end-user and the IT pro impact of your choices. Use the following steps to guide you.
 
-**Planning**
+## Planning
 
 1. **Review requirements, especially hardware requirements for VBS**. Review the virtualization-based security (VBS) features described in [How Device Guard features help protect against threats](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md#how-device-guard-features-help-protect-against-threats). Then you can assess your end-user systems to see how many support the VBS features you are interested in, as described in [Hardware, firmware, and software requirements for Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md#hardware-firmware-and-software-requirements-for-device-guard). 
 
@@ -33,7 +33,7 @@ This topic provides a roadmap for planning and getting started on the Device Gua
 
 4.  **Identify LOB applications that are currently unsigned**. Although requiring signed code (through code integrity policies) protects against many threats, your organization might use unsigned LOB applications, for which the process of signing might be difficult. You might also have applications that are signed, but you want to add a secondary signature to them. If so, identify these applications, because you will need to create a catalog file for them. For a basic description of catalog files, see the table in [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md). For more background information about catalog files, see [Reviewing your applications: application signing and catalog files](requirements-and-deployment-planning-guidelines-for-device-guard.md#reviewing-your-applications-application-signing-and-catalog-files).
 
-**Getting started on the deployment process**
+## Getting started on the deployment process
 
 1.  **Optionally, create a signing certificate for code integrity policies**. As you deploy code integrity policies, you might need to sign catalog files or code integrity policies internally. To do this, you will either need a publicly issued code signing certificate (that you purchase) or an internal CA. If you choose to use an internal CA, you will need to create a code signing certificate. For more information, see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
 

windows/manage/appv-application-publishing-and-client-interaction.md

@@ -500,7 +500,7 @@ App-V registry roaming falls into two scenarios, as shown in the following table
 <td align="left"><p>When a standard user launches an App-V application, both HKLM and HKCU for App-V applications are stored in the HKCU hive on the machine. This presents as two distinct paths:</p>
 <ul>
 <li><p>HKLM: HKCU\SOFTWARE\Classes\AppV\Client\Packages\\{PkgGUID}\REGISTRY\MACHINE\SOFTWARE</p></li>
-<li><p>HKCU: HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\REGISTRY\USER\{UserSID}\SOFTWARE</p></li>
+<li><p>HKCU: HKCU\SOFTWARE\Microsoft\AppV\Client\Packages\\{PkgGUID}\REGISTRY\USER\\{UserSID}\SOFTWARE</p></li>
 </ul>
 <p>The locations are enabled for roaming based on the operating system settings.</p></td>
 </tr>