Merge remote-tracking branch 'refs/remotes/origin/master' into 8442312-app-v

devices/surface-hub/set-up-your-surface-hub.md

@@ -8,7 +8,7 @@ ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: surfacehub
 author: TrudyHa
-localizationpriority: mediumh
+localizationpriority: medium
 ---
 
 # Set up Microsoft Surface Hub

windows/keep-secure/deploy-device-guard-enable-virtualization-based-security.md

@@ -14,13 +14,15 @@ author: brianlic-msft
 -   Windows 10
 -   Windows Server 2016
 
-Hardware-based security features, also called virtualization-based security or VBS, make up a large part of Device Guard security offerings. VBS reinforces the most important feature of Device Guard: configurable code integrity. There are three steps to configure hardware-based security features in Device Guard:
+Hardware-based security features, also called virtualization-based security or VBS, make up a large part of Device Guard security offerings. VBS reinforces the most important feature of Device Guard: configurable code integrity. There are a few steps to configure hardware-based security features in Device Guard:
 
-1.  **Verify that hardware and firmware requirements are met**. Verify that your client computers possess the necessary hardware and firmware to run these features. A list of requirements for hardware-based security features is available 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).
+1.  **Decide whether to use the procedures in this topic, or to use the Device Guard readiness tool**. To enable VBS, you can download and use [the hardware readiness tool on the Microsoft Download Center](https://www.microsoft.com/en-us/download/details.aspx?id=53337), or follow the procedures in this topic.
 
-2.  **Enable the necessary Windows features**. There are several ways to enable the Windows features required for hardware-based security. For details, see the following section, [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-security).
+2.  **Verify that hardware and firmware requirements are met**. Verify that your client computers possess the necessary hardware and firmware to run these features. A list of requirements for hardware-based security features is available 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).
 
-3.  **Enable additional features as desired**. When the necessary Windows features have been enabled, you can enable additional hardware-based security features as desired. For more information, see the following sections in this topic:
+3.  **Enable the necessary Windows features**. There are several ways to enable the Windows features required for hardware-based security. You can use the [Device Guard and Credential Guard hardware readiness tool]((https://www.microsoft.com/en-us/download/details.aspx?id=53337)), or see the following section, [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-security).
+
+4.  **Enable additional features as desired**. When the necessary Windows features have been enabled, you can enable additional hardware-based security features as desired. You can use the [Device Guard and Credential Guard hardware readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337), or see the following sections in this topic:
 
     - [Enable Unified Extensible Firmware Interface Secure Boot](#enable-unified-extensible-firmware-interface-secure-boot)
     - [Enable virtualization-based security for kernel-mode code integrity](#enable-virtualization-based-security-for-kernel-mode-code-integrity)
@@ -51,7 +53,7 @@ After you enable the feature or features, you can configure any additional hardw
 
 Before you begin this process, verify that the target device meets the hardware requirements for UEFI Secure Boot that are laid out 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). There are two options to configure UEFI Secure Boot: manual configuration of the appropriate registry keys and Group Policy deployment. Complete the following steps to manually configure UEFI Secure Boot on a computer running Windows 10.
 
-> **Note**  There are two platform security levels for Secure Boot: stand-alone Secure Boot and Secure Boot with DMA protection. DMA protection provides additional memory protection but will be enabled only on systems whose processors include input/output memory management units (IOMMUs). Protection against driver-based attacks is provided only on systems that have IOMMUs and that have DMA protection enabled. For more information about how IOMMUs help protect against DMA attacks, see [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).
+> **Important**&nbsp;&nbsp;Secure boot settings include **Secure Boot** and **Secure Boot with DMA**. In most situations we recommend that you simply choose **Secure Boot**. This option provides secure boot with as much protection as is supported by a given computer’s hardware. A computer with input/output memory management units (IOMMUs) will have secure boot with DMA protection. A computer without IOMMUs will simply have secure boot enabled.<br>In contrast, with **Secure Boot with DMA**, the setting will enable secure boot—and VBS itself—only on a computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer without IOMMUs will not have VBS (hardware-based) protection, although it can have code integrity policies enabled.<br>For information about how VBS uses the hypervisor to strengthen protections provided by a code integrity policy, see [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).
 
 1.  Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
 
@@ -75,7 +77,7 @@ Unfortunately, it would be time consuming to perform these steps manually on eve
 
     ![Group Policy Management, create a GPO](images/dg-fig2-createou.png)
 
-    Figure 5. Create a new OU-linked GPO
+    Figure 2. Create a new OU-linked GPO
 
 2.  Give the new GPO a name, for example, **Contoso Secure Boot GPO Test**, or any name you prefer. Ideally, the name will align with your existing GPO naming convention.
 
@@ -85,15 +87,15 @@ Unfortunately, it would be time consuming to perform these steps manually on eve
 
     ![Edit the group policy for Virtualization Based Security](images/dg-fig3-enablevbs.png)
 
-    Figure 6. Enable VBS
+    Figure 3. Enable VBS
 
-5.  Select the **Enabled** button, and then select **Secure Boot and DMA Protection** from the **Select Platform Security Level** list.
+5.  Select the **Enabled** button, and then select a secure boot option, such as **Secure Boot**, from the **Select Platform Security Level** list.
 
     ![Group Policy, Turn On Virtualization Based Security](images/device-guard-gp.png)
 
-    Figure 7. Enable Secure Boot (in Windows 10, version 1607)
+    Figure 4. Enable Secure Boot (in Windows 10, version 1607)
 
-    > **Note**&nbsp;&nbsp;Device Guard Secure Boot is maximized when combined with DMA protection. If your hardware contains the IOMMUs required for DMA protection, be sure to select the **Secure Boot and DMA Protection** platform security level. If your hardware does not contain IOMMUs, there are several mitigations provided by leveraging Secure Boot without DMA Protection.
+    > **Important**&nbsp;&nbsp;Secure boot settings include **Secure Boot** and **Secure Boot with DMA**. In most situations we recommend that you choose **Secure Boot**. This option provides secure boot with as much protection as is supported by a given computer’s hardware. A computer with input/output memory management units (IOMMUs) will have secure boot with DMA protection. A computer without IOMMUs will simply have secure boot enabled.<br>In contrast, with **Secure Boot with DMA**, the setting will enable secure boot—and VBS itself—only on a computer that supports DMA, that is, a computer with IOMMUs. With this setting, any computer without IOMMUs will not have VBS (hardware-based) protection, although it can have code integrity policies enabled.<br>For information about how VBS uses the hypervisor to strengthen protections provided by a code integrity policy, see [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).
 
 6.  Close the Group Policy Management Editor, and then restart the Windows 10 test computer. After you configure this setting, UEFI Secure Boot will be enabled upon restart.
 
@@ -123,13 +125,13 @@ It would be time consuming to perform these steps manually on every protected co
 
 > **Note**&nbsp;&nbsp;We recommend that you test-enable this feature on a group of test computers before you deploy it to users' computers. If untested, there is a possibility that this feature can cause system instability and ultimately cause the client operating system to fail.
 
-**To use Group Policy to configure VBS of KMCI:**
+### Use Group Policy to configure VBS of KMCI
 
 1.  Create a new GPO: Right-click the OU to which you want to link the GPO, and then click **Create a GPO in this domain, and Link it here**.
 
     ![Group Policy Management, create a GPO](images/dg-fig5-createnewou.png)
 
-    Figure 2. Create a new OU-linked GPO
+    Figure 5. Create a new OU-linked GPO
 
 2.  Give the new GPO a name, for example, **Contoso VBS CI Protection GPO Test**, or any name you prefer. Ideally, the name will align with your existing GPO naming convention.
 
@@ -139,17 +141,17 @@ It would be time consuming to perform these steps manually on every protected co
 
     ![Edit the group policy for Virtualization Based Security](images/dg-fig6-enablevbs.png)
 
-    Figure 3. Enable VBS
+    Figure 6. Enable VBS
 
 5.  Select the **Enabled** button, and then for **Virtualization Based Protection of Code Integrity**, select the appropriate option:
 
-    - With Windows 10, version 1607 or Windows Server 2016, choose an enabled option:<br>For an initial deployment or test deployment, we recommend **Enabled without UEFI lock**.<br>When your deployment is stable in your environment, we recommend changing to **Enabled with UEFI lock**. This option helps protect the registry from tampering, either through malware or by an unauthorized person.
+    - With Windows 10, version 1607 or Windows Server 2016, choose an enabled option:<br>For an initial deployment or test deployment, we recommend **Enabled without lock**.<br>When your deployment is stable in your environment, we recommend changing to **Enabled with lock**. This option helps protect the registry from tampering, either through malware or by an unauthorized person.
 
     - With earlier versions of Windows 10, or Windows Server 2016 Technical Preview 5 or earlier:<br>Select the **Enable Virtualization Based Protection of Code Integrity** check box.
 
     ![Group Policy, Turn On Virtualization Based Security](images/dg-fig7-enablevbsofkmci.png)
 
-    Figure 4. Enable VBS of KMCI (in Windows 10, version 1607)
+    Figure 7. Enable VBS of KMCI (in Windows 10, version 1607)
 
 6.  Close the Group Policy Management Editor, and then restart the Windows 10 test computer. With this setting configured, the VBS of the KMCI will take effect upon restart.
 
@@ -258,11 +260,11 @@ Table 1. Win32\_DeviceGuard properties
 </tbody>
 </table>
 
-Another method to determine the available and enabled Device Guard features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the Device Guard properties are displayed at the bottom of the **System Summary** section, as shown in Figure 11.
+Another method to determine the available and enabled Device Guard features is to run msinfo32.exe from an elevated PowerShell session. When you run this program, the Device Guard properties are displayed at the bottom of the **System Summary** section, as shown in Figure 8.
 
 ![Device Guard properties in the System Summary](images/dg-fig11-dgproperties.png)
 
-Figure 11. Device Guard properties in the System Summary
+Figure 8. Device Guard properties in the System Summary
 
 ## Related topics
 

windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard.md

@@ -23,7 +23,9 @@ This article describes the following:
 - [Reviewing your applications: application signing and catalog files](#reviewing-your-applications-application-signing-and-catalog-files)
 - [Code integrity policy formats and signing](#code-integrity-policy-formats-and-signing)
 
-The information in this article provides a foundation for [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+The information in this article is intended for IT professionals, and provides a foundation for [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+
+>**Note**  If you are an OEM, see the requirements information at [PC OEM requirements for Device Guard and Credential Guard](https://msdn.microsoft.com/library/windows/hardware/mt767514(v=vs.85).aspx).
 
 ## Hardware, firmware, and software requirements for Device Guard
 

windows/manage/manage-corporate-devices.md

@@ -34,7 +34,7 @@ Your employees using devices that are owned by the organization can connect to A
 
 You can join a device running Windows 10 to an on-premises Active Directory domain after the first-run experience (sometimes called out-of-box experience or OOBE). You can add devices running Windows 10 to your existing Active Directory infrastructure and manage them just as you've always been used to managing PCs running Windows.
 
-Desktop devices running Windows 10 that are joined to an Active Directory domain can be managed using Group Policy and System Center 2012 R2 Configuration Manager. The following table shows the management support for Windows 10 in Configuration Manager.
+Desktop devices running Windows 10 that are joined to an Active Directory domain can be managed using Group Policy and System Center Configuration Manager (current branch). The following table shows the management support for Windows 10 in Configuration Manager.
 
 <table>
 <colgroup>
@@ -49,7 +49,7 @@ Desktop devices running Windows 10 that are joined to an Active Directory domai
 </thead>
 <tbody>
 <tr class="odd">
-<td align="left"><p>[Microsoft System Center Configuration Manager 2016](http://go.microsoft.com/fwlink/p/?LinkId=613622)</p></td>
+<td align="left"><p>[System Center Configuration Manager (current branch) ](https://technet.microsoft.com/en-us/library/mt346023.aspx)</p></td>
 <td align="left"><p>Client deployment, upgrade, and management with new and existing features</p></td>
 </tr>
 <tr class="even">

windows/whats-new/change-history-for-what-s-new-in-windows-10.md

@@ -6,6 +6,7 @@ ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 author: TrudyHa
+redirect_url: https://technet.microsoft.com/en-us/itpro/windows/whats-new/index
 ---
 
 # Change history for What's new in Windows 10

windows/whats-new/whats-new-windows-10-version-1607.md

@@ -50,6 +50,14 @@ The Upgrade Analytics workflow steps you through the discovery and rationalizati
 
 [Learn more about planning and managing Windows upgrades with Windows Upgrade Analytics.](../deploy/manage-windows-upgrades-with-upgrade-analytics.md)
 
+## Windows updates
+
+Windows 10, version 1607, provides administrators with increased control over updates by changing the update deferral increment from weeks to days. Other changes:
+ 
+- Quality Updates can be deferred up to 30 days and paused for 35 days
+- Feature Updates can be deferred up to 180 days and paused for 60 days
+- Update deferrals can be applied to both Current Branch (CB) and Current Branch for Business (CBB)
+
 ## Security
 
 ### Credential Guard and Device Guard