diff --git a/.openpublishing.publish.config.json b/.openpublishing.publish.config.json
index 2358d61c40..576b2cc42a 100644
--- a/.openpublishing.publish.config.json
+++ b/.openpublishing.publish.config.json
@@ -9,7 +9,7 @@
"build_output_subfolder": "education",
"locale": "en-us",
"version": 0,
- "open_to_public_contributors": false,
+ "open_to_public_contributors": true,
"type_mapping": {
"Conceptual": "Content"
}
@@ -20,7 +20,7 @@
"build_output_subfolder": "browsers/internet-explorer",
"locale": "en-us",
"version": 0,
- "open_to_public_contributors": false,
+ "open_to_public_contributors": true,
"type_mapping": {
"Conceptual": "Content"
}
@@ -45,7 +45,7 @@
"build_output_subfolder": "mdop",
"locale": "en-us",
"version": 0,
- "open_to_public_contributors": false,
+ "open_to_public_contributors": true,
"type_mapping": {
"Conceptual": "Content"
}
@@ -56,7 +56,7 @@
"build_output_subfolder": "browsers/edge",
"locale": "en-us",
"version": 0,
- "open_to_public_contributors": false,
+ "open_to_public_contributors": true,
"type_mapping": {
"Conceptual": "Content"
}
@@ -67,7 +67,7 @@
"build_output_subfolder": "devices/surface",
"locale": "en-us",
"version": 0,
- "open_to_public_contributors": false,
+ "open_to_public_contributors": true,
"type_mapping": {
"Conceptual": "Content"
}
@@ -78,7 +78,7 @@
"build_output_subfolder": "devices/surface-hub",
"locale": "en-us",
"version": 0,
- "open_to_public_contributors": false,
+ "open_to_public_contributors": true,
"type_mapping": {
"Conceptual": "Content"
}
@@ -89,7 +89,7 @@
"build_output_subfolder": "windows",
"locale": "en-us",
"version": 0,
- "open_to_public_contributors": false,
+ "open_to_public_contributors": true,
"type_mapping": {
"Conceptual": "Content"
}
@@ -101,7 +101,8 @@
"branches_to_filter": [
""
],
- "git_repository_url_open_to_public_contributors": "",
+ "git_repository_url_open_to_public_contributors": "https://github.com/Microsoft/windows-itpro-docs",
+ "git_repository_branch_open_to_public_contributors": "master",
"skip_source_output_uploading": false,
"dependent_repositories": []
}
diff --git a/devices/hololens/index.md b/devices/hololens/index.md
index 867e2c8492..4b581a5c10 100644
--- a/devices/hololens/index.md
+++ b/devices/hololens/index.md
@@ -1 +1,3 @@
-# Placeholder
\ No newline at end of file
+---
+redirect_url: https://developer.microsoft.com/windows/holographic/commercial_features
+---
diff --git a/devices/surface/advanced-uefi-security-features-for-surface-pro-3.md b/devices/surface/advanced-uefi-security-features-for-surface-pro-3.md
index a590b85c20..7a4c04dabc 100644
--- a/devices/surface/advanced-uefi-security-features-for-surface-pro-3.md
+++ b/devices/surface/advanced-uefi-security-features-for-surface-pro-3.md
@@ -23,7 +23,7 @@ To address more granular control over the security of Surface devices, the v3.11
Before you can configure the advanced security features of your Surface device, you must first install the v3.11.760.0 UEFI update. This update is installed automatically if you receive your updates from Windows Update. For more information about how to configure Windows to update automatically by using Windows Update, see [How to configure and use Automatic Updates in Windows]( http://go.microsoft.com/fwlink/p/?LinkID=618030).
-To update the UEFI on Surface Pro 3, you can download and install the Surface UEFI updates as part of the Surface Pro 3 Firmware and Driver Pack. These firmware and driver packs are available from the [Surface Pro 3 page](https://www.microsoft.com/en-us/download/details.aspx?id=38826) on the Microsoft Download Center. You can find out more about the firmware and driver packs at [Download the latest firmware and drivers for Surface devices](https://technet.microsoft.com/en-us/itpro/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices). The firmware and driver packs are available as both self-contained Windows Installer (.msi) and archive (.zip) formats. You can find out more about these two formats and how you can use them to update your drivers at [Manage Surface driver and firmware updates](https://technet.microsoft.com/en-us/itpro/surface/manage-surface-pro-3-firmware-updates).
+To update the UEFI on Surface Pro 3, you can download and install the Surface UEFI updates as part of the Surface Pro 3 Firmware and Driver Pack. These firmware and driver packs are available from the [Surface Pro 3 page](https://www.microsoft.com/download/details.aspx?id=38826) on the Microsoft Download Center. You can find out more about the firmware and driver packs at [Download the latest firmware and drivers for Surface devices](https://technet.microsoft.com/itpro/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices). The firmware and driver packs are available as both self-contained Windows Installer (.msi) and archive (.zip) formats. You can find out more about these two formats and how you can use them to update your drivers at [Manage Surface driver and firmware updates](https://technet.microsoft.com/itpro/surface/manage-surface-pro-3-firmware-updates).
## Manually configure additional security settings
diff --git a/devices/surface/customize-the-oobe-for-surface-deployments.md b/devices/surface/customize-the-oobe-for-surface-deployments.md
index aa17e2e68f..9160b9b3f5 100644
--- a/devices/surface/customize-the-oobe-for-surface-deployments.md
+++ b/devices/surface/customize-the-oobe-for-surface-deployments.md
@@ -25,9 +25,9 @@ In some scenarios, you may want to provide complete automation to ensure that at
This article provides a summary of the scenarios where a deployment might require additional steps. It also provides the required information to ensure that the desired experience is achieved on any newly deployed Surface device. This article is intended for administrators who are familiar with the deployment process, as well as concepts such as answer files and [reference images](http://go.microsoft.com/fwlink/p/?LinkID=618042).
>**Note:** Although the OOBE phase of setup is still run during a deployment with an automated deployment solution such as the [Microsoft Deployment Toolkit (MDT)](http://go.microsoft.com/fwlink/p/?LinkId=618117) or System Center Configuration Manager Operating System Deployment (OSD), it is automated by the settings supplied in the Deployment Wizard and task sequence. For more information see:
-- [Deploy Windows 10 with the Microsoft Deployment Toolkit](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit)
+- [Deploy Windows 10 with the Microsoft Deployment Toolkit](http://technet.microsoft.com/itpro/windows/deploy/deploy-windows-10-with-the-microsoft-deployment-toolkit)
-- [Deploy Windows 10 with System Center 2012 R2 Configuration Manager](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-windows-10-with-system-center-2012-r2-configuration-manager)
+- [Deploy Windows 10 with System Center 2012 R2 Configuration Manager](http://technet.microsoft.com/itpro/windows/deploy/deploy-windows-10-with-system-center-2012-r2-configuration-manager)
diff --git a/devices/surface/manage-surface-dock-firmware-updates.md b/devices/surface/manage-surface-dock-firmware-updates.md
index 4d2733a4ad..21c8a0d24f 100644
--- a/devices/surface/manage-surface-dock-firmware-updates.md
+++ b/devices/surface/manage-surface-dock-firmware-updates.md
@@ -16,12 +16,12 @@ author: jobotto
Read about the different methods you can use to manage the process of Surface Dock firmware updates.
-The Surface Dock provides external connectivity to Surface devices through a single cable connection that includes Power, Ethernet, Audio, USB 3.0, and DisplayPort. The numerous connections provided by the Surface Dock are enabled by a smart chipset within the Surface Dock device. Like a Surface device’s chipset, the chipset that is built into the Surface Dock is controlled by firmware. For more information about the Surface Dock, see the [Surface Dock demonstration](https://technet.microsoft.com/en-us/mt697552) video.
+The Surface Dock provides external connectivity to Surface devices through a single cable connection that includes Power, Ethernet, Audio, USB 3.0, and DisplayPort. The numerous connections provided by the Surface Dock are enabled by a smart chipset within the Surface Dock device. Like a Surface device’s chipset, the chipset that is built into the Surface Dock is controlled by firmware. For more information about the Surface Dock, see the [Surface Dock demonstration](https://technet.microsoft.com/mt697552) video.
Like the firmware for Surface devices, firmware for Surface Dock is also contained within a downloaded driver that is visible in Device Manager. This driver stages the firmware update files on the Surface device. When a Surface Dock is connected and the driver is loaded, the newer version of the firmware staged by the driver is detected and firmware files are copied to the Surface Dock. The Surface Dock then begins a two-phase process to apply the firmware internally. Each phase requires the Surface Dock to be disconnected from the Surface device before the firmware is applied. The driver copies the firmware into the dock, but only applies it when the user disconnects the Surface device from the Surface Dock. This ensures that there are no disruptions because the firmware is only applied when the user leaves their desk with the device.
>**Note:** You can learn more about the firmware update process for Surface devices and how firmware is updated through driver installation at the following links:
-- [How to manage and update Surface drivers and firmware](https://technet.microsoft.com/en-us/mt697551) from Microsoft Mechanics
+- [How to manage and update Surface drivers and firmware](https://technet.microsoft.com/mt697551) from Microsoft Mechanics
- [Windows Update Makes Surface Better](http://go.microsoft.com/fwlink/p/?LinkId=785354) on the Microsoft Devices Blog
diff --git a/devices/surface/manage-surface-uefi-settings.md b/devices/surface/manage-surface-uefi-settings.md
index 7071bb2da7..246334a4d4 100644
--- a/devices/surface/manage-surface-uefi-settings.md
+++ b/devices/surface/manage-surface-uefi-settings.md
@@ -26,7 +26,7 @@ On the **PC information** page, detailed information about your Surface device i
- **UUID** – This Universally Unique Identification number is specific to your device and is used to identify the device during deployment or management.
- **Serial Number** – This number is used to identify this specific Surface device for asset tagging and support scenarios.
-- **Asset Tag** – The asset tag is assigned to the Surface device with the [Asset Tag Tool](https://www.microsoft.com/en-us/download/details.aspx?id=44076).
+- **Asset Tag** – The asset tag is assigned to the Surface device with the [Asset Tag Tool](https://www.microsoft.com/download/details.aspx?id=44076).
You will also find detailed information about the firmware of your Surface device. Surface devices have several internal components that each run different versions of firmware. The firmware version of each of the following devices is displayed on the **PC information** page (as shown in Figure 1):
@@ -44,7 +44,7 @@ You will also find detailed information about the firmware of your Surface devic
*Figure 1. System information and firmware version information*
-You can find up-to-date information about the latest firmware version for your Surface device in the [Surface Update History](https://www.microsoft.com/surface/en-us/support/install-update-activate/surface-update-history) for your device.
+You can find up-to-date information about the latest firmware version for your Surface device in the [Surface Update History](https://www.microsoft.com/surface/support/install-update-activate/surface-update-history) for your device.
##Security
@@ -70,7 +70,7 @@ On the **Security** page you can also change the configuration of Secure Boot on
*Figure 3. Configure Secure Boot*
-You can also enable or disable the Trusted Platform Module (TPM) device on the **Security** page, as shown in Figure 4. The TPM is used to authenticate encryption for your device’s data with BitLocker. Read more about [BitLocker](https://technet.microsoft.com/en-us/itpro/windows/keep-secure/bitlocker-overview) in the TechNet Library.
+You can also enable or disable the Trusted Platform Module (TPM) device on the **Security** page, as shown in Figure 4. The TPM is used to authenticate encryption for your device’s data with BitLocker. Read more about [BitLocker](https://technet.microsoft.com/itpro/windows/keep-secure/bitlocker-overview) in the TechNet Library.

diff --git a/devices/surface/microsoft-surface-deployment-accelerator.md b/devices/surface/microsoft-surface-deployment-accelerator.md
index c7b442925d..28bbfd35f7 100644
--- a/devices/surface/microsoft-surface-deployment-accelerator.md
+++ b/devices/surface/microsoft-surface-deployment-accelerator.md
@@ -83,7 +83,7 @@ You can find a full list of available driver downloads at [Download the latest f
## Changes and updates
-SDA is periodically updated by Microsoft. For instructions on how these features are used, see [Step-by-Step: Microsoft Surface Deployment Accelerator](https://technet.microsoft.com/en-us/itpro/surface/step-by-step-surface-deployment-accelerator).
+SDA is periodically updated by Microsoft. For instructions on how these features are used, see [Step-by-Step: Microsoft Surface Deployment Accelerator](https://technet.microsoft.com/itpro/surface/step-by-step-surface-deployment-accelerator).
>**Note:** To install a newer version of SDA on a server with a previous version of SDA installed, you only need to run the installation file for the new version of SDA. The installer will handle the upgrade process automatically. If you used SDA to create a deployment share prior to the upgrade and want to use new features of the new version of SDA, you will need to create a new deployment share. SDA does not support upgrades of an existing deployment share.
diff --git a/devices/surface/step-by-step-surface-deployment-accelerator.md b/devices/surface/step-by-step-surface-deployment-accelerator.md
index c2113bd72b..3e6df89af7 100644
--- a/devices/surface/step-by-step-surface-deployment-accelerator.md
+++ b/devices/surface/step-by-step-surface-deployment-accelerator.md
@@ -300,7 +300,7 @@ The **2 – Create Windows Reference Image** task sequence is used to perform a
Like the **1 – Deploy Microsoft Surface** task sequence, the **2 – Create Windows Reference Image** task sequence performs a deployment of the unaltered Windows image directly from the installation media. Creation of a reference image should always be performed on a virtual machine. Using a virtual machine as your reference system helps to ensure that the resulting image is compatible with different hardware configurations.
->**Note:** Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information, see [Deploy a Windows 10 image using MDT 2013 Update 2](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
+>**Note:** Using a virtual machine when you create a reference image for Windows deployment is a recommended practice for performing Windows deployments with Microsoft deployment tools including the Microsoft Deployment Toolkit and System Center Configuration Manager. These Microsoft deployment technologies use the hardware agnostic images produced from a virtual machine and a collection of managed drivers to deploy to different configurations of hardware. For more information, see [Deploy a Windows 10 image using MDT 2013 Update 2](http://technet.microsoft.com/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
diff --git a/devices/surface/surface-diagnostic-toolkit.md b/devices/surface/surface-diagnostic-toolkit.md
index 78142a380b..283a22273c 100644
--- a/devices/surface/surface-diagnostic-toolkit.md
+++ b/devices/surface/surface-diagnostic-toolkit.md
@@ -339,7 +339,7 @@ The device orientation sensor determines what the angle of the Surface device is
This test cycles the screen through brightness levels from 0 percent to 100 percent, and then a message is displayed to confirm if the brightness level changed accordingly. You are then prompted to test for brightness reaction. To test the reaction of brightness when running on battery, disconnect the power adapter. The screen should automatically dim when power is disconnected.
#### Surface Dock test
-The Microsoft Surface Diagnostic Toolkit uses this test only if a Surface Dock is connected to the device. If a Surface Dock is detected, this test verifies that the Surface Dock driver firmware is updated. For more detailed analysis of Surface Dock firmware status and how to manually initiate the firmware update process, see the [Microsoft Surface Dock Updater](https://technet.microsoft.com/en-us/itpro/surface/surface-dock-updater) article.
+The Microsoft Surface Diagnostic Toolkit uses this test only if a Surface Dock is connected to the device. If a Surface Dock is detected, this test verifies that the Surface Dock driver firmware is updated. For more detailed analysis of Surface Dock firmware status and how to manually initiate the firmware update process, see the [Microsoft Surface Dock Updater](https://technet.microsoft.com/itpro/surface/surface-dock-updater) article.
#### System assessment
diff --git a/windows/breadcrumb/toc.yml b/windows/breadcrumb/toc.yml
new file mode 100644
index 0000000000..fa80416cab
--- /dev/null
+++ b/windows/breadcrumb/toc.yml
@@ -0,0 +1,19 @@
+- name: Windows
+ tocHref: /itpro/windows/
+ topicHref: /itpro/windows/index
+ items:
+ - name: What's new
+ tocHref: /itpro/windows/whats-new/
+ topicHref: /itpro/windows/whats-new/index
+ - name: Plan
+ tocHref: /itpro/windows/plan/
+ topicHref: /itpro/windows/plan/index
+ - name: Deploy
+ tocHref: /itpro/windows/deploy/
+ topicHref: /itpro/windows/deploy/index
+ - name: Keep secure
+ tocHref: /itpro/windows/keep-secure/
+ topicHref: /itpro/windows/keep-secure/index
+ - name: Manage
+ tocHref: /itpro/windows/manage/
+ topicHref: /itpro/windows/manage/index
\ No newline at end of file
diff --git a/windows/docfx.json b/windows/docfx.json
index 4d4f037a4c..4b2035530d 100644
--- a/windows/docfx.json
+++ b/windows/docfx.json
@@ -3,7 +3,7 @@
"content":
[
{
- "files": ["**/**.md"],
+ "files": ["**/**.md", "**/**.yml"],
"exclude": ["**/obj/**"]
}
],
@@ -14,7 +14,8 @@
}
],
"globalMetadata": {
- "ROBOTS": "INDEX, FOLLOW"
+ "ROBOTS": "INDEX, FOLLOW",
+ "breadcrumb_path": "/itpro/windows/breadcrumb/toc.json"
},
"externalReference": [
],
diff --git a/windows/keep-secure/additional-configuration-windows-advanced-threat-protection.md b/windows/keep-secure/additional-configuration-windows-advanced-threat-protection.md
new file mode 100644
index 0000000000..279966110f
--- /dev/null
+++ b/windows/keep-secure/additional-configuration-windows-advanced-threat-protection.md
@@ -0,0 +1,7 @@
+ ---
+ redirect_url: https://technet.microsoft.com/en-au/itpro/windows/keep-secure/configure-endpoints-windows-defender-advanced-threat-protection
+ ---
+
+# Additional Windows Defender ATP configuration settings
+
+This page has been redirected to [Configure endpoints](https://technet.microsoft.com/en-au/itpro/windows/keep-secure/configure-endpoints-windows-defender-advanced-threat-protection)
\ No newline at end of file
diff --git a/windows/keep-secure/deploy-device-guard-enable-virtualization-based-security.md b/windows/keep-secure/deploy-device-guard-enable-virtualization-based-security.md
index fdd547a277..bf63f5df7f 100644
--- a/windows/keep-secure/deploy-device-guard-enable-virtualization-based-security.md
+++ b/windows/keep-secure/deploy-device-guard-enable-virtualization-based-security.md
@@ -20,12 +20,9 @@ Hardware-based security features, also called virtualization-based security or V
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 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).
+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)
+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 [Enable virtualization-based security (VBS)](#enable-virtualization-based-security-vbs), later in this topic.
For information about enabling Credential Guard, see [Protect derived domain credentials with Credential Guard](credential-guard.md).
@@ -45,15 +42,19 @@ Hyper-V Hypervisor and Isolated User Mode (not shown).
Figure 1. Enable operating system feature for VBS
-After you enable the feature or features, you can configure any additional hardware-based security features you want. The following sections provide more information:
-- [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)
+After you enable the feature or features, you can enable VBS for Device Guard, as described in the following sections.
-## Enable Unified Extensible Firmware Interface Secure Boot
+## Enable Virtualization Based Security (VBS)
-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.
+Before you begin this process, verify that the target device meets the hardware and firmware requirements for the features that you want, 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). Also, confirm that you have enabled the Windows features discussed in the previous section, [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-security).
-> **Important** 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.
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.
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).
+There are multiple ways to configure VBS features for Device Guard. You can use the [readiness tool](https://www.microsoft.com/en-us/download/details.aspx?id=53337) rather than the procedures in this topic, or you can use the following procedures, either to configure the appropriate registry keys manually or to use Group Policy.
+
+> **Important**
+> - The settings in the following procedure 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.
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 still have code integrity policies enabled.
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).
+> - All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. We recommend that you enable these features on a group of test computers before you enable them on users' computers.
+
+**To configure VBS manually**
1. Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
@@ -65,13 +66,19 @@ Before you begin this process, verify that the target device meets the hardware
| ---------------- | ---------------- |
| **1** enables the **Secure Boot** option
**3** enables the **Secure Boot and DMA protection** option | **1** enables the **Secure Boot** option
**2** enables the **Secure Boot and DMA protection** option |
-4. Restart the client computer.
+4. With a supported operating system earlier than Windows 10, version 1607, or Windows Server 2016, skip this step, and remain in the same registry subkey.
-Unfortunately, it would be time consuming to perform these steps manually on every protected computer in your enterprise. Group Policy offers a much simpler way to deploy UEFI Secure Boot to your organization. This example creates a test organizational unit (OU) called *DG Enabled PCs*. If you want, you can instead link the policy to an existing OU, and then scope the GPO by using appropriately named computer security groups.
+ With Windows 10, version 1607, or Windows Server 2016, navigate to **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard\\Scenarios**.
-> **Note** We recommend that you test-enable this feature on a group of test computers before you deploy it to users' computers.
+5. Set the **HypervisorEnforcedCodeIntegrity DWORD** value to **1**.
-### Use Group Policy to deploy Secure Boot
+6. Restart the client computer.
+
+Unfortunately, it would be time consuming to perform these steps manually on every protected computer in your enterprise. Group Policy offers a much simpler way to deploy these features to your organization. This example creates a test organizational unit (OU) called *DG Enabled PCs*. If you want, you can instead link the policy to an existing OU, and then scope the GPO by using appropriately named computer security groups.
+
+> **Note** We recommend that you test-enable these features on a group of test computers before you enable them on users' computers. If untested, there is a possibility that this feature can cause system instability and ultimately cause the client operating system to fail.
+
+### Use Group Policy to enable VBS
1. To 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**.
@@ -79,7 +86,7 @@ Unfortunately, it would be time consuming to perform these steps manually on eve
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.
+2. Give the new GPO a name, for example, **Contoso VBS settings GPO Test**, or any name you prefer. Ideally, the name will align with your existing GPO naming convention.
3. Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
@@ -89,77 +96,32 @@ Unfortunately, it would be time consuming to perform these steps manually on eve
Figure 3. Enable VBS
-5. Select the **Enabled** button, and then select a secure boot option, such as **Secure Boot**, from the **Select Platform Security Level** list.
+5. Select the **Enabled** button, and then choose a secure boot option, such as **Secure Boot**, from the **Select Platform Security Level** list.

- Figure 4. Enable Secure Boot (in Windows 10, version 1607)
+ Figure 4. Configure VBS, Secure Boot setting (in Windows 10, version 1607)
- > **Important** 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.
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.
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).
+ > **Important** These 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.
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.
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.
+6. For **Virtualization Based Protection of Code Integrity**, select the appropriate option:
-7. Check the test computer’s event log for Device Guard GPOs.
-
- Processed Device Guard policies are logged in event viewer at **Applications and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational**. When the **Turn On Virtualization Based Security** policy is successfully processed, event ID 7000 is logged, which contains the selected settings within the policy.
-
-## Enable virtualization-based security for kernel-mode code integrity
-
-Before you begin this process, verify that the desired computer meets the hardware requirements for VBS found 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), and enable the Windows features discussed in the [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-security) section. When validated, you can enable virtualization-based protection of KMCI in one of two ways: manual configuration of the appropriate registry subkeys and Group Policy deployment.
-
-> **Note** All drivers on the system must be compatible with virtualization-based protection of code integrity; otherwise, your system may fail. We recommend that you enable this feature on a group of test computers before you enable it on users' computers.
-
-**To configure virtualization-based protection of KMCI manually:**
-
-1. Navigate to the appropriate registry subkey:
-
- - With Windows 10, version 1607, or Windows Server 2016:
**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard\\Scenarios**
-
- - With an earlier version of Windows 10, or Windows Server 2016 Technical Preview 5 or earlier:
**HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard**
-
-2. Set the **HypervisorEnforcedCodeIntegrity DWORD** value to **1**.
-
-3. Restart the client computer.
-
-It would be time consuming to perform these steps manually on every protected computer in your enterprise. Instead, use Group Policy to deploy virtualization-based protection of KMCI. This example creates a test OU called *DG Enabled PCs*, which you will use to link the GPO. If you prefer to link the policy to an existing OU rather than create a test OU and scope the policy by using appropriately named computer security groups, that is another option.
-
-> **Note** 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.
-
-### 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**.
-
- 
-
- 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.
-
-3. Open the Group Policy Management Editor: Right-click the new GPO, and then click **Edit**.
-
-4. Within the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Turn On Virtualization Based Security**, and then click **Edit**.
-
- 
-
- 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:
For an initial deployment or test deployment, we recommend **Enabled without lock**.
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 Windows 10, version 1607 or Windows Server 2016, choose an appropriate option:
For an initial deployment or test deployment, we recommend **Enabled without lock**.
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:
Select the **Enable Virtualization Based Protection of Code Integrity** check box.

- Figure 7. Enable VBS of KMCI (in Windows 10, version 1607)
+ Figure 5. Configure VBS, Lock setting (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.
+7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. The settings will take effect upon restart.
-7. Check the test client event log for Device Guard GPOs.
+8. Check the test computer’s event log for Device Guard GPOs.
- Processed Device Guard policies are logged in event viewer under **Applications and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational**. When the **Turn On Virtualization Based Security** policy has been successfully processed, event ID 7000 is logged, which contains the selected settings within the policy.
+ Processed Device Guard policies are logged in event viewer at **Applications and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational**. When the **Turn On Virtualization Based Security** policy is successfully processed, event ID 7000 is logged, which contains the selected settings within the policy.
-**Validate enabled Device Guard hardware-based security features**
+
+### Validate enabled Device Guard hardware-based security features
Windows 10 and Windows Server 2016 and later have a WMI class for Device Guard–related properties and features: *Win32\_DeviceGuard*. This class can be queried from an elevated Windows PowerShell session by using the following command:
@@ -260,11 +222,11 @@ Table 1. Win32\_DeviceGuard properties
-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.
+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 6.

-Figure 8. Device Guard properties in the System Summary
+Figure 6. Device Guard properties in the System Summary
## Related topics
diff --git a/windows/keep-secure/enable-phone-signin-to-pc-and-vpn.md b/windows/keep-secure/enable-phone-signin-to-pc-and-vpn.md
index 28f0292d02..e3c6cbddf6 100644
--- a/windows/keep-secure/enable-phone-signin-to-pc-and-vpn.md
+++ b/windows/keep-secure/enable-phone-signin-to-pc-and-vpn.md
@@ -17,7 +17,7 @@ localizationpriority: high
- Windows 10
- Windows 10 Mobile
-In Windows 10, Version 1607, your network users can use Windows Phone with Windows Hello to sign in to a PC, connect to VPN, and sign in to Office 365 in a browser. Phone sign-in uses Bluetooth, which means no need to wait for a phone call -- just unlock the phone and tap the app.
+In Windows 10, version 1607, your network users can use Windows Phone with Windows Hello to sign in to a PC, connect to VPN, and sign in to Office 365 in a browser. Phone sign-in uses Bluetooth, which means no need to wait for a phone call -- just unlock the phone and tap the app.

diff --git a/windows/keep-secure/implement-microsoft-passport-in-your-organization.md b/windows/keep-secure/implement-microsoft-passport-in-your-organization.md
index 2dc4c2628a..e449b17214 100644
--- a/windows/keep-secure/implement-microsoft-passport-in-your-organization.md
+++ b/windows/keep-secure/implement-microsoft-passport-in-your-organization.md
@@ -20,7 +20,7 @@ localizationpriority: high
You can create a Group Policy or mobile device management (MDM) policy that will implement Windows Hello on devices running Windows 10.
> **Important:** The Group Policy setting **Turn on PIN sign-in** does not apply to Windows 10. Use **Windows Hello for Business** policy settings to manage PINs.
-## Group Policy settings for Passport
+## Group Policy settings for Windows Hello for Businness
The following table lists the Group Policy settings that you can configure for Hello use in your workplace. These policy settings are available in both **User configuration** and **Computer Configuration** under **Policies** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business**.
@@ -139,7 +139,7 @@ The following table lists the Group Policy settings that you can configure for H
-## MDM policy settings for Passport
+## MDM policy settings for Windows Hello for Business
The following table lists the MDM policy settings that you can configure for Windows Hello for Business use in your workplace. These MDM policy settings use the [PassportForWork configuration service provider (CSP)](http://go.microsoft.com/fwlink/p/?LinkId=692070).
Active X Controls:
For more information on ActiveX controls, refer to [ActiveX Control API Reference](http://go.microsoft.com/fwlink/p/?LinkId=331361).
For more information on ActiveX controls, refer to [ActiveX Control API Reference](https://msdn.microsoft.com/library/office/ms440037(v=office.14).aspx).
[Planning for Using App-V with Office](appv-planning-for-using-appv-with-office.md#bkmk-office-vers-supp-appv)
[Supported versions of Microsoft Office](appv-planning-for-using-appv-with-office.md#bkmk-office-vers-supp-appv)
Supported versions of Office
Supported deployment types (for example, desktop, personal Virtual Desktop Infrastructure (VDI), pooled VDI)
[Planning for Using App-V with Office](appv-planning-for-using-appv-with-office.md#bkmk-plan-coexisting)
[Planning for using App-V with coexisting versions of Office](appv-planning-for-using-appv-with-office.md#bkmk-plan-coexisting)
Considerations for installing different versions of Office on the same computer
App-V 4.6.x client type | -App-V client type | -
---|---|
App-V 4.6 SP2 |
-App-V |
-
App-V 4.6 SP2 RDS |
-App-V RDS |
-
App-V 4.6 SP3 |
-App-V |
-
App-V 4.6 SP3 RDS |
-App-V RDS |
-
App-V version | -Link to download the client | -Link to TechNet documentation | -
---|---|---|
App-V 4.6 SP2 |
-[Microsoft Application Virtualization 4.6 Service Pack 2](http://www.microsoft.com/download/details.aspx?id=35513) |
-[About Microsoft Application Virtualization 4.6 SP2](http://technet.microsoft.com/library/jj680847.aspx) |
-
App-V 4.6 SP3 |
-[Microsoft Application Virtualization 4.6 Service Pack 3](http://www.microsoft.com/download/details.aspx?id=41187) |
-[About Microsoft Application Virtualization 4.6 SP3](http://technet.microsoft.com/library/dn511019.aspx) |
-