diff --git a/README.md b/README.md
index 4dc91651ab..f5b28b423b 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,6 @@
 # win-cpub-itpro-docs
 This repo hosts the WDG ITPro content that is published to TechNet.
 
-This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information, see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
\ No newline at end of file
+This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information, see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [opencode@microsoft.com](mailto:opencode@microsoft.com) with any additional questions or comments.
+
+English Handoff Folder Structure Demo!
diff --git a/browsers/edge/TOC.md b/browsers/edge/TOC.md
index 1e0b12897e..df9d4246da 100644
--- a/browsers/edge/TOC.md
+++ b/browsers/edge/TOC.md
@@ -1,5 +1,5 @@
 #[Microsoft Edge - Deployment Guide for IT Pros](index.md)
-##[Change History for Microsoft Edge](change-history-for-microsoft-edge.md)
+##[Change history for Microsoft Edge](change-history-for-microsoft-edge.md)
 ##[Microsoft Edge requirements and language support](hardware-and-software-requirements.md)
 ##[Available policies for Microsoft Edge](available-policies.md)
 ##[Use Enterprise Mode to improve compatibility](emie-to-improve-compatibility.md)
diff --git a/browsers/edge/available-policies.md b/browsers/edge/available-policies.md
index 048f00fbc4..c56c47624b 100644
--- a/browsers/edge/available-policies.md
+++ b/browsers/edge/available-policies.md
@@ -64,26 +64,26 @@ All devices must be enrolled with Intune if you want to use the Windows Custom U
 | Policy name |Supported versions |Supported device |Details |
 |-------------|-------------------|-----------------|--------|
 |AllowAutofill|Windows 10 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowAutofill</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0.** Employees can’t use Autofill to complete form fields.</li><li>**1 (default).** Employees can use Autofill to complete form fields.</li></ul></li></ul>
-|AllowBrowser |Windows 10 or later |Mobile |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowBrowser</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0.** Employees can’t use Microsoft Edge.</li><li>**1 (default).** Employees can use Microsoft Edge.</li></ul></li></ul>| 
+|AllowBrowser |Windows 10 or later |Mobile |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowBrowser</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0.** Employees can’t use Microsoft Edge.</li><li>**1 (default).** Employees can use Microsoft Edge.</li></ul></li></ul>|
+|AllowCookies |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowCookies</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Allows all cookies from all sites.</li><li>**1.** Blocks only cookies from 3rd party websites</li><li>**2.** Blocks all cookies from all sites.</li></ul></li></ul> |
 |AllowDeveloperTools |Windows 10, Version 1511 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowDeveloperTools</li><li>**Data type:** Integer</li><li>**Allowed values:**<ul><li>**0.** Employees can't use the F12 Developer Tools</li><li>**1 (default).** Employees can use the F12 Developer Tools</li></ul></li></ul> |
 |AllowDoNotTrack |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowDoNotTrack</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Stops employees from sending Do Not Track headers to websites requesting tracking info.</li><li>**1.** Employees can send Do Not Track headers to websites requesting tracking info.</li></ul></li></ul> |
 |AllowExtensions |Windows 10 Insider Preview |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowExtensions</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0.** Employees can’t use Edge Extensions.</li><li>**1 (default).** Employees can use Edge Extensions.</li></ul></li></ul> |
 |AllowInPrivate |Windows 10, Version 1511 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowInPrivate</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0.** Employees can’t use InPrivate browsing.</li><li>**1 (default).** Employees can use InPrivate browsing.</li></ul></li></ul> |
 |AllowPasswordManager |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowPasswordManager</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can't use Password Manager to save passwords locally.</li><li>**1.** Employees can use Password Manager to save passwords locally.</li></ul></li></ul> |
 |AllowPopups |Windows 10 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowPopups</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Turns off Pop-up Blocker, allowing pop-up windows.</li><li>**1.** Turns on Pop-up Blocker, stopping pop-up windows.</li></ul></li></ul> |
-|AllowSearchSuggestions<br>inAddressBar |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowSearchSuggestionsinAddressBar/</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can’t see search suggestions in the Address bar of Microsoft Edge.</li><li>**1.** Employees can see search suggestions in the Address bar of Microsoft Edge.</li></ul></li></ul> |
+|AllowSearchSuggestionsinAddressBar |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowSearchSuggestionsinAddressBar</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can’t see search suggestions in the Address bar of Microsoft Edge.</li><li>**1.** Employees can see search suggestions in the Address bar of Microsoft Edge.</li></ul></li></ul> |
 |AllowSmartScreen |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/AllowSmartScreen</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Turns off SmartScreen Filter.</li><li>**1.** Turns on SmartScreen Filter, providing warning messages to your employees about potential phishing scams and malicious software.</li></ul></li></ul> |
-|Cookies |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/Cookies</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Allows all cookies from all sites.</li><li>**1.** Blocks only cookies from 3rd party websites</li><li>**2.** Blocks all cookies from all sites.</li></ul></li></ul> |
 |EnterpriseModeSiteList |Windows 10 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/EnterpriseModeSiteList</li><li>**Data type.** String</li><li>**Allowed values:**<ul><li>Not configured.</li><li>**1 (default).** Use the Enterprise Mode Site List, if configured.</li><li>**2.** Specify the location to the site list.</li></ul></li></ul> |
 |Favorites |Windows 10, Version 1511 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/Favorites</li><li>**Data type.** String</li><li>**Allowed values:**<ul><li>Configure the **Favorite** URLs for your employees.<p>**Example:**<br>`<contoso.com>`<br>`<fabrikam.com>`<p>**Note**<br> URLs must be on separate lines and aren't shared between Microsoft Edge and Internet Explorer 11.</li></ul> |
-|FirstRunURL |Windows 10, Version 1511 or later |Mobile |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/ Browser/FirstRunURL</li><li>**Data type.** String</li><li>**Allowed values:**<ul><li>Configure the first run URL for your employees.<p>**Example:**<br>`<contoso.one>`</li></ul></li></ul> |
+|FirstRunURL |Windows 10, Version 1511 or later |Mobile |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/FirstRunURL</li><li>**Data type.** String</li><li>**Allowed values:**<ul><li>Configure the first run URL for your employees.<p>**Example:**<br>`<contoso.one>`</li></ul></li></ul> |
 |HomePages |Windows 10, Version 1511 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/HomePages</li><li>**Data type.** String</li><li>**Allowed values:**<ul><li>Configure the Home page URLs for your employees.<p>**Example:**<br>`<contoso.com/support><fabrikam.com/support>`</li></ul></li></ul> |
-|PreventAccessToAbout<br>FlagsInMicrosoftEdge |Windows 10 Insider Preview |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventAccessToAboutFlagsInMicrosoftEdge</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can access the about:flags page in Microsoft Edge.</li><li>**1.** Employees can't access the about:flags page in Microsoft Edge.</li></ul></li></ul> |
-|PreventSmartScreen<br>PromptOverride |Windows 10, Version 1511 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventSmartscreenPromptOverride</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can ignore SmartScreen warnings.</li><li>**1.** Employees can't ignore SmartScreen warnings.</li></ul></li></ul> |
-|PreventSmartScreen<br>PromptOverrideForFiles |Windows 10, Version 1511 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventSmartScreenPromptOverrideForFiles </li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can ignore SmartScreen warnings for files.</li><li>**1.** Employees can't ignore SmartScreen warnings for files.</li></ul></li></ul> |
-|PreventUsingLocalHostIP<br>AddressForWebRTC |Windows 10, Version 1511 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventUsingLocalHostIPAddressForWebRTC</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Shows an employee's LocalHost IP address while using the WebRTC protocol.</li><li>**1.** Doesn't show an employee's LocalHost IP address while using the WebRTC protocol.</li></ul></li></ul> |
-|SendIntranetTraffic<br>toInternetExplorer |Windows 10 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/SendIntranetTraffictoInternetExplorer/</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Automatically opens all websites, including intranet sites, using Microsoft Edge.</li><li>**1.** Automatically opens all intranet sites using Internet Explorer 11.</li></ul></li></ul> |
-|ShowMessageWhenOpening<br>InteretExplorerSites |Windows 10 Insider Preview |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/ShowMessageWhenOpeningSitesInInteretExplorer</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Doesn’t show an additional page in Microsoft Edge, stating that a site has been opened using Internet Explorer 11.</li><li>**1.** Shows an additional page in Microsoft Edge, stating that a site has been opened using Internet Explorer 11.</li></ul></li></ul> |
+|PreventAccessToAboutFlagsInMicrosoftEdge |Windows 10 Insider Preview |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventAccessToAboutFlagsInMicrosoftEdge</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can access the about:flags page in Microsoft Edge.</li><li>**1.** Employees can't access the about:flags page in Microsoft Edge.</li></ul></li></ul> |
+|PreventSmartScreenPromptOverride |Windows 10, Version 1511 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventSmartscreenPromptOverride</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can ignore SmartScreen warnings.</li><li>**1.** Employees can't ignore SmartScreen warnings.</li></ul></li></ul> |
+|PreventSmartScreenPromptOverrideForFiles |Windows 10, Version 1511 or later |Both |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventSmartScreenPromptOverrideForFiles </li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Employees can ignore SmartScreen warnings for files.</li><li>**1.** Employees can't ignore SmartScreen warnings for files.</li></ul></li></ul> |
+|PreventUsingLocalHostIPAddressForWebRTC |Windows 10, Version 1511 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/PreventUsingLocalHostIPAddressForWebRTC</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Shows an employee's LocalHost IP address while using the WebRTC protocol.</li><li>**1.** Doesn't show an employee's LocalHost IP address while using the WebRTC protocol.</li></ul></li></ul> |
+|SendIntranetTraffictoInternetExplorer |Windows 10 or later |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/SendIntranetTraffictoInternetExplorer</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Automatically opens all websites, including intranet sites, using Microsoft Edge.</li><li>**1.** Automatically opens all intranet sites using Internet Explorer 11.</li></ul></li></ul> |
+|ShowMessageWhenOpeningInteretExplorerSites |Windows 10 Insider Preview |Desktop |<ul><li>**URI full path.** ./Vendor/MSFT/Policy/Config/Browser/ShowMessageWhenOpeningSitesInInteretExplorer</li><li>**Data type.** Integer</li><li>**Allowed values:**<ul><li>**0 (default).** Doesn’t show an additional page in Microsoft Edge, stating that a site has been opened using Internet Explorer 11.</li><li>**1.** Shows an additional page in Microsoft Edge, stating that a site has been opened using Internet Explorer 11.</li></ul></li></ul> |
 
 ## Microsoft Edge and Windows 10-specific Group Policy settings
 These are additional Windows 10-specific Group Policy settings that work with Microsoft Edge.
diff --git a/browsers/edge/change-history-for-microsoft-edge.md b/browsers/edge/change-history-for-microsoft-edge.md
index 60e52629df..f10af1201c 100644
--- a/browsers/edge/change-history-for-microsoft-edge.md
+++ b/browsers/edge/change-history-for-microsoft-edge.md
@@ -9,6 +9,8 @@ ms.sitesec: library
 # Change history for Microsoft Edge
 This topic lists new and updated topics in the Microsoft Edge documentation for both Windows 10 and Windows 10 Mobile.
 
+For a detailed feature list of what's in the current Microsoft Edge releases, the Windows Insider Preview builds, and what was introduced in previous releases, see the [Microsoft Edge changelog](https://developer.microsoft.com/en-us/microsoft-edge/platform/changelog/).
+
 ## June 2016
 |New or changed topic | Description |
 |----------------------|-------------|
diff --git a/browsers/edge/emie-to-improve-compatibility.md b/browsers/edge/emie-to-improve-compatibility.md
index 707f375170..adb462310e 100644
--- a/browsers/edge/emie-to-improve-compatibility.md
+++ b/browsers/edge/emie-to-improve-compatibility.md
@@ -14,8 +14,6 @@ title: Use Enterprise Mode to improve compatibility (Microsoft Edge for IT Pros)
 **Applies to:**
 
 -   Windows 10
--   Windows 10 Mobile
-
 
 If you have specific web sites and apps that you know have compatibility problems with Microsoft Edge, you can use the Enterprise Mode site list so that the web sites will automatically open using Internet Explorer 11. Additionally, if you know that your intranet sites aren't going to work properly with Microsoft Edge, you can set all intranet sites to automatically open using IE11.
 
diff --git a/devices/surface-hub/TOC.md b/devices/surface-hub/TOC.md
index 485c432a26..b127e38f53 100644
--- a/devices/surface-hub/TOC.md
+++ b/devices/surface-hub/TOC.md
@@ -19,7 +19,7 @@
 ### [Manage Microsoft Surface Hub](manage-surface-hub.md)
 #### [Accessibility](accessibility-surface-hub.md)
 #### [Change the Surface Hub device account](change-surface-hub-device-account.md)
-#### [Device reset](device-reset-suface-hub.md)
+#### [Device reset](device-reset-surface-hub.md)
 #### [End a Surface Hub meeting with I'm Done](i-am-done-finishing-your-surface-hub-meeting.md)
 #### [Install apps on your Surface Hub](install-apps-on-surface-hub.md)
 #### [Manage settings with a local admin account](manage-settings-with-local-admin-account-surface-hub.md)
diff --git a/devices/surface-hub/connect-and-display-with-surface-hub.md b/devices/surface-hub/connect-and-display-with-surface-hub.md
index 35d14c4df5..e5250193a8 100644
--- a/devices/surface-hub/connect-and-display-with-surface-hub.md
+++ b/devices/surface-hub/connect-and-display-with-surface-hub.md
@@ -130,7 +130,7 @@ When a Surface hub is connected to guest computer with the wired connect USB por
 
 -   HID-compliant mouse
 
-**Universal serial bus conntrollers**
+**Universal serial bus controllers**
 
 -   Generic USB hub
 
diff --git a/devices/surface-hub/create-a-device-account-using-office-365.md b/devices/surface-hub/create-a-device-account-using-office-365.md
index a39e64d4cc..1f4a231d66 100644
--- a/devices/surface-hub/create-a-device-account-using-office-365.md
+++ b/devices/surface-hub/create-a-device-account-using-office-365.md
@@ -29,7 +29,7 @@ If you prefer to use a graphical user interface, you can create a device account
 1.  Sign in to Office 365 by visiting http://portal.office.com/admin/
 2.  Provide the admin credentials for your Office 365 tenant. This will take you to your Office 365 Admin Center.
 
-    ![office 365 admin center. ](images/setupdeviceaccto365-02.png)
+    ![Office 365 admin center.](images/setupdeviceaccto365-02.png)
 
 3.  Once you are at the Office 365 Admin Center, navigate to **Users** in the left panel, and then click **Active Users**.
 
@@ -37,13 +37,13 @@ If you prefer to use a graphical user interface, you can create a device account
 
 4.  On the controls above the list of users, click **+** to create a new user. You'll need to enter a **Display name**, **User name**, **Password** and an email address for the recipient of the password. Optionally you can change the password manually, but we recommend that you use the auto-generated option. You also need to assign this account a license that gives the account access to Exchange and Skype for Business services.
 
-    ![screen to create a new user account. ](images/setupdeviceaccto365-04.png)
+    ![screen to create a new user account.](images/setupdeviceaccto365-04.png)
 
     Click **Create**.
 
 5.  Once the account has been successfully created, click **Close** on the resulting dialog box, and you will see the admin center Active Users list again.
 
-    ![confirmation screen for creating a new account. ](images/setupdeviceaccto365-05.png)
+    ![Confirmation screen for creating a new account.](images/setupdeviceaccto365-05.png)
 
 6.  Select the user you just created from the **Active Users** list. You need to disable the Skype for Business license, because you can’t create a Skype Meeting Room with this option.
 
@@ -51,7 +51,7 @@ If you prefer to use a graphical user interface, you can create a device account
 
     In the right panel you can see the account properties and several optional actions. The process so far has created a regular Skype account for this user, which you need to disable. Click **Edit** for the **Assigned license** section, then click the dropdown arrow next to the license to expand the details.
 
-    ![assign license for skype for business online.](images/setupdeviceaccto365-07.png)
+    ![assign license for Skype for Business online.](images/setupdeviceaccto365-07.png)
 
     From the list, uncheck **Skype for Business Online (plan 2)** (this license may vary depending on your organization), and click **SAVE**.
 
@@ -59,39 +59,39 @@ If you prefer to use a graphical user interface, you can create a device account
 
 1.  In the Office 365 Admin Center’s left panel, click **ADMIN**, and then click **Exchange**.
 
-    ![office 365 admin center, showing exchange active users. ](images/setupdeviceaccto365-08.png)
+    ![Office 365 admin center, showing exchange active users.](images/setupdeviceaccto365-08.png)
 
 2.  This will open another tab on your browser to take you to the Exchange Admin Center, where you can create and set the Mailbox Setting for Surface Hub.
 
-    ![exchange admin center. ](images/setupdeviceaccto365-09.png)
+    ![Exchange admin center.](images/setupdeviceaccto365-09.png)
 
 3.  To create a Mobile Device Mailbox Policy, click **Mobile** from the left panel and then click **Mobile device mailbox policies**. Surface Hubs require an account with a mobile device mailbox policy that does not require a password, so if you already have an existing policy that matches this requirement, you can apply that policy to the account. Otherwise use the following steps to create a new one to be used only for Surface Hub device accounts.
 
-    ![excahnge admin center - creating a mobile device mailbox policy. ](images/setupdeviceaccto365-10.png)
+    ![Excahnge admin center - creating a mobile device mailbox policy.](images/setupdeviceaccto365-10.png)
 
 4.  To create a New Surface Hub mobile device mailbox policy, click the **+** button from the controls above the list of policies to add a new policy. For the name, provide a name that will help you distinguish this policy from other device accounts (for example, *SurfaceHubDeviceMobilePolicy*). Make sure the policy does not require a password for the devices assigned to, so make sure **Require a Password** remains unchecked, then click **Save**.
 
-    ![image showing new mobile device policy](images/setupdeviceaccto365-11.png)
+    ![Image showing new mobile device policy.](images/setupdeviceaccto365-11.png)
 
 5.  After you have created the new mobile device mailbox policy, go back to the **Exchange Admin Center** and you will see the new policy listed.
 
-    ![image with new mobile device mailbox policy in exchange admin center. ](images/setupdeviceaccto365-12.png)
+    ![Image with new mobile device mailbox policy in Exchange admin center.](images/setupdeviceaccto365-12.png)
 
 6.  Now, to apply the ActiveSync policy without using PowerShell, you can do the following: In the EAC, click **Recipients** &gt; **Mailboxes** and then select a mailbox.
 
-    ![image showing mailbox in exchange admin center. ](images/setupdeviceaccto365-13.png)
+    ![Image showing mailbox in Exchange admin center.](images/setupdeviceaccto365-13.png)
 
 7.  In the Details pane, scroll to **Phone and Voice Features** and click **View details** to display the **Mobile Device Details** screen.
 
-    ![image showing mobile device details for the mailbox. ](images/setupdeviceaccto365-14.png)
+    ![Image showing mobile device details for the mailbox.](images/setupdeviceaccto365-14.png)
 
 8.  The mobile device mailbox policy that’s currently assigned is displayed. To change the mobile device mailbox policy, click **Browse**.
 
-    ![image with details for the mobile device policy. ](images/setupdeviceaccto365-15.png)
+    ![Image with details for the mobile device policy.](images/setupdeviceaccto365-15.png)
 
 9.  Choose the appropriate mobile device mailbox policy from the list, click **OK** and then click **Save**.
 
-    ![image showing multiple mobile device mailbox policies. ](images/setupdeviceaccto365-16.png)
+    ![Image showing multiple mobile device mailbox policies.](images/setupdeviceaccto365-16.png)
 
 ### <a href="" id="create-device-acct-o365-complete-acct"></a>Use PowerShell to complete device account creation
 
@@ -107,11 +107,11 @@ In order to run cmdlets used by these PowerShell scripts, the following must be
 
 1.  Run Windows PowerShell as Administrator.
 
-    ![image showing how to start windows powershell and run as administrator. ](images/setupdeviceaccto365-17.png)
+    ![Image showing how to start Windows PowerShell and run as administrator.](images/setupdeviceaccto365-17.png)
 
 2.  Create a Credentials object, then create a new session that connects to Skype for Business Online, and provide the global tenant administrator account, then click **OK**.
 
-    ![image for windows powershell credential request. ](images/setupdeviceaccto365-18.png)
+    ![Image for Windows PowerShell credential request. ](images/setupdeviceaccto365-18.png)
 
 3.  To connect to Microsoft Online Services, run:
 
@@ -119,7 +119,7 @@ In order to run cmdlets used by these PowerShell scripts, the following must be
     Connect-MsolService -Credential $Cred
     ```
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-19.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-19.png)
 
 4.  Now to connect to Skype for Business Online Services, run:
 
@@ -127,7 +127,7 @@ In order to run cmdlets used by these PowerShell scripts, the following must be
     $sfbsession = New-CsOnlineSession -Credential $cred
     ```
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-20.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-20.png)
 
 5.  Finally, to connect to Exchange Online Services, run:
 
@@ -136,7 +136,7 @@ In order to run cmdlets used by these PowerShell scripts, the following must be
     "https://outlook.office365.com/powershell-liveid/" -Credential $cred -Authentication "Basic" –AllowRedirection
     ```
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-21.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-21.png)
 
 6.  Now you have to import the Skype for Business Online Session and the Exchange Online session you have just created, which will import the Exchange and Skype Commands so you can use them locally.
 
@@ -147,7 +147,7 @@ In order to run cmdlets used by these PowerShell scripts, the following must be
 
     Note that this could take a while to complete.
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-22.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-22.png)
 
 7.  Once you’re connected to the online services you need to run a few more cmdlets to configure this account as a Surface Hub device account.
 
@@ -180,11 +180,11 @@ Now that you're connected to the online services, you can finish setting up the
 
     You will see the correct email address.
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-23.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-23.png)
 
 2.  You need to convert the account into to a room mailbox, so run:
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-24.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-24.png)
 
     ``` syntax
     Set-Mailbox $strEmail -Type Room
@@ -196,7 +196,7 @@ Now that you're connected to the online services, you can finish setting up the
     Set-Mailbox $strEmail -RoomMailboxPassword (ConvertTo-SecureString  -String "<your password>" -AsPlainText -Force) -EnableRoomMailboxAccount $true
     ```
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-25.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-25.png)
 
 4.  Various Exchange properties can be set on the device account to improve the meeting experience. You can see which properties need to be set in the [Exchange properties](exchange-properties-for-surface-hub-device-accounts.md) section.
 
@@ -205,7 +205,7 @@ Now that you're connected to the online services, you can finish setting up the
     Set-CalendarProcessing -Identity $acctUpn -AddAdditionalResponse $true -AdditionalResponse "This is a <tla rid="surface_hub"/> room!"
     ```
 
-    ![image showing powershell cmdlet.](images/setupdeviceaccto365-26.png)
+    ![Image showing PowerShell cmdlet.](images/setupdeviceaccto365-26.png)
 
 5.  If you decide to have the password not expire, you can set that with PowerShell cmdlets too. See [Password management](password-management-for-surface-hub-device-accounts.md) for more information.
 
@@ -260,11 +260,11 @@ You can use the Exchange Admin Center to create a device account:
 1.  Sign in to your Exchange Admin Center using Exchange admin credentials.
 2.  Once you are at the Exchange Admin Center (EAC), navigate to **Recipients** in the left panel.
 
-    ![image showing mailboxes in exchange admin center. ](images/setupdeviceacctexch-01.png)
+    ![Image showing mailboxes in Exchange admin center.](images/setupdeviceacctexch-01.png)
 
 3.  On the controls above the list of mailboxess, choose **+** to create a new one, and provide a **Display name**, **Name**, and **User logon name**, and then click **Save**.
 
-    ![image showing creating a new mailbox. ](images/setupdeviceacctexch-02.png)
+    ![Image showing creating a new mailbox.](images/setupdeviceacctexch-02.png)
 
 ### <a href="" id="create-device-acct-exch-mbx-policy"></a>Create a mobile device mailbox policy from the Exchange Admin Center
 
@@ -274,37 +274,37 @@ You can use the Exchange Admin Center to create a device account:
 
 1.  Go to the Exchange Admin Center.
 
-    ![image showing exchange admin center. ](images/setupdeviceacctexch-03.png)
+    ![Image showing Exchange admin center.](images/setupdeviceacctexch-03.png)
 
 2.  To create a mobile device mailbox policy, click **Mobile** from the left panel, then **Mobile device mailbox policies**. Surface Hubs require an account with a mobile device mailbox policy that does not require a password, so if you already have an existing policy that matches this requirement, you can apply that policy to the account. Otherwise use the following steps to create a new one to be used only for Surface Hub device accounts.
 
-    ![image showing using exchange admin center to create a mobile device mailbox policy. ](images/setupdeviceacctexch-05.png)
+    ![Image showing using Exchange admin center to create a mobile device mailbox policy.](images/setupdeviceacctexch-05.png)
 
 3.  To create a new mobile device account mailbox policy, click the **+** button from the controls above the list of policies to add a new policy. For the name provide a name that will help you distinguish this policy from other device accounts (for example, *SurfaceHubDeviceMobilePolicy*). The policy must not be password-protected, so make sure **Require a Password** remains unchecked, then click **Save**.
 
-    ![image showing new mobile device mailbox policy. ](images/setupdeviceacctexch-06.png)
+    ![Image showing new mobile device mailbox policy.](images/setupdeviceacctexch-06.png)
 
 4.  After you have created the new mobile device mailbox policy, go back to the Exchange Admin Center and you will see the new policy listed.
 
-    ![image showing new mobile device mailbox policy in exchange admin center. ](images/setupdeviceacctexch-07.png)
+    ![Image showing new mobile device mailbox policy in Exchange admin center.](images/setupdeviceacctexch-07.png)
 
 5.  To apply the ActiveSync policy without using PowerShell, you can do the following:
 
     -   In the EAC, click **Recipients** &gt; **Mailboxes** and select a mailbox.
 
-        ![image showing exchange admin center. ](images/setupdeviceacctexch-08.png)
+        ![image showing exchange admin center.](images/setupdeviceacctexch-08.png)
 
     -   In the **Details** pane, scroll to **Phone and Voice Features** and click **View details** to display the **Mobile Device Details** screen.
 
-        ![image showing mailbox details. ](images/setupdeviceacctexch-09.png)
+        ![image showing mailbox details.](images/setupdeviceacctexch-09.png)
 
     -   The mobile device mailbox policy that’s currently assigned is displayed. To change the mobile device mailbox policy, click **Browse**.
 
-        ![image showing the currently assigned mobile device mailbox policy. ](images/setupdeviceacctexch-10.png)
+        ![image showing the currently assigned mobile device mailbox policy.](images/setupdeviceacctexch-10.png)
 
     -   Choose the appropriate mobile device mailbox policy from the list, click **OK** and then click **Save**.
 
-        ![image showing list of mobile device mailbox policies. ](images/setupdeviceacctexch-11.png)
+        ![image showing list of mobile device mailbox policies.](images/setupdeviceacctexch-11.png)
 
 ### <a href="" id="create-device-acct-exch-powershell-conf"></a>Use PowerShell to configure the account
 
diff --git a/devices/surface-hub/create-and-test-a-device-account-surface-hub.md b/devices/surface-hub/create-and-test-a-device-account-surface-hub.md
index d63259487e..aeb2e566ac 100644
--- a/devices/surface-hub/create-and-test-a-device-account-surface-hub.md
+++ b/devices/surface-hub/create-and-test-a-device-account-surface-hub.md
@@ -116,7 +116,7 @@ You can check online for updated versions at [Surface Hub device account scripts
 
 Your infrastructure will likely fall into one of three configurations. Which configuration you have will affect how you prepare for device setup.
 
-![](images/deploymentoptions-01.png)
+![Image showing deployment options: online, on-premises, or hybrid.](images/deploymentoptions-01.png)
 
 -   [Online deployment (Office 365)](online-deployment-surface-hub-device-accounts.md): Your organization’s environment is deployed entirely on Office 365.
 -   [On-premises deployment](on-premises-deployment-surface-hub-device-accounts.md): Your organization has servers that it controls, where Active Directory, Exchange, and Skype for Business (or Lync) are hosted.
diff --git a/devices/surface-hub/device-reset-suface-hub.md b/devices/surface-hub/device-reset-suface-hub.md
index e4f36616da..b90a11ada6 100644
--- a/devices/surface-hub/device-reset-suface-hub.md
+++ b/devices/surface-hub/device-reset-suface-hub.md
@@ -2,6 +2,7 @@
 title: Device reset (Surface Hub)
 description: You may wish to reset your Microsoft Surface Hub.
 ms.assetid: 44E82EEE-1905-464B-A758-C2A1463909FF
+redirect_url: https://technet.microsoft.com/en-us/itpro/surface-hub/device-reset-surface-hub
 keywords: reset Surface Hub
 ms.prod: w10
 ms.mktglfcycl: manage
@@ -27,7 +28,10 @@ Initiating a reset will return the device to the last cumulative Windows update,
 -   MDM enrollment
 -   Domain join or Azure AD join information
 -   Local admins on the device
--   Configurations from MDM or the Settings app.
+-   Configurations from MDM or the Settings app
+
+**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.
 
 After the reset, you'll be taken through the [first run program](first-run-program-surface-hub.md) again.
 
diff --git a/devices/surface-hub/device-reset-surface-hub.md b/devices/surface-hub/device-reset-surface-hub.md
new file mode 100644
index 0000000000..d2e58dc6fc
--- /dev/null
+++ b/devices/surface-hub/device-reset-surface-hub.md
@@ -0,0 +1,55 @@
+---
+title: Device reset (Surface Hub)
+description: You may wish to reset your Microsoft Surface Hub.
+ms.assetid: 44E82EEE-1905-464B-A758-C2A1463909FF
+keywords: reset Surface Hub
+ms.prod: w10
+ms.mktglfcycl: manage
+ms.sitesec: library
+ms.pagetype: surfacehub
+author: TrudyHa
+---
+
+# Device reset (Surface Hub)
+
+
+You may wish to reset your Microsoft Surface Hub.
+
+Typical reasons for a reset include:
+
+-   The device isn’t running well after installing an update.
+-   You’re repurposing the device for a new meeting space and want to reconfigure it.
+-   You want to change how you locally manage the device.
+
+Initiating a reset will return the device to the last cumulative Windows update, and remove all local user files and configuration, including:
+
+-   The device account
+-   MDM enrollment
+-   Domain join or Azure AD join information
+-   Local admins on the device
+-   Configurations from MDM or the Settings app
+
+**To reset a Surface Hub**
+1.	On your Surface Hub, open **Settings**. 
+
+    ![Image showing Settings app for Surface Hub.](images/sh-settings.png)
+ 
+2.	Click **Update & Security**.
+
+    ![Image showing Update & Security group in Settings app for Surface Hub.](images/sh-settings-update-security.png)
+ 
+3.	Click **Recovery**, and then click **Get started**.
+
+    ![Image showing Reset device option in Settings app for Surface Hub.](images/sh-settings-reset-device.png) 
+
+**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.
+
+After the reset, Surface Hub restarts the [first run program](first-run-program-surface-hub.md) again. 
+
+## Related topics
+
+
+[Manage Microsoft Surface Hub](manage-surface-hub.md)
+
+[Microsoft Surface Hub administrator's guide](surface-hub-administrators-guide.md)
\ No newline at end of file
diff --git a/devices/surface-hub/first-run-program-surface-hub.md b/devices/surface-hub/first-run-program-surface-hub.md
index da4eafbf85..449c447e5c 100644
--- a/devices/surface-hub/first-run-program-surface-hub.md
+++ b/devices/surface-hub/first-run-program-surface-hub.md
@@ -46,7 +46,7 @@ This is the first screen you'll see when you power up the Surface Hub for the fi
 
  
 
-![icd options checklist](images/setuplocale.png)
+![Image showing ICD options checklist.](images/setuplocale.png)
 
 ### Details
 
@@ -72,7 +72,7 @@ If no wired connection can be found, then the device will attempt to set up a wi
 
 If your device does not detect a wired connection that it can use to connect to a network or the Internet, you will see this page. Here you can either connect to a wireless network, or skip making the network connection.
 
-![](images/setupnetworksetup-1.png)
+![Image shoring Network setup page.](images/setupnetworksetup-1.png)
 
 ### Details
 
@@ -97,7 +97,7 @@ If you want to connect to a secured wireless network from this page, click on th
 
 This page will be shown when you've selected a secured wireless network.
 
-![](images/setupnetworksetup-3.png)
+![Image showing wireless network setup page.](images/setupnetworksetup-3.png)
 
 ### Details
 
@@ -121,11 +121,11 @@ This page will be shown when the device detects a wired connection with limited
 
 -   You can select **Enter proxy settings** which will allow you to specify how to use the network proxy. You'll be taken to the next screen.
 
-![](images/setupnetworksetup-2.png)
+![Image showing network proxy page.](images/setupnetworksetup-2.png)
 
 This is the screen you'll see if you clicked **Enter proxy settings** on the previous screen.
 
-![](images/setupnetworksetup-4.png)
+![Image showing proxy server setting details.](images/setupnetworksetup-4.png)
 
 ### Details
 
@@ -149,7 +149,7 @@ You can skip connecting to a network by selecting **Skip this step**. You'll be
 
 This screen is purely informational, and shows which recommended settings have been enabled by default.
 
-![](images/setupsetupforyou.png)
+![Image showing set up for you page.](images/setupsetupforyou.png)
 
 ### Details
 
@@ -170,7 +170,7 @@ On this page, the Surface Hub will ask for credentials for the device account th
 
  
 
-![icd options checklist](images/setupdeviceacct.png)
+![Image showing Enter device account info page.](images/setupdeviceacct.png)
 
 ### Details
 
@@ -192,7 +192,7 @@ If you skip setting it up now, you can add a device account later by using the S
 
 If you click **Skip setting up a device account**, the device will display a dialog box showing what will happen if the device doesn't have a device account. If you choose **Yes, skip this**, you will be sent to the [Name this device page](#name-this-device).
 
-![icd options checklist](images/setupskipdeviceacct.png)
+![Image showing message the is displaed to confirm you want to skip creating a device account.](images/setupskipdeviceacct.png)
 
 ### What happens?
 
@@ -211,7 +211,7 @@ The device will use the UPN or DOMAIN\\User name and password for the device acc
 
 This page will only be shown if there's a problem. Typically, it means that the device account that you provided was found in Active Directory (AD) or Azure Active Directory (Azure AD), but the Exchange server for the account was not discovered.
 
-![icd options checklist](images/setupexchangeserver-01.png)
+![Image showing Exchange server page.](images/setupexchangeserver-01.png)
 
 ### Details
 
@@ -230,7 +230,7 @@ You can enable Exchange services for a device account later by using the Setting
 
 If you click **Skip setting up Exchange services**, the device will display a dialog showing what will happen. If you choose **Yes, skip this**, then Exchange services will not be set up.
 
-![icd options checklist](images/setupexchangeserver-02.png)
+![Image showing confirmation message that is displayed when you skip setting up Exchange services.](images/setupexchangeserver-02.png)
 
 ### What happens?
 
@@ -249,7 +249,7 @@ This page will be shown when:
 -   Exchange supported protocols are not supported by the Surface Hub.
 -   Exchange returns incorrect XML.
 
-![icd options checklist](images/setupexchangepolicies.png)
+![Image showing Exchange policis page.](images/setupexchangepolicies.png)
 
 ### Details
 
@@ -273,7 +273,7 @@ If you choose to skip this check, the Surface Hub will stop looking for the Exch
 
 This page asks you to provide two names that will be used for identifying the Surface Hub.
 
-![icd options checklist](images/setupnamedevice.png)
+![Image showing Name this device page.](images/setupnamedevice.png)
 
 ### Details
 
@@ -307,7 +307,7 @@ Because every Surface Hub can be used by any number of authenticated employees,
 
  
 
-![icd options checklist](images/setupsetupadmins.png)
+![Image showing Set up admins for this device page.](images/setupsetupadmins.png)
 
 ### Details
 
@@ -348,7 +348,7 @@ Joining Azure AD has two primary benefits:
 1.  Some employees from your organization will be able to access the device as admins, and will be able to start the Settings app and configure the device. People that have admin permissions will be defined in your Azure AD subscription.
 2.  If your Azure AD is connected to a mobile device management (MDM) solution, the device will enroll with that MDM solution so you can apply policies and configuration.
 
-![](images/setupjoiningazuread-1.png)
+![Image showing message when you join your Surface Hub to Azure Active Directory.](images/setupjoiningazuread-1.png)
 
 ### Details
 
@@ -357,11 +357,11 @@ The following input is required:
 -   **User's UPN:** The user principal name (UPN) of an account that can join Azure AD.
 -   **Password:** The password of the account you’re using to join Azure AD.
 
-![](images/setupjoiningazuread-2.png)
+![Image showing account log in info.](images/setupjoiningazuread-2.png)
 
 If you get to this point and don't have valid credentials for an Azure AD account, the device will allow you to continue by creating a local admin account. Click **Set up Windows with a local account instead**.
 
-![](images/setupjoiningazuread-3.png)
+![Image showing Set up an admin account page.](images/setupjoiningazuread-3.png)
 
 ### What happens?
 
@@ -373,7 +373,7 @@ This page will ask for credentials to join a domain so that the Surface Hub can
 
 Once the device has been domain joined, you must specify a security group from the domain you joined. This security group will be provisioned as administrators on the Surface Hub, and anyone from the security group can enter their domain credentials to access Settings.
 
-![icd options checklist](images/setupdomainjoin.png)
+![Image showing Set up admins using domain join page.](images/setupdomainjoin.png)
 
 ### Details
 
@@ -385,7 +385,7 @@ The following input is required:
 
 After the credentials are verified, you will be asked to type a security group name. This input is required.
 
-![icd options checklist](images/setupsecuritygroup-1.png)
+![Image showing Enter a security group page.](images/setupsecuritygroup-1.png)
 
 ### What happens?
 
@@ -401,7 +401,7 @@ If the join is successful, you'll see the **Enter a security group** page. When
 
 If you decide not to use Azure Active Directory (Azure AD) or Active Directory (AD) to manage the Surface Hub, you'll need to create a local admin account.
 
-![](images/setuplocaladmin.png)
+![Image showing Set up an admin account for local admin.](images/setuplocaladmin.png)
 
 ### Details
 
diff --git a/devices/surface-hub/hybrid-deployment-surface-hub-device-accounts.md b/devices/surface-hub/hybrid-deployment-surface-hub-device-accounts.md
index fae114b8da..7d9bfa37be 100644
--- a/devices/surface-hub/hybrid-deployment-surface-hub-device-accounts.md
+++ b/devices/surface-hub/hybrid-deployment-surface-hub-device-accounts.md
@@ -21,17 +21,17 @@ Use this procedure if you use Exchange on-prem.
     - In **Active Directory Users and Computers** AD tool, right-click on the folder or Organizational Unit that your Surface Hub accounts will be created in, click **New**, and **User**.
     - Type the display name from the previous cmdlet into the **Full name** box, and the alias into the **User logon name** box. Click **Next**.<p>
     
-        ![new object box for creating a new user in active directory](images/hybriddeployment-01a.png)
+        ![New object box for creating a new user in active directory.](images/hybriddeployment-01a.png)
 
     - Type the password for this account. You'll need to retype it for verification. Make sure the **Password never expires** checkbox is the only option selected.
 
         >**Important** Selecting **Password never expires** is a requirement for Skype for Business on the Surface Hub. Your domain rules may prohibit passwords that don't expire. If so, you'll need to create an exception for each Surface Hub device account.
 
-        ![image showing password dialog box](images/hybriddeployment-02a.png)
+        ![Image showing password dialog box.](images/hybriddeployment-02a.png)
         
     -   Click **Finish** to create the account.
 
-        ![image with account name, logon name, and password options for new user](images/hybriddeployment-03a.png)
+        ![Image with account name, logon name, and password options for new user.](images/hybriddeployment-03a.png)
 
 2.  After you've created the account, run a directory synchronization. When it's complete, go to the users page in your Office 365 admin center and verify that the account created in the previous steps has merged to online.
 
@@ -223,17 +223,17 @@ Use this procedure if you use Exchange online.
     - In **Active Directory Users and Computers** AD tool, right-click on the folder or Organizational Unit that your Surface Hub accounts will be created in, click **New**, and **User**.
     - Type the display name from the previous cmdlet into the **Full name** box, and the alias into the **User logon name** box. Click **Next**.
 
-        ![new object box for creating a new user in active directory](images/hybriddeployment-01a.png)
+        ![New object box for creating a new user in Active Directory.](images/hybriddeployment-01a.png)
 
     - Type the password for this account. You'll need to retype it for verification. Make sure the **Password never expires** checkbox is the only option selected.
     
         >**Important** Selecting **Password never expires** is a requirement for Skype for Business on the Surface Hub. Your domain rules may prohibit passwords that don't expire. If so, you'll need to create an exception for each Surface Hub device account.
     
-        ![image showing password dialog box](images/hybriddeployment-02a.png)
+        ![Image showing password dialog box.](images/hybriddeployment-02a.png)
     
     - Click **Finish** to create the account.
 
-        ![image with account name, logon name, and password options for new user](images/hybriddeployment-03a.png)
+        ![Image with account name, logon name, and password options for new user.](images/hybriddeployment-03a.png)
 
 6.  Directory synchronization.
 
diff --git a/devices/surface-hub/images/sh-settings-reset-device.png b/devices/surface-hub/images/sh-settings-reset-device.png
new file mode 100644
index 0000000000..bdb16e8e20
Binary files /dev/null and b/devices/surface-hub/images/sh-settings-reset-device.png differ
diff --git a/devices/surface-hub/images/sh-settings-update-security.png b/devices/surface-hub/images/sh-settings-update-security.png
new file mode 100644
index 0000000000..44bb2202f0
Binary files /dev/null and b/devices/surface-hub/images/sh-settings-update-security.png differ
diff --git a/devices/surface-hub/images/sh-settings.png b/devices/surface-hub/images/sh-settings.png
new file mode 100644
index 0000000000..12783739ed
Binary files /dev/null and b/devices/surface-hub/images/sh-settings.png differ
diff --git a/devices/surface-hub/install-apps-on-surface-hub.md b/devices/surface-hub/install-apps-on-surface-hub.md
index 2e6754e6cc..2056f2a6f7 100644
--- a/devices/surface-hub/install-apps-on-surface-hub.md
+++ b/devices/surface-hub/install-apps-on-surface-hub.md
@@ -2,7 +2,7 @@
 title: Install apps on your Microsoft Surface Hub
 description: Admins can install apps can from either the Windows Store or the Windows Store for Business.
 ms.assetid: 3885CB45-D496-4424-8533-C9E3D0EDFD94
-keywords: [install apps, Windows Store, Windows Store for Business
+keywords: install apps, Windows Store, Windows Store for Business
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
diff --git a/devices/surface-hub/intro-to-surface-hub.md b/devices/surface-hub/intro-to-surface-hub.md
index 584dc26a5e..f8903f20cd 100644
--- a/devices/surface-hub/intro-to-surface-hub.md
+++ b/devices/surface-hub/intro-to-surface-hub.md
@@ -37,7 +37,7 @@ The capabilities of your Surface Hub will depend on what other Microsoft product
 </tr>
 <tr class="even">
 <td align="left"><p>Meetings using Skype for Business</p></td>
-<td align="left"><p>Device account with Skype for Business (Lync 2010 or later) or Skype for Business Online, and a network connection so the account can be accessed.</p></td>
+<td align="left"><p>Device account with Skype for Business (Lync Server 2013 or later) or Skype for Business Online, and a network connection so the account can be accessed.</p></td>
 </tr>
 <tr class="odd">
 <td align="left"><p>Web browsing through Microsoft Edge</p></td>
diff --git a/devices/surface-hub/manage-settings-with-mdm-for-surface-hub.md b/devices/surface-hub/manage-settings-with-mdm-for-surface-hub.md
index 061bfada43..5fe5d1931c 100644
--- a/devices/surface-hub/manage-settings-with-mdm-for-surface-hub.md
+++ b/devices/surface-hub/manage-settings-with-mdm-for-surface-hub.md
@@ -30,7 +30,7 @@ If you joined your Surface Hub to an Azure Active Directory (Azure AD) subscript
 
 Alternatively, the device can be enrolled like any other Windows device by going to **Settings** &gt; **Accounts** &gt; **Work access**.
 
-![image showing enroll in device maagement page. ](images/managesettingsmdm-enroll.png)
+![Image showing enroll in device maagement page.](images/managesettingsmdm-enroll.png)
 
 ### Manage a device through MDM
 
diff --git a/devices/surface-hub/prepare-your-environment-for-surface-hub.md b/devices/surface-hub/prepare-your-environment-for-surface-hub.md
index 8656c33064..d4af065b4b 100644
--- a/devices/surface-hub/prepare-your-environment-for-surface-hub.md
+++ b/devices/surface-hub/prepare-your-environment-for-surface-hub.md
@@ -29,7 +29,7 @@ In order to function properly, the Surface Hub must have access to a wired or wi
 -   Can receive an IP address using DHCP
 -   Open ports:
     -   HTTPS: 443
-    -   HTTP: 8080
+    -   HTTP: 80
 
 A wired connection is preferred.
 
@@ -79,7 +79,7 @@ In order to ensure that your environment is ready for the Surface Hub, verify th
     -   It must have these ports open:
 
         -   HTTPS: 443
-        -   HTTP: 8080
+        -   HTTP: 80
 
         If your network runs through a proxy, you'll need the proxy address or script information as well.
 
diff --git a/devices/surface-hub/provisioning-packages-for-certificates-surface-hub.md b/devices/surface-hub/provisioning-packages-for-certificates-surface-hub.md
index f3ecf5f2d4..0d7c350af6 100644
--- a/devices/surface-hub/provisioning-packages-for-certificates-surface-hub.md
+++ b/devices/surface-hub/provisioning-packages-for-certificates-surface-hub.md
@@ -58,9 +58,7 @@ In order to create and deploy provisioning packages, all of the following are re
 ### <a href="" id="installing-wicd-prov-pkg"></a>Install the Windows Imaging and Configuration Designer
 
 1.  The Windows Imaging and Configuration Designer (ICD) is installed as part of the Windows 10 ADK. The installer for the ADK can be downloaded from the [Microsoft Download Center](http://go.microsoft.com/fwlink/?LinkId=718147).
-    >**Note**  The ADK must be installed on a separate PC, not on the Surface Hub.
-
-     
+    >**Note**  The ADK must be installed on a separate PC, not on the Surface Hub.  
 
 2.  Run the installer, and set your preferences for installation. When asked what features you want to install, you will see a checklist like the one in the following figure. Note that **Windows Performance Toolkit** and **Windows Assessment Toolkit** should be unchecked, as they are not needed to run the ICD.
 
@@ -73,7 +71,7 @@ In order to create and deploy provisioning packages, all of the following are re
 
     All four of these features are required to run the ICD and create a package for the Surfact Hub.
 
-    ![icd options checklist](images/idcfeatureschecklist.png)
+    ![Image showing Windows ADK install page - select features to install.](images/idcfeatureschecklist.png)
 
 3.  Continue with the installer until the ADK is installed. This may take a while, because the installer downloads remote content.
 
@@ -83,29 +81,29 @@ This example will demonstrate how to create a provisioning package to install a
 
 1.  On the PC that had the Windows 10 ADK installed, open ICD and choose the **New provisioning package** tile from the main menu.
 
-    ![icd tiles](images/wicd-screen01a.png)
+    ![Image showing Start page in Windows Imaging and Configuration Designer.](images/wicd-screen01a.png)
 
 2.  When the **New project** dialog box opens, type whatever name you like in the **Name** box. The **Location** and **Description** boxes can also be filled at your discretion, though we recommend using the **Description** box to help you distinguish among multiple packages. Click **Next**.
 
-    ![icd tiles](images/wicd-screen02a.png)
+    ![Image showing New project screen for Windows Imaging and Configuration Designer.](images/wicd-screen02a.png)
 
     Select the settings that are **Common to all Windows editions**, and click **Next**.
 
-    ![icd tiles](images/wicd-screen02b.png)
+    ![Image showing project settings in Windows Imaging and Configuration Designer.](images/wicd-screen02b.png)
 
     When asked to import a provisioning package, just click **Finish.**
 
-    ![icd tiles](images/wicd-screen02c.png)
+    ![Image showing option for importing a provisioning package.](images/wicd-screen02c.png)
 
 3.  ICD's main screen will be displayed. This is where you create the provisioning package. In the **Available customizations** pane, expand **Runtime settings** and then expand **Certificates**. Click **Root certificates**.
 
-    ![icd tiles](images/wicd-screen03a.png)
+    ![Image showing Windows Imaging and Configuration Designer's man page.](images/wicd-screen03a.png)
 
     In the center pane, you’ll be asked to specify a **CertificateName** for the Root certificate. You can set this to whatever you want. For the example, we've used the same name as the project. Click **Add**, and an entry will be added in the left pane.
 
 4.  In the **Available customizations** pane on the left, a new category has appeared for **CertificatePath** underneath the **CertificateName** you provided. There’s also a red exclamation icon indicating that there is a required field that needs to be set. Click **CeritficatePath**.
 
-    ![icd tiles](images/wicd-screen04a.png)
+    ![Image showing available customizations in Windows Imaging and Configuration Designer.](images/wicd-screen04a.png)
 
 5.  In the center pane, you’ll be asked to specify the path for the certificate. Enter the name of the .cer file that you want to deploy, either by typing or clicking **Browse**. It must be a root certificate. The provisioning package created will copy the .cer file into the package it creates.
 
@@ -238,15 +236,15 @@ The following two methods for deploying provisioning packages apply to any kind
 3.  Navigate to **System &gt; Work Access**. Under the header **Related settings**, click on **Add or remove a management package**.
 4.  Here, click the button for **Add a package**.
 
-    ![](images/provisioningpackagesettings-01.png)
+    ![Image showing provisioining packages page in Settings.](images/provisioningpackagesettings-01.png)
 
 5.  Click **Removable media** from the dropdown list. You will see a list of available provisioning packages on the **Settings** page.
 
-    ![](images/provisioningpackagesettings-02.png)
+    ![Image showing add a package page in Settings.](images/provisioningpackagesettings-02.png)
 
 6.  Choose your package and click **Add**.
 
-    ![](images/provisioningpackagesettings-03.png)
+    ![Image showing select a package box.](images/provisioningpackagesettings-03.png)
 
 7.  You may have to re-enter the admin credentials if User Access Control (UAC) asks for them.
 8.  You’ll see a confirmation dialog box. Click **Yes, add it**. The certificate will be installed.
diff --git a/devices/surface-hub/troubleshoot-surface-hub.md b/devices/surface-hub/troubleshoot-surface-hub.md
index 3e1e8126c3..f5c70dacc3 100644
--- a/devices/surface-hub/troubleshoot-surface-hub.md
+++ b/devices/surface-hub/troubleshoot-surface-hub.md
@@ -43,7 +43,7 @@ Possible fixes for issues on the Surface Hub after you've completed the first-ru
 <p>The device account isn't configured to automatically accept/decline messages.</p>
 </td>
 <td>
-<p>Use PowerShell<code>cmdlet Set-CalendarProcessing $upn -AutomateProcessing AutoAccept</code>.</p>
+<p>Use PowerShell cmdlet <code>Set-CalendarProcessing $upn -AutomateProcessing AutoAccept</code>.</p>
 </td>
 </tr>
 <tr>
@@ -291,7 +291,7 @@ Possible fixes for issues with Surface Hub first-run program.
 </tr>
 <tr>
 <td rowspan="3">
-<div class="alert"><b>Note</b>  <p class="note">People land on the page titled "There's a problem with this account" regarding ActiveSync.</p>
+<div><p>People land on the page titled "There's a problem with this account" regarding ActiveSync.</p>
 </div>
 <div> </div>
 </td>
@@ -456,7 +456,7 @@ This section lists status codes, mapping, user messages, and actions an admin ca
 </colgroup>
 <thead>
 <tr class="header">
-<th align="left">Status Code</th>
+<th align="left">Hex Code</th>
 <th align="left">Mapping</th>
 <th align="left">User-Friendly Message</th>
 <th align="left">Action admin should take</th>
@@ -464,149 +464,148 @@ This section lists status codes, mapping, user messages, and actions an admin ca
 </thead>
 <tbody>
 <tr class="odd">
-<td align="left"><p>-2063532030</p></td>
+<td align="left"><p>0x85010002</p></td>
 <td align="left"><p>E_HTTP_DENIED</p></td>
 <td align="left"><p>The password must be updated.</p></td>
 <td align="left"><p>Update the password.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2147012867</p></td>
+<td align="left"><p>0x80072EFD</p></td>
 <td align="left"><p>WININET_E_CANNOT_CONNECT</p></td>
 <td align="left"><p>Can’t connect to the server right now. Wait a while and try again, or check the account settings.</p></td>
 <td align="left"><p>Verify that the server name is correct and reachable. Verify that the device is connected to the network.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2046817239</p></td>
+<td align="left"><p>0x86000C29</p></td>
 <td align="left"><p>E_NEXUS_STATUS_DEVICE_NOTPROVISIONED (policies don’t match)</p></td>
-<td align="left"><p>The account is configured with policies not compatible with Surface Hub</p>
-.</td>
+<td align="left"><p>The account is configured with policies not compatible with Surface Hub.</p></td>
 <td align="left"><p>Disable the <strong>PasswordEnabled</strong> policy for this account.</p>
 <p>We have a bug were we may surface policy errors if the account doesn’t receive any server notifications within the policy refresh interval.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2046817204</p></td>
+<td align="left"><p>0x86000C4C</p></td>
 <td align="left"><p>E_NEXUS_STATUS_MAXIMUMDEVICESREACHED</p></td>
 <td align="left"><p>The account has too many device partnerships.</p></td>
 <td align="left"><p>Delete one or more partnerships on the server.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2046817270</p></td>
+<td align="left"><p>0x86000C0A</p></td>
 <td align="left"><p>E_NEXUS_STATUS_SERVERERROR_RETRYLATER</p></td>
 <td align="left"><p>Can’t connect to the server right now.</p></td>
 <td align="left"><p>Wait until the server comes back online. If the issue persists, re-provision the account.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2063269885</p></td>
+<td align="left"><p>0x85050003</p></td>
 <td align="left"><p>E_CREDENTIALS_EXPIRED (Credentials have expired and need to be updated)</p></td>
 <td align="left"><p>The password must be updated.</p></td>
 <td align="left"><p>Update the password.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2063269875</p></td>
+<td align="left"><p>0x8505000D</p></td>
 <td align="left"><p>E_AIRSYNC_RESET_RETRY</p></td>
 <td align="left"><p>Can’t connect to the server right now. Wait a while or check the account’s settings.</p></td>
 <td align="left"><p>This is normally a transient error but if the issue persists check the number of devices associated with the account and delete some of them if the number is large.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2046817258</p></td>
+<td align="left"><p>0x86000C16</p></td>
 <td align="left"><p>E_NEXUS_STATUS_USER_HASNOMAILBOX</p></td>
 <td align="left"><p>The mailbox was migrated to a different server.</p></td>
 <td align="left"><p>You should never see this error. If the issue persists, re-provision the account.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2063532028</p></td>
+<td align="left"><p>0x85010004</p></td>
 <td align="left"><p>E_HTTP_FORBIDDEN</p></td>
 <td align="left"><p>Can’t connect to the server right now. Wait a while and try again, or check the account’s settings.</p></td>
 <td align="left"><p>Verify the server name to make sure it is correct. If the account is using cert based authentication make sure the certificate is still valid and update it if not.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2063400920</p></td>
+<td align="left"><p>0x85030028</p></td>
 <td align="left"><p>E_ACTIVESYNC_PASSWORD_OR_GETCERT</p></td>
 <td align="left"><p>The account’s password or client certificate are missing or invalid.</p></td>
 <td align="left"><p>Update the password and/or deploy the client certificate.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2046817238</p></td>
+<td align="left"><p>0x86000C2A</p></td>
 <td align="left"><p>E_NEXUS_STATUS_DEVICE_POLICYREFRESH</p></td>
 <td align="left"><p>The account is configured with policies not compatible with Surface Hub.</p></td>
 <td align="left"><p>Disable the PasswordEnabled policy for this account.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2063269886</p></td>
+<td align="left"><p>0x85050002</p></td>
 <td align="left"><p>E_CREDENTIALS_UNAVAILABLE</p></td>
 <td align="left"><p>The password must be updated.</p></td>
 <td align="left"><p>Update the password.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2147012894</p></td>
+<td align="left"><p>0x80072EE2</p></td>
 <td align="left"><p>WININET_E_TIMEOUT</p></td>
 <td align="left"><p>The network doesn’t support the minimum idle timeout required to receive server notification, or the server is offline.</p></td>
 <td align="left"><p>Verify that the server is running. Verify the NAT settings.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2063589372</p></td>
+<td align="left"><p>0x85002004</p></td>
 <td align="left"><p>E_FAIL_ABORT</p></td>
 <td align="left"><p>This error is used to interrupt the hanging sync, and will not be exposed to users. It will be shown in the telemetry if you force an interactive sync, delete the account, or update its settings.</p></td>
 <td align="left"><p>Nothing.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2063532009</p></td>
+<td align="left"><p>0x85010017</p></td>
 <td align="left"><p>E_HTTP_SERVICE_UNAVAIL</p></td>
 <td align="left"><p>Can’t connect to the server right now. Wait a while or check the account’s settings.</p></td>
 <td align="left"><p>Verify the server name to make sure it is correct. Wait until the server comes back online. If the issue persists, re-provision the account.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2046817267</p></td>
+<td align="left"><p>0x86000C0D</p></td>
 <td align="left"><p>E_NEXUS_STATUS_MAILBOX_SERVEROFFLINE</p></td>
 <td align="left"><p>Can’t connect to the server right now. Wait a while or check the account’s settings.</p></td>
 <td align="left"><p>Verify the server name to make sure it is correct. Wait until the server comes back online. If the issue persists, re-provision the account.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2063400921</p></td>
+<td align="left"><p>0x85030027</p></td>
 <td align="left"><p>E_ACTIVESYNC_GETCERT</p></td>
 <td align="left"><p>The Exchange server requires a certificate.</p></td>
 <td align="left"><p>Import the appropriate EAS certificate on the Surface Hub.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2046817237</p></td>
+<td align="left"><p>0x86000C2B</p></td>
 <td align="left"><p>E_NEXUS_STATUS_INVALID_POLICYKEY</p></td>
 <td align="left"><p>The account is configured with policies not compatible with Surface Hub.</p></td>
 <td align="left"><p>Disable the PasswordEnabled policy for this account.</p>
 <p>We have a bug were we may surface policy errors if the account doesn’t receive any server notifications within the policy refresh interval.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>-2063532027</p></td>
+<td align="left"><p>0x85010005</p></td>
 <td align="left"><p>E_HTTP_NOT_FOUND</p></td>
 <td align="left"><p>The server name is invalid.</p></td>
 <td align="left"><p>Verify the server name to make sure it is correct. If the issue persists, re-provision the account.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>-2063532012</p></td>
+<td align="left"><p>0x85010014</p></td>
 <td align="left"><p>E_HTTP_SERVER_ERROR</p></td>
 <td align="left"><p>Can’t connect to the server.</p></td>
 <td align="left"><p>Verify the server name to make sure it is correct. Trigger a sync and, if the issue persists, re-provision the account.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>0x80072ee7</p></td>
-<td align="left"></td>
+<td align="left"><p>0x80072EE7</p></td>
+<td align="left"><p>WININET_E_NAME_NOT_RESOLVED</p></td>
 <td align="left"><p>The server name or address could not be resolved.</p></td>
 <td align="left"><p>Make sure the server name is entered correctly.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>0x8007052f</p></td>
-<td align="left"></td>
+<td align="left"><p>0x8007052F</p></td>
+<td align="left"><p>ERROR_ACCOUNT_RESTRICTION</p></td>
 <td align="left"><p>While auto-discovering the Exchange server, a policy is applied that prevents the logged-in user from logging in to the server.</p></td>
 <td align="left"><p>This is a timing issue. Re-verify the account's credentials. Try to re-provision when they're correct.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>0x800c0019</p></td>
-<td align="left"></td>
+<td align="left"><p>0x800C0019</p></td>
+<td align="left"><p>INET_E_INVALID_CERTIFICATE</p></td>
 <td align="left"><p>Security certificate required to access this resource is invalid.</p></td>
 <td align="left"><p>Install the correct ActiveSync certificate needed for the provided device account.</p></td>
 </tr>
 <tr class="even">
-<td align="left"><p>0x80072f0d</p></td>
-<td align="left"></td>
+<td align="left"><p>0x80072F0D</p></td>
+<td align="left"><p>WININET_E_INVALID_CA</p></td>
 <td align="left"><p>The certificate authority is invalid or is incorrect. Could not auto-discover the Exchange server because a certificate is missing.</p></td>
 <td align="left"><p>Install the correct ActiveSync certificate needed for the provided device account.</p></td>
 </tr>
@@ -616,12 +615,6 @@ This section lists status codes, mapping, user messages, and actions an admin ca
 <td align="left"><p>The domain provided couldn't be found. The Exchange server could not be auto-discovered and was not provided in the settings.</p></td>
 <td align="left"><p>Make sure that the domain entered is the FQDN, and that there is an Exchange server entered in the Exchange server text box.</p></td>
 </tr>
-<tr class="even">
-<td align="left"><p>0x80072efd</p></td>
-<td align="left"></td>
-<td align="left"><p>Fail to connect to Exchange server as a result of a networking issue. It's possible the server was misspelled or it just couldn't be found.</p></td>
-<td align="left"><p>Make sure that the Exchange server ID is entered correctly, and that the device is connected to the right network.</p></td>
-</tr>
 </tbody>
 </table>
 
diff --git a/devices/surface-hub/use-room-control-system-with-surface-hub.md b/devices/surface-hub/use-room-control-system-with-surface-hub.md
index 590099c5ec..79edc9e9a3 100644
--- a/devices/surface-hub/use-room-control-system-with-surface-hub.md
+++ b/devices/surface-hub/use-room-control-system-with-surface-hub.md
@@ -68,7 +68,7 @@ You can use a standard RJ-11 (6P6C) connector to connect the Surface Hub serial
 
 This diagram shows the correct pinout used for an RJ-11 (6P6C) to DB9 cable.
 
-![image showing the wiring diagram.](images/room-control-wiring-diagram.png)
+![Image showing the wiring diagram.](images/room-control-wiring-diagram.png)
 
 ## Command sets
 
diff --git a/devices/surface-hub/wireless-network-management-for-surface-hub.md b/devices/surface-hub/wireless-network-management-for-surface-hub.md
index c68b67eb32..a84ca0aa97 100644
--- a/devices/surface-hub/wireless-network-management-for-surface-hub.md
+++ b/devices/surface-hub/wireless-network-management-for-surface-hub.md
@@ -25,33 +25,33 @@ If a wired network connection is not available, the Surface Hub can use a wirele
 1.  On the Surface Hub, open **Settings** and enter your admin credentials.
 2.  Click **System**, and then click **Network & Internet**. Under **Wi-Fi**, choose an access point. If you want Surface Hub to automatically connect to this access point, click **Connect automatically**. Click **Connect**.
 
-    ![](images/networkmgtwireless-01.png)
+    ![Image showing Wi-Fi settings, Network & Internet page.](images/networkmgtwireless-01.png)
 
 3.  If the network is secured, you'll be asked to enter the security key. Click **Next** to connect.
 
-    ![](images/networkmgtwireless-02.png)
+    ![Image showing security key and password prompts for connecting to secured Wi-Fi.](images/networkmgtwireless-02.png)
 
 ### Review wireless settings
 
 1.  On the Surface Hub, open **Settings** and enter your admin credentials.
 2.  Click **System**, click **Network & Internet**, then **Wi-Fi**, and then click **Advanced options**.
 
-    ![](images/networkmgtwireless-03.png)
+    ![Image showing where to find Advanced options for Network & Internect, Wi-Fi settings.](images/networkmgtwireless-03.png)
 
 3.  The system will show you the properties for the wireless network connection.
 
-    ![](images/networkmgtwireless-04.png)
+    ![Image showing properties for connected Wi-Fi.](images/networkmgtwireless-04.png)
 
 ### Review wired settings
 
 1.  On the Surface Hub, open **Settings** and enter your admin credentials.
 2.  Click **System**, click **Network & Internet**, then click on the network under Ethernet.
 
-    ![](images/networkmgtwired-01.png)
+    ![Image showing Network & Internet, Ethernet settings page.](images/networkmgtwired-01.png)
 
 3.  The system will show you the properties for the wired network connection.
 
-    ![](images/networkmgtwired-02.png)
+    ![Image showing properties for ethernet connection.](images/networkmgtwired-02.png)
 
 ## Related topics
 
diff --git a/devices/surface/TOC.md b/devices/surface/TOC.md
index 69a46fdc96..07d07e34a6 100644
--- a/devices/surface/TOC.md
+++ b/devices/surface/TOC.md
@@ -2,6 +2,7 @@
 ## [Advanced UEFI security features for Surface Pro 3](advanced-uefi-security-features-for-surface-pro-3.md)
 ## [Customize the OOBE for Surface deployments](customize-the-oobe-for-surface-deployments.md)
 ## [Deploy Surface app with Windows Store for Business](deploy-surface-app-with-windows-store-for-business.md)
+## [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md)
 ## [Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md)
 ## [Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices](enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md)
 ## [Ethernet adapters and Surface deployment](ethernet-adapters-and-surface-device-deployment.md)
@@ -13,4 +14,8 @@
 ### [Step by step: Surface Deployment Accelerator](step-by-step-surface-deployment-accelerator.md)
 ## [Surface Diagnostic Toolkit](surface-diagnostic-toolkit.md)
 ## [Surface Dock Updater](surface-dock-updater.md)
+## [Surface Enterprise Management Mode](surface-enterprise-management-mode.md)
+### [Enroll and configure Surface devices with SEMM](enroll-and-configure-surface-devices-with-semm.md)
+### [Unenroll Surface devices from SEMM](unenroll-surface-devices-from-semm.md)
+## [Upgrade Surface devices to Windows 10 with MDT](upgrade-surface-devices-to-windows-10-with-mdt.md)
 
diff --git a/devices/surface/deploy-surface-app-with-windows-store-for-business.md b/devices/surface/deploy-surface-app-with-windows-store-for-business.md
index 01fc609a8f..4c35222e31 100644
--- a/devices/surface/deploy-surface-app-with-windows-store-for-business.md
+++ b/devices/surface/deploy-surface-app-with-windows-store-for-business.md
@@ -81,6 +81,8 @@ Figure 5 shows the required frameworks for the Surface app.
 
 *Figure 5. Required frameworks for the Surface app*
 
+>**Note:**&nbsp;&nbsp;The version numbers of the Surface app and required frameworks will change as the apps are updated. Check for the latest version of Surface app and each framework in Windows Store for Business. Always use the Surface app and recommended framework versions as provided by Windows Store for Business. Using outdated frameworks or the incorrect versions may result in errors or application crashes.
+
 To download the required frameworks for the Surface app, follow these steps:
 1.	Click the **Download** button under **Microsoft.VCLibs.140.00_14.0.23816.0_x64__8wekyb3d8bbwe**. This downloads the Microsoft.VCLibs.140.00_14.0.23816.0_x64__8wekyb3d8bbwe.Appx file to your specified folder.
 2.	Click the **Download** button under **Microsoft.NET.Native.Runtime.1.1_1.1.23406.0_x64__8wekyb3d8bbwe**. This downloads the Microsoft.NET.Native.Runtime.1.1_1.1.23406.0_x64__8wekyb3d8bbwe.Appx file to your specified folder.
diff --git a/devices/surface/deploy-windows-10-to-surface-devices-with-mdt.md b/devices/surface/deploy-windows-10-to-surface-devices-with-mdt.md
new file mode 100644
index 0000000000..a29f37c0ef
--- /dev/null
+++ b/devices/surface/deploy-windows-10-to-surface-devices-with-mdt.md
@@ -0,0 +1,759 @@
+---
+title: Deploy Windows 10 to Surface devices with Microsoft Deployment Toolkit (Surface)
+description: Walk through the recommended process of how to deploy Windows 10 to your Surface devices with the Microsoft Deployment Toolkit.
+keywords: windows 10 surface, automate, customize, mdt
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.pagetype: surface
+ms.sitesec: library
+author: Scottmca
+---
+
+# Deploy Windows 10 to Surface devices with Microsoft Deployment Toolkit
+
+#### Applies to
+* Surface Pro 4
+* Surface Book
+* Surface 3
+* Windows 10
+
+This article walks you through the recommended process to deploy Windows 10 to Surface devices with Microsoft deployment technologies. The process described in this article yields a complete Windows 10 environment including updated firmware and drivers for your Surface device along with applications like Microsoft Office 365 and the Surface app. When the process is complete, the Surface device will be ready for use by the end user. You can customize this process to include your own applications and configuration to meet the needs of your organization. You can also follow the guidance provided in this article to integrate deployment to Surface devices into existing deployment strategies.
+
+By following the procedures in this article, you can create an up-to-date reference image and deploy this image to your Surface devices, a process known as *reimaging*. Reimaging will erase and overwrite the existing environment on your Surface devices. This process allows you to rapidly configure your Surface devices with identical environments that can be configured to precisely fit your organization’s requirements. 
+
+An alternative to the reimaging process is an upgrade process. The upgrade process is non-destructive and instead of erasing the existing environment on your Surface device, it allows you to install Windows 10 while retaining your user data, applications, and settings. You can read about how to manage and automate the upgrade process of Surface devices to Windows 10 at [Upgrade Surface devices to Windows 10 with MDT](upgrade-surface-devices-to-windows-10-with-mdt.md). 
+
+The goal of the deployment process presented in this article is automation. By leveraging the many technologies and tools available from Microsoft, you can create a process that requires only a single touch on the devices being deployed. The automation can load the deployment environment; format the device; prepare an updated Windows image with the drivers required for the device; apply that image to the device; configure the Windows environment with licensing, membership in a domain, and user accounts; install applications; apply any Windows updates that were not included in the reference image; and log out.
+
+By automating each aspect of the deployment process, you not only greatly decrease the effort involved, but you create a process that can be easily repeated and where human error becomes less of a factor. Take for example a scenario where you create a reference image for the device manually, but you accidentally install conflicting applications and cause the image to become unstable. In this scenario you have no choice but to begin again the manual process of creating your image. If in this same scenario you had automated the reference image creation process, you could repair the conflict by simply editing a step in the task sequence and then re-running the task sequence.
+
+## Deployment tools
+
+The deployment process described in this article leverages a number of Microsoft deployment tools and technologies. Some of these tools and technologies are included in Windows client and Windows Server, such as Hyper-V and Windows Deployment Services (WDS), while others are available as free downloads from the [Microsoft Download Center](https://www.microsoft.com/en-us/download/windows.aspx).
+
+#### Microsoft Deployment Toolkit
+
+The Microsoft Deployment Toolkit (MDT) is the primary component of a Windows deployment. It serves as a unified interface for most of the Microsoft deployment tools and technologies, such as the Windows Assessment and Deployment Kit (Windows ADK), Windows System Image Manager (Windows SIM), Deployment Image Servicing and Management (DISM), User State Migration Tool (USMT), and many other tools and technologies. Each of these is discussed throughout this article. The unified interface, called the *Deployment Workbench*, facilitates automation of the deployment process through a series of stored deployment procedures, known as a *task sequence*. Along with these task sequences and the many scripts and tools that MDT provides, the resources for a Windows deployment (driver files, application installation files, and image files) are stored in a network share known as the *deployment share*. 
+
+You can download and find out more about MDT at [Microsoft Deployment Toolkit](https://technet.microsoft.com/en-us/windows/dn475741).
+
+#### Windows Assessment and Deployment Kit
+
+Although MDT is the tool you will interact with most during the deployment process, the deployment tools found in the Windows ADK perform most of the deployment tasks during the deployment process. The resources for deployment are held within the MDT deployment share, but it is the collection of tools included in Windows ADK that access the image files, stage drivers and Windows updates, run the deployment experience, provide instructions to Windows Setup, and back up and restore user data.
+
+You can download and find out more about the Windows ADK at [Download the Windows ADK](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit#windowsadk).
+
+#### Windows 10 installation media
+
+Before you can perform a deployment with MDT, you must first supply a set of operating system installation files and an operating system image. These files and image can be found on the physical installation media (DVD) for Windows 10. You can also find these files in the disk image (ISO file) for Windows 10, which you can download from the [Volume Licensing Service Center (VLSC)](https://www.microsoft.com/Licensing/servicecenter/default.aspx).
+
+>**Note:**&nbsp;&nbsp;The installation media generated from the [Get Windows 10](https://www.microsoft.com/en-us/software-download/windows10/) page differs from physical media or media downloaded from the VLSC, in that it contains an image file in Electronic Software Download (ESD) format rather than in the Windows Imaging (WIM) format. Installation media with an image file in WIM format is required for use with MDT. Installation media from the Get Windows 10 page cannot be used for Windows deployment with MDT.
+
+#### Windows Server
+
+Although MDT can be installed on a Windows client, to take full advantage of Windows Deployment Services’ ability to network boot, a full Windows Server environment is recommended. To provide network boot for UEFI devices like Surface with WDS, you will need Windows Server 2008 R2 or later.
+
+>**Note:**&nbsp;&nbsp;To evaluate the deployment process for Surface devices or to test the deployment process described in this article with the upcoming release of Windows Server 2016, you can download evaluation and preview versions from the [TechNet Evaluation Center](https://www.microsoft.com/en-us/evalcenter).
+
+#### Windows Deployment Services
+
+Windows Deployment Services (WDS) is leveraged to facilitate network boot capabilities provided by the Preboot Execution Environment (PXE) server. The boot media generated by MDT is loaded onto the Surface device simply by pressing Enter at the prompt when the device attempts to boot from the attached network adapter or Surface Dock.
+
+#### Hyper-V virtualization platform
+
+The process of creating a reference image should always be performed in a virtual environment. When you use a virtual machine as the platform to build your reference image, you eliminate the need for installation of additional drivers. The drivers for a Hyper-V virtual machine are included by default in the factory Windows 10 image. When you avoid the installation of additional drivers – especially complex drivers that include application components like control panel applications – you ensure that the image created by your reference image process will be as universally compatible as possible.
+
+>**Note:**&nbsp;&nbsp;A Generation 1 virtual machine is recommended for the preparation of a reference image in a Hyper-V virtual environment.
+
+Because customizations are performed by MDT at the time of deployment, the goal of reference image creation is not to perform customization but to increase performance during deployment by reducing the number of actions that need to occur on each deployed device. The biggest action that can slow down an MDT deployment is the installation of Windows updates. When MDT performs this step during the deployment process, it downloads the updates on each deployed device and installs them. By installing Windows updates in your reference image, the updates are already installed when the image is deployed to the device and the MDT update process only needs to install updates that are new since the image was created or are applicable to products other than Windows (for example, Microsoft Office updates).
+
+>**Note:**&nbsp;&nbsp;Hyper-V is available not only on Windows Server, but also on Windows clients, including Professional and Enterprise editions of Windows 8, Windows 8.1, and Windows 10. Find out more at [Client Hyper-V on Windows 10](https://msdn.microsoft.com/virtualization/hyperv_on_windows/windows_welcome) and [Client Hyper-V on Windows 8 and Windows 8.1](https://technet.microsoft.com/library/hh857623) in the TechNet Library.  Hyper-V is also available as a standalone product, Microsoft Hyper-V Server, at no cost. You can download [Microsoft Hyper-V Server 2012 R2](https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-2012-r2) or [Microsoft Hyper-V Server 2016 Technical Preview](https://www.microsoft.com/en-us/evalcenter/evaluate-hyper-v-server-technical-preview) from the TechNet Evaluation Center.
+
+#### Surface firmware and drivers
+
+For your deployed Windows environment to function correctly on your Surface devices, you will need to install the drivers used by Windows to communicate with the components of your device. These drivers are available for download in the Microsoft Download Center for each Surface device. You can find the correct Microsoft Download Center page for your device 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).
+
+When you browse to the specific Microsoft Download Center page for your device, you will notice that there are two files available for download. One file is a Windows Installer (.msi) file. This file is used to update drivers on devices that are already running Windows or that have device management solutions. The other file is an archive (.zip) file. This file contains the individual driver files that are used during deployment, or for manual installation with Device Manager. The file that you will need to download is the .zip archive file. You can read more about the difference between the firmware and driver pack file types at [Manage Surface driver and firmware updates](https://technet.microsoft.com/en-us/itpro/surface/manage-surface-pro-3-firmware-updates).
+
+
+In addition to the driver files that help Windows communicate with the hardware components of the Surface device, the .zip file you download will also contain firmware updates. These firmware updates will update the instructions used by the device hardware to communicate between components and Windows. The firmware of Surface device components is updated by installation of specific driver files and thus is installed along with the other drivers during deployment. The firmware of an out-of-date Surface device is thus updated when the device reboots during and after the Windows deployment process.
+
+>**Note:**&nbsp;&nbsp;Beginning in Windows 10, the drivers for Surface devices are included in the Windows Preinstallation Environment (WinPE). In earlier versions of Windows, specific drivers (like network drivers) had to be imported and configured in MDT for use in WinPE to successfully deploy to Surface devices.
+
+#### Application installation files
+
+In addition to the drivers that are used by Windows to communicate with the Surface device’s hardware and components, you will also need to provide the installation files for any applications that you want to install on your deployed Surface devices. To automate the deployment of an application, you will also need to determine the command-line instructions for that application to perform a silent installation. In this article, the Surface app and Microsoft Office 365 will be installed as examples of application installation. The application installation process can be used with any application with installation files that can be launched from command line.
+
+>**Note:**&nbsp;&nbsp;If the application files for your application are stored on your organization’s network and will be accessible from your Surface devices during the deployment process, you can deploy that application directly from that network location. To use installation files from a network location, use the **Install Application Without Source Files or Elsewhere on the Network** option in the MDT New Application Wizard, which is described in the [Import applications](#import-applications) section later in this article.
+
+#### Microsoft Surface Deployment Accelerator
+
+If you want to deploy only to Surface devices or you want an accelerated method to perform deployment to Surface devices, you can use the Microsoft Surface Deployment Accelerator to generate an MDT deployment share complete with Surface device drivers, Surface apps, and pre-configured task sequences to create a reference image and perform deployment to Surface devices. Microsoft Surface Deployment Accelerator can automatically import boot images into WDS and prepare WDS for network boot (PXE). You can download the Microsoft Surface Deployment Accelerator from the [Surface Tools for IT](https://www.microsoft.com/en-us/download/details.aspx?id=46703) page in the Microsoft Download Center.
+
+### Install the deployment tools
+
+Before you can configure the deployment environment with Windows images, drivers, and applications, you must first install the deployment tools that will be used throughout the deployment process. The three main tools to be installed are WDS, Windows ADK, and MDT. WDS provides the capacity for network boot, Windows ADK provides several deployment tools that perform specific deployment tasks, and MDT provides automation and a central interface from which to manage and control the deployment process.
+
+To boot from the network with either your reference virtual machines or your Surface devices, your deployment environment must include a Windows Server environment. The Windows Server environment is required to install WDS and the WDS PXE server. Without PXE support, you will be required to create physical boot media, such as a USB stick to perform your deployment – MDT and Windows ADK will still be required, but Windows Server is not required. Both MDT and Windows ADK can be installed on a Windows client and perform a Windows deployment.
+
+>**Note:**&nbsp;&nbsp;To download deployment tools directly to Windows Server, you must disable [Internet Explorer Enhanced Security Configuration](https://technet.microsoft.com/library/dd883248). On Windows Server 2012 R2, this can be performed directly through the **Server Manager** option on the **Local Server** tab. In the **Properties** section, **IE Enhanced Security Configuration** can be found on the right side. You may also need to enable the **File Download** option for the **Internet** zone through the **Security** tab of **Internet Options**.
+
+#### Install Windows Deployment Services
+
+Windows Deployment Services (WDS) is a Windows Server role. To add the WDS role to a Windows Server 2012 R2 environment, use the Add Roles and Features Wizard, as shown in Figure 1. Start the Add Roles and Features Wizard from the **Manage** button of **Server Manager**. Install both the Deployment Server and Transport Server role services.
+
+![Install the Windows Deployment Services role](images\surface-deploymdt-fig1.png "Install the Windows Deployment Services role")
+
+*Figure 1. Install the Windows Deployment Services server role*
+
+After the WDS role is installed, you need to configure WDS. You can begin the configuration process from the WDS node of Server Manager by right-clicking your server’s name and then clicking **Windows Deployment Services Management Console**. In the **Windows Deployment Services** window, expand the **Servers** node to find your server, right-click your server, and then click **Configure** in the menu to start the Windows Deployment Services Configuration Wizard, as shown in Figure 2.
+
+![Configure PXE response for Windows Deployment Services](images\surface-deploymdt-fig2.png "Configure PXE response for Windows Deployment Services")
+
+*Figure 2. Configure PXE response for Windows Deployment Services*
+
+>**Note:**&nbsp;&nbsp;Before you configure WDS make sure you have a local NTFS volume that is not your system drive (C:) available for use with WDS. This volume is used to store WDS boot images, deployment images, and configuration.
+
+Using the Windows Deployment Services Configuration Wizard, configure WDS to fit the needs of your organization. You can find detailed instructions for the installation and configuration of WDS at [Windows Deployment Services Getting Started Guide for Windows Server 2012](https://technet.microsoft.com/library/jj648426). On the **PXE Server Initial Settings** page, be sure to configure WDS so that it will respond to your Surface devices when they attempt to boot from the network. If you have already installed WDS or need to change your PXE server response settings, you can do so on the **PXE Response** tab of the **Properties** of your server in the Windows Deployment Services Management Console.
+
+>**Note:**&nbsp;&nbsp;You will add boot images to WDS when you update your boot images in MDT. You do not need to add boot images or Windows images to WDS when you configure the role.
+
+#### Install Windows Assessment and Deployment Kit
+
+To install Windows ADK, run the Adksetup.exe file that you downloaded from [Download the Windows ADK](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit#adkwin10). Windows ADK must be installed before MDT. You should always download and use the most recent version of Windows ADK. A new version is usually released corresponding with each new version of Windows.
+
+>**Note:**&nbsp;&nbsp;You can also use the Adksetup.exe file to download the Windows ADK installation files locally for use on other devices.
+
+When you get to the **Select the features you want to install** page, you only need to select the **Deployment Tools** and **Windows Preinstallation Environment (Windows PE)** check boxes to deploy Windows 10 using MDT, as shown in Figure 3. 
+
+![Required options for deployment with MDT](images\surface-deploymdt-fig3.png "Required options for deployment with MDT")
+
+*Figure 3. Only Deployment Tools and Windows PE options are required for deployment with MDT*
+
+#### Install Microsoft Deployment Toolkit
+
+After the Windows ADK installation completes successfully, you can install MDT. When you download MDT, ensure that you download the version that matches the architecture of your deployment server environment. For Windows Server the architecture is 64-bit. Download the MDT installation file that ends in **x64**. When MDT is installed you can use the default options during the installation wizard, as shown in Figure 4.
+
+![MDT installation with default options](images/surface-deploymdt-fig4.png "MDT installation with default options")
+
+*Figure 4. Install the Microsoft Deployment Toolkit with default options*
+
+Before you can open the MDT Deployment Workbench, you must enable execution of scripts in PowerShell. If you do not do this, the following error message may be displayed: *"Initialization Error PowerShell is required to use the Deployment Workbench.  Please install PowerShell then relaunch Deployment Workbench."*
+
+To enable the execution of scripts, run the following cmdlet in PowerShell as an Administrator:
+
+   `Set-ExecutionPolicy RemoteSigned -Scope CurrentUser`
+
+## Create a reference image
+
+Now that you have installed the required tools, you can begin the first step of customizing your deployment environment to your needs – create a reference image. Because the reference image should be created in a virtual machine where there is no need for drivers to be installed, and because the reference image will not include applications, you can use the MDT deployment environment almost entirely with default settings.
+
+### Create a deployment share
+
+Now that you have the tools installed, the next step is to configure MDT for the creation of a reference image. Before you can perform the process of creating a reference image, MDT needs to be set up with a repository for scripts, images, and other deployment resources. This repository is known as the *deployment share*. After the deployment share is created, you must supply MDT with a complete set of Windows 10 installation files, the last set of tools required before MDT can perform reference image creation.
+
+To create the deployment share, follow these steps:
+
+1. Open the Deployment Workbench from your Start menu or Start screen, as shown in Figure 5.
+
+   ![The MDT Deployment Workbench](images\surface-deploymdt-fig5.png "The MDT Deployment Workbench")
+
+   *Figure 5. The MDT Deployment Workbench*
+
+2. Right-click the **Deployment Shares** folder, and then click **New Deployment Share** to start the New Deployment Share Wizard, as shown in Figure 6.
+
+   ![Summary page of the New Deployment Share Wizard](images\surface-deploymdt-fig6.png "Summary page of the New Deployment Share Wizard")
+
+   *Figure 6. The Summary page of the New Deployment Share Wizard*
+
+3. Create a new deployment share with New Deployment Share Wizard with the following steps:
+
+  * **Path** – Specify a local folder where the deployment share will reside, and then click **Next**.
+
+      >**Note:**&nbsp;&nbsp;Like the WDS remote installation folder, it is recommended that you put this folder on an NTFS volume that is not your system volume.
+
+  * **Share** – Specify a name for the network share under which the local folder specified on the **Path** page will be shared, and then click **Next**.
+
+      >**Note:**&nbsp;&nbsp;The share name cannot contain spaces.
+
+      >**Note:**&nbsp;&nbsp;You can use a Dollar Sign (**$**) to hide your network share so that it will not be displayed when users browse the available network shares on the server in File Explorer.
+
+  * **Descriptive Name** – Enter a descriptive name for the network share (this descriptive name can contain spaces), and then click **Next**. The descriptive name will be the name of the folder as it appears in the Deployment Workbench.
+  * **Options** – You can accept the default options on this page. Click **Next**.
+  * **Summary** – Review the specified configuration on this page before you click **Next** to begin creation of the deployment share.
+  * **Progress** – While the deployment share is being created, a progress bar is displayed on this page to indicate the status of the deployment share creation process.
+  * **Confirmation** – When the deployment share creation process completes, the success of the process is displayed on this page. Click **Finish** to complete the New Deployment Share Wizard.
+
+4. When the New Deployment Share Wizard is complete, you can expand the Deployment Shares folder to find your newly created deployment share.
+5. You can expand your deployment share, where you will find several folders for the resources, scripts, and components of your MDT deployment environment are stored.
+
+To secure the deployment share and prevent unauthorized access to the deployment resources, you can create a local user on the deployment share host and configure permissions for that user to have read-only access to the deployment share only. It is especially important to secure access to the deployment share if you intend to automate the logon to the deployment share during the deployment boot process. By automating the logon to the deployment share during the boot of deployment media, the credentials for that logon are stored in plaintext in the bootstrap.ini file on the boot media.
+
+>**Note:**&nbsp;&nbsp;If you intend to capture images (such as the reference image) with this user, the user must also have write permission on the Captures folder in the MDT deployment share.
+
+You now have an empty deployment share that is ready for you to add the resources that will be required for reference image creation and deployment to Surface devices.
+
+### Import Windows installation files
+
+The first resources that are required to perform a deployment of Windows are the installation files from Windows 10 installation media. Even if you have an already prepared reference image, you still need to supply the unaltered installation files from your installation media. The source of these files can be a physical disk, or it can be an ISO file like the download from the Volume Licensing Service Center (VLSC).
+
+>**Note:**&nbsp;&nbsp;A 64-bit operating system is required for compatibility with Surface Pro 4, Surface Book, Surface Pro 3, and Surface 3.
+
+To import Windows 10 installation files, follow these steps:
+
+1. Right-click the **Operating Systems** folder under your deployment share in the Deployment Workbench, and then click **New Folder** to open the **New Folder** page, as shown in Figure 7.
+
+   ![Create a new folder on the New Folder page](images\surface-deploymdt-fig7.png "Create a new folder on the New Folder page")
+   
+   *Figure 7. Create a new folder on the New Folder page*
+
+2. On the **New Folder** page a series of steps is displayed, as follows:
+  * **General Settings** – Enter a name for the folder in the **Folder Name** field (for example, Windows 10 Enterprise), add any comments you want in the **Comments** field, and then click **Next**.
+  * **Summary** – Review the specified configuration of the new folder on this page, and then click **Next**.
+  * **Progress** – A progress bar will be displayed on this page while the folder is created. This page will likely pass very quickly.
+  * **Confirmation** – When the new folder has been created, a **Confirmation** page displays the success of the operation. Click **Finish** to close the **New Folder** page.
+3. Expand the Operating Systems folder to see the newly created folder.
+4. Right-click the newly created folder, and then click **Import Operating System** to launch the Import Operating System Wizard, as shown in Figure 8.
+
+   ![Import source files with the Import Operating System Wizard](images\surface-deploymdt-fig8.png "Import source files with the Import Operating System Wizard")
+
+   *Figure 8. Import source files with the Import Operating System Wizard*
+
+5. The Import Operating System Wizard walks you through the import of your operating system files, as follows:
+  * **OS Type** – Click **Full Set of Source Files** to specify that you are importing the Windows source files from installation media, and then click **Next**.
+  * **Source** – Click **Browse**, move to and select the folder or drive where your installation files are found, and then click **Next**.
+  * **Destination** – Enter a name for the new folder that will be created to hold the installation files, and then click **Next**.
+  * **Summary** – Review the specified configuration on this page before you click **Next** to begin the import process.
+  * **Progress** – While the installation files are imported, a progress bar is displayed on this page.
+  * **Confirmation** – When the operating system import process completes, the success of the process is displayed on this page. Click **Finish** to complete Import Operating System Wizard.
+6.	Expand the folder you created in Step 1 to see the entry for your newly imported installation files for Windows 10.
+
+Now that you’ve imported the installation files from the installation media, you have the files that MDT needs to create the reference image and you are ready to instruct MDT how to create the reference image to your specifications.
+
+### Create reference image task sequence
+
+As described in the [Deployment tools](#deployment-tools) section of this article, the goal of creating a reference image is to keep the Windows environment as simple as possible while performing tasks that would be common to all devices being deployed. You should now have a basic MDT deployment share configured with default options and a set of unaltered, factory installation files for Windows 10. This simple configuration is perfect for reference image creation because the deployment share contains no applications or drivers to interfere with the process.
+
+>**Note:**&nbsp;&nbsp;For some organizations keeping a simple deployment share without applications or drivers is the simplest solution for creation of reference images. You can easily connect to more than one deployment share from a single Deployment Workbench and copy images from a simple, reference-image-only deployment share to a production deployment share complete with drivers and applications.
+
+To create the reference image task sequence, follow these steps:
+
+1. Right-click the **Task Sequences** folder under your deployment share in the Deployment Workbench, and then click **New Task Sequence** to start the New Task Sequence Wizard, as shown in Figure 9.
+
+   ![Create new task sequence to deploy and update a Windows 10 reference environment](images\surface-deploymdt-fig9.png "Create new task sequence to deploy and update a Windows 10 reference environment")
+
+   *Figure 9. Create a new task sequence to deploy and update a Windows 10 reference environment*
+
+2. The New Task Sequence Wizard presents a series of steps, as follows:
+  * **General Settings** – Enter an identifier for the reference image task sequence in the **Task Sequence ID** field, a name for the reference image task sequence in the **Task Sequence Name** field, and any comments for the reference image task sequence in the **Task Sequence Comments** field, and then click **Next**.
+  >**Note:**&nbsp;&nbsp;The **Task Sequence ID** field cannot contain spaces and can be a maximum of 16 characters.
+  * **Select Template** – Select **Standard Client Task Sequence** from the drop-down menu, and then click **Next**.
+  * **Select OS** – Navigate to and select the Windows 10 image you imported with the Windows 10 installation files, and then click **Next**.
+  * **Specify Product Key** – Click **Do Not Specify a Product Key at This Time**, and then click **Next**.
+  * **OS Settings** – Enter a name, organization, and home page URL in the **Full Name**, **Organization**, and **Internet Explorer Home Page** fields, and then click **Next**.
+  * **Admin Password** – Click **Use the Specified Local Administrator Password**, enter a password in the provided field, and then click **Next**.
+  >**Note:**&nbsp;&nbsp;During creation of a reference image, any specified Administrator password will be automatically removed when the image is prepared for capture with Sysprep. During reference image creation, a password is not necessary, but is recommended to remain in line with best practices for production deployment environments.
+  * **Summary** – Review the specified configuration on this page before you click **Next** to begin creation of the task sequence.
+  * **Progress** – While the task sequence is created, a progress bar is displayed on this page.
+  * **Confirmation** – When the task sequence creation completes, the success of the process is displayed on this page. Click **Finish** to complete the New Task Sequence Wizard.
+2. Select the **Task Sequences** folder, right-click the new task sequence you created, and then click **Properties**.
+3. Select the **Task Sequence** tab to view the steps that are included in the Standard Client Task Sequence template, as shown in Figure 10.
+
+   ![Enable Windows Update in the reference image task sequence](images\surface-deploymdt-fig10.png "Enable Windows Update in the reference image task sequence")
+
+   *Figure 10. Enable Windows Update in the reference image task sequence*
+
+4. Select the **Windows Update (Pre-Application Installation)** option, located under the **State Restore** folder.
+5. Click the **Options** tab, and then clear the **Disable This Step** check box.
+6. Repeat Step 4 and Step 5 for the **Windows Update (Post-Application Installation)** option.
+7. Click **OK** to apply changes to the task sequence, and then close the task sequence properties window.
+
+### Generate and import MDT boot media
+
+To boot the reference virtual machine from the network, the MDT deployment share first must be updated to generate boot media with the resources that have been added in the previous sections.
+
+To update the MDT boot media, follow these steps:
+
+1. Right-click the deployment share in the Deployment Workbench, and then click **Update Deployment Share** to start the Update Deployment Share Wizard, as shown in Figure 11.
+
+   ![Generate boot images with the Update Deployment Share Wizard](images\surface-deploymdt-fig11.png "Generate boot images with the Update Deployment Share Wizard")
+
+   *Figure 11. Generate boot images with the Update Deployment Share Wizard*
+
+2. Use the Update Deployment Share Wizard to create boot images with the following process:
+  * **Options** – Click **Completely Regenerate the Boot Images**, and then click **Next**.
+  >**Note:**&nbsp;&nbsp;Because this is the first time the newly created deployment share has been updated, new boot images will be generated regardless of which option you select on the **Options** page.
+  * **Summary** – Review the specified options on this page before you click **Next** to begin generation of boot images.
+  * **Progress** – While the boot images are being generated, a progress bar is displayed on this page.
+  * **Confirmation** – When the boot images have been generated, the success of the process is displayed on this page. Click **Finish** to complete the Update Deployment Share Wizard.
+3. Confirm that boot images have been generated by navigating to the deployment share in File Explorer and opening the Boot folder. The following files should be displayed, as shown in Figure 12:
+  * **LiteTouchPE_x86.iso**
+  * **LiteTouchPE_x86.wim**
+  * **LiteTouchPE_x64.iso**
+  * **LiteTouchPE_x64.wim**
+
+
+   ![Boot images in the Boot folder after Update Deployment Share Wizard completes](images\surface-deploymdt-fig12.png "Boot images in the Boot folder after Update Deployment Share Wizard completes")
+
+   *Figure 12. Boot images displayed in the Boot folder after completion of the Update Deployment Share Wizard*
+
+To import the MDT boot media into WDS for PXE boot, follow these steps:
+
+1. Open Windows Deployment Services from the Start menu or Start screen.
+2. Expand **Servers** and your deployment server.
+3. Click the **Boot Images** folder, as shown in Figure 13.
+
+   ![Start the Add Image Wizard from the Boot Images folder](images\surface-deploymdt-fig13.png "Start the Add Image Wizard from the Boot Images folder")
+
+   *Figure 13. Start the Add Image Wizard from the Boot Images folder*
+
+4. Right-click the **Boot Images** folder, and then click **Add Boot Image** to open the Add Image Wizard, as shown in Figure 14.
+
+   ![Import the LiteTouchPE_x86.wim MDT boot image](images\surface-deploymdt-fig14.png "Import the LiteTouchPE_x86.wim MDT boot image")
+
+   *Figure 14. Import the LiteTouchPE_x86.wim MDT boot image*
+
+5. The Add Image Wizard displays a series of steps, as follows:
+  * **Image File** – Click **Browse** and navigate to the **Boot** folder in your deployment share, click **LiteTouchPE_x86.wim**, click **Open**, and then click **Next**.
+  * **Image Metadata** – Enter a name and description for the MDT boot media, or click **Next** to accept the default options.
+  * **Summary** – Review your selections to import a boot image into WDS, and then click **Next**.
+  * **Task Progress** – A progress bar is displayed as the selected image file is copied into the WDS remote installation folder. Click **Finish** when the task is complete to close the Add Image Wizard.
+
+>**Note:**&nbsp;&nbsp;Only the 32-bit boot image, LiteTouchPE_x86.wim, is required to boot from BIOS devices, including Generation 1 Hyper-V virtual machines like the reference virtual machine.
+
+If your WDS configuration is properly set up to respond to PXE clients, you should now be able to boot from the network with any device with a network adapter properly configured for network boot (PXE).
+
+>**Note:**&nbsp;&nbsp;If your WDS server resides on the same server as DHCP or in a different subnet than the devices you are attempting to boot, additional configuration may be required. For more information, see [Managing Network Boot Programs](https://technet.microsoft.com/library/cc732351).
+
+### Deploy and capture a reference image
+
+Your deployment environment is now set up to create a reference image for Windows 10 complete with Windows Updates.
+
+>**Note:**&nbsp;&nbsp;You cannot install version updates (such as Windows 10, Version 1511) in a reference image. To create a reference image with a new version of Windows, you must use installation files from that version of Windows. When  you install a version update in Windows, it effectively performs an upgrade to a new version of Windows, and upgraded installations of Windows cannot be prepared for deployment with Sysprep.<br/><br/>
+By using a fully automated task sequence in an MDT deployment share dedicated to reference image creation, you can greatly reduce the time and effort required to create new reference images and it is the best way to ensure that your organization is ready for feature updates and new versions of Windows 10.
+
+You can now boot from the network with a virtual machine to run the prepared task sequence and generate a reference image. When you prepare your virtual machine in Hyper-V for reference image creation, consider the following:
+
+* Use a Generation 1 virtual machine for the simplicity of drivers and to ensure maximum compatibility with both BIOS and UEFI devices.
+* Ensure your virtual machine has at least 1 GB of system memory at boot. You can ensure that the virtual machine has at least 1 GB of memory at boot but allow the memory to adjust after boot by using Dynamic Memory. You can read more about Dynamic Memory in the [Hyper-V Dynamic Memory Overview](https://technet.microsoft.com/library/hh831766).
+* Ensure your virtual machine uses a legacy network adapter to support network boot (PXE); that network adapter should be connected to the same network as your deployment server, and that network adapter should receive an IP address automatically via DHCP.
+* Configure your boot order such that PXE Boot is the first option.
+
+When your virtual machine (VM) is properly configured and ready, start or boot the VM and be prepared to press the F12 key when prompted to boot via PXE from the WDS server.
+
+Perform the reference image deployment and capture using the following steps:
+
+1. Start your virtual machine and press the F12 key when prompted to boot to the WDS server via PXE, as shown in Figure 15.
+
+   ![Start network boot by pressing the F12 key](images\surface-deploymdt-fig15.png "Start network boot by pressing the F12 key")
+
+   *Figure 15. Start network boot by pressing the F12 key*
+
+2. Click **Run the Deployment Wizard to Install a New Operating System** to begin the MDT deployment process.
+3. Enter your MDT username and password, a user with rights to access the MDT deployment share over the network and with rights to write to the Captures folder in the deployment share.
+4. After your credentials are validated, the Windows Deployment Wizard will start and process the boot and deployment share rules.
+5. The Windows Deployment Wizard displays a series of steps, as follows:
+  * **Task Sequence** – Select the task sequence you created for reference image creation (it should be the only task sequence available), and then click **Next**.
+  * **Computer Details** – Leave the default computer name, workgroup name, and the **Join a Workgroup** option selected, and then click **Next**. The computer name and workgroup will be reset when the image is prepared by Sysprep and captured.
+  * **Move Data and Settings** – Leave the default option of **Do Not Move User Data and Settings** selected, and then click **Next**.
+  * **User Data (Restore)** – Leave the default option of **Do Not Restore User Data and Settings** selected, and then click **Next**.
+  * **Locale and Time** – Leave the default options for language and time settings selected. The locale and time settings will be specified during deployment of the image to other devices. Click **Next**.
+  * **Capture Image** – Click the **Capture an Image of this Reference Computer** option, as shown in Figure 16. In the **Location** field, keep the default location of the Captures folder. You can keep or change the name of the image file in the **File Name** field. When you are finished, click **Next**.
+  
+  ![Capture an image of the reference machine](images\surface-deploymdt-fig16.png "Capture an image of the reference machine")
+    
+  *Figure 16. Use the Capture Image page to capture an image of the reference machine after deployment*
+
+  * **Ready** – You can review your selections by expanding **Details** on the **Ready** page. Click **Begin** when you are ready to perform the deployment and capture of your reference image.
+
+6. Your reference task sequence will run with the specified options.
+
+As the task sequence processes the deployment, it will automatically perform the following tasks:
+* Install the Windows 10 image from the installation files you supplied
+* Reboot into Windows 10
+* Run Windows updates until all Windows updates have been installed and the Windows environment is fully up to date
+* Run Sysprep and prepare the Windows 10 environment for deployment
+* Reboot into WinPE
+* Capture an image of the Windows 10 environment and store it in the Captures folder in the MDT deployment share
+
+>**Note:**&nbsp;&nbsp;The Windows Update process can take some time to complete as it searches the Internet for updates, downloads those updates, and then installs them. By performing this process now, in the reference environment, you eliminate the need to perform these tasks on each deployed device and significantly reduce the amount of time and bandwidth required to perform your deployment. 
+
+When the task sequence completes, your virtual machine will be off and a new reference image complete with updates will be ready in your MDT deployment share for you to import it and prepare your deployment environment for deployment to Surface devices.
+
+## Deploy Windows 10 to Surface devices
+
+With a freshly prepared reference image, you are now ready to configure the deployment process for deployment to the Surface devices. Use the steps detailed in this section to produce a deployment process that requires minimal effort on each Surface device to produce a complete and ready-to-use Windows 10 environment.
+
+### Import reference image
+
+After the reference image has been created and stored in the Captures folder, you need to add it to your MDT deployment share as an image for deployment. You perform this task by using the same process that you used to import the installation files for Windows 10.
+
+To import the reference image for deployment, use the following steps:
+
+1. Right-click the **Operating Systems** folder under your deployment share in the Deployment Workbench or the folder you created in when you imported Windows 10 installation files, and then click **Import Operating System** to start the Import Operating System Wizard. 
+2. Import the custom image with the Import Operating System Wizard by using the following steps:
+  * **OS Type** – Select Custom Image File to specify that you are importing the Windows source files from installation media, and then click **Next**.
+  * **Image** – Click **Browse**, and then navigate to and select the image file in the **Captures** folder in your deployment share. Select the **Move the Files to the Deployment Share Instead of Copying Them** checkbox if desired. Click **Next**. 
+  * **Setup** – Click **Setup Files are not Neededf**, and then click **Next**.
+  * **Destination** – Enter a name for the new folder that will be created to hold the image file, and then click **Next**.
+  * **Summary** – Review the specified configuration on this page before you click **Next** to begin the import process.
+  * **Progress** – While the image is imported, a progress bar is displayed on this page.
+  * **Confirmation** – When the import process completes, the success of the process is displayed on this page. Click **Finish** to complete the Import Operating System Wizard.
+3.	Expand the folder in which you imported the image to verify that the import completed successfully.
+
+>**Note:**&nbsp;&nbsp;You can import the reference image into the same deployment share that you used to create your reference image, or you could import the reference image into a new deployment share for deployment to your Surface devices. If you chose to create a new deployment share for deployment of your reference image, remember that you still need to import a full set of installation files from installation media.
+
+Now that your updated reference image is imported, it is time to prepare your deployment environment for deployment to Surface devices complete with drivers, applications, and automation.
+
+### Import Surface drivers
+
+Before you can deploy your updated reference image to Surface devices, or any physical environment, you need to supply MDT with the drivers that Windows will use to communicate with that physical environment. For Surface devices you can download all of the drivers required by Windows in a single archive (.zip) file in a format that is ready for deployment. In addition to the drivers that are used by Windows to communicate with the hardware and components, Surface firmware and driver packs also include updates for the firmware of those components. By installing the Surface firmware and driver pack, you will also bring your device’s firmware up to date. If you have not done so already, download the drivers for your Surface device listed 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).
+
+Many devices require that you import drivers specifically for WinPE in order for the MDT boot media to communicate with the deployment share and to boot properly on that device. Even Surface Pro 3 required that network drivers be imported specifically for WinPE for deployment of Windows 8.1. Fortunately, for Windows 10 deployments to Surface devices, all of the required drivers for operation of WinPE are contained within the out-of-box drivers that are built into Windows 10. It is still a good idea to prepare your environment with folder structure and selection profiles that allow you to specify drivers for use in WinPE. You can read more about that folder structure in **Step 5: Prepare the drivers repository** in [Deploy a Windows 10 image using MDT 2013 Update 2](https://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt/#sec05).
+
+To import the Surface drivers (in this example, Surface Pro 4) into MDT, follow these steps:
+
+1. Extract the downloaded archive (.zip) file to a folder that you can easily locate. Keep the driver files separate from other drivers or files.
+2. Open the Deployment Workbench and expand the Deployment Shares node and your deployment share. 
+3. If you have not already created a folder structure by operating system version, you should do so now and create under the Windows 10 x64 folder a new folder for Surface Pro 4 drivers named Surface Pro 4. Your Out-of-Box Drivers folder should resemble the following structure, as shown in Figure 17:
+   * WinPE x86
+   * WinPE x64
+   * Windows 10 x64
+     * Microsoft Corporation
+       * Surface Pro 4
+
+   ![Recommended folder structure for drivers](images\surface-deploymdt-fig17.png "Recommended folder structure for drivers")
+
+   *Figure 17. The recommended folder structure for drivers*
+
+4. Right-click the **Surface Pro 4** folder, and then click **Import Drivers** to start the Import Drivers Wizard, as shown in Figure 18.
+
+   ![Progress page during drivers import](images\surface-deploymdt-fig18.png "Progress page during drivers import")
+
+   *Figure 18. The Progress page during drivers import*
+
+5. The Import Driver Wizard displays a series of steps, as follows:
+  * **Specify Directory** – Click **Browse** and navigate to the folder where you extracted the Surface Pro 4 firmware and drivers in Step 1.
+  * **Summary** – Review the specified configuration on this page before you click **Next** to begin the import process.
+  * **Progress** – While the drivers are imported, a progress bar is displayed on this page.
+  * **Confirmation** – When the import process completes, the success of the process is displayed on this page. Click **Finish** to complete the Import Drivers Wizard.
+6.	Click the **Surface Pro 4** folder and verify that the folder now contains the drivers that were imported, as shown in Figure 19.
+
+   ![Drivers for Surface Pro 4 imported and organized in the MDT deployment share](images\surface-deploymdt-fig19.png "Drivers for Surface Pro 4 imported and organized in the MDT deployment share")
+
+   *Figure 19. Drivers for Surface Pro 4 imported and organized in the MDT deployment share*
+
+### Import applications
+
+You can import any number of applications into MDT for installation on your devices during the deployment process. You can configure your applications and task sequences to prompt you during deployment to pick and choose which applications are installed, or you can use your task sequence to explicitly define which applications are installed. For more information, see **Step 4: Add an application** in [Deploy a Windows 10 image using MDT 2013 Update 2](https://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt/#sec04).
+
+#### Import Microsoft Office 365 Installer
+
+The Office Deployment Tool is a free download available in the Microsoft Download Center that allows IT professionals and system administrators to download and prepare Office installation packages for Office Click-to-Run. You can find the Office Deployment Tool and instructions to download Click-to-Run for Office 365 installation source files at [Download Click-to-Run for Office 365 products by using the Office Deployment Tool](https://technet.microsoft.com/library/jj219424).
+
+Download and install the version of Office Deployment Tool (ODT), for Office 2013 or Office 2016, that fits your organization’s needs and use the steps provided by that page to download the Office installation files for use with MDT.
+
+After you have downloaded the source files for your version of Office Click-to-Run, you need to edit the Configuration.xml file with instructions to install Office Click-to-Run silently. To configure the Office Deployment Tool for silent installation, follow these steps:
+
+1. Right-click the existing **Configuration.xml** file, and then click **Edit**.
+2. This action opens the file in Notepad. Replace the existing text with the following:
+  ```
+   <Configuration> 
+   <Add OfficeClientEdition="32">  
+    <Product ID="O365ProPlusRetail" >  
+     <Language ID="en-us" />        
+    </Product>  
+   </Add> 
+   <Display Level="None" AcceptEULA="TRUE" /> </Configuration>
+```
+
+3. Save the file.
+
+The default behavior of Setup.exe is to look for the source files in the path that contains **Setup.exe**. If the installation files are not found in this folder, the Office Deployment Tool will default to online source files from an Internet connection.
+
+For MDT to perform an automated installation of office, it is important to configure the **Display Level** option to a value of **None**. This setting is used to suppress the installation dialog box for silent installation. It is required that the **AcceptEULA** option is set to **True** to accept the license agreement when the **Display Level** option is set to **None**. With both of these options configured, the installation of Office will occur without the display of dialog boxes which could potentially cause the installation to pause until a user can address an open dialog box.
+
+Now that the installation and configuration files are prepared, the application can be imported into the deployment share by following these steps:
+
+1. Open the Deployment Workbench. 
+2. Expand the deployment share, right-click the **Applications** folder, and then click **New Application** to start the New Application Wizard, as shown in Figure 20.
+
+   ![Enter the command and directory for Office 2016 Click-to-Run](images\surface-deploymdt-fig20.png "Enter the command and directory for Office 2016 Click-to-Run")
+
+   *Figure 20. Enter the command and directory for Office 2016 Click-to-Run*
+
+3. The New Application Wizard walks you through importing the Office 2016 Click-to-Run files, as follows:
+  * **Application Type** – Click **Application with Source Files**, and then click **Next**.
+  * **Details** – Enter a name for the application (for example, Office 2016 Click-to-Run) in the **Application Name** field. Enter publisher, version, and language information in the **Publisher**, **Version**, and **Language** fields if desired. Click **Next**.
+  * **Source** – Click **Browse** to navigate to and select the folder where you downloaded the Office installation files with the Office Deployment Tool, and then click **Next**.
+  * **Destination** – Enter a name for the folder where the application files will be stored in the **Specify the Name of the Directory that Should Be Created** field or click **Next** to accept the default name.
+  * **Command Details** – Enter the Office Deployment Tool installation command line:
+
+     `Setup.exe /configure configuration.xml`
+
+  * **Summary** – Review the specified configuration on this page before you click **Next** to begin the import process.
+  * **Progress** – While the installation files are imported, a progress bar is displayed on this page.
+  * **Confirmation** – When the import process completes, the success of the process is displayed on this page. Click **Finish** to complete the New Application Wizard.
+
+4. You should now see the **Office 2016 Click-to-Run** item under the **Applications** folder in the Deployment Workbench.
+
+#### Import Surface app installer
+
+The Surface app is a Windows Store app that provides the user with greater control over specific Surface device functions and capabilities (for example, control over the sensitivity of the Surface Pen). It is a highly recommended app for Surface devices to provide end users with the best experience and greatest control over their device. Find out more about the Surface app at [Install and use the Surface app](https://www.microsoft.com/surface/en-us/support/apps-and-windows-store/surface-app?os=windows-10).
+
+To perform a deployment of the Surface app, you will need to download the app files through Windows Store for Business. You can find detailed instructions on how to download the Surface app through Windows Store for Business at [Deploy Surface app with Windows Store for Business](https://technet.microsoft.com/en-us/itpro/surface/deploy-surface-app-with-windows-store-for-business).
+
+After you have downloaded the installation files for Surface app, including the AppxBundle and license files, you can import these files into the deployment share through the same process as a desktop application like Microsoft Office. Both the AppxBundle and license files must be together in the same folder for the import process to complete successfully. Use the following command on the **Command Details** page to install the Surface app:
+   ```
+DISM.exe /Online /Add-ProvisionedAppxPackage /PackagePath: Microsoft.SurfaceHub_10.0.342.0_neutral_~_8wekyb3d8bbwe.AppxBundle /LicensePath: Microsoft.SurfaceHub_8wekyb3d8bbwe_a53ef8ab-9dbd-dec1-46c5-7b664d4dd003.xml
+   ```
+
+### Create deployment task sequence
+
+The next step in the process is to create the deployment task sequence. This task sequence will be configured to completely automate the deployment process and will work along with customized deployment share rules to reduce the need for user interaction down to a single touch. Before you can make  customizations to include all of this automation, the new task sequence has to be created from a template.
+
+To create the deployment task sequence, follow these steps:
+1. In the Deployment Workbench, under your Deployment Share, right-click the **Task Sequences** folder, and then click **New Task Sequence** to start the New Task Sequence Wizard.
+2. Use these steps to create the deployment task sequence with the New Task Sequence Wizard:
+  * **General Settings** – Enter an identifier for the deployment task sequence in the **Task Sequence ID** field, a name for the deployment task sequence in the **Task Sequence Name** field, and any comments for the deployment task sequence in the **Task Sequence Comments** field, then click **Next**.
+  >**Note:**&nbsp;&nbsp;The **Task Sequence ID** field cannot contain spaces and can be a maximum of 16 characters.
+  * **Select Template** – Click **Standard Client Task Sequence** from the drop-down menu, and then click **Next**.
+  * **Select OS** – Navigate to and select the reference image that you imported, and then click **Next**.
+  * **Specify Product Key** – Select the product key entry that fits your organization's licensing system. The **Do Not Specify a Product Key at This Time** option can be used for systems that will be activated via Key Management Services (KMS) or Active Directory Based Activation (ADBA). A product key can be specified specifically if your organization uses Multiple Activation Keys (MAK). Click **Next**.
+  * **OS Settings** – Enter a name and organization for registration of Windows, and a home page URL for users when they browse the Internet in the **Full Name**, **Organization**, and **Internet Explorer Home Page** fields, and then click **Next**.
+  * **Admin Password** – Click **Use the Specified Local Administrator Password**, enter a password in the provided field, and then click **Next**.
+  * **Summary** – Review the specified configuration on this page before you click **Next** to begin creation of the task sequence.
+  * **Progress** – While the task sequence is being created, a progress bar is displayed on this page.
+  * **Confirmation** – When the task sequence creation completes, the success of the process is displayed on this page. Click **Finish** to complete the New Task Sequence Wizard.
+
+After the task sequence is created it can be modified for increased automation, such as the installation of applications without user interaction, the selection of drivers, and the installation of Windows updates.
+
+1. Click the **Task Sequences** folder, right-click the new task sequence you created, and then click **Properties**.
+2. Click the **Task Sequence** tab to view the steps that are included in the new task sequence.
+3. Click the **Windows Update (Pre-Application Installation)** step, located under the **State Restore** folder.
+4. Click the **Options** tab, and then clear the **Disable This Step** check box.
+5. Repeat Step 4 and Step 5 for the **Windows Update (Post-Application Installation)** option.
+6. Between the two **Windows Update** steps is the **Install Applications** step. Click the **Install Applications** step, and then click **Add**.
+7. Hover the mouse over **General** under the **Add** menu, and then click **Install Application**. This will add a new step after the selected step for the installation of a specific application as shown in Figure 21.
+
+   ![A new Install Application step in the deployment task sequence](images\surface-deploymdt-fig21.png "A new Install Application step in the deployment task sequence")
+
+   *Figure 21. A new Install Application step in the deployment task sequence*
+
+8. On the **Properties** tab of the new **Install Application** step, enter **Install Microsoft Office 2016 Click-to-Run** in the **Name** field.
+9. Click **Install a Single Application**, and then click **Browse** to view available applications that have been imported into the deployment share.
+10.	Select Office 2016 Click-to-Run from the list of applications, and then click **OK**.
+11.	Repeat Steps 6 through 10 for the Surface app.
+12.	Expand the **Preinstall** folder, and then click the **Enable BitLocker (Offline)** step.
+13.	Open the **Add** menu again and choose **Set Task Sequence Variable** from under the **General** menu.
+14. On the **Properties** tab of the new **Set Task Sequence Variable** step (as shown in Figure 22), configure the following options:
+  * **Name** – Set DriverGroup001
+  * **Task Sequence Variable** – DriverGroup001
+  * **Value** – Windows 10 x64\%Make%\%Model%
+
+   ![Configure a new Set Task Sequence Variable step in the deployment task sequence](images\surface-deploymdt-fig22.png "Configure a new Set Task Sequence Variable step in the deployment task sequence")
+
+   Figure 22. Configure a new Set Task Sequence Variable step in the deployment task sequence
+
+15.	Select the **Inject Drivers** step, the next step in the task sequence.
+16.	On the **Properties** tab of the **Inject Drivers** step (as shown in Figure 23), configure the following options:
+  * In the **Choose a selection profile** drop-down menu, select **Nothing**.
+  * Click the **Install all drivers from the selection profile** button.
+
+   ![Configure deployment task sequence not to choose the drivers to inject into Windows](images\surface-deploymdt-fig23.png "Configure deployment task sequence not to choose the drivers to inject into Windows")
+
+   *Figure 23. Configure the deployment task sequence not to choose the drivers to inject into Windows*
+
+17.	Click **OK** to apply changes to the task sequence and close the task sequence properties window.
+
+### Configure deployment share rules
+
+The experience of users during a Windows deployment is largely governed by a set of rules that control how the MDT and Windows Deployment Wizard experience should proceed. These rules are stored in two configuration files. Boot media rules are stored in the Bootstrap.ini file that is processed when the MDT boot media is first run. Deployment share rules are stored in the Customsettings.ini file and tell the Windows Deployment Wizard how to operate (for example, what screens to show and what questions to ask). By using these the rules stored in these two files, you can completely automate the process of deployment to where you will not be asked to supply the answer to any questions during deployment and the deployment will perform all tasks completely on its own.
+
+#### Configure Bootstrap.ini
+
+Bootstrap.ini is the simpler of the two rule files. The purpose it serves is to provide instructions from when the MDT boot media starts on a device until the Windows Deployment Wizard is started. The primary use of this file is to provide the credentials that will be used to log on to the deployment share and start the Windows Deployment Wizard.
+
+To automate the boot media rules, follow these steps:
+
+1. Right-click your deployment share in the Deployment Workbench, and then click **Properties**.
+2. Click the **Rules** tab, and then click **Edit Bootstrap.ini** to open Bootstrap.ini in Notepad.
+3. Replace the text of the Bootstrap.ini file with the following text:
+
+  ```
+  [Settings]
+  Priority=Model,Default
+
+  [Surface Pro 4]
+  DeployRoot=\\STNDeployServer\DeploymentShare$
+  UserDomain=STNDeployServer
+  UserID=MDTUser
+  UserPassword=P@ssw0rd
+  SkipBDDWelcome=YES
+
+  [Surface Pro 4]
+  DeployRoot=\\STNDeployServer\DeploymentShare$
+  ```
+
+4. Press Ctrl+S to save Bootstrap.ini, and then close Notepad.
+
+You can use a number of variables in both boot media and deployment share rules to apply rules only when certain conditions are met. For example, you can use MAC addresses to identify specific machines where MDT will run fully automated, but will run with required user interaction on all other devices. You can also use the model of the device to instruct the MDT boot media to perform different actions based on computer model, much as the way **[Surface Pro 4]** is listed in Step 3. You can use the following cmdlet in a PowerShell session to see what the Model variable would be on a device:
+   
+```wmic csproduct get name```
+
+Rules used in the text shown in Step 3 include:
+
+* **DeployRoot** – Used to specify the deployment share that the MDT boot media will connect to.
+* **UserDomain** – Used to specify the domain or computer where the MDT user account is located.
+* **UserID** – Used to specify the MDT user account for automatic logon to the deployment share.
+* **UserPassword** – Used to specify the MDT user password for automatic logon to the deployment share.
+* **SkipBDDWelcome** – Used to skip the Welcome page and to start the Windows Deployment Wizard immediately using the specified credentials and deployment share.
+
+#### Configure CustomSettings.ini
+
+The bulk of the rules used to automate the MDT deployment process are stored in the deployment share rules, or the Customsettings.ini file. In this file you can answer and hide all of the prompts from the Windows Deployment Wizard, which yields a deployment experience that mostly consists of a progress bar that displays the automated actions occurring on the device. The deployment share rules are shown directly in the **Rules** tab of the deployment share properties, as shown in Figure 24.
+
+![Deployment share rules configured for automation of the Windows Deployment Wizard](images\surface-deploymdt-fig24.png "Deployment share rules configured for automation of the Windows Deployment Wizard")
+
+*Figure 24. Deployment share rules configured for automation of the Windows Deployment Wizard*
+
+To configure automation for the production deployment, copy and paste the following text into the text box on the **Rules** tab of your deployment share properties:
+
+   ```
+[Settings]
+Priority=Model,Default
+Properties=MyCustomProperty
+
+[Surface Pro 4]
+SkipTaskSequence=YES
+TaskSequenceID=Win10SP4
+
+[Default]
+OSInstall=Y
+SkipCapture=YES
+SkipAdminPassword=YES
+SkipProductKey=YES
+SkipComputerBackup=YES
+SkipBitLocker=YES
+SkipBDDWelcome=YES
+SkipUserData=YES
+UserDataLocation=AUTO
+SkipApplications=YES
+SkipPackageDisplay=YES
+SkipComputerName=YES
+SkipDomainMembership=YES
+JoinDomain=contoso.com
+DomainAdmin=MDT
+DomainAdminDomain=contoso
+DomainAdminPassword=P@ssw0rd
+SkipLocaleSelection=YES
+KeyboardLocale=en-US
+UserLocale=en-US
+UILanguage=en-US
+SkipTimeZone=YES
+TimeZoneName=Pacific Standard Time
+UserID=MDTUser
+UserDomain=STNDeployServer
+UserPassword=P@ssw0rd
+SkipSummary=YES
+SkipFinalSummary=YES
+FinishAction=LOGOFF
+   ```
+Rules used in this example include:
+
+* **SkipTaskSequence** – This rule is used to skip the **Task Sequence** page where the user would have to select between available task sequences.
+* **TaskSequenceID** – This rule is used to instruct the Windows Deployment Wizard to run a specific task sequence. In this scenario the task sequence ID should match the deployment task sequence you created in the previous section.
+* **OSInstall** – This rule indicates that the Windows Deployment Wizard will be performing an operating system deployment.
+* **SkipCapture** – This rule prevents the **Capture Image** page from being displayed, prompting the user to create an image of this device after deployment.
+* **SkipAdminPassword** – This rule prevents the **Admin Password** page from being displayed. The Administrator password specified in the task sequence will still be applied.
+* **SkipProductKey** – This rule prevents the **Specify Product Key** page from being displayed. The product key specified in the task sequence will still be applied.
+* **SkipComputerBackup** – This rule prevents the **Move Data and Settings** page from being displayed, where the user is asked if they would like to make a backup of the computer before performing deployment.
+* **SkipBitLocker** – This rule prevents the **BitLocker** page from being displayed, where the user is asked if BitLocker Drive Encryption should be used to encrypt the device.
+* **SkipBDDWelcome** – This rule prevents the **Welcome** page from being displayed, where the user is prompted to begin Windows deployment.
+* **SkipUserData** – This rule prevents the **User Data (Restore)** page from being displayed, where the user is asked to restore previously backed up user data in the new environment.
+* **UserDataLocation** – This rule prevents the user from being prompted to supply a location on the User Data (Restore) page.
+* **SkipApplications** – This rule prevents the **Applications** page from being displayed, where the user is prompted to select from available applications to be installed in the new environment.
+* **SkipPackageDisplay** – This rule prevents the **Packages** page from being displayed, where the user is prompted to select from available packages to be installed in the new environment.
+* **SkipComputerName** – This rule, when combined with the **SkipDomainMembership** rule, prevents the **Computer Details** page from being displayed, where the user is asked to supply computer name and join a domain or workgroup.
+* **SkipDomainMembership** – This rule, when combined with the **SkipComputerName** rule, prevents the **Computer Details** page from being displayed, where the user is asked to supply computer name and join a domain or workgroup.
+* **JoinDomain** – This rule instructs the Windows Deployment Wizard to have the computer join the specified domain using the specified credentials. 
+* **DomainAdmin** – This rule specifies the username for the domain join operation.
+* **DomainAdminDomain** – This rule specifies the domain for the username for the domain join operation.
+* **DomainAdminPassword** – This rule specifies the password for the username for the domain join operation.
+* **SkipLocaleSelection** –  This rule, along with the **SkipTimeZone** rule, prevents the **Locale and Time** page from being displayed.
+* **KeyboardLocale** – This rule is used to specify the keyboard layout for the deployed Windows environment.
+* **UserLocale** – This rule is used to specify the geographical locale for the deployed Windows environment.
+* **UILanguage** – This rule is used to specify the language to be used in the deployed Windows environment.
+* **SkipTimeZone** –  This rule, along with the **SkipLocaleSelection** rule, prevents the **Locale and Time** page from being displayed.
+* **TimeZoneName** – This rule is used to specify the time zone for the deployed Windows environment.
+* **UserID** – This rule is used to supply the username under which the MDT actions and task sequence steps are performed.
+* **UserDomain** – This rule is used to supply the domain for the username under which the MDT actions and task sequence steps are performed.
+* **UserPassword** – This rule is used to supply the password for the username under which the MDT actions and task sequence steps are performed.
+* **SkipSummary** – This rule prevents the **Summary** page from being displayed before the task sequence is run, where the user is prompted to confirm the selections before beginning the task sequence.
+* **SkipFinalSummary** – This rule prevents the **Summary** page from being displayed when the task sequence has completed.
+* **FinishAction** – This rule specifies whether to log out, reboot, or shut down the device after the task sequence has completed.
+
+You can read about all of the possible deployment share and boot media rules in the [Microsoft Deployment Toolkit Reference](https://technet.microsoft.com/library/dn781091).
+
+### Update and import updated MDT boot media
+
+The process to update MDT boot media with these new rules and changes to the deployment share is very similar to the process to generate boot media from scratch.
+
+To update the MDT boot media, follow these steps:
+
+1. Right-click the deployment share in the Deployment Workbench, and then click **Update Deployment Share** to start the Update Deployment Share Wizard.
+2. The Update Deployment Share Wizard displays a series of steps, as follows:
+  * **Options** – Choose between the **Completely Regenerate the Boot Images** or **Optimize the Boot Image Updating Process** options. Completely regenerating the boot images will take more time, but produces boot media that is not fragmented and does not contain out of date components. Optimizing the boot image updating process will proceed more quickly, but may result in longer load times when booting via PXE. Click **Next**.
+  * **Summary** – Review the specified options on this page before you click **Next** to begin the update of boot images.
+  * **Progress** – While the boot images are being updated a progress bar is displayed on this page.
+  * **Confirmation** – When the boot images have been updated, the success of the process is displayed on this page. Click **Finish** to complete the Update Deployment Share Wizard.
+
+To import the updated MDT boot media into WDS for PXE boot, follow these steps:
+
+1. Open Windows Deployment Services from the Start menu or Start screen.
+2. Expand **Servers** and your deployment server.
+3. Click the **Boot Images** folder.
+4. Right-click the existing MDT boot image, and then click **Replace Image** to open the Replace Boot Image Wizard.
+5. Replace the previously imported MDT boot image with the updated version by using these steps in the Replace Boot Image Wizard:
+  * **Image File** – Click **Browse** and navigate to the **Boot** folder in your deployment share, click **LiteTouchPE_x86.wim**, and then click **Open**. Click **Next**.
+  * **Available Images** – Only one image should be listed and selected **LiteTouch Windows PE (x86)**, click **Next**.
+  * **Image Metadata** – Enter a name and description for the MDT boot media, or click **Next** to accept the default options.
+  * **Summary** – Review your selections for importing a boot image into WDS, and then click **Next**.
+  * **Task Progress** – A progress bar is displayed as the selected image file is copied into the WDS remote installation folder. Click **Finish** when the task is complete to close the Replace Boot Image Wizard.
+6. Right-click the **Boot Images** folder, and then click **Add Image** to open the Add Image Wizard.
+7. Add the new 64-bit boot image for 64-bit UEFI device compatibility with the Add Image Wizard , as follows:
+  * **Image File** – Click **Browse** and navigate to the **Boot** folder in your deployment share, select **LiteTouchPE_x64.wim**, and then click **Open**. Click **Next**.
+  * **Image Metadata** – Enter a name and description for the MDT boot media, or click **Next** to accept the default options.
+  * **Summary** – Review your selections to import a boot image into WDS, and then click **Next**.
+  * **Task Progress** – A progress bar is displayed as the selected image file is copied into the WDS remote installation folder. Click **Finish** when the task is complete to close the Add Image Wizard.
+
+>**Note:**&nbsp;&nbsp;Although it is a best practice to replace and update the boot images in WDS whenever the MDT deployment share is updated, for deployment to Surface devices the 32-bit boot image, LiteTouchPE_x86.wim, is not required. Only the 64-bit boot image is required for 64-bit UEFI devices.
+
+### Deploy Windows to Surface
+
+With all of the automation provided by the deployment share rules and task sequence, performing the deployment on each Surface device becomes as easy as a single touch.
+
+>**Note:**&nbsp;&nbsp;For the deployment to require only a single touch, the Surface devices must be connected to a keyboard, connected to the network with a Microsoft Surface USB Ethernet Adapter or Surface Dock, and configured with PXE boot as the first boot option, as shown in Figure 25.
+
+![Set boot priority for PXE boot](images\surface-deploymdt-fig25.png "Set boot priority for PXE boot")
+
+*Figure 25. Setting boot priority for PXE boot*
+
+On a properly configured Surface device, simply turn on the device and press Enter when you are prompted to boot from the network. The fully automated MDT deployment process will then take over and perform the following tasks:
+
+* The MDT boot media will be loaded to your Surface device via the network
+* The MDT boot media will use the provided credentials and rules to connect to the MDT deployment share
+* The task sequence and drivers will be automatically selected for your device via make and model information
+* The task sequence will deploy your updated Windows 10 image to the device complete with the selected drivers
+* The task sequence will join your device to the domain
+* The task sequence will install the applications you specified, Microsoft Office and Surface app
+* Windows Update will run, installing any new Windows Updates or updates for installed applications, like Microsoft Office
+* The task sequence will complete silently and log out of the device
+
+>**Note:**&nbsp;&nbsp;For Surface devices not configured to boot to the network as the first boot option, you can hold Volume Down and press Power to boot the system immediately to a USB or network device.
+
+The resulting configuration is a Surface device that is logged out and ready for an end user to enter their credentials, log on, and get right to work. The applications and drivers they need are already installed and up to date.
+
+
+
+
diff --git a/devices/surface/enroll-and-configure-surface-devices-with-semm.md b/devices/surface/enroll-and-configure-surface-devices-with-semm.md
new file mode 100644
index 0000000000..08696c682d
--- /dev/null
+++ b/devices/surface/enroll-and-configure-surface-devices-with-semm.md
@@ -0,0 +1,135 @@
+---
+title: Enroll and configure Surface devices with SEMM (Surface)
+description: Learn how to create a Surface UEFI configuration package to control the settings of Surface UEFI, as well as enroll a Surface device in SEMM.
+keywords: surface enterprise management
+ms.prod: w10
+ms.mktglfcycl: manage
+ms.pagetype: surface, devices, security
+ms.sitesec: library
+author: jobotto
+---
+
+# Enroll and configure Surface devices with SEMM
+
+With Microsoft Surface Enterprise Management Mode (SEMM), you can securely configure the settings of Surface UEFI on a Surface device and manage those settings on Surface devices in your organization. When a Surface device is managed by SEMM, that device is considered to be *enrolled* (sometimes referred to as activated). This article shows you how to create a Surface UEFI configuration package that will not only control the settings of Surface UEFI, but will also enroll a Surface device in SEMM.
+
+For a more high-level overview of SEMM, see [Microsoft Surface Enterprise Management Mode](https://technet.microsoft.com/en-us/itpro/surface/surface-enterprise-management-mode).
+
+#### Download and install Microsoft Surface UEFI Configurator
+The tool used to create SEMM packages is Microsoft Surface UEFI Configurator. You can download Microsoft Surface UEFI Configurator from the [Surface Tools for IT](https://www.microsoft.com/en-us/download/details.aspx?id=46703) page in the Microsoft Download Center.
+Run the Microsoft Surface UEFI Configurator Windows Installer (.msi) file to start the installation of the tool. When the installer completes, find Microsoft Surface UEFI Configurator in the All Apps section of your Start menu.
+
+>**Note**:&nbsp;&nbsp;Microsoft Surface UEFI Configurator is supported only on Windows 10.
+
+## Create a Surface UEFI configuration package
+
+The Surface UEFI configuration package performs both the role of applying a new configuration of Surface UEFI settings to a Surface device managed with SEMM and the role of enrolling Surface devices in SEMM. The creation of a configuration package requires you to have a signing certificate to be used with SEMM to secure the configuration of UEFI settings on each Surface device. For more information about the requirements for the SEMM certificate, see [Microsoft Surface Enterprise Management Mode](https://technet.microsoft.com/en-us/itpro/surface/surface-enterprise-management-mode).
+
+To create a Surface UEFI configuration package, follow these steps:
+
+1. Open Microsoft Surface UEFI Configurator from the Start menu.
+2. Click **Start**.
+3. Click **Configuration Package**, as shown in Figure 1.
+
+   ![Create a package for SEMM enrollment](images\surface-semm-enroll-fig1.png "Create a package for SEMM enrollment")
+
+   *Figure 1. Select Configuration Package to create a package for SEMM enrollment and configuration*
+
+4. Click **Certificate Protection** to add your exported certificate file with private key (.pfx), as shown in Figure 2. Browse to the location of your certificate file, select the file, and then click **OK**.
+
+   ![Add the SEM certificate and Surface UEFI password to configuration package](images\surface-semm-enrollment-fig2.png "Add the SEM certificate and Surface UEFI password to configuration package")
+
+   *Figure 2. Add the SEMM certificate and Surface UEFI password to a Surface UEFI configuration package*
+
+5. When you are prompted to confirm the certificate password, enter and confirm the password for your certificate file, and then click **OK**.
+6. Click **Password Protection** to add a password to Surface UEFI. This password will be required whenever you boot to UEFI. If this password is not entered, only the **PC information**, **About**, **Enterprise management**, and **Exit** pages will be displayed. This step is optional.
+7. When you are prompted, enter and confirm your chosen password for Surface UEFI, and then click **OK**. If you want to clear an existing Surface UEFI password, leave the password field blank.
+8. If you do not want the Surface UEFI package to apply to a particular device, on the **Choose which Surface type you want to target** page, click the slider beneath the corresponding Surface Book or Surface Pro 4 image so that it is in the **Off** position. (As shown in Figure 3.)
+
+   ![Choose devices for package compatibility](images\surface-semm-enroll-fig3.png "Choose devices for package compatibility")
+
+   *Figure 3. Choose the devices for package compatibility*
+
+9. Click **Next**.
+10. If you want to deactivate a component on managed Surface devices, on the **Choose which components you want to activate or deactivate** page, click the slider next to any device or group of devices you want to deactivate so that the slider is in the **Off** position. (Shown in Figure 4.) The default configuration for each device is **On**. Click the **Reset** button if you want to return all sliders to the default position.
+
+   ![Disable or enable Surface components](images\surface-semm-enroll-fig4.png "Disable or enable Surface components")
+
+   *Figure 4. Disable or enable individual Surface components*
+
+11.	Click **Next**.
+12.	To enable or disable advanced options in Surface UEFI or the display of Surface UEFI pages, on the **Choose the advanced settings for your devices** page, click the slider beside the desired setting to configure that option to **On** or **Off** (shown in Figure 5). In the **UEFI Front Page** section, you can use the sliders for **Security**, **Devices**, and **Boot** to control what pages are available to users who boot into Surface UEFI. (For more information about Surface UEFI settings, see [Manage Surface UEFI settings](https://technet.microsoft.com/en-us/itpro/surface/manage-surface-uefi-settings).) Click **Build** when you have finished selecting options to generate and save the package.
+
+   ![Control advanced Surface UEFI settings and Surface UEFI pages](images\surface-semm-enroll-fig5.png "Control advanced Surface UEFI settings and Surface UEFI pages")
+
+   *Figure 5. Control advanced Surface UEFI settings and Surface UEFI pages with SEMM*
+
+13.	In the **Save As** dialog box, specify a name for the Surface UEFI configuration package, browse to the location where you would like to save the file, and then click **Save**.
+14.	When the package is created and saved, the **Successful** page is displayed.
+
+>**Note**:&nbsp;&nbsp;Record the certificate thumbprint characters that are displayed on this page, as shown in Figure 6. You will need these characters to confirm enrollment of new Surface devices in SEMM. Click **End** to complete package creation and close Microsoft Surface UEFI Configurator.
+
+![Display of certificate thumbprint characters](images\surface-semm-enroll-fig6.png "Display of certificate thumbprint characters")
+
+*Figure 6. The last two characters of the certificate thumbprint are displayed on the Successful page*
+
+Now that you have created your Surface UEFI configuration package, you can enroll or configure Surface devices.
+
+>**Note**:&nbsp;&nbsp;When a Surface UEFI configuration package is created, a log file is created on the desktop with details of the configuration package settings and options.
+
+## Enroll a Surface device in SEMM
+When the Surface UEFI configuration package is executed, the SEMM certificate and Surface UEFI configuration files are staged in the firmware storage of the Surface device. When the Surface device reboots, Surface UEFI processes these files and begins the process of applying the Surface UEFI configuration or enrolling the Surface device in SEMM, as shown in Figure 7.
+
+![SEMM process for configuration of Surface UEFI or enrollment](images\surface-semm-enroll-fig7.png "SEMM process for configuration of Surface UEFI or enrollment")
+
+*Figure 7. The SEMM process for configuration of Surface UEFI or enrollment of a Surface device*
+
+Before you begin the process to enroll a Surface device in SEMM, ensure that you have the last two characters of the certificate thumbprint on hand. You will need these characters to confirm the device’s enrollment (see Figure 6).
+
+To enroll a Surface device in SEMM with a Surface UEFI configuration package, follow these steps:
+
+1. Run the Surface UEFI configuration package .msi file on the Surface device you want to enroll in SEMM. This will provision the Surface UEFI configuration file in the device’s firmware.
+2. Select the **I accept the terms in the License Agreement** check box to accept the End User License Agreement (EULA), and then click **Install** to begin the installation process.
+3. Click **Finish** to complete the Surface UEFI configuration package installation and restart the Surface device when you are prompted to do so.
+4. Surface UEFI will load the configuration file and determine that SEMM is not enabled on the device. Surface UEFI will then begin the SEMM enrollment process, as follows:
+  * Surface UEFI will verify that the SEMM configuration file contains a SEMM certificate.
+  * Surface UEFI will prompt you to enter to enter the last two characters of the certificate thumbprint to confirm enrollment of the Surface device in SEMM, as shown in Figure 8.
+
+  ![SEMM enrollment requires last two characters of certificate thumbprint](images\surface-semm-enroll-fig8.png "SEMM enrollment requires last two characters of certificate thumbprint")
+  
+  *Figure 8. Enrollment in SEMM requires the last two characters of the certificate thumbprint*
+
+   * Surface UEFI will store the SEMM certificate in firmware and apply the configuration settings that are specified in the Surface UEFI configuration file.
+   
+5. The Surface device is now enrolled in SEMM and will boot to Windows.
+
+You can verify that a Surface device has been successfully enrolled in SEMM by looking for **Microsoft Surface Configuration Package** in **Programs and Features** (as shown in Figure 9), or in the events stored in the **Microsoft Surface UEFI Configurator** log, found under **Applications and Services Logs** in Event Viewer (as shown in Figure 10).
+
+![Verify enrollment of Surface device in SEMM in Programs and Features](images\surface-semm-enroll-fig9.png "Verify enrollment of Surface device in SEMM in Programs and Features")
+
+*Figure 9. Verify the enrollment of a Surface device in SEMM in Programs and Features*
+
+![Verify enrollment of Surface device in SEMM in Event Viewer](images\surface-semm-enroll-fig10.png "Verify enrollment of Surface device in SEMM in Event Viewer")
+
+*Figure 10. Verify the enrollment of a Surface device in SEMM in Event Viewer*
+
+You can also verify that the device is enrolled in SEMM in Surface UEFI – while the device is enrolled, Surface UEFI will contain the **Enterprise management** page (as shown in Figure 11).
+
+![Surface UEFI Enterprise management page](images\surface-semm-enroll-fig11.png "Surface UEFI Enterprise management page")
+
+*Figure 11. The Surface UEFI Enterprise management page*
+
+
+## Configure Surface UEFI settings with SEMM
+
+After a device is enrolled in SEMM, you can run Surface UEFI configuration packages signed with the same SEMM certificate to apply new Surface UEFI settings. These settings are applied automatically the next time the device boots, without any interaction from the user. You can use application deployment solutions like System Center Configuration Manager to deploy Surface UEFI configuration packages to Surface devices to change or manage the settings in Surface UEFI.
+
+For more information about how to deploy Windows Installer (.msi) files with Configuration Manager, see [Deploy and manage applications with System Center Configuration Manager](https://technet.microsoft.com/library/mt627959).
+
+If you have secured Surface UEFI with a password, users without the password who attempt to boot to Surface UEFI will only have the **PC information**, **About**, **Enterprise management**, and **Exit** pages displayed to them.
+
+If you have not secured Surface UEFI with a password or a user enters the password correctly, settings that are configured with SEMM will be dimmed (unavailable) and the text Some settings are managed by your organization will be displayed at the top of the page, as shown in Figure 12.
+
+![Settings managed by SEMM disabled in Surface UEFI](images\surface-semm-enroll-fig12.png "Settings managed by SEMM disabled in Surface UEFI")
+
+*Figure 12. Settings managed by SEMM will be disabled in Surface UEFI*
\ No newline at end of file
diff --git a/devices/surface/images/sda-fig1-select-steps.png b/devices/surface/images/sda-fig1-select-steps.png
index 15e6e64edc..cb5c24c2e0 100644
Binary files a/devices/surface/images/sda-fig1-select-steps.png and b/devices/surface/images/sda-fig1-select-steps.png differ
diff --git a/devices/surface/images/sda-fig2-specify-local.png b/devices/surface/images/sda-fig2-specify-local.png
index 24d002bc50..a7eb4d5b33 100644
Binary files a/devices/surface/images/sda-fig2-specify-local.png and b/devices/surface/images/sda-fig2-specify-local.png differ
diff --git a/devices/surface/images/sdasteps-fig4-select.png b/devices/surface/images/sdasteps-fig4-select.png
index 48f7d695a2..15d4df2af7 100644
Binary files a/devices/surface/images/sdasteps-fig4-select.png and b/devices/surface/images/sdasteps-fig4-select.png differ
diff --git a/devices/surface/images/sdasteps-fig6-specify-driver-app-files.png b/devices/surface/images/sdasteps-fig6-specify-driver-app-files.png
index 7c6750a0c8..cb82d3fec7 100644
Binary files a/devices/surface/images/sdasteps-fig6-specify-driver-app-files.png and b/devices/surface/images/sdasteps-fig6-specify-driver-app-files.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig1.png b/devices/surface/images/surface-deploymdt-fig1.png
new file mode 100644
index 0000000000..d2fe0995a7
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig1.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig10.png b/devices/surface/images/surface-deploymdt-fig10.png
new file mode 100644
index 0000000000..96cb86b56f
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig10.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig11.png b/devices/surface/images/surface-deploymdt-fig11.png
new file mode 100644
index 0000000000..a78c147322
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig11.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig12.png b/devices/surface/images/surface-deploymdt-fig12.png
new file mode 100644
index 0000000000..6200a677ec
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig12.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig13.png b/devices/surface/images/surface-deploymdt-fig13.png
new file mode 100644
index 0000000000..c04c8f6d19
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig13.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig14.png b/devices/surface/images/surface-deploymdt-fig14.png
new file mode 100644
index 0000000000..f02bc1fdb9
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig14.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig15.png b/devices/surface/images/surface-deploymdt-fig15.png
new file mode 100644
index 0000000000..4eb72e98cc
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig15.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig16.png b/devices/surface/images/surface-deploymdt-fig16.png
new file mode 100644
index 0000000000..0c5abc40a3
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig16.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig17.png b/devices/surface/images/surface-deploymdt-fig17.png
new file mode 100644
index 0000000000..3ccd548a70
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig17.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig18.png b/devices/surface/images/surface-deploymdt-fig18.png
new file mode 100644
index 0000000000..f510c5b884
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig18.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig19.png b/devices/surface/images/surface-deploymdt-fig19.png
new file mode 100644
index 0000000000..535a139991
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig19.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig2.png b/devices/surface/images/surface-deploymdt-fig2.png
new file mode 100644
index 0000000000..ad18f2ad58
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig2.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig20.png b/devices/surface/images/surface-deploymdt-fig20.png
new file mode 100644
index 0000000000..045801b6ac
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig20.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig21.png b/devices/surface/images/surface-deploymdt-fig21.png
new file mode 100644
index 0000000000..7660a618c8
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig21.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig22.png b/devices/surface/images/surface-deploymdt-fig22.png
new file mode 100644
index 0000000000..1852197dc7
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig22.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig23.png b/devices/surface/images/surface-deploymdt-fig23.png
new file mode 100644
index 0000000000..306a662236
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig23.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig24.png b/devices/surface/images/surface-deploymdt-fig24.png
new file mode 100644
index 0000000000..546a310733
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig24.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig25.png b/devices/surface/images/surface-deploymdt-fig25.png
new file mode 100644
index 0000000000..a58b7fba71
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig25.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig3.png b/devices/surface/images/surface-deploymdt-fig3.png
new file mode 100644
index 0000000000..7d87a1c986
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig3.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig4.png b/devices/surface/images/surface-deploymdt-fig4.png
new file mode 100644
index 0000000000..944fd37f41
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig4.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig5.png b/devices/surface/images/surface-deploymdt-fig5.png
new file mode 100644
index 0000000000..8fa0679886
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig5.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig6.png b/devices/surface/images/surface-deploymdt-fig6.png
new file mode 100644
index 0000000000..53c923be28
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig6.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig7.png b/devices/surface/images/surface-deploymdt-fig7.png
new file mode 100644
index 0000000000..48892a9ef0
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig7.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig8.png b/devices/surface/images/surface-deploymdt-fig8.png
new file mode 100644
index 0000000000..59028f2a82
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig8.png differ
diff --git a/devices/surface/images/surface-deploymdt-fig9.png b/devices/surface/images/surface-deploymdt-fig9.png
new file mode 100644
index 0000000000..6044405883
Binary files /dev/null and b/devices/surface/images/surface-deploymdt-fig9.png differ
diff --git a/devices/surface/images/surface-diagnostic-kit-fig1-options.png b/devices/surface/images/surface-diagnostic-kit-fig1-options.png
new file mode 100644
index 0000000000..8e10b877f9
Binary files /dev/null and b/devices/surface/images/surface-diagnostic-kit-fig1-options.png differ
diff --git a/devices/surface/images/surface-diagnostic-kit-fig2-testdepth.png b/devices/surface/images/surface-diagnostic-kit-fig2-testdepth.png
new file mode 100644
index 0000000000..061c7748b3
Binary files /dev/null and b/devices/surface/images/surface-diagnostic-kit-fig2-testdepth.png differ
diff --git a/devices/surface/images/surface-diagnostic-kit-fig3-results.png b/devices/surface/images/surface-diagnostic-kit-fig3-results.png
new file mode 100644
index 0000000000..e02087d6d9
Binary files /dev/null and b/devices/surface/images/surface-diagnostic-kit-fig3-results.png differ
diff --git a/devices/surface/images/surface-diagnostic-kit-fig4-notes.png b/devices/surface/images/surface-diagnostic-kit-fig4-notes.png
new file mode 100644
index 0000000000..02726648db
Binary files /dev/null and b/devices/surface/images/surface-diagnostic-kit-fig4-notes.png differ
diff --git a/devices/surface/images/surface-diagnostic-kit-gear-icon.png b/devices/surface/images/surface-diagnostic-kit-gear-icon.png
new file mode 100644
index 0000000000..fe6be488b1
Binary files /dev/null and b/devices/surface/images/surface-diagnostic-kit-gear-icon.png differ
diff --git a/devices/surface/images/surface-enroll-semm-fig1.png b/devices/surface/images/surface-enroll-semm-fig1.png
new file mode 100644
index 0000000000..0db814ae84
Binary files /dev/null and b/devices/surface/images/surface-enroll-semm-fig1.png differ
diff --git a/devices/surface/images/surface-ent-mgmt-fig1-uefi-configurator.png b/devices/surface/images/surface-ent-mgmt-fig1-uefi-configurator.png
new file mode 100644
index 0000000000..7ed392d31d
Binary files /dev/null and b/devices/surface/images/surface-ent-mgmt-fig1-uefi-configurator.png differ
diff --git a/devices/surface/images/surface-ent-mgmt-fig2-securepackage.png b/devices/surface/images/surface-ent-mgmt-fig2-securepackage.png
new file mode 100644
index 0000000000..a1316359d3
Binary files /dev/null and b/devices/surface/images/surface-ent-mgmt-fig2-securepackage.png differ
diff --git a/devices/surface/images/surface-ent-mgmt-fig3-enabledisable.png b/devices/surface/images/surface-ent-mgmt-fig3-enabledisable.png
new file mode 100644
index 0000000000..39b0c797e7
Binary files /dev/null and b/devices/surface/images/surface-ent-mgmt-fig3-enabledisable.png differ
diff --git a/devices/surface/images/surface-ent-mgmt-fig4-advancedsettings.png b/devices/surface/images/surface-ent-mgmt-fig4-advancedsettings.png
new file mode 100644
index 0000000000..405e8c4d7e
Binary files /dev/null and b/devices/surface/images/surface-ent-mgmt-fig4-advancedsettings.png differ
diff --git a/devices/surface/images/surface-ent-mgmt-fig5-success.png b/devices/surface/images/surface-ent-mgmt-fig5-success.png
new file mode 100644
index 0000000000..508f76533c
Binary files /dev/null and b/devices/surface/images/surface-ent-mgmt-fig5-success.png differ
diff --git a/devices/surface/images/surface-ent-mgmt-fig6-enrollconfirm.png b/devices/surface/images/surface-ent-mgmt-fig6-enrollconfirm.png
new file mode 100644
index 0000000000..78126407fa
Binary files /dev/null and b/devices/surface/images/surface-ent-mgmt-fig6-enrollconfirm.png differ
diff --git a/devices/surface/images/surface-ent-mgmt-fig7-semmrecovery.png b/devices/surface/images/surface-ent-mgmt-fig7-semmrecovery.png
new file mode 100644
index 0000000000..5a3395e0ee
Binary files /dev/null and b/devices/surface/images/surface-ent-mgmt-fig7-semmrecovery.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig1.png b/devices/surface/images/surface-semm-enroll-fig1.png
new file mode 100644
index 0000000000..0db814ae84
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig1.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig10.png b/devices/surface/images/surface-semm-enroll-fig10.png
new file mode 100644
index 0000000000..e61cf3d70a
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig10.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig11.png b/devices/surface/images/surface-semm-enroll-fig11.png
new file mode 100644
index 0000000000..91c03fef5e
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig11.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig12.png b/devices/surface/images/surface-semm-enroll-fig12.png
new file mode 100644
index 0000000000..d6c0505c16
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig12.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig3.png b/devices/surface/images/surface-semm-enroll-fig3.png
new file mode 100644
index 0000000000..2d66b485f9
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig3.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig4.png b/devices/surface/images/surface-semm-enroll-fig4.png
new file mode 100644
index 0000000000..39b0c797e7
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig4.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig5.png b/devices/surface/images/surface-semm-enroll-fig5.png
new file mode 100644
index 0000000000..b3d3db34c7
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig5.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig6.png b/devices/surface/images/surface-semm-enroll-fig6.png
new file mode 100644
index 0000000000..95b1c1b24b
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig6.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig7.png b/devices/surface/images/surface-semm-enroll-fig7.png
new file mode 100644
index 0000000000..26a640ac0c
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig7.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig8.png b/devices/surface/images/surface-semm-enroll-fig8.png
new file mode 100644
index 0000000000..a1421da21c
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig8.png differ
diff --git a/devices/surface/images/surface-semm-enroll-fig9.png b/devices/surface/images/surface-semm-enroll-fig9.png
new file mode 100644
index 0000000000..9229ee255d
Binary files /dev/null and b/devices/surface/images/surface-semm-enroll-fig9.png differ
diff --git a/devices/surface/images/surface-semm-enrollment-fig2.png b/devices/surface/images/surface-semm-enrollment-fig2.png
new file mode 100644
index 0000000000..1a5649b01e
Binary files /dev/null and b/devices/surface/images/surface-semm-enrollment-fig2.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig1.png b/devices/surface/images/surface-semm-unenroll-fig1.png
new file mode 100644
index 0000000000..b0247d3871
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig1.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig10.png b/devices/surface/images/surface-semm-unenroll-fig10.png
new file mode 100644
index 0000000000..968bf44d8c
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig10.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig11.png b/devices/surface/images/surface-semm-unenroll-fig11.png
new file mode 100644
index 0000000000..c5e86d2b65
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig11.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig12.png b/devices/surface/images/surface-semm-unenroll-fig12.png
new file mode 100644
index 0000000000..d9a3e0617b
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig12.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig13.png b/devices/surface/images/surface-semm-unenroll-fig13.png
new file mode 100644
index 0000000000..cfe16c3a99
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig13.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig14.png b/devices/surface/images/surface-semm-unenroll-fig14.png
new file mode 100644
index 0000000000..5c95097c8d
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig14.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig2.png b/devices/surface/images/surface-semm-unenroll-fig2.png
new file mode 100644
index 0000000000..5affd8cef6
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig2.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig3.png b/devices/surface/images/surface-semm-unenroll-fig3.png
new file mode 100644
index 0000000000..45c1ae38ed
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig3.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig4.png b/devices/surface/images/surface-semm-unenroll-fig4.png
new file mode 100644
index 0000000000..c4ecf92b1b
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig4.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig5.png b/devices/surface/images/surface-semm-unenroll-fig5.png
new file mode 100644
index 0000000000..9229ee255d
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig5.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig6.png b/devices/surface/images/surface-semm-unenroll-fig6.png
new file mode 100644
index 0000000000..91c03fef5e
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig6.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig7.png b/devices/surface/images/surface-semm-unenroll-fig7.png
new file mode 100644
index 0000000000..0dcbace491
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig7.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig8.png b/devices/surface/images/surface-semm-unenroll-fig8.png
new file mode 100644
index 0000000000..77e7e05407
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig8.png differ
diff --git a/devices/surface/images/surface-semm-unenroll-fig9.png b/devices/surface/images/surface-semm-unenroll-fig9.png
new file mode 100644
index 0000000000..b40ccb2449
Binary files /dev/null and b/devices/surface/images/surface-semm-unenroll-fig9.png differ
diff --git a/devices/surface/images/surface-upgrademdt-fig1.png b/devices/surface/images/surface-upgrademdt-fig1.png
new file mode 100644
index 0000000000..094f5d700b
Binary files /dev/null and b/devices/surface/images/surface-upgrademdt-fig1.png differ
diff --git a/devices/surface/images/surface-upgrademdt-fig2.png b/devices/surface/images/surface-upgrademdt-fig2.png
new file mode 100644
index 0000000000..88ec207691
Binary files /dev/null and b/devices/surface/images/surface-upgrademdt-fig2.png differ
diff --git a/devices/surface/images/surface-upgrademdt-fig3.png b/devices/surface/images/surface-upgrademdt-fig3.png
new file mode 100644
index 0000000000..7660a618c8
Binary files /dev/null and b/devices/surface/images/surface-upgrademdt-fig3.png differ
diff --git a/devices/surface/images/surface-upgrademdt-fig4.png b/devices/surface/images/surface-upgrademdt-fig4.png
new file mode 100644
index 0000000000..1852197dc7
Binary files /dev/null and b/devices/surface/images/surface-upgrademdt-fig4.png differ
diff --git a/devices/surface/images/surface-upgrademdt-fig5.png b/devices/surface/images/surface-upgrademdt-fig5.png
new file mode 100644
index 0000000000..306a662236
Binary files /dev/null and b/devices/surface/images/surface-upgrademdt-fig5.png differ
diff --git a/devices/surface/index.md b/devices/surface/index.md
index 19658afe3a..20b688e39b 100644
--- a/devices/surface/index.md
+++ b/devices/surface/index.md
@@ -1,6 +1,6 @@
 ---
 title: Surface (Surface)
-description: .
+description: 
 ms.assetid: 2a6aec85-b8e2-4784-8dc1-194ed5126a04
 ms.prod: w10
 ms.mktglfcycl: manage
@@ -47,45 +47,59 @@ For more information on planning for, deploying, and managing Surface devices in
 <td><p>Find out how to add and download Surface app with Windows Store for Business, as well as install Surface app with PowerShell and MDT.</p></td>
 </tr>
 <tr class="even">
+<td><p>[Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md)</p></td>
+<td><p>Walk through the recommended process of how to deploy Windows 10 to your Surface devices with the Microsoft Deployment Toolkit.</p></td>
+</tr>
+<tr class="odd">
 <td><p>[Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md)</p></td>
 <td><p>Get a list of the available downloads for Surface devices and links to download the drivers and firmware for your device.</p></td>
 </tr>
-<tr class="odd">
+<tr class="even">
 <td><p>[Enable PEAP, EAP-FAST, and Cisco LEAP on Surface devices](enable-peap-eap-fast-and-cisco-leap-on-surface-devices.md)</p></td>
 <td><p>Find out how to enable support for PEAP, EAP-FAST, or Cisco LEAP protocols on your Surface device.</p></td>
 </tr>
-<tr class="even">
+<tr class="odd">
 <td><p>[Ethernet adapters and Surface deployment](ethernet-adapters-and-surface-device-deployment.md)</p></td>
 <td><p>Get guidance and answers to help you perform a network deployment to Surface devices.</p></td>
 </tr>
-<tr class="odd">
+<tr class="even">
 <td><p>[Manage Surface Dock firmware updates](manage-surface-dock-firmware-updates.md)</p></td>
 <td><p>Read about the different methods you can use to manage the process of Surface Dock firmware updates.</p></td>
 </tr>
-<tr class="even">
+<tr class="odd">
 <td><p>[Manage Surface driver and firmware updates](manage-surface-pro-3-firmware-updates.md)</p></td>
 <td><p>Explore the available options to manage firmware and driver updates for Surface devices.</p></td>
 </tr>
-<tr class="odd">
+<tr class="even">
 <td><p>[Manage Surface UEFI settings](manage-surface-uefi-settings.md)<p></td>
 <td><p>Use Surface UEFI settings to enable or disable devices, configure security settings, and adjust Surface device boot settings.</p></td>
 </tr>
-<tr class="even">
+<tr class="odd">
 <td><p>[Surface Data Eraser](microsoft-surface-data-eraser.md)</p></td>
 <td><p>Find out how the Microsoft Surface Data Eraser tool can help you securely wipe data from your Surface devices.</p></td>
 </tr>
-<tr class="odd">
+<tr class="even">
 <td><p>[Surface Deployment Accelerator](microsoft-surface-deployment-accelerator.md)</p></td>
 <td><p>See how Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices.</p></td>
 </tr>
-<tr class="even">
+<tr class="odd">
 <td><p>[Surface Diagnostic Toolkit](surface-diagnostic-toolkit.md)</p></td>
 <td><p>Find out how you can use the Microsoft Surface Diagnostic Toolkit to test the hardware of your Surface device.</p></td>
 </tr>
-<tr class="odd">
+<tr class="even">
 <td><p>[Surface Dock Updater](surface-dock-updater.md)</p></td>
 <td><p>Get a detailed walkthrough of Microsoft Surface Dock Updater.</p></td>
 </tr>
+<tr class="odd">
+<td><p>[Surface Enterprise Management Mode](surface-enterprise-management-mode.md)</p></td>
+<td><p>See how this feature of Surface devices with Surface UEFI allows you to secure and manage firmware settings within your organization.
+</p></td>
+</tr>
+<tr class="even">
+<td><p>[Upgrade Surface devices to Windows 10 with MDT](upgrade-surface-devices-to-windows-10-with-mdt.md)</p></td>
+<td><p>Find out how to perform a Windows 10 upgrade deployment to your Surface devices.</p></td>
+</tr>
+
 </tbody>
 </table>
 
diff --git a/devices/surface/manage-surface-dock-firmware-updates.md b/devices/surface/manage-surface-dock-firmware-updates.md
index 9428200756..f11c5fefe8 100644
--- a/devices/surface/manage-surface-dock-firmware-updates.md
+++ b/devices/surface/manage-surface-dock-firmware-updates.md
@@ -43,7 +43,7 @@ The Surface Dock firmware update process shown in Figure 1 follows these steps:
 
 8.  When the Surface Dock is disconnected for a second time, the Surface dock installs the firmware update to the DisplayPort chipset. This process takes up to 3 minutes to apply.
 
-![figure 1](images/manage-surface-dock-fig1-updateprocess.png)
+![Surface Dock firmware update process](images/manage-surface-dock-fig1-updateprocess.png "Surface Dock firmware update process")
 
 *1- Driver installation can be performed by Windows Update, manual installation, or automatically downloaded with Microsoft Surface Dock Updater*
 
diff --git a/devices/surface/manage-surface-uefi-settings.md b/devices/surface/manage-surface-uefi-settings.md
index 44428903c1..e36486bfa4 100644
--- a/devices/surface/manage-surface-uefi-settings.md
+++ b/devices/surface/manage-surface-uefi-settings.md
@@ -39,9 +39,9 @@ You will also find detailed information about the firmware of your Surface devic
 
 - Touch Firmware 
 
-*Figure 1. System information and firmware version information*
+![System information and firmware version information](images/manage-surface-uefi-figure-1.png "System information and firmware version information")
 
-![figure 1](images/manage-surface-uefi-figure-1.png)
+*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. 
 
@@ -59,21 +59,21 @@ On the **Security** page of Surface UEFI settings, you can set a password to pro
 
 The password must be at least 6 characters and is case sensitive. 
 
-*Figure 2. Add a password to protect Surface UEFI settings*
+![Add a password to protect Surface UEFI settings](images/manage-surface-uefi-fig2.png "Add a password to protect Surface UEFI settings")
 
-![figure 2](images/manage-surface-uefi-fig2.png)
+*Figure 2. Add a password to protect Surface UEFI settings*
 
 On the **Security** page you can also change the configuration of Secure Boot on your Surface device. Secure Boot technology prevents unauthorized boot code from booting on your Surface device, which protects against bootkit and rootkit-type malware infections. You can disable Secure Boot to allow your Surface device to boot third-party operating systems or bootable media. You can also configure Secure Boot to work with third-party certificates, as shown in Figure 3. Read more about [Secure Boot](https://msdn.microsoft.com/windows/hardware/commercialize/manufacture/desktop/secure-boot-overview) in the TechNet Library.
 
-*Figure 3. Configure Secure Boot* 
+![Configure Secure Boot](images/manage-surface-uefi-fig3.png "Configure Secure Boot")
 
-![figure 3](images/manage-surface-uefi-fig3.png)
+*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. 
 
-*Figure 4. Configure Surface UEFI security settings*
+![Configure Surface UEFI security settings](images/manage-surface-uefi-fig4.png "Configure Surface UEFI security settings")
 
-![figure 4](images/manage-surface-uefi-fig4.png)
+*Figure 4. Configure Surface UEFI security settings*
 
 ##Devices 
 
@@ -95,9 +95,9 @@ On the **Devices** page you can enable or disable specific devices and component
 
 Each device is listed with a slider button that you can move to **On** (enabled) or **Off** (disabled) position, as shown in Figure 5. 
 
-*Figure 5. Enable and disable specific devices*
+![Enable and disable specific devices](images/manage-surface-uefi-fig5.png "Enable and disable specific devices")
 
-![figure 5](images/manage-surface-uefi-fig5.png)
+*Figure 5. Enable and disable specific devices*
 
 ##Boot configuration 
 
@@ -115,9 +115,9 @@ You can boot from a specific device immediately, or you can swipe left on that d
 
 For the specified boot order to take effect, you must set the **Enable Alternate Boot Sequence** option to **On**, as shown in Figure 6. 
 
-*Figure 6. Configure the boot order for your Surface device* 
+![Configure the boot order for your Surface device](images/manage-surface-uefi-fig6.png "Configure the boot order for your Surface device")
 
-![figure 6](images/manage-surface-uefi-fig6.png)
+*Figure 6. Configure the boot order for your Surface device* 
 
 You can also turn on and off IPv6 support for PXE with the **Enable IPv6 for PXE Network Boot** option, for example when performing a Windows deployment using PXE where the PXE server is configured for IPv4 only.  
 
@@ -125,14 +125,14 @@ You can also turn on and off IPv6 support for PXE with the **Enable IPv6 for PXE
 
 The **About** page displays regulatory information, such as compliance with FCC rules, as shown in Figure 7. 
 
-*Figure 7. Regulatory information is displayed on the About page*
+![Regulatory information displayed on the About page](images/manage-surface-uefi-fig7.png "Regulatory information displayed on the About page")
 
-![figure 7](images/manage-surface-uefi-fig7.png)
+*Figure 7. Regulatory information displayed on the About page*
 
 ##Exit 
 
 Use the **Restart Now** button on the **Exit** page to exit UEFI settings, as shown in Figure 8. 
 
-*Figure 8. Click Restart Now to exit Surface UEFI and restart the device*
+![Exit Surface UEFI and restart the device](images/manage-surface-uefi-fig8.png "Exit Surface UEFI and restart the device")
 
-![figure 8](images/manage-surface-uefi-fig8.png)
+*Figure 8. Click Restart Now to exit Surface UEFI and restart the device*
diff --git a/devices/surface/microsoft-surface-data-eraser.md b/devices/surface/microsoft-surface-data-eraser.md
index 6f76da2a15..1fde46555c 100644
--- a/devices/surface/microsoft-surface-data-eraser.md
+++ b/devices/surface/microsoft-surface-data-eraser.md
@@ -65,24 +65,24 @@ After the creation tool is installed, follow these steps to create a Microsoft S
 
 3.  Click **Start** to acknowledge that you have a USB stick of at least 4 GB connected, as shown in Figure 1.
 
-    ![figure 1](images/dataeraser-start-tool.png)
+    ![Start the Microsoft Surface Data Eraser tool](images/dataeraser-start-tool.png "Start the Microsoft Surface Data Eraser tool")
 
-    Figure 1. Start the Microsoft Surface Data Eraser tool
+    *Figure 1. Start the Microsoft Surface Data Eraser tool*
 
 4.  Select the USB drive of your choice from the **USB Thumb Drive Selection** page as shown in Figure 2, and then click **Start** to begin the USB creation process. The drive you select will be formatted and any existing data on this drive will be lost.
   >**Note:**&nbsp;&nbsp;If the Start button is disabled, check that your removable drive has a total capacity of at least 4 GB.
   
-    ![figure 2](images/dataeraser-usb-selection.png)
+    ![USB thumb drive selection](images/dataeraser-usb-selection.png "USB thumb drive selection")
 
-    Figure 2. USB thumb drive selection
+    *Figure 2. USB thumb drive selection*
 
 5.  After the creation process is finished, the USB drive has been formatted and all binaries are copied to the USB drive. Click **Success**.
 
 6.  When the **Congratulations** screen is displayed, you can eject and remove the thumb drive. This thumb drive is now ready to be inserted into a Surface device, booted from, and wipe any data on the device. Click **Complete** to finish the USB creation process, as shown in Figure 3.
 
-    ![figure 3](images/dataeraser-complete-process.png)
+    ![Surface Data Eraser USB creation process](images/dataeraser-complete-process.png "Surface Data Eraser USB creation process")
 
-    Figure 3. Complete the Microsoft Surface Data Eraser USB creation process
+    *Figure 3. Complete the Microsoft Surface Data Eraser USB creation process*
 
 7.  Click **X** to close Microsoft Surface Data Eraser.
 
@@ -105,9 +105,9 @@ After you create a Microsoft Surface Data Eraser USB stick, you can boot a suppo
 
 3.  When the Surface device boots, a **SoftwareLicenseTerms** text file is displayed.
 
-    ![](images/data-eraser-3.png)
+    ![Booting the Microsoft Surface Data Eraser USB stick](images/data-eraser-3.png "Booting the Microsoft Surface Data Eraser USB stick")
 
-    Figure 4. Booting the Microsoft Surface Data Eraser USB stick
+    *Figure 4. Booting the Microsoft Surface Data Eraser USB stick*
 
 4.  Read the software license terms, and then close the notepad file.
 
@@ -123,9 +123,9 @@ After you create a Microsoft Surface Data Eraser USB stick, you can boot a suppo
 
 7.  If you typed **S** to begin the data erase process, the partition that will be erased is displayed, as shown in Figure 5. If this is correct, press **Y** to continue, or **N** to shut down the device.
 
-    ![](images/sda-fig5-erase.png)
+    ![Partition to be erased is displayed](images/sda-fig5-erase.png "Partition to be erased is displayed")
 
-    Figure 5. Partition to be erased is displayed in Microsoft Surface Data Eraser
+    *Figure 5. Partition to be erased is displayed in Microsoft Surface Data Eraser*
 
 8.  If you pressed **Y** in step 7, due to the destructive nature of the data erasure process, an additional dialog box is displayed to confirm your choice.
 
diff --git a/devices/surface/microsoft-surface-deployment-accelerator.md b/devices/surface/microsoft-surface-deployment-accelerator.md
index 8b9b17335c..3a37d4c81c 100644
--- a/devices/surface/microsoft-surface-deployment-accelerator.md
+++ b/devices/surface/microsoft-surface-deployment-accelerator.md
@@ -13,17 +13,17 @@ author: miladCA
 # Microsoft Surface Deployment Accelerator
 
 
-Microsoft Surface Deployment Accelerator provides a quick and simple deployment mechanism for organizations to reimage Surface devices.
+Microsoft Surface Deployment Accelerator (SDA) provides a quick and simple deployment mechanism for organizations to reimage Surface devices.
 
-Microsoft Surface Deployment Accelerator includes a wizard that automates the creation and configuration of a Microsoft recommended deployment experience by using free Microsoft deployment tools. The resulting deployment solution is complete with everything you need to immediately begin the deployment of Windows to a Surface device. You can also use Microsoft Surface Deployment Accelerator to create and capture a Windows reference image and then deploy it with the latest Windows Updates.
+SDA includes a wizard that automates the creation and configuration of a Microsoft recommended deployment experience by using free Microsoft deployment tools. The resulting deployment solution is complete with everything you need to immediately begin the deployment of Windows to a Surface device. You can also use SDA to create and capture a Windows reference image and then deploy it with the latest Windows updates.
 
-Microsoft Surface Deployment Accelerator is built on the powerful suite of deployment tools available from Microsoft including the Windows Assessment and Deployment Kit (ADK), the Microsoft Deployment Toolkit (MDT), and Windows Deployment Services (WDS). The resulting deployment share encompasses the recommended best practices for managing drivers during deployment and automating image creation and can serve as a starting point upon which you build your own customized deployment solution.
+SDA is built on the powerful suite of deployment tools available from Microsoft including the Windows Assessment and Deployment Kit (ADK), the Microsoft Deployment Toolkit (MDT), and Windows Deployment Services (WDS). The resulting deployment share encompasses the recommended best practices for managing drivers during deployment and automating image creation and can serve as a starting point upon which you build your own customized deployment solution.
 
 You can find more information about how to deploy to Surface devices, including step-by-step walkthroughs of customized deployment solution implementation, on the Deploy page of the [Surface TechCenter](http://go.microsoft.com/fwlink/p/?LinkId=691693).
 
 **Download Microsoft Surface Deployment Accelerator**
 
-You can download the installation files for Microsoft Surface Deployment Accelerator from the Microsoft Download Center. To download the installation files:
+You can download the installation files for SDA from the Microsoft Download Center. To download the installation files:
 
 1.  Go to the [Surface Tools for IT](http://go.microsoft.com/fwlink/p/?LinkId=618121) page on the Microsoft Download Center.
 
@@ -32,9 +32,9 @@ You can download the installation files for Microsoft Surface Deployment Acceler
 ## Microsoft Surface Deployment Accelerator prerequisites
 
 
-Before you install Microsoft Surface Deployment Accelerator, your environment must meet the following prerequisites:
+Before you install SDA, your environment must meet the following prerequisites:
 
--   Microsoft Surface Deployment Accelerator must be installed on Windows Server 2012 R2 or later
+-   SDA must be installed on Windows Server 2012 R2 or later
 
 -   PowerShell Script Execution Policy must be set to **Unrestricted**
 
@@ -44,45 +44,74 @@ Before you install Microsoft Surface Deployment Accelerator, your environment mu
 
 -   To support network boot, the Windows Server 2012 R2 environment must have Windows Deployment Services installed and configured to respond to PXE requests
 
--   Access to Windows source files or installation media is required when you prepare a deployment with Microsoft Surface Deployment Accelerator
+-   Access to Windows source files or installation media is required when you prepare a deployment with SDA
 
 -   At least 6 GB of free space for each version of Windows you intend to deploy
 
 ## How Microsoft Surface Deployment Accelerator works
 
 
-As you progress through the Microsoft Surface Deployment Accelerator wizard, you will be asked some basic questions about how your deployment solution should be configured. As you select the desired Surface models to be supported and apps to be installed (see Figure 1), the wizard will prepare scripts that download, install, and configure everything needed to perform a complete deployment and capture of a reference image. By using the network boot (PXE) capabilities of Windows Deployment Services (WDS), the resulting solution enables you to boot a Surface device from the network and perform a clean deployment of Windows.
+As you progress through the SDA wizard, you will be asked some basic questions about how your deployment solution should be configured. As you select the desired Surface models to be supported and apps to be installed (see Figure 1), the wizard will prepare scripts that download, install, and configure everything needed to perform a complete deployment and capture of a reference image. By using the network boot (PXE) capabilities of Windows Deployment Services (WDS), the resulting solution enables you to boot a Surface device from the network and perform a clean deployment of Windows.
 
-![figure 1](images/sda-fig1-select-steps.png)
+![Software and driver selection window](images/sda-fig1-select-steps.png "Software and driver selection window")
 
-Figure 1: Select desired apps and drivers
+*Figure 1. Select desired apps and drivers*
 
-When the Microsoft Surface Deployment Accelerator completes, you can use the deployment share to deploy over the network immediately. Simply boot your Surface device from the network using a Surface Ethernet Adapter and select the Surface deployment share you created with the Microsoft Surface Deployment Accelerator wizard. Select the **1- Deploy Microsoft Surface** task sequence and the wizard will walk you through an automated deployment of Windows to your Surface device.
+When the SDA completes, you can use the deployment share to deploy over the network immediately. Simply boot your Surface device from the network using a Surface Ethernet Adapter and select the Surface deployment share you created with the SDA wizard. Select the **1- Deploy Microsoft Surface** task sequence and the wizard will walk you through an automated deployment of Windows to your Surface device.
 
 You can modify the task sequence in the MDT Deployment Workbench to [include your own apps](http://go.microsoft.com/fwlink/p/?linkid=691700), or to [pause the automated installation routine](http://go.microsoft.com/fwlink/p/?linkid=691701). While the installation is paused, you can make changes to customize your reference image. After the image is captured, you can configure a deployment task sequence and distribute this custom configuration by using the same network boot capabilities as before.
 
->**Note:**&nbsp;&nbsp;With Microsoft Surface Deployment Accelerator v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
+>**Note:**&nbsp;&nbsp;With SDA v1.9.0258, Surface Pro 3, Surface Pro 4, and Surface Book are supported for Windows 10 deployment, and Surface Pro 3 is supported for Windows 8.1 deployment.
 
  
 
 ## <a href="" id="use-microsoft-surface-deployment-accelerator-without-an-internet-connection--"></a>Use Microsoft Surface Deployment Accelerator without an Internet connection
 
 
-For environments where the Microsoft Surface Deployment Accelerator server will not be able to connect to the Internet, the required Surface files can be downloaded separately. To specify a local source for Surface driver and app files, select the **Copy from a local directory** option and specify the location of your downloaded files (see Figure 2). All of the driver and app files for your selected choices must be placed in the specified folder.
+For environments where the SDA server will not be able to connect to the Internet, the required Surface files can be downloaded separately. To specify a local source for Surface driver and app files, select the **Copy from a local directory** option and specify the location of your downloaded files (see Figure 2). All of the driver and app files for your selected choices must be placed in the specified folder.
 
-![figure 2](images/sda-fig2-specify-local.png)
+![Specify a local source for Surface driver and app files](images/sda-fig2-specify-local.png "Specify a local source for Surface driver and app files")
 
-Figure 2. Specify a local source for Surface driver and app files
+*Figure 2. Specify a local source for Surface driver and app files*
 
 You can find a full list of available driver downloads at [Download the latest firmware and drivers for Surface devices](deploy-the-latest-firmware-and-drivers-for-surface-devices.md)
 
 >**Note:**&nbsp;&nbsp;Downloaded files do not need to be extracted. The downloaded files can be left as .zip files as long as they are stored in one folder.
 
+>**Note:**&nbsp;&nbsp;Using files from a local directory is not supported when including Office 365 in your deployment share. To include Office 365 in your deployment share, select the **Download from the Internet** check box. 
+
+## 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).
+
+>**Note:**&nbsp;&nbsp;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.
  
+### Version 1.96.0405
+This version of SDA adds support for the following:
+* Microsoft Deployment Toolkit (MDT) 2013 Update 2
+* Office 365 Click-to-Run
+* Surface 3 and Surface 3 LTE
+* Reduced Windows Assessment and Deployment Kit (Windows ADK) footprint, only the following Windows ADK components are installed:
+  * Deployment tools
+  * Windows Preinstallation Environment (WinPE)
+  * User State Migration Tool (USMT)
 
- 
+### Version 1.90.0258
+This version of SDA adds support for the following:
+* Surface Book
+* Surface Pro 4
+* Windows 10
 
- 
+### Version 1.90.0000
+This version of SDA adds support for the following:
+* Local driver and app files can be used to create a deployment share without access to the Internet
+
+### Version 1.70.0000
+This version is the original release of SDA. This version of SDA includes support for:
+* MDT 2013 Update 1
+* Windows ADK
+* Surface Pro 3
+* Windows 8.1
 
 
 
diff --git a/devices/surface/step-by-step-surface-deployment-accelerator.md b/devices/surface/step-by-step-surface-deployment-accelerator.md
index 07c32b693b..016c7ddfbd 100644
--- a/devices/surface/step-by-step-surface-deployment-accelerator.md
+++ b/devices/surface/step-by-step-surface-deployment-accelerator.md
@@ -26,17 +26,17 @@ For information about prerequisites and instructions for how to download and ins
 
 3.  Accept the End User License Agreement (EULA) by selecting the check box, and then click **Install**, as shown in Figure 1.
 
-    ![figure 1](images/sdasteps-fig1.png)
+    ![Surface Deployment Accelerator setup](images/sdasteps-fig1.png "Surface Deployment Accelerator setup")
 
-    Figure 1. SDA setup
+    *Figure 1. SDA setup*
 
 4.  Click **Finish** to complete the installation of SDA.
 
-The tool installs in the Surface Deployment Accelerator program group, as shown in Figure 2.
+The tool installs in the SDA program group, as shown in Figure 2.
 
-![figure 2](images/sdasteps-fig2.png)
+![SDA program group and icon](images/sdasteps-fig2.png "SDA program group and icon")
 
-Figure 2. The Surface Deployment Accelerator program group and icon
+*Figure 2. The SDA program group and icon*
 
 >**Note:**&nbsp;&nbsp;At this point the tool has not yet prepared any deployment environment or downloaded any materials from the Internet.
 
@@ -45,7 +45,7 @@ Figure 2. The Surface Deployment Accelerator program group and icon
 ## Create a deployment share
 
 
-The following steps show how you create a deployment share for Windows 10 that supports Surface Pro 3, Surface Pro 4, Surface Book, the Surface Firmware Tool, and the Surface Asset Tag Tool. As you follow the steps below, make the selections that are applicable for your organization. For example, you could choose to deploy Windows 10 to Surface Book only, without any of the Surface apps.
+The following steps show you how to create a deployment share for Windows 10 that supports Surface 3, Surface Pro 3, Surface Pro 4, Surface Book, the Surface Firmware Tool, the Surface Asset Tag Tool, and Office 365. As you follow the steps below, make the selections that are applicable for your organization. For example, you could choose to deploy Windows 10 to Surface Book only, without any of the Surface apps.
 
 >**Note:**&nbsp;&nbsp;SDA lets you create deployment shares for both Windows 8.1 and Windows 10 deployments, but you can only create a single deployment share at a time. Therefore, to create both Windows 8.1 and Windows 10 deployment shares, you will need to run the tool twice.
 
@@ -55,7 +55,14 @@ The following steps show how you create a deployment share for Windows 10 that
 
 2.  On the **Welcome** page, click **Next** to continue.
 
-3.  On the **Verify System** page, the SDA wizard verifies the prerequisites required for an SDA deployment share. This process also checks for the presence of the Windows Assessment and Deployment Kit (ADK) for Windows 10 and the Microsoft Deployment Toolkit (MDT) 2013 Update 1. If these tools are not detected, they are downloaded and installed automatically. Click **Next** to continue.
+3.  On the **Verify System** page, the SDA wizard verifies the prerequisites required for an SDA deployment share. This process also checks for the presence of the Windows Assessment and Deployment Kit (Windows ADK) for Windows 10 and the Microsoft Deployment Toolkit (MDT) 2013 Update 2. If these tools are not detected, they are downloaded and installed automatically. Click **Next** to continue.
+
+  >**Note:**&nbsp;&nbsp;As of SDA version 1.96.0405, SDA will install only the components of the Windows ADK that are required for deployment, as follows:
+    * Deployment tools
+    * User State Migration Tool (USMT)
+    * Windows Preinstallation Environment (WinPE)</br></br>
+
+  >**Note:**&nbsp;&nbsp;As of SDA version 1.96.0405, SDA will install and use MDT 2013 Update 2. Earlier versions of SDA are compatible only with MDT 2013 Update 1.
 
 4.  On the **Windows 8.1** page, to create a Windows 10 deployment share, do not select the **Would you like to support Windows 8.1** check box. Click **Next** to continue.
 
@@ -75,15 +82,17 @@ The following steps show how you create a deployment share for Windows 10 that
 
         -   **Local Path** – Specify or browse to the root directory of Windows 10 installation files. If you have an ISO file, mount it and browse to the root of the mounted drive. You must have a full set of source files, not just **Install.wim**.
 
-    ![figure 3](images/sdasteps-fig3.png)
+    ![Specify Windows 10 deployment share options](images/sdasteps-fig3.png "Specify Windows 10 deployment share options")
 
-    Figure 3. Specify Windows 10 deployment share options
+    *Figure 3. Specify Windows 10 deployment share options*
 
-6.  On the **Configure** page, select the check box next to each device or app that you want to include in your deployment share. Note that Surface Pro 4 and Surface Book only support Windows 10 and are not available for the deployment of Windows 8.1. The Surface Firmware Tool is only applicable to Surface Pro 3 and cannot be selected unless Surface Pro 3 drivers are selected, as shown in Figure 4. Click **Next** to continue.
+6.  On the **Configure** page, select the check box next to each device or app that you want to include in your deployment share. Note that Surface Pro 4 and Surface Book only support Windows 10 and are not available for the deployment of Windows 8.1. The Surface Firmware Tool is only applicable to Surface 3 and Surface Pro 3 and cannot be selected unless Surface 3 or Surface Pro 3 drivers are selected, as shown in Figure 4. Click **Next** to continue.
 
-    ![figure 4](images/sdasteps-fig4-select.png)
+    ![Firmware tool selection](images/sdasteps-fig4-select.png "Firmware tool selection")
 
-    Figure 4. Selecting Surface Firmware Tool requires Surface Pro 3 drivers
+    *Figure 4. Selecting Surface Firmware Tool requires Surface Pro 3 drivers*
+
+    >**Note:**&nbsp;&nbsp;You cannot select both Surface 3 and Surface 3 LTE models at the same time.
 
 7.  On the **Summary** page confirm your selections and click **Finish** to begin the creation of your deployment share. The process can take several minutes as files are downloaded, the tools are installed, and the deployment share is created. While the SDA scripts are creating your deployment share, an **Installation Progress** window will be displayed, as shown in Figure 5. A typical SDA process includes:
 
@@ -105,9 +114,9 @@ The following steps show how you create a deployment share for Windows 10 that
 
     -   Creation of rules and task sequences for Windows deployment
 
-    ![figure 5](images/sdasteps-fig5-installwindow.png)
+    ![The installatin progress window](images/sdasteps-fig5-installwindow.png "The installatin progress window")
 
-    Figure 5. The **Installation Progress** window
+    *Figure 5. The Installation Progress window*
 
 8.  When the SDA process completes the creation of your deployment share, a **Success** window is displayed. Click **Finish** to close the window. At this point your deployment share is now ready to perform a Windows deployment to Surface devices.
 
@@ -115,13 +124,15 @@ The following steps show how you create a deployment share for Windows 10 that
 
 If you are unable to connect to the Internet with your deployment server, or if you want to download the Surface drivers and apps separately, you can specify a local source for the driver an app files at the time of deployment share creation. On the **Configure** page of the SDA wizard, select the **Copy from a Local Directory** check box, as shown in Figure 6. The **Download from the Internet** check box will be automatically deselected. Enter the folder location where you have placed the driver and app files in the **Local Path** field, as shown in Figure 6.
 
->**Note:**&nbsp;&nbsp;All of the downloaded driver and applications files must be located in the same folder. The driver and app files do not need to be extracted from the downloaded .zip files.
+>**Note:**&nbsp;&nbsp;All of the downloaded driver and applications files must be located in the same folder. If a required driver or application file is missing from the selected folder when you click **Next**, a warning is displayed and the wizard will not proceed to the next step.
 
- 
+>**Note:**&nbsp;&nbsp;The driver and app files do not need to be extracted from the downloaded .zip files.
 
-![figure 6](images/sdasteps-fig6-specify-driver-app-files.png)
+>**Note:**&nbsp;&nbsp;Including Office 365 in your deployment share requires an Internet connection and cannot be performed if you use local files.
 
-Figure 6. Specify the Surface driver and app files from a local path
+![Specify Surface driver and app files](images/sdasteps-fig6-specify-driver-app-files.png "Specify Surface driver and app files")
+
+*Figure 6. Specify the Surface driver and app files from a local path*
 
 >**Note:**&nbsp;&nbsp;The **Copy from a Local Directory** check box is only available in SDA version 1.90.0221 or later.
 
@@ -159,9 +170,9 @@ Before you can create bootable media files within the MDT Deployment Workbench o
 
 9.  **exit** – Exits DiskPart, after which you can close the PowerShell or Command Prompt window.
 
-    ![figure 7](images/sdasteps-fig7-diskpart.png)
+    ![Use DiskPart to prepare a USB drive for boot](images/sdasteps-fig7-diskpart.png "Use DiskPart to prepare a USB drive for boot")
 
-    Figure 7. Use DiskPart to prepare a USB drive for boot
+    *Figure 7. Use DiskPart to prepare a USB drive for boot*
 
     >**Note:**&nbsp;&nbsp;You can format your USB drive with FAT32 from Disk Management, but you must still use DiskPart to set the partition as active for the drive to boot properly.
 
@@ -177,15 +188,15 @@ After you have prepared the USB drive for boot, the next step is to generate off
 
 4.  Right-click the **Media** folder and click **New Media** as shown in Figure 8 to start the New Media Wizard.
 
-    ![figure 8](images/sdasteps-fig8-mediafolder.png)
+    ![The Media folder of the SDA deployment share](images/sdasteps-fig8-mediafolder.png "The Media folder of the SDA deployment share")
 
-    Figure 8. The Media folder of the SDA deployment share
+    *Figure 8. The Media folder of the SDA deployment share*
 
 5.  On the **General Settings** page in the **Media path** field, enter or browse to a folder where you will create the files for the new offline media. See the example **E:\\SDAMedia** in Figure 9. Leave the default profile **Everything** selected in the **Selection profile** drop-down menu, and then click **Next**.
 
-    ![figure 9](images/sdasteps-fig9-location.png)
+    ![Specify a location and selection profile for your offline media](images/sdasteps-fig9-location.png "Specify a location and selection profile for your offline media")
 
-    Figure 9. Specify a location and selection profile for your offline media
+    *Figure 9. Specify a location and selection profile for your offline media*
 
 6.  On the **Summary** page verify your selections, and then click **Next** to begin creation of the media.
 
@@ -195,9 +206,9 @@ After you have prepared the USB drive for boot, the next step is to generate off
 
 9.  Right-click the **Microsoft Surface Deployment Accelerator** deployment share folder, click **Properties**, and then click the **Rules** tab as shown in Figure 10.
 
-    ![figure 10](images/sdasteps-fig10-rules.png)
+    ![Rules of the SDA deployment share](images/sdasteps-fig10-rules.png "Rules of the SDA deployment share")
 
-    Figure 10. The Rules of the SDA deployment share
+    *Figure 10. Rules of the SDA deployment share*
 
 10. Use your mouse to highlight all of the text displayed in the text box of the **Rules** tab, and then press **Ctrl+C** to copy the text.
 
@@ -229,15 +240,17 @@ After you have prepared the USB drive for boot, the next step is to generate off
     UserPassword=
     ```
 
-    ![figure 11](images/sdasteps-fig11-bootstrap.ini.png)
+    ![The Bootstrap.ini file](images/sdasteps-fig11-bootstrap.ini.png "The Bootstrap.ini file")
 
-    Figure 11. The Bootstrap.ini file of MEDIA001
+    *Figure 11. The Bootstrap.ini file of MEDIA001*
 
 20. Close Bootstrap.ini and click **OK** in **MEDIA001** deployment share properties to close the window.
 
 21. In the **Deployment Workbench** under the **Media** folder, right-click the newly created **MEDIA001** and click **Update Media Content**, as shown in Figure 12. This will update the media files with the content of the **Microsoft Surface Deployment Accelerator** deployment share.
 
-    ![figure 12](images/sdasteps-fig12-updatemedia.png)Figure 12. Select **Update Media Content**
+    ![Select the Update Media Content option](images/sdasteps-fig12-updatemedia.png "Select the Update Media Content option")
+    
+    *Figure 12. Select the Update Media Content option*
 
 22. The **Update Media Content** window is displayed and shows the progress as the media files are created. When the process completes, click **Finish.**
 
@@ -252,11 +265,11 @@ Your USB drive is now configured as bootable offline media that contains all of
 ## SDA task sequences
 
 
-The SDA deployment share is configured with all of the resources required to perform a Windows deployment to a Surface device. These resources include Windows source files, image, Surface drivers, and Surface apps. The deployment share also contains two pre-configured task sequences, as shown in Figure 13. These task sequences contain the steps required to perform a deployment to a Surface device using the default Windows image from the installation media or to create a reference image complete with Windows updates and applications. To learn more about task sequences, see [MDT 2013 Update 1 Lite Touch components](http://technet.microsoft.com/en-us/itpro/windows/deploy/mdt-2013-lite-touch-components).
+The SDA deployment share is configured with all of the resources required to perform a Windows deployment to a Surface device. These resources include Windows source files, image, Surface drivers, and Surface apps. The deployment share also contains two pre-configured task sequences, as shown in Figure 13. These task sequences contain the steps required to perform a deployment to a Surface device using the default Windows image from the installation media or to create a reference image complete with Windows updates and applications. To learn more about task sequences, see [MDT 2013 Update 2 Lite Touch components](https://technet.microsoft.com/itpro/windows/deploy/mdt-2013-lite-touch-components).
 
-![figure 13](images/sdasteps-fig13-taskseq.png)
+![Task sequences in the Deployment Workbench](images/sdasteps-fig13-taskseq.png "Task sequences in the Deployment Workbench")
 
-Figure 13. Task sequences in the Deployment Workbench
+*Figure 13. Task sequences in the Deployment Workbench*
 
 ### Deploy Microsoft Surface
 
@@ -286,7 +299,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:**&nbsp;&nbsp;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 1](http://technet.microsoft.com/en-us/itpro/windows/deploy/deploy-a-windows-10-image-using-mdt).
+>**Note:**&nbsp;&nbsp;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).
 
  
 
@@ -323,9 +336,9 @@ To instruct your Surface device to boot from the network, start with the device
 
 4.  Enter the domain credentials that you use to log on to the server where SDA is installed when you are prompted, as shown in Figure 14.
 
-    ![figure 14](images/sdasteps-fig14-credentials.png)
+    ![Prompt for credentials to the deployment share](images/sdasteps-fig14-credentials.png "Prompt for credentials to the deployment share")
 
-    Figure 14. The prompt for credentials to the deployment share
+    *Figure 14. The prompt for credentials to the deployment share*
 
 5.  The Windows Deployment Wizard will start from the deployment share to walk you through the deployment process.
 
@@ -343,15 +356,15 @@ To run the Deploy Microsoft Surface task sequence:
 
 1.  On the **Task Sequence** page, select the **1 – Deploy Microsoft Surface** task sequence as shown in Figure 15, and then click **Next.**
 
-    ![figure 15](images/sdasteps-fig15-deploy.png)
+    ![Select the task sequence](images/sdasteps-fig15-deploy.png "Select the task sequence")
 
-    Figure 15. Select the **1 – Deploy Microsoft Surface** task sequence
+    *Figure 15. Select the 1 – Deploy Microsoft Surface task sequence*
 
 2.  On the **Computer Details** page, type a name for the Surface device in the **Computer Name** box. In the **Join a domain** section, type your domain name and credentials as shown in Figure 16, and then click **Next**.
 
-    ![figure 16](images/sdasteps-fig16-computername.png)
+    ![Computer name and domain credentials](images/sdasteps-fig16-computername.png "Computer name and domain credentials")
 
-    Figure 16. Enter the computer name and domain information
+    *Figure 16. Enter the computer name and domain information*
 
 3.  On the **Product Key** page, keep the **No product key is required** check box selected if you are deploying the same version and edition of Windows to your Surface devices as they came with from the factory. If you are deploying a different version or edition of Windows to the device, such as Windows Enterprise, select the licensing option that is applicable to your scenario.
 
@@ -363,9 +376,9 @@ To run the Deploy Microsoft Surface task sequence:
 
 7.  On the **Ready** page, verify your selections and then click **Begin** to start the automated deployment to this device. The deployment will not require user interaction again. The Windows Deployment Wizard will close and an **Installation Progress** window is displayed to show progress of the task sequence as the image is applied and applications are installed (Figure 17).
 
-    ![figure 17](images/sdasteps-fig17-installprogresswindow.png)
+    ![Installation progress window](images/sdasteps-fig17-installprogresswindow.png "Installation progress window")
 
-    Figure 17. The **Installation Progress** window
+    *Figure 17. The Installation Progress window*
 
 8.  When the deployment task sequence completes, a **Success** window is displayed. Click **Finish** to complete the deployment and begin using your Surface device.
 
diff --git a/devices/surface/surface-diagnostic-toolkit.md b/devices/surface/surface-diagnostic-toolkit.md
index bcea29785f..0dc868613b 100644
--- a/devices/surface/surface-diagnostic-toolkit.md
+++ b/devices/surface/surface-diagnostic-toolkit.md
@@ -33,7 +33,7 @@ The [Microsoft Surface Diagnostic Toolkit](http://go.microsoft.com/fwlink/p/?Lin
 
 - Surface Pro
 
->**Note:**&nbsp;&nbsp;Security software and built-in security measures in many email applications and services will block executable files that are transferred through email. To email the Surface Diagnostic Toolkit, attach the .zip archive file as downloaded from the Surface Tools for IT page without extracting it first. You can also create a custom .zip archive that contains the .exe file. (For example, if you want to localize the text as described in the [Localization](#localization) section of this article.)
+>**Note:**&nbsp;&nbsp;Security software and built-in security measures in many email applications and services will block executable files that are transferred through email. To email the Surface Diagnostic Toolkit, attach the archive file (.zip) as downloaded from the Surface Tools for IT page without extracting it first. You can also create a custom .zip archive that contains the .exe file. (For example, if you want to localize the text as described in the [Localization](#localization) section of this article.)
 
 Running the Microsoft Surface Diagnostic Toolkit is a hands-on activity. The test sequence includes several tests that require you to perform actions or observe the outcome of the test, and then click the applicable **Pass** or **Fail** button. Some tests require connectivity to external devices, like an external display. Other tests use the built in Windows troubleshooters. At the end of testing, a visual report of the test results is displayed and you are given the option to save a log file or copy the results to the clipboard.
 
@@ -49,17 +49,73 @@ To run a full set of tests with the Microsoft Surface Diagnostic Toolkit, you sh
 
 - Room to move the Surface device around
 
-- External speakers or headphones
+- External speakers or headphones with a 3.5mm stereo plug
 
->**Note:**&nbsp;&nbsp;The Microsoft Surface Diagnostic Toolkit tests verify only the hardware of a Surface device and do not test or resolve issues with the operating system or software.
+- A power adapter for your Surface device
+
+>**Note:**&nbsp;&nbsp;The Microsoft Surface Diagnostic Toolkit tests verify only the hardware of a Surface device and do not resolve issues with the operating system or software.
+
+## Configure test options
+
+Before you select the tests you want to run, you can click the Tools ![images\surface-diagnostic-kit-gear-icon.png](images\surface-diagnostic-kit-gear-icon.png) button in the upper right corner of the window (as shown in Figure 1) to access the Options section of the Microsoft Surface Diagnostic Toolkit. In the Options section, you can configure the depth of testing and logs, as well as the save location for log files. You can also create and use additional language files for the dialog of each test.
+
+![Tools button highlighted in upper right corner of window](images\surface-diagnostic-kit-fig1-options.png "Tools button highlighted in upper right corner of window")
+
+*Figure 1. The Tools button highlighted in upper right corner of window*  
+
+>**Note:**&nbsp;&nbsp;Any options you want to select must be specified before you run the tests. You cannot change the test options after the testing sequence has started.
+
+####Test depth
+You can quickly select among three modes for testing and diagnostics by using the **Test Depth** page. The **Test Depth** page displays a slider with three possible positions, as shown in Figure 2. These positions determine which tests are run and what information is recorded without requiring you to select specific tests with the **Run Specific Tests** button. The three modes allow you to focus the tests of the Microsoft Surface Diagnostic Toolkit on hardware, software, or both hardware and software.
+ 
+![Screen that displays Test Depth slider to select depth of data collection](images/surface-diagnostic-kit-fig2-testdepth.png "Screen that displays Test Depth slider to select depth of data collection")
+
+*Figure 2. The Test Depth slider to select the depth of data collection*
+
+When you select a mode by using the Test Depth slider, a configuration file (.ini) with the same name as the Microsoft Surface Diagnostic Toolkit executable (.exe) file is created in the same folder. For example, if the Microsoft Surface Diagnostic Toolkit executable file is SurfaceDiagnosticToolkit.exe, the configuration file will be SurfaceDiagnosticToolkit.ini. When the executable file is run, the options will be automatically set by the configuration file. To run the Microsoft Surface Diagnostic Toolkit in a specific mode on multiple devices, ensure that the .ini file remains in the same folder with the .exe file used on each device.
+
+When you run the Microsoft Surface Diagnostic Toolkit, you can still use the **Run Specific Tests** button to enable or disable specific tests. The tests selected on the **Please Select Tests to Run** page take priority over the tests enabled or disabled by the mode specified on the **Test Depth** page. When a mode is selected the tests that are applicable to that mode will be enabled by default and the tests that are not required for that mode will be disabled.
+
+Each mode has a specific focus and records a different level of information in the log files, as follows:
+
+* **Hardware and Software Focus.** This is the default mode for the Microsoft Surface Diagnostic Toolkit. In this mode all tests that are applicable to the device are run. This mode logs the most information and takes the most time.
+* **Software Experience Focus.** This mode collects information about the device and records it in the log file. No hardware tests are performed in this mode. The following tests are run in this mode:
+  * Windows Update Check Test
+  * Device Information Test
+  * System Assessment Test
+  * Crash Dump Collection Test
+  * Modern Standby Test
+* **Hardware Validation Focus.** This mode tests the hardware of the device but does not collect system log files or device information. All diagnostic tests relevant to the device hardware are run in this mode. The exact tests that are run will vary from device to device depending on the hardware configuration. This mode logs the least information and requires the least amount of time.
+
+
+####Save location
+Use the **Browse** button on the **Save Location** page to select a default location for the Microsoft Surface Diagnostic Toolkit log files to be saved. When the tests complete the user will still be prompted to save a log file and a log file will not be saved automatically. The user must still click the **Save to File** button to save the log files. As with the Test Depth mode, this save location is stored in the Microsoft Surface Diagnostic Toolkit configuration (.ini) file and if the file does not exist, configuring this option will generate the file.
+
+####Additional language
+Refer to the [Localization](#localization) section of this article for information about how to customize the dialog displayed during each test. On the **Additional Language** page, you can generate a localization file that you can use to customize the dialog during each test. You can also specify a specific localization file to be used with the Microsoft Surface Diagnostic Toolkit with the **Browse** button.
+
+####Feedback
+You can use the form on the **Feedback** page to inform the product team of any problems that you encounter with the Microsoft Surface Diagnostic Toolkit or to provide any suggestions for how the Microsoft Surface Diagnostic Toolkit could be improved.
 
- 
 
 ## The tests
 
-
 The Microsoft Surface Diagnostic Toolkit runs several individual tests on a Surface device. Not all tests are applicable to every device. For example, the Home button test is not applicable to Surface Pro 4 where there is no Home button. You can specify which tests to run, or you can choose to run all tests. For tests that require external devices (such as testing output to an external display) but you do not have the required external device at the time of the test, you are given the option to skip the test. If a test fails, you are prompted to continue or stop testing at that time.
 
+When the testing completes, the **Test Results** page is displayed (as shown in Figure 3) and shows the status of each test: passed, failed, or inconclusive (skipped). You can choose to run the tests again; to save a log file, including any additional log files gathered by tests; or to copy the log file text to the clipboard.
+
+![Sample display of Test Results page](images/surface-diagnostic-kit-fig3-results.png "Sample display of Test Results page")
+
+*Figure 3. View of the results of the tests*
+
+When the tests have completed, you can also add additional notes to the log files by clicking **Add additional feedback to results ->** on the **Test Results** page. Use the **Type any additional feedback about these tests** field on the **Test Results** page to add your notes, as shown in Figure 4.
+
+![Window that shows where you can add notes to a log file](images/surface-diagnostic-kit-fig4-notes.png "Window that shows where you can add notes to a log file")
+
+*Figure 4. Add notes to the log file*
+
+Notes that you type on this page are displayed in the log files after the results of the selected tests and before the **Files** section. The section header in the log files for these notes is named **User Feedback**.
+
 #### Windows Update
 
 This test checks for any outstanding Windows updates and will prompt you to install those updates before you proceed to other tests. It is important to keep a Surface device up to date with the latest Windows updates, including drivers and firmware for the Surface device. The success of some of the tests that are performed later in the task sequence depend on these updated drivers and firmware. You will be prompted to restart the device if required by Windows Update. If you must restart the device, you will need to start the Microsoft Surface Diagnostic Toolkit again.
@@ -213,7 +269,7 @@ Insert a micro SD or SD card when you are prompted. When the SD card is detected
 
 #### Microphone test
 
-This test displays the **Recording** tab of the Sound item in Control Panel. The test prompts you to monitor the meter that is displayed next to the **Microphone Array** recording device. A recommended test is to speak and watch for your speech to be detected in the meter. If the meter moves when you speak, the microphone is working correctly. For Surface Book you will be prompted to tap locations near the microphones. This tapping should produce noticeable spikes in the audio meter.
+This test displays a meter that shows the microphone sound level and records audio for a short period of time. Say a few words or make noise and make note that the meter displays the sound level accordingly. A countdown timer is displayed to indicate how much time is remaining for you to record sound. When the countdown timer expires, the recorded audio is played back. Verify that the words or noises sound clear and accurate, and then mark the test as passed or failed depending on the results.
 
 #### Video out test
 
@@ -231,11 +287,13 @@ After you receive a prompt to put the device in pairing mode, the test opens the
 
 Use this test to verify that the cameras on your Surface device are operating properly. Images will be displayed from both the front and rear cameras, and the infrared camera on a Surface Pro 4. Continuous autofocus can be enabled on the rear camera. Move the device closer and farther away from an object to verify the operation of continuous autofocus.
 
+>**Note:**&nbsp;&nbsp;You can also use the **Snapshot to Logs** option to save a snapshot of the video output to the log files.
+
 #### Speaker test
 
 >**Note:**&nbsp;&nbsp;Headphones or external speakers are required to test the headphone jack in this test.
 
-This test plays audio over left and right channels respectively, both for the internal speakers and for speakers or headphones connected to the headphone jack. Mark each channel as a pass or fail as you hear the audio play.
+This test plays audio over left and right channels respectively, both for the internal speakers and for speakers or headphones connected through the headphone jack. Plug in your headphones or speakers to the 3.5mm stereo jack when prompted. The test will automatically detect that a sound playback device has been connected. Mark each channel as a pass or fail as you hear the audio play through the speakers or headphones.
 
 #### Network test
 
@@ -267,15 +325,21 @@ The compass detects which direction the Surface device is facing relative to nor
 
 The ambient light sensor is used to automatically adjust screen brightness relative to the ambient lighting in the environment. Turn the device toward or away from a light source to cause the screen to dim or brighten in response increased or decreased light. The test automatically passes when the screen brightness automatically changes.
 
+>**Note:**&nbsp;&nbsp;You can also block the ambient light from the sensor by holding your hand slightly in front of the light sensor, which is located directly next to the camera. Use the provided meter to determine if you are blocking light from the sensor.
+
 #### Device orientation test
 
 >**Note:**&nbsp;&nbsp;Before you run this test, disable rotation lock from the Action Center if enabled.
 
-The device orientation sensor determines what the angle of the Surface device is, relative to the ground. Rotate the display 90 degrees or 180 degrees to cause the screen orientation to switch between portrait and landscape mode. The test automatically passes when the screen orientation switches.
+The device orientation sensor determines what the angle of the Surface device is, relative to the ground. Rotate the display 90 degrees or 180 degrees to cause the screen orientation to switch between portrait and landscape mode. If you have a Surface Type Cover or the Surface Book keyboard connected, you will be prompted to disconnect the Surface from the keyboard to allow screen rotation. The test automatically passes when the screen orientation switches.
 
 #### Brightness test
 
-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 disconnect the power adapter. The screen should automatically dim when power is disconnected.
+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.
+
 
 #### System assessment
 
@@ -291,6 +355,19 @@ Performance and diagnostic trace logs are recorded from Performance Monitor for
 
 If your Surface device has encountered an error that caused the device to fail or produce a blue screen error, this stage of the Microsoft Surface Diagnostic Toolkit records the information from the automatically recorded crash dump files in the diagnostic log. You can use these crash dump files to identify a faulty driver, hardware component, or application through analysis. Use the [Windows Debugging Tool](http://go.microsoft.com/fwlink/p/?LinkId=746488) to analyze these files. If you are not familiar with the analysis of crash dump files, you can describe your issue and post a link to your crash dump files (uploaded to OneDrive or another file sharing service) in the [Windows TechNet Forums](http://go.microsoft.com/fwlink/p/?LinkId=746489).
 
+#### Connected standby text
+
+>**Note:**&nbsp;&nbsp;This test is only available on Surface devices running Windows 8 or Windows 8.1.
+
+If connected standby is enabled on the Surface device, this test passes automatically. If connected standby is not enabled, a failure is recorded for this test. Find out more about Connected Standby and Modern Standby at [Modern Standby](https://msdn.microsoft.com/library/windows/hardware/mt282515) on MSDN.
+
+#### Modern standby test
+
+>**Note:**&nbsp;&nbsp;This test is only available on Surface devices running Windows 10.
+
+This test records log files of the power configuration for the Surface device using the **powercfg.exe /a** command. The test completes automatically and a failure is only recorded if the command does not run.
+
+
 ## Command line
 
 You can run the Microsoft Surface Diagnostic Toolkit from the command line or as part of a script. The tool supports the following arguments:
@@ -430,25 +507,26 @@ Surface_Diagnostic_Toolkit_1.0.60.0.exe “logpath=C:\Folder with spaces”
 ## Localization
 
 
-By default, the Microsoft Surface Diagnostic Toolkit is available in English only. If you want to localize the text of the Microsoft Surface Diagnostic Toolkit prompts into another language, you can do so by creating a custom localization file. If the localization file exists, the Microsoft Surface Diagnostic Toolkit will override the default English text and use the text contained in the file instead. To create a localization file, follow these steps:
+By default, the Microsoft Surface Diagnostic Toolkit is available in English only. If you want to localize the text of the Microsoft Surface Diagnostic Toolkit prompts into another language, you can do so by creating a custom localization file. To create a new localization file (.locale), follow these steps:
 
-1.  Open Notepad.
+1. Click the Tools ![images\surface-diagnostic-kit-gear-icon.png](images\surface-diagnostic-kit-gear-icon.png) button.
+2. Click the **Additional Language** page.
+3. Click the **Generate** button and the new .locale file is created.
 
-2.  Type the following line at the beginning of the file:
+The locale file that is created when you use these steps will have the same name as your executable file, even if it has been changed from the default. For example, if the Microsoft Surface Diagnostic Toolkit executable file is SurfaceDiagnosticToolkit.exe, the localization file would be SurfaceDiagnosticToolkit.locale. The locale file will be created in the same folder as the executable file. If a localization file with this name already exists, you will be prompted to overwrite the existing file. The file that is created when you click the **Generate** button is always generated in the default language, English.
 
-    ``` syntax
-    <root />
-    ```
+To customize the localization file, open the file in a text or XML editor such as Notepad. To edit the dialog for each test, replace the text for each phrase tag. (For example, `<phrase key="testdialog">text</phrase>`.) To use the file automatically when you start the Microsoft Surface Diagnostic Toolkit, simply save the file with the same name it had when it was created. To save the file for use with other instances of Microsoft Surface Diagnostic Toolkit, copy the file to another location or save the file with another name.
 
-3.  Save the file as SurfaceDiagnosticTool\_v1.0.60.0.locale in the same location where the Microsoft Surface Diagnostic Toolkit executable file is stored.
+If a localization file with the same name and in the same folder as the executable file is detected when Microsoft Surface Diagnostic Toolkit started, the alternate text specified in that localization file replaces the default dialog and prompts. If a custom localization file is not present or the file name is not the same as the executable file, the tool will default to English text. At any point you can also explicitly specify a localization file to be used by the Microsoft Surface Diagnostic Toolkit. To specify a localization file, follow these steps:
+1.	Click the Tools ![images\surface-diagnostic-kit-gear-icon.png](images\surface-diagnostic-kit-gear-icon.png) button.
+2.	Click the **Additional Language** page.
+3.	Click **Browse**.
+4.	Browse to and select your custom localization file.
 
-4.  Run the Microsoft Surface Diagnostic Toolkit executable file, Surface\_Diagnostic\_Toolkit\_v1.0.60.0.exe. The SurfaceDiagnosticTool\_v1.0.60.0.locale file will be populated with all of the text from the default prompts.
+A custom localization file selected through this process does not need a specific name. After you select the custom localization file, the Microsoft Surface Diagnostic Toolkit will import the contents and write them to a .locale file with the same name as the .exe file, just like if you click the **Generate** button to create a new .locale file.
 
-5.  Open the SurfaceDiagnosticTool\_v1.0.60.0.locale file in Notepad and change the text of each prompt to your custom or localized text.
+>**Note:**&nbsp;&nbsp;If you import a localization file by clicking the **Browse** button, an existing localization file will be overwritten without prompting if that file has the same name as the Microsoft Surface Diagnostic Toolkit executable file.
 
-6.  Save the SurfaceDiagnosticTool\_v1.0.60.0.locale file.
-
->**Note:**&nbsp;&nbsp;The SurfaceDiganosticTool\_v1.0.60.0.locale file must be located in the same folder and have the same name other than the file extension as the Microsoft Surface Diagnostic Toolkit executable file to use the custom prompt text. The SurfaceDiganosticTool\_v1.0.60.0.locale is an .xml file and must use UTF-8 encoding.
 
  
 
diff --git a/devices/surface/surface-dock-updater.md b/devices/surface/surface-dock-updater.md
index ea56c4cc95..4020a499aa 100644
--- a/devices/surface/surface-dock-updater.md
+++ b/devices/surface/surface-dock-updater.md
@@ -34,15 +34,15 @@ To update a Surface Dock with Microsoft Surface Dock Updater, follow these steps
 
     -   If the tool determines that the firmware of your Surface Dock is up to date, a **You have the latest firmware for this Surface Dock** message is displayed, as shown in Figure 1.
 
-        ![figure 1](images/surfacedockupdater-fig1-uptodate-568pix.png)
+        ![Screen that shows your Surface Dock firmware is up to date](images/surfacedockupdater-fig1-uptodate-568pix.png "Screen that shows your Surface Dock firmware is up to date")
 
-        Figure 1. Your Surface Dock firmware is up to date.
+        *Figure 1. Your Surface Dock firmware is up to date*
 
     -   If Microsoft Surface Dock Updater determines that the firmware of your Surface Dock is not up to date, a **This Surface Dock is not running the latest firmware** message is displayed, as shown in Figure 2.
 
-        ![figure 2](images/surfacedockupdater-fig2a-needsupdating.png)
+        ![Screen that shows your Surface Dock firmware needs to be updated](images/surfacedockupdater-fig2a-needsupdating.png "Screen that shows your Surface Dock firmware needs to be updated")
 
-        Figure 2. Your Surface Dock firmware needs to be updated
+        *Figure 2. Your Surface Dock firmware needs to be updated*
 
 3.  To begin the firmware update process, click **Update** on the **Surface Dock Firmware** page.
 
@@ -50,27 +50,27 @@ To update a Surface Dock with Microsoft Surface Dock Updater, follow these steps
 
 5.  As the firmware update is uploaded to the Surface Dock, a **Progress** page is displayed, as shown in Figure 3. Do not disconnect the Surface Dock while firmware is being uploaded.
 
-    ![figure 3](images/surfacedockupdater-fig3-progress.png)
+    ![Progress of firmware update upload](images/surfacedockupdater-fig3-progress.png "Progress of firmware update upload")
 
-    Figure 3. Progress of firmware update upload to Surface Dock
+    *Figure 3. Progress of firmware update upload to Surface Dock*
 
 6.  After the firmware update has successfully uploaded to the Surface Dock, you are prompted to disconnect and then reconnect the Surface Dock from the Surface device, as shown in Figure 4. The main chipset firmware update will be applied while the Surface Dock is disconnected.
 
-    ![figure 4](images/surfacedockupdater-fig4-disconnect.png)
+    ![Disconnect and reconnect Surface Dock when prompted](images/surfacedockupdater-fig4-disconnect.png "Disconnect and reconnect Surface Dock when prompted")
 
-    Figure 4. Disconnect and reconnect Surface Dock when prompted
+    *Figure 4. Disconnect and reconnect Surface Dock when prompted*
 
 7.  When the main chipset firmware update is verified, the DisplayPort chipset firmware update will be uploaded to the Surface Dock. Upon completion, a **Success** page is displayed and you will again be prompted to disconnect the Surface Dock, as shown in Figure 5.
 
-    ![figure 5](images/surfacedockupdater-fig5-success.png)
+    ![Screen showing successful upload](images/surfacedockupdater-fig5-success.png "Screen showing successful upload")
 
-    Figure 5. Successful upload of Surface Dock firmware
+    *Figure 5. Successful upload of Surface Dock firmware*
 
 8.  After you disconnect the Surface Dock the DisplayPort firmware update will be installed. This process occurs on the Surface Dock hardware while it is disconnected. The Surface Dock must remain powered for up to 3 minutes after it has been disconnected for the firmware update to successfully install. An **Update in Progress** page is displayed (as shown in Figure 6), with a countdown timer to show the estimated time remaining to complete the firmware update installation.
 
-    ![figure 6](images/surfacedockupdater-fig6-countdown.png)
+    ![Countdown timer to complete firmware installation](images/surfacedockupdater-fig6-countdown.png "Countdown timer to complete firmware installation")
 
-    Figure 6. Countdown timer to complete firmware installation on Surface Dock
+    *Figure 6. Countdown timer to complete firmware installation on Surface Dock*
 
 9.  If you want to update multiple Surface Docks in one sitting, you can click the **Update another Surface Dock** button to begin the process on the next Surface Dock.
 
@@ -83,9 +83,9 @@ To update a Surface Dock with Microsoft Surface Dock Updater, follow these steps
 
 If the Surface Dock firmware update process encounters an installation error with either firmware update, the **Encountered an unexpected error** page may be displayed, as shown in Figure 7.
 
-![figure 7](images/surfacedockupdater-fig7-error.png)
+![Firmware update installation error](images/surfacedockupdater-fig7-error.png "Firmware update installation error")
 
-Figure 7. Firmware update installation has encountered an error
+*Figure 7. Firmware update installation has encountered an error*
 
 Microsoft Surface Dock Updater logs its progress into the Event Log, as shown in Figure 8. If you need to troubleshoot an update through this tool, you will find Surface Dock events recorded with the following event IDs:
 
@@ -97,9 +97,9 @@ Microsoft Surface Dock Updater logs its progress into the Event Log, as shown in
 | 12105    | Error                                                    |
 
 
-Figure 8. Surface Dock Updater events in Event Viewer
+![Surface Dock Updater events in Event Viewer](images/surfacedockupdater-fig8-737test.png "Surface Dock Updater events in Event Viewer")
 
-![figure 8](images/surfacedockupdater-fig8-737test.png)
+*Figure 8. Surface Dock Updater events in Event Viewer*
 
 
 ## Related topics
diff --git a/devices/surface/surface-enterprise-management-mode.md b/devices/surface/surface-enterprise-management-mode.md
new file mode 100644
index 0000000000..981d6dae06
--- /dev/null
+++ b/devices/surface/surface-enterprise-management-mode.md
@@ -0,0 +1,163 @@
+---
+title: Surface Enterprise Management Mode (Surface)
+description: See how this feature of Surface devices with Surface UEFI helps you secure and manage firmware settings within your organization.
+keywords: uefi, configure, firmware, secure, semm
+ms.prod: w10
+ms.mktglfcycl: manage
+ms.pagetype: surface, devices, security
+ms.sitesec: library
+author: jobotto
+---
+
+# Microsoft Surface Enterprise Management Mode
+
+Microsoft Surface Enterprise Management Mode (SEMM) is a feature of Surface devices with Surface UEFI that allows you to secure and manage firmware settings within your organization. With SEMM, IT professionals can prepare configurations of UEFI settings and install them on a Surface device. In addition to the ability to configure UEFI settings, SEMM also uses a certificate to protect the configuration from unauthorized tampering or removal.
+
+>**Note**:&nbsp;&nbsp;SEMM is only available on devices with Surface UEFI firmware, such as Surface Pro 4 and Surface Book. For more information about Surface UEFI, see [Manage Surface UEFI Settings](https://technet.microsoft.com/en-us/itpro/surface/manage-surface-uefi-settings).
+
+When Surface devices are configured by SEMM and secured with the SEMM certificate, they are considered *enrolled* in SEMM. When the SEMM certificate is removed and control of UEFI settings is returned to the user of the device, the Surface device is considered *unenrolled* in SEMM.
+
+## Microsoft Surface UEFI Configurator
+
+The primary workspace of SEMM is Microsoft Surface UEFI Configurator, as shown in Figure 1. Microsoft Surface UEFI Configurator is a tool that is used to create Windows Installer (.msi) packages that are used to enroll, configure, and unenroll SEMM on a Surface device. These packages contain a configuration file where the settings for UEFI are specified. SEMM packages also contain a certificate that is installed and stored in firmware and used to verify the signature of configuration files before UEFI settings are applied.
+
+![Microsoft Surface UEFI Configurator](images\surface-ent-mgmt-fig1-uefi-configurator.png "Microsoft Surface UEFI Configurator")
+
+*Figure 1. Microsoft Surface UEFI Configurator*
+
+>**Note**:&nbsp;&nbsp;Windows 10 is required to run Microsoft Surface UEFI Configurator
+
+You can use the Microsoft Surface UEFI Configurator tool in three modes:
+
+* [Surface UEFI Configuration Package](#configuration-package). Use this mode to create a Surface UEFI configuration package to enroll a Surface device in SEMM and to configure UEFI settings on enrolled devices.
+* [Surface UEFI Reset Package](#reset-package). Use this mode to unenroll a Surface device from SEMM.
+* [Surface UEFI Recovery Request](#recovery-request). Use this mode to respond to a recovery request to unenroll a Surface device from SEMM where a Reset Package operation is not successful.
+
+
+#### Download Microsoft Surface UEFI Configurator
+
+You can download Microsoft Surface UEFI Configurator from the [Surface Tools for IT](https://www.microsoft.com/en-us/download/details.aspx?id=46703) page in the Microsoft Download Center.
+
+### Configuration package
+
+Surface UEFI configuration packages are the primary mechanism to implement and manage SEMM on Surface devices. These packages contain a configuration file of UEFI settings specified during creation of the package in Microsoft Surface UEFI Configurator and a certificate file, as shown in Figure 2. When a configuration package is run for the first time on a Surface device that is not already enrolled in SEMM, it provisions the certificate file in the device’s firmware and enrolls the device in SEMM. When enrolling a device in SEMM, you will be prompted to confirm the operation by providing the last two digits of the SEMM certificate thumbprint before the certificate file is stored and the enrollment can complete. This confirmation requires that a user be present at the device at the time of enrollment to perform the confirmation.
+
+![Secure a SEMM configuration package with a certificate](images\surface-ent-mgmt-fig2-securepackage.png "Secure a SEMM configuration package with a certificate")
+
+*Figure 2. Secure a SEMM configuration package with a certificate*
+
+See the [Surface Enterprise Management Mode certificate requirements](#surface-enterprise-management-mode-certificate-requirements) section of this article for more information about the requirements for the SEMM certificate.
+
+>**Note**:&nbsp;&nbsp;You can also specify a UEFI password with SEMM that is required to view the **Security**, **Devices**, **Boot Configuration**, or **Enterprise Management** pages of Surface UEFI.
+
+After a device is enrolled in SEMM, the configuration file is read and the settings specified in the file are applied to UEFI. When you run a configuration package on a device that is already enrolled in SEMM, the signature of the configuration file is checked against the certificate that is stored in the device firmware. If the signature does not match, no changes are applied to the device.
+
+You can use Surface UEFI settings to enable or disable the operation of individual components, such as cameras, wireless communication, or docking USB port (as shown in Figure 3), and configure advanced settings (as shown in Figure 4).
+
+![Enable or disable devices in Surface UEFI with SEMM](images\surface-ent-mgmt-fig3-enabledisable.png "Enable or disable devices in Surface UEFI with SEMM")
+
+*Figure 3. Enable or disable devices in Surface UEFI with SEMM*
+
+![Configure advanced settings in SEMM](images\surface-ent-mgmt-fig4-advancedsettings.png "Configure advanced settings in SEMM")
+
+*Figure 4. Configure advanced settings with SEMM*
+
+You can enable or disable the following devices with SEMM:
+
+* Docking USB Port
+* On-board Audio
+* Type Cover
+* Micro SD or SD Card Slots
+* Front Camera
+* Rear Camera
+* Infrared Camera, for Windows Hello
+* Bluetooth Only
+* Wi-Fi and Bluetooth
+* Trusted Platform Module (TPM)
+
+You can configure the following advanced settings with SEMM:
+
+* IPv6 support for PXE boot
+* Alternate boot order, where the Volume Down button and Power button can be pressed together during boot, to boot directly to a USB or Ethernet device
+* Lock the boot order to prevent changes
+* Support for booting to USB devices
+* Display of the Surface UEFI **Security** page
+* Display of the Surface UEFI **Devices** page
+* Display of the Surface UEFI **Boot** page
+
+>**Note**:&nbsp;&nbsp;When you create a SEMM configuration package, two characters are shown on the **Successful** page, as shown in Figure 5.
+
+![Certificate thumbprint display](images\surface-ent-mgmt-fig5-success.png "Certificate thumbprint display")
+
+*Figure 5. Display of the last two characters of the certificate thumbprint on the Successful page*
+
+These characters are the last two characters of the certificate thumbprint and should be written down or recorded. The characters are required to confirm enrollment in SEMM on a Surface device, as shown in Figure 6.
+
+![Enrollment confirmation in SEMM](images\surface-ent-mgmt-fig6-enrollconfirm.png "Enrollment confirmation in SEMM")
+
+*Figure 6. Enrollment confirmation in SEMM with the SEMM certificate thumbprint*
+
+To enroll a Surface device in SEMM or to apply the UEFI configuration from a configuration package, all you need to do is run the .msi file on the intended Surface device. You can use application deployment or operating system deployment technologies such as [System Center Configuration Manager](https://technet.microsoft.com/library/mt346023) or the [Microsoft Deployment Toolkit](https://technet.microsoft.com/en-us/windows/dn475741). When you enroll a device in SEMM you must be present to confirm the enrollment on the device. User interaction is not required when you apply a configuration to devices that are already enrolled in SEMM.
+
+### Reset package
+
+A Surface UEFI reset package is used to perform only one task — to unenroll a Surface device from SEMM. The reset package contains signed instructions to remove the SEMM certificate from the device’s firmware and to reset UEFI settings to factory default. Like a Surface UEFI configuration package, a reset package must be signed with the same SEMM certificate that is provisioned on the Surface device. When you create a SEMM reset package, you are required to supply the serial number of the Surface device you intend to reset. SEMM reset packages are not universal and are specific to one device.
+
+### Recovery request
+
+In some scenarios, it may be impossible to use a Surface UEFI reset package. (For example, if Windows becomes unusable on the Surface device.) In these scenarios you can unenroll the Surface device from SEMM through the **Enterprise Management** page of Surface UEFI (shown in Figure 7) with a Recovery Request operation.
+
+![Initiate a SEMM recovery request](images\surface-ent-mgmt-fig7-semmrecovery.png "Initiate a SEMM recovery request")
+
+*Figure 7. Initiate a SEMM recovery request on the Enterprise Management page*
+
+When you use the process on the **Enterprise Management** page to reset SEMM on a Surface device, you are provided with a Reset Request. This Reset Request can be saved as a file to a USB drive, copied as text, or read as a QR Code with a mobile device to be easily emailed or messaged. Use the Microsoft Surface UEFI Configurator Reset Request option to load a Reset Request file or enter the Reset Request text or QR Code. Microsoft Surface UEFI Configurator will generate a verification code that can be entered on the Surface device. If you enter the code on the Surface device and click **Restart**, the device will be unenrolled from SEMM. 
+
+>**Note**:&nbsp;&nbsp;A Reset Request expires two hours after it is created.
+
+## Surface Enterprise Management Mode certificate requirements
+
+>**Note**:&nbsp;&nbsp;The SEMM certificate is required to perform any modification to SEMM or Surface UEFI settings on enrolled Surface devices. If the SEMM certificate is corrupted or lost, SEMM cannot be removed or reset. Manage your SEMM certificate accordingly with an appropriate solution for backup and recovery.
+
+Packages created with the Microsoft Surface UEFI Configurator tool are signed with a certificate. This certificate ensures that after a device is enrolled in SEMM, only packages created with the approved certificate can be used to modify the settings of UEFI. The following settings are recommended for the SEMM certificate:
+
+* **Key Algorithm** – RSA 
+* **Key Length** – 2048
+* **Hash Algorithm** – SHA-256
+* **Type** – SSL Server Authentication
+* **Key Usage** – Key Encipherment
+* **Provider** – Microsoft Enhanced RSA and AES Cryptographic Provider
+* **Expiration Date** – 15 Months from certificate creation
+* **Key Export Policy** – Exportable
+
+It is also recommended that the SEMM certificate be authenticated in a two-tier public key infrastructure (PKI) architecture where the intermediate certification authority (CA) is dedicated to SEMM, enabling certificate revocation. For more information about a two-tier PKI configuration, see [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy](https://technet.microsoft.com/library/hh831348).
+
+>**Note**:&nbsp;&nbsp;You can use the following PowerShell script to create a self-signed certificate for use in proof-of-concept scenarios.
+  To use this script, copy the following text into Notepad and save the file as a PowerShell script (.ps1). This script creates a certificate with a password of `12345678`.<br/><br/>The certificate generated by this script is not recommended for production environments.
+  
+   ```
+if (-not (Test-Path "Demo Certificate"))  { New-Item -ItemType Directory -Force -Path "Demo Certificate" }
+if (Test-Path "Demo Certificate\TempOwner.pfx") { Remove-Item "Demo Certificate\TempOwner.pfx" }
+
+# Generate the Ownership private signing key with password 12345678
+$pw = ConvertTo-SecureString "12345678" -AsPlainText -Force
+
+$TestUefiV2 = New-SelfSignedCertificate `
+  -Subject "CN=Surface Demo Kit, O=Contoso Corporation, C=US" `
+  -Type SSLServerAuthentication `
+  -HashAlgorithm sha256 `
+  -KeyAlgorithm RSA `
+  -KeyLength 2048 `
+  -KeyUsage KeyEncipherment `
+  -KeyUsageProperty All `
+  -Provider "Microsoft Enhanced RSA and AES Cryptographic Provider" `
+  -NotAfter (Get-Date).AddYears(25) `
+  -TextExtension @("2.5.29.37={text}1.2.840.113549.1.1.1") `
+  -KeyExportPolicy Exportable
+
+$TestUefiV2 | Export-PfxCertificate -Password $pw -FilePath "Demo Certificate\TempOwner.pfx"
+   ```
+
+For use with SEMM and Microsoft Surface UEFI Configurator, the certificate must be exported with the private key and with password protection. Microsoft Surface UEFI Configurator will prompt you to select the SEMM certificate file (.pfx) and certificate password when it is required.
+
+>**Note**:&nbsp;&nbsp;For organizations that use an offline root in their PKI infrastructure, Microsoft Surface UEFI Configurator must be run in an environment connected to the root CA to authenticate the SEMM certificate. The packages generated by Microsoft Surface UEFI Configurator can be transferred as files and therefore can be transferred outside the offline network environment with removable storage, such as a USB stick.
diff --git a/devices/surface/unenroll-surface-devices-from-semm.md b/devices/surface/unenroll-surface-devices-from-semm.md
new file mode 100644
index 0000000000..5e31091376
--- /dev/null
+++ b/devices/surface/unenroll-surface-devices-from-semm.md
@@ -0,0 +1,148 @@
+---
+title: Unenroll Surface devices from SEMM (Surface)
+description: Learn how to unenroll a device from SEMM by using a Surface UEFI reset package or the Recovery Request option.
+keywords: surface enterprise management
+ms.prod: w10
+ms.mktglfcycl: manage
+ms.pagetype: surface, devices, security
+ms.sitesec: library
+author: jobotto
+---
+
+# Unenroll Surface devices from SEMM
+
+When a Surface device is enrolled in Surface Enterprise Management Mode (SEMM), a certificate is stored in the firmware of that device. The presence of that certificate and the enrollment in SEMM prevent any unauthorized changes to Surface UEFI settings or options while the device is enrolled in SEMM. To restore control of Surface UEFI settings to the user, the Surface device must be unenrolled from SEMM, a process sometimes described as reset or recovery. There are two methods you can use to unenroll a device from SEMM—a Surface UEFI reset package and a Recovery Request.
+
+>**Warning:**&nbsp;&nbsp;To unenroll a device from SEMM and restore user control of Surface UEFI settings, you must have the SEMM certificate that was used to enroll the device in SEMM. If this certificate becomes lost or corrupted, it is not possible to unenroll from SEMM. Back up and protect your SEMM certificate accordingly.
+
+For more information about SEMM, see [Microsoft Surface Enterprise Management Mode](https://technet.microsoft.com/en-us/itpro/surface/surface-enterprise-management-mode).
+
+## Unenroll a Surface device from SEMM with a Surface UEFI reset package
+
+The Surface UEFI reset package is the primary method you use to unenroll a Surface device from SEMM. Like a Surface UEFI configuration package, the reset package is a Windows Installer (.msi) file that configures SEMM on the device. Unlike the configuration package, the reset package will reset the Surface UEFI configuration on a Surface device to its default settings, remove the SEMM certificate, and unenroll the device from SEMM.
+
+Reset packages are created specifically for an individual Surface device. To begin the process of creating a reset package, you will need the serial number of the device you want to unenroll, as well as the SEMM certificate used to enroll the device. You can find the serial number of your Surface device on the **PC information** page of Surface UEFI, as shown in Figure 1. This page is displayed even if Surface UEFI is password protected and the incorrect password is entered.
+
+![Serial number of Surface device is displayed](images\surface-semm-unenroll-fig1.png "Serial number of Surface device is displayed")
+
+*Figure 1. The serial number of the Surface device is displayed on the Surface UEFI PC information page*
+
+>**Note:**&nbsp;&nbsp;To boot to Surface UEFI, press **Volume Up** and **Power** simultaneously while the device is off. Hold **Volume Up** until the Surface logo is displayed and the device begins to boot.
+
+To create a Surface UEFI reset package, follow these steps:
+
+1. Open Microsoft Surface UEFI Configurator from the Start menu.
+2. Click **Start**.
+3. Click **Reset Package**, as shown in Figure 2.
+
+   ![Select Reset Package to create a package to unenroll Surface device from SEMM](images\surface-semm-unenroll-fig2.png "Select Reset Package to create a package to unenroll Surface device from SEMM")
+
+   *Figure 2. Click Reset Package to create a package to unenroll a Surface device from SEMM*
+
+4. Click **Certificate Protection** to add your SEMM certificate file with private key (.pfx), as shown in Figure 3. Browse to the location of your certificate file, select the file, and then click **OK**.
+
+   ![Add the SEMM certificate to Surface UEFI reset package](images\surface-semm-unenroll-fig3.png "Add the SEMM certificate to Surface UEFI reset package")
+
+   *Figure 3. Add the SEMM certificate to a Surface UEFI reset package*
+
+5. Click **Next**.
+6. Type the serial number of the device you want to unenroll from SEMM (as shown in Figure 4), and then click **Build** to generate the Surface UEFI reset package.
+
+   ![Create a Surface UEFI reset package with serial number of Surface device](images\surface-semm-unenroll-fig4.png "Create a Surface UEFI reset package with serial number of Surface device")
+
+   *Figure 4. Use the serial number of your Surface device to create a Surface UEFI reset package*
+
+7. In the **Save As** dialog box, specify a name for the Surface UEFI reset package, browse to the location where you would like to save the file, and then click **Save**.
+8. When the package generation has completed, the **Successful** page is displayed. Click **End** to complete package creation and close Microsoft Surface UEFI Configurator.
+
+Run the Surface UEFI reset package Windows Installer (.msi) file on the Surface device to unenroll the device from SEMM. The reset package will require a reboot to perform the unenroll operation. After the device has been unenrolled, you can verify the successful removal by ensuring that the **Microsoft Surface Configuration Package** item in **Programs and Features** (shown in Figure 5) is no longer present.
+
+![Screen that shows device is enrolled in SEMM](images\surface-semm-unenroll-fig5.png "Screen that shows device is enrolled in SEMM")
+
+*Figure 5. The presence of the Microsoft Surface Configuration Package item in Programs and Features indicates that the device is enrolled in SEMM*
+
+## Unenroll a Surface device from SEMM with a Recovery Request
+
+In some scenarios, a Surface UEFI reset package may not be a viable option to unenroll a Surface device from SEMM (for example, where Windows has become unusable). In these scenarios you can unenroll the device by using a Recovery Request generated from within Surface UEFI. The Recovery Request process can be initiated even on devices where you do not have the Surface UEFI password.
+
+The Recovery Request process is initiated from Surface UEFI on the Surface device, approved with Microsoft Surface UEFI Configurator on another computer, and then completed in Surface UEFI. Like the reset package, approving a Recovery Request with Microsoft Surface UEFI Configurator requires access to the SEMM certificate that was used to enroll the Surface device.
+
+To initiate a Recovery Request, follow these steps:
+
+1. Boot the Surface device that is to be unenrolled from SEMM to Surface UEFI.
+2. Type the Surface UEFI password if you are prompted to do so.
+3. Click the **Enterprise management** page, as shown in Figure 6.
+
+   ![Enterprise Management page](images\surface-semm-unenroll-fig6.png "Enterprise Management page")
+
+   *Figure 6. The Enterprise management page is displayed in Surface UEFI on devices enrolled in SEMM*
+
+4. Click or press **Get Started**.
+5. Click or press **Next** to begin the Recovery Request process.
+   >**Note:**&nbsp;&nbsp;A Recovery Request expires two hours after it is created. If a Recovery Request is not completed in this time, you will have to restart the Recovery Request process.
+6. Select **SEMM Certificate** from the list of certificates displayed on the **Choose a SEMM reset key** page (shown in Figure 7), and then click or press **Next**.
+
+   ![Select SEMM certificate for your Recovery Request](images\surface-semm-unenroll-fig7.png "Select SEMM certificate for your Recovery Request")
+
+   *Figure 7. Choose SEMM Certificate for your Recovery Request (Reset Request)*
+
+7. On the **Enter SEMM reset verification code** page you can click the **QR Code** or **Text** buttons to display your Recovery Request (Reset Request) as shown in Figure 8, or the **USB** button to save your Recovery Request (Reset Request) as a file to a USB drive, as shown in Figure 9.
+
+   ![Recovery Request displayed as a QR Code](images\surface-semm-unenroll-fig8.png "Recovery Request displayed as a QR Code")
+
+   *Figure 8. A Recovery Request (Reset Request) displayed as a QR Code*
+
+   ![Save a recovery request to a USB drive](images\surface-semm-unenroll-fig9.png "Save a recovery request to a USB drive")
+
+   *Figure 9. Save a Recovery Request (Reset Request) to a USB drive*
+
+   * To use a QR Code Recovery Request (Reset Request), use a QR reader app on a mobile device to read the code. The QR reader app will translate the QR code into an alphanumeric string. You can then email or message that string to the administrator that will produce the reset verification code with Microsoft Surface UEFI Configurator.
+   * To use a Recovery Request (Reset Request) saved to a USB drive as a file, use the USB drive to transfer the file to the computer where Microsoft Surface UEFI Configurator will be used to produce the Reset Verification Code. The file can also be copied from the USB drive on another device to be emailed or transferred over the network.
+   * To use the Recovery Request (Reset Request) as text, simply type the text directly into Microsoft Surface UEFI Configurator.
+
+8. Open Microsoft Surface UEFI Configurator from the Start menu on another computer.
+>**Note:**&nbsp;&nbsp;Microsoft Surface UEFI Configurator must run in an environment that is able to authenticate the certificate chain for the SEMM certificate.
+9. Click **Start**.
+10. Click **Recovery Request**, as shown in Figure 10.
+
+   ![Start process to approve a Recovery Request](images\surface-semm-unenroll-fig10.png "Start process to approve a Recovery Request")
+
+   *Figure 10. Click Recovery Request to begin the process to approve a Recovery Request*
+
+11.	Click **Certificate Protection** to authenticate the Recovery Request with the SEMM certificate.
+12.	Browse to and select your SEMM certificate file, and then click **OK**.
+13.	When you are prompted to enter the certificate password as shown in Figure 11, type and confirm the password for the certificate file, and then click **OK**.
+
+   ![Type password for SEMM certificate](images\surface-semm-unenroll-fig11.png "Type password for SEMM certificate")
+
+   *Figure 11. Type the password for the SEMM certificate*
+
+14. Click **Next**.
+15. Enter the Recovery Request (Reset Request), and then click **Generate** to create a reset verification code (as shown in Figure 12).
+
+   ![Enter the recovery request](images\surface-semm-unenroll-fig12.png "Enter the recovery request")
+
+   *Figure 12. Enter the Recovery Request (Reset Request)*
+
+   * If you displayed the Recovery Request (Reset Request) as text on the Surface device being reset, use the keyboard to type the Recovery Request (Reset Request)  in the provided field.
+   * If you displayed the Recovery Request (Reset Request) as a QR Code and then used a messaging or email application to send the code to the computer with Microsoft Surface UEFI Configurator, copy and paste the code into the provided field.
+   * If you saved the Recovery Request (Reset Request) as a file to a USB drive, click the **Import** button, browse to and select the Recovery Request (Reset Request) file, and then click **OK**.
+
+16.	The reset verification code is displayed in Microsoft Surface UEFI Configurator, as shown in Figure 13.
+
+   ![Display of the reset verification code](images\surface-semm-unenroll-fig13.png "Display of the reset verification code")
+
+   *Figure 13. The reset verification code displayed in Microsoft Surface UEFI Configurator*
+
+   * Click the **Share** button to send the reset verification code by email.
+
+17.	Enter the reset verification code in the provided field on the Surface device (shown in Figure 8), and then click or press **Verify** to reset the device and unenroll the device from SEMM.
+18.	Click or press **Restart now** on the **SEMM reset successful** page to complete the unenrollment from SEMM, as shown in Figure 14.
+
+   ![Example display of successful unenrollment from SEMM](images\surface-semm-unenroll-fig14.png "Example display of successful unenrollment from SEMM")
+
+   *Figure 14. Successful unenrollment from SEMM*
+
+19.	Click **End** in Microsoft Surface UEFI Configurator to complete the Recovery Request (Reset Request) process and close Microsoft Surface UEFI Configurator.
+
+
diff --git a/devices/surface/upgrade-surface-devices-to-windows-10-with-mdt.md b/devices/surface/upgrade-surface-devices-to-windows-10-with-mdt.md
new file mode 100644
index 0000000000..d44af98e0d
--- /dev/null
+++ b/devices/surface/upgrade-surface-devices-to-windows-10-with-mdt.md
@@ -0,0 +1,226 @@
+---
+title: Upgrade Surface devices to Windows 10 with Microsoft Deployment Toolkit (Surface)
+description: Find out how to perform a Windows 10 upgrade deployment to your Surface devices. 
+keywords: windows 10 surface, upgrade, customize, mdt
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.pagetype: surface
+ms.sitesec: library
+author: Scottmca
+---
+
+#  Upgrade Surface devices to Windows 10 with Microsoft Deployment Toolkit
+
+#### Applies to
+* Surface Pro 3
+* Surface 3
+* Surface Pro 2
+* Surface Pro
+* Windows 10
+
+In addition to the traditional deployment method of reimaging devices, administrators that want to upgrade Surface devices that are running Windows 8.1 or Windows 10 have the option of deploying upgrades. By performing an upgrade deployment, Windows 10 can be applied to devices without removing users, apps, or configuration. The users of the deployed devices can simply continue using the devices with the same apps and settings that they used prior to the upgrade. The process described in this article shows how to perform a Windows 10 upgrade deployment to Surface devices.
+
+If you are not already familiar with the deployment of Windows or the Microsoft deployment tools and technologies, you should read [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md) and familiarize yourself with the traditional deployment method before you proceed.
+
+#### The upgrade concept
+
+When you use the factory installation media to install Windows on a device, you are presented with two options or *installation paths* to install Windows on that device. The first of these installation paths – *clean installation* –  allows you to apply a factory image of Windows to that device, including all default settings. The second of these installation paths – *upgrade* – allows you to apply Windows to the device but retains the device’s users, apps, and settings.
+
+When you perform a Windows deployment using traditional deployment methods, you follow an installation path that is very similar to a clean installation. The primary difference between the clean installation and the traditional deployment method of *reimaging* is that with reimaging, you can apply an image that includes customizations. Microsoft deployment technologies, such as the Microsoft Deployment Toolkit (MDT), expand the capabilities of the reimaging process by modifying the image during deployment. For example, MDT is able to inject drivers for a specific hardware configuration during deployment, and with pre and post imaging scripts to perform a number of tasks, such as the installation of applications.
+
+For versions of Windows prior to Windows 10, if you wanted to install a new version of Windows on your devices and preserve the configuration of those systems, you had to perform additional steps during your deployment. For example, if you wanted to keep the data of users on the device, you had to back up user data with the User State Migration Tool (USMT) prior to the deployment and restore that data after the deployment had completed.
+
+Introduced with Windows 10 and MDT 2013 Update 1, you can use the upgrade installation path directly with Microsoft deployment technologies such as the Microsoft Deployment Toolkit (MDT). With an upgrade deployment you can use the same deployment technologies and process, but you can preserve users settings, and applications of the existing environment on the device.
+
+## Deployment tools and resources
+
+Performing an upgrade deployment of Windows 10 requires the same tools and resources that are required for a traditional reimaging deployment. You can read about the tools required, including detailed explanations and installation instructions, in [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md). To proceed with the upgrade deployment described in this article, you will need the following tools installed and configured:
+
+* [Microsoft Deployment Toolkit (MDT)](https://technet.microsoft.com/en-us/windows/dn475741)
+* [Windows Assessment and Deployment Kit (Windows ADK)](https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit#windowsadk), which includes:
+   * Deployment Image Servicing and Management (DISM)
+   * Windows Preinstallation Environment (Windows PE)
+   * Windows System Image Manager (Windows SIM)
+
+You will also need to have available the following resources:
+
+* Windows 10 installation files, such as the installation media downloaded from the [Volume Licensing Service Center](https://www.microsoft.com/Licensing/servicecenter/default.aspx)
+   >**Note:**&nbsp;&nbsp;Installation media for use with MDT must contain a Windows image in Windows Imaging Format (.wim). Installation media produced by the [Get Windows 10](https://www.microsoft.com/en-us/software-download/windows10/) page does not use a .wim file, instead using an Electronic Software Download (.esd) file, which is not compatible with MDT.
+* [Surface firmware and drivers](https://technet.microsoft.com/en-us/itpro/surface/deploy-the-latest-firmware-and-drivers-for-surface-devices) for Windows 10
+* Application installation files for any applications you want to install, such as the Surface app
+
+## Prepare the upgrade deployment
+
+Before you begin the process described in this section, you need to have installed and configured the deployment tools outlined in the previous [Deployment tools and resources](#deployment-tools-and-resources) section. For instructions on how to install and configure the deployment tools, see the **Install the deployment tools** section in the [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md#install-the-deployment-tools) article. You will also have needed to create a deployment share with MDT, described in the section Create a Deployment Share in the aforementioned article.
+
+### Import Windows 10 installation files
+
+Windows 10 installation files only need to be imported if you have not already done so in the deployment share. To import Windows 10 installation files, follow the steps described in the **Import Windows installation files** section in the [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md#import-windows-installation-files) article.
+
+### Import Surface drivers
+In the import process example shown in the [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md) article, drivers for Surface Pro 4 were imported for Windows 10. To perform an upgrade deployment of Windows 10 to Surface Pro 3, drivers for Surface Pro 3 must also be imported. To import the Surface drivers for Surface Pro 3, follow these steps:
+
+1. Download the Surface Pro 3 firmware and driver pack for Windows 10 archive file (.zip), SurfacePro3_Win10_xxxxxx.zip, from the [Surface Pro 3 download page](https://www.microsoft.com/en-US/download/details.aspx?id=38826) in the Microsoft Download Center.
+2. Extract the contents of the Surface Pro 3 firmware and driver pack archive file to a temporary folder. Keep the driver files separate from other drivers or files.
+3. Open the Deployment Workbench and expand the Deployment Shares node and your deployment share. 
+4. If you have not already created a folder structure by operating system version, you should do so next. Under the **Windows 10 x64** folder, create a new folder for Surface Pro 3 drivers named **Surface Pro 3**. Your Out-of-Box Drivers folder should resemble the following structure:
+  * WinPE x86
+  * WinPE x64
+  * Windows 10 x64
+    * Microsoft Corporation
+      * Surface Pro 4
+      * Surface Pro 3
+5. Right-click the **Surface Pro 3** folder, and then click **Import Drivers** to start the Import Drivers Wizard, as shown in Figure 1.
+
+  ![Import Surface Pro 3 drivers for Windows 10](images\surface-upgrademdt-fig1.png "Import Surface Pro 3 drivers for Windows 10")
+
+  *Figure 1. Import Surface Pro 3 drivers for Windows 10*
+
+6. The Import Driver Wizard displays a series of steps, as follows:
+  - **Specify Directory** – Click **Browse** and navigate to the folder where you extracted the Surface Pro 3 firmware and drivers in Step 1.
+  - **Summary** – Review the specified configuration on this page before you click **Next** to begin the import process.
+  - **Progress** – While the drivers are imported, a progress bar is displayed on this page.
+  - **Confirmation** – When the import process completes, the success of the process is displayed on this page. Click **Finish** to complete Import Drivers Wizard.
+7. Select the **Surface Pro 3** folder and verify that the folder now contains the drivers that were imported, as shown in Figure 2.
+
+  ![Drivers for Surface Pro 3 imported and organized in the MDT deployment share](images\surface-upgrademdt-fig2.png "Drivers for Surface Pro 3 imported and organized in the MDT deployment share")
+
+  *Figure 2. Drivers for Surface Pro 3 imported and organized in the MDT deployment share*
+
+### Import applications
+
+Installation of applications in an upgrade deployment is not always necessary because the applications from the previous environment will remain on the device. (For example, in the [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md) article, the deployment includes Office 365 which is not required in an upgrade deployment where the user is already using Office 365 on the device.)
+
+There are still some circumstances where you will want to deploy an application, even during an upgrade deployment. For example, you may have Surface Pro 3 devices on which you would like to add the Surface app. To deploy the Surface app in an upgrade scenario use the same process as you would for a traditional deployment. See the [Deploy Surface app with Windows Store for Business](https://technet.microsoft.com/en-us/itpro/surface/deploy-surface-app-with-windows-store-for-business) article for instructions on how to add the Surface app to an MDT task sequence.
+
+### Create the upgrade task sequence
+
+After you have all of the resources in place to perform the deployment (including the installation files, Surface drivers, and application files), the next step is to create the upgrade task sequence. This task sequence is a series of steps that will be performed on the device being upgraded that applies the new Windows environment, compatible drivers, and any applications you have specified.
+
+Create the upgrade task sequence with the following process:
+
+1. In the Deployment Workbench under your Deployment Share, right-click the **Task Sequences** folder, and then click **New Task Sequence** to start the New Task Sequence Wizard.
+2. Use these steps to create the deployment task sequence with the New Task Sequence Wizard:
+  - **General Settings** – Enter an identifier for the deployment task sequence in the Task Sequence ID field, a name for the deployment task sequence in the Task Sequence Name field, and any comments for the deployment task sequence in the **Task Sequence Comments** field, and then click **Next**.
+  >**Note:**&nbsp;&nbsp;The **Task Sequence ID** field cannot contain spaces and can be a maximum of 16 characters.
+  - **Select Template** – Select **Standard Client Upgrade Task Sequence** from the drop-down menu, and then click **Next**.
+  - **Select OS** – Navigate to and select the Windows image that you imported, and then click **Next**.
+  - **Specify Product Key** – Select the product key entry that fits your organization’s licensing system. The **Do Not Specify a Product Key at This Time** option can be used for systems that will be activated via Key Management Services (KMS) or Active Directory Based Activation (ADBA). A product key can be specified specifically if your organization uses Multiple Activation Keys (MAK). Click **Next**.
+  - **OS Settings** – Enter a name and organization for registration of Windows, and a home page URL for users when they browse the Internet in the **Full Name**, **Organization**, and **Internet Explorer Home Page** fields, and then click **Next**.
+  - **Admin Password** – Select **Use the Specified Local Administrator Password** and enter a password in the provided fields, and then click **Next**.
+  - **Summary** – Review the specified configuration on this page before you click **Next** to begin creation of the task sequence.
+  - **Progress** – While the task sequence is being created, a progress bar is displayed on this page.
+  - **Confirmation** – When the task sequence creation completes, the success of the process is displayed on this page. Click **Finish** to complete New Task Sequence Wizard.
+
+After the task sequence is created, you can modify some additional settings to provide additional automation of the task sequence and require less interaction during deployment. Follow these steps to modify the task sequence:
+
+1. Select the **Task Sequences** folder, right-click the new task sequence you created, and then click **Properties**.
+2. Select the **Task Sequence** tab to view the steps that are included in the new task sequence.
+3. Select the **Windows Update (Pre-Application Installation)** step, located under the **State Restore** folder.
+4. Click the **Options** tab, and then clear the **Disable This Step** check box.
+5. Repeat Step 3 and Step 4 for the **Windows Update (Post-Application Installation)** step.
+6. Between the two Windows Update steps is an **Install Applications** step. Select that step and then click **Add**.
+7. Hover the mouse over **General** under the **Add** menu, and then choose **Install Application**. This will add a new step after the selected step for the installation of a specific application as shown in Figure 3.
+
+  ![A new Install Application step in the deployment task sequence](images\surface-upgrademdt-fig3.png "A new Install Application step in the deployment task sequence")
+  
+  *Figure 3. A new Install Application step in the deployment task sequence*
+  
+8. On the **Properties** tab of the new **Install Application** step, enter **Install Surface App** in the **Name** field.
+9. Select **Install a Single Application**, and then click **Browse** to view available applications that have been imported into the deployment share.
+10. Select **Surface App** from the list of applications, and then click **OK**.
+11. Expand the **Preinstall** folder and select the **Enable BitLocker (Offline)** step.
+12. Open the **Add** menu again and choose **Set Task Sequence Variable** from under the **General** menu.
+13. On the **Properties** tab of the new **Set Task Sequence Variable** step (as shown in Figure 4) configure the following options:
+
+  - **Name** – Set DriverGroup001
+  - **Task Sequence Variable** – DriverGroup001
+  - **Value** – Windows 10 x64\%Make%\%Model%
+
+  ![Configure a new Set Task Sequence Variable step in the deployment task sequence](images\surface-upgrademdt-fig4.png "Configure a new Set Task Sequence Variable step in the deployment task sequence")
+  
+  *Figure 4. Configure a new Set Task Sequence Variable step in the deployment task sequence*
+  
+14. Select the **Inject Drivers** step, the next step in the task sequence.
+15. On the **Properties** tab of the **Inject Drivers** step (as shown in Figure 5) configure the following options:
+  * In the **Choose a selection profile** drop-down menu, select **Nothing**.
+  * Click the **Install all drivers from the selection profile** button.
+  
+  ![Configure the deployment task sequence to not install drivers](images\surface-upgrademdt-fig5.png "Configure the deployment task sequence to not install drivers")
+  
+  *Figure 5. Configure the deployment task sequence to not install drivers*
+
+16. Click **OK** to apply changes to the task sequence and close the task sequence properties window.
+
+Steps 11 through 15 are very important to the deployment of Surface devices. These steps instruct the task sequence to install only drivers that are organized into the correct folder using the organization for drivers from the [Import Surface drivers](#import-surface-drivers) section. 
+
+### Deployment share rules
+
+To automate the upgrade process, the rules of the MDT deployment share need to be modified to suppress prompts for information from the user. Unlike a traditional deployment, Bootstrap.ini does not need to be modified because the deployment process is not started from boot media. Similarly, boot media does not need to be imported into WDS because it will not be booted over the network with PXE.
+
+To modify the deployment share rules and suppress the Windows Deployment Wizard prompts for information, copy and paste the following text into the text box on the **Rules** tab of your deployment share properties:
+
+```
+[Settings]
+Priority=Model,Default
+Properties=MyCustomProperty
+
+[Surface Pro 4]
+SkipTaskSequence=YES
+TaskSequenceID=Win10SP4
+
+[Surface Pro 3]
+SkipTaskSequence=YES
+TaskSequenceID=Win10SP3Up
+
+[Default]
+OSInstall=Y
+SkipCapture=YES
+SkipAdminPassword=YES
+SkipProductKey=YES
+SkipComputerBackup=YES
+SkipBitLocker=YES
+SkipBDDWelcome=YES
+SkipUserData=YES
+UserDataLocation=AUTO
+SkipApplications=YES
+SkipPackageDisplay=YES
+SkipComputerName=YES
+SkipDomainMembership=YES
+JoinDomain=contoso.com
+DomainAdmin=MDT
+DomainAdminDomain=contoso
+DomainAdminPassword=P@ssw0rd
+SkipLocaleSelection=YES
+KeyboardLocale=en-US
+UserLocale=en-US
+UILanguage=en-US
+SkipTimeZone=YES
+TimeZoneName=Pacific Standard Time
+UserID=MDTUser
+UserDomain=STNDeployServer
+UserPassword=P@ssw0rd
+SkipSummary=YES
+SkipFinalSummary=YES
+FinishAction=LOGOFF
+```
+
+
+
+For more information about the rules configured by this text, see the **Configure deployment share rules** section in the [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md#configure-deployment-share-rules) article.
+
+### Update deployment share
+
+To update the deployment share, right-click the deployment share in the Deployment Workbench and click **Update Deployment Share**, then proceed through the Update Deployment Share Wizard. See the **Update and import updated MDT boot media** section of the [Deploy Windows 10 to Surface devices with MDT](deploy-windows-10-to-surface-devices-with-mdt.md#update-and-import-updated-mdt-boot-media) article for detailed steps.
+
+### Run the upgrade deployment
+
+Unlike a traditional deployment, the upgrade task sequence must be launched from within the Windows environment that will be upgraded. This requires that a user on the device to be upgraded navigate to the deployment share over the network and launch a script, LiteTouch.vbs. This script is the same script that displays the Windows Deployment Wizard in Windows PE in a traditional deployment. In this scenario, Litetouch.vbs will run within Windows. To perform the upgrade task sequence and deploy the upgrade to Windows 10 follow these steps:
+
+1. Browse to the network location of your deployment share in File Explorer.
+2. Navigate to the **Scripts** folder, locate **LiteTouch.vbs**, and then double-click **LiteTouch.vbs** to start the Windows Deployment Wizard.
+3. Enter your credentials when prompted.
+4. The upgrade task sequence for Surface Pro 3 devices will automatically start when the model of the device is detected and determined to match the deployment share rules.
+5. The upgrade process will occur automatically and without user interaction.
+
+The task sequence will automatically install the drivers for Surface Pro 3 and the Surface app, and will perform any outstanding Windows Updates. When it completes, it will log out and be ready for the user to log on with the credentials they have always used for this device.
diff --git a/education/windows/take-a-test-multiple-pcs.md b/education/windows/take-a-test-multiple-pcs.md
index 7ab6d68a18..d0d6052781 100644
--- a/education/windows/take-a-test-multiple-pcs.md
+++ b/education/windows/take-a-test-multiple-pcs.md
@@ -20,10 +20,10 @@ author: jdeckerMS
 Many schools use online testing for formative and summative assessments. It's critical that students use a secure browser that prevents them from using other computer or Internet resources during the test. The **Take a Test** app in Windows 10, Version 1607, creates the right environment for taking a test:
 
 - A Microsoft Edge browser window opens, showing just the test and nothing else.
+- The clipboard is cleared.
 - Students aren’t able to go to other websites.
 - Students can’t open or access other apps.
 - Students can't share, print, or record their screens.
-- Students can’t copy or paste.
 - Students can’t change settings, extend their display, see notifications, get updates, or use autofill features.
 - Cortana is turned off.
 
diff --git a/education/windows/take-a-test-single-pc.md b/education/windows/take-a-test-single-pc.md
index a1fa849959..fece24bac1 100644
--- a/education/windows/take-a-test-single-pc.md
+++ b/education/windows/take-a-test-single-pc.md
@@ -20,10 +20,10 @@ author: jdeckerMS
 The **Take a Test** app in Windows 10, Version 1607, creates the right environment for taking a test:
 
 - A Microsoft Edge browser window opens, showing just the test and nothing else.
+- The clipboard is cleared.
 - Students aren’t able to go to other websites.
 - Students can’t open or access other apps.
 - Students can't share, print, or record their screens.
-- Students can’t copy or paste.
 - Students can’t change settings, extend their display, see notifications, get updates, or use autofill features.
 - Cortana is turned off.
 
diff --git a/education/windows/take-tests-in-windows-10.md b/education/windows/take-tests-in-windows-10.md
index 9e881238b6..c0de33cc5b 100644
--- a/education/windows/take-tests-in-windows-10.md
+++ b/education/windows/take-tests-in-windows-10.md
@@ -20,10 +20,10 @@ author: jdeckerMS
 Many schools use online testing for formative and summative assessments. It's critical that students use a secure browser that prevents them from using other computer or Internet resources during the test. The **Take a Test** app in Windows 10, Version 1607, creates the right environment for taking a test:
 
 - **Take a Test** shows just the test and nothing else.
+- **Take a Test** clears the clipboard.
 - Students aren’t able to go to other websites.
 - Students can’t open or access other apps.
 - Students can't share, print, or record their screens.
-- Students can’t copy or paste.
 - Students can’t change settings, extend their display, see notifications, get updates, or use autofill features.
 - Cortana is turned off.
 
diff --git a/windows/deploy/TOC.md b/windows/deploy/TOC.md
index ff58491fd1..a6d2e9d108 100644
--- a/windows/deploy/TOC.md
+++ b/windows/deploy/TOC.md
@@ -35,6 +35,7 @@
 ## [Upgrade to Windows 10 with the Microsoft Deployment Toolkit](upgrade-to-windows-10-with-the-microsoft-deployment-toolkit.md)
 ## [Upgrade to Windows 10 with System Center Configuration Manager](upgrade-to-windows-10-with-system-center-configuraton-manager.md)
 ## [Configure a PXE server to load Windows PE](configure-a-pxe-server-to-load-windows-pe.md)
+## [Windows 10 upgrade paths](windows-10-upgrade-paths.md)
 ## [Windows 10 edition upgrade](windows-10-edition-upgrades.md)
 ## [Deploy Windows To Go in your organization](deploy-windows-to-go.md)
 ## [Update Windows 10 images with provisioning packages](update-windows-10-images-with-provisioning-packages.md)
diff --git a/windows/deploy/change-history-for-deploy-windows-10.md b/windows/deploy/change-history-for-deploy-windows-10.md
index ce380b474a..3276e429b0 100644
--- a/windows/deploy/change-history-for-deploy-windows-10.md
+++ b/windows/deploy/change-history-for-deploy-windows-10.md
@@ -15,7 +15,8 @@ This topic lists new and updated topics in the [Deploy Windows 10](index.md) doc
 | New or changed topic | Description |
 |----------------------|-------------|
 | [Configure a PXE server to load Windows PE](configure-a-pxe-server-to-load-windows-pe.md) | New |
-| [User State Migration Tool Technical Reference](usmt-technical-reference.md) | Updated |
+| [User State Migration Tool Technical Reference](usmt-technical-reference.md) | Updated support statement for Office 2016 |
+| [Windows 10 upgrade paths](windows-10-upgrade-paths.md) | New |
 
 ## May 2016
 | New or changed topic | Description |
diff --git a/windows/deploy/images/PoC.png b/windows/deploy/images/PoC.png
new file mode 100644
index 0000000000..de73506071
Binary files /dev/null and b/windows/deploy/images/PoC.png differ
diff --git a/windows/deploy/images/check_grn.png b/windows/deploy/images/check_grn.png
new file mode 100644
index 0000000000..f9f04cd6bd
Binary files /dev/null and b/windows/deploy/images/check_grn.png differ
diff --git a/windows/deploy/images/hyper-v-feature.png b/windows/deploy/images/hyper-v-feature.png
new file mode 100644
index 0000000000..d7293d808e
Binary files /dev/null and b/windows/deploy/images/hyper-v-feature.png differ
diff --git a/windows/deploy/images/sec-bios.png b/windows/deploy/images/sec-bios.png
new file mode 100644
index 0000000000..4498497d59
Binary files /dev/null and b/windows/deploy/images/sec-bios.png differ
diff --git a/windows/deploy/images/x_blk.png b/windows/deploy/images/x_blk.png
new file mode 100644
index 0000000000..69432ff71c
Binary files /dev/null and b/windows/deploy/images/x_blk.png differ
diff --git a/windows/deploy/index.md b/windows/deploy/index.md
index c6b8e27ed1..d4254111b1 100644
--- a/windows/deploy/index.md
+++ b/windows/deploy/index.md
@@ -23,6 +23,7 @@ Learn about deploying Windows 10 for IT professionals.
 |[Upgrade to Windows 10 with System Center Configuration Manager](upgrade-to-windows-10-with-system-center-configuraton-manager.md) |The simplest path to upgrade PCs currently running Windows 7, Windows 8, or Windows 8.1 to Windows 10 is through an in-place upgrade. You can use a System Center Configuration Manager task sequence to completely automate the process. |
 |[Configure a PXE server to load Windows PE](configure-a-pxe-server-to-load-windows-pe.md) |This guide describes how to configure a PXE server to load Windows PE by booting a client computer from the network. |
 |[Windows 10 edition upgrade](windows-10-edition-upgrades.md) |With Windows 10, you can quickly upgrade from one edition of Windows 10 to another, provided the upgrade path is supported. |
+|[Windows 10 upgrade paths](windows-10-upgrade-paths.md) |You can upgrade directly to Windows 10 from a previous operating system. |
 |[Deploy Windows To Go in your organization](deploy-windows-to-go.md) |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](../plan/windows-to-go-overview.md) and [Prepare your organization for Windows To Go](../plan/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. |
 |[Update Windows 10 images with provisioning packages](update-windows-10-images-with-provisioning-packages.md) |Use a provisioning package to apply settings, profiles, and file assets to a Windows 10 image. |
 |[Upgrade a Windows Phone 8.1 to Windows 10 Mobile with Mobile Device Management](upgrade-windows-phone-8-1-to-10.md) |This topic describes how to upgrade eligible Windows Phone 8.1 devices to Windows 10 Mobile. |
diff --git a/windows/deploy/windows-10-edition-upgrades.md b/windows/deploy/windows-10-edition-upgrades.md
index 8b20a8f77c..cbc6ee73c5 100644
--- a/windows/deploy/windows-10-edition-upgrades.md
+++ b/windows/deploy/windows-10-edition-upgrades.md
@@ -15,17 +15,17 @@ author: greg-lindsay
 -   Windows 10
 -   Windows 10 Mobile
 
-With Windows 10, you can quickly upgrade from one edition of Windows 10 to another, provided the upgrade path is supported. For information on what edition of Windows 10 is right for you, see [Compare Windows 10 Editions](http://go.microsoft.com/fwlink/p/?LinkID=690882).
+With Windows 10, you can quickly upgrade from one edition of Windows 10 to another, provided the upgrade path is supported. For information on what edition of Windows 10 is right for you, see [Compare Windows 10 Editions](http://go.microsoft.com/fwlink/p/?LinkID=690882). For a comprehensive list of all possible upgrade paths to Windows 10, see [Windows 10 upgrade paths](windows-10-upgrade-paths.md).
 
-The following table shows the methods you can use to upgrade editions of Windows 10.
+The following table shows the methods and paths available to change the edition of Windows 10 that is running on your computer.
 
 |Method |Home > Pro |Home > Education |Pro > Education |Pro > Enterprise |Ent > Education |Mobile > Mobile Enterprise |
 |-------|-----------|-----------------|----------------|-----------------|----------------|--------|
-| Using mobile device management (MDM) |![unsupported](images/crossmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |
-| Using a provisioning package |![unsupported](images/crossmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |
-| Using a command-line tool |![unsupported](images/crossmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![unsupported](images/crossmark.png) |
-| Entering a product key manually |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![supported](images/checkmark.png) |![unsupported](images/crossmark.png) |
-| Purchasing a license from the Windows Store |![supported](images/checkmark.png) |![unsupported](images/crossmark.png) |![unsupported](images/crossmark.png) |![unsupported](images/crossmark.png) |![unsupported](images/crossmark.png) |![unsupported](images/crossmark.png) |
+| Using mobile device management (MDM) |![unsupported](images/x_blk.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |
+| Using a provisioning package |![unsupported](images/x_blk.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |
+| Using a command-line tool |![unsupported](images/x_blk.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![unsupported](images/x_blk.png) |
+| Entering a product key manually |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![supported](images/check_grn.png) |![unsupported](images/x_blk.png) |
+| Purchasing a license from the Windows Store |![supported](images/check_grn.png) |![unsupported](images/x_blk.png) |![unsupported](images/x_blk.png) |![unsupported](images/x_blk.png) |![unsupported](images/x_blk.png) |![unsupported](images/x_blk.png) |
 
 **Note**<br>Each desktop edition in the table also has an N and KN edition. These editions have had media-related functionality removed. Devices with N or KN editions installed can be upgraded to corresponding N or KN editions using the same methods.
 
diff --git a/windows/deploy/windows-10-poc-mdt.md b/windows/deploy/windows-10-poc-mdt.md
new file mode 100644
index 0000000000..04cb2496e2
--- /dev/null
+++ b/windows/deploy/windows-10-poc-mdt.md
@@ -0,0 +1,28 @@
+---
+title: Placeholder (Windows 10)
+description: Deploy Windows 10 in a test lab using Microsoft Deployment Toolkit 
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: deploy
+author: greg-lindsay
+---
+
+# Deploy Windows 10 in a test lab using Microsoft Deployment Toolkit
+
+**Applies to**
+
+-   Windows 10
+
+## In this guide
+
+## Related Topics
+
+ 
+
+ 
+
+
+
+
+
diff --git a/windows/deploy/windows-10-poc-sccm.md b/windows/deploy/windows-10-poc-sccm.md
new file mode 100644
index 0000000000..3e43d7c402
--- /dev/null
+++ b/windows/deploy/windows-10-poc-sccm.md
@@ -0,0 +1,28 @@
+---
+title: Placeholder (Windows 10)
+description: Deploy Windows 10 in a test lab using System Center Configuration Manager 
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: deploy
+author: greg-lindsay
+---
+
+# Deploy Windows 10 in a test lab using System Center Configuration Manager
+
+**Applies to**
+
+-   Windows 10
+
+## In this guide
+
+## Related Topics
+
+ 
+
+ 
+
+
+
+
+
diff --git a/windows/deploy/windows-10-upgrade-paths.md b/windows/deploy/windows-10-upgrade-paths.md
new file mode 100644
index 0000000000..2503ea6a25
--- /dev/null
+++ b/windows/deploy/windows-10-upgrade-paths.md
@@ -0,0 +1,387 @@
+---
+title: Windows 10 upgrade paths (Windows 10)
+description: You can upgrade to Windows 10 from a previous version of Windows if the upgrade path is supported.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: mobile
+author: greg-lindsay
+---
+
+# Windows 10 upgrade paths
+**Applies to**
+
+-   Windows 10
+-   Windows 10 Mobile
+
+## Upgrade paths
+
+This topic provides a summary of available upgrade paths to Windows 10. You can upgrade to Windows 10 from Windows 7 or a later operating system. This includes upgrading from one release of Windows 10 to later release of Windows 10. Migrating from one edition of Windows 10 to a different edition of the same release is also supported. For more information about migrating to a different edition of Windows 10, see [Windows 10 edition upgrade](windows-10-edition-upgrades.md).
+
+>**Windows N/KN**: Windows "N" and "KN" editions follow the same upgrade paths shown below. If the pre-upgrade and post-upgrade editions are not the same type (e.g. Windows 8.1 Pro N to Windows 10 Pro), personal data will be kept but applications and settings will be removed during the upgrade process.  
+
+>**Free upgrade**: Some upgrade paths qualify for a free upgrade using Windows Update. For a list of upgrade paths that are available as part of the free upgrade offer, see [Free upgrade paths](#Free-upgrade-paths).
+
+✔ = Full upgrade is supported including personal data, settings, and applications.<BR>
+D = Edition downgrade; personal data is maintained, applications and settings are removed.
+
+<table border="1" cellpadding="3">
+    <tr>
+        <td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td>
+        <td></td>
+        <td>Windows 10 Home</td>
+        <td>Windows 10 Pro</td>
+        <td>Windows 10 Education</td>
+        <td>Windows 10 Enterprise</td>
+        <td>Windows 10 Mobile</td>
+        <td>Windows 10 Mobile Enterprise</td>
+    </tr>
+    <tr>
+        <td rowspan="7" nowrap="nowrap">Windows 7</td>
+    </tr>
+    <tr>
+        <td>Starter</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Home Basic</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Home Premium</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Professional</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Ultimate</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Enterprise</td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td rowspan="8" nowrap="nowrap">Windows 8</td>
+    </tr>
+    <tr>
+        <td>(Core)</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Professional</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Professional WMC</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Enterprise</td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Embedded Industry</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Windows RT</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Windows Phone 8</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td rowspan="10" nowrap="nowrap">Windows 8.1</td>
+    </tr>
+    <tr>
+        <td>(Core)</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Connected</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Professional</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Professional Student</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Professional WMC</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Enterprise</td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Embedded Industry</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Windows RT</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Windows Phone 8.1</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td></td>
+    </tr>
+    <tr>
+        <td rowspan="7" nowrap="nowrap">Windows 10</td>
+    </tr>
+    <tr>
+        <td>Home</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Professional</td>
+        <td>D</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Education</td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td>D</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Enterprise</td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td>✔</td>
+        <td></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td>Mobile</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td>✔</td>
+        <td>✔</td>
+    </tr>
+    <tr>
+        <td>Mobile Enterprise</td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td></td>
+        <td>D</td>
+        <td>✔</td>
+    </tr>
+</table>
+
+## Free upgrade paths
+
+Windows 10 is offered as a free upgrade for the first year after launch of Windows 10, with the following restrictions: 
+- The offer expires on July 29th, 2016.
+- The offer applies to devices connected to the Internet with Windows Update enabled.
+- Upgrading to Windows 10 Pro requires a computer running the Pro or Ultimate version of Windows 7/8/8.1.
+- Windows Phone 8.0 users must update to Windows 8.1 before upgrading to Windows 10 Mobile<sup>1</sup>. 
+- Editions that are excluded from the free upgrade offer include: Windows 7 Enterprise, Windows 8/8.1 Enterprise, and Windows RT/RT 8.1<sup>2</sup>. 
+
+><sup>1</sup>The availability of Windows 10 Mobile for Windows 8.1 devices will vary by device manufacturer, device model, country or region, mobile operator or service provider, hardware limitations, and other factors. For a list of eligible phones and important info about the upgrade and Windows 10 Mobile, see [Windows 10 specifications](http://windows.com/specsmobile).
+
+><sup>2</sup>Active Software Assurance customers in volume licensing have the benefit to upgrade to Windows 10 Enterprise outside of this offer. Windows 10 is not supported on devices running the RT versions of Windows 8.
+
+The following table summarizes the free upgrade paths to Windows 10. For a list of frequently asked questions about the free upgrade to Windows 10, see [Upgrade to Windows 10: FAQ](http://windows.microsoft.com/en-us/windows-10/upgrade-to-windows-10-faq).
+
+<table border="1" cellpadding="3">
+    <tr>
+        <td>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;</td>
+        <td>From</td>
+        <td>To</td>
+    </tr>
+    <tr>
+        <td BGCOLOR="#a0e4fa" colspan="3">Windows 7</td>
+    </tr>
+    <tr>
+        <td></td>
+        <td>Windows 7 Starter</td>
+        <td rowspan="3">Windows 10 Home</td>
+    </tr>
+    <tr>
+        <td>&nbsp;</td>
+        <td>Windows 7 Home Basic</td>
+    </tr>
+    <tr>
+        <td>&nbsp;</td>
+        <td>Windows 7 Home Premium</td>
+    </tr>
+    <tr>
+        <td></td>
+        <td>Windows 7 Professional</td>
+        <td rowspan="2">Windows 10 Pro</td>
+    </tr>
+    <tr>
+        <td>&nbsp;</td>
+        <td>Windows 7 Ultimate</td>
+    </tr>
+        <tr>
+	        <td BGCOLOR="#a0e4fa" colspan="3">Windows 8/8.1</td>
+	    </tr>
+	    <tr>
+	        <td></td>
+	        <td>Windows Phone 8.1</td>
+	        <td>Windows 10 Mobile</td>
+       </tr>
+	    <tr>
+	        <td></td>
+	        <td>Windows 8/8.1</td>
+	        <td>Windows 10 Home</td>
+       </tr>
+    <tr>
+        <td></td>
+        <td>Windows 8/8.1 Pro</td>
+        <td rowspan="2">Windows 10 Pro</td>
+    </tr>
+    <tr>
+        <td>&nbsp;</td>
+        <td>Windows 8/8.1 Pro for Students</td>
+    </tr>
+
+</table>
+
+## Related Topics
+
+[Windows 10 deployment scenarios](windows-10-deployment-scenarios.md)<BR>
+[Windows upgrade and migration considerations](windows-upgrade-and-migration-considerations.md)
+ 
+
+ 
+
+
+
+
+
diff --git a/windows/deploy/windows-upgrade-and-migration-considerations.md b/windows/deploy/windows-upgrade-and-migration-considerations.md
index 7763b0502d..fc4c69a980 100644
--- a/windows/deploy/windows-upgrade-and-migration-considerations.md
+++ b/windows/deploy/windows-upgrade-and-migration-considerations.md
@@ -8,13 +8,13 @@ ms.sitesec: library
 author: greg-lindsay
 ---
 
-# Windows Upgrade and Migration Considerations
+# Windows upgrade and migration considerations
 Files and application settings can be migrated to new hardware running the Windows® operating system, or they can be maintained during an operating system upgrade on the same computer. This topic summarizes the Microsoft® tools you can use to move files and settings between installations in addition to special considerations for performing an upgrade or migration.
 
-## Upgrade from a Previous Version of Windows
+## Upgrade from a previous version of Windows
 You can upgrade from an earlier version of Windows, which means you can install the new version of Windows and retain your applications, files, and settings as they were in your previous version of Windows. If you decide to perform a custom installation of Windows instead of an upgrade, your applications and settings will not be maintained. Your personal files, and all Windows files and directories, will be moved to a Windows.old folder. You can access your data in the Windows.old folder after Windows Setup is complete.
 
-## Migrate Files and Settings
+## Migrate files and settings
 Migration tools are available to transfer settings from one computer that is running Windows to another. These tools transfer only the program settings, not the programs themselves.
 
 For more information about application compatibility, see the [Application Compatibility Toolkit (ACT)](http://go.microsoft.com/fwlink/p/?LinkId=131349).
@@ -29,13 +29,13 @@ With Windows Easy Transfer, files and settings can be transferred using a netwo
 ### Migrate with the User State Migration Tool
 You can use USMT to automate migration during large deployments of the Windows operating system. USMT uses configurable migration rule (.xml) files to control exactly which user accounts, user files, operating system settings, and application settings are migrated and how they are migrated. You can use USMT for both *side-by-side* migrations, where one piece of hardware is being replaced, or *wipe-and-load* (or *refresh*) migrations, when only the operating system is being upgraded.
 
-## Upgrade and Migration Considerations
+## Upgrade and migration monsiderations
 Whether you are upgrading or migrating to a new version of Windows, you must be aware of the following issues and considerations:
 
-### Application Compatibility
+### Application compatibility
 For more information about application compatibility in Windows, see the [Application Compatibility Toolkit (ACT)](http://go.microsoft.com/fwlink/p/?LinkId=131349).
 
-### Multilingual Windows Image Upgrades
+### Multilingual Windows image upgrades
 When performing multilingual Windows upgrades, cross-language upgrades are not supported by USMT. If you are upgrading or migrating an operating system with multiple language packs installed, you can upgrade or migrate only to the system default user interface (UI) language. For example, if English is the default but you have a Spanish language pack installed, you can upgrade or migrate only to English.
 
 If you are using a single-language Windows image that matches the system default UI language of your multilingual operating system, the migration will work. However, all of the language packs will be removed, and you will have to reinstall them after the upgrade is completed.
@@ -43,7 +43,7 @@ If you are using a single-language Windows image that matches the system default
 ### Errorhandler.cmd
 When upgrading from an earlier version of Windows, if you intend to use Errorhandler.cmd, you must copy this file into the %WINDIR%\\Setup\\Scripts directory on the old installation. This makes sure that if there are errors during the down-level phase of Windows Setup, the commands in Errorhandler.cmd will run.
 
-### Data Drive ACL Migration
+### Data drive ACL migration
 During the configuration pass of Windows Setup, the root access control list (ACL) on drives formatted for NTFS that do not appear to have an operating system will be changed to the default Windows XP ACL format. The ACLs on these drives are changed to enable authenticated users to modify access on folders and files.
 
 Changing the ACLs may affect the performance of Windows Setup if the default Windows XP ACLs are applied to a partition with a large amount of data. Because of these performance concerns, you can change the following registry value to disable this feature:
@@ -57,7 +57,10 @@ Value: "DDACLSys_Disabled" = 1
 This feature is disabled if this registry key value exists and is configured to `1`.
 
 ## Related topics
-- [User State Migration Tool (USMT) Overview Topics](usmt-topics.md)
+[User State Migration Tool (USMT) Overview Topics](usmt-topics.md)<BR>
+[Windows 10 upgrade paths](windows-10-upgrade-paths.md)<BR>
+[Windows 10 edition upgrade](windows-10-edition-upgrades.md)
+
 
  
 
diff --git a/windows/keep-secure/TOC.md b/windows/keep-secure/TOC.md
index 58cc934bd4..e2590ac099 100644
--- a/windows/keep-secure/TOC.md
+++ b/windows/keep-secure/TOC.md
@@ -1,9 +1,6 @@
 # [Keep Windows 10 secure](index.md)
 ## [Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md)
 ## [Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md)
-## [Device Guard certification and compliance](device-guard-certification-and-compliance.md)
-### [Get apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md)
-### [Create a Device Guard code integrity policy based on a reference device](creating-a-device-guard-policy-for-signed-apps.md)
 ## [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md)
 ### [Implement Microsoft Passport in your organization](implement-microsoft-passport-in-your-organization.md)
 ### [Why a PIN is better than a password](why-a-pin-is-better-than-a-password.md)
@@ -14,6 +11,16 @@
 ## [Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md)
 ## [Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md)
 ## [Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md)
+## [Device Guard deployment guide](device-guard-deployment-guide.md)
+### [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+### [Requirements and deployment planning guidelines for Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md)
+### [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
+### [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+#### [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md)
+#### [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
+#### [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
+#### [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md)
+### [Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
 ## [Protect derived domain credentials with Credential Guard](credential-guard.md)
 ## [Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md)
 ### [Create an enterprise data protection (EDP) policy](overview-create-edp-policy.md)
@@ -23,11 +30,23 @@
 ##### [Create and deploy a VPN policy for enterprise data protection (EDP) using Microsoft Intune](create-vpn-and-edp-policy-using-intune.md)
 #### [Create and deploy an enterprise data protection (EDP) policy using System Center Configuration Manager](create-edp-policy-using-sccm.md)
 ### [General guidance and best practices for enterprise data protection (EDP)](guidance-and-best-practices-edp.md)
+#### [Mandatory tasks and settings required to turn on Windows Information Protection (WIP)](mandatory-settings-for-wip.md)
 #### [Enlightened apps for use with enterprise data protection (EDP)](enlightened-microsoft-apps-and-edp.md)
 #### [Testing scenarios for enterprise data protection (EDP)](testing-scenarios-for-edp.md)
 ## [Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md)
 ## [VPN profile options](vpn-profile-options.md)
+## [Windows security baselines](windows-security-baselines.md)
 ## [Security technologies](security-technologies.md)
+### [Access Control Overview](access-control.md)
+#### [Dynamic Access Control Overview](dynamic-access-control.md)
+#### [Security identifiers](security-identifiers.md)
+#### [Security Principals](security-principals.md)
+#### [Local Accounts](local-accounts.md)
+#### [Active Directory Accounts](active-directory-accounts.md)
+#### [Microsoft Accounts](microsoft-accounts.md)
+#### [Service Accounts](service-accounts.md)
+#### [Active Directory Security Groups](active-directory-security-groups.md)
+#### [Special Identities](special-identities.md)
 ### [AppLocker](applocker-overview.md)
 #### [Administer AppLocker](administer-applocker.md)
 ##### [Maintain AppLocker policies](maintain-applocker-policies.md)
@@ -668,12 +687,15 @@
 ### [Windows Defender Advanced Threat Protection](windows-defender-advanced-threat-protection.md)
 #### [Minimum requirements](minimum-requirements-windows-defender-advanced-threat-protection.md)
 #### [Data storage and privacy](data-storage-privacy-windows-defender-advanced-threat-protection.md)
+#### [Assign user access to the portal](assign-portal-access-windows-defender-advanced-threat-protection.md)
 #### [Onboard endpoints and set up access](onboard-configure-windows-defender-advanced-threat-protection.md)
-<!--##### [Service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md)-->
 ##### [Configure endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md)
+###### [Configure endpoints using Group Policy](configure-endpoints-gp-windows-defender-advanced-threat-protection.md)
+###### [Configure endpoints using System Security Configuration Manager](configure-endpoints-sccm-windows-defender-advanced-threat-protection.md)
+###### [Configure endpoints using Mobile Device Management tools](configure-endpoints-mdm-windows-defender-advanced-threat-protection.md)
+####### [Configure endpoints using Microsoft Intune](configure-endpoints-mdm-windows-defender-advanced-threat-protection.md#configure-endpoints-using-microsoft-intune)
+###### [Configure endpoints using a local script](configure-endpoints-script-windows-defender-advanced-threat-protection.md)
 ##### [Configure proxy and Internet settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md)
-##### [Additional configuration settings](additional-configuration-windows-defender-advanced-threat-protection.md)
-##### [Monitor onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md)
 ##### [Troubleshoot onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
 #### [Portal overview](portal-overview-windows-defender-advanced-threat-protection.md)
 #### [Use the Windows Defender ATP portal](use-windows-defender-advanced-threat-protection.md)
@@ -691,6 +713,7 @@
 ### [Windows Defender in Windows 10](windows-defender-in-windows-10.md)
 #### [Update and manage Windows Defender in Windows 10](get-started-with-windows-defender-for-windows-10.md)
 #### [Configure Windows Defender in Windows 10](configure-windows-defender-in-windows-10.md)
+#### [Use PowerShell cmdlets for Windows Defender](use-powershell-cmdlets-windows-defender-for-windows-10.md)
 #### [Troubleshoot Windows Defender in Windows 10](troubleshoot-windows-defender-in-windows-10.md)
 ### [Windows Firewall with Advanced Security](windows-firewall-with-advanced-security.md)
 #### [Isolating Windows Store Apps on Your Network](isolating-apps-on-your-network.md)
@@ -803,7 +826,6 @@
 ###### [Verify That Network Traffic Is Authenticated](verify-that-network-traffic-is-authenticated.md)
 ## [Enterprise security guides](windows-10-enterprise-security-guides.md)
 ### [Control the health of Windows 10-based devices](protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md)
-### [Device Guard deployment guide](device-guard-deployment-guide.md)
 ### [Microsoft Passport guide](microsoft-passport-guide.md)
 ### [Windows 10 Mobile security guide](windows-10-mobile-security-guide.md)
 ### [Windows 10 security overview](windows-10-security-guide.md)
diff --git a/windows/keep-secure/access-control.md b/windows/keep-secure/access-control.md
new file mode 100644
index 0000000000..969bd01684
--- /dev/null
+++ b/windows/keep-secure/access-control.md
@@ -0,0 +1,137 @@
+---
+title: Access Control Overview (Windows 10)
+description: Access Control Overview
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Access Control Overview
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This topic for the IT professional describes access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing.
+
+## <a href="" id="bkmk-over"></a>Feature description
+
+
+Computers that are running a supported version of Windows can control the use of system and network resources through the interrelated mechanisms of authentication and authorization. After a user is authenticated, the Windows operating system uses built-in authorization and access control technologies to implement the second phase of protecting resources: determining if an authenticated user has the correct permissions to access a resource.
+
+Shared resources are available to users and groups other than the resource’s owner, and they need to be protected from unauthorized use. In the access control model, users and groups (also referred to as security principals) are represented by unique security identifiers (SIDs). They are assigned rights and permissions that inform the operating system what each user and group can do. Each resource has an owner who grants permissions to security principals. During the access control check, these permissions are examined to determine which security principals can access the resource and how they can access it.
+
+Security principals perform actions (which include Read, Write, Modify, or Full control) on objects. Objects include files, folders, printers, registry keys, and Active Directory Domain Services (AD DS) objects. Shared resources use access control lists (ACLs) to assign permissions. This enables resource managers to enforce access control in the following ways:
+
+-   Deny access to unauthorized users and groups
+
+-   Set well-defined limits on the access that is provided to authorized users and groups
+
+Object owners generally grant permissions to security groups rather than to individual users. Users and computers that are added to existing groups assume the permissions of that group. If an object (such as a folder) can hold other objects (such as subfolders and files), it is called a container. In a hierarchy of objects, the relationship between a container and its content is expressed by referring to the container as the parent. An object in the container is referred to as the child, and the child inherits the access control settings of the parent. Object owners often define permissions for container objects, rather than individual child objects, to ease access control management.
+
+This content set contains:
+
+-   [Dynamic Access Control Overview](dynamic-access-control.md)
+
+-   [Security identifiers](security-identifiers.md)
+
+-   [Security Principals](security-principals.md)
+
+    -   [Local Accounts](local-accounts.md)
+
+    -   [Active Directory Accounts](active-directory-accounts.md)
+
+    -   [Microsoft Accounts](microsoft-accounts.md)
+
+    -   [Service Accounts](service-accounts.md)
+
+    -   [Active Directory Security Groups](active-directory-security-groups.md)
+
+## <a href="" id="bkmk-app"></a>Practical applications
+
+
+Administrators who use the supported version of Windows can refine the application and management of access control to objects and subjects to provide the following security:
+
+-   Protect a greater number and variety of network resources from misuse.
+
+-   Provision users to access resources in a manner that is consistent with organizational policies and the requirements of their jobs.
+
+-   Enable users to access resources from a variety of devices in numerous locations.
+
+-   Update users’ ability to access resources on a regular basis as an organization’s policies change or as users’ jobs change.
+
+-   Account for a growing number of use scenarios (such as access from remote locations or from a rapidly expanding variety of devices, such as tablet computers and mobile phones).
+
+-   Identify and resolve access issues when legitimate users are unable to access resources that they need to perform their jobs.
+
+## Permissions
+
+
+Permissions define the type of access that is granted to a user or group for an object or object property. For example, the Finance group can be granted Read and Write permissions for a file named Payroll.dat.
+
+By using the access control user interface, you can set NTFS permissions for objects such as files, Active Directory objects, registry objects, or system objects such as processes. Permissions can be granted to any user, group, or computer. It is a good practice to assign permissions to groups because it improves system performance when verifying access to an object.
+
+For any object, you can grant permissions to:
+
+-   Groups, users, and other objects with security identifiers in the domain.
+
+-   Groups and users in that domain and any trusted domains.
+
+-   Local groups and users on the computer where the object resides.
+
+The permissions attached to an object depend on the type of object. For example, the permissions that can be attached to a file are different from those that can be attached to a registry key. Some permissions, however, are common to most types of objects. These common permissions are:
+
+-   Read
+
+-   Modify
+
+-   Change owner
+
+-   Delete
+
+When you set permissions, you specify the level of access for groups and users. For example, you can let one user read the contents of a file, let another user make changes to the file, and prevent all other users from accessing the file. You can set similar permissions on printers so that certain users can configure the printer and other users can only print.
+
+When you need to change the permissions on a file, you can run Windows Explorer, right-click the file name, and click **Properties**. On the **Security** tab, you can change permissions on the file. For more information, see [Managing Permissions](http://technet.microsoft.com/library/cc770962.aspx).
+
+**Note**  
+Another kind of permissions, called share permissions, is set on the Sharing tab of a folder's **Properties** page or by using the Shared Folder Wizard. For more information see [Share and NTFS Permissions on a File Server](http://technet.microsoft.com/library/cc754178.aspx).
+
+ 
+
+### Ownership of objects
+
+An owner is assigned to an object when that object is created. By default, the owner is the creator of the object. No matter what permissions are set on an object, the owner of the object can always change the permissions. For more information, see [Manage Object Ownership](http://technet.microsoft.com/library/cc732983.aspx).
+
+### Inheritance of permissions
+
+Inheritance allows administrators to easily assign and manage permissions. This feature automatically causes objects within a container to inherit all the inheritable permissions of that container. For example, the files within a folder inherit the permissions of the folder. Only permissions marked to be inherited will be inherited.
+
+## User rights
+
+
+User rights grant specific privileges and sign-in rights to users and groups in your computing environment. Administrators can assign specific rights to group accounts or to individual user accounts. These rights authorize users to perform specific actions, such as signing in to a system interactively or backing up files and directories.
+
+User rights are different from permissions because user rights apply to user accounts, and permissions are associated with objects. Although user rights can apply to individual user accounts, user rights are best administered on a group account basis. There is no support in the access control user interface to grant user rights. However, user rights assignment can be administered through **Local Security Settings**.
+
+For more information about user rights, see [User Rights Assignment](user-rights-assignment.md).
+
+## Object auditing
+
+
+With administrator's rights, you can audit users' successful or failed access to objects. You can select which object access to audit by using the access control user interface, but first you must enable the audit policy by selecting **Audit object access** under **Local Policies** in **Local Security Settings**. You can then view these security-related events in the Security log in Event Viewer.
+
+For more information about auditing, see [Security Auditing Overview](security-auditing-overview.md).
+
+## See also
+
+-   For more information about access control and authorization, see [Access Control and Authorization Overview](https://technet.microsoft.com/en-us/library/jj134043(v=ws.11).aspx).
+
+
+ 
+
+ 
+
+
+
+
diff --git a/windows/keep-secure/active-directory-accounts.md b/windows/keep-secure/active-directory-accounts.md
new file mode 100644
index 0000000000..3b4ee0e979
--- /dev/null
+++ b/windows/keep-secure/active-directory-accounts.md
@@ -0,0 +1,851 @@
+---
+title: Active Directory Accounts (Windows 10)
+description: Active Directory Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Active Directory Accounts
+
+**Applies to**
+-   Windows Server 2016
+
+Windows Server operating systems are installed with default local accounts. In addition, you can create user accounts to meet the requirements of your organization. This reference topic for the IT professional describes the Windows Server default local accounts that are stored locally on the domain controller and are used in Active Directory.
+
+This reference topic does not describe default local user accounts for a member or standalone server or for a Windows client. For more information, see [Local Accounts](local-accounts.md).
+
+## About this topic
+
+
+This topic describes the following:
+
+-   [Default local accounts in Active Directory](#sec-ad-default-accounts)
+
+    -   [Administrator account](#sec-administrator)
+
+    -   [Guest account](#sec-guest)
+
+    -   [HelpAssistant account (installed with a Remote Assistance session)](#sec-helpassistant)
+
+    -   [KRBTGT account](#sec-krbtgt)
+
+-   [Settings for default local accounts in Active Directory](#sec-account-settings)
+
+-   [Manage default local accounts in Active Directory](#sec-manage-local-accounts)
+
+-   [Restrict and protect sensitive domain accounts](#sec-restrict-protect-accounts)
+
+    -   [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
+
+    -   [Create dedicated workstation hosts without Internet and email access](#task2-admin-workstations)
+
+    -   [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
+
+    -   [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
+
+-   [Secure and manage domain controllers](#sec-secure-manage-dcs)
+
+## <a href="" id="sec-ad-default-accounts"></a>Default local accounts in Active Directory
+
+
+Default local accounts are built-in accounts that are created automatically when a Windows Server domain controller is installed and the domain is created. These default local accounts have counterparts in Active Directory. These accounts also have domain-wide access and are completely separate from the default local user accounts for a member or standalone server.
+
+You can assign rights and permissions to default local accounts on a particular domain controller, and only on that domain controller. These accounts are local to the domain. After the default local accounts are installed, they are stored in the Users container in Active Directory Users and Computers. It is a best practice to keep the default local accounts in the User container and not attempt to move these accounts, for example, to a different organizational unit (OU).
+
+The default local accounts in the Users container include: Administrator, Guest, and KRBTGT. The HelpAssistant account is installed when a Remote Assistance session is established. The following sections describe the default local accounts and their use in Active Directory.
+
+Primarily, default local accounts do the following:
+
+-   Let the domain represent, identify, and authenticate the identity of the user that is assigned to the account by using unique credentials (user name and password). It is a best practice to assign each user to a single account to ensure maximum security. Multiple users are not allowed to share one account. A user account lets a user sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
+
+-   Authorize (grant or deny) access to resources. After a user’s credentials have been authenticated, the user is authorized to access the network and domain resources based on the user’s explicitly assigned rights on the resource.
+
+-   Audit the actions that are carried out on a user account.
+
+In Active Directory, default local accounts are used by administrators to manage domain and member servers directly and from dedicated administrative workstations. Active Directory accounts provide access to network resources. Active Directory User accounts and Computer accounts can represent a physical entity, such as a computer or person, or act as dedicated service accounts for some applications.
+
+Each default local account is automatically assigned to a security group that is preconfigured with the appropriate rights and permissions to perform specific tasks. Active Directory security groups collect user accounts, computer accounts, and other groups into manageable units. For more information, see [Active Directory Security Groups](active-directory-security-groups.md).
+
+On an Active Directory domain controller, each default local account is referred to as a security principal. A security principal is a directory object that is used to secure and manage Active Directory services that provide access to domain controller resources. A security principal includes objects such as user accounts, computer accounts, security groups, or the threads or processes that run in the security context of a user or computer account. For more information, see [Security Principals](security-principals.md).
+
+A security principal is represented by a unique security identifier (SID).The SIDs that are related to each of the default local accounts in Active Directory are described in the sections below.
+
+Some of the default local accounts are protected by a background process that periodically checks and applies a specific security descriptor. A security descriptor is a data structure that contains security information that is associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the default local accounts or groups is overwritten with the protected settings.
+
+This security descriptor is present on the AdminSDHolder object. If you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the AdminSDHolder object to ensure that it is applied consistently. Be careful when making these modifications, because you are also changing the default settings that are applied to all of your protected accounts.
+
+## <a href="" id="sec-administrator"></a>Administrator account
+
+
+The Administrator account is a default account that is used in all versions of the Windows operating system on every computer and device. The Administrator account is used by the system administrator for tasks that require administrative credentials. This account cannot be deleted or locked out, but the account can be renamed or disabled.
+
+The Administrator account gives the user complete access (Full Control permissions) of the files, directories, services, and other resources that are on that local server. The Administrator account can be used to create local users, and assign user rights and access control permissions. Administrator can also be used to take control of local resources at any time simply by changing the user rights and permissions. Although files and directories can be protected from the Administrator account temporarily, the Administrator account can take control of these resources at any time by changing the access permissions.
+
+**Account group membership**
+
+The Administrator account has membership in the default security groups as described in the Administrator account attributes table later in this topic.
+
+The security groups ensure that you can control administrator rights without having to change each Administrator account. In most instances, you do not have to change the basic settings for this account. However, you might have to change its advanced settings, such as membership in particular groups.
+
+**Security considerations**
+
+After installation of the server operating system, your first task is to set up the Administrator account properties securely. This includes setting up an especially long, strong password, and securing the Remote control and Remote Desktop Services profile settings.
+
+The Administrator account can also be disabled when it is not required. Renaming or disabling the Administrator account makes it more difficult for malicious users to try to gain access to the account. However, even when the Administrator account is disabled, it can still be used to gain access to a domain controller by using safe mode.
+
+On a domain controller, the Administrator account becomes the Domain Admin account. The Domain Admin account is used to sign in to the domain controller and this account requires a strong password. The Domain Admin account gives you access to domain resources.
+
+**Note**  
+When the domain controller is initially installed, you can sign in and use Server Manager to set up a local Administrator account, with the rights and permissions you want to assign. For example, you can use a local Administrator account to manage the operating system when you first install it. By using this approach, you can set up the operating system without getting locked out. Generally, you do not need to use the account after installation. You can only create local user accounts on the domain controller, before Active Directory Domain Services is installed, and not afterwards.
+
+ 
+
+When Active Directory is installed on the first domain controller in the domain, the Administrator account is created for Active Directory. The Administrator account is the most powerful account in the domain. It is given domain-wide access and administrative rights to administer the computer and the domain, and it has the most extensive rights and permissions over the domain. The person who installs Active Directory Domain Services on the computer creates the password for this account during the installation.
+
+**Administrator account attributes**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-500</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>N/A</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Administrators, Domain Admins, Enterprise Administrators, Domain Users. Note that the Primary Group ID of all user accounts is Domain Users.</p>
+<p>Group Policy Creator Owners, and Schema Admins in Active Directory</p>
+<p>Domain Users group</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-service administrators?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-guest"></a>Guest account
+
+
+The Guest account is a default local account has limited access to the computer and is disabled by default. The Guest account cannot be deleted or disabled, and the account name cannot be changed. By default, the Guest account password is left blank. A blank password allows the Guest account to be accessed without requiring the user to enter a password.
+
+The Guest account enables occasional or one-time users, who do not have an individual account on the computer, to sign in to the local server or domain with restricted rights and permissions. The Guest account can be enabled, and the password can be set up if needed, but only by a member of the Administrator group on the domain.
+
+**Account group membership**
+
+The Guest account has membership in the default security groups that are described in the following Guest account attributes table. By default, the Guest account is the only member of the default Guests group, which lets a user sign in to a server, and the Domain Guests global group, which lets a user sign in to a domain.
+
+A member of the Administrators group or Domain Admins group can set up a user with a Guest account on one or more computers.
+
+**Security considerations**
+
+Because the Guest account can provide anonymous access, it is a security risk. It also has a well-known SID. For this reason, it is a best practice to leave the Guest account disabled, unless its use is required and then only with restricted rights and permissions for a very limited period of time.
+
+When the Guest account is required, an Administrator on the domain controller is required to enable the Guest account. The Guest account can be enabled without requiring a password, or it can be enabled with a strong password. The Administrator also grants restricted rights and permissions for the Guest account. To help prevent unauthorized access:
+
+-   Do not grant the Guest account the [Shut down the system](shut-down-the-system.md) user right. When a computer is shutting down or starting up, it is possible that a Guest user or anyone with local access, such as a malicious user, could gain unauthorized access to the computer.
+
+-   Do not provide the Guest account with the ability to view the event logs. After the Guest account is enabled, it is a best practice to monitor this account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
+
+-   Do not use the Guest account when the server has external network access or access to other computers.
+
+If you decide to enable the Guest account, be sure to restrict its use and to change the password regularly. As with the Administrator account, you might want to rename the account as an added security precaution.
+
+In addition, an administrator is responsible for managing the Guest account. The administrator monitors the Guest account, disables the Guest account when it is no longer in use, and changes or removes the password as needed.
+
+For details about the Guest account attributes, see the following table.
+
+**Guest account attributes**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-501</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Guests, Domain Guests</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Can be moved out, but we do not recommend it.</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed with a Remote Assistance session)
+
+
+The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.
+
+HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the user’s invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
+
+**Security considerations**
+
+The SIDs that pertain to the default HelpAssistant account include:
+
+-   SID: S-1-5-&lt;domain&gt;-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note that, in Windows Server 2008, Remote Desktop Services are called Terminal Services.
+
+-   SID: S-1-5-&lt;domain&gt;-14, display name Remote Interactive Logon. This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
+
+For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
+
+For details about the HelpAssistant account attributes, see the following table.
+
+**HelpAssistant account attributes**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-13 (Terminal Server User), S-1-5-&lt;domain&gt;-14 (Remote Interactive Logon)</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Domain Guests</p>
+<p>Guests</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Can be moved out, but we do not recommend it.</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-krbtgt"></a>KRBTGT account
+
+
+The KRBTGT account is a local default account that acts as a service account for the Key Distribution Center (KDC) service. This account cannot be deleted, and the account name cannot be changed. The KRBTGT account cannot be enabled in Active Directory.
+
+KRBTGT is also the security principal name used by the KDC for a Windows Server domain, as specified by RFC 4120. The KRBTGT account is the entity for the KRBTGT security principal, and it is created automatically when a new domain is created.
+
+Windows Server Kerberos authentication is achieved by the use of a special Kerberos ticket-granting ticket (TGT) enciphered with a symmetric key. This key is derived from the password of the server or service to which access is requested. The TGT password of the KRBTGT account is known only by the Kerberos service. In order to request a session ticket, the TGT must be presented to the KDC. The TGT is issued to the Kerberos client from the KDC.
+
+### KRBTGT account maintenance considerations
+
+A strong password is assigned to the KRBTGT account automatically. Be sure that you change the password on a regular schedule. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. The password for a domain trust account is used to derive an inter-realm key for encrypting referral tickets.
+
+On occasion, the KRBTGT account password requires a reset, for example, when an attempt to change the password on the KRBTGT account fails. In order to resolve this issue, you reset the KRBTGT user account password twice by using Active Directory Users and Computers. You must reset the password twice because the KRBTGT account stores only two of the most recent passwords in the password history. By resetting the password twice, you effectively clear all passwords from the password history.
+
+Resetting the password requires you either to be a member of the Domain Admins group, or to have been delegated with the appropriate authority. In addition, you must be a member of the local Administrators group, or you must have been delegated the appropriate authority.
+
+After you reset the KRBTGT password, ensure that event ID 6 in the (Kerberos) Key-Distribution-Center event source is written to the System event log.
+
+### Security considerations
+
+It is also a best practice to reset the KRBTGT account password to ensure that a newly restored domain controller does not replicate with a compromised domain controller. In this case, in a large forest recovery that is spread across multiple locations, you cannot guarantee that all domain controllers are shut down, and if they are shut down, they cannot be rebooted again before all of the appropriate recovery steps have been undertaken. After you reset the KRBTGT account, another domain controller cannot replicate this account password by using an old password.
+
+An organization suspecting domain compromise of the KRBTGT account should consider the use of professional incident response services. The impact to restore the ownership of the account is domain-wide and labor intensive an should be undertaken as part of a larger recovery effort.
+
+The KRBTGT password is the key from which all trust in Kerberos chains up to. Resetting the KRBTGT password is similar to renewing the root CA certificate with a new key and immediately not trusting the old key, resulting in almost all subsequent Kerberos operations will be affected.
+
+For all account types (users, computers, and services)
+
+-   All the TGTs that are already issued and distributed will be invalid because the DCs will reject them. These tickets are encrypted with the KRBTGT so any DC can validate them. When the password changes, the tickets become invalid.
+
+-   All currently authenticated sessions that logged on users have established (based on their service tickets) to a resource (such as a file share, SharePoint site, or Exchange server) are good until the service ticket is required to re-authenticate.
+
+-   NTLM authenticated connections are not affected
+
+Because it is impossible to predict the specific errors that will occur for any given user in a production operating environment, you must assume all computers and users will be affected.
+
+**Important**  
+Rebooting a computer is the only reliable way to recover functionality as this will cause both the computer account and user accounts to log back in again. Logging in again will request new TGTs that are valid with the new KRBTGT, correcting any KRBTGT related operational issues on that computer.
+
+For information about how to help mitigate the risks associated with a potentially compromised KRBTGT account, see [KRBTGT Account Password Reset Scripts now available for customers](http://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/).
+
+### Read-only domain controllers and the KRBTGT account
+
+Windows Server 2008 introduced the read-only domain controller (RODC). The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different KRBTGT account and password than the KDC on a writable domain controller when it signs or encrypts ticket-granting ticket (TGT) requests. After an account is successfully authenticated, the RODC determines if a user's credentials or a computer's credentials can be replicated from the writable domain controller to the RODC by using the Password Replication Policy.
+
+After the credentials are cached on the RODC, the RODC can accept that user's sign-in requests until the credentials change. When a TGT is signed with the KRBTGT account of the RODC, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.
+
+### KRBTGT account attributes
+
+For details about the KRBTGT account attributes, see the following table.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-502</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>User</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Domain Users group. Note that the Primary Group ID of all user accounts is Domain Users.</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Can be moved out, but we do not recommend it.</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-account-settings"></a>Settings for default local accounts in Active Directory
+
+
+Each default local account in Active Directory has a number of account settings that you can use to configure password settings and security-specific information, as described in the following table.
+
+**Settings for default local accounts in Active Directory**
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Account settings</th>
+<th>Description</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>User must change password at next logon</p></td>
+<td><p>Forces a password change the next time that the user logs signs in to the network. Use this option when you want to ensure that the user is the only person to know his or her password.</p></td>
+</tr>
+<tr class="even">
+<td><p>User cannot change password</p></td>
+<td><p>Prevents the user from changing the password. Use this option when you want to maintain control over a user account, such as for a Guest or temporary account.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Password never expires</p></td>
+<td><p>Prevents a user password from expiring. It is a best practice to enable this option with service accounts and to use strong passwords.</p></td>
+</tr>
+<tr class="even">
+<td><p>Store passwords using reversible encryption</p></td>
+<td><p>Provides support for applications that use protocols requiring knowledge of the plaintext form of the user’s password for authentication purposes.</p>
+<p>This option is required when using Challenge Handshake Authentication Protocol (CHAP) in Internet Authentication Services (IAS), and when using digest authentication in Internet Information Services (IIS).</p></td>
+</tr>
+<tr class="odd">
+<td><p>Account is disabled</p></td>
+<td><p>Prevents the user from signing in with the selected account. As an administrator, you can use disabled accounts as templates for common user accounts.</p></td>
+</tr>
+<tr class="even">
+<td><p>Smart card is required for interactive logon</p></td>
+<td><p>Requires that a user has a smart card to sign on to the network interactively. The user must also have a smart card reader attached to their computer and a valid personal identification number (PIN) for the smart card.</p>
+<p>When this attribute is applied on the account, the effect is as follows:</p>
+<ul>
+<li><p>The attribute only restricts initial authentication for interactive logon and Remote Desktop logon. When interactive or Remote Desktop logon requires a subsequent network logon, such as with a domain credential, an NT Hash provided by the domain controller is used to complete the smartcard authentication process</p></li>
+<li><p>Each time the attribute is enabled on an account, the account’s current password hash value is replaced with a 128-bit random number. This invalidates the use of any previously configured passwords for the account. The value does not change after that unless a new password is set or the attribute is disabled and re-enabled.</p></li>
+<li><p>Accounts with this attribute cannot be used to start services or run scheduled tasks.</p></li>
+</ul></td>
+</tr>
+<tr class="odd">
+<td><p>Account is trusted for delegation</p></td>
+<td><p>Lets a service running under this account perform operations on behalf of other user accounts on the network. A service running under a user account (also known as a service account) that is trusted for delegation can impersonate a client to gain access to resources, either on the computer where the service is running or on other computers. For example, in a forest that is set to the Windows Server 2003 functional level, this setting is found on the <strong>Delegation</strong> tab. It is available only for accounts that have been assigned service principal names (SPNs), which are set by using the <strong>setspn</strong> command from Windows Support Tools. This setting is security-sensitive and should be assigned cautiously.</p></td>
+</tr>
+<tr class="even">
+<td><p>Account is sensitive and cannot be delegated</p></td>
+<td><p>Gives control over a user account, such as for a Guest account or a temporary account. This option can be used if this account cannot be assigned for delegation by another account.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Use DES encryption types for this account</p></td>
+<td><p>Provides support for the Data Encryption Standard (DES). DES supports multiple levels of encryption, including Microsoft Point-to-Point Encryption (MPPE) Standard (40-bit and 56-bit), MPPE standard (56-bit), MPPE Strong (128-bit), Internet Protocol security (IPSec) DES (40-bit), IPSec 56-bit DES, and IPSec Triple DES (3DES).</p>
+<div class="alert">
+<strong>Note</strong>  
+<p>DES is not enabled by default in Windows Server operating systems starting with Windows Server 2008 R2, nor in Windows client operating systems starting with Windows 7. For these operating systems, computers will not use DES-CBC-MD5 or DES-CBC-CRC cipher suites by default. If your environment requires DES, then this setting might affect compatibility with client computers or services and applications in your environment. For more information, see [Hunting down DES in order to securely deploy Kerberos](http://blogs.technet.com/b/askds/archive/2010/10/19/hunting-down-des-in-order-to-securely-deploy-kerberos.aspx).</p>
+</div>
+<div>
+ 
+</div></td>
+</tr>
+<tr class="even">
+<td><p>Do not require Kerberos preauthentication</p></td>
+<td><p>Provides support for alternate implementations of the Kerberos protocol. Because preauthentication provides additional security, use caution when enabling this option. Note that domain controllers running Windows 2000 or Windows Server 2003 can use other mechanisms to synchronize time.</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="sec-manage-local-accounts"></a>Manage default local accounts in Active Directory
+
+
+After the default local accounts are installed, these accounts reside in the Users container in Active Directory Users and Computers. Default local accounts can be created, disabled, reset, and deleted by using the Active Directory Users and Computers Microsoft Management Console (MMC) and by using command-line tools.
+
+You can use Active Directory Users and Computers to assign rights and permissions on a given local domain controller, and that domain controller only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a computer, such as backing up files and folders or shutting down a computer. In contrast, an access permission is a rule that is associated with an object, usually a file, folder, or printer, that regulates which users can have access to the object and in what manner.
+
+For more information about creating and managing local user accounts in Active Directory, see [Manage Local Users](http://technet.microsoft.com/library/cc731899.aspx).
+
+You can also use Active Directory Users and Computers on a domain controller to target remote computers that are not domain controllers on the network.
+
+You can obtain recommendations from Microsoft for domain controller configurations that you can distribute by using the Security Compliance Manager (SCM) tool. For more information, see [Microsoft Security Compliance Manager](http://technet.microsoft.com/library/cc677002.aspx).
+
+Some of the default local user accounts are protected by a background process that periodically checks and applies a specific security descriptor, which is a data structure that contains security information that is associated with a protected object. This security descriptor is present on the AdminSDHolder object.
+
+This means, when you want to modify the permissions on a service administrator group or on any of its member accounts, you are also required to modify the security descriptor on the AdminSDHolder object. This approach ensures that the permissions are applied consistently. Be careful when you make these modifications, because this action can also affect the default settings that are applied to all of your protected administrative accounts.
+
+## <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect sensitive domain accounts
+
+
+Restricting and protecting domain accounts in your domain environment requires you to adopt and implement the following best practices approach:
+
+-   Strictly limit membership to the Administrators, Domain Admins, and Enterprise Admins groups.
+
+-   Stringently control where and how domain accounts are used.
+
+Member accounts in the Administrators, Domain Admins, and Enterprise Admins groups in a domain or forest are high-value targets for malicious users. It is a best practice to strictly limit membership to these administrator groups to the smallest number of accounts in order to limit any exposure. Restricting membership in these groups reduces the possibility that an administrator might unintentionally misuse these credentials and create a vulnerability that malicious users can exploit.
+
+Moreover, it is a best practice to stringently control where and how sensitive domain accounts are used. Restrict the use of Domain Admins accounts and other administrator accounts to prevent them from being used to sign in to management systems and workstations that are secured at the same level as the managed systems. When administrator accounts are not restricted in this manner, each workstation from which a domain administrator signs in provides another location that malicious users can exploit.
+
+Implementing these best practices is separated into the following tasks:
+
+-   [Separate administrator accounts from user accounts](#task1-separate-admin-accounts)
+
+-   [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
+
+-   [Restrict administrator logon access to servers and workstations](#task3-restrict-admin-logon)
+
+-   [Disable the account delegation right for administrator accounts](#task4-disable-account-delegation)
+
+Note that, to provide for instances where integration challenges with the domain environment are expected, each task is described according to the requirements for a minimum, better, and ideal implementation. As with all significant changes to a production environment, ensure that you test these changes thoroughly before you implement and deploy them. Then stage the deployment in a manner that allows for a rollback of the change in case technical issues occur.
+
+### <a href="" id="task1-separate-admin-accounts"></a>Separate administrator accounts from user accounts
+
+Restrict Domain Admins accounts and other sensitive accounts to prevent them from being used to sign in to lower trust servers and workstations. Restrict and protect administrator accounts by segregating administrator accounts from standard user accounts, by separating administrative duties from other tasks, and by limiting the use of these accounts. Create dedicated accounts for administrative personnel who require administrator credentials to perform specific administrative tasks, and then create separate accounts for other standard user tasks, according to the following guidelines:
+
+-   **Privileged account**. Allocate administrator accounts to perform the following administrative duties only:
+
+    -   **Minimum**. Create separate accounts for domain administrators, enterprise administrators, or the equivalent with appropriate administrator rights in the domain or forest. Use accounts that have been granted sensitive administrator rights only to administer domain data and domain controllers.
+
+    -   **Better**. Create separate accounts for administrators that have reduced administrative rights, such as accounts for workstation administrators, and accounts with user rights over designated Active Directory organizational units (OUs).
+
+    -   **Ideal**. Create multiple, separate accounts for an administrator who has a variety of job responsibilities that require different trust levels. Set up each administrator account with significantly different user rights, such as for workstation administration, server administration and domain administration, to let the administrator sign in to given workstations, servers and domain controllers based strictly on his or her job responsibilities.
+
+-   **Standard user account**. Grant standard user rights for standard user tasks, such as email, web browsing, and using line-of-business (LOB) applications. These accounts should not be granted administrator rights.
+
+**Important**  
+Ensure that sensitive administrator accounts cannot access email or browse the Internet as described in the following section.
+
+ 
+
+### <a href="" id="task2-admin-workstations"></a>Create dedicated workstation hosts without Internet and email access
+
+Administrators need to manage job responsibilities that require sensitive administrator rights from a dedicated workstation because they do not have easy physical access to the servers. A workstation that is connected to the Internet and has email and web browsing access is regularly exposed to compromise through phishing, downloading, and other types of Internet attacks. Because of these threats, it is a best practice to set these administrators up by using workstations that are dedicated to administrative duties only, and not provide access to the Internet, including email and web browsing. For more information, see [Separate administrator accounts from user accounts](#task1-separate-admin-accounts).
+
+**Note**  
+If the administrators in your environment can sign in locally to managed servers and perform all tasks without elevated rights or domain rights from their workstation, you can skip this task.
+
+ 
+
+-   **Minimum**. Build dedicated administrative workstations and block Internet access on those workstations including web browsing and email. Use the following ways to block Internet access:
+
+    -   Configure authenticating boundary proxy services, if they are deployed, to disallow administrator accounts from accessing the Internet.
+
+    -   Configure boundary firewall or proxy services to disallow Internet access for the IP addresses that are assigned to dedicated administrative workstations.
+
+    -   Block outbound access to the boundary proxy servers in the Windows Firewall.
+
+    The instructions for meeting this minimum requirement are described in the following procedure.
+
+-   **Better**. Do not grant administrators membership in the local Administrator group on the computer in order to restrict the administrator from bypassing these protections.
+
+-   **Ideal**. Restrict workstations from having any network connectivity, except for the domain controllers and servers that the administrator accounts are used to manage. Alternately, use AppLocker application control policies to restrict all applications from running, except for the operating system and approved administrative tools and applications. For more information about AppLocker, see [AppLocker](applocker-overview.md).
+
+The following procedure describes how to block Internet access by creating a Group Policy Object (GPO) that configures an invalid proxy address on administrative workstations. These instructions apply only to computers running Internet Explorer and other Windows components that use these proxy settings.
+
+**Note**  
+In this procedure, the workstations are dedicated to domain administrators. By simply modifying the administrator accounts to grant permission to administrators to sign in locally, you can create additional OUs to manage administrators that have fewer administrative rights to use the instructions described in the following procedure.
+
+**To install administrative workstations in a domain and block Internet and email access (minimum)**
+
+1.  As a domain administrator on a domain controller, open Active Directory Users and Computers, and create a new OU for administrative workstations.
+
+2.  Create computer accounts for the new workstations.
+
+    > **Note**&nbsp;&nbsp;You might have to delegate permissions to join computers to the domain if the account that joins the workstations to the domain does not already have them. For more information, see [Delegation of Administration in Active Directory](http://social.technet.microsoft.com/wiki/contents/articles/20292.delegation-of-administration-in-active-directory.aspx).
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc1-sample1.gif)
+
+3.  Close Active Directory Users and Computers.
+
+4.  Start the **Group Policy Management** Console (GPMC).
+
+5.  Right-click the new OU, and &gt; **Create a GPO in this domain, and Link it here**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc1-sample2.png)
+
+6.  Name the GPO, and &gt; **OK**.
+
+7.  Expand the GPO, right-click the new GPO, and &gt; **Edit**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc1-sample3.png)
+
+8.  Configure which members of accounts can log on locally to these administrative workstations as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**.
+
+    2.  Double-click **Allow log on locally**, and then select the **Define these policy settings** check box.
+
+    3.  Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    4.  Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        **Important**  
+        These instructions assume that the workstation is to be dedicated to domain administrators.
+
+         
+
+    5.  Click **Add User or Group**, type **Administrators**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample4.png)
+
+9.  Configure the proxy configuration:
+
+    1.  Navigate to User Configuration\\Policies\\Windows Settings\\Internet Explorer, and &gt; **Connection**.
+
+    2.  Double-click **Proxy Settings**, select the **Enable proxy settings** check box, type **127.0.0.1** (the network Loopback IP address) as the proxy address, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample5.png)
+
+10. Configure the loopback processing mode to enable the user Group Policy proxy setting to apply to all users on the computer as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Administrative Templates\\System, and &gt; **Group Policy**.
+
+    2.  Double-click **User Group Policy loopback policy processing mode**, and &gt; **Enabled**.
+
+    3.  Select **Merge Mode**, and &gt; **OK**.
+
+11. Configure software updates as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Administrative Templates\\Windows Components, and then click **Windows Update**.
+
+    2.  Configure Windows Update settings as described in the following table.
+
+        <table>
+        <colgroup>
+        <col width="50%" />
+        <col width="50%" />
+        </colgroup>
+        <tbody>
+        <tr class="odd">
+        <td><p><strong>Windows Update Setting</strong></p></td>
+        <td><p><strong>Configuration</strong></p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Allow Automatic Updates immediate installation</p></td>
+        <td><p>Enabled</p></td>
+        </tr>
+        <tr class="odd">
+        <td><p>Configure Automatic Updates</p></td>
+        <td><p>Enabled<br>4 - Auto download and schedule the installation<br>0 - Every day 03:00</p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Enable Windows Update Power Management to automatically wake up the system to install scheduled updates</p></td>
+        <td><p>Enabled</p></td>
+        </tr>
+        <tr class="odd">
+        <td><p>Specify intranet Microsoft Update service location</p></td>
+        <td><p>Enabled http://&lt;WSUSServername&gt; http://&lt;WSUSServername&gt; Where &lt;WSUSServername&gt; is the DNS name or IP address of the Windows Server Update Services (WSUS) in the environment.</p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Automatic Updates detection frequency</p></td>
+        <td><p>6 hours</p></td>
+        </tr>
+        <tr class="odd">
+        <td><p>Re-prompt for restart with scheduled installations</p></td>
+        <td><p>1 minute</p></td>
+        </tr>
+        <tr class="even">
+        <td><p>Delay restart for scheduled installations</p></td>
+        <td><p>5 minutes</p></td>
+        </tr>
+        </tbody>
+        </table>
+
+        > **Note**&nbsp;&nbsp;This step assumes that Windows Server Update Services (WSUS) is installed and configured in the environment. You can skip this step if you use another tool to deploy software updates. Also, if the public Microsoft Windows Update service only is used on the Internet, then these administrative workstations no longer receive updates.
+
+12. Configure the inbound firewall to block all connections as follows:
+
+    1.  Right-click **Windows Firewall with Advanced Security LDAP://path**, and &gt; **Properties**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample6.png)
+
+    2.  On each profile, ensure that the firewall is enabled and that inbound connections are set to **Block all connections**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc1-sample7.png)
+
+    3.  Click **OK** to complete the configuration.
+
+13. Close the Group Policy Management Console.
+
+14. Install the Windows operating system on the workstations, give each workstation the same names as the computer accounts assigned to them, and then join them to the domain.
+
+### <a href="" id="task3-restrict-admin-logon"></a>Restrict administrator logon access to servers and workstations
+
+It is a best practice to restrict administrators from using sensitive administrator accounts to sign in to lower-trust servers and workstations. This restriction prevents administrators from inadvertently increasing the risk of credential theft by signing in to a lower-trust computer.
+
+**Important**  
+Ensure that you either have local access to the domain controller or that you have built at least one dedicated administrative workstation.
+
+ 
+
+Restrict logon access to lower-trust servers and workstations by using the following guidelines:
+
+-   **Minimum**. Restrict domain administrators from having logon access to servers and workstations. Before starting this procedure, identify all OUs in the domain that contain workstations and servers. Any computers in OUs that are not identified will not restrict administrators with sensitive accounts from signing-in to them.
+
+-   **Better**. Restrict domain administrators from non-domain controller servers and workstations.
+
+-   **Ideal**. Restrict server administrators from signing in to workstations, in addition to domain administrators.
+
+**Note**  
+For this procedure, do not link accounts to the OU that contain workstations for administrators that perform administration duties only, and do not provide Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations)
+
+ 
+
+**To restrict domain administrators from workstations (minimum)**
+
+1.  As a domain administrator, open the Group Policy Management Console (GPMC).
+
+2.  Open **Group Policy Management**, and expand *&lt;forest&gt;*\\Domains\\*&lt;domain&gt;*, and then expand to **Group Policy Objects**.
+
+3.  Right-click **Group Policy Objects**, and &gt; **New**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc2-sample1.png)
+
+4.  In the **New GPO** dialog box, name the GPO that restricts administrators from signing in to workstations, and &gt; **OK**.
+
+    ![Active Directory local accounts](images/adlocalaccounts-proc2-sample2.png)
+
+5.  Right-click **New GPO**, and &gt; **Edit**.
+
+6.  Configure user rights to deny logon locally for domain administrators.
+
+7.  Navigate to Computer Configuration\\Policies\\Windows Settings\\Local Policies, and then click **User Rights Assignment**, and perform the following:
+
+    1.  Double-click **Deny logon locally**, and &gt; **Define these policy settings**.
+
+    2.  Click **Add User or Group**, click **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    3.  Click **Add User or Group**, click **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample3.png)
+
+        **Note**  
+        You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
+
+         
+
+    4.  Click **OK** to complete the configuration.
+
+8.  Configure the user rights to deny batch and service logon rights for domain administrators as follows:
+
+    **Note**  
+    Completing this step might cause issues with administrator tasks that run as scheduled tasks or services with accounts in the Domain Admins group. The practice of using domain administrator accounts to run services and tasks on workstations creates a significant risk of credential theft attacks and therefore should be replaced with alternative means to run scheduled tasks or services.
+
+     
+
+    1.  Double-click **Deny logon as a batch job**, and &gt; **Define these policy settings**.
+
+    2.  Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    3.  Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample4.png)
+
+        **Note**  
+        You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
+
+         
+
+    4.  Double-click **Deny logon as a service**, and &gt; **Define these policy settings**.
+
+    5.  Click **Add User or Group** &gt; **Browse**, type **Enterprise Admins**, and &gt; **OK**.
+
+    6.  Click **Add User or Group** &gt; **Browse**, type **Domain Admins**, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample5.png)
+
+        **Note**  
+        You can optionally add any groups that contain server administrators who you want to restrict from signing in to workstations.
+
+         
+
+9.  Link the GPO to the first Workstations OU.
+
+    Navigate to the *&lt;forest&gt;*\\Domains\\*&lt;domain&gt;*\\OU Path, and then:
+
+    1.  Right-click the workstation OU, and then &gt; **Link an Existing GPO**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample6.png)
+
+    2.  Select the GPO that you just created, and &gt; **OK**.
+
+        ![Active Directory local accounts](images/adlocalaccounts-proc2-sample7.png)
+
+10. Test the functionality of enterprise applications on workstations in the first OU and resolve any issues caused by the new policy.
+
+11. Link all other OUs that contain workstations.
+
+    However, do not create a link to the Administrative Workstation OU if it is created for administrative workstations that are dedicated to administration duties only, and that are without Internet or email access. For more information, see [Create dedicated workstation hosts for administrators](#task2-admin-workstations).
+
+    **Important**  
+    If you later extend this solution, do not deny logon rights for the **Domain Users** group. The **Domain Users** group includes all user accounts in the domain, including Users, Domain Administrators, and Enterprise Administrators.
+
+     
+
+### <a href="" id="task4-disable-account-delegation"></a>Disable the account delegation right for sensitive administrator accounts
+
+Although user accounts are not marked for delegation by default, accounts in an Active Directory domain can be trusted for delegation. This means that a service or a computer that is trusted for delegation can impersonate an account that authenticates to them to access other resources across the network.
+
+For sensitive accounts, such as those belonging to members of the Administrators, Domain Admins, or Enterprise Admins groups in Active Directory, delegation can present a substantial risk of rights escalation. For example, if an account in the Domain Admins group is used to sign in to a compromised member server that is trusted for delegation, that server can request access to resources in the context of the Domain Admins account, and escalate the compromise of that member server to a domain compromise.
+
+It is a best practice to configure the user objects for all sensitive accounts in Active Directory by selecting the **Account is sensitive and cannot be delegated** check box under **Account options** to prevent these accounts from being delegated. For more information, see [Setting for default local accounts in Active Directory](#sec-account-settings).
+
+As with any configuration change, test this enabled setting fully to ensure that it performs correctly before you implement it.
+
+![Active Directory local accounts](images/adlocalaccounts-proc3-sample1.png)
+
+## <a href="" id="sec-secure-manage-dcs"></a>Secure and manage domain controllers
+
+
+It is a best practice to strictly enforce restrictions on the domain controllers in your environment. This ensures that the domain controllers:
+
+1.  Run only required software
+
+2.  Required software is regularly updated
+
+3.  Are configured with the appropriate security settings
+
+One aspect of securing and managing domain controllers is to ensure that the default local user accounts are fully protected. It is of primary importance to restrict and secure all sensitive domain accounts, as described in the preceding sections.
+
+Because domain controllers store credential password hashes of all accounts in the domain, they are high-value targets for malicious users. When domain controllers are not well managed and secured by using restrictions that are strictly enforced, they can be compromised by malicious users. For example, a malicious user could steal sensitive domain administrator credentials from one domain controller, and then use these credentials to attack the domain and forest.
+
+In addition, installed applications and management agents on domain controllers might provide a path for escalating rights that malicious users can use to compromise the management service or administrators of that service. The management tools and services, which your organization uses to manage domain controllers and their administrators, are equally important to the security of the domain controllers and the domain administrator accounts. Ensure that these services and administrators are fully secured with equal effort.
+
+## See also
+
+- [Security Principals](security-principals.md)
+
+- [Access Control Overview](access-control.md)
diff --git a/windows/keep-secure/active-directory-security-groups.md b/windows/keep-secure/active-directory-security-groups.md
new file mode 100644
index 0000000000..630308945a
--- /dev/null
+++ b/windows/keep-secure/active-directory-security-groups.md
@@ -0,0 +1,3591 @@
+---
+title: Active Directory Security Groups (Windows 10)
+description: Active Directory Security Groups
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Active Directory Security Groups
+
+**Applies to**
+-   Windows Server 2016
+
+This reference topic for the IT professional describes the default Active Directory security groups.
+
+## <a href="" id="w2k3tr-princ-how-eabp"></a>
+
+
+There are two forms of common security principals in Active Directory: user accounts and computer accounts. These accounts represent a physical entity (a person or a computer). User accounts can also be used as dedicated service accounts for some applications. Security groups are used to collect user accounts, computer accounts, and other groups into manageable units.
+
+In the Windows Server operating system, there are several built-in accounts and security groups that are preconfigured with the appropriate rights and permissions to perform specific tasks. For Active Directory, there are two types of administrative responsibilities:
+
+-   **Service administrators**   Responsible for maintaining and delivering Active Directory Domain Services (AD DS), including managing domain controllers and configuring the AD DS.
+
+-   **Data administrators**   Responsible for maintaining the data that is stored in AD DS and on domain member servers and workstations.
+
+## About Active Directory groups
+
+
+Groups are used to collect user accounts, computer accounts, and other groups into manageable units. Working with groups instead of with individual users helps simplify network maintenance and administration.
+
+There are two types of groups in Active Directory:
+
+-   **Distribution groups** Used to create email distribution lists.
+
+-   **Security groups** Used to assign permissions to shared resources.
+
+### Distribution groups
+
+Distribution groups can be used only with email applications (such as Exchange Server) to send email to collections of users. Distribution groups are not security enabled, which means that they cannot be listed in discretionary access control lists (DACLs).
+
+### Security groups
+
+Security groups can provide an efficient way to assign access to resources on your network. By using security groups, you can:
+
+-   Assign user rights to security groups in Active Directory.
+
+    User rights are assigned to a security group to determine what members of that group can do within the scope of a domain or forest. User rights are automatically assigned to some security groups when Active Directory is installed to help administrators define a person’s administrative role in the domain.
+
+    For example, a user who is added to the Backup Operators group in Active Directory has the ability to back up and restore files and directories that are located on each domain controller in the domain. This is possible because, by default, the user rights **Backup files and directories** and **Restore files and directories** are automatically assigned to the Backup Operators group. Therefore, members of this group inherit the user rights that are assigned to that group.
+
+    You can use Group Policy to assign user rights to security groups to delegate specific tasks. For more information about using Group Policy, see [User Rights Assignment](user-rights-assignment.md).
+
+-   Assign permissions to security groups for resources.
+
+    Permissions are different than user rights. Permissions are assigned to the security group for the shared resource. Permissions determine who can access the resource and the level of access, such as Full Control. Some permissions that are set on domain objects are automatically assigned to allow various levels of access to default security groups, such as the Account Operators group or the Domain Admins group.
+
+    Security groups are listed in DACLs that define permissions on resources and objects. When assigning permissions for resources (file shares, printers, and so on), administrators should assign those permissions to a security group rather than to individual users. The permissions are assigned once to the group, instead of several times to each individual user. Each account that is added to a group receives the rights that are assigned to that group in Active Directory, and the user receives the permissions that are defined for that group.
+
+Like distribution groups, security groups can be used as an email entity. Sending an email message to the group sends the message to all the members of the group.
+
+### <a href="" id="bkmk-groupscope"></a>Group scope
+
+Groups are characterized by a scope that identifies the extent to which the group is applied in the domain tree or forest. The scope of the group defines where the group can be granted permissions. The following three group scopes are defined by Active Directory:
+
+-   Universal
+
+-   Global
+
+-   Domain Local
+
+**Note**  
+In addition to these three scopes, the default groups in the **Builtin** container have a group scope of Builtin Local. This group scope and group type cannot be changed.
+
+ 
+
+The following table lists the three group scopes and more information about each scope for a security group.
+
+**Group scopes**
+
+<table>
+<colgroup>
+<col width="20%" />
+<col width="20%" />
+<col width="20%" />
+<col width="20%" />
+<col width="20%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Scope</th>
+<th>Possible Members</th>
+<th>Scope Conversion</th>
+<th>Can Grant Permissions</th>
+<th>Possible Member of</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Universal</p></td>
+<td><p>Accounts from any domain in the same forest</p>
+<p>Global groups from any domain in the same forest</p>
+<p>Other Universal groups from any domain in the same forest</p></td>
+<td><p>Can be converted to Domain Local scope</p>
+<p>Can be converted to Global scope if the group does not contain any other Universal groups</p></td>
+<td><p>On any domain in the same forest or trusting forests</p></td>
+<td><p>Other Universal groups in the same forest</p>
+<p>Domain Local groups in the same forest or trusting forests</p>
+<p>Local groups on computers in the same forest or trusting forests</p></td>
+</tr>
+<tr class="even">
+<td><p>Global</p></td>
+<td><p>Accounts from the same domain</p>
+<p>Other Global groups from the same domain</p></td>
+<td><p>Can be converted to Universal scope if the group is not a member of any other global group</p></td>
+<td><p>On any domain in the same forest, or trusting domains or forests</p></td>
+<td><p>Universal groups from any domain in the same forest</p>
+<p>Other Global groups from the same domain</p>
+<p>Domain Local groups from any domain in the same forest, or from any trusting domain</p></td>
+</tr>
+<tr class="odd">
+<td><p>Domain Local</p></td>
+<td><p>Accounts from any domain or any trusted domain</p>
+<p>Global groups from any domain or any trusted domain</p>
+<p>Universal groups from any domain in the same forest</p>
+<p>Other Domain Local groups from the same domain</p>
+<p>Accounts, Global groups, and Universal groups from other forests and from external domains</p></td>
+<td><p>Can be converted to Universal scope if the group does not contain any other Domain Local groups</p></td>
+<td><p>Within the same domain</p></td>
+<td><p>Other Domain Local groups from the same domain</p>
+<p>Local groups on computers in the same domain, excluding built-in groups that have well-known SIDs</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="special-identity-groups-"></a>Special identity groups
+
+Special identities are generally referred to as groups. Special identity groups do not have specific memberships that can be modified, but they can represent different users at different times, depending on the circumstances. Some of these groups include Creator Owner, Batch, and Authenticated User.
+
+For information about all the special identity groups, see [Special Identities](special-identities.md).
+
+## Default security groups
+
+
+Default groups, such as the Domain Admins group, are security groups that are created automatically when you create an Active Directory domain. You can use these predefined groups to help control access to shared resources and to delegate specific domain-wide administrative roles.
+
+Many default groups are automatically assigned a set of user rights that authorize members of the group to perform specific actions in a domain, such as logging on to a local system or backing up files and folders. For example, a member of the Backup Operators group has the right to perform backup operations for all domain controllers in the domain.
+
+When you add a user to a group, the user receives all the user rights that are assigned to the group and all the permissions that are assigned to the group for any shared resources.
+
+Default groups are located in the **Builtin** container and in the **Users** container in Active Directory Users and Computers. The **Builtin** container includes groups that are defined with the Domain Local scope. The **Users** includes contains groups that are defined with Global scope and groups that are defined with Domain Local scope. You can move groups that are located in these containers to other groups or organizational units (OU) within the domain, but you cannot move them to other domains.
+
+Some of the administrative groups that are listed in this topic and all members of these groups are protected by a background process that periodically checks for and applies a specific security descriptor. This descriptor is a data structure that contains security information associated with a protected object. This process ensures that any successful unauthorized attempt to modify the security descriptor on one of the administrative accounts or groups will be overwritten with the protected settings.
+
+The security descriptor is present on the **AdminSDHolder** object. This means that if you want to modify the permissions on one of the service administrator groups or on any of its member accounts, you must modify the security descriptor on the **AdminSDHolder** object so that it will be applied consistently. Be careful when you make these modifications because you are also changing the default settings that will be applied to all of your protected administrative accounts.
+
+### <a href="" id="bkmk-groupstable"></a>Active Directory default security groups by operating system version
+
+The following tables provide descriptions of the default groups that are located in the **Builtin** and **Users** containers in each operating system.
+
+<table>
+<colgroup>
+<col width="20%" />
+<col width="20%" />
+<col width="20%" />
+<col width="20%" />
+<col width="20%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Default Security Group</th>
+<th>Windows Server 2012 R2</th>
+<th>Windows Server 2012</th>
+<th>Windows Server 2008 R2</th>
+<th>Windows Server 2008</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>[Access Control Assistance Operators](#bkmk-acasstops)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="even">
+<td><p>[Account Operators](#bkmk-accountoperators)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Administrators](#bkmk-admins)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Allowed RODC Password Replication Group](#bkmk-allowedrodcpwdrepl)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Backup Operators](#bkmk-backupoperators)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Certificate Service DCOM Access](#bkmk-certificateservicedcomaccess)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Cert Publishers](#bkmk-certpublishers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Cloneable Domain Controllers](#bkmk-cloneabledomaincontrollers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>[Cryptographic Operators](#bkmk-cryptographicoperators)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Distributed COM Users](#bkmk-distributedcomusers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[DnsUpdateProxy](#bkmk-dnsupdateproxy)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[DnsAdmins](#bkmk-dnsadmins)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Domain Admins](#bkmk-domainadmins)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Domain Computers](#bkmk-domaincomputers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Domain Controllers](#bkmk-domaincontrollers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Domain Guests](#bkmk-domainguests)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Domain Users](#bkmk-domainusers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Enterprise Admins](#bkmk-entadmins)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Enterprise Read-only Domain Controllers](#bkmk-entrodc)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Event Log Readers](#bkmk-eventlogreaders)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Group Policy Creators Owners](#bkmk-gpcreatorsowners)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Guests](#bkmk-guests)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Hyper-V Administrators](#bkmk-hypervadministrators)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>[IIS_IUSRS](#bkmk-iis-iusrs)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Incoming Forest Trust Builders](#bkmk-inforesttrustbldrs)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Network Configuration Operators](#bkmk-networkcfgoperators)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Performance Log Users](#bkmk-perflogusers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Performance Monitor Users](#bkmk-perfmonitorusers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Pre–Windows 2000 Compatible Access](#bkmk-pre-ws2kcompataccess)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Print Operators](#bkmk-printoperators)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Protected Users](#bkmk-protectedusers)</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>[RAS and IAS Servers](#bkmk-rasandias)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[RDS Endpoint Servers](#bkmk-rdsendpointservers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>[RDS Management Servers](#bkmk-rdsmanagementservers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="even">
+<td><p>[RDS Remote Access Servers](#bkmk-rdsremoteaccessservers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>[Read-only Domain Controllers](#bkmk-rodc)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Remote Desktop Users](#bkmk-remotedesktopusers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Remote Management Users](#bkmk-remotemanagementusers)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+<tr class="even">
+<td><p>[Replicator](#bkmk-replicator)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Schema Admins](#bkmk-schemaadmins)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Server Operators](#bkmk-serveroperators)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Terminal Server License Servers](#bkmk-terminalserverlic)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[Users](#bkmk-users)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>[Windows Authorization Access Group](#bkmk-winauthaccess)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>[WinRMRemoteWMIUsers_](#bkmk-winrmremotewmiusers-)</p></td>
+<td><p>Yes</p></td>
+<td><p>Yes</p></td>
+<td><p></p></td>
+<td><p></p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-acasstops"></a>Access Control Assistance Operators
+
+Members of this group can remotely query authorization attributes and permissions for resources on the computer.
+
+The Access Control Assistance Operators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-579</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>BuiltIn Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=BuiltIn, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p>
+<p></p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-accountoperators"></a>Account Operators
+
+The Account Operators group grants limited account creation privileges to a user. Members of this group can create and modify most types of accounts, including those of users, local groups, and global groups, and members can log in locally to domain controllers.
+
+Members of the Account Operators group cannot manage the Administrator user account, the user accounts of administrators, or the [Administrators](#bkmk-admins), [Server Operators](#bkmk-serveroperators), [Account Operators](#bkmk-accountoperators), [Backup Operators](#bkmk-backupoperators), or [Print Operators](#bkmk-printoperators) groups. Members of this group cannot modify user rights.
+
+The Account Operators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+**Note**  
+By default, this built-in group has no members, and it can create and manage users and groups in the domain, including its own membership and that of the Server Operators group. This group is considered a service administrator group because it can modify Server Operators, which in turn can modify domain controller settings. As a best practice, leave the membership of this group empty, and do not use it for any delegated administration. This group cannot be renamed, deleted, or moved.
+
+ 
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-548</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>BuiltIn Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=BuiltIn, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>[Allow log on locally](allow-log-on-locally.md): SeInteractiveLogonRight</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-admins"></a>Administrators
+
+Members of the Administrators group have complete and unrestricted access to the computer, or if the computer is promoted to a domain controller, members have unrestricted access to the domain.
+
+The Administrators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+**Note**  
+The Administrators group has built-in capabilities that give its members full control over the system. This group cannot be renamed, deleted, or moved. This built-in group controls access to all the domain controllers in its domain, and it can change the membership of all administrative groups.
+
+Membership can be modified by members of the following groups: the default service Administrators, Domain Admins in the domain, or Enterprise Admins. This group has the special privilege to take ownership of any object in the directory or any resource on a domain controller. This account is considered a service administrator group because its members have full access to the domain controllers in the domain.
+
+ 
+
+This security group includes the following changes since Windows Server 2008:
+
+-   Default user rights changes: **Allow log on through Terminal Services** existed in Windows Server 2008, and it was replaced by [Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md).
+
+-   [Remove computer from docking station](remove-computer-from-docking-station.md) was removed in Windows Server 2012 R2.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-544</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>BuiltIn Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=BuiltIn, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Administrator, Domain Admins, Enterprise Admins</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>[Adjust memory quotas for a process](adjust-memory-quotas-for-a-process.md): SeIncreaseQuotaPrivilege</p>
+<p>[Access this computer from the network](access-this-computer-from-the-network.md): SeNetworkLogonRight</p>
+<p>[Allow log on locally](allow-log-on-locally.md): SeInteractiveLogonRight</p>
+<p>[Allow log on through Remote Desktop Services](allow-log-on-through-remote-desktop-services.md): SeRemoteInteractiveLogonRight</p>
+<p>[Back up files and directories](back-up-files-and-directories.md): SeBackupPrivilege</p>
+<p>[Bypass traverse checking](bypass-traverse-checking.md): SeChangeNotifyPrivilege</p>
+<p>[Change the system time](change-the-system-time.md): SeSystemTimePrivilege</p>
+<p>[Change the time zone](change-the-time-zone.md): SeTimeZonePrivilege</p>
+<p>[Create a pagefile](create-a-pagefile.md): SeCreatePagefilePrivilege</p>
+<p>[Create global objects](create-global-objects.md): SeCreateGlobalPrivilege</p>
+<p>[Create symbolic links](create-symbolic-links.md): SeCreateSymbolicLinkPrivilege</p>
+<p>[Debug programs](debug-programs.md): SeDebugPrivilege</p>
+<p>[Enable computer and user accounts to be trusted for delegation](enable-computer-and-user-accounts-to-be-trusted-for-delegation.md): SeEnableDelegationPrivilege</p>
+<p>[Force shutdown from a remote system](force-shutdown-from-a-remote-system.md): SeRemoteShutdownPrivilege</p>
+<p>[Impersonate a client after authentication](impersonate-a-client-after-authentication.md): SeImpersonatePrivilege</p>
+<p>[Increase scheduling priority](increase-scheduling-priority.md): SeIncreaseBasePriorityPrivilege</p>
+<p>[Load and unload device drivers](load-and-unload-device-drivers.md): SeLoadDriverPrivilege</p>
+<p>[Log on as a batch job](log-on-as-a-batch-job.md): SeBatchLogonRight</p>
+<p>[Manage auditing and security log](manage-auditing-and-security-log.md): SeSecurityPrivilege</p>
+<p>[Modify firmware environment values](modify-firmware-environment-values.md): SeSystemEnvironmentPrivilege</p>
+<p>[Perform volume maintenance tasks](perform-volume-maintenance-tasks.md): SeManageVolumePrivilege</p>
+<p>[Profile system performance](profile-system-performance.md): SeSystemProfilePrivilege</p>
+<p>[Profile single process](profile-single-process.md): SeProfileSingleProcessPrivilege</p>
+<p>[Remove computer from docking station](remove-computer-from-docking-station.md): SeUndockPrivilege</p>
+<p>[Restore files and directories](restore-files-and-directories.md): SeRestorePrivilege</p>
+<p>[Shut down the system](shut-down-the-system.md): SeShutdownPrivilege</p>
+<p>[Take ownership of files or other objects](take-ownership-of-files-or-other-objects.md): SeTakeOwnershipPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-allowedrodcpwdrepl"></a>Allowed RODC Password Replication Group
+
+The purpose of this security group is to manage a RODC password replication policy. This group has no members by default, and it results in the condition that new Read-only domain controllers do not cache user credentials. The [Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl) group contains a variety of high-privilege accounts and security groups. The Denied RODC Password Replication group supersedes the Allowed RODC Password Replication group.
+
+The Allowed RODC Password Replication group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-571</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-backupoperators"></a>Backup Operators
+
+Members of the Backup Operators group can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to and shut down the computer. This group cannot be renamed, deleted, or moved. By default, this built-in group has no members, and it can perform backup and restore operations on domain controllers. Its membership can be modified by the following groups: default service Administrators, Domain Admins in the domain, or Enterprise Admins. It cannot modify the membership of any administrative groups. While members of this group cannot change server settings or modify the configuration of the directory, they do have the permissions needed to replace files (including operating system files) on domain controllers. Because of this, members of this group are considered service administrators.
+
+The Backup Operators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-551</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=BuiltIn, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>[Allow log on locally](allow-log-on-locally.md): SeInteractiveLogonRight</p>
+<p>[Back up files and directories](back-up-files-and-directories.md): SeBackupPrivilege</p>
+<p>[Log on as a batch job](log-on-as-a-batch-job.md): SeBatchLogonRight</p>
+<p>[Restore files and directories](restore-files-and-directories.md): SeRestorePrivilege</p>
+<p>[Shut down the system](shut-down-the-system.md): SeShutdownPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-certificateservicedcomaccess"></a>Certificate Service DCOM Access
+
+Members of this group are allowed to connect to certification authorities in the enterprise.
+
+The Certificate Service DCOM Access group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-&lt;domain&gt;-574</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-certpublishers"></a>Cert Publishers
+
+Members of the Cert Publishers group are authorized to publish certificates for User objects in Active Directory.
+
+The Cert Publishers group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-517</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-cloneabledomaincontrollers"></a>Cloneable Domain Controllers
+
+Members of the Cloneable Domain Controllers group that are domain controllers may be cloned. In Windows Server 2012 R2 and Windows Server 2012, you can deploy domain controllers by copying an existing virtual domain controller. In a virtual environment, you no longer have to repeatedly deploy a server image that is prepared by using sysprep.exe, promote the server to a domain controller, and then complete additional configuration requirements for deploying each domain controller (including adding the virtual domain controller to this security group).
+
+For more information, see [Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100)](https://technet.microsoft.com/library/hh831734.aspx).
+
+This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-522</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-cryptographicoperators"></a>Cryptographic Operators
+
+Members of this group are authorized to perform cryptographic operations. This security group was added in Windows Vista Service Pack 1 (SP1) to configure Windows Firewall for IPsec in Common Criteria mode.
+
+The Cryptographic Operators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group was introduced in Windows Vista Service Pack 1, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-569</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-deniedrodcpwdrepl"></a>Denied RODC Password Replication Group
+
+Members of the Denied RODC Password Replication group cannot have their passwords replicated to any Read-only domain controller.
+
+The purpose of this security group is to manage a RODC password replication policy. This group contains a variety of high-privilege accounts and security groups. The Denied RODC Password Replication Group supersedes the [Allowed RODC Password Replication Group](#bkmk-allowedrodcpwdrepl).
+
+This security group includes the following changes since Windows Server 2008:
+
+-   Windows Server 2012 changed the default members to include [Cert Publishers](#bkmk-certpublishers).
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-572</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>[Cert Publishers](#bkmk-certpublishers)</p>
+<p>[Domain Admins](#bkmk-domainadmins)</p>
+<p>[Domain Controllers](#bkmk-domaincontrollers)</p>
+<p>[Enterprise Admins](#bkmk-entadmins)</p>
+<p>Group Policy Creator Owners</p>
+<p>krbtgt</p>
+<p>[Read-only Domain Controllers](#bkmk-rodc)</p>
+<p>[Schema Admins](#bkmk-schemaadmins)</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-distributedcomusers"></a>Distributed COM Users
+
+Members of the Distributed COM Users group are allowed to launch, activate, and use Distributed COM objects on the computer. Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. Distributed Component Object Model (DCOM) allows applications to be distributed across locations that make the most sense to you and to the application. This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+The Distributed COM Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-562</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-dnsupdateproxy"></a>DnsUpdateProxy
+
+Members of the DnsUpdateProxy group are DNS clients. They are permitted to perform dynamic updates on behalf of other clients (such as DHCP servers). A DNS server can develop stale resource records when a DHCP server is configured to dynamically register host (A) and pointer (PTR) resource records on behalf of DHCP clients by using dynamic update. Adding clients to this security group mitigates this scenario.
+
+However, to protect against unsecured records or to permit members of the DnsUpdateProxy group to register records in zones that allow only secured dynamic updates, you must create a dedicated user account and configure DHCP servers to perform DNS dynamic updates by using the credentials of this account (user name, password, and domain). Multiple DHCP servers can use the credentials of one dedicated user account.
+
+For information, see [DNS Record Ownership and the DnsUpdateProxy Group](http://technet.microsoft.com/library/dd334715.aspx).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-1103</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-dnsadmins"></a>DnsAdmins
+
+Members of DNSAdmins group have access to network DNS information. The default permissions are as follows: Allow: Read, Write, Create All Child objects, Delete Child objects, Special Permissions.
+
+For more information about security and DNS, see [DNSSEC in Windows Server 2012](https://technet.microsoft.com/library/dn593694(v=ws.11).aspx).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-1102</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-domainadmins"></a>Domain Admins
+
+Members of the Domain Admins security group are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. The Domain Admins group is the default owner of any object that is created in Active Directory for the domain by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.
+
+The Domain Admins group controls access to all domain controllers in a domain, and it can modify the membership of all administrative accounts in the domain. Membership can be modified by members of the service administrator groups in its domain (Administrators and Domain Admins), and by members of the Enterprise Admins group. This is considered a service administrator account because its members have full access to the domain controllers in a domain.
+
+The Domain Admins group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-512</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Administrator</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Administrators](#bkmk-admins)</p>
+<p>[Denied RODC Password ReplicationGroup](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>See [Administrators](#bkmk-admins)</p>
+<p>See [Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-domaincomputers"></a>Domain Computers
+
+This group can include all computers and servers that have joined the domain, excluding domain controllers. By default, any computer account that is created automatically becomes a member of this group.
+
+The Domain Computers group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-515</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>All computers joined to the domain, excluding domain controllers</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes (but not required)</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-domaincontrollers"></a>Domain Controllers
+
+The Domain Controllers group can include all domain controllers in the domain. New domain controllers are automatically added to this group.
+
+The Domain Controllers group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-516</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Computer accounts for all domain controllers of the domain</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-domainguests"></a>Domain Guests
+
+The Domain Guests group includes the domain’s built-in Guest account. When members of this group sign in as local guests on a domain-joined computer, a domain profile is created on the local computer.
+
+The Domain Guests group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-514</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Guest</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Guests](#bkmk-guests)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Can be moved out but it is not recommended</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>See [Guests](#bkmk-guests)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-domainusers"></a>Domain Users
+
+The Domain Users group includes all user accounts in a domain. When you create a user account in a domain, it is automatically added to this group.
+
+By default, any user account that is created in the domain automatically becomes a member of this group. This group can be used to represent all users in the domain. For example, if you want all domain users to have access to a printer, you can assign permissions for the printer to this group (or add the Domain Users group to a local group on the print server that has permissions for the printer).
+
+The Domain Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-513</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Administrator</p>
+<p>krbtgt</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Users](#bkmk-users)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>See [Users](#bkmk-users)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-entadmins"></a>Enterprise Admins
+
+The Enterprise Admins group exists only in the root domain of an Active Directory forest of domains. It is a Universal group if the domain is in native mode; it is a Global group if the domain is in mixed mode. Members of this group are authorized to make forest-wide changes in Active Directory, such as adding child domains.
+
+By default, the only member of the group is the Administrator account for the forest root domain. This group is automatically added to the Administrators group in every domain in the forest, and it provides complete access for configuring all domain controllers. Members in this group can modify the membership of all administrative groups. Membership can be modified only by the default service administrator groups in the root domain. This is considered a service administrator account.
+
+The Enterprise Admins group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;root domain&gt;-519</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Universal (if Domain is in Native-Mode) else Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Administrator</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Administrators](#bkmk-admins)</p>
+<p>[Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>See [Administrators](#bkmk-admins)</p>
+<p>See [Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-entrodc"></a>Enterprise Read-Only Domain Controllers
+
+Members of this group are Read-Only Domain Controllers in the enterprise. Except for account passwords, a Read-only domain controller holds all the Active Directory objects and attributes that a writable domain controller holds. However, changes cannot be made to the database that is stored on the Read-only domain controller. Changes must be made on a writable domain controller and then replicated to the Read-only domain controller.
+
+Read-only domain controllers address some of the issues that are commonly found in branch offices. These locations might not have a domain controller. Or, they might have a writable domain controller, but not the physical security, network bandwidth, or local expertise to support it.
+
+For more information, see [What Is an RODC?](https://technet.microsoft.com/library/cc771030.aspx).
+
+The Enterprise Read-Only Domain Controllers group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-498</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Universal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-eventlogreaders"></a>Event Log Readers
+
+Members of this group can read event logs from local computers. The group is created when the server is promoted to a domain controller.
+
+The Event Log Readers group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-573</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-gpcreatorsowners"></a>Group Policy Creators Owners
+
+This group is authorized to create, edit, or delete Group Policy Objects in the domain. By default, the only member of the group is Administrator.
+
+For information about other features you can use with this security group, see [Group Policy Overview](https://technet.microsoft.com/library/hh831791.aspx).
+
+The Group Policy Creators Owners group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;domain&gt;-520</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Administrator</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>See [Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-guests"></a>Guests
+
+Members of the Guests group have the same access as members of the Users group by default, except that the Guest account has further restrictions. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to sign in with limited privileges to a computer’s built-in Guest account.
+
+When a member of the Guests group signs out, the entire profile is deleted. This includes everything that is stored in the **%userprofile%** directory, including the user's registry hive information, custom desktop icons, and other user-specific settings. This implies that a guest must use a temporary profile to sign in to the system. This security group interacts with the Group Policy setting **Do not logon users with temporary profiles** when it is enabled. This setting is located under the following path:
+
+Computer Configuration\\Administrative Templates\\System\\User Profiles
+
+**Note**  
+A Guest account is a default member of the Guests security group. People who do not have an actual account in the domain can use the Guest account. A user whose account is disabled (but not deleted) can also use the Guest account.
+
+The Guest account does not require a password. You can set rights and permissions for the Guest account as in any user account. By default, the Guest account is a member of the built-in Guests group and the Domain Guests global group, which allows a user to sign in to a domain. The Guest account is disabled by default, and we recommend that it stay disabled.
+
+ 
+
+The Guests group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-546</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=BuiltIn, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Guest</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Domain Guests](#bkmk-domainguests)</p>
+<p>Guest</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-hypervadministrators"></a>Hyper-V Administrators
+
+Members of the Hyper-V Administrators group have complete and unrestricted access to all the features in Hyper-V. Adding members to this group helps reduce the number of members required in the Administrators group, and further separates access.
+
+**Note**  
+Prior to Windows Server 2012, access to features in Hyper-V was controlled in part by membership in the Administrators group.
+
+ 
+
+This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-578</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=BuiltIn, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-iis-iusrs"></a>IIS\_IUSRS
+
+IIS\_IUSRS is a built-in group that is used by Internet Information Services beginning with IIS 7.0. A built-in account and group are guaranteed by the operating system to always have a unique SID. IIS 7.0 replaces the IUSR\_MachineName account and the IIS\_WPG group with the IIS\_IUSRS group to ensure that the actual names that are used by the new account and group will never be localized. For example, regardless of the language of the Windows operating system that you install, the IIS account name will always be IUSR, and the group name will be IIS\_IUSRS.
+
+For more information, see [Understanding Built-In User and Group Accounts in IIS 7](http://www.iis.net/learn/get-started/planning-for-security/understanding-built-in-user-and-group-accounts-in-iis).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-568</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>BuiltIn Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=BuiltIn, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>IUSR</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-inforesttrustbldrs"></a>Incoming Forest Trust Builders
+
+Members of the Incoming Forest Trust Builders group can create incoming, one-way trusts to this forest. Active Directory provides security across multiple domains or forests through domain and forest trust relationships. Before authentication can occur across trusts, Windows must determine whether the domain being requested by a user, computer, or service has a trust relationship with the logon domain of the requesting account.
+
+To make this determination, the Windows security system computes a trust path between the domain controller for the server that receives the request and a domain controller in the domain of the requesting account. A secured channel extends to other Active Directory domains through interdomain trust relationships. This secured channel is used to obtain and verify security information, including security identifiers (SIDs) for users and groups.
+
+**Note**  
+This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+ 
+
+For more information, see [How Domain and Forest Trusts Work: Domain and Forest Trusts](http://technet.microsoft.com/library/f5c70774-25cd-4481-8b7a-3d65c86e69b1).
+
+The Incoming Forest Trust Builders group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+**Note**  
+This group cannot be renamed, deleted, or moved.
+
+ 
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-557</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>BuiltIn local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-networkcfgoperators"></a>Network Configuration Operators
+
+Members of the Network Configuration Operators group can have the following administrative privileges to manage configuration of networking features:
+
+-   Modify the Transmission Control Protocol/Internet Protocol (TCP/IP) properties for a local area network (LAN) connection, which includes the IP address, the subnet mask, the default gateway, and the name servers.
+
+-   Rename the LAN connections or remote access connections that are available to all the users.
+
+-   Enable or disable a LAN connection.
+
+-   Modify the properties of all of remote access connections of users.
+
+-   Delete all the remote access connections of users.
+
+-   Rename all the remote access connections of users.
+
+-   Issue **ipconfig**, **ipconfig /release**, or **ipconfig /renew** commands.
+
+-   Enter the PIN unblock key (PUK) for mobile broadband devices that support a SIM card.
+
+**Note**  
+This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+ 
+
+The Network Configuration Operators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+**Note**  
+This group cannot be renamed, deleted, or moved.
+
+ 
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-556</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>BuiltIn local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-perflogusers"></a>Performance Log Users
+
+Members of the Performance Log Users group can manage performance counters, logs, and alerts locally on the server and from remote clients without being a member of the Administrators group. Specifically, members of this security group:
+
+-   Can use all the features that are available to the Performance Monitor Users group.
+
+-   Can create and modify Data Collector Sets after the group is assigned the [Log on as a batch job](log-on-as-a-batch-job.md) user right.
+
+    **Warning**  
+    If you are a member of the Performance Log Users group, you must configure Data Collector Sets that you create to run under your credentials.
+
+     
+
+-   Cannot use the Windows Kernel Trace event provider in Data Collector Sets.
+
+For members of the Performance Log Users group to initiate data logging or modify Data Collector Sets, the group must first be assigned the [Log on as a batch job](log-on-as-a-batch-job.md) user right. To assign this user right, use the Local Security Policy snap-in in Microsoft Management Console.
+
+**Note**  
+This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+ 
+
+The Performance Log Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+**Note**  
+This account cannot be renamed, deleted, or moved.
+
+ 
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-559</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>[Log on as a batch job](log-on-as-a-batch-job.md): SeBatchLogonRight</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-perfmonitorusers"></a>Performance Monitor Users
+
+Members of this group can monitor performance counters on domain controllers in the domain, locally and from remote clients, without being a member of the Administrators or Performance Log Users groups. The Windows Performance Monitor is a Microsoft Management Console (MMC) snap-in that provides tools for analyzing system performance. From a single console, you can monitor application and hardware performance, customize what data you want to collect in logs, define thresholds for alerts and automatic actions, generate reports, and view past performance data in a variety of ways.
+
+Specifically, members of this security group:
+
+-   Can use all the features that are available to the Users group.
+
+-   Can view real-time performance data in Performance Monitor.
+
+    Can change the Performance Monitor display properties while viewing data.
+
+-   Cannot create or modify Data Collector Sets.
+
+    **Warning**  
+    You cannot configure a Data Collector Set to run as a member of the Performance Monitor Users group.
+
+     
+
+**Note**  
+This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO). This group cannot be renamed, deleted, or moved.
+
+ 
+
+The Performance Monitor Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-558</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-pre-ws2kcompataccess"></a>Pre–Windows 2000 Compatible Access
+
+Members of the Pre–Windows 2000 Compatible Access group have Read access for all users and groups in the domain. This group is provided for backward compatibility for computers running Windows NT 4.0 and earlier. By default, the special identity group, Everyone, is a member of this group. Add users to this group only if they are running Windows NT 4.0 or earlier.
+
+**Warning**  
+This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+ 
+
+The Pre–Windows 2000 Compatible Access group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-554</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>If you choose the Pre–Windows 2000 Compatible Permissions mode, Everyone and Anonymous are members, and if you choose the Windows 2000-only permissions mode, Authenticated Users are members.</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>[Access this computer from the network](access-this-computer-from-the-network.md): SeNetworkLogonRight</p>
+<p>[Bypass traverse checking](bypass-traverse-checking.md): SeChangeNotifyPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-printoperators"></a>Print Operators
+
+Members of this group can manage, create, share, and delete printers that are connected to domain controllers in the domain. They can also manage Active Directory printer objects in the domain. Members of this group can locally sign in to and shut down domain controllers in the domain.
+
+This group has no default members. Because members of this group can load and unload device drivers on all domain controllers in the domain, add users with caution. This group cannot be renamed, deleted, or moved.
+
+The Print Operators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008. However, in Windows Server 2008 R2, functionality was added to manage print administration. For more information, see [Assign Delegated Print Administrator and Printer Permission Settings in Windows Server 2012](https://technet.microsoft.com/library/jj190062(v=ws.11).aspx).
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-550</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>[Allow log on locally](allow-log-on-locally.md): SeInteractiveLogonRight</p>
+<p>[Load and unload device drivers](load-and-unload-device-drivers.md): SeLoadDriverPrivilege</p>
+<p>[Shut down the system](shut-down-the-system.md): SeShutdownPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-protectedusers"></a>Protected Users
+
+Members of the Protected Users group are afforded additional protection against the compromise of credentials during authentication processes.
+
+This security group is designed as part of a strategy to effectively protect and manage credentials within the enterprise. Members of this group automatically have non-configurable protection applied to their accounts. Membership in the Protected Users group is meant to be restrictive and proactively secure by default. The only method to modify the protection for an account is to remove the account from the security group.
+
+This domain-related, global group triggers non-configurable protection on devices and host computers running Windows Server 2012 R2 and Windows 8.1, and on domain controllers in domains with a primary domain controller running Windows Server 2012 R2. This greatly reduces the memory footprint of credentials when users sign in to computers on the network from a non-compromised computer.
+
+Depending on the account’s domain functional level, members of the Protected Users group are further protected due to behavior changes in the authentication methods that are supported in Windows.
+
+-   Members of the Protected Users group cannot authenticate by using the following Security Support Providers (SSPs): NTLM, Digest Authentication, or CredSSP. Passwords are not cached on a device running Windows 8.1, so the device fails to authenticate to a domain when the account is a member of the Protected User group.
+
+-   The Kerberos protocol will not use the weaker DES or RC4 encryption types in the preauthentication process. This means that the domain must be configured to support at least the AES cipher suite.
+
+-   The user’s account cannot be delegated with Kerberos constrained or unconstrained delegation. This means that former connections to other systems may fail if the user is a member of the Protected Users group.
+
+-   The default Kerberos ticket-granting tickets (TGTs) lifetime setting of four hours is configurable by using Authentication Policies and Silos, which can be accessed through the Active Directory Administrative Center. This means that when four hours has passed, the user must authenticate again.
+
+The Protected Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This group was introduced in Windows Server 2012 R2. For more information about how this group works, see [Protected Users Security Group](https://technet.microsoft.com/library/dn466518.aspx).
+
+The following table specifies the properties of the Protected Users group.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-525</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default user rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-rasandias"></a>RAS and IAS Servers
+
+Computers that are members of the RAS and IAS Servers group, when properly configured, are allowed to use remote access services. By default, this group has no members. Computers that are running the Routing and Remote Access service are added to the group automatically, such as IAS servers and Network Policy Servers. Members of this group have access to certain properties of User objects, such as Read Account Restrictions, Read Logon Information, and Read Remote Access Information.
+
+The RAS and IAS Servers group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-553</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-rdsendpointservers"></a>RDS Endpoint Servers
+
+Servers that are members in the RDS Endpoint Servers group can run virtual machines and host sessions where user RemoteApp programs and personal virtual desktops run. This group needs to be populated on servers running RD Connection Broker. Session Host servers and RD Virtualization Host servers used in the deployment need to be in this group.
+
+For information about Remote Desktop Services, see [Host desktops and apps in Remote Desktop Services](https://technet.microsoft.com/library/mt718499.aspx).
+
+This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-553</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-rdsmanagementservers"></a>RDS Management Servers
+
+Servers that are members in the RDS Management Servers group can be used to perform routine administrative actions on servers running Remote Desktop Services. This group needs to be populated on all servers in a Remote Desktop Services deployment. The servers running the RDS Central Management service must be included in this group.
+
+This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-577</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-rdsremoteaccessservers"></a>RDS Remote Access Servers
+
+Servers in the RDS Remote Access Servers group provide users with access to RemoteApp programs and personal virtual desktops. In Internet facing deployments, these servers are typically deployed in an edge network. This group needs to be populated on servers running RD Connection Broker. RD Gateway servers and RD Web Access servers that are used in the deployment need to be in this group.
+
+For more information, see [Host desktops and apps in Remote Desktop Services](https://technet.microsoft.com/library/mt718499.aspx).
+
+This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-575</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-remotedesktopusers"></a>Remote Desktop Users
+
+The Remote Desktop Users group on an RD Session Host server is used to grant users and groups permissions to remotely connect to an RD Session Host server. This group cannot be renamed, deleted, or moved. It appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+The Remote Desktop Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-555</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin Local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-rodc"></a>Read-Only Domain Controllers
+
+This group is comprised of the Read-only domain controllers in the domain. A Read-only domain controller makes it possible for organizations to easily deploy a domain controller in scenarios where physical security cannot be guaranteed, such as branch office locations, or in scenarios where local storage of all domain passwords is considered a primary threat, such as in an extranet or in an application-facing role.
+
+Because administration of a Read-only domain controller can be delegated to a domain user or security group, an Read-only domain controller is well suited for a site that should not have a user who is a member of the Domain Admins group. A Read-only domain controller encompasses the following functionality:
+
+-   Read-only AD DS database
+
+-   Unidirectional replication
+
+-   Credential caching
+
+-   Administrator role separation
+
+-   Read-only Domain Name System (DNS)
+
+For information about deploying a Read-only domain controller, see [Understanding Planning and Deployment for Read-Only Domain Controllers](https://technet.microsoft.com/library/cc754719(v=ws.10).aspx).
+
+This security group was introduced in Windows Server 2008, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-521</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>See [Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-remotemanagementusers"></a>Remote Management Users
+
+Members of the Remote Management Users group can access WMI resources over management protocols (such as WS-Management via the Windows Remote Management service). This applies only to WMI namespaces that grant access to the user.
+
+The Remote Management Users group is generally used to allow users to manage servers through the Server Manager console, whereas the [WinRMRemoteWMIUsers\_](#bkmk-winrmremotewmiusers-) group is allows remotely running Windows PowerShell commands.
+
+For more information, see [What's New in MI?](https://msdn.microsoft.com/library/jj819828(v=vs.85).aspx) and [About WMI](http://msdn.microsoft.com/library/aa384642.aspx).
+
+This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-580</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-replicator"></a>Replicator
+
+Computers that are members of the Replicator group support file replication in a domain. Windows Server operating systems use the File Replication service (FRS) to replicate system policies and logon scripts stored in the System Volume (SYSVOL). Each domain controller keeps a copy of SYSVOL for network clients to access. FRS can also replicate data for the Distributed File System (DFS), synchronizing the content of each member in a replica set as defined by DFS. FRS can copy and maintain shared files and folders on multiple servers simultaneously. When changes occur, content is synchronized immediately within sites and by a schedule between sites.
+
+**Important**  
+In Windows Server 2008 R2, FRS cannot be used for replicating DFS folders or custom (non-SYSVOL) data. A Windows Server 2008 R2 domain controller can still use FRS to replicate the contents of a SYSVOL shared resource in a domain that uses FRS for replicating the SYSVOL shared resource between domain controllers.
+
+However, Windows Server 2008 R2 servers cannot use FRS to replicate the contents of any replica set apart from the SYSVOL shared resource. The DFS Replication service is a replacement for FRS, and it can be used to replicate the contents of a SYSVOL shared resource, DFS folders, and other custom (non-SYSVOL) data. You should migrate all non-SYSVOL FRS replica sets to DFS Replication. For more information, see:
+
+- [File Replication Service (FRS) Is Deprecated in Windows Server 2008 R2 (Windows)](http://msdn.microsoft.com/library/windows/desktop/ff384840.aspx)
+- [DFS Namespaces and DFS Replication Overview](https://technet.microsoft.com/library/jj127250(v=ws.11).aspx)
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-552</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-schemaadmins"></a>Schema Admins
+
+Members of the Schema Admins group can modify the Active Directory schema. This group exists only in the root domain of an Active Directory forest of domains. It is a Universal group if the domain is in native mode; it is a Global group if the domain is in mixed mode.
+
+The group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain. This group has full administrative access to the schema.
+
+The membership of this group can be modified by any of the service administrator groups in the root domain. This is considered a service administrator account because its members can modify the schema, which governs the structure and content of the entire directory.
+
+For more information, see [What Is the Active Directory Schema?: Active Directory](http://technet.microsoft.com/library/cc784826.aspx).
+
+The Schema Admins group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-&lt;root domain&gt;-518</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Universal (if Domain is in Native-Mode) else Global</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Administrator</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>[Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>See [Denied RODC Password Replication Group](#bkmk-deniedrodcpwdrepl)</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-serveroperators"></a>Server Operators
+
+Members in the Server Operators group can administer domain servers. This group exists only on domain controllers. By default, the group has no members. Memebers of the Server Operators group can sign in to a server interactively, create and delete network shared resources, start and stop services, back up and restore files, format the hard disk drive of the computer, and shut down the computer. This group cannot be renamed, deleted, or moved.
+
+By default, this built-in group has no members, and it has access to server configuration options on domain controllers. Its membership is controlled by the service administrator groups, Administrators and Domain Admins, in the domain, and the Enterprise Admins group. Members in this group cannot change any administrative group memberships. This is considered a service administrator account because its members have physical access to domain controllers, they can perform maintenance tasks (such as backup and restore), and they have the ability to change binaries that are installed on the domain controllers. Note the default user rights in the following table.
+
+The Server Operators group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-549</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>[Allow log on locally](allow-log-on-locally.md): SeInteractiveLogonRight</p>
+<p>[Back up files and directories](back-up-files-and-directories.md): SeBackupPrivilege</p>
+<p>[Change the system time](change-the-system-time.md): SeSystemTimePrivilege</p>
+<p>[Change the time zone](change-the-time-zone.md): SeTimeZonePrivilege</p>
+<p>[Force shutdown from a remote system](force-shutdown-from-a-remote-system.md): SeRemoteShutdownPrivilege</p>
+<p>[Restore files and directories](restore-files-and-directories.md): Restore files and directories SeRestorePrivilege</p>
+<p>[Shut down the system](shut-down-the-system.md): SeShutdownPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-terminalserverlic"></a>Terminal Server License Servers
+
+Members of the Terminal Server License Servers group can update user accounts in Active Directory with information about license issuance. This is used to track and report TS Per User CAL usage. A TS Per User CAL gives one user the right to access a Terminal Server from an unlimited number of client computers or devices. This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+For more information about this security group, see [Terminal Services License Server Security Group Configuration](http://technet.microsoft.com/library/cc775331.aspx).
+
+The Terminal Server License Servers group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+**Note**  
+This group cannot be renamed, deleted, or moved.
+
+ 
+
+This security group only applies to Windows Server 2003 and Windows Server 2008 because Terminal Services was replaced by Remote Desktop Services in Windows Server 2008 R2.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-561</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="odd">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-users"></a>Users
+
+Members of the Users group are prevented from making accidental or intentional system-wide changes, and they can run most applications. After the initial installation of the operating system, the only member is the Authenticated Users group. When a computer joins a domain, the Domain Users group is added to the Users group on the computer.
+
+Users can perform tasks such as running applications, using local and network printers, shutting down the computer, and locking the computer. Users can install applications that only they are allowed to use if the installation program of the application supports per-user installation. This group cannot be renamed, deleted, or moved.
+
+The Users group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+This security group includes the following changes since Windows Server 2008:
+
+-   In Windows Server 2008 R2, INTERACTIVE was added to the default members list.
+
+-   In Windows Server 2012, the default **Member Of** list changed from Domain Users to none.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-545</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Authenticated Users</p>
+<p>[Domain Users](#bkmk-domainusers)</p>
+<p>INTERACTIVE</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>Domain Users (this membership is due to the fact that the Primary Group ID of all user accounts is Domain Users.)</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-winauthaccess"></a>Windows Authorization Access Group
+
+Members of this group have access to the computed token GroupsGlobalAndUniversal attribute on User objects. Some applications have features that read the token-groups-global-and-universal (TGGAU) attribute on user account objects or on computer account objects in Active Directory Domain Services. Some Win32 functions make it easier to read the TGGAU attribute. Applications that read this attribute or that call an API (referred to as a function) that reads this attribute do not succeed if the calling security context does not have access to the attribute. This group appears as a SID until the domain controller is made the primary domain controller and it holds the operations master role (also known as flexible single master operations or FSMO).
+
+The Windows Authorization Access group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+**Note**  
+This group cannot be renamed, deleted, or moved.
+
+ 
+
+This security group has not changed since Windows Server 2008.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-32-560</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Builtin local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Builtin, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>Enterprise Domain Controllers</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Cannot be moved</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default user rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+### <a href="" id="bkmk-winrmremotewmiusers-"></a>WinRMRemoteWMIUsers\_
+
+In Windows 8 and in Windows Server 2012, a **Share** tab was added to the Advanced Security Settings user interface. This tab displays the security properties of a remote file share. To view this information, you must have the following permissions and memberships, as appropriate for the version of Windows Server that the file server is running.
+
+The WinRMRemoteWMIUsers\_ group applies to versions of the Windows Server operating system listed in the [Active Directory Default Security Groups table](#bkmk-groupstable).
+
+-   If the file share is hosted on a server that is running a supported version of the operating system:
+
+    -   You must be a member of the WinRMRemoteWMIUsers\_\_ group or the BUILTIN\\Administrators group.
+
+    -   You must have Read permissions to the file share.
+
+-   If the file share is hosted on a server that is running a version of Windows Server that is earlier than Windows Server 2012:
+
+    -   You must be a member of the BUILTIN\\Administrators group.
+
+    -   You must have Read permissions to the file share.
+
+In Windows Server 2012, the Access Denied Assistance functionality adds the Authenticated Users group to the local WinRMRemoteWMIUsers\_\_ group. Therefore, when the Access Denied Assistance functionality is enabled, all authenticated users who have Read permissions to the file share can view the file share permissions.
+
+**Note**  
+The WinRMRemoteWMIUsers\_ group allows running Windows PowerShell commands remotely whereas the [Remote Management Users](#bkmk-remotemanagementusers) group is generally used to allow users to manage servers by using the Server Manager console.
+
+ 
+
+This security group was introduced in Windows Server 2012, and it has not changed in subsequent versions.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-21-&lt;domain&gt;-1000</p></td>
+</tr>
+<tr class="even">
+<td><p>Type</p></td>
+<td><p>Domain local</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default container</p></td>
+<td><p>CN=Users, DC=&lt;domain&gt;, DC=</p></td>
+</tr>
+<tr class="even">
+<td><p>Default members</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default member of</p></td>
+<td><p>None</p></td>
+</tr>
+<tr class="even">
+<td><p>Protected by ADMINSDHOLDER?</p></td>
+<td><p>No</p></td>
+</tr>
+<tr class="odd">
+<td><p>Safe to move out of default container?</p></td>
+<td><p>Yes</p></td>
+</tr>
+<tr class="even">
+<td><p>Safe to delegate management of this group to non-Service admins?</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+## See also
+
+- [Security Principals](security-principals.md)
+
+- [Special Identities](special-identities.md)
+
+- [Access Control Overview](access-control.md)
diff --git a/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md b/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md
index eb028e5f03..56525c8a4e 100644
--- a/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md
+++ b/windows/keep-secure/add-apps-to-protected-list-using-custom-uri.md
@@ -1,6 +1,6 @@
 ---
-title: Add multiple apps to your enterprise data protection (EDP) Protected Apps list (Windows 10)
-description: Add multiple apps to your enterprise data protection (EDP) Protected Apps list at the same time, by using the Microsoft Intune Custom URI functionality and the AppLocker.
+title: Add apps to your enterprise data protection (EDP) policy by using Microsoft Intune and custom URI functionality (Windows 10)
+description: Add apps to your enterprise data protection (EDP) allowed app list, by using the Microsoft Intune custom URI functionality and AppLocker.
 ms.assetid: b50db35d-a2a9-4b78-a95d-a1b066e66880
 keywords: EDP, Enterprise Data Protection, protected apps, protected app list
 ms.prod: w10
@@ -10,7 +10,7 @@ ms.sitesec: library
 author: eross-msft
 ---
 
-# Add multiple apps to your enterprise data protection (EDP) Protected Apps list
+# Add apps to your enterprise data protection (EDP) policy by using the Microsoft Intune custom URI functionality
 **Applies to:**
 
 -   Windows 10 Insider Preview
@@ -18,34 +18,35 @@ author: eross-msft
 
 <span style="color:#ED1C24;">[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
 
-Add multiple apps to your enterprise data protection (EDP) **Protected Apps** list at the same time, by using the Microsoft Intune Custom URI functionality and AppLocker. For more info about how to create a custom URI using Intune, see [Windows 10 custom policy settings in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=691330).
+You can add apps to your enterprise data protection (EDP) protected app list using the Microsoft Intune custom URI functionality and AppLocker. For more info about how to create a custom URI using Intune, [Windows 10 custom policy settings in Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkID=691330).
 
-**Important**  
+>**Important**  
 Results can be unpredictable if you configure your policy using both the UI and the Custom URI method together. We recommend using a single method for each policy.
 
-If you only want to add one app at a time, you can follow the instructions in the [Create an enterprise data protection (EDP) policy using Microsoft Intune](create-edp-policy-using-intune.md) topic.
-
-**To add Universal Windows Platform (UWP) apps**
-
+## Add Store apps
 1.  Go to the AppLocker UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**.
 
-2.  Double-click **Application Control Policies**, double-click **AppLocker**, right-click **Packaged app Rules**, and then click **Automatically Generate Rules**.<p>
-The **Automatically Generate Packaged app Rules** wizard opens, letting you create EDP-protected app polices for all of the installed apps on the device or for packaged apps within a specific folder.
+2. In the left pane, expand **Application Control Policies**, expand **AppLocker**, right-click **Packaged app Rules**, and then click **Automatically Generate Rules**.
 
-3.  In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box.<p>
-You want to keep this value because your EDP policy needs to apply to the device being managed, not a single user or group of users.
+    The **Automatically Generate Packaged app Rules** wizard opens, letting you create EDP-protected app polices for all of the installed apps on the device or for packaged apps within a specific folder.
 
-4.  Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**.<p>
-This name should be easily recognizable, such as *EDP_UniversalApps_Rules*.
+3.  In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box.
 
-5.  In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules.<p>
-**Important**<br>You can also use **Path** rules instead of the **File hash** if you have concerns about unsigned files potentially changing the hash value if they're updated in the future.<p>
-**Note**<br>We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.<p>If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule.<p>Finally, there's **Path** rules. **Path** rules are easier to set up and maintain, but can let apps bypass enterprise data protection (EDP) by simply renaming and moving an unallowed file to match one of the apps on the **Protected App** list. For example, if your **Path** rule says to allow `%PROGRAMFILES%/NOTEPAD.EXE`, it becomes possible to rename DisallowedApp.exe to Notepad.exe, move it into the specified path above, and have it suddenly be allowed.
+    You want to keep this value because your EDP policy needs to apply to the device being managed, not a single user or group of users.
+
+4.  Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**.
+
+    This name should be easily recognizable, such as *EDP_StoreApps_Rules*.
+
+5.  In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules.
+
+    >**Note**<br>We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.<p>If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule.
 
 6.  In the **Review Rules** screen, look over your rules to make sure they’re right, and then click **Create** to add them to your collection of rules.
 
-7.  In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules.<p>
-**Important**<br>Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy.
+7.  In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules.
+
+    >**Important**<br>Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy.
 
 8.  Open the Intune administration console, and go to the **Policy** node, click **Add Policy** from the **Tasks** area, go to **Windows**, click the **Custom Configuration (Windows 10 Desktop and Mobile and later)** policy, click **Create and Deploy a Custom Policy**, and then click **Create Policy**.
 
@@ -59,36 +60,42 @@ This name should be easily recognizable, such as *EDP_UniversalApps_Rules*.
 
 13. Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad.
 
-14. Copy the text that has a **Type** of Appx, within the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
+14. Copy the text that has a **Type** of `Appx`, within the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
 
     ```
-    <RuleCollection Type="Appx" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
+        <RuleCollection Type="Appx" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
     ```
 
 15. Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**.<p>
 After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your enterprise data protection (EDP) policy](deploy-edp-policy-using-intune.md) topic.
 
-**To add Classic Windows applications**
+## Add Desktop apps
+1.  Open the Local Security Policy snap-in (SecPol.msc).
 
-1.  Go to the AppLocker UI by opening a command line window and running secpol.msc. The local security policy MMC snap-in opens showing the **Security Settings**.
+2.  In the left pane, expand **Application Control Policies**, expand **AppLocker**, right-click **Executable Rules**, and then click **Automatically Generate Rules**.
 
-2.  Double-click **Application Control Policies**, double-click **AppLocker**, right-click **Executable Rules**, and then click **Automatically Generate Rules**.<p>
-The **Automatically Generate Executable Rules** wizard opens, letting you create EDP-protected app polices by analyzing the files within a specific folder.
+    The **Automatically Generate Executable Rules** wizard opens, letting you create EDP-protected app polices by analyzing the files within a specific folder.
 
-3.  In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box.<p>
-You want to keep this value because your EDP policy needs to apply to the device being managed, not a single user or group of users.
+3.  In the **Folder and Permissions** screen, keep the default value of **Everyone** in the **User or security group that the rules will apply to** box.
 
-4.  Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**.<p>
-This name should be easily recognizable, such as *EDP_ClassicApps_Rules*.
+    You want to keep this value because your EDP policy needs to apply to the device being managed, not a single user or group of users.
 
-5.  In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules.<p>
-**Important**<br>You can also use **Path** rules instead of the **File hash** if you have concerns about unsigned files potentially changing the hash value if they're updated in the future.<p>
-**Note**<br>We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.<p>If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule.<p>Finally, there's **Path** rules. **Path** rules are easier to set up and maintain, but can let apps bypass enterprise data protection (EDP) by simply renaming and moving an unallowed file to match one of the apps on the **Protected App** list. For example, if your **Path** rule says to allow `%PROGRAMFILES%/NOTEPAD.EXE`, it becomes possible to rename DisallowedApp.exe to Notepad.exe, move it into the specified path above, and have it suddenly be allowed.
+4.  Type the name you’ll use to tag the rules into the **Name to identify this set of rules** box, and then click **Next**.
+
+    This name should be easily recognizable, such as *EDP_DesktopApps_Rules*.
+
+5.  In the **Rules Preferences** screen, keep the default settings, and then click **Next** to start generating the rules.
+
+    >**Important**<br>You can also use **Path** rules instead of the **File hash** if you have concerns about unsigned files potentially changing the hash value if they're updated in the future.
+    
+    <p>
+    >**Note**<br>We recommend that you use **Publisher** rules because they only work with apps you've specifically defined and they can be configured to not require updating simply because a new version came out.<p>If you can't use **Publisher** rules, we then recommend that you use **File hash** rules. **File hash** rules are a secure alternative that can be used on unsigned code. The primary disadvantage to **File hash** is that every time a binary changes (such as, through servicing updates or upgrades), you'll need to create a new rule.<p>Finally, there's **Path** rules. **Path** rules are easier to set up and maintain, but can let apps bypass enterprise data protection (EDP) by simply renaming and moving an unallowed file to match one of the apps on the **Protected App** list. For example, if your **Path** rule says to allow `%PROGRAMFILES%/NOTEPAD.EXE`, it becomes possible to rename DisallowedApp.exe to Notepad.exe, move it into the specified path above, and have it suddenly be allowed.
 
 6.  In the **Review Rules** screen, look over your rules to make sure they’re right, and then click **Create** to add them to your collection of rules.
 
-7.  In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules.<p>
-**Important**<br>Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy.
+7.  In the left pane, right-click **AppLocker**, click **Export Policies**, go to where you want to save the XML file and type a file name, click **Save**, and then clear your AppLocker rules.
+
+    >**Important**<br>Be aware that what you're saving are the actual AppLocker rules using your local policy. You don't want to apply these rules to your employee devices, you just want to use them to create and export the XML content. You must delete the AppLocker rules before you apply your policy.
 
 8.  Open the Intune administration console, and go to the **Policy** node, click **Add Policy** from the **Tasks** area, go to **Windows**, click the **Custom Configuration (Windows 10 Desktop and Mobile and later)** policy, click **Create and Deploy a Custom Policy**, and then click **Create Policy**.
 
@@ -102,14 +109,15 @@ This name should be easily recognizable, such as *EDP_ClassicApps_Rules*.
 
 13. Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad.
 
-14. Copy the text that has a **Type** of EXE, within in the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
+14. Copy the text that has a **Type** of `EXE`, within in the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
 
     ``` 
-    <RuleCollection Type="Exe" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
+        <RuleCollection Type="Exe" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
     ```
 
-15. Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**.<p>
-After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your enterprise data protection (EDP) policy](deploy-edp-policy-using-intune.md) topic.
+15. Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**.
+
+    After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your enterprise data protection (EDP) policy](deploy-edp-policy-using-intune.md) topic.
 
 ##Related topics
 - [Create an enterprise data protection (EDP) policy using Microsoft Intune](create-edp-policy-using-intune.md)
diff --git a/windows/keep-secure/additional-configuration-windows-defender-advanced-threat-protection.md b/windows/keep-secure/additional-configuration-windows-defender-advanced-threat-protection.md
deleted file mode 100644
index 93d466aa32..0000000000
--- a/windows/keep-secure/additional-configuration-windows-defender-advanced-threat-protection.md
+++ /dev/null
@@ -1,47 +0,0 @@
----
-title: Additional Windows Defender ATP configuration settings
-description: Use the Group Policy Console to configure settings that enable sample sharing from your endpoints. These settings are used in the deep analysis feature.
-keywords: configuration settings, Windows Defender ATP configuration settings, Windows Defender Advanced Threat Protection configuration settings, group policy Management Editor, computer configuration, policies, administrative templates,
-search.product: eADQiWindows 10XVcnh
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.pagetype: security
-ms.sitesec: library
-author: mjcaparas
----
-
-# Additional Windows Defender ATP configuration settings
-
-**Applies to**
-
-- Windows 10 Insider Preview Build 14332 or later
-- Windows Defender Advanced Threat Protection (Windows Defender ATP)
-
-<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
-
-You can use Group Policy (GP) to configure settings, such as settings for the sample sharing used in the deep analysis feature.
-
-## Configure sample collection settings with Group Policy
-1.  On your GP management machine, copy the following files from the
-    configuration package:
-
-    a.  Copy _AtpConfiguration.admx_ into _C:\\Windows\\PolicyDefinitions_
-
-    b.  Copy _AtpConfiguration.adml_ into _C:\\Windows\\PolicyDefinitions\\en-US_
-
-2.  Open the [Group Policy Management Console](https://technet.microsoft.com/en-us/library/cc731212.aspx), right-click the GPO you want to configure and click **Edit**.
-
-3.  In the **Group Policy Management Editor**, go to **Computer configuration**.
-
-4.  Click **Policies**, then **Administrative templates**.
-
-5.  Click **Windows components** and then **Windows Advanced Threat Protection**.
-
-6.  Choose to enable or disable sample sharing from your endpoints.
-
-## Related topics
-<!--- [Windows Defender ATP service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md)-->
-- [Configure Windows Defender ATP endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md)
-- [Configure endpoint proxy and Internet connectivity settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md)
-- [Monitor the Windows Defender ATP onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md)
-- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
diff --git a/windows/keep-secure/assign-portal-access-windows-defender-advanced-threat-protection.md b/windows/keep-secure/assign-portal-access-windows-defender-advanced-threat-protection.md
new file mode 100644
index 0000000000..eb788e5359
--- /dev/null
+++ b/windows/keep-secure/assign-portal-access-windows-defender-advanced-threat-protection.md
@@ -0,0 +1,39 @@
+---
+title: Assign user access to the Windows Defender Advanced Threat Protection portal
+description: Assign read and write or read only access to the Windows Defender Advanced Threat Protection portal. 
+keywords: assign user roles, assign read and write access, assign read only access, user, user roles, roles
+search.product: eADQiWindows 10XVcnh
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: mjcaparas
+---
+
+# Assign user access to the Windows Defender ATP portal
+
+**Applies to:**
+
+- Windows 10 Insider Preview Build 14332 or later
+- Azure Active Directory
+- Office 365
+- Windows Defender Advanced Threat Protection (Windows Defender ATP)
+
+<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
+
+Windows Defender ATP users and access permissions are managed in Azure Active Directory (AAD). User can be assigned one of the following levels of permissions:
+- Full access (Read and Write)
+- Read only access
+
+**Full access** <br>
+Users with full access can log in, view all system information as well as resolve alerts, submit files for deep analysis, and download the onboarding package.
+Assigning full access rights requires adding the users to the “Security Administrator” or “Global Administrator” AAD built-in roles.
+
+**Read only access** <br>
+Users with read only access can log in, view all alerts, and related information. 
+They will not be able to change alert states, submit files for deep analysis or perform any state changing operations.
+Assigning read only access rights requires adding the users to the “Security Reader” AAD built-in role.
+
+Your administrator can assign roles using the Office 365 portal, or in the Azure classic portal, or by using the AAD module for Windows PowerShell. 
+For more information, see [Assigning admin roles in Office 365](https://support.office.com/en-us/article/Assigning-admin-roles-in-Office-365-eac4d046-1afd-4f1a-85fc-8219c79e1504?ui=en-US&rs=en-US&ad=US) and [Assigning administrator roles in Azure Active Directory](https://azure.microsoft.com/en-us/documentation/articles/active-directory-assign-admin-roles/).
+
diff --git a/windows/keep-secure/change-history-for-keep-windows-10-secure.md b/windows/keep-secure/change-history-for-keep-windows-10-secure.md
index c415733140..4b25f1edc5 100644
--- a/windows/keep-secure/change-history-for-keep-windows-10-secure.md
+++ b/windows/keep-secure/change-history-for-keep-windows-10-secure.md
@@ -12,6 +12,17 @@ author: brianlic-msft
 # Change history for Keep Windows 10 secure
 This topic lists new and updated topics in the [Keep Windows 10 secure](index.md) documentation for [Windows 10 and Windows 10 Mobile](../index.md).
 
+## July 2016
+
+|New or changed topic | Description |
+|----------------------|-------------|
+|[Mandatory settings for Windows Information Protection (WIP)](mandatory-settings-for-wip.md) |New |
+|[Create an enterprise data protection (EDP) policy using Microsoft Intune](create-edp-policy-using-intune.md) |New |
+|[Create an enterprise data protection (EDP) policy using System Center Configuration Manager](create-edp-policy-using-sccm.md) |New |
+|[Windows Defender Advanced Threat Protection](windows-defender-advanced-threat-protection.md) (multiple topics) | Updated |
+|[Device Guard deployment guide](device-guard-deployment-guide.md) (multiple topics) | Updated |
+
+
 ## June 2016
 
 |New or changed topic | Description |
@@ -19,6 +30,7 @@ This topic lists new and updated topics in the [Keep Windows 10 secure](index.md
 |[Create an enterprise data protection (EDP) policy using Microsoft Intune](create-edp-policy-using-intune.md) |Added an update about needing to reconfigure your enterprise data protection app rules after delivery of the June service update. |
 | [Windows Firewall with Advanced Security](windows-firewall-with-advanced-security.md) (multiple topics) | New |
 | [Advanced security audit policy settings](advanced-security-audit-policy-settings.md) (mutiple topics) | New security monitoring reference topics |
+| [Windows security baselines](windows-security-baselines.md) | New |
 
 ## May 2016
 
diff --git a/windows/keep-secure/configure-endpoints-gp-windows-defender-advanced-threat-protection.md b/windows/keep-secure/configure-endpoints-gp-windows-defender-advanced-threat-protection.md
new file mode 100644
index 0000000000..d8db5694c4
--- /dev/null
+++ b/windows/keep-secure/configure-endpoints-gp-windows-defender-advanced-threat-protection.md
@@ -0,0 +1,111 @@
+---
+title: Configure Windows Defender ATP endpoints using Group Policy
+description: Use Group Policy to deploy the configuration package on endpoints so that they are onboarded to the service.
+keywords: configure endpoints using group policy, endpoint management, configure Windows ATP endpoints, configure Windows Defender Advanced Threat Protection endpoints, group policy
+search.product: eADQiWindows 10XVcnh
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: mjcaparas
+---
+
+# Configure endpoints using Group Policy
+
+**Applies to:**
+
+- Windows 10 Insider Preview Build 14332 or later
+- Windows Defender Advanced Threat Protection (Windows Defender ATP)
+
+<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
+
+> **Note**&nbsp;&nbsp;To use Group Policy (GP) updates to deploy the package, you must be on Windows Server 2008 R2 or later. 
+
+### Onboard endpoints
+1.  Open the GP configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+
+    a.  Click **Endpoint Management** on the **Navigation pane**.
+
+    b.  Select **Group Policy**, click **Download package** and save the .zip file.
+
+2.	Extract the contents of the .zip file to a shared, read-only location that can be accessed by the endpoints. You should have a folder called *OptionalParamsPolicy* and the file *WindowsDefenderATPOnboardingScript.cmd*.
+
+3. Open the [Group Policy Management Console](https://technet.microsoft.com/en-us/library/cc731212.aspx) (GPMC), right-click the Group Policy Object (GPO) you want to configure and click **Edit**.
+
+4. In the **Group Policy Management Editor**, go to **Computer configuration**, then **Preferences**, and then **Control panel settings**.
+
+5. Right-click **Scheduled tasks**, point to **New**, and then click **Immediate task**.
+
+6. In the  **Task** window that opens, go to the **General** tab. Choose the local SYSTEM user account under **Security options**.
+
+7. Select **Run whether user is logged on or not** and check the **Run with highest privileges** check box.
+
+8. Go to the **Actions** tab and click **New...** Ensure that **Start a program** is selected in the **Action** field. Enter the file name and location of the shared *WindowsDefenderATPOnboardingScript.cmd* file.
+
+9. Click **OK** and close any open GPMC windows.
+
+## Additional Windows Defender ATP configuration settings
+
+You can use Group Policy (GP) to configure settings, such as settings for the sample sharing used in the deep analysis feature.
+
+### Configure sample collection settings 
+1.  On your GP management machine, copy the following files from the
+    configuration package:
+
+    a.  Copy _AtpConfiguration.admx_ into _C:\\Windows\\PolicyDefinitions_
+
+    b.  Copy _AtpConfiguration.adml_ into _C:\\Windows\\PolicyDefinitions\\en-US_
+
+2.  Open the [Group Policy Management Console](https://technet.microsoft.com/en-us/library/cc731212.aspx), right-click the GPO you want to configure and click **Edit**.
+
+3.  In the **Group Policy Management Editor**, go to **Computer configuration**.
+
+4.  Click **Policies**, then **Administrative templates**.
+
+5.  Click **Windows components** and then **Windows Advanced Threat Protection**.
+
+6.  Choose to enable or disable sample sharing from your endpoints.
+
+### Offboard endpoints
+For security reasons, the package used to offboard endpoints will expire 30 days after the date it was downloaded. Expired offboarding packages sent to an endpoint will be rejected. When downloading an offboarding package you will be notified of the packages expiry date and it will also be included in the package name.
+
+> **Note**&nbsp;&nbsp;Onboarding and offboarding policies must not be deployed on the same endpoint at the same time, otherwise this will cause unpredictable collisions.
+
+1.	Get the offboarding package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+
+    a. Click **Endpoint Management** on the **Navigation pane**.
+    
+    b. Under **Endpoint offboarding** section, select **Group Policy**, click **Download package** and save the .zip file.
+    
+2.	Extract the contents of the .zip file to a shared, read-only location that can be accessed by the endpoints. You should have a file named *WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd*.
+
+3.	Open the [Group Policy Management Console](https://technet.microsoft.com/en-us/library/cc731212.aspx) (GPMC), right-click the Group Policy Object (GPO) you want to configure and click Edit.
+
+4.	In the **Group Policy Management Editor**, go to **Computer configuration,** then **Preferences**, and then **Control panel settings**.
+
+5.	Right-click **Scheduled tasks**, point to **New**, and then click **Immediate task**.
+
+6.	In the **Task** window that opens, go to the **General** tab. Choose the local SYSTEM user account under **Security options**.
+
+7.	Select **Run whether user is logged on or not** and check the **Run with highest privileges** check-box.
+
+8.	Go to the **Actions** tab and click **New...**. Ensure that **Start a program** is selected in the **Action** field. Enter the file name and location of the shared  *WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd* file.
+
+9.	Click **OK** and close any open GPMC windows.
+
+## Monitor endpoint configuration 
+With Group Policy there isn’t an option to monitor deployment of policies on the endpoints. Monitoring can be done directly on the portal, or by using the different deployment tools.
+
+## Monitor endpoints using the portal 
+1.	Go to the [Windows Defender ATP portal](https://securitycenter.windows.com/).
+2.	Click **Machines view**.
+3.	Verify that endpoints are appearing.
+
+> **Note**&nbsp;&nbsp;It can take several days for endpoints to start showing on the **Machines view**. This includes the time it takes for the policies to be distributed to the endpoint, the time it takes before the user logs on, and the time it takes for the endpoint to start reporting.
+
+
+## Related topics
+- [Configure endpoints using System Center Configuration Manager](configure-endpoints-sccm-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using Mobile Device Management tools](configure-endpoints-mdm-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using a local script](configure-endpoints-script-windows-defender-advanced-threat-protection.md)
+- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
diff --git a/windows/keep-secure/configure-endpoints-mdm-windows-defender-advanced-threat-protection.md b/windows/keep-secure/configure-endpoints-mdm-windows-defender-advanced-threat-protection.md
new file mode 100644
index 0000000000..22692ee168
--- /dev/null
+++ b/windows/keep-secure/configure-endpoints-mdm-windows-defender-advanced-threat-protection.md
@@ -0,0 +1,92 @@
+---
+title: Configure Windows Defender ATP endpoints using Mobile Device Management tools
+description: Use Mobile Device Management tools to deploy the configuration package on endpoints so that they are onboarded to the service.
+keywords: configure endpoints using mdm, endpoint management, configure Windows ATP endpoints, configure Windows Defender Advanced Threat Protection endpoints, mdm
+search.product: eADQiWindows 10XVcnh
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: mjcaparas
+---
+
+# Configure endpoints using Mobile Device Management tools
+
+**Applies to:**
+
+- Windows 10 Insider Preview Build 14379 or later
+- Windows Defender Advanced Threat Protection (Windows Defender ATP)
+
+<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
+
+You can use mobile device management (MDM) solutions to configure endpoints. Windows Defender ATP supports MDMs by providing OMA-URIs to create policies to manage endpoints. 
+
+For more information on using Windows Defender ATP CSP see, [WindowsAdvancedThreatProtection CSP](https://msdn.microsoft.com/en-us/library/windows/hardware/mt723296(v=vs.85).aspx) and [WindowsAdvancedThreatProtection DDF file](https://msdn.microsoft.com/en-us/library/windows/hardware/mt723297(v=vs.85).aspx).
+
+## Configure endpoints using Microsoft Intune
+
+For more information on using Windows Defender ATP CSP see, [WindowsAdvancedThreatProtection CSP](https://msdn.microsoft.com/en-us/library/windows/hardware/mt723296(v=vs.85).aspx) and [WindowsAdvancedThreatProtection DDF file](https://msdn.microsoft.com/en-us/library/windows/hardware/mt723297(v=vs.85).aspx).
+
+### Onboard and monitor endpoints 
+
+1. Open the Microsoft Intune configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+ 
+    a.  Click **Endpoint Management** on the **Navigation pane**.
+
+    b.  Select **Mobile Device Management/Microsoft Intune**, click **Download package** and save the .zip file.
+
+2. Extract the contents of the .zip file to a shared, read-only location that can be accessed by the network administrators who will deploy the package. You should have a file called  *WindowsDefenderATP.onboarding*.
+
+3. Use the Microsoft Intune custom configuration policy to deploy the following supported OMA-URI settings. For more information on Microsoft Intune policy settings see, [Windows 10 policy settings in Microsoft Intune](https://docs.microsoft.com/en-us/intune/deploy-use/windows-10-policy-settings-in-microsoft-intune).
+
+Onboarding - Use the onboarding policies to deploy configuration settings on endpoints. These policies can be sub-categorized to:
+- Onboarding
+- Health Status for onboarded machines
+- Configuration for onboarded machines
+
+Policy | OMA-URI | Type | Value | Description
+:---|:---|:---|:---|:---
+Onboarding | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Onboarding | String | Copy content from onboarding MDM file |  Onboarding
+Health Status for onboarded machines | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/HealthState/SenseIsRunning | Boolean | TRUE |  Windows Defender ATP service is running
+ | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/HealthState/OnBoardingState | Integer | 1 | Onboarded to Windows Defender ATP
+  | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/HealthState/OrgId | String | Use OrgID from onboarding file | Onboarded to Organization ID
+ Configuration for onboarded machines  | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Configuration/SampleSharing | Integer | 0 or 1 <br> Default value: 1 | Windows Defender ATP Sample sharing is enabled 
+ 
+
+> **Note**&nbsp;&nbsp;Policies **Health Status for onboarded machines** use read-only properties and can't be remediated.
+
+### Offboard and monitor endpoints
+
+For security reasons, the package used to offboard endpoints will expire 30 days after the date it was downloaded. Expired offboarding packages sent to an endpoint will be rejected. When downloading an offboarding package you will be notified of the packages expiry date and it will also be included in the package name.
+
+> **Note**&nbsp;&nbsp;Onboarding and offboarding policies must not be deployed on the same endpoint at the same time, otherwise this will cause unpredictable collisions.
+
+1.	Get the offboarding package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+
+    a. Click **Endpoint Management** on the **Navigation pane**.
+    
+    b. Under **Endpoint offboarding** section, select **Mobile Device Management /Microsoft Intune**, click **Download package** and save the .zip file.
+    
+2.	Extract the contents of the .zip file to a shared, read-only location that can be accessed by the network administrators who will deploy the package. You should have a file named *WindowsDefenderATP_valid_until_YYYY-MM-DD.offboarding*.
+
+3. Use the Microsoft Intune custom configuration policy to deploy the following supported OMA-URI settings. For more information on Microsoft Intune policy settings see, [Windows 10 policy settings in Microsoft Intune](https://docs.microsoft.com/en-us/intune/deploy-use/windows-10-policy-settings-in-microsoft-intune). 
+
+Offboarding - Use the offboarding policies to remove configuration settings on endpoints. These policies can be sub-categorized to:
+- Offboarding
+- Health Status for offboarded machines
+- Configuration for offboarded machines
+
+Policy | OMA-URI | Type | Value | Description
+:---|:---|:---|:---|:---
+Offboarding | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/Offboarding | String | Copy content from offboarding MDM file | Offboarding 
+ Health Status for offboarded machines | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/HealthState/SenseIsRunning | Boolean | FALSE |Windows Defender ATP service is not running
+  | ./Device/Vendor/MSFT/WindowsAdvancedThreatProtection/HealthState/OnBoardingState | Integer | 0 | Offboarded from Windows Defender ATP
+
+> **Note**&nbsp;&nbsp;Policies **Health Status for offboarded machines** use read-only properties and can't be remediated.
+
+
+## Related topics
+- [Configure endpoints using Group Policy](configure-endpoints-gp-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using System Center Configuration Manager](configure-endpoints-sccm-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using a local script](configure-endpoints-script-windows-defender-advanced-threat-protection.md) 
+- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
\ No newline at end of file
diff --git a/windows/keep-secure/configure-endpoints-sccm-windows-defender-advanced-threat-protection.md b/windows/keep-secure/configure-endpoints-sccm-windows-defender-advanced-threat-protection.md
new file mode 100644
index 0000000000..3f7fac27dc
--- /dev/null
+++ b/windows/keep-secure/configure-endpoints-sccm-windows-defender-advanced-threat-protection.md
@@ -0,0 +1,94 @@
+---
+title: Configure Windows Defender ATP endpoints using System Center Configuration Manager
+description: Use System Center Configuration Manager to deploy the configuration package on endpoints so that they are onboarded to the service.
+keywords: configure endpoints using sccm, endpoint management, configure Windows ATP endpoints, configure Windows Defender Advanced Threat Protection endpoints, sccm
+search.product: eADQiWindows 10XVcnh
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: mjcaparas
+---
+
+# Configure endpoints using System Center Configuration Manager
+
+
+**Applies to:**
+
+- Windows 10 Insider Preview Build 14332  or later
+- Windows Defender Advanced Threat Protection (Windows Defender ATP)
+
+<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
+
+<span id="sccm1606"/>
+## Configure endpoints using System Center Configuration Manager (current branch) version 1606
+System Center Configuration Manager (current branch) version 1606, currently in technical preview, has UI integrated support for configuring and managing Windows Defender ATP on endpoints. For more information, see the [Support for Windows Defender Advanced Threat Protection service](https://technet.microsoft.com/en-us/library/mt706220.aspx#BKMK_ATP) section.
+
+> **Note**&nbsp;&nbsp; If you intend to use this deployment tool, ensure that you are on Windows 10 Insider Preview Build 14379 or later. This deployment method is only available from that build or later.
+
+<span id="sccm1602"/>
+## Configure endpoints using System Center Configuration Manager (current branch) version 1602 or earlier versions 
+You can use System Center Configuration Manager’s existing functionality to create a policy to configure your endpoints. This is supported in System Center Configuration Manager (current branch), version 1602 or earlier, including: System Center 2012 R2 Configuration Manager and System Center 2012 Configuration Manager. 
+
+### Onboard endpoints 
+
+1. Open the SCCM configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+
+    a. Click **Endpoint Management** on the **Navigation pane**.
+
+    b. Select **System Center Configuration Manager (current branch) version 1602 or earlier**, click **Download package**, and save the .zip file.
+
+2. Extract the contents of the .zip file to a shared, read-only location that can be accessed by the network administrators who will deploy the package. You should have a file called *WindowsDefenderATPOnboardingScript.cmd*.
+
+3. Import the configuration package by following the steps in the [How to Create Packages and Programs in Configuration Manager](https://technet.microsoft.com/en-us/library/gg682112.aspx#BKMK_Import) topic.
+
+4. Deploy the package by following the steps in the [How to Deploy Packages and Programs in Configuration Manager](https://technet.microsoft.com/en-us/library/gg682178.aspx) topic.
+
+    a. Choose a predefined device collection to deploy the package to.
+    
+### Offboard endpoints 
+
+For security reasons, the package used to offboard endpoints will expire 30 days after the date it was downloaded. Expired offboarding packages sent to an endpoint will be rejected. When downloading an offboarding package you will be notified of the packages expiry date and it will also be included in the package name.
+
+> **Note**&nbsp;&nbsp;Onboarding and offboarding policies must not be deployed on the same endpoint at the same time, otherwise this will cause unpredictable collisions.
+
+1.	Get the offboarding package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+
+     a. Click **Endpoint Management** on the **Navigation pane**.
+    
+    b. Under **Endpoint offboarding** section, select **System Center Configuration Manager (current branch) version 1602 or earlier**, click **Download package**, and save the .zip file.
+    
+2.	Extract the contents of the .zip file to a shared, read-only location that can be accessed by the network administrators who will deploy the package. You should have a file named *WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd*.
+
+3. Import the configuration package by following the steps in the [How to Create Packages and Programs in Configuration Manager](https://technet.microsoft.com/en-us/library/gg682112.aspx#BKMK_Import) topic.
+
+4. Deploy the package by following the steps in the [How to Deploy Packages and Programs in Configuration Manager](https://technet.microsoft.com/en-us/library/gg682178.aspx) topic.
+
+    a. Choose a predefined device collection to deploy the package to.
+    
+### Monitor endpoint configuration
+Monitoring with SCCM consists of two parts:
+
+1. Confirming the configuration package has been correctly deployed and is running (or has successfully run) on the endpoints in your network.
+
+2. Checking that the endpoints are compliant with the Windows Defender ATP service (this ensures the endpoint can complete the onboarding process and can continue to report data to the service).
+
+**To confirm the configuration package has been correctly deployed:**
+
+1. In the SCCM console, click **Monitoring** at the bottom of the navigation pane.
+
+2. Click **Overview** and then **Deployments**.
+
+3. Click on the deployment with the package name.
+
+4. Review the status indicators under **Completion Statistics** and **Content Status**.
+
+If there are failed deployments (endpoints with **Error**, **Requirements Not Met**, or **Failed statuses**), you may need to  troubleshoot the endpoints. See the [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md) topic for more information.
+
+![SCCM showing successful deployment with no errors](images/sccm-deployment.png)
+
+## Related topics
+- [Configure endpoints using Group Policy](configure-endpoints-gp-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using Mobile Device Management tools](configure-endpoints-mdm-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using a local script](configure-endpoints-script-windows-defender-advanced-threat-protection.md) 
+- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
\ No newline at end of file
diff --git a/windows/keep-secure/configure-endpoints-script-windows-defender-advanced-threat-protection.md b/windows/keep-secure/configure-endpoints-script-windows-defender-advanced-threat-protection.md
new file mode 100644
index 0000000000..37cff93fb6
--- /dev/null
+++ b/windows/keep-secure/configure-endpoints-script-windows-defender-advanced-threat-protection.md
@@ -0,0 +1,69 @@
+---
+title: Configure Windows Defender ATP endpoints using a local script
+description: Use a local script to deploy the configuration package on endpoints so that they are onboarded to the service.
+keywords: configure endpoints using a local script, endpoint management, configure Windows ATP endpoints, configure Windows Defender Advanced Threat Protection endpoints
+search.product: eADQiWindows 10XVcnh
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: mjcaparas
+---
+
+# Configure endpoints using a local script
+You can also manually onboard individual endpoints to Windows Defender ATP. You might want to do this first when testing the service before you commit to onboarding all endpoints in your network.
+
+
+1.  Open the GP configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+
+    a.  Click **Endpoint Management** on the **Navigation pane**.
+
+    b.  Select **Local Script**, click **Download package** and save the .zip file.
+
+
+2.  Extract the contents of the configuration package to a location on the endpoint you want to onboard (for example, the Desktop). You should have a file called *WindowsDefenderATPOnboardingScript.cmd*.
+
+3.  Open an elevated command-line prompt on the endpoint and run the script:
+
+    a.  Click **Start** and type **cmd**.
+
+    b.  Right-click **Command prompt** and select **Run as administrator**.
+
+    ![Window Start menu pointing to Run as administrator](images/run-as-admin.png)
+
+4.  Type the location of the script file. If you copied the file to the desktop, type: *%userprofile%\Desktop\WindowsDefenderATPOnboardingScript.cmd*
+
+5.  Press the **Enter** key or click **OK**.
+
+See the [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md) topic for details on how you can manually validate that the endpoint is compliant and correctly reports telemetry.
+
+## Offboard endpoints using a local script
+For security reasons, the package used to offboard endpoints will expire 30 days after the date it was downloaded. Expired offboarding packages sent to an endpoint will be rejected. When downloading an offboarding package you will be notified of the packages expiry date and it will also be included in the package name.
+
+> **Note**&nbsp;&nbsp;Onboarding and offboarding policies must not be deployed on the same endpoint at the same time, otherwise this will cause unpredictable collisions.
+
+1.	Get the offboarding package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
+
+    a. Click **Endpoint Management** on the **Navigation pane**.
+    b. Under **Endpoint offboarding** section, select **Group Policy**, click **Download package** and save the .zip file.
+    
+2.	Extract the contents of the .zip file to a shared, read-only location that can be accessed by the endpoints. You should have a file named *WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd*.
+
+3.  Open an elevated command-line prompt on the endpoint and run the script:
+
+    a.  Click **Start** and type **cmd**.
+
+    b.  Right-click **Command prompt** and select **Run as administrator**.
+
+    ![Window Start menu pointing to Run as administrator](images/run-as-admin.png)
+
+4.  Type the location of the script file. If you copied the file to the desktop, type: *%userprofile%\Desktop\WindowsDefenderATPOffboardingScript_valid_until_YYYY-MM-DD.cmd*
+
+5.  Press the **Enter** key or click **OK**.
+
+
+## Related topics
+- [Configure endpoints using Group Policy](configure-endpoints-gp-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using System Center Configuration Manager](configure-endpoints-sccm-windows-defender-advanced-threat-protection.md)
+- [Configure endpoints using Mobile Device Management tools](configure-endpoints-mdm-windows-defender-advanced-threat-protection.md)
+- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
\ No newline at end of file
diff --git a/windows/keep-secure/configure-endpoints-windows-defender-advanced-threat-protection.md b/windows/keep-secure/configure-endpoints-windows-defender-advanced-threat-protection.md
index aede6f38ed..0028b5478b 100644
--- a/windows/keep-secure/configure-endpoints-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/configure-endpoints-windows-defender-advanced-threat-protection.md
@@ -1,13 +1,13 @@
 ---
 title: Configure Windows Defender ATP endpoints
 description: Use Group Policy or SCCM to deploy the configuration package or do manual registry changes on endpoints so that they are onboarded to the service.
-keywords: configure endpoints, client onboarding, configure Windows ATP endpoints, configure Windows Defender Advanced Threat Protection endpoints, sccm, system center configuration manager
+keywords: configure endpoints, endpoint management, configure Windows ATP endpoints, configure Windows Defender Advanced Threat Protection endpoints, sccm, system center configuration manager
 search.product: eADQiWindows 10XVcnh
 ms.prod: w10
 ms.mktglfcycl: deploy
 ms.sitesec: library
 ms.pagetype: security
-author: iaanw
+author: mjcaparas
 ---
 
 # Configure Windows Defender ATP endpoints
@@ -19,86 +19,19 @@ author: iaanw
 
 <span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
 
-You can use a Group Policy (GP) configuration package, a System Center Configuration Manager (SCCM) package, or an automated script to configure endpoints.
+Endpoints in your organization must be configured so that the Windows Defender ATP service can get telemetry from them. There are various methods and deployment tools that you can use to configure the endpoints in your organization. 
 
-## Configure with Group Policy
-Using the GP configuration package ensures your endpoints will be correctly configured to report to the Windows Defender ATP service.
+Windows Defender ATP supports the following deployment tools and methods:
 
-> **Note**&nbsp;&nbsp;To use GP updates to deploy the package, you must be on Windows Server 2008 R2 or later. The endpoints must be running Windows 10 Insider Preview Build 14332 or later.
+- Group Policy
+- System Center Configuration Manager
+- Mobile Device Management (including Microsoft Intune)
+- Local script
 
-1.  Open the GP configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
-
-    a.  Click **Client onboarding** on the **Navigation pane**.
-
-    b.  Select **Group Policy**, click **Download package** and save the .zip file.
-
-2.	Extract the contents of the .zip file to a shared, read-only location that can be accessed by the endpoints. You should have a folder called *OptionalParamsPolicy* and the file *WindowsDefenderATPOnboardingScript.cmd*.
-
-3. Open the [Group Policy Management Console](https://technet.microsoft.com/en-us/library/cc731212.aspx) (GPMC), right-click the Group Policy Object (GPO) you want to configure and click **Edit**.
-
-4. In the **Group Policy Management Editor**, go to **Computer configuration**, then **Preferences**, and then **Control panel settings**.
-
-5. Right-click **Scheduled tasks**, point to **New**, and then click **Immediate task**.
-
-6. In the  **Task** window that opens, go to the **General** tab. Choose the local SYSTEM user account under **Security options**.
-
-7. Select **Run whether user is logged on or not** and check the **Run with highest privileges** check box.
-
-8. Go to the **Actions** tab and click **New...** Ensure that **Start a program** is selected in the **Action** field. Enter the file name and location of the shared *WindowsDefenderATPOnboardingScript.cmd* file.
-
-9. Click **OK** and close any open GPMC windows.
-
-For additional settings, see the [Additional configuration settings section](additional-configuration-windows-defender-advanced-threat-protection.md).
-
-
-## Configure with System Center Configuration Manager
-
-1. Open the SCCM configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
-
-    a. Click **Client onboarding** on the **Navigation pane**.
-
-    b. Select **System Center Configuration Manager**, click **Download package**, and save the .zip file.
-
-2. Extract the contents of the .zip file to a shared, read-only location that can be accessed by the network administrators who will deploy the package. You should have a file called *WindowsDefenderATPOnboardingScript.cmd*.
-
-3. Import the configuration package by following the steps in the [How to Create Packages and Programs in Configuration Manager](https://technet.microsoft.com/en-us/library/gg682112.aspx#BKMK_Import) topic.
-
-4. Deploy the package by following the steps in the [How to Deploy Packages and Programs in Configuration Manager](https://technet.microsoft.com/en-us/library/gg682178.aspx) topic.
-
-    a. Choose a predefined device collection to deploy the package to.
-
-
-## Configure endpoints individually with an automated script
-<a name="manual"></a>
-You can also manually onboard individual endpoints to Windows Defender ATP. You might want to do this first when testing the service before you commit to onboarding all endpoints in your network.
-
-
-1.  Open the GP configuration package .zip file (*WindowsDefenderATPOnboardingPackage.zip*) that you downloaded from the service onboarding wizard. You can also get the package from the [Windows Defender ATP portal](https://securitycenter.windows.com/):
-
-    a.  Click **Client onboarding** on the **Navigation pane**.
-
-    b.  Select **Local Script**, click **Download package** and save the .zip file.
-
-
-2.  Extract the contents of the configuration package to a location on the endpoint you want to onboard (for example, the Desktop). You should have a file called *WindowsDefenderATPOnboardingScript.cmd*.
-
-3.  Open an elevated command-line prompt on the endpoint and run the script:
-
-    a.  Click **Start** and type **cmd**.
-
-    b.  Right-click **Command prompt** and select **Run as administrator**.
-
-    ![Window Start menu pointing to Run as administrator](images/run-as-admin.png)
-
-4.  Type the location of the script file. If you copied the file to the desktop, type: *`%userprofile%\Desktop\WindowsDefenderATPOnboardingScript.cmd`*
-
-5.  Press the **Enter** key or click **OK**.
-
-See the [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md) topic for details on how you can manually validate that the endpoint is compliant and correctly reports telemetry.
-
-## Related topics
-<!--- [Windows Defender ATP service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md)-->
-- [Configure endpoint proxy and Internet connectivity settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md)
-- [Additional Windows Defender ATP configuration settings](additional-configuration-windows-defender-advanced-threat-protection.md)
-- [Monitor the Windows Defender ATP onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md)
-- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
+## In this section
+Topic | Description
+:---|:---
+[Configure endpoints using Group Policy](configure-endpoints-gp-windows-defender-advanced-threat-protection.md) | Use Group Policy to deploy the configuration package on endpoints.
+[Configure endpoints using System Center Configuration Manager](configure-endpoints-sccm-windows-defender-advanced-threat-protection.md) | You can use either use System Center Configuration Manager (current branch) version 1606 or System Center Configuration Manager(current branch) version 1602 or earlier to deploy the configuration package on endpoints.
+[Configure endpoints using Mobile Device Management tools](configure-endpoints-mdm-windows-defender-advanced-threat-protection.md) | Use Mobile Device Managment tools or Microsoft Intune to deploy the configuration package on endpoints.
+[Configure endpoints using a local script](configure-endpoints-script-windows-defender-advanced-threat-protection.md) | Learn how to use the local script to deploy the configuration package on endpoints.
diff --git a/windows/keep-secure/configure-proxy-internet-windows-defender-advanced-threat-protection.md b/windows/keep-secure/configure-proxy-internet-windows-defender-advanced-threat-protection.md
index e0564e8606..27177d0829 100644
--- a/windows/keep-secure/configure-proxy-internet-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/configure-proxy-internet-windows-defender-advanced-threat-protection.md
@@ -116,15 +116,16 @@ For more information on how to use Netsh see, [Netsh Commands for Windows Hypert
 
 If a proxy or firewall is blocking all traffic by default and allowing only specific domains through, make sure that the following URLs are white-listed to permit communication with Windows Defender ATP service in port 80 and 443:
 
-- us.vortex-win.data.microsoft.com  
+- *.blob.core.windows.net
+- crl.microsoft.com
 - eu.vortex-win.data.microsoft.com
 - sevillegwcus.microsoft.com
 - sevillegweus.microsoft.com
-- sevillegwweu.microsoft.com
 - sevillegwneu.microsoft.com
+- sevillegwweu.microsoft.com
+- us.vortex-win.data.microsoft.com 
 - www.microsoft.com
-- crl.microsoft.com
-- \*.blob.core.windows.net
+
 
 If a proxy or firewall is blocking anonymous traffic, as Windows Defender ATP  sensor is connecting from system context, make sure anonymous traffic is permitted to the above listed URLs.
 
@@ -165,21 +166,18 @@ Verify the proxy configuration completed successfully, that WinHTTP can discover
 
 7. Repeat the same steps for the remaining URLs with the following arguments:
 
-    - portqry.exe -n eu.vortex-win.data.microsoft.com -e 443 -p tcp
-    - portqry.exe -n sevillegwcus.microsoft.com -e 443 -p tcp
-    - portqry.exe -n sevillegweus.microsoft.com -e 443 -p tcp
-    - portqry.exe -n sevillegwweu.microsoft.com -e 443 -p tcp
-    - portqry.exe -n sevillegwneu.microsoft.com -e 443 -p tcp
-    - portqry.exe -n www.microsoft.com -e 80 -p tcp
-    - portqry.exe -n crl.microsoft.com -e 80 -p tcp
+   - portqry.exe -n eu.vortex-win.data.microsoft.com -e 443 -p tcp
+   - portqry.exe -n sevillegwcus.microsoft.com -e 443 -p tcp
+   - portqry.exe -n sevillegweus.microsoft.com -e 443 -p tcp
+   - portqry.exe -n sevillegwweu.microsoft.com -e 443 -p tcp
+   - portqry.exe -n sevillegwneu.microsoft.com -e 443 -p tcp
+   - portqry.exe -n www.microsoft.com -e 80 -p tcp
+   - portqry.exe -n crl.microsoft.com -e 80 -p tcp
 
 8. Verify that each URL shows that the name is **resolved** and the connection status is **listening**.
 
 If the any of the verification steps indicate a fail, then verify that you have performed the proxy configuration steps to enable server discovery and access to the service URLs.
 
 ## Related topics
-<!--- [Windows Defender ATP service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md)-->
 - [Configure Windows Defender ATP endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md)
-- [Additional Windows Defender ATP configuration settings](additional-configuration-windows-defender-advanced-threat-protection.md)
-- [Monitor the Windows Defender ATP onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md)
 - [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
diff --git a/windows/keep-secure/create-edp-policy-using-intune.md b/windows/keep-secure/create-edp-policy-using-intune.md
index 194bdc40b7..49a3959cc2 100644
--- a/windows/keep-secure/create-edp-policy-using-intune.md
+++ b/windows/keep-secure/create-edp-policy-using-intune.md
@@ -20,314 +20,494 @@ author: eross-msft
 Microsoft Intune helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
 
 ## Important note about the June service update
-We've received some great feedback from you, our Windows 10 Insider Preview customers, about our enterprise data protection experiences and processes. Because of that feedback, we're delighted to deliver an enhanced apps policy experience with the June service update. This means that when you open an existing enterprise data protection policy after we release the June service update in your test environment, your existing Windows 10 enterprise data protection app rules (formerly in the **Protected Apps** area) will be removed.<p>To prepare for this change, we recommend that you make an immediate backup of your current app rules as they are today, so you can use them to help reconfigure your app rules with the enhanced experience. When you open an existing enterprise data protection policy after we release the June service update, you'll get a dialog box telling you about this change. Click the **OK** button to close the box and to begin reconfiguring your app rules.<p>![Microsoft Intune: Reconfigure app rules list dialog box](images/edp-intune-app-reconfig-warning.png)<p>Note that if you exit the **Policy** page before you've saved your new policy, your existing deployments won't be affected. However, if you save the policy without reconfiguring your apps, an updated policy will be deployed to your employees with an empty app rules list.
+We've received some great feedback from you, our Windows 10 Insider Preview customers, about our enterprise data protection experiences and processes. Because of that feedback, we're delighted to deliver an enhanced apps policy experience with the June service update. This means that when you open an existing enterprise data protection policy after we release the June service update in your test environment, your existing Windows 10 enterprise data protection app rules (formerly in the **Protected Apps** area) will be removed.<p>To prepare for this change, we recommend that you make an immediate backup of your current app rules as they are today, so you can use them to help reconfigure your app rules with the enhanced experience. When you open an existing enterprise data protection policy after we release the June service update, you'll get a dialog box telling you about this change. Click the **OK** button to close the box and to begin reconfiguring your app rules.
+
+![Microsoft Intune: Reconfigure app rules list dialog box](images/edp-intune-app-reconfig-warning.png)
+
+Note that if you exit the **Policy** page before you've saved your new policy, your existing deployments won't be affected. However, if you save the policy without reconfiguring your apps, an updated policy will be deployed to your employees with an empty app rules list.
  
 ## Add an EDP policy
-After you’ve installed and set up Intune for your organization, you must create an EDP-specific policy.
+After you’ve set up Intune for your organization, you must create an EDP-specific policy.
 
 **To add an EDP policy**
 1.  Open the Intune administration console, and go to the **Policy** node, and then click **Add Policy** from the **Tasks** area.
 
-2.  Go to **Windows**, click the **Enterprise Data Protection (Windows 10 and Mobile and later) policy**, pick the EDP template, click **Create and Deploy a Custom Policy**, and then click **Create Policy**.
+2.  Go to **Windows**, click the **Enterprise data protection (Windows 10 Desktop and Mobile and later) policy**, click **Create and Deploy a Custom Policy**, and then click **Create Policy**.
 
     ![Microsoft Intune: Create your new policy from the New Policy screen](images/intune-createnewpolicy.png)
 
 3.  Type a name (required) and an optional description for your policy into the **Name** and **Description** boxes.
 
-    ![Microsoft Intune: Fill out the required Name and optional Description fields](images/intune-namedescription.png)
+    ![Microsoft Intune: Fill out the required Name and optional Description fields](images/intune-generalinfo.png)
 
-## Add individual apps to your Protected App list
+### Add app rules to your policy
 During the policy-creation process in Intune, you can choose the apps you want to give access to your enterprise data through EDP. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps.
 
-The steps to add your apps are based on the type of app it is; either a Universal Windows Platform (UWP) app, or a signed Desktop app, also known as a Classic Windows application.
+The steps to add your app rules are based on the type of rule template being applied. You can add a store app (also known as a Universal Windows Platform (UWP) app), a signed desktop app (also known as a Classic Windows app), or an AppLocker policy file.
 
->**Important**<br>EDP-aware apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, EDP-unaware apps might not respect the corporate network boundary and will encrypt all files they create or modify, meaning that they could encrypt personal data and cause data loss during the revocation process. Care must be taken to get a support statement from the software provider that their app is safe with EDP before adding it to your **Protected App** list.<p>
+>**Important**<br>
+EDP-aware apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, EDP-unaware apps might not respect the corporate network boundary, and EDP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause data loss during the revocation process.<p>Care must be taken to get a support statement from the software provider that their app is safe with EDP before adding it to your App Rules list. If you don’t get this statement, it’s possible that you could experience app compat issues due to an app losing the ability to access a necessary file after revocation.
 
->**Note**<br>If you want to use **File hash** or **Path** rules, instead of Publisher rules, you must follow the steps in the [Add multiple apps to your enterprise data protection (EDP) Protected Apps list](add-apps-to-protected-list-using-custom-uri.md) topic.
+<p>
+>**Note**<br>
+If you want to use **File hash** or **Path** rules, instead of **Publisher** rules, you must follow the steps in the [Add apps using Microsoft Intune and custom URI](add-apps-to-protected-list-using-custom-uri.md) topic.
 
-**To add a UWP app**
+#### Add a store app rule to your policy
+For this example, we’re going to add Microsoft OneNote, a store app, to the **App Rules** list.
 
-1.  From the **Configure the following apps to be protected by EDP** table in the **Protected Apps** area, click **Add.**
+**To add a store app**
+1.	From the **App Rules** area, click **Add**.
 
-2.  Click **Universal App**, type the **Publisher Name** and the **Product Name** into the associated boxes, and then click **OK**. If you don't have the publisher or product name, you can find them for both desktop devices and Windows 10 Mobile phones by following these steps.
+    The **Add App Rule** box appears.
 
-    **To find the Publisher and Product name values for Microsoft Store apps without installing them**
+        ![Microsoft Intune, Add a store app to your policy](images/intune-add-uwp-apps.png)
 
-    1.  Go to the [Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkID=722910) website, and find your app. For example, Microsoft OneNote.
-    
-        >**Note**<br>If your app is already installed on desktop devices, you can use the AppLocker local security policy MMC snap-in to gather the info for adding the app to the **Protected App** list. For info about how to do this, see the [Add multiple apps to your enterprise data protection (EDP) Protected Apps list](add-apps-to-protected-list-using-custom-uri.md) topic.
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Microsoft OneNote*.
 
-    2.  Copy the ID value from the app URL. For example, Microsoft OneNote's ID URL is https://www.microsoft.com/store/apps/onenote/9wzdncrfhvjl, and you'd copy the ID value, `9wzdncrfhvjl`.
+3.	Click **Allow** from the **Enterprise data protection mode** drop-down list.
+
+    Allow turns on EDP, helping to protect that app’s corporate data through the enforcement of EDP restrictions. Instructions for exempting an app are included in the [Exempt apps from EDP restrictions](#exempt-apps-from-edp-restrictions) section of this topic.
+
+4.	Pick **Store App** from the **Rule template** drop-down list.
+
+    The box changes to show the store app rule options.
+
+5.	Type the name of the app and the name of its publisher, and then click **OK**. For this UWP app example, the **Publisher** is`CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US` and the **Product name** is `Microsoft.Office.OneNote`.
+
+If you don't know the publisher or product name, you can find them for both desktop devices and Windows 10 Mobile phones by following these steps.
+
+**To find the Publisher and Product Name values for Store apps without installing them**
+1.	Go to the [Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkID=722910) website, and find your app. For example, *Microsoft OneNote*.
+
+    >**Note**<br>
+    If your app is already installed on desktop devices, you can use the AppLocker local security policy MMC snap-in to gather the info for adding the app to the protected apps list. For info about how to do this, see the [Add apps using Microsoft Intune and custom URI](add-apps-to-protected-list-using-custom-uri.md) topic.
+
+2.	Copy the ID value from the app URL. For example, Microsoft OneNote's ID URL is https://www.microsoft.com/store/apps/onenote/9wzdncrfhvjl, and you'd copy the ID value, `9wzdncrfhvjl`.
+
+3.	In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON) file that includes the publisher and product name values. For example, run https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfhvjl/applockerdata, where `9wzdncrfhvjl` is replaced with your ID value.
 
-    3.  In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON) file that includes the publisher and product name values. For example, run https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/*9wzdncrfhvjl*/applockerdata, where *9wzdncrfhvjl* is replaced with your ID value.
-    <p>
     The API runs and opens a text editor with the app details.
 
         ``` json
-        {
-          "packageIdentityName": "Microsoft.Office.OneNote",
-          "publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
-        }
+            {
+                "packageIdentityName": "Microsoft.Office.OneNote",
+                "publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
+            }
         ```
-    4.  Copy the `publisherCertificateName` value into the **Publisher Name** box and copy the `packageIdentityName` value into the **Product Name** box of Intune.
-     <p>**Important**<br>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as “CN=” followed by the `windowsPhoneLegacyId`.
-    <p>For example:<br>
-     ``` json
+4. Copy the `publisherCertificateName` value into the **Publisher Name** box and copy the `packageIdentityName` value into the **Product Name** box of Intune.
+
+    >**Important**<br>
+    The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as `CN=` followed by the `windowsPhoneLegacyId`.<p>For example:<br>
+    
+    ``` json
         {
-          "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
-        }
-       ```
-    ![Microsoft Intune: Add a UWP app to the Protected Apps list](images/intune-addapps.png)
+	       "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
+	    }
+    ```
 
-    **To find the Publisher and Product name values for apps installed on Windows 10 Mobile phones**
+**To find the Publisher and Product Name values for apps installed on Windows 10 mobile phones**
+1.	If you need to add mobile apps that aren't distributed through the Store for Business, you must use the **Windows Device Portal** feature.
 
-    1.  If you need to add mobile apps that aren't distributed through the Store for Business, you must use the **Windows Device Portal** feature.
+    >**Note**<br>
+    Your PC and phone must be on the same wireless network.
+
+2.	On the Windows Phone, go to **Settings**, choose **Update & security**, and then choose **For developers**.
+
+3.	In the **For developers** screen, turn on **Developer mode**, turn on **Device Discovery**, and then turn on **Device Portal**.
+
+4.	Copy the URL in the **Device Portal** area into your device's browser, and then accept the SSL certificate.
+
+5.	In the **Device discovery** area, press **Pair**, and then enter the PIN into the website from the previous step.
+
+6.	On the **Apps** tab of the website, you can see details for the running apps, including the publisher and product names.
+
+7.	Start the app for which you're looking for the publisher and product name values.
+
+8.	Copy the `publisherCertificateName` value and paste it into the **Publisher Name** box and the `packageIdentityName` value into the **Product Name** box of Intune.
+
+    >**Important**<br>
+    The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as `CN=` followed by the `windowsPhoneLegacyId`.<p>For example:<br>
     
-        >**Note**<br>Your PC and phone must be on the same wireless network.
-
-    2.  On the Windows Phone, go to **Settings**, choose **Update & security**, and then choose **For developers**.
-
-    3.  In the **For developers** screen, turn on **Developer mode**, turn on **Device Discovery**, and then turn on **Device Portal**.
-
-    4.  Copy the URL in the **Device Portal** area into your device's browser, and then accept the SSL certificate.
-
-    5.  In the **Device discovery** area, press **Pair**, and then enter the PIN into the website from the previous step.
-
-    6.  On the **Apps** tab of the website, you can see details for the running apps, including the publisher and product names.
-    
-    7. Start the app for which you're looking for the publisher and product name values
-
-    8.  Copy the `publisherCertificateName` value and paste it into the **Publisher Name** box and the `packageIdentityName` value into the **Product Name** box of Intune.
-    
-        >**Important**<br>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as “CN=” followed by the `windowsPhoneLegacyId`.
-    <p>For example:<br>
-     ``` json
+    ``` json
         {
-          "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
-        }
-       ```
+	       "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
+	    }
+    ```
 
-**To add a Classic Windows application**
+#### Add a desktop app rule to your policy
+For this example, we’re going to add Internet Explorer, a desktop app, to the **App Rules** list.
 
-1.  From the **Configure the following apps to be protected by EDP** table in the **Protected Apps** area, click **Add.**
-<p>A dialog box appears, letting you pick whether the app is a **Universal App** or a **Desktop App**.
+**To add a desktop app**
+1.	From the **App Rules** area, click **Add**.
+
+    The **Add App Rule** box appears.
+
+        ![Microsoft Intune, Add a desktop app to your policy](images/intune-add-classic-apps.png)
+
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Internet Explorer*.
+
+3.	Click **Allow** from the **Enterprise data protection mode** drop-down list.
+
+    Allow turns on EDP, helping to protect that app’s corporate data through the enforcement of EDP restrictions. Instructions for exempting an app are included in the [Exempt apps from EDP restrictions](#exempt-apps-from-edp-restrictions) section of this topic.
+
+4.	Pick **Desktop App** from the **Rule template** drop-down list.
+
+    The box changes to show the store app rule options.
+
+5. Pick the options you want to include for the app rule (see table), and then click **OK**.
 
-2.  Click **Desktop App**, pick the options you want (see table), and then click **OK**.
     <table>
         <tr>
             <th>Option</th>
             <th>Manages</th>
         </tr>
         <tr>
-            <td>All fields left as "*"</td>
+            <td>All fields left as “*”</td>
             <td>All files signed by any publisher. (Not recommended.)</td>
         </tr>
         <tr>
             <td><strong>Publisher</strong> selected</td>
             <td>All files signed by the named publisher.<p>This might be useful if your company is the publisher and signer of internal line-of-business apps.</td>
         </tr>
-         <tr>
+        <tr>
             <td><strong>Publisher</strong> and <strong>Product Name</strong> selected</td>
             <td>All files for the specified product, signed by the named publisher.</td>
-        </tr>  
-         <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, and <strong>File Name</strong> selected</td>
+        </tr>
+        <tr>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, and <strong>Binary name</strong> selected</td>
             <td>Any version of the named file or package for the specified product, signed by the named publisher.</td>
         </tr>
-         <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>File Name</strong>, and <strong>File Version, Exactly</strong> selected</td>
-            <td>Specified version of the named file or package for the specified product, signed by the named publisher.</td>
-        </tr>
-         <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>File Name</strong>, and <strong>File Version, And above</strong> selected</td>
+        <tr>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>Binary name</strong>, and <strong>File Version, and above</strong>, selected</td>
             <td>Specified version or newer releases of the named file or package for the specified product, signed by the named publisher.<p>This option is recommended for enlightened apps that weren't previously enlightened.</td>
         </tr>
-         <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>File Name</strong>, and <strong>File Version, And below</strong> selected</td>
+        <tr>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>Binary name</strong>, and <strong>File Version, And below</strong> selected</td>
             <td>Specified version or older releases of the named file or package for the specified product, signed by the named publisher.</td>
-        </tr>                                            
+        </tr>
+        <tr>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>Binary name</strong>, and <strong>File Version, Exactly</strong> selected</td>
+            <td>Specified version of the named file or package for the specified product, signed by the named publisher.</td>
+        </tr>
     </table>
 
 If you’re unsure about what to include for the publisher, you can run this PowerShell command:
 
-``` ps1
-Get-AppLockerFileInformation -Path "<path of the exe>"
+```ps1
+    Get-AppLockerFileInformation -Path "<path of the exe>"
 ```
-Where `"<path_of_the_exe>"` goes to the location of the app on the device. For example, `Get-AppLockerFileInformation -Path "C:\Program Files\Internet Explorer\iexplore.exe"`.
+Where `"<path of the exe>"` goes to the location of the app on the device. For example, `Get-AppLockerFileInformation -Path "C:\Program Files\Internet Explorer\iexplore.exe"`.
 
 In this example, you'd get the following info:
 
 ``` json
-Path                                          Publisher
-----                                          ---------
-%PROGRAMFILES%\INTERNET EXPLORER\IEXPLORE.EXE O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\INTERNET EXPLOR...
+    Path                   Publisher
+    ----                   ---------
+    %PROGRAMFILES%\INTERNET EXPLORER\IEXPLORE.EXE O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US\INTERNET EXPLOR...
 ```
 Where the text, `O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US` is the publisher name to enter in the **Publisher Name** box.
 
-![Microsoft Intune: Add a Classic Windows app to the Protected Apps list](images/intune-add-desktop-app.png)
+#### Add an AppLocker policy file
+For this example, we’re going to add an AppLocker XML file to the **App Rules** list. You’ll use this option if you want to add multiple apps at the same time. For more info about AppLocker, see the [AppLocker](https://technet.microsoft.com/en-us/itpro/windows/keep-secure/applocker-overview) content.
 
-## Exempt apps from EDP restrictions
+**To create an app rule and xml file using the AppLocker tool**
+1.	Open the Local Security Policy snap-in (SecPol.msc).
+    
+2.	In the left pane, expand **Application Control Policies**, expand **AppLocker**, and then click **Packaged App Rules**.
+
+    ![Local security snap-in, showing the Packaged app Rules](images/intune-local-security-snapin.png)
+
+3.	Right-click in the right-hand pane, and then click **Create New Rule**.
+
+    The **Create Packaged app Rules** wizard appears.
+
+4. On the **Before You Begin** page, click **Next**.
+
+    ![Create Packaged app Rules wizard, showing the Before You Begin page](images/intune-applocker-before-begin.png)
+
+5. On the **Permissions** page, make sure the **Action** is set to **Allow** and the **User or group** is set to **Everyone**, and then click **Next**.
+
+    ![Create Packaged app Rules wizard, showing the Before You Begin page](images/intune-applocker-permissions.png)
+
+6.	On the **Publisher** page, click **Select** from the **Use an installed packaged app as a reference** area.
+
+    ![Create Packaged app Rules wizard, showing the Publisher](images/intune-applocker-publisher.png)
+
+7. In the **Select applications** box, pick the app that you want to use as the reference for your rule, and then click **OK**. For this example, we’re using Microsoft Photos.
+
+    ![Create Packaged app Rules wizard, showing the Select applications page](images/intune-applocker-select-apps.png)
+
+8. On the updated **Publisher** page, click **Create**.
+
+    ![Create Packaged app Rules wizard, showing the Microsoft Photos on the Publisher page](images/intune-applocker-publisher-with-app.png)
+
+9. Review the Local Security Policy snap-in to make sure your rule is correct.
+
+    ![Local security snap-in, showing the new rule](images/intune-local-security-snapin-updated.png)
+
+10.	In the left pane, right-click on **AppLocker**, and then click **Export policy**.
+
+    The **Export policy** box opens, letting you export and save your new policy as XML.
+
+    ![Local security snap-in, showing the Export Policy option](images/intune-local-security-export.png)
+
+11.	In the **Export policy** box, browse to where the policy should be stored, give the policy a name, and then click **Save**.
+
+    The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
+
+    **Example XML file**<br>
+    This is the XML file that AppLocker creates for Microsoft Photos.
+
+    ```xml
+     <AppLockerPolicy Version="1">
+        <RuleCollection Type="Exe" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Msi" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Script" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Dll" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Appx" EnforcementMode="NotConfigured">
+            <FilePublisherRule Id="5e0c752b-5921-4f72-8146-80ad5f582110" Name="Microsoft.Windows.Photos, version 16.526.0.0 and above, from Microsoft Corporation" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
+                <Conditions>
+                    <FilePublisherCondition PublisherName="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" ProductName="Microsoft.Windows.Photos" BinaryName="*">
+                        <BinaryVersionRange LowSection="16.526.0.0" HighSection="*" />
+                    </FilePublisherCondition>
+                </Conditions>
+            </FilePublisherRule>
+        </RuleCollection>
+	</AppLockerPolicy>
+    ```
+12.	After you’ve created your XML file, you need to import it by using Microsoft Intune.
+
+**To import your Applocker policy file app rule using Microsoft Intune**
+1.	From the **App Rules** area, click **Add**.
+    
+    The **Add App Rule** box appears.
+
+        ![Microsoft Intune, Importing your AppLocker policy file using Intune](images/intune-add-applocker-xml-file.png)
+
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Allowed app list*.
+
+3.	Click **Allow** from the **Enterprise data protection mode** drop-down list.
+
+    Allow turns on EDP, helping to protect that app’s corporate data through the enforcement of EDP restrictions. Instructions for exempting an app are included in the [Exempt apps from EDP restrictions](#exempt-apps-from-edp-restrictions) section of this topic.
+
+4.	Pick **AppLocker policy file** from the **Rule template** drop-down list.
+
+    The box changes to let you import your AppLocker XML policy file.
+
+5.	Click **Import**, browse to your AppLocker XML file, click **Open**, and then click **OK** to close the **Add App Rule** box.
+
+    The file is imported and the apps are added to your **App Rules** list.
+
+#### Exempt apps from EDP restrictions
 If you're running into compatibility issues where your app is incompatible with EDP, but still needs to be used with enterprise data, you can exempt the app from the EDP restrictions. This means that your apps won't include auto-encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might leak.
 
-**To exempt an UWP app**
-
-1.  Follow the **Add a UWP app** steps in the [Add multiple apps to your enterprise data protection (EDP) Protected Apps list](add-apps-to-protected-list-using-custom-uri.md) topic, through to Step 11.
-
-2.  In the **OMA-URI** box at Step 12, type `./Vendor/MSFT/AppLocker/EnterpriseDataProtection/<your_enterprise_name>edpexempt/StoreApp EXE`.<p>Where **edpexempt** is added as a substring, making the app exempt.
-
-3.  Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad.
-
-4.  Copy the text that has a **Type** of Appx, within in the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
-
-    ``` 
-    <RuleCollection Type="Appx" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
-    ```
+**To exempt a store app, a desktop app, or an AppLocker policy file app rule**
+1.	From the **App Rules** area, click **Add**.
     
-5.  Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**.<p>After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your enterprise data protection (EDP) policy](deploy-edp-policy-using-intune.md) topic.
+    The **Add App Rule** box appears.
 
-**To exempt a Classic Windows application**
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Exempt apps list*.
 
-1.  Follow the **Add a Classic Windows application app** steps in the [Add multiple apps to your enterprise data protection (EDP) Protected Apps list](add-apps-to-protected-list-using-custom-uri.md) topic, through to Step 11.
+3.	Click **Exempt** from the **Enterprise data protection mode** drop-down list.
 
-2.  In the **OMA-URI** box at Step 12, type `./Vendor/MSFT/AppLocker/EnterpriseDataProtection/<your_enterprise_name>edpexempt/EXE`.<p>Where **edpexempt** is added as a substring, making the app exempt.
+    Be aware that when you exempt apps, they’re allowed to bypass the EDP restrictions and access your corporate data. To allow apps, see the [Add app rules to your policy](#add-app-rules-to-your-policy) section of this topic.
 
-3.  Open File Explorer, go to the location where you saved your new XML file, and open it using an XML editor, such as Notepad.
+4.	Fill out the rest of the app rule info, based on the type of rule you’re adding:
 
-4.  Copy the text that has a **Type** of EXE, within in the **RuleCollection** tags, and then go back to Intune and paste the text into the **Value** box of the **Add or edit OMA-URI Setting** box. For example:
+    - **Store app.** Follow the **Publisher** and **Product name** instructions in the [Add a store app rule to your policy](#add-a-store-app-rule-to-your-policy) section of this topic.
 
-    ``` 
-    <RuleCollection Type="Exe" EnforcementMode="Enabled"><your_xml_rules_here></RuleCollection>
-    ```
+    - **Desktop app.** Follow the **Publisher**, **Product name**, **Binary name**, and **Version** instructions in the [Add a desktop app rule to your policy](#add-a-desktop-app-rule-to-your-policy) section of this topic.
 
-5.  Click **OK** to close the **Add or edit OMA-URI Setting** box, and then click **Save Policy**.<p>After saving the policy, you’ll need to deploy it to your employee’s devices. For more info, see the [Deploy your enterprise data protection (EDP) policy](deploy-edp-policy-using-intune.md) topic.
+    - **AppLocker policy file.** Follow the **Import** instructions in the [Add an AppLocker policy file](#add-an-applocker-policy-file) section of this topic, using a list of exempted apps.
 
-## Manage the EDP protection level for your enterprise data
+5.	Click **OK**.
+
+### Manage the EDP protection mode for your enterprise data
 After you've added the apps you want to protect with EDP, you'll need to apply a management and protection mode.
 
-We recommend that you start with **Silent** or **Override** while verifying with a small group that you have the right apps on your **Protected Apps** list. After you're done, you can change to your final enforcement policy, either **Override** or **Block**.
-<table>
-    <tr>
-        <th>Mode</th>
-        <th>Description</th>
-    </tr>
-    <tr>
-        <td>Block</td>
-        <td>EDP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between other people and devices outside of your enterprise.</td>
-    </tr>
-    <tr>
-        <td>Override</td>
-        <td>EDP looks for inappropriate data sharing, warning employees if they do something deemed potentially unsafe. However, this management mode lets the employee override the policy and share the data, logging the action to your audit log, accessible through the [Reporting CSP](http://go.microsoft.com/fwlink/p/?LinkID=746459).</td>
-    </tr>
-    <tr>
-        <td>Silent</td>
-        <td>EDP runs silently, logging inappropriate data sharing, without blocking anything.</td>
-    </tr>
-    <tr>
-        <td>Off</td>
-        <td>EDP is turned off and doesn't help to protect or audit your data.<p>After you turn off EDP, an attempt is made to decrypt any closed EDP-tagged files on the locally attached drives.</td>
-    </tr>
-</table>
+We recommend that you start with **Silent** or **Override** while verifying with a small group that you have the right apps on your protected apps list. After you're done, you can change to your final enforcement policy, either **Override** or **Block**.
 
-![Microsoft Intune: Add the protection level for your Protected Apps list](images/intune-encryption-level.png)
+|Mode |Description |
+|-----|------------|
+|Block |EDP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between other people and devices outside of your enterprise.|
+|Override |EDP looks for inappropriate data sharing, warning employees if they do something deemed potentially unsafe. However, this management mode lets the employee override the policy and share the data, logging the action to your audit log, accessible through the [Reporting CSP](http://go.microsoft.com/fwlink/p/?LinkID=746459). |
+|Silent |EDP runs silently, logging inappropriate data sharing, without blocking anything that would’ve been prompted for employee interaction while in Override mode. Unallowed actions, like apps inappropriately trying to access a network resource or EDP-protected data, are still blocked.|
+|Off (not recommended) |EDP is turned off and doesn't help to protect or audit your data.<p>After you turn off EDP, an attempt is made to decrypt any closed EDP-tagged files on the locally attached drives.|
 
-## Define your enterprise-managed identity domains
-Specify your company’s enterprise identity, expressed as your primary internet domain. For example, if your company is Contoso, its enterprise identity might be contoso.com. The first listed domain (in this example, contoso.com) is the primary enterprise identity string used to tag files protected by any app on the **Protected App** list.
+![Microsoft Intune, Set the protection mode for your data](images/intune-protection-mode.png)
 
-You can also specify all the domains owned by your enterprise that are used for user accounts, separating them with the "|" character. For example, if Contoso also has some employees with email addresses or user accounts on the fabrikam.com domain, you would use contoso.com|fabrikam.com.
+### Define your enterprise-managed corporate identity
+Corporate identity, usually expressed as your primary Internet domain (for example, contoso.com), helps to identify and tag your corporate data from apps you’ve marked as protected by EDP. For example, emails using contoso.com are identified as being corporate and are restricted by your enterprise data protection policies.
 
-This list of managed identity domains, along with the primary domain, make up the identity of your managing enterprise. User identities (user@domain) that end in any of the domains on this list, are considered managed.
+You can specify multiple domains owned by your enterprise by separating them with the "|" character. For example, (`contoso.com|newcontoso.com`). With multiple domains, the first one is designated as your corporate identity and all of the additional ones as being owned by the first one. We strongly recommend that you include all of your email address domains in this list.
 
-**To add your primary domain**
+**To add your corporate identity**
+- Type the name of your corporate identity into the **Corporate identity** field. For example, `contoso.com` or `contoso.com|newcontoso.com`.
 
--   Type the name of your primary domain into the **Primary domain** field. For example, *contoso.com*.<p>
-If you have multiple domains, you must separate them with the "|" character. For example, `contoso.com|fabrikam.com`.
+    ![Microsoft Intune, Set your primary Internet domains](images/intune-corporate-identity.png)
 
-    ![Microsoft Intune: Add the primary internet domain for your enterprise identity](images/intune-primary-domain.png)
+### Choose where apps can access enterprise data
+After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise data on your network.
 
-## Choose where apps can access enterprise data
-After you've added a protection level to your apps, you'll need to decide where those apps can access enterprise data on your network. There are 6 options, including your network domain, cloud domain, proxy server, internal proxy server, IPv4 range, and IPv6 range.
+There are no default locations included with EDP, you must add each of your network locations. This area applies to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of your enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for example, on local NTFS, FAT, ExFAT).
 
 >**Important**<br>
--   Every EDP policy should include policy that defines your enterprise network locations.<p>
+- Every EDP policy should include policy that defines your enterprise network locations.<p>
 - Classless Inter-Domain Routing (CIDR) notation isn’t supported for EDP configurations.
 
-**To specify where your protected apps can find and send enterprise data on the network**
+**To define where your protected apps can find and send enterprise data on you network**
 
-1.  Add additional network locations your apps can access by clicking **Add**, typing a description into the **Description** box, and then choosing your location type, including:
+1. Add additional network locations your apps can access by clicking **Add**.
+
+    The **Add or edit corporate network definition** box appears.
+
+2.	Type a name for your corporate network element into the **Name** box, and then pick what type of network element it is, from the **Network element** drop-down box. This can include any of the options in the following table.
+
+    ![Microsoft Intune, Add your corporate network definitions](images/intune-networklocation.png)
+<p>
     <table>
-        <tr>
-            <th>Network location type</th>
-            <th>Format</th>
-            <th>Description</th>
-        </tr>
-        <tr>
-            <td>Enterprise Cloud Domain</td>
-            <td>contoso.sharepoint.com,proxy1.contoso.com|<br>office.com|proxy2.contoso.com</td>
-            <td>Specify the cloud resources traffic to restrict to your protected apps.<p>For each cloud resource, you may also specify an internal proxy server that routes your traffic from your **Enterprise Internal Proxy Server** policy. If you have multiple resources, you must use the &#x7C; delimiter.<p>Include the "," delimiter just before the "|" if you don’t use proxies. For example:<br> `[URL,Proxy]|[URL,Proxy]`</td>     
-        </tr>
-        <tr>
-            <td>Enterprise Network Domain</td>
-            <td>domain1.contoso.com,domain2.contoso.com</td>
-            <td>Specify the DNS suffix used in your environment. All traffic to the fully-qualified domains using this DNS suffix will be protected. If you have multiple resources, you must use the "," delimiter.<p>This setting works with the IP Ranges settings to detect whether a network endpoint is enterprise or personal on private networks.</td>                
-        </tr>
-        <tr>
-            <td>Enterprise Proxy Server</td>
-            <td>domain1.contoso.com:80;domain2.contoso.com:137</td>
-            <td>Specify the proxy server and the port traffic is routed through. If you have multiple resources, you must use the ";" delimiter.<p>This setting is required if you use a proxy in your network. If you don't have a proxy server, you might find that enterprise resources are unavailable when a client is behind a proxy, such as when using certain Wi-Fi hotspots at hotels and restaurants.</td>                
-        </tr>
-        <tr>
-            <td>Enterprise Internal Proxy Server</td>
-            <td>proxy1.contoso.com;proxy2.contoso.com</td>
-            <td>Specify the proxy servers your cloud resources will go through. If you have multiple resources, you must use the ";" delimiter.</td>                
-        </tr>
-        <tr>
-            <td>Enterprise IPv4 Range</td>
-            <td>**Starting IPv4 Address:** 3.4.0.1<br>**Ending IPv4 Address:** 3.4.255.254<br>**Custom URI:** 3.4.0.1-3.4.255.254,10.0.0.1-10.255.255.254</td>
-            <td>Specify the addresses for a valid IPv4 value range within your intranet.<p>If you are adding a single range, you can enter the starting and ending addresses into your management system’s UI. If you want to add multiple addresses, we suggest creating a Custom URI, using the "-" delimiter between start and end of a range, and the "," delimiter to separate ranges.</td>
-        </tr>
-        <tr>
-            <td>Enterprise IPv6 Range</td>
-            <td>**Starting IPv6 Address:** 2a01:110::<br>**Ending IPv6 Address:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff<br>**Custom URI:** 2a01:110::-2a01:110:7fff:ffff:ffff:ffff:ffff:ffff,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff</td>
-            <td>Specify the addresses for a valid IPv6 value range within your intranet.<p>If you are adding a single range, you can enter the starting and ending addresses into your management system’s UI. If you want to add multiple addresses, we suggest creating a Custom URI, using the "-" delimiter between start and end of a range, and the "," delimiter to separate ranges.</td>
-        </tr>                
-    </table>
+            <tr>
+                <th>Network location type</th>
+                <th>Format</th>
+                <th>Description</th>
+            </tr>
+            <tr>
+                <td>Enterprise Cloud Resources</td>
+                <td>**With proxy:** contoso.sharepoint.com,proxy.contoso.com|<br>contoso.visualstudio.com,proxy.contoso.com<p>**Without proxy:** contoso.sharepoint.com|contoso.visualstudio.com</td>
+                <td>Specify the cloud resources to be treated as corporate and protected by EDP.<p>For each cloud resource, you may also optionally specify an internal proxy server that routes your traffic through your Enterprise Internal Proxy Server.<p>If you have multiple resources, you must separate them using the "|" delimiter. If you don’t use proxy servers, you must also include the "," delimiter just before the "|". For example: `URL <,proxy>|URL <,proxy>`.<p>If Windows is unable to determine whether an app should be allowed to connect to a network resource, it will automatically block the connection. If instead you want Windows to allow the connections to happen, you can add the `/*AppCompat*/` string to this setting. For example: `URL <,proxy>|URL <,proxy>|/*AppCompat*/`</td>
+            </tr>
+            <tr>
+                <td>Enterprise Network Domain Names (Required)</td>
+                <td>corp.contoso.com,region.contoso.com</td>
+                <td>Specify the DNS suffixes used in your environment. All traffic to the fully-qualified domains appearing in this list will be protected.<p>This setting works with the IP ranges settings to detect whether a network endpoint is enterprise or personal on private networks.<p>If you have multiple resources, you must separate them using the "," delimiter.</td>                
+            </tr>
+            <tr>
+                <td>Enterprise Proxy Servers</td>
+                <td>proxy.contoso.com:80;proxy2.contoso.com:137</td>
+                <td>Specify your externally-facing proxy server addresses, along with the port through which traffic is allowed and protected with EDP.<p>This list shouldn’t include any servers listed in the Enterprise Internal Proxy Servers list, which are used for EDP-protected traffic.<p>This setting is also required if you use a proxy in your network. If you don't have a proxy server, you might find that enterprise resources are unavailable when a client is behind a proxy, such as when you’re visiting another company and not on that company’s guest network.<p>If you have multiple resources, you must separate them using the ";" delimiter.</td>
+            </tr>
+            <tr>
+                <td>Enterprise Internal Proxy Servers</td>
+                <td>contoso.internalproxy1.com;contoso.internalproxy2.com</td>
+                <td>Specify the proxy servers your devices will go through to reach your cloud resources.<p>Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.<p>This list shouldn’t include any servers listed in the Enterprise Proxy Servers list, which are used for non-EDP-protected traffic.<p>If you have multiple resources, you must separate them using the ";" delimiter.</td>                
+            </tr>
+            <tr>
+                <td>Enterprise IPv4 Range (Required, if not using IPv6)</td>
+                <td>**Starting IPv4 Address:** 3.4.0.1<br>**Ending IPv4 Address:** 3.4.255.254<br>**Custom URI:** 3.4.0.1-3.4.255.254,<br>10.0.0.1-10.255.255.254</td>
+                <td>Specify the addresses for a valid IPv4 value range within your intranet. These addresses, used with your Enterprise Network Domain Names, define your corporate network boundaries.<p>If you have multiple ranges, you must separate them using the "," delimiter.</td>
+            </tr>
+            <tr>
+                <td>Enterprise IPv6 Range (Required, if not using IPv4)</td>
+                <td>**Starting IPv6 Address:** 2a01:110::<br>**Ending IPv6 Address:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff<br>**Custom URI:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff,<br>fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff</td>
+                <td>Specify the addresses for a valid IPv6 value range within your intranet. These addresses, used with your Enterprise Network Domain Names, define your corporate network boundaries.<p>If you have multiple ranges, you must separate them using the "," delimiter.</td>
+            </tr>
+            <tr>
+                <td>Neutral Resources</td>
+                <td>sts.contoso.com,sts.contoso2.com</td>
+                <td>Specify your authentication redirection endpoints for your company.<p>These locations are considered enterprise or personal, based on the context of the connection before the redirection.<p>If you have multiple resources, you must separate them using the "," delimiter.</td>
+            </tr>           
+        </table>
 
-    ![Microsoft Intune: Choose the primary domain and the other network locations for protected apps](images/intune-networklocation.png)
+3.	Add as many locations as you need, and then click **OK**.
 
-2.  Add as many locations as you need, and then click **OK**.<p>The **Add or Edit Enterprise Network Locations box** closes.
+    The **Add corporate network definition** box closes.
 
-3.  In the **Use a data recovery certificate in case of data loss** box, click **Browse** to add a data recovery certificate for your policy.<p>Adding a data recovery certificate helps you to access locally-protected files on the device. For example, if an employee leaves the company and the IT department has to access EDP-protected data from a Windows 10 company computer. This can also help recover data in case an employee's device is accidentally revoked. For more info about how to find and export your data recovery certificate, see the [Data Recovery and Encrypting File System (EFS)](http://go.microsoft.com/fwlink/p/?LinkId=761462) topic.<p>
+4. Decide if you want to Windows to look for additional network settings:
 
-    ![Microsoft Intune: Specify a data recovery certificate for your policy](images/intune-data-recovery.png)
+    - **Enterprise Proxy Servers list is authoritative (do not auto-detect).** Click this box if you want Windows to treat the proxy servers you specified in the network boundary definition as the complete list of proxy servers available on your network. If you clear this box, Windows will search for additional proxy servers in your immediate network.
 
-## Choose your optional EDP-related settings
+	- **Enterprise IP Ranges list is authoritative (do not auto-detect).** Click this box if you want Windows to treat the IP ranges you specified in the network boundary definition as the complete list of IP ranges available on your network. If you clear this box, Windows will search for additional IP ranges on any domain-joined devices connected to your network.
+
+	- **Show the enterprise data protection icon overlay on your allowed apps that are EDP-unaware in the Windows Start menu and on corporate file icons in the File Explorer.** Click this box if you want the enterprise data protection icon overlay to appear on corporate files or in the Start menu, on top the tiles for your unenlightened protected apps.
+
+5.	In the required **Upload a Data Recovery Agent (DRA) certificate to allow recovery of encrypted data** box, click **Browse** to add a data recovery certificate for your policy.
+
+       ![Microsoft Intune, Add your Data Recovery Agent (DRA) certificate](images/intune-data-recovery.png)
+
+    After you create and deploy your EDP policy to your employees, Windows will begin to encrypt your corporate data on the employees’ local device drive. If somehow the employees’ local encryption keys get lost or revoked, the encrypted data can become unrecoverable. To help avoid this possibility, the DRA certificate lets Windows use an included public key to encrypt the local data, while you maintain the private key that can unencrypt the data.
+
+    For more info about how to find and export your data recovery certificate, see the [Data Recovery and Encrypting File System (EFS)](http://go.microsoft.com/fwlink/p/?LinkId=761462) topic.
+
+#### Create and verify an Encrypting File System (EFS) DRA certificate for EDP
+If you don’t already have an EFS DRA certificate, you’ll need to create and extract one from your system before you can use EDP in your organization. For the purposes of this section, we’ll use the file name *EFSDRA*; however, this name can be replaced with anything that makes sense to you.
+
+>**Important**<br>If you already have an EFS DRA certificate for your organization, you can skip creating a new one. Just use your current EFS DRA certificate in your policy.
+
+**To manually create an EFS DRA certificate**
+1. On a computer without an EFS DRA certificate installed, open a command prompt with elevated rights, and then navigate to where you want to store the certificate.
+
+2. Run this command:
+    
+    `cipher /r:<EFSDRA>`<br>Where `<EFSDRA>` is the name of the .cer and .pfx files that you want to create.
+
+3. When prompted, type and confirm a password to help protect your new Personal Information Exchange (.pfx) file.
+
+    The EFSDRA.cer and EFSDRA.pfx files are created in the location you specified in Step 1. 
+
+    >**Important**<br>Because these files can be used to decrypt any EDP file, you must protect them accordingly. We highly recommend storing them as a public key (PKI) on a smart card with strong protection, stored in a secured physical location.
+
+4.	Add your EFS DRA certificate to your EDP policy by using Step 3 of the [Choose where apps can access enterprise data](#choose-where-apps-can-access-enterprise-data) section of this topic.
+
+**To verify your data recovery certificate is correctly set up on an EDP client computer**
+1.	Open an app on your protected app list, and then create and save a file so that it’s encrypted by EDP.
+
+2.	Open a command prompt with elevated rights, navigate to where you stored the file you just created, and then run this command:
+
+    `cipher /c <filename>`<br>Where `<filename>` is the name of the file you created in Step 1.
+
+3.	Make sure that your data recovery certificate is listed in the **Recovery Certificates** list.
+
+**To recover your data using the EFS DRA certificate in a test environment**
+1.	Copy your EDP-encrypted file to a location where you have admin access.
+
+2.	Install the EFSDRA.pfx file, using your password.
+
+3.	Open a command prompt with elevated rights, navigate to the encrypted file, and then run this command:
+
+    `cipher /d <encryptedfile.extension>`<br>Where `<encryptedfile.extension>` is the name of your encrypted file. For example, corporatedata.docx.
+
+### Choose your optional EDP-related settings
 After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to decide if you want to add any optional EDP settings.
 
-**To add your optional settings**
+![Microsoft Intune, Choose any additional, optional settings](images/intune-optional-settings.png)
 
-1.  Choose to set any or all of the optional EDP-related settings:
+**To set your optional settings**
+1.	Choose to set any or all of the optional settings:
 
-    -   **Allow the user to decrypt data that was created or edited by the apps configured above.** Clicking **Yes**, or turning off this setting in Intune, lets your employees right-click to decrypt their protected app data, along with the option to decrypt data in the **Save As** box and the **Save As** file picker . Clicking **No** removes the **Decrypt** option and saves all data for protected apps as enterprise-encrypted.
+    - **Show the Personal option in the File ownership menus of File Explorer and the Save As dialog box.** Determines whether users can see the Personal option for files within File Explorer and the **Save As** dialog box. The options are:
+    
+        - **Yes, or not configured (recommended).** Employees can choose whether a file is **Work** or **Personal** in File Explorer and the **Save As** dialog box. 
+	
+        - **No.** Hides the **Personal** option from employees. Be aware that if you pick this option, apps that use the **Save As** dialog box might encrypt new files as corporate data unless a different file path is given during the original file creation. After this happens, decryption of work files becomes more difficult.
 
-    -   **Protect app content when the device is in a locked state for the apps configured above.** Clicking **Yes** lets EDP help to secure protected app content when a mobile device is locked. We recommend turning this option on to help prevent data leaks from things such as email text that appears on the **Lock** screen of a Windows 10 Mobile phone.
+    - **Prevent corporate data from being accessed by apps when the device is locked. Applies only to Windows 10 Mobile**. Determines whether apps can show corporate data on a Windows 10 Mobile device **Lock** screen. The options are:
+	
+        - **Yes (recommended).** Stop apps from reading corporate data on Windows 10 Mobile device when the screen is locked.
+	
+        - **No, or not configured.**  Allows apps to read corporate data on Windows 10 Mobile device when the screen is locked.
 
-        ![Microsoft Intune: Optional EDP settings](images/intune-edpsettings.png)
+    - **Revoke encryption keys on unenroll.** Determines whether to revoke a user’s local encryption keys from a device when it’s unenrolled from enterprise data protection. If the encryption keys are revoked, a user no longer has access to encrypted corporate data. The options are:
 
-2.  Click **Save Policy**.
+        - **Yes, or not configured (recommended).** Revokes local encryption keys from a device during unenrollment.
+        
+        - **No.** Stop local encryption keys from being revoked from a device during unenrollment. For example, if you’re migrating between Mobile Device Management (MDM) solutions.
+
+    - **Allow Windows Search to search encrypted corporate data and Store apps.** Determines whether Windows Search can search and index encrypted corporate data and Store apps. The options are:
+
+	    - **Yes.** Allows Windows Search to search and index encrypted corporate data and Store apps.
+
+	    - **No, or not configured (recommended).** Stops Windows Search from searching and indexing encrypted corporate data and Store apps.
+
+    - **Show the enterprise data protection icon overlay.** Determines whether the enterprise data protection icon overlay appears on corporate files or in the **Start** menu, on top of the tiles for your unenlightened protected apps. The options are:
+
+    	- **Yes (recommended).** Allows the enterprise data protection icon overlay to appear for files or on top of the tiles for your unenlightened protected apps in the **Start** menu.
+
+	    - **No, or not configured.** Stops the enterprise data protection icon overlay from appearing for files or on top of the tiles for your unenlightened protected apps in the **Start** menu.
+
+2. Click **Save Policy**.
 
 ## Related topics
 - [Add multiple apps to your enterprise data protection (EDP) Protected Apps list](add-apps-to-protected-list-using-custom-uri.md)
 - [Deploy your enterprise data protection (EDP) policy](deploy-edp-policy-using-intune.md)
 - [Create and deploy a VPN policy for enterprise data protection (EDP) using Microsoft Intune](create-vpn-and-edp-policy-using-intune.md)
-- [General guidance and best practices for enterprise data protection (EDP)](guidance-and-best-practices-edp.md)
-
-
-
- 
-
- 
-
-
-
-
-
+- [General guidance and best practices for enterprise data protection (EDP)](guidance-and-best-practices-edp.md)
\ No newline at end of file
diff --git a/windows/keep-secure/create-edp-policy-using-sccm.md b/windows/keep-secure/create-edp-policy-using-sccm.md
index fa412028a7..ee26d44b41 100644
--- a/windows/keep-secure/create-edp-policy-using-sccm.md
+++ b/windows/keep-secure/create-edp-policy-using-sccm.md
@@ -1,6 +1,6 @@
 ---
 title: Create and deploy an enterprise data protection (EDP) policy using System Center Configuration Manager (Windows 10)
-description: Configuration Manager (version 1511 or later) helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
+description: Configuration Manager (version 1606 or later) helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
 ms.assetid: 85b99c20-1319-4aa3-8635-c1a87b244529
 keywords: EDP, Enterprise Data Protection, SCCM, System Center Configuration Manager, Configuration Manager
 ms.prod: w10
@@ -15,28 +15,14 @@ author: eross-msft
 
 -   Windows 10 Insider Preview
 -   Windows 10 Mobile Preview
--   System Center Configuration Manager (version 1511 or later)
+-   System Center Configuration Manager (version 1605 Tech Preview or later)
 
 <span style="color:#ED1C24;">[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
 
-Configuration Manager (version 1511 or later) helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
+System Center Configuration Manager (version 1605 Tech Preview or later) helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection mode, and how to find enterprise data on the network.
 
-## In this topic:
--   [Add an EDP policy](#add-an-edp-policy)
-
--   [Choose which apps can access your enterprise data](#choose-which-apps-can-access-your-enterprise-data)
-
--   [Manage the EDP protection level for your enterprise data](#manage-the-edp-protection-level-for-your-enterprise-data)
-
--   [Define your enterprise-managed identity domains](#define-your-enterprise-managed-identity-domains)
-
--   [Choose where apps can access enterprise data](#choose-where-apps-can-access-enterprise-data)
-
--   [Choose your optional EDP-related settings](#choose-your-optional-EDP-related-settings)
-
--   [Review your configuration choices in the Summary screen](#review-your-configuration-choices-in-the-summary-screen)
-
--   [Deploy the EDP policy](#deploy-the-edp-policy)
+>**Important**<br>
+If you previously created an EDP policy using System Center Configuration Manager version 1511 or 1602, you’ll need to recreate it using version 1605 Tech Preview or later. Editing an EDP policy created in version 1511 or 1602 is not supported in version 1605 Tech Preview. There is no migration path between EDP policies across these versions.
 
 ## Add an EDP policy
 After you’ve installed and set up System Center Configuration Manager for your organization, you must create a configuration item for EDP, which in turn becomes your EDP policy.
@@ -66,60 +52,124 @@ The **Create Configuration Item Wizard** starts.
 
     ![Create Configuration Item wizard, choose the supported platforms for the policy](images/edp-sccm-supportedplat.png)
 
-6.  On the **Device Settings** screen, click **Enterprise Data Protection**, and then click **Next**.
+6.  On the **Device Settings** screen, click **Enterprise data protection**, and then click **Next**.
 
     ![Create Configuration Item wizard, choose the enterprise data protection settings](images/edp-sccm-devicesettings.png)
 
-The **Configure Enterprise Data Protection settings** page appears, where you'll configure your policy for your organization.
+The **Configure enterprise data protection settings** page appears, where you'll configure your policy for your organization.
 
-## Choose which apps can access your enterprise data
-During the policy-creation process in Configuration Manager, you can choose the apps you want to give access to your enterprise data through EDP. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps or unprotected network locations.
+### Add app rules to your policy
+During the policy-creation process in System Center Configuration Manager, you can choose the apps you want to give access to your enterprise data through EDP. Apps included in this list can protect data on behalf of the enterprise and are restricted from copying or moving enterprise data to unprotected apps.
 
-The steps to add your apps are based on the type of app it is; either a Universal Windows Platform (UWP) app, or a signed Classic Windows application.
+The steps to add your app rules are based on the type of rule template being applied. You can add a store app (also known as a Universal Windows Platform (UWP) app), a signed desktop app (also known as a Classic Windows app), or an AppLocker policy file.
 
-**Important**<br>EDP-aware apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, EDP-unaware apps might not respect the corporate network boundary and will encrypt all files they create or modify, meaning that they could encrypt personal data and cause data leaks during the revocation process. Care must be taken to get a support statement from the software provider that their app is safe with EDP before adding it to your **Protected App** list.
+>**Important**<br>
+EDP-aware apps are expected to prevent enterprise data from going to unprotected network locations and to avoid encrypting personal data. On the other hand, EDP-unaware apps might not respect the corporate network boundary, and EDP-unaware apps will encrypt all files they create or modify. This means that they could encrypt personal data and cause data loss during the revocation process. <p>Care must be taken to get a support statement from the software provider that their app is safe with EDP before adding it to your **App rules** list. If you don’t get this statement, it’s possible that you could experience app compat issues due to an app losing the ability to access a necessary file after revocation.
 
-**To add a UWP app**
+#### Add a store app rule to your policy
+For this example, we’re going to add Microsoft OneNote, a store app, to the **App Rules** list.
 
-1.  From the **Configure the following apps to be protected by EDP** table in the **Protected Apps** area, click **Add.**
+**To add a store app**
 
-2.  Click **Universal App**, type the **Publisher Name** and the **Product Name** into the associated boxes, and then click **OK**. If you don't have the publisher or product name, you can find them by following these steps.
+1.	From the **App rules** area, click **Add**.
+    
+    The **Add app rule** box appears.
 
-    **To find the Publisher and Product name values for Microsoft Store apps without installing them**
+    ![Create Configuration Item wizard, add a universal store app](images/edp-sccm-adduniversalapp.png)
 
-    1.  Go to the [Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkID=722910) website, and find your app. For example, Microsoft OneNote.
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Microsoft OneNote*.
 
-    2.  Copy the ID value from the app URL. For example, Microsoft OneNote's ID URL is https://www.microsoft.com/store/apps/onenote/9wzdncrfhvjl, and you'd copy the ID value, `9wzdncrfhvjl`.
+3.	Click **Allow** from the **Enterprise data protection mode** drop-down list.
 
-    3.  In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON) file that includes the publisher and product name values. For example, run https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/*9wzdncrfhvjl*/applockerdata, where *9wzdncrfhvjl* is replaced with your ID value.
+    Allow turns on EDP, helping to protect that app’s corporate data through the enforcement of EDP restrictions. If you want to exempt an app, you can follow the steps in the [Exempt apps from EDP restrictions](#exempt-apps-from-edp) section.
 
-        The API runs and opens a text editor with the app details.
+4.	Pick **Store App** from the **Rule template** drop-down list.
 
-        ``` json
+    The box changes to show the store app rule options.
+
+5.	Type the name of the app and the name of its publisher, and then click **OK**. For this UWP app example, the **Publisher** is `CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US` and the **Product name** is `Microsoft.Office.OneNote`.
+
+If you don't know the publisher or product name, you can find them for both desktop devices and Windows 10 Mobile phones by following these steps.
+
+**To find the Publisher and Product Name values for Store apps without installing them**
+
+1.	Go to the [Windows Store for Business](http://go.microsoft.com/fwlink/p/?LinkID=722910) website, and find your app. For example, Microsoft OneNote.
+
+    >**Note**<br>
+    If your app is already installed on desktop devices, you can use the AppLocker local security policy MMC snap-in to gather the info for adding the app to the protected apps list. For info about how to do this, see the steps in the [Add an AppLocker policy file](#add-an-applocker-policy-file) section.
+
+2.	Copy the ID value from the app URL. For example, Microsoft OneNote's ID URL is https://www.microsoft.com/store/apps/onenote/9wzdncrfhvjl, and you'd copy the ID value, `9wzdncrfhvjl`.
+
+3.	In a browser, run the Store for Business portal web API, to return a JavaScript Object Notation (JSON) file that includes the publisher and product name values. For example, run https://bspmts.mp.microsoft.com/v1/public/catalog/Retail/Products/9wzdncrfhvjl/applockerdata, where `9wzdncrfhvjl` is replaced with your ID value.
+
+    The API runs and opens a text editor with the app details.
+
+    ``` json
         {
-          "packageIdentityName": "Microsoft.Office.OneNote",
-          "publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
+        "packageIdentityName": "Microsoft.Office.OneNote",
+        "publisherCertificateName": "CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US"
+        }
+    ```
+
+4.  Copy the `publisherCertificateName` value and paste them into the **Publisher Name** box, copy the `packageIdentityName` value into the **Product Name** box of Intune.
+
+    >**Important**<br>
+    The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as “CN=” followed by the `windowsPhoneLegacyId`.<p>For example:
+       ```json
+        {
+            "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
         }
         ```
 
-    4.  Copy the `publisherCertificateName` value and paste them into the **Publisher Name** box, copy the `packageIdentityName` value into the **Product Name** box of the **Add app** box, and then click **OK**.
-    <p>**Important**<br>If you don’t see the **Product Name** box, it could mean that your tenant is not on the latest build and that you need to wait until it's upgraded. Same applies if you see the **AppId** box. The **AppId** box has been removed in the latest build and should disappear (along with any entries) when your tenant is upgraded.
-    <p>**Important**<br>The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as “CN=” followed by the `windowsPhoneLegacyId`.<p>For example:<br>    
+**To find the Publisher and Product Name values for apps installed on Windows 10 mobile phones**
+1.	If you need to add mobile apps that aren't distributed through the Store for Business, you must use the **Windows Device Portal** feature.
 
-        ```
+    >**Note**<br>
+    Your PC and phone must be on the same wireless network.
+
+2.	On the Windows Phone, go to **Settings**, choose **Update & security**, and then choose **For developers**.
+
+3.	On the **For developers** screen, turn on **Developer mode**, turn on **Device Discovery**, and then turn on **Device Portal**.
+
+4.	Copy the URL in the **Device Portal** area into your device's browser, and then accept the SSL certificate.
+
+5.	In the **Device discovery** area, press **Pair**, and then enter the PIN into the website from the previous step.
+
+6.	On the **Apps** tab of the website, you can see details for the running apps, including the publisher and product names.
+
+7.	Start the app for which you're looking for the publisher and product name values.
+
+8.	Copy the `publisherCertificateName` value and paste it into the **Publisher Name** box and the `packageIdentityName` value into the **Product Name** box of Intune.
+
+    >**Important**<br>
+    The JSON file might also return a `windowsPhoneLegacyId` value for both the **Publisher Name** and **Product Name** boxes. This means that you have an app that’s using a XAP package and that you must set the **Product Name** as `windowsPhoneLegacyId`, and set the **Publisher Name** as “CN=” followed by the `windowsPhoneLegacyId`.<p>For example:
+       ```json
         {
-          "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
+            "windowsPhoneLegacyId": "ca05b3ab-f157-450c-8c49-a1f127f5e71d",
         }
         ```
 
-        ![Create Configuration Item wizard, add a Universal Windows Platform (UWP) app](images/edp-sccm-adduniversalapp.png)
+#### Add a desktop app rule to your policy
+For this example, we’re going to add Internet Explorer, a desktop app, to the **App Rules** list.
 
-**To add a Classic Windows application**
+**To add a desktop app to your policy**
+1.	From the **App rules** area, click **Add**.
+    
+    The **Add app rule** box appears.
 
-1.  From the **Configure the following apps to be protected by EDP** table in the **Protected Apps** area, click **Add.**
-<p>A dialog box appears, letting you pick whether the app is a **Universal App** or a **Desktop App**.
+    ![Create Configuration Item wizard, add a classic desktop app](images/edp-sccm-adddesktopapp.png)
 
-2.  Click **Desktop App**, pick the options you want (see table), and then click **OK**.
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Internet Explorer*.
+
+3.	Click **Allow** from the **Enterprise data protection mode** drop-down list.
+
+    Allow turns on EDP, helping to protect that app’s corporate data through the enforcement of EDP restrictions. If you want to exempt an app, you can follow the steps in the [Exempt apps from EDP restrictions](#exempt-apps-from-edp) section.
+
+4.	Pick **Desktop App** from the **Rule template** drop-down list.
+
+    The box changes to show the desktop app rule options.
+
+5.	Pick the options you want to include for the app rule (see table), and then click **OK**.
 
     <table>
         <tr>
@@ -139,21 +189,21 @@ The steps to add your apps are based on the type of app it is; either a Universa
             <td>All files for the specified product, signed by the named publisher.</td>
         </tr>
         <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, and <strong>File Name</strong> selected</td>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, and <strong>Binary name</strong> selected</td>
             <td>Any version of the named file or package for the specified product, signed by the named publisher.</td>
         </tr>
         <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>File Name</strong>, and <strong>File Version, Exactly</strong>, selected</td>
-            <td>Specified version of the named file or package for the specified product, signed by the named publisher.</td>
-        </tr>
-        <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>File Name</strong>, and <strong>File Version, And above</strong> selected</td>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>Binary name</strong>, and <strong>File Version, and above</strong>, selected</td>
             <td>Specified version or newer releases of the named file or package for the specified product, signed by the named publisher.<p>This option is recommended for enlightened apps that weren't previously enlightened.</td>
         </tr>
         <tr>
-            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>File Name</strong>, and <strong>File Version, And below</strong> selected</td>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>Binary name</strong>, and <strong>File Version, And below</strong> selected</td>
             <td>Specified version or older releases of the named file or package for the specified product, signed by the named publisher.</td>
         </tr>
+        <tr>
+            <td><strong>Publisher</strong>, <strong>Product Name</strong>, <strong>Binary name</strong>, and <strong>File Version, Exactly</strong> selected</td>
+            <td>Specified version of the named file or package for the specified product, signed by the named publisher.</td>
+        </tr>
     </table>
 
 If you’re unsure about what to include for the publisher, you can run this PowerShell command:
@@ -172,43 +222,166 @@ Path                   Publisher
 ```
 Where the text, `O=MICROSOFT CORPORATION, L=REDMOND, S=WASHINGTON, C=US` is the publisher name to enter in the **Publisher Name** box.
 
-![Create Configuration Item wizard, add a Classic Windows app](images/edp-sccm-adddesktopapp.png)
+#### Add an AppLocker policy file
+For this example, we’re going to add an AppLocker XML file to the **App Rules** list. You’ll use this option if you want to add multiple apps at the same time. For more info about AppLocker, see the [AppLocker](https://technet.microsoft.com/en-us/itpro/windows/keep-secure/applocker-overview) content.
 
-## Manage the EDP-protection level for your enterprise data
-After you've added the apps you want to protect with EDP, you'll need to apply an app management mode.
+**To create an app rule and xml file using the AppLocker tool**
+1.	Open the Local Security Policy snap-in (SecPol.msc).
+    
+2.	In the left pane, expand **Application Control Policies**, expand **AppLocker**, and then click **Packaged App Rules**.
 
-We recommend that you start with **Silent** or **Override** while verifying with a small group that you have the right apps on your **Protected Apps** list. After you're done, you can change to your final enforcement policy, either **Override** or **Block**.
+    ![Local security snap-in, showing the Packaged app Rules](images/intune-local-security-snapin.png)
+
+3.	Right-click in the right-hand pane, and then click **Create New Rule**.
+
+    The **Create Packaged app Rules** wizard appears.
+
+4. On the **Before You Begin** page, click **Next**.
+
+    ![Create Packaged app Rules wizard, showing the Before You Begin page](images/intune-applocker-before-begin.png)
+
+5. On the **Permissions** page, make sure the **Action** is set to **Allow** and the **User or group** is set to **Everyone**, and then click **Next**.
+
+    ![Create Packaged app Rules wizard, showing the Before You Begin page](images/intune-applocker-permissions.png)
+
+6.	On the **Publisher** page, click **Select** from the **Use an installed packaged app as a reference** area.
+
+    ![Create Packaged app Rules wizard, showing the Publisher](images/intune-applocker-publisher.png)
+
+7. In the **Select applications** box, pick the app that you want to use as the reference for your rule, and then click **OK**. For this example, we’re using Microsoft Photos.
+
+    ![Create Packaged app Rules wizard, showing the Select applications page](images/intune-applocker-select-apps.png)
+
+8. On the updated **Publisher** page, click **Create**.
+
+    ![Create Packaged app Rules wizard, showing the Microsoft Photos on the Publisher page](images/intune-applocker-publisher-with-app.png)
+
+9. Review the Local Security Policy snap-in to make sure your rule is correct.
+
+    ![Local security snap-in, showing the new rule](images/intune-local-security-snapin-updated.png)
+
+10.	In the left pane, right-click on **AppLocker**, and then click **Export policy**.
+
+    The **Export policy** box opens, letting you export and save your new policy as XML.
+
+    ![Local security snap-in, showing the Export Policy option](images/intune-local-security-export.png)
+
+11.	In the **Export policy** box, browse to where the policy should be stored, give the policy a name, and then click **Save**.
+
+    The policy is saved and you’ll see a message that says 1 rule was exported from the policy.
+
+    **Example XML file**<br>
+    This is the XML file that AppLocker creates for Microsoft Photos.
+
+    ```xml
+     <AppLockerPolicy Version="1">
+        <RuleCollection Type="Exe" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Msi" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Script" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Dll" EnforcementMode="NotConfigured" />
+        <RuleCollection Type ="Appx" EnforcementMode="NotConfigured">
+            <FilePublisherRule Id="5e0c752b-5921-4f72-8146-80ad5f582110" Name="Microsoft.Windows.Photos, version 16.526.0.0 and above, from Microsoft Corporation" Description="" UserOrGroupSid="S-1-1-0" Action="Allow">
+                <Conditions>
+                    <FilePublisherCondition PublisherName="CN=Microsoft Corporation, O=Microsoft Corporation, L=Redmond, S=Washington, C=US" ProductName="Microsoft.Windows.Photos" BinaryName="*">
+                        <BinaryVersionRange LowSection="16.526.0.0" HighSection="*" />
+                    </FilePublisherCondition>
+                </Conditions>
+            </FilePublisherRule>
+        </RuleCollection>
+	</AppLockerPolicy>
+    ```
+12. After you’ve created your XML file, you need to import it by using System Center Configuration Manager.
+
+**To import your Applocker policy file app rule using 1System Center Configuration Manager**
+1.	From the **App rules** area, click **Add**.
+    
+    The **Add app rule** box appears.
+
+    ![Create Configuration Item wizard, add an AppLocker policy](images/edp-sccm-addapplockerfile.png)
+
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Allowed app list*.
+
+3.	Click **Allow** from the **Enterprise data protection mode** drop-down list.
+
+    Allow turns on EDP, helping to protect that app’s corporate data through the enforcement of EDP restrictions. If you want to exempt an app, you can follow the steps in the [Exempt apps from EDP restrictions](#exempt-apps-from-edp) section.
+
+4.	Pick the **AppLocker policy file** from the **Rule template** drop-down list.
+
+    The box changes to let you import your AppLocker XML policy file.
+
+5. Click the ellipsis (...) to browse for your AppLocker XML file, click **Open**, and then click **OK** to close the **Add app rule** box.
+
+    The file is imported and the apps are added to your **App Rules** list.
+
+#### Exempt apps from EDP restrictions
+If you're running into compatibility issues where your app is incompatible with EDP, but still needs to be used with enterprise data, you can exempt the app from the EDP restrictions. This means that your apps won't include auto-encryption or tagging and won't honor your network restrictions. It also means that your exempted apps might leak.
+
+**To exempt a store app, a desktop app, or an AppLocker policy file app rule**
+
+1.	From the **App rules** area, click **Add**.
+    
+    The **Add app rule** box appears.
+
+2.	Add a friendly name for your app into the **Title** box. In this example, it’s *Exempt apps list*.
+
+3.	Click **Exempt** from the **Enterprise data protection mode** drop-down list.
+
+    Be aware that when you exempt apps, they’re allowed to bypass the EDP restrictions and access your corporate data. To allow apps, see the [Add app rules to your policy](#add-app-rules-to-your-policy) section of this topic.
+
+4.	Fill out the rest of the app rule info, based on the type of rule you’re adding:
+
+    - **Store app.** Follow the **Publisher** and **Product name** instructions in the [Add a store app rule to your policy](#add-a-store-app-rule-to-your-policy) section of this topic.
+
+    - **Desktop app.** Follow the **Publisher**, **Product name**, **Binary name**, and **Version** instructions in the [Add a desktop app rule to your policy](#add-a-desktop-app-rule-to-your-policy) section of this topic.
+
+    - **AppLocker policy file.** Follow the **Import** instructions in the [Add an AppLocker policy file](#add-an-applocker-policy-file) section of this topic, using a list of exempted apps.
+
+5.	Click **OK**.
+
+### Manage the EDP-protection level for your enterprise data
+After you've added the apps you want to protect with EDP, you'll need to apply a management and protection mode.
+
+We recommend that you start with **Silent** or **Override** while verifying with a small group that you have the right apps on your protected apps list. After you're done, you can change to your final enforcement policy, either **Override** or **Block**.
 
 |Mode |Description |
 |-----|------------|
-|Block |EDP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between other people and devices outside of your enterprise. |
+|Block |EDP looks for inappropriate data sharing practices and stops the employee from completing the action. This can include sharing info across non-enterprise-protected apps in addition to sharing enterprise data between other people and devices outside of your enterprise.|
 |Override |EDP looks for inappropriate data sharing, warning employees if they do something deemed potentially unsafe. However, this management mode lets the employee override the policy and share the data, logging the action to your audit log, accessible through the [Reporting CSP](http://go.microsoft.com/fwlink/p/?LinkID=746459). |
-|Silent |EDP runs silently, logging inappropriate data sharing, without blocking anything. |
-|Off (not recommended) |EDP is turned off and doesn't help to protect or audit your data.
-<p>After you turn off EDP, an attempt is made to decrypt any closed EDP-tagged files on the locally attached drives. |
+|Silent |EDP runs silently, logging inappropriate data sharing, without blocking anything that would’ve been prompted for employee interaction while in Override mode. Unallowed actions, like apps inappropriately trying to access a network resource or EDP-protected data, are still blocked.|
+|Off (not recommended) |EDP is turned off and doesn't help to protect or audit your data.<p>After you turn off EDP, an attempt is made to decrypt any closed EDP-tagged files on the locally attached drives.|
 
 ![Create Configuration Item wizard, choose your EDP-protection level](images/edp-sccm-appmgmt.png)
 
-## Define your enterprise-managed identity domains
-Specify your company’s enterprise identity, expressed as your primary internet domain. For example, if your company is Contoso, its enterprise identity might be contoso.com. The first listed domain (in this example, contoso.com) is the primary enterprise identity string used to tag files protected by any app on the **Protected App** list.
+### Define your enterprise-managed identity domains
+Corporate identity, usually expressed as your primary internet domain (for example, contoso.com), helps to identify and tag your corporate data from apps you’ve marked as protected by EDP. For example, emails using contoso.com are identified as being corporate and are restricted by your enterprise data protection policies.
 
-You can also specify all the domains owned by your enterprise that are used for user accounts, separating them with the "|" character. For example, if Contoso also has some employees with email addresses or user accounts on the fabrikam.com domain, you would use contoso.com|fabrikam.com.
+You can specify multiple domains owned by your enterprise by separating them with the "|" character. For example, (contoso.com|newcontoso.com). With multiple domains, the first one is designated as your corporate identity and all of the additional ones as being owned by the first one. We strongly recommend that you include all of your email address domains in this list.
 
-This list of managed identity domains, along with the primary domain, make up the identity of your managing enterprise. User identities (user@domain) that end in any of the domains on this list, are considered managed.
+**To add your corporate identity**
 
-![Create Configuration Item wizard, Add the primary Internet domain for your enterprise identity](images/sccm-primary-domain.png)
+- Type the name of your corporate identity into the **Corporate identity** field. For example, `contoso.com` or `contoso.com|newcontoso.com`.
 
-**To add your primary domain**
+    ![Create Configuration Item wizard, Add the primary Internet domain for your enterprise identity](images/edp-sccm-corp-identity.png)
 
--   Type the name of your primary domain into the **Primary domain** field. For example, *contoso.com*.<p>
-If you have multiple domains, you must separate them with the "|" character. For example, contoso.com|fabrikam.com.
+### Choose where apps can access enterprise data
+After you've added a protection mode to your apps, you'll need to decide where those apps can access enterprise data on your network.
 
-## Choose where apps can access enterprise data
-After you've added a management level to your protected apps, you'll need to decide where those apps can access enterprise data on your network. There are 6 options, including your network domain, cloud domain, proxy server, internal proxy server, IPv4 range, and IPv6 range.
+There are no default locations included with EDP, you must add each of your network locations. This area applies to any network endpoint device that gets an IP address in your enterprise’s range and is also bound to one of your enterprise domains, including SMB shares. Local file system locations should just maintain encryption (for example, on local NTFS, FAT, ExFAT).
 
-**To specify where your protected apps can find and send enterprise data on the network**
+>**Important**<br>
+- Every EDP policy should include policy that defines your enterprise network locations.
+- Classless Inter-Domain Routing (CIDR) notation isn’t supported for EDP configurations.
+
+**To define where your protected apps can find and send enterprise data on you network**
+
+1. Add additional network locations your apps can access by clicking **Add**.
+
+    The **Add or edit corporate network definition** box appears.
+
+2.	Type a name for your corporate network element into the **Name** box, and then pick what type of network element it is, from the **Network element** drop-down box. This can include any of the options in the following table.
+
+    ![Add or edit corporate network definition box, Add your enterprise network locations](images/edp-sccm-add-network-domain.png)
 
-1.  Add additional network locations your apps can access by clicking **Add**, and then choosing your location type, including:
     <table>
         <tr>
             <th>Network location type</th>
@@ -216,65 +389,145 @@ After you've added a management level to your protected apps, you'll need to dec
             <th>Description</th>
         </tr>
         <tr>
-            <td>Enterprise Cloud Domain</td>
-            <td>contoso.sharepoint.com,proxy1.contoso.com|<br>office.com|proxy2.contoso.com</td>
-            <td>Specify the cloud resources traffic to restrict to your protected apps.<p>For each cloud resource, you may also specify an internal proxy server that routes your traffic from your **Enterprise Internal Proxy Server** policy. If you have multiple resources, you must use the &#x7C; delimiter. Include the "|" delimiter just before the "|" if you don’t use proxies. For example: [URL,Proxy]|[URL,Proxy].</td>     
+            <td>Enterprise Cloud Resources</td>
+            <td>**With proxy:** contoso.sharepoint.com,proxy.contoso.com|<br>contoso.visualstudio.com,proxy.contoso.com<p>**Without proxy:** contoso.sharepoint.com|contoso.visualstudio.com</td>
+            <td>Specify the cloud resources to be treated as corporate and protected by EDP.<p>For each cloud resource, you may also optionally specify an internal proxy server that routes your traffic through your Enterprise Internal Proxy Server.<p>If you have multiple resources, you must separate them using the "|" delimiter. If you don’t use proxy servers, you must also include the "," delimiter just before the "|". For example: `URL <,proxy>|URL <,proxy>`.<p>If Windows is unable to determine whether an app should be allowed to connect to a network resource, it will automatically block the connection. If instead you want Windows to allow the connections to happen, you can add the `/*AppCompat*/` string to this setting. For example: `URL <,proxy>|URL <,proxy>|/*AppCompat*/`</td>
         </tr>
         <tr>
-            <td>Enterprise Network Domain</td>
-            <td>domain1.contoso.com,domain2.contoso.com</td>
-            <td>Specify the DNS suffix used in your environment. All traffic to the fully-qualified domains using this DNS suffix will be protected. If you have multiple resources, you must use the "," delimiter.<p>This setting works with the IP Ranges settings to detect whether a network endpoint is enterprise or personal on private networks.</td>                
+            <td>Enterprise Network Domain Names (Required)</td>
+            <td>corp.contoso.com,region.contoso.com</td>
+            <td>Specify the DNS suffixes used in your environment. All traffic to the fully-qualified domains appearing in this list will be protected.<p>This setting works with the IP ranges settings to detect whether a network endpoint is enterprise or personal on private networks.<p>If you have multiple resources, you must separate them using the "," delimiter.</td>                
         </tr>
         <tr>
-            <td>Enterprise Proxy Server</td>
-            <td>domain1.contoso.com:80;domain2.contoso.com:137</td>
-            <td>Specify the proxy server and the port traffic is routed through. If you have multiple resources, you must use the ";" delimiter.<p>This setting is required if you use a proxy in your network. If you don't have a proxy server, you might find that enterprise resources are unavailable when a client is behind a proxy, such as when using certain Wi-Fi hotspots at hotels and restaurants.</td>                
+            <td>Enterprise Proxy Servers</td>
+            <td>proxy.contoso.com:80;proxy2.contoso.com:137</td>
+            <td>Specify your externally-facing proxy server addresses, along with the port through which traffic is allowed and protected with EDP.<p>This list shouldn’t include any servers listed in the Enterprise Internal Proxy Servers list, which are used for EDP-protected traffic.<p>This setting is also required if you use a proxy in your network. If you don't have a proxy server, you might find that enterprise resources are unavailable when a client is behind a proxy, such as when you’re visiting another company and not on that company’s guest network.<p>If you have multiple resources, you must separate them using the ";" delimiter.</td>
         </tr>
         <tr>
-            <td>Enterprise Internal Proxy Server</td>
-            <td>proxy1.contoso.com;proxy2.contoso.com</td>
-            <td>Specify the proxy servers your cloud resources will go through. If you have multiple resources, you must use the ";" delimiter.</td>                
+            <td>Enterprise Internal Proxy Servers</td>
+            <td>contoso.internalproxy1.com;contoso.internalproxy2.com</td>
+            <td>Specify the proxy servers your devices will go through to reach your cloud resources.<p>Using this server type indicates that the cloud resources you’re connecting to are enterprise resources.<p>This list shouldn’t include any servers listed in the Enterprise Proxy Servers list, which are used for non-EDP-protected traffic.<p>If you have multiple resources, you must separate them using the ";" delimiter.</td>                
         </tr>
         <tr>
-            <td>Enterprise IPv4 Range</td>
-            <td>**Starting IPv4 Address:** 3.4.0.1<br>**Ending IPv4 Address:** 3.4.255.254<br>**Custom URI:** 3.4.0.1-3.4.255.254,10.0.0.1-10.255.255.254</td>
-            <td>Specify the addresses for a valid IPv4 value range within your intranet.<p>If you are adding a single range, you can enter the starting and ending addresses into your management system’s UI. If you want to add multiple addresses, we suggest creating a Custom URI, using the "-" delimiter between start and end of a range, and the "," delimiter to separate ranges.</td>
+            <td>Enterprise IPv4 Range (Required)</td>
+            <td>**Starting IPv4 Address:** 3.4.0.1<br>**Ending IPv4 Address:** 3.4.255.254<br>**Custom URI:** 3.4.0.1-3.4.255.254,<br>10.0.0.1-10.255.255.254</td>
+            <td>Specify the addresses for a valid IPv4 value range within your intranet. These addresses, used with your Enterprise Network Domain Names, define your corporate network boundaries.<p>If you have multiple ranges, you must separate them using the "," delimiter.</td>
         </tr>
         <tr>
             <td>Enterprise IPv6 Range</td>
-            <td>**Starting IPv6 Address:** 2a01:110::<br>**Ending IPv6 Address:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff<br>**Custom URI:** 2a01:110::-2a01:110:7fff:ffff:ffff:ffff:ffff:ffff,fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff</td>
-            <td>Specify the addresses for a valid IPv6 value range within your intranet.<p>If you are adding a single range, you can enter the starting and ending addresses into your management system’s UI. If you want to add multiple addresses, we suggest creating a Custom URI, using the "-" delimiter between start and end of a range, and the "," delimiter to separate ranges.</td>
-        </tr>                
+            <td>**Starting IPv6 Address:** 2a01:110::<br>**Ending IPv6 Address:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff<br>**Custom URI:** 2a01:110:7fff:ffff:ffff:ffff:ffff:ffff,<br>fd00::-fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff</td>
+            <td>Specify the addresses for a valid IPv6 value range within your intranet. These addresses, used with your Enterprise Network Domain Names, define your corporate network boundaries.<p>If you have multiple ranges, you must separate them using the "," delimiter.</td>
+        </tr>
+        <tr>
+            <td>Neutral Resources</td>
+            <td>sts.contoso.com,sts.contoso2.com</td>
+            <td>Specify your authentication redirection endpoints for your company.<p>These locations are considered enterprise or personal, based on the context of the connection before the redirection.<p>If you have multiple resources, you must separate them using the "," delimiter.</td>
+        </tr>           
     </table>
 
-    ![Create Configuration Item wizard, specify the network locations that can be accessed by the protected apps](images/edp-sccm-primarydomain2.png)
+3.	Add as many locations as you need, and then click **OK**.
 
-2.  Add as many locations as you need, and then click **OK**.<p>
-The **Add or Edit Enterprise Network Locations box** closes.
+    The **Add or edit corporate network definition** box closes.
 
-3.  In the **Use a data recovery certificate in case of data loss** box, click **Browse** to add a data recovery certificate for your policy.<p>
-Adding a data recovery certificate helps you to access locally-protected files on the device. For example, if an employee leaves the company and the IT department has to access EDP-protected data from a Windows 10 company computer. This can also help recover data in case an employee's device is accidentally revoked. For more info about how to find and export your data recovery certificate, see the[Data Recovery and Encrypting File System (EFS)](http://go.microsoft.com/fwlink/p/?LinkId=761462) topic.
+4.	Decide if you want to Windows to look for additional network settings.
 
-## Choose your optional EDP-related settings
+    ![Create Configuration Item wizard, Add whether to search for additional network settings](images/edp-sccm-optsettings.png)
+
+        - **Enterprise Proxy Servers list is authoritative (do not auto-detect).** Click this box if you want Windows to treat the proxy servers you specified in the network boundary definition as the complete list of proxy servers available on your network. If you clear this box, Windows will search for additional proxy servers in your immediate network.
+
+        - **Enterprise IP Ranges list is authoritative (do not auto-detect).** Click this box if you want Windows to treat the IP ranges you specified in the network boundary definition as the complete list of IP ranges available on your network. If you clear this box, Windows will search for additional IP ranges on any domain-joined devices connected to your network.
+
+        - **Show the enterprise data protection icon overlay on your allowed apps that are EDP-unaware in the Windows Start menu and on corporate file icons in the File Explorer.** Click this box if you want the enterprise data protection icon overlay to appear on corporate files or in the Start menu, on top the tiles for your unenlightened protected apps.
+
+5.	In the required **Upload a Data Recovery Agent (DRA) certificate to allow recovery of encrypted data** box, click **Browse** to add a data recovery certificate for your policy.
+    
+    ![Create Configuration Item wizard, Add a data recovery agent (DRA) certificate](images/edp-sccm-dra.png)
+
+    After you create and deploy your EDP policy to your employees, Windows will begin to encrypt your corporate data on the employees’ local device drive. If somehow the employees’ local encryption keys get lost or revoked, the encrypted data can become unrecoverable. To help avoid this possibility, the DRA certificate lets Windows use an included public key to encrypt the local data, while you maintain the private key that can unencrypt the data. 
+    
+    For more info about how to find and export your data recovery certificate, see the [Data Recovery and Encrypting File System (EFS)](http://go.microsoft.com/fwlink/p/?LinkId=761462) topic.
+
+#### Create and verify an Encrypting File System (EFS) DRA certificate for EDP
+If you don’t already have an EFS DRA certificate, you’ll need to create and extract one from your system before you can use EDP in your organization. For the purposes of this section, we’ll use the file name EFSDRA; however, this name can be replaced with anything that makes sense to you.
+
+>**Important**<br>If you already have an EFS DRA certificate for your organization, you can skip creating a new one. Just use your current EFS DRA certificate in your policy.
+
+**To manually create an EFS DRA certificate**
+1. On a computer without an EFS DRA certificate installed, open a command prompt with elevated rights, and then navigate to where you want to store the certificate.
+2. Run this command:
+    
+    `cipher /r:<EFSDRA>`<br>Where `<EFSDRA>` is the name of the .cer and .pfx files that you want to create.
+
+3. When prompted, type and confirm a password to help protect your new Personal Information Exchange (.pfx) file.
+
+    The EFSDRA.cer and EFSDRA.pfx files are created in the location you specified in Step 1. 
+
+    >**Important**<br>Because these files can be used to decrypt any EDP file, you must protect them accordingly. We highly recommend storing them as a public key (PKI) on a smart card with strong protection, stored in a secured physical location.
+
+4.	Add your EFS DRA certificate to your EDP policy by using Step 3 of the [Choose where apps can access enterprise data](#choose-where-apps-can-access-enterprise-data) section of this topic.
+
+**To verify your data recovery certificate is correctly set up on an EDP client computer**
+1.	Open an app on your protected app list, and then create and save a file so that it’s encrypted by EDP.
+
+2.	Open a command prompt with elevated rights, navigate to where you stored the file you just created, and then run this command:
+
+    `cipher /c <filename>`<br>Where `<filename>` is the name of the file you created in Step 1.
+
+3.	Make sure that your data recovery certificate is listed in the **Recovery Certificates** list.
+
+**To recover your data using the EFS DRA certificate in a test environment**
+1.	Copy your EDP-encrypted file to a location where you have admin access.
+
+2.	Install the EFSDRA.pfx file, using your password.
+
+3.	Open a command prompt with elevated rights, navigate to the encrypted file, and then run this command:
+
+    `cipher /d <encryptedfile.extension>`<br>Where `<encryptedfile.extension>` is the name of your encrypted file. For example, corporatedata.docx.
+
+### Choose your optional EDP-related settings
 After you've decided where your protected apps can access enterprise data on your network, you’ll be asked to decide if you want to add any optional EDP settings.
 
-**To add your optional settings**
--   Choose to set any or all of the optional EDP-related settings:
+![Create Configuration Item wizard, Choose any additional, optional settings](images/edp-sccm-additionalsettings.png)
 
-    -   **Block the user from decrypting data that was created or edited by the apps configured above.** Clicking **No**, or leaving the setting blank, lets your employees right-click to decrypt their protected app data, along with the option to decrypt data in the **Save As** box and the **Save As** file picker . Clicking **Yes** removes the **Decrypt** option and saves all data for protected apps as enterprise-encrypted.
+**To set your optional settings**
+1.	Choose to set any or all of the optional settings:
 
-    -   **Protect app content when the device is in a locked state for the apps configured above.** Clicking **Yes** lets EDP help to secure protected app content when a mobile device is locked. We recommend turning this option on to help prevent data leaks from things such as email text that appears on the **Lock** screen of a Windows 10 Mobile phone.
+    - **Show the Personal option in the File ownership menus of File Explorer and the Save As dialog box.** Determines whether users can see the Personal option for files within File Explorer and the **Save As** dialog box. The options are:
+    
+        - **Yes, or not configured (recommended).** Employees can choose whether a file is **Work** or **Personal** in File Explorer and the **Save As** dialog box. 
+	
+        - **No.** Hides the **Personal** option from employees. Be aware that if you pick this option, apps that use the **Save As** dialog box might encrypt new files as corporate data unless a different file path is given during the original file creation. After this happens, decryption of work files becomes more difficult.
 
-        ![Create Configuration Item wizard, choose additional optional settings for enterprise data protection](images/edp-sccm-optsettings.png)
+    - **Prevent corporate data from being accessed by apps when the device is locked. Applies only to Windows 10 Mobile**. Determines whether apps can show corporate data on a Windows 10 Mobile device **Lock** screen. The options are:
+	
+        - **Yes (recommended).** Stop apps from reading corporate data on Windows 10 Mobile device when the screen is locked.
+	
+        - **No, or not configured.**  Allows apps to read corporate data on Windows 10 Mobile device when the screen is locked.
 
-## Review your configuration choices in the Summary screen
+    - **Allow Windows Search to search encrypted corporate data and Store apps.** Determines whether Windows Search can search and index encrypted corporate data and Store apps. The options are:
+
+	    - **Yes.** Allows Windows Search to search and index encrypted corporate data and Store apps.
+
+	    - **No, or not configured (recommended).** Stops Windows Search from searching and indexing encrypted corporate data and Store apps.
+
+    - **Revoke local encryption keys during the unerollment process.** Determines whether to revoke a user’s local encryption keys from a device when it’s unenrolled from enterprise data protection. If the encryption keys are revoked, a user no longer has access to encrypted corporate data. The options are:
+
+        - **Yes, or not configured (recommended).** Revokes local encryption keys from a device during unenrollment.
+        
+        - **No.** Stop local encryption keys from being revoked from a device during unenrollment. For example, if you’re migrating between Mobile Device Management (MDM) solutions.
+
+2. After you pick all of the settings you want to include, click **Summary**.
+
+### Review your configuration choices in the Summary screen
 After you've finished configuring your policy, you can review all of your info on the **Summary** screen.
 
 **To view the Summary screen**
--   Click the **Summary** button to review your policy choices, and then click **Next** to finish and to save your policy.<p>
-A progress bar appears, showing you progress for your policy. After it's done, click **Close** to return to the **Configuration Items** page.
+- Click the **Summary** button to review your policy choices, and then click **Next** to finish and to save your policy.
+
+    ![Create Configuration Item wizard, Summary screen for all of your policy choices](images/edp-sccm-summaryscreen.png)
+ 
+    A progress bar appears, showing you progress for your policy. After it's done, click **Close** to return to the **Configuration Items** page.
 
-    ![Create Configuration Item wizard, review the Summary screen before creating the policy](images/edp-sccm-summaryscreen.png)
 
 ## Deploy the EDP policy
 After you’ve created your EDP policy, you'll need to deploy it to your organization's devices. For info about your deployment options, see these topics:
@@ -283,15 +536,6 @@ After you’ve created your EDP policy, you'll need to deploy it to your organiz
 - [How to Deploy Configuration Baselines in Configuration Manager]( http://go.microsoft.com/fwlink/p/?LinkId=708226)
 
 ## Related topics
-- [System Center Configuration Manager and Endpoint Protection (Version 1511)](http://go.microsoft.com/fwlink/p/?LinkId=717372)
+- [System Center Configuration Manager and Endpoint Protection (Version 1606)](http://go.microsoft.com/fwlink/p/?LinkId=717372)
 - [TechNet documentation for Configuration Manager](http://go.microsoft.com/fwlink/p/?LinkId=691623)
-- [Manage mobile devices with Configuration Manager and Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=691624)
-
- 
-
- 
-
-
-
-
-
+- [Manage mobile devices with Configuration Manager and Microsoft Intune](http://go.microsoft.com/fwlink/p/?LinkId=691624)
\ No newline at end of file
diff --git a/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md b/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md
index a1b2db57b3..fdf497e545 100644
--- a/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md
+++ b/windows/keep-secure/creating-a-device-guard-policy-for-signed-apps.md
@@ -1,112 +1,5 @@
 ---
 title: Create a Device Guard code integrity policy based on a reference device (Windows 10)
-description: To implement Device Guard app protection, you will need to create a code integrity policy. Code integrity policies determine what apps are considered trustworthy and are allowed to run on a protected device.
-ms.assetid: 6C94B14E-E2CE-4F6C-8939-4B375406E825
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.sitesec: library
-ms.pagetype: security
-author: brianlic-msft
+redirect_url: device-guard-deployment-guide.md
 ---
 
-# Create a Device Guard code integrity policy based on a reference device
-**Applies to**
--   Windows 10
-
-To implement Device Guard app protection, you will need to create a code integrity policy. Code integrity policies determine what apps are considered trustworthy and are allowed to run on a protected device.
-
-## <a href="" id="create-a-device-guard-code-integrity-policy-based-on--a-reference-device"></a>Create a Device Guard code integrity policy based on a reference device
-
-To create a code integrity policy, you'll first need to create a reference image that includes the signed applications you want to run on your protected devices. For information on how to sign applications, see [Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md).
-> **Note:**  Before creating a code integrity policy, make sure your reference device is clean of viruses and malware.
- 
-**To create a code integrity policy based on a reference device**
-
-1.  On your reference device, start PowerShell as an administrator.
-2.  In PowerShell, initialize variables by typing:
-    ``` syntax
-    $CIPolicyPath=$env:userprofile+"\Desktop\"
-    $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"
-    $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"
-    ```
-3.  Scan your device for installed applications and create a new code integrity policy by typing:
-    ``` syntax
-    New-CIPolicy -Level <RuleLevel> -FilePath $InitialCIPolicy -UserPEs -Fallback Hash 3> Warningslog.txt
-    ```
-    Where *&lt;RuleLevel&gt;* can be set to any of the following options:
-    <table>
-    <colgroup>
-    <col width="50%" />
-    <col width="50%" />
-    </colgroup>
-    <thead>
-    <tr class="header">
-    <th align="left">Rule level</th>
-    <th align="left">Description</th>
-    </tr>
-    </thead>
-    <tbody>
-    <tr class="odd">
-    <td align="left"><p>Hash</p></td>
-    <td align="left"><p>Specifies individual hash values for each discovered app. Each time an app is updated the hash value will change and you will need to update your policy.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>FileName</p></td>
-    <td align="left"><p>Currently unsupported.</p></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>SignedVersion</p></td>
-    <td align="left"><p>Currently unsupported.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>Publisher</p></td>
-    <td align="left"><p>This level is a combination of the PCA certificate and the common name (CN) on the leaf certificate. When a PCA certificate is used to sign apps from multiple companies (such as VeriSign), this rule level allows you to trust the PCA certificate but only for the company whose name is on the leaf certificate.</p></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>FilePublisher</p></td>
-    <td align="left"><p>Currently unsupported.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>LeafCertificate</p></td>
-    <td align="left"><p>Adds trusted signers at the individual signing certificate level. When an app is updated, the hash value is modified but the signing certificate stays the same. You will only need to update your policy if the signing certificate for an app changes.</p>
-    <div class="alert">
-    <strong>Note</strong>  Leaf certificates have much shorter validity periods than PCA certificates. You will need to update your policy if a certificate expires.
-    </div>
-    <div>
-     
-    </div></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>PcaCertificate</p></td>
-    <td align="left"><p>Adds the highest certificate in the provided certificate chain to signers. This is typically one certificate below the root certificate, as the scan does not validate anything above the presented signature by going online or checking local root stores.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>RootCertificate</p></td>
-    <td align="left"><p>Currently unsupported.</p></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>WHQL</p></td>
-    <td align="left"><p>Currently unsupported.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>WHQLPublisher</p></td>
-    <td align="left"><p>Currently unsupported.</p></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>WHQLFilePublisher</p></td>
-    <td align="left"><p>Currently unsupported.</p></td>
-    </tr>
-    </tbody>
-    </table>
-     
-4.  Type the following to convert the code integrity policy to a binary format:
-    ``` syntax
-    ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
-    ```
-Once you have completed these steps, the Device Guard policy binary file (DeviceGuardPolicy.bin) and original xml file (InitialScan.xml) will be available on your desktop.
->**Note:**  We recommend that you keep a copy of InitialScan.xml to use if you need to merge this code integrity policy with another policy, or update policy rule options.
- 
-## Related topics
-[Getting apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md)
- 
- 
diff --git a/windows/keep-secure/credential-guard.md b/windows/keep-secure/credential-guard.md
index acf87038bb..3974a748e2 100644
--- a/windows/keep-secure/credential-guard.md
+++ b/windows/keep-secure/credential-guard.md
@@ -29,7 +29,8 @@ Credential Guard isolates secrets that previous versions of Windows stored in th
 
 For security reasons, the isolated LSA process doesn't host any device drivers. Instead, it only hosts a small subset of operating system binaries that are needed for security and nothing else. All of these binaries are signed with a certificate that is trusted by virtualization-based security and these signatures are validated before launching the file in the protected environment.
 
-Credential Guard also does not allow older variants of NTLM, unconstrained Kerberos delegation, and Kerberos authentication protocols and cipher suites when using default derived credentials, including NTLMv1, MS-CHAPv2, and weaker Kerberos encryption types, such as DES.
+Credential Guard also does not allow unconstrained Kerberos delegation, NTLMv1, MS-CHAPv2, Digest, CredSSP, and Kerberos DES encryption.
+
 Here's a high-level overview on how the LSA is isolated by using virtualization-based security:
 
 ![Credential Guard overview](images/credguard.png)
diff --git a/windows/keep-secure/deploy-catalog-files-to-support-code-integrity-policies.md b/windows/keep-secure/deploy-catalog-files-to-support-code-integrity-policies.md
new file mode 100644
index 0000000000..a20497761c
--- /dev/null
+++ b/windows/keep-secure/deploy-catalog-files-to-support-code-integrity-policies.md
@@ -0,0 +1,327 @@
+---
+title: Deploy catalog files to support code integrity policies (Windows 10)
+description: This article describes how to deploy catalog files to support code integrity policies, one of the main features that are part of Device Guard in Windows 10. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Deploy catalog files to support code integrity policies
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+Catalog files can be important in your deployment of code integrity polices if you have unsigned line-of-business (LOB) applications for which the process of signing is difficult. To prepare to create code integrity policies that allow these trusted applications but block unsigned code (most malware is unsigned), you create a *catalog file* that contains information about the trusted applications. After you sign and distribute the catalog, your trusted applications can be handled by code integrity policies in the same way as any other signed application. With this foundation, you can more easily block all unsigned applications, allowing only signed applications to run.
+
+For more description of 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) in "Requirements and deployment planning guidelines for Device Guard." 
+
+## Create catalog files
+
+The creation of a catalog file is a necessary step for adding an unsigned application to a code integrity policy.
+
+To create a catalog file, you use a tool called **Package Inspector**. You must also have a code integrity policy deployed in audit mode on the computer on which you run Package Inspector, because Package Inspector does not always detect installation files that have been removed from the computer during the installation process.
+
+> **Note**&nbsp;&nbsp;When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, *\*-Contoso.cat* is used as the example naming convention. For more information about why this practice is helpful to inventory or detect catalog files, see [Inventory catalog files with System Center Configuration Manager](#inventory-catalog-files-with-system-center-configuration-manager), later in this topic.
+
+1.  Be sure that a code integrity policy is currently deployed in audit mode on the computer on which you will run Package Inspector.
+
+    Package Inspector does not always detect installation files that have been removed from the computer during the installation process. To ensure that these binaries are also trusted, deploy a code integrity policy in audit mode. You can use the code integrity policy that you created and audited in [Create a code integrity policy from a golden computer](deploy-code-integrity-policies-steps.md#create-a-code-integrity-policy-from-a-golden-computer) and [Audit code integrity policies](deploy-code-integrity-policies-steps.md#audit-code-integrity-policies).
+
+    > **Note**&nbsp;&nbsp;This process should **not** be performed on a system with an enforced Device Guard policy, only with a policy in audit mode. If a policy is currently being enforced, you will not be able to install and run the application.
+
+2.  Start Package Inspector, and then start scanning a local drive, for example, drive C:
+
+    ` PackageInspector.exe Start C:`
+
+    > **Note**&nbsp;&nbsp;Package inspector can monitor installations on any local drive. Specify the appropriate drive on the local computer.
+    
+3.  Copy the installation media to the local drive (typically drive C).
+
+    By copying the installation media to the local drive, you ensure that Package Inspector detects and catalogs the actual installer. If you skip this step, the future code integrity policy may trust the application to run but not to be installed.
+
+4.  Install the application. Install it to the same drive that the application installer is located on (the drive you are scanning). Also, while Package Inspector is running, do not run any installations or updates that you don't want to capture in the catalog.
+
+    > **Important**&nbsp;&nbsp;Every binary that is run while Package Inspector is running will be captured in the catalog. Ensure that only trusted applications are run during this time. 
+
+5.  Start the application.
+
+6.  Ensure that product updates are installed, and downloadable content associated with the application is downloaded.
+
+7.  Close and reopen the application. 
+
+    This step is necessary to ensure that the scan has captured all binaries.
+    
+8.  As appropriate, with Package Inspector still running, repeat the process for another application that you want in the catalog. Copy the installation media to the local drive, install the application, ensure it is updated, and then close and reopen the application.
+
+9. When you have confirmed that the previous steps are complete, use the following commands to generate the catalog and definition files on your computer's desktop. The filenames used in these example commands are **LOBApp-Contoso.cat** (catalog file) and **LOBApp.cdf** (definition file)—substitute different filenames as appropriate. 
+
+    For the last command, which stops Package Inspector, be sure to type the drive letter of the drive you have been scanning, for example, C:.  
+
+    ` $ExamplePath=$env:userprofile+"\Desktop"`
+
+    ` $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
+
+    ` $CatDefName=$ExamplePath+"\LOBApp.cdf"`
+
+    ` PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
+
+> **Note**&nbsp;&nbsp;Package Inspector catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
+
+When finished, the files will be saved to your desktop. You can double-click the \*.cat file to see its contents, and you can view the \*.cdf file with a text editor. 
+
+To trust this catalog file within a code integrity policy, the catalog must first be signed. Then, the signing certificate can be added to the code integrity policy, and the catalog file can be distributed to the individual client computers. 
+
+For information about signing catalog files by using a certificate and SignTool.exe, a free tool available in the Windows SDK, see the next section, [Catalog signing with SignTool.exe](#catalog-signing-with-signtool.exe).
+
+For information about adding the signing certificate to a code integrity policy, see [Add a catalog signing certificate to a code integrity policy](deploy-code-integrity-policies-steps.md#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+
+## Catalog signing with SignTool.exe
+
+In this section, you sign a catalog file you generated by using PackageInspector.exe, as described in the previous section, [Create catalog files](#create-catalog-files). In this example, you need the following:
+
+-   SignTool.exe, found in the Windows software development kit (SDK—Windows 7 or later)
+
+-   The catalog file that you generated in the [Create catalog files](#create-catalog-files) section, or another catalog file that you have created
+
+-   An internal certification authority (CA) code signing certificate or purchased code signing certificate
+
+If you do not have a code signing certificate, see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) for a walkthrough of how to create one. That topic uses an example certificate name of **ContosoDGSigningCert**, and the procedure that follows uses that example certificate name to sign the catalog file that you created in [Create catalog files](#create-catalog-files), earlier in this topic. If you are using an alternate certificate or catalog file, update the following steps with the appropriate variables and certificate. 
+
+To sign the existing catalog file, copy each of the following commands into an elevated Windows PowerShell session.
+
+1.  Initialize the variables that will be used:
+
+    ` $ExamplePath=$env:userprofile+"\Desktop"`
+    
+    ` $CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
+
+    > **Note**&nbsp;&nbsp;This example specifies the catalog file you created in the [Create catalog files](#create-catalog-files) section. If you are signing another catalog file, update the *$ExamplePath* and *$CatFileName* variables with the correct information.
+
+2.  Import the code signing certificate that will be used to sign the catalog file. Import it to the signing user’s personal store. This example uses the certificate name from [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
+
+3.  Sign the catalog file with Signtool.exe:
+
+    ` <path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName`
+
+    > **Note**&nbsp;&nbsp;The *&lt;Path to signtool.exe&gt;* variable should be the full path to the Signtool.exe utility. *ContosoDGSigningCert* represents the subject name of the certificate that you will use to sign the catalog file. This certificate should be imported to your personal certificate store on the computer on which you are attempting to sign the catalog file.
+
+    > **Note**&nbsp;&nbsp;For additional information about Signtool.exe and all additional switches, visit the [MSDN Sign Tool page](https://msdn.microsoft.com/library/8s9b9yaz(v=vs.110).aspx).
+    
+4.  Verify the catalog file digital signature. Right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with a **sha256** algorithm, as shown in Figure 1.
+
+    ![Digital Signature list in file Properties](images/dg-fig12-verifysigning.png)
+
+    Figure 1. Verify that the signing certificate exists
+
+5.  Copy the catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
+
+    For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale implementations, to copy the appropriate catalog files to all desired computers, we recommend that you use Group Policy File Preferences or an enterprise systems management product such as System Center Configuration Manager. Doing this also simplifies the management of catalog versions.
+
+## Add a catalog signing certificate to a code integrity policy
+
+After the catalog file is signed, add the signing certificate to a code integrity policy, as described in the following steps.
+
+<!-- All options below need to be confirmed. -->
+
+1.  If you have not already verified the catalog file digital signature, right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with the algorithm you expect.
+
+2.  If you already have an XML policy file that you want to add the signing certificate to, skip to the next step. Otherwise, use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to create a code integrity policy that you will later merge into another policy (not deploy as-is). This example creates a policy called **CatalogSignatureOnly.xml** in the location **C:\\PolicyFolder**:
+
+    ` New-CIPolicy -Level PcaCertificate -FilePath C:\PolicyFolder\CatalogSignatureOnly.xml –UserPEs`
+
+    > **Note**&nbsp;&nbsp;Include the **-UserPEs** parameter to ensure that the policy includes user mode code integrity.
+
+3.  Use [Add-SignerRule](https://technet.microsoft.com/library/mt634479.aspx) to add the signing certificate to the code integrity policy, filling in the correct path and filenames for *<policypath>* and *<certpath>*:
+
+    ` Add-SignerRule -FilePath <policypath> -CertificatePath <certpath> -User `
+
+If you used step 2 to create a new code integrity policy, and want information about merging policies together, see [Merge code integrity policies](deploy-code-integrity-policies-steps.md#merge-code-integrity-policies).  
+
+## Deploy catalog files with Group Policy
+
+To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the appropriate computers in your organization. The following process walks you through the deployment of a signed catalog file called **LOBApp-Contoso.cat** to a test OU called DG Enabled PCs with a GPO called **Contoso DG Catalog File GPO Test**.
+
+> **Note**&nbsp;&nbsp;This walkthrough requires that you have previously created a signed catalog file and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a catalog file, see [Create catalog files](#create-catalog-files), earlier in this topic. Also, before you begin testing of a catalog file with the code integrity policy it supports, review [Add a catalog signing certificate to a code integrity policy](#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+
+**To deploy a catalog file with Group Policy:**
+
+1.  From either a domain controller or a client computer that has Remote Server Administration Tools (RSAT) installed, open the Group Policy Management Console (GPMC) by running **GPMC.MSC** or by searching for Group Policy Management.
+
+2.  Create a new GPO: right-click an OU, for example, the **DG Enabled PCs OU**, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 2.
+
+    > **Note**&nbsp;&nbsp;You can use any OU name. Also, security group filtering is an option when you consider different ways of combining code integrity policies (or keeping them separate), as discussed in [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+
+   ![Group Policy Management, create a GPO](images/dg-fig13-createnewgpo.png)
+
+   Figure 2. Create a new GPO
+
+3.  Give the new GPO a name, for example, **Contoso DG Catalog File GPO Test**, or any name you prefer.
+
+4.  Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
+
+5.  Within the selected GPO, navigate to Computer Configuration\\Preferences\\Windows Settings\\Files. Right-click **Files**, point to **New**, and then click **File**, as shown in Figure 3.
+
+    ![Group Policy Management Editor, New File](images/dg-fig14-createnewfile.png)
+
+    Figure 3. Create a new file
+
+6.  Configure the catalog file share.
+
+    To use this setting to provide consistent deployment of your catalog file (in this example, LOBApp-Contoso.cat), the source file should be on a share that is accessible to the computer account of every deployed computer. This example uses a share (on a computer running Windows 10) called \\\\Contoso-Win10\\Share. The catalog file being deployed is copied to this share.
+
+7.  To keep versions consistent, in the **New File Properties** dialog box (Figure 4), select **Replace** from the **Action** list so that the newest version is always used.
+
+    ![File Properties, Replace option](images/dg-fig15-setnewfileprops.png)
+
+    Figure 4. Set the new file properties
+
+8.  In the **Source file(s)** box, type the name of your accessible share, with the catalog file name included (for example, \\\\Contoso-Win10\\share\\LOBApp-Contoso.cat).
+
+9.  In the **Destination File** box, type a path and file name, for example:
+
+    **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\LOBApp-Contoso.cat**
+
+    For the catalog file name, use the name of the catalog you are deploying.
+
+10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Doing this ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
+
+11. Click **OK** to complete file creation.
+
+12. Close the Group Policy Management Editor, and then update the policy on the test computer running Windows 10, by running GPUpdate.exe. When the policy has been updated, verify that the catalog file exists in C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} on the computer running Windows 10.
+
+Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate code integrity policy, as described in [Add a catalog signing certificate to a code integrity policy](#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+
+## Deploy catalog files with System Center Configuration Manager
+
+As an alternative to Group Policy, you can use System Center Configuration Manager to deploy catalog files to the managed computers in your environment. This approach can simplify the deployment and management of multiple catalog files as well as provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, System Center Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment package for catalog files:
+
+> **Note**&nbsp;&nbsp;The following example uses a network share named \\\\Shares\\CatalogShare as a source for the catalog files. If you have collection specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
+
+1.  Open the Configuration Manager console, and select the Software Library workspace.
+
+2.  Navigate to Overview\\Application Management, right-click **Packages**, and then click **Create Package**.
+
+3.  Name the package, set your organization as the manufacturer, and select an appropriate version number.
+
+    ![Create Package and Program Wizard](images/dg-fig16-specifyinfo.png)
+
+    Figure 5. Specify information about the new package
+
+4.  Click **Next**, and then select **Standard program** as the program type.
+
+5.  On the **Standard Program** page, select a name, and then set the **Command Line** property to **XCopy \\\\Shares\\CatalogShare C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y**.
+
+6.  On the **Standard Program** page, select the following options (Figure 6):
+
+    -   In **Name**, type a name such as **Contoso Catalog File Copy Program**.
+
+    -   In **Command line**, browse to the program location.
+
+    -   In **Startup folder**, type **C:\\Windows\\System32**.
+
+    -   From the **Run** list, select **Hidden**.
+
+    -   From the **Program can run** list, select **Whether or not a user is logged on**.
+
+    -   From the **Drive mode** list, select **Runs with UNC name**.
+
+    ![Standard Program page of wizard](images/dg-fig17-specifyinfo.png)
+
+    Figure 6. Specify information about the standard program
+
+7.  Accept the defaults for the rest of the wizard, and then close the wizard.
+
+After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you just created to a test collection:
+
+1.  In the Software Library workspace, navigate to Overview\\Application Management\\Packages, right-click the catalog file package, and then click **Deploy**.
+
+2.  On the **General** page, select the test collection to which the catalog files will be deployed, and then click **Next**.
+
+3.  On the **Content** page, click **Add** to select the distribution point that will serve content to the selected collection, and then click **Next**.
+
+4.  On the **Deployment Settings** page, select **Required** in the **Purpose** box.
+
+5.  On the **Scheduling** page, click **New**.
+
+6.  In the **Assignment Schedule** dialog box, select **Assign immediately after this event**, set the value to **As soon as possible**, and then click **OK**.
+
+7.  On the **Scheduling** page, click **Next**.
+
+8.  On the **User Experience** page (Figure 7), set the following options, and then click **Next**:
+
+    -   Select the **Software installation** check box.
+
+    -   Select the **Commit changes at deadline or during a maintenance window (requires restarts)** check box.
+
+    ![Deploy Software Wizard, User Experience page](images/dg-fig18-specifyux.png)
+
+    Figure 7. Specify the user experience
+
+9.  On the **Distribution Points** page, in the **Deployment options** box, select **Run program from distribution point**, and then click **Next**.
+
+10. On the **Summary** page, review the selections, and then click **Next**.
+
+11. Close the wizard.
+
+Before you begin testing the deployed catalog file, make sure that the catalog signing certificate has been added to an appropriate code integrity policy, as described in [Add a catalog signing certificate to a code integrity policy](#add-a-catalog-signing-certificate-to-a-code-integrity-policy).
+
+## Inventory catalog files with System Center Configuration Manager
+
+When catalog files have been deployed to the computers within your environment, whether by using Group Policy or System Center Configuration Manager, you can inventory them with the software inventory feature of System Center Configuration Manager. The following process walks you through the enablement of software inventory to discover catalog files on your managed systems through the creation and deployment of a new client settings policy.
+
+> **Note**&nbsp;&nbsp;A standard naming convention for your catalog files will significantly simplify the catalog file software inventory process. In this example, *-Contoso* has been added to all catalog file names.
+
+1.  Open the Configuration Manager console, and select the Administration workspace.
+
+2.  Navigate to **Overview\\Client Settings**, right-click **Client Settings**, and then click **Create Custom Client Device Settings**.
+
+3.  Name the new policy, and under **Select and then configure the custom settings for client devices**, select the **Software Inventory** check box, as shown in Figure 8.
+
+    ![Create Custom Client Device Settings](images/dg-fig19-customsettings.png)
+
+    Figure 8. Select custom settings
+
+4.  In the navigation pane, click **Software Inventory**, and then click **Set Types**, as shown in Figure 9.
+
+    ![Software Inventory settings for devices](images/dg-fig20-setsoftwareinv.png)
+
+    Figure 9. Set the software inventory
+
+5.  In the **Configure Client Setting** dialog box, click the **Start** button to open the **Inventories File Properties** dialog box.
+
+6.  In the **Name** box, type a name such as **\*Contoso.cat**, and then click **Set**.
+
+    > **Note**&nbsp;&nbsp;When typing the name, follow your naming convention for catalog files.
+
+7.  In the **Path Properties** dialog box, select **Variable or path name**, and then type **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}** in the box, as shown in Figure 10.
+
+    ![Path Properties, specifying a path](images/dg-fig21-pathproperties.png)
+
+    Figure 10. Set the path properties
+
+8.  Click **OK**.
+
+9.  Now that you have created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
+
+At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you will be able to view the inventoried files in the built-in System Center Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
+
+1.  Open the Configuration Manager console, and select the Assets and Compliance workspace.
+
+2.  Navigate to Overview\\Devices, and search for the device on which you want to view the inventoried files.
+
+3.  Right-click the computer, point to **Start**, and then click **Resource Explorer**.
+
+4.  In Resource Explorer, navigate to Software\\File Details to view the inventoried catalog files.
+
+> **Note**&nbsp;&nbsp;If nothing is displayed in this view, navigate to Software\\Last Software Scan in Resource Explorer to verify that the client has recently completed a software inventory scan.
+
+## Related topics
+
+- [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+
+- [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
+
+- [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+
diff --git a/windows/keep-secure/deploy-code-integrity-policies-policy-rules-and-file-rules.md b/windows/keep-secure/deploy-code-integrity-policies-policy-rules-and-file-rules.md
new file mode 100644
index 0000000000..f9cae0de10
--- /dev/null
+++ b/windows/keep-secure/deploy-code-integrity-policies-policy-rules-and-file-rules.md
@@ -0,0 +1,108 @@
+---
+title: Deploy code integrity policies - policy rules and file rules (Windows 10)
+description: This article provides information about two elements in code integrity policies, called policy rules and file rules. Code integrity policies are part of Device Guard in Windows 10. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Deploy code integrity policies: policy rules and file rules
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+Code integrity policies maintain the standards by which a computer running Windows 10 determines whether an application is trustworthy and can be run. For an overview of code integrity, 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) in "Introduction to Device Guard: virtualization-based security and code integrity policies."
+- [Code integrity policy formats and signing](requirements-and-deployment-planning-guidelines-for-device-guard.md#code-integrity-policy-formats-and-signing) in "Requirements and deployment planning guidelines for Device Guard."
+
+If you already understand the basics of code integrity policy and want procedures for creating, auditing, and merging code integrity policies, see [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md).
+
+This topic includes the following sections:
+
+- [Overview of the process of creating code integrity policies](#overview-of-the-process-of-creating-code-integrity-policies): Helps familiarize you with the process described in this and related topics.
+- [Code integrity policy rules](#code-integrity-policy-rules): Describes one key element you specify in a policy, the *policy rules*, which control options such as audit mode or whether UMCI is enabled in a code integrity policy.
+- [Code integrity file rule levels](#code-integrity-file-rule-levels): Describes the other key element you specify in a policy, the *file rules* (or *file rule levels*), which specify the level at which applications will be identified and trusted.
+
+## Overview of the process of creating code integrity policies
+
+A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. Code integrity policies follow a similar methodology, that begins with the establishment of a golden computer. As with imaging, you can have multiple golden computers based on model, department, application set, and so on. Although the thought process around the creation of code integrity policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional code integrity policies based on what should be allowed to be installed and run and for whom. For more details on doing this assessment, see the planning steps in [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+
+> **Note**&nbsp;&nbsp;Each computer can have only **one** code integrity policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to C:\\Windows\\System32\\CodeIntegrity. Keep this in mind when you create your code integrity policies.
+
+Optionally, code integrity policies can align with your software catalog as well as any IT department–approved applications. One straightforward method to implement code integrity policies is to use existing images to create one master code integrity policy. You do so by creating a code integrity policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, if the applications are installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
+
+If you plan to use an internal CA to sign catalog files or code integrity policies, see the steps in [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md). 
+
+## Code integrity policy rules
+
+Code integrity policies include *policy rules*, which control options such as audit mode or whether UMCI is enabled in a code integrity policy. You can modify these options in a new or existing code integrity policy. (For information about *file rules*, which specify the level at which applications will be identified and trusted, see the next section, [Code integrity file rule levels](#code-integrity-file-rule-levels).)
+
+To modify the policy rule options of an existing code integrity policy, use the [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) Windows PowerShell cmdlet. Note the following examples of how to use this cmdlet to add and remove a rule option on an existing code integrity policy:
+
+-   To enable UMCI, add rule option 0 to an existing policy by running the following command:
+
+    ` Set-RuleOption -FilePath <Path to policy> -Option 0`
+
+-   To disable UMCI on an existing code integrity policy, delete rule option 0 by running the following command:
+
+    ` Set-RuleOption -FilePath <Path to policy> -Option 0 -Delete`
+
+You can set several rule options within a code integrity policy. To display a list of rule options, you can type **Set-
+RuleOption -Help** in a Windows PowerShell session. Table 2 describes each rule option. 
+
+> **Note**&nbsp;&nbsp;**Enabled:Audit Mode** is an important rule option. We recommend that you use this option for a period of time with all new code integrity policies, because it allows you to test them before you enforce them. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. To expand the policy so that (when enforced) it will allow these applications, you can use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy.
+
+> The mode—audit mode or enforced mode—is set by including or deleting **Enabled:Audit Mode** in the code integrity policy. When this option is deleted, the policy runs in enforced mode.
+
+**Table 2. Code integrity policy - policy rule options**
+
+| Rule option | Description |
+|------------ | ----------- |
+| **0 Enabled:UMCI** | Code integrity policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
+| **1 Enabled:Boot Menu Protection** | This option is not currently supported. |
+| **2 Required:WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Going forward, every new Windows 10–compatible driver must be WHQL certified. |
+| **3 Enabled:Audit Mode (Default)** | Enables the execution of binaries outside of the code integrity policy but logs each occurrence in the CodeIntegrity event log, which can be used to update the existing policy before enforcement. To begin enforcing a code integrity policy, delete this option. |
+| **4 Disabled:Flight Signing** | If enabled, code integrity policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flighted builds. |
+| **5 Enabled:Inherent Default Policy** | This option is not currently supported. |
+| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. |
+| **7 Allowed:Debug Policy Augmented** | This option is not currently supported. |
+| **8 Required:EV Signers** | In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement. |
+| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all code integrity policies. Setting this rule option allows the F8 menu to appear to physically present users. |
+| **10 Enabled:Boot Audit on Failure** | Used when the code integrity policy is in enforcement mode. When a driver fails during startup, the code integrity policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
+
+## Code integrity file rule levels
+
+File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as fine-tuned as the hash of each binary or as general as a CA certificate. You specify file rule levels both when you create a new code integrity policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, code integrity policies combine their file rules, so that any application that would be allowed by either of the original policies will be allowed by the combined policy. 
+
+Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Device Guard deployment scenario.
+
+<!-- Need to confirm these updated table rows:
+    | **SignedVersion** | This combines the publisher rule with a version number. This option allows anything from the specified publisher, with a version at or above the specified version number, to run. |
+    | **FilePublisher** | This is a combination of the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
+--> 
+
+Table 3. Code integrity policy - file rule levels
+
+| Rule level | Description |
+|----------- | ----------- |
+| **Hash** | Specifies individual hash values for each discovered binary. Although this level is specific, it can cause additional administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
+| **FileName** | Specifies individual binary file names. Although the hash values for an application are modified when updated, the file names are typically not. This offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
+| **SignedVersion** | This combines the publisher rule with a version number. This option allows anything from the specified publisher, with a version at or above the specified version number, to run. |
+| **Publisher** | This is a combination of the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. This rule level allows organizations to trust a certificate from a major CA (such as Symantec), but only if the leaf certificate is from a specific company (such as Intel, for device drivers). |
+| **FilePublisher** | This is a combination of the “FileName” attribute of the signed file, plus “Publisher” (PCA certificate with CN of leaf), plus a minimum version number. This option trusts specific files from the specified publisher, with a version at or above the specified version number. |
+| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than CA certificates, so additional administrative overhead is associated with updating the code integrity policy when these certificates expire. |
+| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This is typically one certificate below the root certificate, because the scan does not validate anything beyond the certificates included in the provided signature (it does not go online or check local root stores). |
+| **RootCertificate** | Currently unsupported. |
+| **WHQL** | Trusts binaries if they have been validated and signed by WHQL. This is primarily for kernel binaries. |
+| **WHQLPublisher** | This is a combination of the WHQL and the CN on the leaf certificate and is primarily for kernel binaries. |
+| **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This is primarily for kernel binaries. |
+
+> **Note**&nbsp;&nbsp;When you create code integrity policies with the [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) cmdlet, you can specify a primary file rule level by including the **–Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **–Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
+
+## Related topics
+
+- [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)
+- [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
+
diff --git a/windows/keep-secure/deploy-code-integrity-policies-steps.md b/windows/keep-secure/deploy-code-integrity-policies-steps.md
new file mode 100644
index 0000000000..d9fa657c72
--- /dev/null
+++ b/windows/keep-secure/deploy-code-integrity-policies-steps.md
@@ -0,0 +1,384 @@
+---
+title: Deploy code integrity policies - steps (Windows 10)
+description: This article describes how to deploy code integrity policies, one of the main features that are part of Device Guard in Windows 10. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Deploy code integrity policies: steps
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+For an overview of the process described in the following procedures, see [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md). To understand how the deployment of code integrity policies fits with other steps in the Device Guard deployment process, see [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+
+## Create a code integrity policy from a golden computer
+
+The process for creating a golden code integrity policy from a reference system is straightforward. This section outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First, for this example, you must initiate variables to be used during the creation process. Rather than using variables, you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the system for installed applications. When created, the policy file is converted to binary format so that Windows can consume its contents.
+
+> **Note**&nbsp;&nbsp;Before you begin this procedure, ensure that the reference PC is clean of viruses or malware. Each piece of installed software should be validated as trustworthy before you create this policy. Also, be sure that any software that you would like to be scanned is installed on the system before you create the code integrity policy.
+
+To create a code integrity policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
+
+1.  Initialize variables that you will use. The following example commands use **InitialScan.xml** and **DeviceGuardPolicy.bin** for the names of the files that will be created:
+
+    ` $CIPolicyPath=$env:userprofile+"\Desktop\"`
+
+    ` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
+
+    ` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
+
+2.  Use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to create a new code integrity policy by scanning the system for installed applications:
+
+    ` New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt `
+
+    > **Notes**
+    
+    > - By specifying the *–UserPEs* parameter, rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. If you do not specify this parameter, to enable UMCI, use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) as shown in the following command:<br>**Set-RuleOption -FilePath $InitialCIPolicy -Option 0** 
+
+    > - You can add the *–Fallback* parameter to catch any applications not discovered using the primary file rule level specified by the *–Level* parameter. For more information about file rule level options, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in “Deploy code integrity policies: policy rules and file rules.”
+
+    > - To specify that the code integrity policy scan only a specific drive, include the *–ScanPath* parameter followed by a path. Without this parameter, the entire system is scanned.
+    
+    > - The preceding example includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
+
+3.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the code integrity policy to a binary format:
+
+    ` ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
+
+After you complete these steps, the Device Guard binary file (DeviceGuardPolicy.bin) and original .xml file (IntialScan.xml) will be available on your desktop. You can use the binary version as a code integrity policy or sign it for additional security.
+
+> **Note**&nbsp;&nbsp;We recommend that you keep the original .xml file of the policy for use when you need to merge the code integrity policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge code integrity policies, see [Merge code integrity policies](#merge-code-integrity-policies).
+
+We recommend that every code integrity policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error message dialog boxes. For information about how to audit a code integrity policy, see the next section, [Audit code integrity policies](#audit-code-integrity-policies).
+
+## Audit code integrity policies
+
+When code integrity policies are run in audit mode, it allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a code integrity policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. When these logged binaries have been validated, they can easily be added to a new code integrity policy. When the new exception policy is created, you can merge it with your existing code integrity policies.
+
+> **Note**&nbsp;&nbsp;Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer), earlier in this topic, for a step-by-step walkthrough of the process to create a code integrity policy and convert it to binary format.
+
+**To audit a code integrity policy with local policy:**
+
+1.  Find a *.bin policy file that you have created, for example, the DeviceGuardPolicy.bin file that resulted from the steps in the earlier section, [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). Copy the file to C:\\Windows\\System32\\CodeIntegrity.
+
+2.  On the computer you want to run in audit mode, open the Local Group Policy Editor by running **GPEdit.msc**.
+
+    > **Notes**
+    
+    > - The computer that you will run in audit mode must be clean of viruses or malware. Otherwise, in the process that you follow after auditing the system, you might unintentionally merge in a code integrity policy that allows viruses or malware to run.
+    
+    > - An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into C:\\Windows\\System32\\CodeIntegrity, rather than deploy it by using the Local Group Policy Editor.
+    
+3.  Navigate to **Computer Configuration\\Administrative Templates\\System\\Device Guard**, and then select **Deploy Code Integrity Policy**. Enable this setting by using the appropriate file path, for example, C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 1.
+
+    > **Notes**
+    
+    > - The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). Also, this policy file does not need to be copied to every system. You can instead copy the code integrity policies to a file share to which all computer accounts have access.
+
+    > - Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers.
+
+    > - You might have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped onto the computers running Windows 10. We recommend that you make your code integrity policy names friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
+
+   ![Group Policy called Deploy Code Integrity Policy](images/dg-fig22-deploycode.png)
+
+   Figure 1. Deploy your code integrity policy
+
+4.  Restart the reference system for the code integrity policy to take effect.
+
+5.  Use the system as you normally would, and monitor code integrity events in the event log. While in audit mode, any exception to the deployed code integrity policy will be logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log, as shown in Figure 2.
+
+   ![Event showing exception to code integrity policy](images/dg-fig23-exceptionstocode.png)
+
+   Figure 2. Exceptions to the deployed code integrity policy
+
+   You will be reviewing the exceptions that appear in the event log, and making a list of any applications that should be allowed to run in your environment.
+   
+6. If you want to create a catalog file to simplify the process of including unsigned LOB applications in your code integrity policy, this is a good time to create it. For information, see [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md).   
+
+Now that you have a code integrity policy deployed in audit mode, you can capture any audit information that appears in the event log. This is described in the next section.
+
+## Create a code integrity policy that captures audit information from the event log
+
+Use the following procedure after you have been running a computer with a code integrity policy in audit mode for a period of time. When you are ready to capture the needed policy information from the event log (so that you can later merge that information into the original code integrity policy), complete the following steps. 
+
+<!-- Watch the phrase "later step in this procedure" in step 1, in case the organization of the procedures changes. -->
+
+1.  Review the audit information in the event log. From the code integrity policy exceptions that you see, make a list of any applications that should be allowed to run in your environment, and decide on the file rule level that should be used to trust these applications.
+
+    Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of them. For information about file rule levels, see [Code integrity file rule levels](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-file-rule-levels) in "Deploy code integrity policies: policy rules and file rules."
+    
+    Your event log might also contain exceptions for applications that you eventually want your code integrity policy to block. If these appear, make a list of these also, for a later step in this procedure.
+
+2.  In an elevated Windows PowerShell session, initialize the variables that will be used. The example filename shown here is **DeviceGuardAuditPolicy.xml**:
+
+    ` $CIPolicyPath=$env:userprofile+"\Desktop\"`
+
+    ` $CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
+
+3.  Use [New-CIPolicy](https://technet.microsoft.com/library/mt634473.aspx) to generate a new code integrity policy from logged audit events. This example uses a file rule level of **Hash** and includes `3> CIPolicylog.txt`, which redirects warning messages to a text file, **CIPolicylog.txt**.
+
+    ` New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
+
+    > **Note**&nbsp;&nbsp;When you create policies from audit events, you should carefully consider the file rule level that you select to trust. The preceding example uses the **Hash** rule level, which is the most specific. Any change to the file (such as replacing the file with a newer version of the same file) will change the Hash value, and require an update to the policy.
+
+4.  Find and review the Device Guard audit policy .xml file that you created. If you used the example variables as shown, the filename will be **DeviceGuardAuditPolicy.xml**, and it will be on your desktop. Look for the following:
+
+    - Any applications that were caught as exceptions, but should be allowed to run in your environment. These are applications that should be in the .xml file. Leave these as-is in the file.
+    
+    - Any applications that actually should not be allowed to run in your environment. Edit these out of the .xml file. If they remain in the .xml file, and the information in the file is merged into your existing code integrity policy, the policy will treat the applications as trusted, and allow them to run. 
+
+You can now use this file to update the existing code integrity policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing code integrity policy, see the next section, [Merge code integrity policies](#merge-code-integrity-policies).
+
+> **Note**&nbsp;&nbsp;You may have noticed that you did not generate a binary version of this policy as you did in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). This is because code integrity policies created from an audit log are not intended to run as stand-alone policies but rather to update existing code integrity policies.
+
+## Merge code integrity policies
+
+When you develop code integrity policies, you will occasionally need to merge two policies. A common example is when a code integrity policy is initially created and audited. Another example is when you create a single master policy by using multiple code integrity policies previously created from golden computers. Because each computer running Windows 10 can have only one code integrity policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary code integrity policy that you then merge with the initial code integrity policy.
+
+> **Note**&nbsp;&nbsp;The following example uses the code integrity policy .xml files that you created in earlier sections in this topic. You can follow this process, however, with any two code integrity policies you would like to combine.
+
+To merge two code integrity policies, complete the following steps in an elevated Windows PowerShell session:
+
+1.  Initialize the variables that will be used:
+
+    ` $CIPolicyPath=$env:userprofile+"\Desktop\"`
+
+    ` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
+
+    ` $AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
+
+    ` $MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"`
+
+    ` $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"`
+
+    > **Note**&nbsp;&nbsp;The variables in this section specifically expect to find an initial policy on your desktop called **InitialScan.xml** and an audit code integrity policy called **DeviceGuardAuditPolicy.xml**. If you want to merge other code integrity policies, update the variables accordingly.
+
+2.  Use [Merge-CIPolicy](https://technet.microsoft.com/library/mt634485.aspx) to merge two policies and create a new code integrity policy:
+
+    ` Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy`
+
+3.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the merged code integrity policy to binary format:
+
+    ` ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin `
+
+Now that you have created a new code integrity policy (for example, called **NewDeviceGuardPolicy.bin**), you can deploy the policy to systems manually or by using Group Policy or Microsoft client management solutions. For information about how to deploy this new policy with Group Policy, see the [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy) section.
+
+## Enforce code integrity policies
+
+Every code integrity policy is created with audit mode enabled. After you have successfully deployed and tested a code integrity policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
+
+> **Note**&nbsp;&nbsp;Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies, see [Audit code integrity policies](#audit-code-integrity-policies), earlier in this topic.
+
+1.  Initialize the variables that will be used:
+
+    ` $CIPolicyPath=$env:userprofile+"\Desktop\"`
+
+    ` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" `
+
+    ` $EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"`
+
+    ` $CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"`
+
+    > **Note**&nbsp;&nbsp;The initial code integrity policy that this section refers to was created in the [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer) section. If you are using a different code integrity policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
+
+2. Ensure that rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) are set the way that you intend for this policy. We strongly recommend that you enable these rule options before you run any enforced policy for the first time. Enabling these options provides administrators with a pre-boot command prompt, and allows Windows to start even if the code integrity policy blocks a kernel-mode driver from running. When ready for enterprise deployment, you can remove these options.
+
+    To ensure that these options are enabled in a policy, use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) as shown in the following commands. You can run these commands even if you're not sure whether options 9 and 10 are already enabled—if so, the commands have no effect.
+    
+    ` Set-RuleOption -FilePath $InitialCIPolicy -Option 9`
+    
+    ` Set-RuleOption -FilePath $InitialCIPolicy -Option 10`
+
+3.  Copy the initial file to maintain an original copy:
+
+    ` copy $InitialCIPolicy $EnforcedCIPolicy`
+
+4.  Use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) to delete the audit mode rule option:
+
+    ` Set-RuleOption -FilePath $EnforcedCIPolicy -Option 3 -Delete`
+
+    > **Note**&nbsp;&nbsp;To enforce a code integrity policy, you delete option 3, the **Audit Mode Enabled** option. There is no “enforced” option that can be placed in a code integrity policy.
+
+5.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the new code integrity policy to binary format:
+
+    ` ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin`
+
+Now that this policy is in enforced mode, you can deploy it to your test computers. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy). You can also use other client management software to deploy and manage the policy.
+
+## Signing code integrity policies with SignTool.exe
+
+Signed code integrity policies give organizations the highest level of malware protection available in Windows 10. In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the computer. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed code integrity policies than unsigned ones. Before you sign and deploy a signed code integrity policy, we recommend that you audit the policy to discover any blocked applications that should be allowed to run. For more information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
+
+Signing code integrity policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward. If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) to create one with your on-premises CA. 
+
+Before signing code integrity policies for the first time, be sure to enable rule options 9 (“Advanced Boot Options Menu”) and 10 (“Boot Audit on Failure”) to leave troubleshooting options available to administrators. To ensure that a rule option is enabled, you can run a command such as `Set-RuleOption -FilePath <PathAndFilename> -Option 9` even if you're not sure whether the option is already enabled—if so, the command has no effect. When validated and ready for enterprise deployment, you can remove these options. For more information about rule options, see [Code integrity policy rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md#code-integrity-policy-rules) in "Deploy code integrity policies: policy rules and file rules."
+
+> **Note**&nbsp;&nbsp;Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers, be sure to test its effect on a subset of computers.
+
+To sign a code integrity policy with SignTool.exe, you need the following components:
+
+-   SignTool.exe, found in the Windows SDK (Windows 7 or later)
+
+-   The binary format of the code integrity policy that you generated in the [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer) section or another code integrity policy that you have created
+
+-   An internal CA code signing certificate or a purchased code signing certificate
+
+If you do not have a code signing certificate, see the [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md) section for instructions on how to create one. If you use an alternate certificate or code integrity policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing code integrity policy, copy each of the following commands into an elevated Windows PowerShell session:
+
+1.  Initialize the variables that will be used:
+
+    ` $CIPolicyPath=$env:userprofile+"\Desktop\"`
+    
+    ` $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
+    
+    ` $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
+
+    > **Note**&nbsp;&nbsp;This example uses the code integrity policy that you created in the [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
+
+2.  Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the code integrity policy into the signing user’s personal store on the computer that will be doing the signing. In this example, you use the certificate that was created in [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md).
+
+3.  Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer version to your desktop. This version will be added to the policy so that it can be updated later.
+
+4.  Navigate to your desktop as the working directory:
+
+    ` cd $env:USERPROFILE\Desktop `
+
+5.  Use [Add-SignerRule](https://technet.microsoft.com/library/mt634479.aspx) to add an update signer certificate to the code integrity policy:
+
+    ` Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
+
+   > **Notes**&nbsp;&nbsp;*&lt;Path to exported .cer certificate&gt;* should be the full path to the certificate that you exported in step 3.
+   
+   > Also, adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed code integrity policies, see the [Disable signed code integrity policies within Windows](#disable-signed-code-integrity-policies-within-windows) section.
+
+6.  Use [Set-RuleOption](https://technet.microsoft.com/library/mt634483.aspx) to remove the unsigned policy rule option:
+
+    ` Set-RuleOption -FilePath $InitialCIPolicy -Option 6 -Delete`
+
+7.  Use [ConvertFrom-CIPolicy](https://technet.microsoft.com/library/mt733073.aspx) to convert the policy to binary format:
+
+    ` ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
+
+8.  Sign the code integrity policy by using SignTool.exe:
+
+    ` <Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
+
+    > **Note**&nbsp;&nbsp;The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the code integrity policy. You should import this certificate to your personal certificate store on the computer you use to sign the policy.
+
+9.  Validate the signed file. When complete, the commands should output a signed policy file called DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy code integrity policies, see [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy).
+
+## Disable unsigned code integrity policies
+
+There may come a time when an administrator wants to disable a code integrity policy. For unsigned code integrity policies, this process is simple. Depending on how the code integrity policy was deployed, unsigned policies can be disabled in one of two ways. If a code integrity policy was manually enabled and copied to the code integrity folder location, simply delete the file and restart the computer. The following locations can contain executing code integrity policies:
+
+-   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
+
+-   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
+
+If the code integrity policy was deployed by using Group Policy, the GPO that is currently enabling and deploying the policy must be set to disabled. Then, the code integrity policy will be disabled on the next computer restart.
+
+## Disable signed code integrity policies within Windows
+
+Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed code integrity policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed code integrity policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps.
+
+> **Note**&nbsp;&nbsp;For reference, signed code integrity policies should be replaced and removed from the following locations:
+
+-   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
+
+-   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
+
+
+1.  Replace the existing policy with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
+
+    > **Note**&nbsp;&nbsp;To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
+
+2.  Restart the client computer.
+
+3.  Verify that the new signed policy exists on the client.
+
+    > **Note**&nbsp;&nbsp;If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
+
+4.  Delete the new policy.
+
+5.  Restart the client computer.
+
+If the signed code integrity policy has been deployed using by using Group Policy, you must complete the following steps:
+
+1.  Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
+
+    > **Note**&nbsp;&nbsp;To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
+
+2.  Restart the client computer.
+
+3.  Verify that the new signed policy exists on the client.
+
+    > **Note**&nbsp;&nbsp;If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
+
+4.  Set the GPO to disabled.
+
+5.  Delete the new policy.
+
+6.  Restart the client computer.
+
+## Disable signed code integrity policies within the BIOS
+
+There may be a time when signed code integrity policies cause a boot failure. Because code integrity policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed code integrity policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
+
+-   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
+
+-   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
+
+## Deploy and manage code integrity policies with Group Policy
+
+Code integrity policies can easily be deployed and managed with Group Policy. A Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Device Guard hardware-based security features and code integrity policies. The following procedure walks you through how to deploy a code integrity policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
+
+> **Note**&nbsp;&nbsp;This walkthrough requires that you have previously created a code integrity policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer), earlier in this topic.
+
+> **Note**&nbsp;&nbsp;Signed code integrity policies can cause boot failures when deployed. We recommend that signed code integrity policies be thoroughly tested on each hardware platform before enterprise deployment.
+
+To deploy and manage a code integrity policy with Group Policy:
+
+1.  On a domain controller on a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** or searching for “Group Policy Management” in Windows Search.
+
+2.  Create a new GPO: right-click an OU, for example, the **DG Enabled PCs OU**, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 3.
+
+    > **Note**&nbsp;&nbsp;You can use any OU name. Also, security group filtering is an option when you consider different ways of combining code integrity policies (or keeping them separate), as discussed in [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+
+   ![Group Policy Management, create a GPO](images/dg-fig24-creategpo.png)
+
+   Figure 3. Create a GPO
+
+3.  Name new GPO **Contoso GPO Test**. This example uses Contoso GPO Test as the name of the GPO. You can choose any name that you prefer for this example.
+
+4.  Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
+
+5.  In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Deploy Code Integrity Policy** and then click **Edit**.
+
+    ![Edit the group policy for code integrity](images/dg-fig25-editcode.png)
+
+    Figure 4. Edit the group policy for code integrity
+
+6.  In the **Display Code Integrity Policy** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
+
+   In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. For example, with DeviceGuardPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 5.
+
+    > **Note**&nbsp;&nbsp;The illustration shows the example file name *DeviceGuardPolicy.bin* because this name was used earlier in this topic, in [Create a code integrity policy from a golden computer](#create-a-code-integrity-policy-from-a-golden-computer). Also, this policy file does not need to be copied to every computer. You can instead copy the code integrity policies to a file share to which all computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
+
+   ![Group Policy called Deploy Code Integrity Policy](images/dg-fig26-enablecode.png)
+
+   Figure 5. Enable the code integrity policy
+
+    > **Note**&nbsp;&nbsp;You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the client computer running Windows 10. Make your code integrity policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
+
+7.  Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the code integrity policy. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
+
+## Related topics
+
+[Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+
+[Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
+
diff --git a/windows/keep-secure/deploy-device-guard-deploy-code-integrity-policies.md b/windows/keep-secure/deploy-device-guard-deploy-code-integrity-policies.md
new file mode 100644
index 0000000000..02ce631862
--- /dev/null
+++ b/windows/keep-secure/deploy-device-guard-deploy-code-integrity-policies.md
@@ -0,0 +1,30 @@
+---
+title: Deploy Device Guard - deploy code integrity policies (Windows 10)
+description: This article, and the articles it links to, describe how to create code integrity policies, one of the main features that are part of Device Guard in Windows 10. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Deploy Device Guard: deploy code integrity policies
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This section includes the following topics:
+
+- [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md)
+- [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
+- [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
+- [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md)
+
+To increase the protection for devices that meet certain hardware requirements, you can use virtualization-based security (VBS) with your code integrity policies.
+- For requirements, see [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) in "Requirements and deployment planning guidelines for Device Guard."
+- For steps, see [Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md).
+
+## Related topics
+
+[Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+
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
new file mode 100644
index 0000000000..9eda4d82c8
--- /dev/null
+++ b/windows/keep-secure/deploy-device-guard-enable-virtualization-based-security.md
@@ -0,0 +1,246 @@
+---
+title: Deploy Device Guard - enable virtualization-based security (Windows 10)
+description: This article describes how to enable virtualization-based security, one of the main features that are part of Device Guard in Windows 10. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Deploy Device Guard: enable virtualization-based security
+
+**Applies to**
+-   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:
+
+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).
+
+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).
+
+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:
+
+    - [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)
+
+For information about enabling Credential Guard, see [Protect derived domain credentials with Credential Guard](credential-guard.md).
+
+## Windows feature requirements for virtualization-based security
+
+In addition to the hardware requirements 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), you must enable certain operating system features before you can enable VBS: Microsoft Hyper-V and isolated user mode (shown in Figure 1).
+
+> **Note**&nbsp;&nbsp;You can configure these features manually by using Windows PowerShell or Deployment Image Servicing and Management. For specific information about these methods, see [Protect derived domain credentials with Credential Guard](credential-guard.md).
+ 
+![Turn Windows features on or off](images/dg-fig1-enableos.png)
+
+Figure 1. Enable operating system features for VBS
+
+After you enable these 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)
+
+## Enable Unified Extensible Firmware Interface Secure Boot
+
+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**&nbsp;&nbsp;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.
+
+1.  Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
+
+2.  Set the **EnableVirtualizationBasedSecurity DWORD** value to **1**.
+
+3.  Set the **RequirePlatformSecurityFeatures DWORD** value as appropriate:
+
+    -   Set this value to **1** to enable the **Secure Boot** option.
+
+    -   Set this value to **2** to enable the **Secure Boot with DMA Protection** option.
+
+4.  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 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.
+
+> **Note**&nbsp;&nbsp;We recommend that you test-enable this feature on a group of test computers before you deploy it to users' computers.
+
+### Use Group Policy to deploy Secure Boot
+
+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**.
+
+    ![Group Policy Management, create a GPO](images/dg-fig2-createou.png)
+
+    Figure 5. 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.
+
+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**.
+
+    ![Edit the group policy for Virtualization Based Security](images/dg-fig3-enablevbs.png)
+
+    Figure 6. Enable VBS
+
+5.  Select the **Enabled** option, and then select **Secure Boot and DMA Protection** from the **Select Platform Security Level** list.
+
+    ![Group Policy, Turn On Virtualization Based Security](images/device-guard-gp.png)
+
+    Figure 7. Enable Secure Boot
+
+    > **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.
+
+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.
+
+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**&nbsp;&nbsp;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 **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
+
+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**&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:**
+
+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
+
+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**.
+
+    ![Edit the group policy for Virtualization Based Security](images/dg-fig6-enablevbs.png)
+
+    Figure 3. Enable VBS
+
+5.  Select the **Enabled** option, and then 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
+
+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.  Check the test client 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.
+
+**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:
+
+` Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard`
+
+> **Note**&nbsp;&nbsp;The *Win32\_DeviceGuard* WMI class is only available on the Enterprise edition of Windows 10.
+
+The output of this command provides details of the available hardware-based security features as well as those features that are currently enabled. For detailed information about what each property means, refer to Table 1.
+
+Table 1. Win32\_DeviceGuard properties
+
+<table>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th align="left"><strong>Properties</strong></th>
+<th align="left"><strong>Description</strong></th>
+<th align="left"><strong>Valid values</strong></th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td align="left"><strong>AvailableSecurityProperties</strong></td>
+<td align="left">This field helps to enumerate and report state on the relevant security properties for Device Guard.</td>
+<td align="left"><ul>
+<li><p><strong>0.</strong> If present, no relevant properties exist on the device.</p></li>
+<li><p><strong>1.</strong> If present, hypervisor support is available.</p></li>
+<li><p><strong>2.</strong> If present, Secure Boot is available.</p></li>
+<li><p><strong>3.</strong> If present, DMA protection is available.</p></li>
+</ul></td>
+</tr>
+<tr class="even">
+<td align="left"><strong>InstanceIdentifier</strong></td>
+<td align="left">A string that is unique to a particular device.</td>
+<td align="left">Determined by WMI.</td>
+</tr>
+<tr class="odd">
+<td align="left"><strong>RequiredSecurityProperties</strong></td>
+<td align="left">This field describes the required security properties to enable virtualization-based security.</td>
+<td align="left"><ul>
+<li><p><strong>0.</strong> Nothing is required.</p></li>
+<li><p><strong>1.</strong> If present, Secure Boot is needed.</p></li>
+<li><p><strong>2.</strong> If present, DMA protection is needed.</p></li>
+<li><p><strong>3.</strong> If present, both Secure Boot and DMA protection are needed.</p></li>
+</ul></td>
+</tr>
+<tr class="even">
+<td align="left"><strong>SecurityServicesConfigured</strong></td>
+<td align="left">This field indicates whether the Credential Guard or HVCI service has been configured.</td>
+<td align="left"><ul>
+<li><p><strong>0.</strong> No services configured.</p></li>
+<li><p><strong>1.</strong> If present, Credential Guard is configured.</p></li>
+<li><p><strong>2.</strong> If present, HVCI is configured.</p></li>
+</ul></td>
+</tr>
+<tr class="odd">
+<td align="left"><strong>SecurityServicesRunning</strong></td>
+<td align="left">This field indicates whether the Credential Guard or HVCI service is running.</td>
+<td align="left"><ul>
+<li><p><strong>0.</strong> No services running.</p></li>
+<li><p><strong>1.</strong> If present, Credential Guard is running.</p></li>
+<li><p><strong>2.</strong> If present, HVCI is running.</p></li>
+</ul></td>
+</tr>
+<tr class="even">
+<td align="left"><strong>Version</strong></td>
+<td align="left">This field lists the version of this WMI class.</td>
+<td align="left">The only valid value now is <strong>1.0</strong>.</td>
+</tr>
+<tr class="odd">
+<td align="left"><strong>VirtualizationBasedSecurityStatus</strong></td>
+<td align="left">This field indicates whether VBS is enabled and running.</td>
+<td align="left"><ul>
+<li><p><strong>0.</strong> VBS is not enabled.</p></li>
+<li><p><strong>1.</strong> VBS is enabled but not running.</p></li>
+<li><p><strong>2.</strong> VBS is enabled and running.</p></li>
+</ul></td>
+</tr>
+<tr class="even">
+<td align="left"><strong>PSComputerName</strong></td>
+<td align="left">This field lists the computer name.</td>
+<td align="left">All valid values for computer name.</td>
+</tr>
+</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.
+
+![Device Guard properties in the System Summary](images/dg-fig11-dgproperties.png)
+
+Figure 11. Device Guard properties in the System Summary
+
+## Related topics
+
+- [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+
+- [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
diff --git a/windows/keep-secure/device-guard-certification-and-compliance.md b/windows/keep-secure/device-guard-certification-and-compliance.md
index 6ac463047e..5e60c5e980 100644
--- a/windows/keep-secure/device-guard-certification-and-compliance.md
+++ b/windows/keep-secure/device-guard-certification-and-compliance.md
@@ -1,107 +1,4 @@
 ---
 title: Device Guard certification and compliance (Windows 10)
-description: Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications.
-ms.assetid: 94167ECA-AB08-431D-95E5-7A363F42C7E3
-ms.pagetype: security
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.sitesec: library
-author: brianlic-msft
+redirect_url: device-guard-deployment-guide.md
 ---
-# Device Guard certification and compliance
-**Applies to**
--   Windows 10
-
-Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when.
-Device Guard uses the new virtualization-based security in Windows 10 to isolate the Code Integrity service from the Windows kernel itself, letting the service use signatures defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
-For details on how to implement Device Guard, see [Device Guard deployment guide](device-guard-deployment-guide.md).
-## Why use Device Guard
-With thousands of new malicious files created every day, using traditional methods like signature-based detection to fight against malware provides an inadequate defense against new attacks. Device Guard on Windows 10 changes from a mode where apps are trusted unless blocked by an antivirus or other security solutions, to a mode where the operating system trusts only apps authorized by your enterprise.
-Device Guard also helps protect against [zero day attacks](http://go.microsoft.com/fwlink/p/?linkid=534209) and works to combat the challenges of [polymorphic viruses](http://go.microsoft.com/fwlink/p/?LinkId=534210).
-
-### Advantages to using Device Guard
-
-You can take advantage of the benefits of Device Guard, based on what you turn on and use:
--   Helps provide strong malware protection with enterprise manageability
--   Helps provide the most advanced malware protection ever offered on the Windows platform
--   Offers improved tamper resistance
-
-## How Device Guard works
-
-Device Guard restricts the Windows 10 operating system to only running code that’s signed by trusted signers, as defined by your Code Integrity policy through specific hardware and security configurations, including:
--   User Mode Code Integrity (UMCI)
--   New kernel code integrity rules (including the new Windows Hardware Quality Labs (WHQL) signing constraints)
--   Secure Boot with database (db/dbx) restrictions
--   Virtualization-based security to help protect system memory and kernel mode apps and drivers from possible tampering.
--   Optional: Trusted Platform Module (TPM) 1.2 or 2.0
-Device Guard works with your image-building process, so you can turn the virtualization-based security feature on for capable devices, configure your Code Integrity policy, and set any other operating system settings you require for Windows 10. After that, Device Guard works to help protect your devices:
-1.  Your device starts up using Universal Extensible Firmware Interface (UEFI) Secure Boot, so that boot kits can’t run and so that Windows 10 starts before anything else.
-2.  After securely starting up the Windows boot components, Windows 10 can start the Hyper-V virtualization-based security services, including Kernel Mode Code Integrity. These services help protect the system core (kernel), privileged drivers, and system defenses, like anti-malware solutions, by preventing malware from running early in the boot process, or in kernel after startup.
-3.  Device Guard uses UMCI to make sure that anything that runs in User mode, such as a service, a Universal Windows Platform (UWP) app, or a Classic Windows application is trusted, allowing only trusted binaries to run.
-4.  At the same time that Windows 10 starts up, so too does the trusted platform module (TPM). TPM provides an isolated hardware component that helps protect sensitive information, such as user credentials and certificates.
-## Required hardware and software
-The following table shows the hardware and software you need to install and configure to implement Device Guard.
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">Requirement</th>
-<th align="left">Description</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><p>Windows 10 Enterprise</p></td>
-<td align="left"><p>The PC must be running Windows 10 Enterprise.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>UEFI firmware version 2.3.1 or higher with UEFI Secure Boot and Platform Secure Boot</p></td>
-<td align="left"><p>UEFI Secure Boot ensures that the device boots only authorized code. Additionally, Boot Integrity, also known as Platform Secure Boot must be supported. You can validate it against the following Windows Hardware Compatibility Program requirements:</p>
-<ul>
-<li><p>[System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot)</p></li>
-<li><p>[System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](http://msdn.microsoft.com/library/windows/hardware/dn932807.aspx#system-fundamentals-firmware-cs-uefisecureboot-connectedstandby)</p></li>
-</ul></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>Virtualization extensions</p></td>
-<td align="left"><p>The following virtualization extensions are required to support virtualization-based security:</p>
-<ul>
-<li>Intel VT-x or AMD-V</li>
-<li>Second Level Address Translation</li>
-</ul></td>
-</tr>
-<tr class="even">
-<td align="left"><p>Firmware lock</p></td>
-<td align="left"><ul>
-<li><p>The firmware setup should be locked to prevent other operating systems from starting and to prevent changes to the UEFI settings.</p></li>
-<li><p>Work with your hardware manufacturer to ensure that the devices are Device Guard ready</p></li>
-<li><p>You should require a firmware password or higher authentication to change firmware settings.</p></li>
-</ul></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>x64 architecture</p></td>
-<td align="left"><p>The features that virtualization-based security uses in the Windows hypervisor can only run on a 64-bit PC.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>A VT-d or AMD-Vi IOMMU (Input/output memory management unit)</p></td>
-<td align="left"><p>In Windows 10, an IOMMU enhances system resiliency against memory attacks.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>Secure firmware update process</p></td>
-<td align="left"><p>To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement.</p><p>Device Guard relies on the security of the underlying hardware and firmware. It is critical to keep the firmware updated with the latest security fixes.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>Signed processor microcode updates</p></td>
-<td align="left"><p>If the processor supports it, you must require signed microcode updates.</p></td>
-</tr>
-</tbody>
-</table>
- 
-## Related topics
-[Get apps to run on Device Guard-protected devices](getting-apps-to-run-on-device-guard-protected-devices.md)
-[Create a Device Guard code integrity policy based on a reference device](creating-a-device-guard-policy-for-signed-apps.md)
- 
- 
diff --git a/windows/keep-secure/device-guard-deployment-guide.md b/windows/keep-secure/device-guard-deployment-guide.md
index f98d7216ea..e82f511105 100644
--- a/windows/keep-secure/device-guard-deployment-guide.md
+++ b/windows/keep-secure/device-guard-deployment-guide.md
@@ -5,1162 +5,49 @@ ms.assetid: 4BA52AA9-64D3-41F3-94B2-B87EC2717486
 keywords: virtualization, security, malware
 ms.prod: w10
 ms.mktglfcycl: deploy
-ms.pagetype: security, devices
-author: challum
+author: brianlic-msft
 ---
 
 # Device Guard deployment guide
 
 **Applies to**
--   Windows 10
+-   Windows 10
+-   Windows Server 2016
 
-Microsoft Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating system’s security. Windows 10 employs Device Guard as well as code integrity and advanced hardware features such as CPU virtualization extensions, Trusted Platform Module, and second-level address translation to offer comprehensive modern security to its users. This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them.
+Device Guard is a combination of enterprise-related hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications that you define in your code integrity policies. If the app isn’t trusted it can’t run, period. With hardware that meets basic requirements, it also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code. With appropriate hardware, Device Guard can use the new virtualization-based security in Windows 10 Enterprise to isolate the Code Integrity service from the Microsoft Windows kernel itself. In this case, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
 
-## Introduction to Device Guard
+This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them. It includes:
 
-Today’s security threat landscape is more aggressive than ever before. Modern malicious attacks are focused on revenue generation, intellectual property theft, and targeted system degradation, which results in financial loss. Many of these modern attackers are sponsored by nation states with unknown motives and large cyber terrorism budgets. These threats can enter a company through something as simple as an email message and can permanently damage its reputation for securing its software assets, as well as having significant financial impact. Windows 10 introduces several new security features that help mitigate a large percentage of today’s known threats.
+- [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
 
-It is estimated that more than 300,000 new malware variants are discovered daily. Unfortunately, companies currently use an ancient method to discover this infectious software and prevent its use. In fact, current PCs trust everything that runs until malware signatures determine whether a threat exists; then, the antimalware software attempts to clean the PC, often after the malicious software’s effect has already been noticed. This signature-based system focuses on reacting to an infection and ensuring that the particular infection does not happen again. In this model, the system that drives malware detection relies on the discovery of malicious software; only then can a signature be provided to the client to remediate it, which implies that a computer must be infected first. The time between the detection of the malware and a client being issued a signature could mean the difference between losing data and staying safe.
+- [Requirements and deployment planning guidelines for Device Guard](requirements-and-deployment-planning-guidelines-for-device-guard.md)
 
-In addition to antimalware solutions, there are some “whitelisting” technologies available, including AppLocker. These technologies perform single instance, or blanket-allow or blanket-deny rules for running applications. Although this is more preventative than signature-based detection, it requires significant ongoing maintenance. In Windows 10, these applications are most effective when they are deployed alongside Microsoft Device Guard.
+- [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
 
-Device Guard breaks the current model of detection first-block later, and allows only trusted applications to run, period. This methodology is consistent with the successful prevention strategy for mobile phone security. With Device Guard, Microsoft has changed how the Windows operating system handles untrusted applications, which makes its defenses difficult for malware to penetrate. This new prevention versus detection model provides Windows clients with the necessary security for modern threats and, when implemented, makes most of today’s threats completely obsolete from day one.
+- [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
 
-Device Guard's features revolutionize the Windows operating system’s security by taking advantage of new virtualization-based security (VBS) options and the trust-nothing mobile device operating system model, which makes its defenses much more difficult for malware to penetrate. By using configurable code integrity policies, organizations are able to choose exactly which applications are allowed to run in their environment. Configurable code integrity is not limited to Windows Store applications and can be used with existing unsigned or signed Win32 applications, without the requirement that the application be repackaged. In addition, configurable code integrity can be deployed as an individual feature if organizations don’t possess the required hardware for Device Guard. Along with code integrity, Windows 10 leverages advanced hardware features such as CPU virtualization extensions, input/output memory management units (IOMMUs), Trusted Platform Module (TPM), and second-level address translation (SLAT) to offer comprehensive modern security to its users. Device Guard deployed with configurable code integrity and Credential Guard will be among the most impactful client-side security deployments an organization can implement today. In this guide, you learn about the individual features found within Device Guard as well as how to plan for, configure, and deploy them. Device Guard with configurable code integrity is intended for deployment alongside additional threat-mitigating Windows features such as Credential Guard and AppLocker.
+    - [Optional: Create a code signing certificate for code integrity policies](optional-create-a-code-signing-certificate-for-code-integrity-policies.md)
 
-## Device Guard overview
-Device Guard is a feature set that consists of both hardware and software system integrity hardening features. These features revolutionize the Windows operating system’s security by taking advantage of new virtualization-based security options and the trust-nothing mobile device operating system model. A key feature in this model is called *configurable code integrity*, which allows your organization to choose exactly which software or trusted software publishers are allowed to run code on your client machines—exactly what has made mobile phone security so successful. In addition, Device Guard offers organizations a way to sign existing line-of-business (LOB) applications so that they can trust their own code, without the requirement that the application be repackaged. Also, this same method of signing provides organizations with a way to trust individual third-party applications. Device Guard—with configurable code integrity, Credential Guard, and AppLocker—is the most complete security defense that any Microsoft product has ever been able to offer a Windows client.
+    - [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
 
-Advanced hardware features such as CPU virtualization extensions, IOMMUs, and SLAT, drive these new client security offerings. By integrating these hardware features further into the core operating system, Windows 10 leverages them in new ways. For example, the same type 1 hypervisor technology that is used to run virtual machines in Microsoft Hyper-V is used to isolate core Windows services into a virtualization-based, protected container. This is just one example of how Windows 10 integrates advanced hardware features deeper into the operating system to offer comprehensive modern security to its users. These hardware features are now available in consumer and enterprise PC markets and are discussed in detail in the [Hardware considerations](#hardware-considerations) section.
+    - [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)
 
-Along with these new features, some components of Device Guard are existing tools or technologies that have been included in this strategic security offering to provide customers with the most secure Windows operating system possible. Device Guard is intended as a set of client security features to be used in conjunction with the other threat-resistance features available in the Windows operating system, some of which are mentioned in this guide. In addition to an overview of each feature, this guide walks you through the configuration and deployment of them.
+    - [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md)
 
-**Configurable code integrity**
-
-The Windows operating system consists of two operating modes: user mode and kernel mode. The base of the operating system runs within the kernel mode, which is where the Windows operating system directly interfaces with hardware resources. User mode is primarily responsible for running applications and brokering information to and from the kernel mode for hardware resource requests. For example, when an application that is running in user mode needs additional memory, the user mode process must request the resources from kernel mode, not directly from RAM.
-
-Code integrity is the component of the Windows operating system that verifies that the code Windows is running is trusted and safe. Like the operating system, Windows code integrity also contains two primary components: kernel mode code integrity (KMCI) and user mode code integrity (UMCI). KMCI has been used in recent versions of the Windows operating system to protect the kernel mode from running unsigned drivers. Although effective, drivers are not the only route that malware can take to penetrate the kernel mode space of the operating system. In Windows 10, however, Microsoft has raised the standard for kernel mode code out of the box as well as provided enterprises with a way to set their own UMCI and KMCI standards. Beginning with the Code Integrity service itself and continuing through the policies a Windows client uses to verify that an application should be allowed to run, Microsoft has made Windows 10 more secure than any previous Windows release. Historically, UMCI has been available only in Windows RT and on Windows Phone devices, which has made it difficult for these devices to be infected with viruses and malware. In Windows 10, these same successful UMCI standards are available.
-
-Historically, most malware has been unsigned. By simply deploying code integrity policies, organizations will immediately protect themselves against unsigned malware, which is estimated to be responsible for more than 95 percent of current attacks. By using code integrity policies, an enterprise can select exactly which binaries are allowed to run in both user mode and kernel mode, from the signer to the hash level. When completely enforced, it makes user mode in Windows function like a mobile phone, by allowing only specific applications or specific signatures to be trusted and run. This feature alone fundamentally changes the security in an enterprise. This additional security is not limited to Windows apps and does not require that an application be rewritten to be compatible with your existing, unsigned applications. You can implement configurable code integrity without enabling Device Guard, but it is intended to run in conjunction with Device Guard when supported hardware is available. For more information about how to configure, deploy, and manage code integrity policies, see the [Code integrity policies](#code-integrity-policies) section.
-
-**Hardware security features and virtualization-based security**
-
-The Device Guard core functionality and protection start at the hardware level. Devices that have processors equipped with SLAT technologies and virtualization extensions, such as Intel Virtualization Technology (VT-x) and AMD-V, will be able to take advantage of virtualization-based security (VBS) features that enhance Windows security. Device Guard leverages VBS to isolate core Windows services that are critical to the security and integrity of the operating system. This isolation removes the vulnerability of these services from both the user and kernel modes and acts as an impenetrable barrier for most malware used today. One of these isolated services, called the Windows Code Integrity service, drives the Device Guard kernel mode configurable code integrity feature. This prevents code that has penetrated the kernel mode operations from compromising the code integrity service.
-Another Windows 10 feature that employs VBS is Credential Guard. Credential Guard provides additional protection to Active Directory domain users by storing domain credentials within the virtualization container that hosts the Windows security services, such as code integrity. By isolating these domain credentials from the active user mode and kernel mode, they have a much lower risk of being stolen. For more information about how Credential Guard complements Device Guard, see the [Device Guard with Credential Guard](#device-guard-with-credential-guard) section. For information about how to enable Credential Guard, see the [Enable Credential Guard](#enable-credential-guard) section.
-
-**Device Guard with AppLocker**
-
-Although AppLocker is not considered a new Device Guard feature, it complements Device Guard functionality when enforced code integrity cannot be fully implemented or its functionality does not cover every desired scenario. There are many scenarios in which code integrity policies would be used alongside AppLocker rules. As a best practice, you should enforce code integrity policies at the most restrictive level possible for your organization, and then you can use AppLocker to fine-tune the restrictions to an even lower level.
-
->**Note:**  One example in which Device Guard functionality needs AppLocker supplementation is when your organization would like to limit universal applications. Universal applications have already been validated by Microsoft to be trustworthy to run, but an organization may not want to allow specific universal applications to run in their environment. You can accomplish this enforcement by using an AppLocker rule.
-AppLocker and Device Guard should run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible. In addition to these features, Microsoft recommends that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
-
-**Device Guard with Credential Guard**
-
-Although Credential Guard is not a feature within Device Guard, many organizations will likely deploy Credential Guard alongside Device Guard for additional protection against credential theft. Similar to virtualization-based protection of kernel mode code integrity, Credential Guard leverages hypervisor technology to protect domain credentials. This mitigation is targeted at resisting the use of pass-the-hash and pass-the-ticket techniques. By employing multifactor authentication with Credential Guard, organizations can gain additional protection against such threats. For information about how to deploy Credential Guard to your Windows 10 Enterprise clients, see the [Enable Credential Guard](#enable-cg) section. In addition to the client-side enablement of Credential Guard, organizations can deploy mitigations at both the CA and domain controller level to help prevent credential theft. Microsoft will be releasing details about these additional mitigations in the future.
-
-**Unified manageability**
-
-You can easily manage Device Guard features by using the familiar enterprise and client-management tools that IT pros use every day. Use the following management tools to enable and manage Device Guard:
-
--   **Group Policy**. Windows 10 provides an administrative template to configure and deploy the configurable code integrity policies for your organization. This template also allows you to specify which hardware-based security features you would like to enable and deploy. You can manage these settings along with your existing Group Policy Objects (GPOs), which makes it simple to implement Device Guard features. In addition to these code integrity and hardware-based security features, you can use Group Policy to help you manage your catalog files. For more information about catalog files, see the [Catalog files](#catalog-files) section.
--   **Microsoft System Center Configuration Manager**. You can use System Center Configuration Manager to simplify deployment and management of catalog files, code integrity policies, and hardware-based security features, as well as provide version control. For more information about how to deploy catalog files by using System Center Configuration Manager, see the [Deploy catalog files with System Center Configuration Manager](#deploy-cat-sccm) section.
--   **Microsoft Intune**. In a future release of Microsoft Intune, organizations will be able to leverage Intune for deployment and management of code integrity policies and catalog files.
--   **Windows PowerShell**. Windows PowerShell is primarily used to create and service code integrity policies. These policies represent the most powerful component of Device Guard. For a step-by-step walkthrough of how to create, audit, service, enforce, and deploy code integrity policies, see the [Code integrity policies](#code-integrity-policies) section.
-
-These options provide the same experience you are used to in order to manage your existing enterprise management solutions. For more information about how to manage and deploy Device Guard hardware and code integrity features in your organization, see the [Device Guard deployment](#dg-deployment) section.
-
-## Plan for Device Guard
-
-In this section, you will learn about the following topics:
-
--   [Approach enterprise code integrity deployment](#approach-enterprise-code-integrity-deployment). Device Guard deployment in your organization requires a planned approach. In this section, you get high-level recommendations for how to approach enterprise code integrity deployment in your organization.
--   [Device Guard deployment scenarios](#device-guard-deployment-scenarios). When you plan for Device Guard deployment, Microsoft recommends that you categorize each device in your organization into a deployment scenario. These scenarios will provide a roadmap for your Device Guard deployment.
--   [Code signing adoption](#code-signing-adoption). Code signing is important to the security that Device Guard provides. This section outlines the options for code signing and the benefits and disadvantages of each method.
--   [Hardware considerations](#hardware-considerations). Several Device Guard features require advanced hardware. This section outlines the requirements for each of those features and what to look for during your next hardware refresh.
-
-## Approach enterprise code integrity deployment
-
-Enterprises that want to consider Device Guard should not expect deployment to their entire organization overnight. Device Guard implementation requires that you plan for both end-user and IT pro impact. In addition, the deployment of Device Guard features to your enterprise requires a planned, phased approach to ensure that end-user systems are fully capable and ready to enforce these new security restrictions. Perform the following high-level tasks to approach the deployment of Device Guard to your enterprise:
-
-1.  **Group devices into similar functions**. Categorize machines into the groups described in the [Device Guard deployment scenarios](#device-guard-deployment-scenarios) section. This begins the roadmap for your Device Guard deployment and provides groups of easier and more difficult implementations. From there, assess the quantity of necessary Device Guard policies. The easiest solution is to lock down your entire enterprise, but it might not fit your individual departments’ needs.
-
-    To discover an appropriate number of policies for your organization, try to separate the defined groups into departments or roles. Then ask some questions: What software does each department or role need to do their job? Should they be able to install and run other departments’ software? Do we need to create a base code integrity policy that aligns with our application catalog? Should users be able to install any application or only choose from an “allowed” list? Do we allow users to use their own peripheral devices? These questions will help you discover the number of necessary policies for your organization. Finally, try to focus on which people or departments would require an additional level of privileges. For example, should department x be able to install and run application xyz, even though no other department does? If the answer is yes and justifiable, you will need a secondary code integrity policy for that group. If not, you will likely be able to merge several policies to simplify management. For more information about configurable code integrity policies, see the [Code integrity policies](#code-integrity-policies) section.
-
-2.  **Create code integrity policies from “golden” PCs**. After you create the groups of devices, you can create code integrity policies to align with those groups, similar to the way you would manage corporate images. When you have separated these groups and set up golden PCs that mimic the software and hardware those individual groups require, create code integrity policies from each of them. After you create these, you can merge these code integrity policies to create a master policy, or you can manage and deploy them individually. For step-by-step instructions about how to create code integrity policies, see the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) section.
-
-3.  **Audit and merge code integrity policies**. Microsoft recommends that you test code integrity policies in audit mode before you enforce them. Audit mode allows administrators to run the code integrity policy on a system but not actually block anything. Rather than not allowing applications to run, events are logged with each exception to the policy. This way, you can easily highlight any issues that were not discovered during the initial scan. You can create additional code integrity policies by using the audit events and merge them into the existing policy. For more information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
-
-4.  **Assess LOB applications that are currently unsigned, and create a catalog file for them**. Catalog files allow organizations to sign applications that do not currently possess digitally signed binaries or applications that a customer would want to add a secondary signature to. These applications can be in-house applications or from third parties, and the process does not require any repackaging of the application. When you create code integrity policies at a rule level above hash values, you will not discover unsigned applications. To include these applications in your code integrity policies, simply create, sign, and deploy a catalog file. For information about catalog files, see the [Catalog files](#catalog-files) section.
-
-5.  **Enable desired hardware security features**. Each type of device found in the [Device Guard deployment scenarios](#device-guard-deployment-scenarios) section takes advantage of different software and hardware integrity configurations. You should assess hardware-based security features separately from code integrity policies because they provide complementary functionality. For information about how to configure Device Guard hardware-based security features, see the [Configure hardware-based security features](#configure-hardware-based-security-features) section.
-
-6.  **Deploy code integrity policies and catalog files**. After you have created and signed the necessary catalog files and created and audited code integrity policies, you are ready to deploy them in phases. Microsoft strongly recommends that you deploy these components to a test group of users, even after your IT organization has tested and vetted them. This provides a final quality control validation before you deploy the catalog files and policies more broadly. For information about how to deploy catalog files with Group Policy, see the [Deploy catalog files with Group Policy](#deploy-catalog-files-with-group-policy) section. For additional information about how to deploy code integrity policies, see the [Deploy code integrity policies with Group Policy](#deploy-code-integrity-policies-with-group-policy) section.
-
-## Device Guard deployment scenarios
-
-To help simplify the deployment of Device Guard to your organization, Microsoft recommends that you group devices into the deployment scenarios described in this section. Device Guard is not a feature that organizations will just simply “turn on”; rather, it typically requires a phased implementation approach. To see where these scenarios fit into an overall Device Guard deployment approach, see the [Approach to enterprise code integrity deployment](#approach-to-enterprise-code-integrity-deployment) section.
-
-**Fixed-workload devices**
-
-The lists of approved applications on fixed-workload devices rarely change as they perform the same tasks day after day. Examples of such devices include kiosks, point-of-sale systems, and call center PCs. These devices could easily employ the full capabilities of Device Guard and would require little management or policy modification. Device Guard implementation to these devices is painless and requires little ongoing administration. With Device Guard fully implemented, users are able to run only those applications that the IT department installs, manages, and trusts.
-Device Guard components that are applicable to fixed-workload devices include:
-
--   KMCI VBS protection
--   Enforced UMCI policy
-
-**Fully managed devices**
-
-Fully managed devices are those for which the IT department restricts the software that is installed and run on them, but allows users to request installation of additional software or provides a list of approved software in an application catalog. Examples of such devices include locked-down, company-owned desktops and laptops. With these devices, establish an initial baseline code integrity policy and enforce the code integrity policy. The IT department manages the policies and updates the devices when new applications are approved or are provided in the System Center Configuration Manager catalog.
-Device Guard components that are applicable to fully managed devices include:
-
--   KMCI VBS protection
--   Enforced UMCI policy
-
-In this scenario, an application list is provided and trusted, and the trust policy is constantly re-evaluated when a user requests a new application. When an application is trusted across all of these devices, new user requests for that application do not require a policy update (alignment with application catalog). In addition, you can couple this with an onboarding process for new applications that you should add to the central application catalog. Initial implementation of Device Guard to fully managed devices is simple but does require more administrative overhead to manage trusted signatures of newly requested and approved applications.
-
-**Lightly managed devices**
-
-Lightly managed devices are company-owned machines over which users have full control, which includes what is installed on them. These devices run the organization’s antivirus solution and client management tools but are not restricted by software request or compliance policies.
-
-Device Guard components that are applicable to lightly managed devices include:
-
--   KMCI VBS protection
--   UMCI policy in Audit mode
-
-**Bring Your Own Device**
-
-Device Guard is not a good way to manage devices in a Bring Your Own Device (BYOD) model. When employees are allowed to bring their own devices, the management of user-mode applications on them can make it difficult for users to use their own devices when they are not at work. In addition, Device Guard functionality is difficult to maintain from an administrative perspective. For devices in this group, explore alternate hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune.
-
-## Code signing adoption
-
-Code signing is crucial to the successful implementation of configurable code integrity policies. These policies can trust the signing certificates from both independent software vendors and customers. In Windows 10, all Windows Store applications are signed. Also, you can easily trust any other signed application by adding the signing certificate to the code integrity policy.
-For unsigned applications, customers have multiple options for signing them so that code integrity policies can trust them. The first option is traditional embedded code signing. Organizations that have in-house development teams can incorporate binary code signing into their application development process, and then simply add the signing certificate to their code integrity policies. The second option for signing unsigned applications is to use catalog files. In Windows 10, customers have the ability to create catalog files as they monitor the installation and initial run of an application. For more information about signing existing unsigned LOB applications or third-party applications, see the [Existing line-of-business applications](#existing-line-of-business-applications) section.
-
-### Existing line-of-business applications
-
-Until now, existing LOB applications were difficult to trust if they were signed by a source other than the Windows Store or not signed at all. With Windows 10, signing your existing LOB and third-party unsigned applications is simplified. This new signing method does not require that applications be repackaged in any way. With catalog files, administrators can sign these unsigned applications simply by monitoring for an installation and initial startup. By using this monitoring information, an administrator can generate a catalog file. Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries’ hash values are updated every time an application is updated and therefore require an updated catalog file. For simplified administration, consider incorporating embedded code signing into your application development process. For more information about how to generate catalog files, see the [Catalog files](#catalog-files) section.
-
->**Note:**  Catalog files are lists of individual binaries’ hash values. If the scanned application is updated, you will need to create a new catalog file. That said, binary signing is still highly recommended for any future applications so that no catalog files are needed.
- 
-When you create a catalog file, you must sign it by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. When signed, code integrity policies can trust the signer or signing certificate of those files. For information about catalog file signing, see the [Catalog files](#catalog-files) section.
-
-**Application development**
-
-Although in-house applications can be signed after packaging by using catalog files, Microsoft strongly recommends that embedded code signing be incorporated into your application development process. When signing applications, simply add the code signing certificate used to sign your applications to your code integrity policy. This ensures that your code integrity policy will trust any future application that is signed with that certificate. Embedding code signing into any in-house application development process is beneficial to your IT organization as you implement code integrity policies.
-
-## Hardware considerations
-
-Careful consideration about which hardware vendor and specific models to purchase during your next hardware refresh is vitally important to the success of your organization’s Device Guard implementation efforts. In alignment with your current hardware life cycle, consider the process that is discussed in the [Approach enterprise code integrity deployment](#approach-enterprise-code-integrity-deployment) section when you determine the appropriate order of hardware replacement in your organization. Device Guard should be deployed in phases; therefore, you have time to methodically plan for its implementation.
-
-Different hardware features are required to implement the various features of Device Guard. There will likely be some individual features that you will be able to enable with your current hardware and some that you will not. However, for organizations that want to implement Device Guard in its entirety, several advanced hardware features will be required. For additional details about the hardware features that are required for Device Guard components, see the following table.
-
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">Requirement</th>
-<th align="left">Description</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><p>Windows 10 Enterprise</p></td>
-<td align="left"><p>The PC must be running Windows 10 Enterprise.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>UEFI firmware version 2.3.1 or higher with UEFI Secure Boot and Platform Secure Boot</p></td>
-<td align="left"><p>UEFI Secure Boot ensures that the device boots only authorized code. Additionally, Boot Integrity, also known as Platform Secure Boot must be supported. You can validate it against the following Windows Hardware Compatibility Program requirements:</p>
-<ul>
-<li><p>[System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot)</p></li>
-<li><p>[System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](http://msdn.microsoft.com/library/windows/hardware/dn932807.aspx#system-fundamentals-firmware-cs-uefisecureboot-connectedstandby)</p></li>
-</ul></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>Virtualization extensions</p></td>
-<td align="left"><p>The following virtualization extensions are required to support virtualization-based security:</p>
-<ul>
-<li>Intel VT-x or AMD-V</li>
-<li>Second Level Address Translation</li>
-</ul></td>
-</tr>
-<tr class="even">
-<td align="left"><p>Firmware lock</p></td>
-<td align="left"><ul>
-<li><p>The firmware setup should be locked to prevent other operating systems from starting and to prevent changes to the UEFI settings.</p></li>
-<li><p>Work with your hardware manufacturer to ensure that the devices are Device Guard ready.</p></li>
-<li><p>You should require a firmware password or higher authentication to change firmware settings.</p></li>
-</ul></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>x64 architecture</p></td>
-<td align="left"><p>The features that virtualization-based security uses in the Windows hypervisor can only run on a 64-bit PC.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>A VT-d or AMD-Vi IOMMU (Input/output memory management unit)</p></td>
-<td align="left"><p>In Windows 10, an IOMMU enhances system resiliency against memory attacks.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>Secure firmware update process</p></td>
-<td align="left"><p>To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement.</p><p>Device Guard relies on the security of the underlying hardware and firmware. It is critical to keep the firmware updated with the latest security fixes.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>Signed processor microcode updates</p></td>
-<td align="left"><p>If the processor supports it, you must require signed microcode updates.</p></td>
-</tr>
-</tbody>
-</table>
-
-## Device Guard deployment
-
-In this section, you learn about the following topics:
-
--   [Configure hardware-based security features](#configure-hardware-based-security-features). This section explains how to enable the hardware-based security features in Device Guard. Also, you verify that the features are enabled by using both Windows Management Infrastructure (WMI) and Msinfo32.exe.
--   [Catalog files](#catalog-files). In this section, you create, sign, and deploy catalog files. You deploy the catalog files by using both Group Policy and System Center Configuration Manager. Also, you use System Center Configuration Manager to inventory the deployed catalog files for reporting purposes.
--   [Code integrity policies](#code-integrity-policies). This section provides information on how to create, audit, service, merge, deploy, and remove signed and unsigned configurable code integrity policies.
-
-## Configure hardware-based security features
-
-Hardware-based security features 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:
-
-1.  **Verify that hardware requirements are met and enabled**. Verify that your client machines possess the necessary hardware to run these features. A list of hardware requirements for the hardware-based security features is available in the [Hardware considerations](#hardware-considerations) section.
-2.  **Enable the necessary Windows features**. There are several ways to enable the Windows features required for hardware-based security. For details on which Windows features are needed, see the [Windows feature requirements for virtualization-based security](#windows-feature-requirements-for-virtualization-based-security) section.
-3.  **Enable desired features**. When the necessary hardware and Windows features have been enabled, you are ready to enable the desired hardware-based security features. For UEFI Secure Boot, see the [Enable UEFI Secure Boot](#enable-unified-extensible-interface-secure-boot) section. For information about how to enable VBS protection of the KMCI service, see the [Enable virtualization-based protection of kernel mode code integrity](#enable-virtualbased) section. Finally, for information about how to enable Credential Guard, see the [Enable Credential Guard](#enable-credential-guard) section.
-
-### Windows feature requirements for virtualization-based security
-
-In addition to the hardware requirements found in the [Hardware considerations](#hardware-considerations) section, you must enable certain operating system features before you can enable VBS: Microsoft Hyper-V and isolated user mode (shown in Figure 1).
-
->**Note:**  You can configure these features manually by using Windows PowerShell or Deployment Image Servicing and Management. For specific information about these methods, refer to the [Credential Guard documentation](http://go.microsoft.com/fwlink/p/?LinkId=624529).
- 
-![figure 1](images/dg-fig1-enableos.png)
-
-Figure 1. Enable operating system features for VBS
-
-After you enable these features, you can configure any hardware-based security features you want. For information about how to enable virtualization-based protection of kernel-mode code integrity, see the [Enable virtualization-based protection of kernel-mode code integrity](#enable-virtualization-based-protection-of-kernel-mode-code-integrity) section. For information about how to enable UEFI Secure Boot, see the [Enable UEFI Secure Boot](#enable-unified-extensible-interface-secure-boot) section. Finally, for additional information about how to enable Credential Guard, see the [Enable Credential Guard](#enable-credential-guard) section.
-
-### Enable Unified Extensible Firmware Interface Secure Boot
-
-Before you begin this process, verify that the target device meets the hardware requirements for UEFI Secure Boot that are laid out in the [Hardware considerations](#hardware-considerations) section. 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 DMA protection (IOMMU) technologies. Without the presence of IOMMUs and with DMA protection disabled, customers will lose protection from driver-based attacks.
-
-1.  Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
-2.  Set the **EnableVirtualizationBasedSecurity DWORD** value to **1**.
-3.  Set the **RequirePlatformSecurityFeatures DWORD** value as appropriate:
-
-    -   Set this value to **1** to enable the **Secure Boot** option.
-    -   Set this value to **2** to enable the **Secure Boot with DMA Protection** option.
-
-4.  Restart the client machine.
-
-Unfortunately, it would be time consuming to perform these steps manually on every protected machine 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 prefer to link the policy to an existing OU, and then scope the GPO by using appropriately named computer security groups, you can certainly do so.
-
->**Note:**  Microsoft recommends that you test-enable this feature on a group of test machines before you deploy it to machines that are currently deployed to users.
-
-**Use Group Policy to deploy Secure Boot**
-
-<a href="" id="bkmk-depsecureboot"></a>
-
-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**.
-
-    ![figure 2](images/dg-fig2-createou.png)
-
-    Figure 2. Create a new OU-linked GPO
-
-2.  Name the new GPO **Contoso Secure Boot GPO Test**. This example uses *Contoso Secure Boot GPO Test* as the name of the GPO. You can choose any name for this example. Ideally, the name would align with your existing GPO naming convention.
-
-3.  To 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. Then, right-click **Turn On Virtualization Based Security**, and then click **Edit**.
-
-    ![figure 3](images/dg-fig3-enablevbs.png)
-
-    Figure 3. Enable VBS
-
-5.  Select the **Enabled** option, and then select **Secure Boot and DMA Protection** from the **Select Platform Security Level** list.
-
-    ![figure 4](images/device-guard-gp.png)
-
-    Figure 4. Enable Secure Boot
-
-    >**Note:**  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 IOMMU, there are several mitigations provided by leveraging Secure Boot without DMA Protection.
-     
-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.
-
-7.  Check the test computer’s event log for Device Guard GPOs.
-    
-    Processed Device Guard policies are logged in event viewer at Application 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 of kernel-mode code integrity
-
-Before you begin this process, verify that the desired computer meets the hardware requirements for VBS found in the [Hardware considerations](#hardware-considerations) section, and enable the Windows features discussed in the [Virtualization-based security Windows feature requirements](#virtualization-based-security-windows-featurerrequirements) 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. Microsoft recommends that you enable this feature on a group of test machines before you enable it on deployed machines.
-
-To configure virtualization-based protection of KMCI manually:
-
-1.  Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\DeviceGuard** registry subkey.
-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 machine 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:**  Microsoft recommends that you test-enable this feature on a group of test computers before you deploy it to machines that are currently deployed to users. 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:
-
-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](images/dg-fig5-createnewou.png)
-
-    Figure 5. Create a new OU-linked GPO
-
-2.  Name the new GPO **Contoso VBS CI Protection GPO Test**.
-
-    This example uses *Contoso VBS CI Protection GPO Test* as the name of the GPO. You can choose any name you prefer for this example. Ideally, this name would 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. Then, right-click **Turn On Virtualization Based Security**, and then click **Edit**.
-
-    ![figure 6](images/dg-fig6-enablevbs.png)
-
-    Figure 6. Enable VBS
-
-5.  Select the **Enabled** option, and then select the **Enable Virtualization Based Protection of Code Integrity** check box.
-
-    ![figure 7](images/dg-fig7-enablevbsofkmci.png)
-
-    Figure 7. Enable VBS of KMCI
-
-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.  Check the test client event log for Device Guard GPOs.
-
-    Processed Device Guard policies are logged in event viewer under Application 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.
-
-### Enable Credential Guard
-
-Credential Guard provides an additional layer of credential protection specifically for domain users by storing the credentials within the virtualized container, away from both the kernel and user mode operating system. This makes it difficult for even a compromised system to obtain access to the credentials. In addition to the client-side enablement of Credential Guard, you can deploy additional mitigations at both the Certification Authority and domain controller level to prevent credential theft. Microsoft will be releasing details about these additional mitigations in the future.
-
-Before you begin this process, verify that the desired system meets the hardware requirements for VBS found in the [Hardware considerations](#hardware) section, and that you have enabled the Windows features laid out in the [Virtualization-based security Windows feature requirements](#virtualization-based-security-windows-feature-requirements) section. When validated, you can enable Credential Guard manually, by configuring the appropriate registry subkeys, or through Group Policy deployment.
-
-To configure VBS of Credential Guard manually:
-
-1.  Navigate to the **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\Lsa** registry subkey.
-2.  Set the **LsaCfgFlags DWORD** value to **1**.
-3.  Restart the client computer.
-
-To avoid spending an unnecessary amount of time in manual deployments, use Group Policy to deploy Credential Guard to your organization. This example creates a test OU called *DG Enabled PCs*. To enable Credential Guard, you can link to any OU, and then scope the GPO’s application by using security groups.
-
->**Note:**  Microsoft recommends that you enable Credential Guard before you join a machine to the domain to ensure that all credentials are properly protected. Setting the appropriate registry subkeys during your imaging process would be ideal to achieve this protection.
-
-To use Group Policy to enable Credential Guard:
-
-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 8](images/dg-fig8-createoulinked.png)
-
-    Figure 8. Create a new OU-linked GPO
-
-2.  Name the new GPO **Contoso Credential Guard GPO Test**.
-
-    This example uses *Contoso Credential Guard GPO Test* as the name of the GPO. You can choose any name you prefer for this example. Ideally, this name would 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 9](images/dg-fig9-enablevbs.png)
-
-    Figure 9. Enable VBS
-
-5.  Select the **Enabled** option, and then select the **Enable Credential Guard** check box.
-
-    ![figure 10](images/dg-fig10-enablecredentialguard.png)
-
-    Figure 10. Enable Credential Guard
-
-6.  Close Group Policy Management Editor, and then restart the Windows 10 test computer.
-
-    >**Note:**  The default platform security level is **Secure Boot**. If IOMMUs are available within the protected machines, it is recommended that you select **Secure Boot and DMA Protection** to maximize the mitigations that are available through Credential Guard.
-
-7.  Check the test client event log for Device Guard GPOs.
-
->**Note**  All processed Device Guard policies are logged in event viewer under Application and Services Logs\\Microsoft\\Windows\\DeviceGuard-GPEXT\\Operational.
- 
-For additional information about how Credential Guard works as well as additional configuration options, please refer to the [Credential Guard documentation](http://go.microsoft.com/fwlink/p/?LinkId=624529).
-
-**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:
-
-`Get-CimInstance –ClassName Win32_DeviceGuard –Namespace root\Microsoft\Windows\DeviceGuard`
-
->**Note:**  The *Win32\_DeviceGuard* WMI class is only available on the Enterprise edition of Windows 10.
-
-The output of this command provides details of the available hardware-based security features as well as those features that are currently enabled. For detailed information about what each property means, refer to Table 1.
- 
-Table 1. Win32\_DeviceGuard properties
-
-<table>
-<colgroup>
-<col width="33%" />
-<col width="33%" />
-<col width="33%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left"><strong>Properties</strong></th>
-<th align="left"><strong>Description</strong></th>
-<th align="left"><strong>Valid values</strong></th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><strong>AvailableSecurityProperties</strong></td>
-<td align="left">This field helps to enumerate and report state on the relevant security properties for Device Guard.</td>
-<td align="left"><ul>
-<li><p><strong>0.</strong> If present, no relevant properties exist on the device.</p></li>
-<li><p><strong>1.</strong> If present, hypervisor support is available.</p></li>
-<li><p><strong>2.</strong> If present, Secure Boot is available.</p></li>
-<li><p><strong>3.</strong> If present, DMA protection is available.</p></li>
-</ul></td>
-</tr>
-<tr class="even">
-<td align="left"><strong>InstanceIdentifier</strong></td>
-<td align="left">A string that is unique to a particular device.</td>
-<td align="left">Determined by WMI.</td>
-</tr>
-<tr class="odd">
-<td align="left"><strong>RequiredSecurityProperties</strong></td>
-<td align="left">This field describes the required security properties to enable virtualization-based security.</td>
-<td align="left"><ul>
-<li><p><strong>0.</strong> Nothing is required.</p></li>
-<li><p><strong>1.</strong> If present, Secure Boot is needed.</p></li>
-<li><p><strong>2.</strong> If present, DMA protection is needed.</p></li>
-<li><p><strong>3.</strong> If present, both Secure Boot and DMA protection are needed.</p></li>
-</ul></td>
-</tr>
-<tr class="even">
-<td align="left"><strong>SecurityServicesConfigured</strong></td>
-<td align="left">This field indicates whether the Credential Guard or HVCI service has been configured.</td>
-<td align="left"><ul>
-<li><p><strong>0.</strong> No services configured.</p></li>
-<li><p><strong>1.</strong> If present, Credential Guard is configured.</p></li>
-<li><p><strong>2.</strong> If present, HVCI is configured.</p></li>
-</ul></td>
-</tr>
-<tr class="odd">
-<td align="left"><strong>SecurityServicesRunning</strong></td>
-<td align="left">This field indicates whether the Credential Guard or HVCI service is running.</td>
-<td align="left"><ul>
-<li><p><strong>0.</strong> No services running.</p></li>
-<li><p><strong>1.</strong> If present, Credential Guard is running.</p></li>
-<li><p><strong>2.</strong> If present, HVCI is running.</p></li>
-</ul></td>
-</tr>
-<tr class="even">
-<td align="left"><strong>Version</strong></td>
-<td align="left">This field lists the version of this WMI class.</td>
-<td align="left">The only valid value now is <strong>1.0</strong>.</td>
-</tr>
-<tr class="odd">
-<td align="left"><strong>VirtualizationBasedSecurityStatus</strong></td>
-<td align="left">This field indicates whether VBS is enabled and running.</td>
-<td align="left"><ul>
-<li><p><strong>0.</strong> VBS is not enabled.</p></li>
-<li><p><strong>1.</strong> VBS is enabled but not running.</p></li>
-<li><p><strong>2.</strong> VBS is enabled and running.</p></li>
-</ul></td>
-</tr>
-<tr class="even">
-<td align="left"><strong>PSComputerName</strong></td>
-<td align="left">This field lists the computer name.</td>
-<td align="left">All valid values for computer name.</td>
-</tr>
-</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.
-
-![figure 11](images/dg-fig11-dgproperties.png)
-
-Figure 11. Device Guard properties in the System Summary
-
-## Catalog files
-
-Enforcement of Device Guard on a system requires that every trusted application have a signature or its binary hashes added to the code integrity policy. For many organizations, this can be an issue when considering unsigned LOB applications. To avoid the requirement that organizations repackage and sign these applications, Windows 10 includes a tool called Package Inspector that monitors an installation process for any deployed and executed binary files. If the tool discovers such files, it itemizes them in a catalog file. These catalog files offer you a way to trust your existing unsigned applications, whether developed in house or by a third party, as well as trust signed applications for which you do not want to trust the signer but rather the specific application. When created, these files can be signed, the signing certificates added to your existing code integrity policies, and the catalog files themselves distributed to the clients.
-
->**Note:**  The Enterprise edition of Windows 10 or Windows Server 2016 is required to create and use catalog files.
-
-### Create catalog files
-
-The creation of catalog files is the first step to add an unsigned application to a code integrity policy. To create a catalog file, copy each of the following commands into an elevated Windows PowerShell session, and then complete the steps:
-
->**Note:**  When you establish a naming convention it makes it easier to detect deployed catalog files in the future. In this guide, you will use *\*-Contoso.cat* as the naming convention. For more information about why this practice is helpful to inventory or detect catalog files, see the [Inventory catalog files with System Center Configuration Manager](#inventory-catalog-files-with-system-center-configuration-manager) section.
- 
-1.  Be sure that a code integrity policy is currently running in audit mode.
-
-    Package Inspector does not always detect installation files that have been removed from the machine during the installation process. To ensure that these binaries are also trusted, the code integrity policy that you created and audited in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) and [Audit code integrity policies](#audit-code-integrity-policies) sections should be deployed, in audit mode, to the system on which you are running Package Inspector.
-
-    **Note**  
-    This process should **not** be performed on a system running an enforced Device Guard policy, only with a policy running in audit mode. If a policy is currently being enforced, you will not be able to install and run the application.
-
-2.  Start Package Inspector, and then scan drive C:
-
-    `PackageInspector.exe Start C:`
-
-    >**Note:**  Package inspector can monitor installations on any local drive. In this example, we install the application on drive C, but any other drive can be used.
-    
-3.  Copy the installation media to drive C.
-
-    By copying the installation media to drive C, you ensure that Package Inspector detects and catalogs the actual installer. If you skip this step, the future code integrity policy may trust the application to run but not be installed.
-
-4.  Install and launch the application.
-
-    Install the application to drive C. When the installation is finished, launch the application and ensure that any product updates are installed and any downloadable content caught during the scan. When finished, close and 
-    reopen the application once again to ensure that the scan has captured all binaries.
-    
-    >**Note:**      Every binary that is run while Package Inspector is running will be captured in the catalog. Therefore, be sure not to run additional installations or updates during the scan to minimize the risk of trusting the incorrect binaries. Alternatively, if you want to add multiple applications to a single catalog file, simply repeat the installation and run process while the current scan is running.
-     
-5.  Stop the scan, and then generate definition and catalog files. When application installation and initial setup are finished, stop the Package Inspector scan and generate the catalog and definition files on your desktop by using the following commands:
-
-    `$ExamplePath=$env:userprofile+"\Desktop"`
-    `$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"`
-    `$CatDefName=$ExamplePath+"\LOBApp.cdf"`
-    `PackageInspector.exe Stop C: -Name $CatFileName -cdfpath $CatDefName`
-
->**Note:**  This scan catalogs the hash values for each discovered binary file. If the applications that were scanned are updated, complete this process again to trust the new binaries’ hash values.
-When finished, the files will be saved to your desktop. To trust this catalog file within a code integrity policy, the catalog must first be signed. Then, the signing certificate can be included in the code integrity policy, and the catalog file can be distributed to the individual client machines. Catalog files can be signed by using a certificate and SignTool.exe, a free tool available in the Windows SDK. For more information about signing catalog files with SignTool.exe, see the [Catalog signing with SignTool.exe](#catalog-signing-with-signtool.exe) section.
-
-### Catalog signing with SignTool.exe
-
-Device Guard makes it easy for organizations to sign and trust existing unsigned LOB applications. In this section, you sign a catalog file you generated in a previous section by using PackageInspector.exe. For information about how to create catalog files, see the [Create catalog files](#create-catalog-files) section. In this example, you need the following:
-
--   SignTool.exe, found in the Windows software development kit (SDK—Windows 7 or later)
--   The catalog file that you generated in the [Create catalog files](#create-catalog-files) section, or another catalog file that you have created
--   Internal certification authority (CA) code signing certificate or purchased code signing certificate
-
-If you do not have a code signing certificate, please see the [Create a Device Guard code signing certificate](#create-a-device-guard-code-signing-certificate) section for a walkthrough of how to create one. In addition to using the certificate you create in the Create a Device Guard code signing certificate section, this example signs the catalog file that you created in the [Create catalog files](#create-catalog-files) section. If you are using an alternate certificate or catalog file, update the following steps with the appropriate variables and certificate. To sign the existing catalog file, copy each of the following commands into an elevated Windows PowerShell session:
-
-1.  Initialize the variables that will be used:
-
-    '$ExamplePath=$env:userprofile+"\Desktop"'
-    
-    '$CatFileName=$ExamplePath+"\LOBApp-Contoso.cat"'
-
-   >**Note:**     In this example, you use the catalog file you created in the [Create catalog files](#create-catalog-files) section. If you are signing another catalog file, be sure to update the *$ExamplePath* and *$CatFileName* variables with the correct information.
-
-2.  Import the code signing certificate. Import the code signing certificate that will be used to sign the catalog file to the signing user’s personal store. In this example, you use the certificate that you created in the [Create a Device Guard code signing certificate](#create-a-device-guard-code-signing-certificate) section.
-
-3.  Sign the catalog file with Signtool.exe:
-
-    `<path to signtool.exe> sign /n "ContosoDGSigningCert" /fd sha256 /v $CatFileName`
-
-   >**Note:**  The *&lt;Path to signtool.exe&gt;* variable should be the full path to the Signtool.exe utility. *ContosoDGSigningCert* is the subject name of the certificate that you will use to sign the catalog file. This certificate should be imported to your personal certificate store on the machine on which you are attempting to sign the catalog file.
-   
-   >**Note:**  For additional information about Signtool.exe and all additional switches, visit [MSDN Sign Tool page](http://go.microsoft.com/fwlink/p/?LinkId=624163).
-     
-4.  Verify the catalog file digital signature. Right-click the catalog file, and then click **Properties**. On the **Digital Signatures** tab, verify that your signing certificate exists with a **sha256** algorithm, as shown in Figure 12.
-
-    ![figure 12](images/dg-fig12-verifysigning.png)
-
-    Figure 12. Verify that the signing certificate exists
-
-5.  Copy the catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}.
-
-    For testing purposes, you can manually copy signed catalog files to their intended folder. For large-scale implementations, Microsoft recommends that you use Group Policy File Preferences to copy the appropriate catalog files to all desired machines or an enterprise systems management product such as System Center Configuration Manager. Doing this simplifies the management of catalog versions, as well.
-
-### Deploy catalog files with Group Policy
-
-To simplify the management of catalog files, you can use Group Policy preferences to deploy catalog files to the appropriate PCs in your organization. The following process walks you through the deployment of a signed catalog file called LOBApp-Contoso.cat to a test OU called DG Enabled PCs with a GPO called **Contoso DG Catalog File GPO Test**.
-
->**Note:**  This walkthrough requires that you have previously created a signed catalog file and have a Windows 10 client PC on which to test a Group Policy deployment. For more information about how to create and sign a catalog file, see the [Catalog files](#catalog-files) section.
-
-To deploy a catalog file with Group Policy:
-
-1.  From either a domain controller or a client PC that has Remote Server Administration Tools (RSAT) installed, open the Group Policy Management Console (GPMC) by running **GPMC.MSC** or by searching for Group Policy Management.
-2.  Create a new GPO: right-click the DG Enabled PCs OU, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 13.
-
-   >**Note:**  The DG Enabled PCs OU is just an example of where to link the test GPO that you created in this section. You can use any OU name. Also, security group filtering is an option when you consider policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise-code-integrity-deployment) section.
-
-   ![figure 13](images/dg-fig13-createnewgpo.png)
-   
-   Figure 13. Create a new GPO
-
-3.  Name the new GPO **Contoso DG Catalog File GPO Test**.
-
-    This example uses *Contoso DG Catalog File GPO Test* as the name of the GPO. You can choose any name you prefer for this example.
-
-4.  Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
-
-5.  Within the selected GPO, navigate to Computer Configuration\\Preferences\\Windows Settings\\Files. Right-click **Files**, point to **New**, and then click **File**, as shown in Figure 14.
-
-    ![figure 14](images/dg-fig14-createnewfile.png)
-
-    Figure 14. Create a new file
-
-6.  Configure the catalog file share.
-
-    To use this setting to provide consistent deployment of LOBApp-Contoso.cat, the source file should be on a share that is accessible to the computer account of every deployed machine. This example uses a share on a Windows 10 client machine called \\\\Contoso-Win10\\Share. The catalog file being deployed is copied to this share.
-
-7.  To keep versions consistent, in the **New File Properties** dialog box (Figure 15), select **Replace** from the **Action** list so that the newest version is always used.
-
-    ![figure 15](images/dg-fig15-setnewfileprops.png)
-
-    Figure 15. Set the new file properties
-
-8.  In the **Source file(s)** box, type the name of your accessible share, with the catalog file name included (for example, \\\\Contoso-Win10\\share\\LOBApp-Contoso.cat).
-
-9.  In the **Destination File** box, type **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}\\LOBApp-Contoso.cat**.
-
-    >**Note:**  LOBApp-Contoso.cat is not a required catalog name: This name was used in the [Create catalog files](#create-catalog-files) section, and so it was used here, as well.
-     
-10. On the **Common** tab of the **New File Properties** dialog box, select the **Remove this item when it is no longer applied** option. Doing this ensures that the catalog file is removed from every system, in case you ever need to stop trusting this application.
-
-11. Click **OK** to complete file creation.
-
-12. Close the Group Policy Management Editor, and then update the policy on the test Windows 10 machine by running GPUpdate.exe. When the policy has been updated, verify that the catalog file exists in C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} on the Windows 10 machine.
-
-### Deploy catalog files with System Center Configuration Manager
-
-As an alternative to Group Policy, you can use System Center Configuration Manager to deploy catalog files to the managed machines in your environment. This approach can simplify the deployment and management of multiple catalog files as well as provide reporting around which catalog each client or collection has deployed. In addition to the deployment of these files, System Center Configuration Manager can also be used to inventory the currently deployed catalog files for reporting and compliance purposes. Complete the following steps to create a new deployment package for catalog files:
-
->**Note:**  The following example uses a network share named \\\\Shares\\CatalogShare as a source for the catalog files. If you have collection specific catalog files, or prefer to deploy them individually, use whichever folder structure works best for your organization.
-
-1.  Open the Configuration Manager console, and select the Software Library workspace.
-2.  Navigate to Overview\\Application Management, right-click **Packages**, and then click **Create Package**.
-3.  Name the package, set your organization as the manufacturer, and select an appropriate version number (Figure 16).
-
-    ![figure 16](images/dg-fig16-specifyinfo.png)
-
-    Figure 16. Specify information about the new package
-
-4.  Click **Next**, and then select **Standard program** as the program type.
-5.  On the **Standard Program** page, select a name, and then set the **Command Line** property to **XCopy \\\\Shares\\CatalogShare C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} /H /K /E /Y**.
-6.  On the **Standard Program** page, select the following options (Figure 17):
-
-    -   In **Name**, type **Contoso Catalog File Copy Program**.
-    -   In **Command line**, browse to the program location.
-    -   In **Startup folder**, type **C:\\Windows\\System32**.
-    -   From the **Run** list, select **Hidden**.
-    -   From the **Program can run** list, select **Whether or not a user is logged on**.
-    -   From the **Drive mode** list, select **Runs with UNC name**.
-
-    ![figure 17](images/dg-fig17-specifyinfo.png)
-
-    Figure 17. Specify information about the standard program
-
-7.  Accept the defaults for the rest of the wizard, and then close the wizard.
-After you create the deployment package, deploy it to a collection so that the clients will receive the catalog files. In this example, you deploy the package you just created to a test collection:
-
-1.  In the Software Library workspace, navigate to Overview\\Application Management\\Packages, right-click the catalog file package, and then click **Deploy**.
-2.  On the **General** page, select the test collection to which the catalog files will be deployed, and then click **Next**.
-3.  On the **Content** page, click **Add** to select the distribution point that will serve content to the selected collection, and then click **Next**.
-4.  On the **Deployment Settings** page, select **Required** in the **Purpose** box.
-5.  On the **Scheduling** page, click **New**.
-6.  In the **Assignment Schedule** dialog box, select **Assign immediately after this event**, set the value to **As soon as possible**, and then click **OK**.
-7.  On the **Scheduling** page, click **Next**.
-8.  On the **User Experience** page (Figure 18), set the following options, and then click **Next**:
-
-    -   Select the **Software installation** check box.
-    -   Select the **Commit changes at deadline or during a maintenance window (requires restarts)** check box.
-
-    ![figure 18](images/dg-fig18-specifyux.png)
-
-    Figure 18. Specify the user experience
-
-9.  On the **Distribution Points** page, in the **Deployment options** box, select **Run program from distribution point**, and then click **Next**.
-10. On the **Summary** page, review the selections, and then click **Next**.
-11. Close the wizard.
-
-### Inventory catalog files with System Center Configuration Manager
-
-When catalog files have been deployed to the machines within your environment, whether by using Group Policy or System Center Configuration Manager, you can inventory them with the software inventory feature of System Center Configuration Manager. The following process walks you through the enablement of software inventory to discover catalog files on your managed systems through the creation and deployment of a new client settings policy.
-
->**Note:**  A standard naming convention for your catalog files will significantly simplify the catalog file software inventory process. In this example, *-Contoso* has been added to all catalog file names.
-
-1.  Open the Configuration Manager console, and select the Administration workspace.
-2.  Navigate to **Overview\\Client Settings**, right-click **Client Settings**, and then click **Create Custom Client Device Settings**.
-3.  Name the new policy, and select the **Software Inventory** check box from the **Select and then configure the custom settings for client devices** list, as shown in Figure 19.
-
-    ![figure 19](images/dg-fig19-customsettings.png)
-
-    Figure 19. Select custom settings
-
-4.  In the navigation pane, click **Software Inventory**, and then click **Set Types**, as shown in Figure 20.
-
-    ![figure 20](images/dg-fig20-setsoftwareinv.png)
-
-    Figure 20. Set the software inventory
-
-5.  In the **Configure Client Setting** dialog box, click the **Start** button to open the **Inventories File Properties** dialog box.
-
-6.  In the **Name** box, type **\*Contoso.cat**, and then click **Set**.
-
-    >**Note:**  **\*Contoso.cat** is the naming convention used in this example. This should mimic the naming convention you use for your catalog files.
-     
-7.  In the **Path Properties** dialog box, select **Variable or path name**, and then type **C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE}** in the box, as shown in Figure 21.
-    
-    ![figure 21](images/dg-fig21-pathproperties.png)
-    
-    Figure 21. Set the path properties
-
-8.  Click **OK**.
-
-9.  Now that you have created the client settings policy, right-click the new policy, click **Deploy**, and then choose the collection on which you would like to inventory the catalog files.
-At the time of the next software inventory cycle, when the targeted clients receive the new client settings policy, you will be able to view the inventoried files in the built-in System Center Configuration Manager reports or Resource Explorer. To view the inventoried files on a client within Resource Explorer, complete the following steps:
-
-1.  Open the Configuration Manager console, and select the Assets and Compliance workspace.
-2.  Navigate to Overview\\Devices, and search for the device on which you want to view the inventoried files.
-3.  Right-click the computer, point to **Start**, and then click **Resource Explorer**.
-4.  In Resource Explorer, navigate to Software\\File Details to view the inventoried catalog files.
-
->**Note:**  If nothing is displayed in this view, navigate to Software\\Last Software Scan in Resource Explorer to verify that the client has recently completed a software inventory scan.
- 
-## Code integrity policies
-
-Code integrity policies maintain the standards by which a computer running Windows 10 determines whether an application is trustworthy and can be run. For an overview of code integrity, see the [Configurable code integrity](#configurable-code-integrity) section.
-
-A common system imaging practice in today’s IT organization is to establish a “golden” image as a reference for what an ideal system should look like, and then use that image to clone additional company assets. Code integrity policies follow a similar methodology, that begins with the establishment of a golden PC. Like when imaging, you can have multiple golden PCs based on model, department, application set, and so on. Although the thought process around the creation of code integrity policies is similar to imaging, these policies should be maintained independently. Assess the necessity of additional code integrity policies based on what should be allowed to be installed and run and for whom.
-
->**Note:**  Each machine can have only **one** code integrity policy at a time. Whichever way you deploy this policy, it is renamed to SIPolicy.p7b and copied to C:\\Windows\\System32\\CodeIntegrity. Keep this in mind when you create your code integrity policies.
-
-Optionally, code integrity policies can align with your software catalog as well as any IT department–approved applications. One simple method to implement code integrity policies is to use existing images to create one master code integrity policy. You do so by creating a code integrity policy from each image, and then by merging the policies. This way, what is installed on all of those images will be allowed to run, should the applications be installed on a computer based on a different image. Alternatively, you may choose to create a base applications policy and add policies based on the computer’s role or department. Organizations have a choice of how their policies are created, merged or serviced, and managed.
-
->**Note:**  The following section assumes that you will deploy code integrity policies as part of your Device Guard deployment. Alternatively, configurable code integrity is available without the enablement of Device Guard.
-
-### Code integrity policy rules
-
-Code integrity policies consist of several components. The two major components, which are configurable, are called *policy rules* and *file rules*, respectively. Code integrity policy rules are options that the code integrity policy creator can specify on the policy. These options include the enablement of audit mode, UMCI, and so on. You can modify these options in a new or existing code integrity policy. File rules are the level to which the code integrity policy scan ties each binary trust. For example, the hash level is going to itemize each discovered hash on the system within the generated code integrity policy. This way, when a binary prepares to run, the code integrity service will validate its hash value against the trusted hashes found in the code integrity policy. Based on that result, the binary will or will not be allowed to run.
-
-To modify the policy rule options of an existing code integrity policy, use the **Set-RuleOption** Windows PowerShell cmdlet. Note the following examples of how to use this cmdlet to add and remove a rule option on an existing code integrity policy:
-
--   To enable UMCI, add rule option 0 to an existing policy by running the following command:
-
-    `Set-RuleOption -Option 0 -FilePath <Path to policy>`
-
--   To disable UMCI on an existing code integrity policy, remove rule option 0 by running the following command:
-
-    ` Set-RuleOption -Option 0 -FilePath <Path to policy> -Delete`
-
-You can set several rule options within a code integrity policy. Table 2 lists each rule and its high-level meaning.
-
-Table 2. Code integrity policy - policy rule options
-
-| Rule option | Description |
-|------------ | ----------- |
-| **0 Enabled:UMCI** | Code integrity policies restrict both kernel-mode and user-mode binaries. By default, only kernel-mode binaries are restricted. Enabling this rule option validates user mode executables and scripts. |
-| **1 Enabled:Boot Menu Protection** | This option is not currently supported. |
-| **2 Required:WHQL** | By default, legacy drivers that are not Windows Hardware Quality Labs (WHQL) signed are allowed to execute. Enabling this rule requires that every executed driver is WHQL signed and removes legacy driver support. Going forward, every new Windows 10–compatible driver must be WHQL certified. |
-| **3 Enabled:Audit Mode (Default)** | Enables the execution of binaries outside of the code integrity policy but logs each occurrence in the CodeIntegrity event log, which can be used to update the existing policy before enforcement. To enforce a code integrity policy, remove this option. |
-| **4 Disabled:Flight Signing** | If enabled, code integrity policies will not trust flightroot-signed binaries. This would be used in the scenario in which organizations only want to run released binaries, not flighted builds. |
-| **5 Enabled:Inherent Default Policy** | This option is not currently supported. |
-| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and have UpdatePolicySigners added to the policy to enable future policy modifications. |
-| **7 Allowed:Debug Policy Augmented** | This option is not currently supported. |
-| **8 Required:EV Signers** | In addition to being WHQL signed, this rule requires that drivers must have been submitted by a partner that has an Extended Verification (EV) certificate. All future Windows 10 and later drivers will meet this requirement. |
-| **9 Enabled:Advanced Boot Options Menu** | The F8 preboot menu is disabled by default for all code integrity policies. Setting this rule option allows the F8 menu to appear to physically present users. |
-| **10 Enabled:Boot Audit on Failure** | Used when the code integrity policy is in enforcement mode. When a driver fails during startup, the code integrity policy will be placed in audit mode so that Windows will load. Administrators can validate the reason for the failure in the CodeIntegrity event log. |
-File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as low as the hash of each binary and as high as a PCA certificate. File rule levels are specified both when you create a new code integrity policy from a scan and when you create a policy from audit events. In addition, to combine rule levels found in multiple policies, you can merge the policies. When merged, code integrity policies combine their file rules. Each file rule level has its benefit and disadvantage. Use Table 3 to select the appropriate protection level for your available administrative resources and Device Guard deployment scenario.
-
-Table 3. Code integrity policy - file rule levels
-
-| Rule level | Description |
-|----------- | ----------- |
-| **Hash** | Specifies individual hash values for each discovered binary. Although this level is specific, it can cause additional administrative overhead to maintain the current product versions’ hash values. Each time a binary is updated, the hash value changes, therefore requiring a policy update. |
-| **FileName** | Specifies individual binary file names. Although the hash values for an application are modified when updated, the file names are typically not. This offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
-| **SignedVersion** | This combines the publisher rule with a file version number. This option allows anything from the specified publisher, with a file version at or above the specified version number, to run. |
-| **Publisher** | This is a combination of the PCA certificate and the common name (CN) on the leaf certificate. In the scenario that a PCA certificate is used to sign multiple companies’ applications (such as VeriSign), this rule level allows organizations to trust the PCA certificate but only for the company whose name is on the leaf certificate (for example, Intel for device drivers). This level trusts a certificate with a long validity period but only when combined with a trusted leaf certificate. |
-| **FilePublisher** | This is a combination of the publisher file rule level and the SignedVersion rule level. Any signed file from the trusted publisher that is the specified version or newer is trusted. |
-| **LeafCertificate** | Adds trusted signers at the individual signing certificate level. The benefit of using this level versus the individual hash level is that new versions of the product will have different hash values but typically the same signing certificate. Using this level, no policy update would be needed to run the new version of the application. However, leaf certificates have much shorter validity periods than PCA certificates, so additional administrative overhead is associated with updating the code integrity policy when these certificates expire. |
-| **PcaCertificate** | Adds the highest certificate in the provided certificate chain to signers. This is typically one certificate below the root certificate, because the scan does not validate anything above the presented signature by going online or checking local root stores. |
-| **RootCertificate** | Currently unsupported. |
-| **WHQL** | Trusts binaries if they have been validated and signed by WHQL. This is primarily for kernel binaries. |
-| **WHQLPublisher** | This is a combination of the WHQL and the CN on the leaf certificate and is primarily for kernel binaries. |
-| **WHQLFilePublisher** | Specifies that the binaries are validated and signed by WHQL, with a specific publisher (WHQLPublisher), and that the binary is the specified version or newer. This is primarily for kernel binaries. |
-
->**Note:**  When you create code integrity policies with the **New-CIPolicy** cmdlet, you can specify a primary file rule level by including the **–Level** parameter. For discovered binaries that cannot be trusted based on the primary file rule criteria, use the **–Fallback** parameter. For example, if the primary file rule level is PCACertificate but you would like to trust the unsigned applications as well, using the Hash rule level as a fallback adds the hash values of binaries that did not have a signing certificate.
-
-### Create code integrity policies from golden PCs
-
-The process to create a golden code integrity policy from a reference system is straightforward. This section outlines the process that is required to successfully create a code integrity policy with Windows PowerShell. First, for this example, you must initiate variables to be used during the creation process. Rather than using variables, you can simply use the full file paths in the command. Next, you create the code integrity policy by scanning the system for installed applications. When created, the policy file is converted to binary format so that Windows can consume its contents.
-
->**Note:**  Before you begin this procedure, ensure that the reference PC is clean of viruses or malware. Each piece of installed software should be validated as trustworthy before you create this policy. Also, be sure that any software that you would like to be scanned is installed on the system before you create the code integrity policy.
-
-To create a code integrity policy, copy each of the following commands into an elevated Windows PowerShell session, in order:
-
-1.  Initialize variables that you will use:
-
-    `$CIPolicyPath=$env:userprofile+"\Desktop\"`
-    `$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
-    `$CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
-
-2.  Create a new code integrity policy by scanning the system for installed applications:
-
-    `New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy –UserPEs 3> CIPolicyLog.txt `
-
-   >**Note:**  By specifying the *–UserPEs* parameter, rule option **0 Enabled:UMCI** is automatically added to the code integrity policy. If you do not specify this parameter, use the following command to enable UMCI:
-   
-    `Set-RuleOption -Option 0 -FilePath $InitialCIPolicy`
-   
-   >**Note:**  You can add the *–Fallback* parameter to catch any applications not discovered using the primary file rule level specified by the *–Level* parameter. For more information about file rule level options, see the [Code integrity policy rules](#code-integrity-policy-rules) section.
-   
-   >**Note:**  If you would like to specify the code integrity policy scan to look only at a specific drive, you can do so by using the *–ScanPath* parameter. Without this parameter, as shown in the example, the entire system is scanned.
-
-3.  Convert the code integrity policy to a binary format:
-
-    `ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
-
-After you complete these steps, the Device Guard binary file (DeviceGuardPolicy.bin) and original .xml file (IntialScan.xml) will be available on your desktop. You can use the binary version as a code integrity policy or sign it for additional security.
-
->**Note:**  Microsoft recommends that you keep the original .xml file of the policy for use when you need to merge the code integrity policy with another policy or update its rule options. Alternatively, you would have to create a new policy from a new scan for servicing. For more information about how to merge code integrity policies, see the [Merge code integrity policies](#merge-code-integrity-policies) section.
-
-Microsoft recommends that every code integrity policy be run in audit mode before being enforced. Doing so allows administrators to discover any issues with the policy without receiving error message dialog boxes. For information about how to audit a code integrity policy, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
-
-### Audit code integrity policies
-
-When code integrity policies are run in audit mode, it allows administrators to discover any applications that were missed during an initial policy scan and to identify any new applications that have been installed and run since the original policy was created. While a code integrity policy is running in audit mode, any binary that runs and would have been denied had the policy been enforced is logged in the Applications and Services Logs\\Microsoft\\CodeIntegrity\\Operational event log. When these logged binaries have been validated, they can easily be added to a new code integrity policy. When the new exception policy is created, you can merge it with your existing code integrity policies.
-
->**Note:**  Before you begin this process, you need to create a code integrity policy binary file. If you have not already done so, see the [Create an audit code integrity policy](#create-an-audit-code-integrity-policy) section for a step-by-step walkthrough of the process to create a code integrity policy and convert it to binary format.
-
-To audit a code integrity policy with local policy:
-
-1.  Copy the DeviceGuardPolicy.bin file that you created in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) section to C:\\Windows\\System32\\CodeIntegrity.
-2.  On the system you want to run in audit mode, open the Local Group Policy Editor by running **GPEdit.msc**.
-3.  Navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard, and then select **Deploy Code Integrity Policy**. Enable this setting by using the file path C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 22.
-
-   >**Note:**  *DeviceGuardPolicy.bin* is not a required policy name. This name was simply used in the [Create code integrity policies from golden PCs](#create-code-golden) section and so was used here. Also, this policy file does not need to be copied to every system. Alternatively, you can copy the code integrity policies to a file share to which all computer accounts have access.
-   
-   >**Note:**  Any policy you select here is converted to SIPolicy.p7b when it is deployed to the individual computers.
-   
-   ![figure 22](images/dg-fig22-deploycode.png)
-   
-   Figure 22. Deploy your code integrity policy
-   
-   >**Note:**     You may have noticed that the GPO setting references a .p7b file and this policy uses a .bin file. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the Windows 10 computers. Microsoft recommends that you make your code integrity policies friendly and allow the system to convert the policy names for you. By doing this, it ensures that the policies are easily distinguishable when viewed in a share or any other central repository.
-
-4.  Restart reference system for the code integrity policy to take effect.
-5.  Monitor the CodeIntegrity event log. While in audit mode, any exception to the deployed code integrity policy will be logged in the Applications and Services Logs\\Microsoft\\CodeIntegrity\\Operational event log, as shown in 
-Figure 23.
-
-   ![figure 23](images/dg-fig23-exceptionstocode.png)
-
-   Figure 23. Exceptions to the deployed code integrity policy
-
-6.  Validate any code integrity policy exceptions.
-
-    After you run a code integrity policy in audit mode, Microsoft recommends that each logged exception be researched and validated. In addition to discovering which application is causing the exception and ensuring that it should be added to the code integrity policy, be sure to check which file level should be used to trust each application. Although the Hash file rule level will catch all of these exceptions, it may not be the best way to trust all of the exceptions. For information about file rule levels and their purpose, see the [Code integrity policy rules](#code-integrity-policy-rules) section.
-
-7.  Create code integrity policy from audit events.
-
-    For information about how to create code integrity policies from audit events, see the [Create code integrity policies from golden PCs](#create-code-golden) section.
-
->**Note:**  An alternative method to test a policy is to rename the test file to SIPolicy.p7b and drop it into C:\\Windows\\System32\\CodeIntegrity, rather than deploy it with the local machine policy.
-
-### Create an audit code integrity policy
-
-When you run code integrity policies in audit mode, validate any exceptions and determine whether you will need to add them to the code integrity policy you want to audit. Use the system as you normally would to ensure that any use exceptions are logged. When you are ready to create a code integrity policy from the auditing events, complete the following steps in an elevated Windows PowerShell session:
-
-1.  Initialize the variables that will be used:
-
-    `$CIPolicyPath=$env:userprofile+"\Desktop\"`
-    `$CIAuditPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
-
-2.  Analyze audit results.
-
-    Before you create a code integrity policy from audit events, Microsoft recommends that each exception be analyzed, as discussed in steps 5 and 6 of the [Audit code integrity policies](#audit-code-integrity-policies) section.
-
-3.  Generate a new code integrity policy from logged audit events:
-
-    `New-CIPolicy -Audit -Level Hash -FilePath $CIAuditPolicy –UserPEs 3> CIPolicylog.txt`
-
->**Note:**  When you create policies from audit events, you should carefully consider the file rule level that you select to trust. In this example, you use the Hash rule level, which should be used as a last resort.
-After you complete these steps, the Device Guard audit policy .xml file (DeviceGuardAuditPolicy.xml) will be available on your desktop. You can now use this file to update the existing code integrity policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing code integrity policy, see the [Merge code integrity policies](#merge-code-integrity-policies) section.
-
->**Note:**  You may have noticed that you did not generate a binary version of this policy as you did in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) section. This is because code integrity policies created from an audit log are not intended to run as stand-alone policies but rather to update existing code integrity policies.
-
-### Merge code integrity policies
-
-When you develop code integrity policies, you will occasionally need to merge two policies. A common example is when a code integrity policy is initially created and audited. Another example is when you create a single master policy by using multiple code integrity policies previously created from golden PCs. Because each Windows 10 machine can have only one code integrity policy, it is important to properly maintain these policies. In this example, audit events have been saved into a secondary code integrity policy that you then merge with the initial code integrity policy.
-
->**Note:**  The following example uses the code integrity policy .xml files that you created in the [Create code integrity policies from golden PCs](#create-code-integrity-policies-from-golden-pcs) and [Audit code integrity policies](#audit-code-integrity-policies) sections. You can follow this process, however, with any two code integrity policies you would like to combine.
-
-To merge two code integrity policies, complete the following steps in an elevated Windows PowerShell session:
-
-1.  Initialize the variables that will be used:
-
-    ` $CIPolicyPath=$env:userprofile+"\Desktop\"`
-    `$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml"`
-    `$AuditCIPolicy=$CIPolicyPath+"DeviceGuardAuditPolicy.xml"`
-    `$MergedCIPolicy=$CIPolicyPath+"MergedPolicy.xml"`
-    `    $CIPolicyBin=$CIPolicyPath+"NewDeviceGuardPolicy.bin"`
-    
-    >**Note:**  The variables in this section specifically expect to find an initial policy on your desktop called InitialScan.xml and an audit code integrity policy called DeviceGuardAuditPolicy.xml. If you want to merge other code integrity policies, update the variables accordingly.
-     
-2.  Merge two policies to create a new code integrity policy:
-    
-    `Merge-CIPolicy -PolicyPaths $InitialCIPolicy,$AuditCIPolicy -OutputFilePath $MergedCIPolicy`
-3.  
-Convert the merged code integrity policy to binary format:
-
-    ` ConvertFrom-CIPolicy $MergedCIPolicy $CIPolicyBin `
-
-Now that you have created a new code integrity policy called NewDeviceGuardPolicy.bin, you can deploy the policy to systems manually or by using Group Policy or Microsoft client management solutions. For information about how to deploy this new policy with Group Policy, see the [Deploy and manage code integrity policies with Group Policy](#deploy-manage-code-gp) section.
-
-**Enforce code integrity policies**
-
-Every code integrity policy is created with audit mode enabled. After you have successfully deployed and tested a code integrity policy in audit mode and are ready to test the policy in enforced mode, complete the following steps in an elevated Windows PowerShell session:
-
->**Note:**  Every code integrity policy should be tested in audit mode first. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity) section.
-
-1.  Initialize the variables that will be used:
-
-    `$CIPolicyPath=$env:userprofile+"\Desktop\"`
-    `$InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" `
-    `$EnforcedCIPolicy=$CIPolicyPath+"EnforcedPolicy.xml"`
-    `$CIPolicyBin=$CIPolicyPath+"EnforcedDeviceGuardPolicy.bin"`
-
-    >**Note:**  The initial code integrity policy that this section referenced was created in the [Create code integrity polices from golden PCs](#create-code-golden) section. If you are using a different code integrity policy, update the **CIPolicyPath** and **InitialCIPolicy** variables.
-     
-2.  Copy the initial file to maintain an original copy:
-
-    `cp $InitialCIPolicy $EnforcedCIPolicy`
-
-3.  Remove the audit mode rule option:
-
-    `Set-RuleOption -Option 3 -FilePath $EnforcedCIPolicy -Delete`
-
-    >**Note:**  Rather than adding an **Enforced** option, code integrity policies are implicitly enforced if no **Audit Mode Enabled** option is present.
-     
-4.  Convert the new code integrity policy to binary format:
-    
-    `ConvertFrom-CIPolicy $EnforcedCIPolicy $CIPolicyBin`
-    >**Note:**  Microsoft strongly recommends that you enable rule options 9 and 10 before you run any enforced policy for the first time. If already present in the policy, do not remove it. Doing so allows Windows to start if the code integrity policy blocks a kernel-mode driver from running and provides administrators with a pre-boot command prompt. When ready for enterprise deployment, you can remove these options.
-     
-Now that this policy has been enforced, you can deploy it to your test machines. Rename the policy to SIPolicy.p7b and copy it to C:\\Windows\\System32\\CodeIntegrity for testing, or deploy the policy through Group Policy by following the instructions in the [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy) section, or through client management software by following the instructions in the section “Deploying and managing code integrity policies by using Microsoft client management solutions.”
-
-**Signing code integrity policies with SignTool.exe**
-
-Signed code integrity policies give organizations the highest level of malware protection available in Windows 10. In addition to their enforced policy rules, signed policies cannot be modified or deleted by a user or administrator on the machine. These policies are designed to prevent administrative tampering and kernel mode exploit access. With this in mind, it is much more difficult to remove signed code integrity policies than unsigned ones. Before you sign and deploy a signed code integrity policy, Microsoft recommends that you audit the policy to discover any blocked applications that should be allowed to run. For more information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies) section.
-
-Signing code integrity policies by using an on-premises CA-generated certificate or a purchased code signing certificate is straightforward. If you do not currently have a code signing certificate exported in .pfx format (containing private keys, extensions, and root certificates), see [Create a Device Guard code signing certificate](#create-a-device-guard-code-signing-certificate) to create one with your on-premises CA. Before signing code integrity policies for the first time, be sure to enable rule options 9 and 10 to leave troubleshooting options available to test administrators. When validated and ready for enterprise deployment, you can remove these options. For information about how to add rule options, see the [Code integrity policy rules](#code-integrity-policy-rules) section.
-
->**Note:**  Signing code integrity policies is the last step in a code integrity deployment. It is much more difficult to remove a signed code integrity policy than an unsigned one. Before you deploy a signed code integrity policy to deployed client computers, be sure to test its effect on a subset of machines.
-
-To sign a code integrity policy with SignTool.exe, you need the following components:
-
--   SignTool.exe, found in the Windows SDK (Windows 7 or later)
--   The binary format of the code integrity policy that you generated in the [Create code integrity policies from golden PCs](#create-code-golden) section or another code integrity policy that you have created
--   An internal CA code signing certificate or a purchased code signing certificate
-
-If you do not have a code signing certificate, see the [Create a Device Guard code signing certificate](#create-dg-code) section for instructions on how to create one. If you use an alternate certificate or code integrity policy, be sure to update the following steps with the appropriate variables and certificate so that the commands will function properly. To sign the existing code integrity policy, copy each of the following commands into an elevated 
-Windows PowerShell session:
-
-1.  Initialize the variables that will be used:
-
-    `$CIPolicyPath=$env:userprofile+"\Desktop\" $InitialCIPolicy=$CIPolicyPath+"InitialScan.xml" $CIPolicyBin=$CIPolicyPath+"DeviceGuardPolicy.bin"`
-
-    >**Note:**  This example uses the code integrity policy that you created in the [Create code integrity policies from golden PCs](#create-code-golden) section. If you are signing another policy, be sure to update the **$CIPolicyPath** and **$CIPolicyBin** variables with the correct information.
-
-2.  Import the .pfx code signing certificate. Import the code signing certificate that you will use to sign the code integrity policy into the signing user’s personal store on the machine that will be doing the signing. In this example, you use the certificate that was created in the [Create a Device Guard code signing certificate](#create-dg-code) section.
-
-3.  Export the .cer code signing certificate. After the code signing certificate has been imported, export the .cer version to your desktop. This version will be added to the policy so that it can be updated later.
-
-4.  Navigate to your desktop as the working directory:
-
-    `cd $env:USERPROFILE\Desktop `
-
-5.  Add an update signer certificate to the code integrity policy:
-
-    `Add-SignerRule -FilePath $InitialCIPolicy -CertificatePath <Path to exported .cer certificate> -Kernel -User –Update`
-
-   >**Note:**  *&lt;Path to exported .cer certificate&gt;* should be the full path to the certificate that you exported in step 3.
-   
-   >**Note:**  Adding update signers is crucial to being able to modify or disable this policy in the future. For more information about how to disable signed code integrity policies, see the [Disable signed code integrity policies within Windows](#disable-signed-code) section.
-
-6.  Remove the unsigned policy rule option:
-
-    `Set-RuleOption -Option 6 -FilePath $InitialCIPolicy -Delete`
-
-7.  Convert the policy to binary format:
-
-    `ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin`
-
-8.  Sign the code integrity policy by using SignTool.exe:
-
-    `<Path to signtool.exe> sign -v /n "ContosoDGSigningCert" -p7 . -p7co 1.3.6.1.4.1.311.79.1 -fd sha256 $CIPolicyBin`
-    >**Note:**  The *&lt;Path to signtool.exe&gt;* variable should be the full path to the SignTool.exe utility. **ContosoDGSigningCert** is the subject name of the certificate that will be used to sign the code integrity policy. You should import this certificate to your personal certificate store on the machine you use to sign the policy.
-
-9.  Validate the signed file. When complete, the commands should output a signed policy file called DeviceGuardPolicy.bin.p7 to your desktop. You can deploy this file the same way you deploy an enforced or non-enforced policy. For information about how to deploy code integrity policies, see the [Deploy and manage code integrity policies with Group Policy](#deploy-and-manage-code-integrity-policies-with-group-policy) section.
-
-### Disable unsigned code integrity policies
-
-There may come a time when an administrator wants to disable a code integrity policy. For unsigned code integrity policies, this process is simple. Depending on how the code integrity policy was deployed, unsigned policies can be disabled in one of two ways. If a code integrity policy was manually enabled and copied to the code integrity folder location, simply delete the file and restart the machine. The following locations can contain executing code integrity policies:
-
--   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
--   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
-
-If the code integrity policy was deployed by using Group Policy, the GPO that is currently enabling and deploying the policy must be set to disabled. Then, the code integrity policy will be disabled on the next computer restart.
-
-### Disable signed code integrity policies within Windows
-
-Signed policies protect Windows from administrative manipulation as well as malware that has gained administrative-level access to the system. For this reason, signed code integrity policies are intentionally more difficult to remove than unsigned policies. They inherently protect themselves from modification or removal and therefore are difficult even for administrators to remove successfully. If the signed code integrity policy is manually enabled and copied to the CodeIntegrity folder, to remove the policy, you must complete the following steps:
-
->**Note:**  For reference, signed code integrity policies should be replaced and removed from the following locations:
-
--   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
--   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
-
-1.  Replace the existing policy with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
-
-    >**Note:**  To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
-
-2.  Restart the client computer.
-
-3.  Verify that the new signed policy exists on the client.
-
-    >**Note:**  If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
-
-4.  Delete the new policy.
-
-5.  Restart the client computer.
-
-If the signed code integrity policy has been deployed using by using Group Policy, you must complete the following steps:
-
-1.  Replace the existing policy in the GPO with another signed policy that has the **6 Enabled: Unsigned System Integrity Policy** rule option enabled.
-    >**Note:**  To take effect, this policy must be signed with a certificate previously added to the **UpdatePolicySigners** section of the original signed policy you want to replace.
-     
-2.  Restart the client computer.
-
-3.  Verify that the new signed policy exists on the client.
-
-    >**Note:**  If the signed policy that contains rule option 6 has not been processed on the client, the addition of an unsigned policy may cause boot failures.
-
-4.  Set the GPO to disabled.
-5.  Delete the new policy.
-6.  Restart the client computer.
-
-### Disable signed code integrity policies within the BIOS
-
-There may be a time when signed code integrity policies cause a boot failure. Because code integrity policies enforce kernel mode drivers, it is important that they be thoroughly tested on each software and hardware configuration before being enforced and signed. Signed code integrity policies are validated in the pre-boot sequence by using Secure Boot. When you disable the Secure Boot feature in the BIOS, and then delete the file from the following locations on the operating system disk, it allows the system to boot into Windows:
-
--   &lt;EFI System Partition&gt;\\Microsoft\\Boot\\
--   &lt;OS Volume&gt;\\Windows\\System32\\CodeIntegrity\\
-
-### <a href="" id="deploy-manage-code-gp"></a>
-
-**Deploy and manage code integrity policies with Group Policy**
-
-Code integrity policies can easily be deployed and managed with Group Policy. A Device Guard administrative template will be available in Windows Server 2016 that allows you to simplify deployment of Device Guard hardware-based security features and code integrity policies. The following procedure walks you through how to deploy a code integrity policy called **DeviceGuardPolicy.bin** to a test OU called *DG Enabled PCs* by using a GPO called **Contoso GPO Test**.
-
->**Note:**  This walkthrough requires that you have previously created a code integrity policy and have a Windows 10 client PC on which to test a Group Policy deployment. For more information about how to create a code integrity policy, see the [Create code integrity polices from golden PCs](#create-code-integrity-polices-from-golden-pcs) section.
-
->**Note:**  Signed code integrity policies can cause boot failures when deployed. Microsoft recommends that signed code integrity policies be thoroughly tested on each hardware platform before enterprise deployment.
-To deploy and manage a code integrity policy with Group Policy:
-
-1.  On a domain controller on a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** or searching for “Group Policy Management” in Windows Search.
-
-2.  Create a new GPO: right-click the DG Enabled PCs OU, and then click **Create a GPO in this domain, and Link it here**, as shown in Figure 24.
-
-    >**Note:**  The DG Enabled PCs OU is just an example of where to link the test GPO created in this section. Any OU name can be used. Also, security group filtering is an option when considering policy partitioning options based on the strategy discussed in the [Approach enterprise code integrity deployment](#approach-enterprise) section.
-   
-   ![figure 24](images/dg-fig24-creategpo.png)
-   
-   Figure 24. Create a GPO
-
-3.  Name new GPO **Contoso GPO Test**. This example uses Contoso GPO Test as the name of the GPO. You can choose any name that you prefer for this example.
-
-4.  Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
-
-5.  In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Then, right-click **Deploy Code Integrity Policy**, and then click **Edit**.
-
-    ![figure 25](images/dg-fig25-editcode.png)
-
-    Figure 25. Edit the code integration policy
-
-6.  In the **Display Code Integrity Policy** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
-   In this policy setting, you specify either the local path in which the policy will exist on the client computer or a Universal Naming Convention (UNC) path that the client computers will look to retrieve the latest version of the policy. This example copied the DeviceGuardPolicy.bin file onto the test machine and will enable this setting and use the file path C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 26.
-
-   >**Note:**  *DeviceGuardPolicy.bin* is not a required policy name: It was simply used in the [Create code integrity policies from golden PCs](#create-code-golden) section and so is used here, as well. Also, this policy file does not need to be copied to every computer. Alternatively, you can copy the code integrity policies to a file share to which the computer accounts have access. Any policy selected here is converted to SIPolicy.p7b when it is deployed to the individual client computers.
-   
-   ![figure 26](images/dg-fig26-enablecode.png)
-   
-   Figure 26. Enable the code integrity policy
-   
-   >**Note:**  You may have noticed that the GPO setting references a .p7b file and this example uses a .bin file for the policy. Regardless of the type of policy you deploy (.bin, .p7b, or .p7), they are all converted to SIPolicy.p7b when dropped on the Windows 10 client computers. Make your code integrity policies friendly and allow the system to convert the policy names for you to ensure that the policies are easily distinguishable when viewed in a share or any other central repository.
-
-7.  Close the Group Policy Management Editor, and then restart the Windows 10 test machine. Restarting the client computer updates the code integrity policy. For information about how to audit code integrity policies, see the [Audit code integrity policies](#audit-code-integrity-policies)section.
-
-## Create a Device Guard code signing certificate
-
-To sign catalog files or code integrity policies internally, you will either need a publicly issued code signing certificate or an internal CA. If you have purchased a code signing certificate, you can skip these steps and proceed to the sections that outline the steps to sign catalog files and code integrity policies. If you have not purchased a certificate but have an internal CA, complete these steps to create a code signing certificate:
-
-1.  Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
-2.  When connected, right-click **Certificate Templates**, and then click **Manage** to open the Certification Templates Console.
-
-    ![figure 27](images/dg-fig27-managecerttemp.png)
-
-    Figure 27. Manage the certificate templates
-
-3.  In the navigation pane, right-click the Code Signing certificate, and then click **Duplicate Template**.
-
-4.  On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** from the **Certification Authority** list, and then select **Windows 8 / Windows Server 2012** from the **Certificate recipient** list.
-5.  On the **General** tab, specify the **Template display name** and **Template name**. This example uses **DG Catalog Signing Certificate**.
-6.  On the **Request Handling** tab, select the **Allow private key to be exported** check box.
-7.  On the **Extensions** tab, select the **Basic Constraints** check box, and then click **Edit**.
-8.  In the **Edit Basic Constraints Extension** dialog box, select the **Enable the extension** check box, as shown in Figure 28.
-    
-    ![figure 28](images/dg-fig29-enableconstraints.png)
-    
-    Figure 28. Enable constraints on the new template
-9.  
-If a certificate manager is required to approve any issued certificates, on the **Issuance Requirements** tab, select **CA certificate manager approval**.
-10. On the **Subject Name** tab, select **Supply in the request**.
-11. On the **Security** tab, verify that whatever account will be used to request the certificate has the right to enroll the certificate.
-12. Click **OK** to create the template, and then close the Certificate Template Console.
-When this certificate template has been created, you must publish it to the CA published template store. To do so, complete the following steps:
-1.  In the Certification Authority MMC snap-in, right-click **Certification Templates**, point to **New**, and then click **Certificate Template to Issue**, as shown in Figure 29.
-
-    A list of available templates to issue appears, including the template you just created.
-    
-    ![figure 29](images/dg-fig30-selectnewcert.png)
-    
-    Figure 29. Select the new certificate template to issue
-    
-2.  Select the DG Catalog signing certificate, and then click **OK**.
-Now that the template is available to be issued, you must request one from the Windows 10 computer that you use to create and sign catalog files. To begin, open the MMC, and then complete the following steps:
-1.  In MMC, from the **File** menu, click **Add/Remove Snap-in**. Double-click **Certificates**, and then select **My user account**.
-2.  In the Certificates snap-in, right-click the Personal store folder, point to **All Tasks**, and then click **Request New Certificate**.
-3.  Click **Next** twice to get to the certificate selection list.
-4.  In the **Request Certificate** list, select your newly created code signing certificate, and then select the blue text that requests additional information, as shown in Figure 30.
-    
-    ![figure 30](images/dg-fig31-getmoreinfo.png)
-    
-    Figure 30. Get more information for your code signing certificate
-5.  
-In the **Certificate Properties** dialog box, for **Type**, select **Common name**. For **Value**, select **ContosoDGSigningCert**, and then click **Add**. When added, click **OK.**
-6.  Enroll and finish.
-
->**Note:**  If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
-
-This certificate must be installed in the user’s personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the machine on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
-
-1.  Right-click the certificate, point to **All Tasks**, and then click **Export**.
-2.  Click **Next**, and then select **Yes, export the private key**.
-3.  Choose the default settings, and then select **Export all extended properties**.
-4.  Set a password, select an export path, and then select **DGCatSigningCert.pfx** as the file name.
-When the certificate has been exported, import it into the personal store for the user who will be signing the catalog files or code integrity policies on the specific computer that will be signing them.
+- [Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
 
 ## Related topics
 
-- [AppLocker overview](applocker-overview.md)
-- [Code integrity](http://go.microsoft.com/fwlink/p/?LinkId=624173)
-- [Credential guard](credential-guard.md)
-- [Driver compatibility with Device Guard in Windows 10](http://go.microsoft.com/fwlink/p/?LinkId=624843)
-- [Dropping the Hammer Down on Malware Threats with Windows 10’s Device Guard](http://go.microsoft.com/fwlink/p/?LinkId=624844)
+[AppLocker overview](applocker-overview.md)
+
+<!-- The following topic is EIGHT YEARS OLD, but I don't really see anything better out there on Code Integrity that existed before Windows 10. -->
+
+[Code integrity](https://technet.microsoft.com/library/dd348642.aspx)
+
+[Protect derived domain credentials with Credential Guard](credential-guard.md)
+
+[Driver compatibility with Device Guard in Windows 10](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10)
+
+[Dropping the Hammer Down on Malware Threats with Windows 10’s Device Guard](https://channel9.msdn.com/Events/Ignite/2015/BRK2336)
+
+
diff --git a/windows/keep-secure/dynamic-access-control.md b/windows/keep-secure/dynamic-access-control.md
new file mode 100644
index 0000000000..643a78aa1c
--- /dev/null
+++ b/windows/keep-secure/dynamic-access-control.md
@@ -0,0 +1,139 @@
+---
+title: Dynamic Access Control Overview (Windows 10)
+description: Dynamic Access Control Overview
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Dynamic Access Control Overview
+
+**Applies to**
+-   Windows Server 2016
+
+This overview topic for the IT professional describes Dynamic Access Control and its associated elements, which were introduced in Windows Server 2012 and Windows 8.
+
+Domain-based Dynamic Access Control enables administrators to apply access-control permissions and restrictions based on well-defined rules that can include the sensitivity of the resources, the job or role of the user, and the configuration of the device that is used to access these resources.
+
+For example, a user might have different permissions when they access a resource from their office computer versus when they are using a portable computer over a virtual private network. Or access may be allowed only if a device meets the security requirements that are defined by the network administrators. When Dynamic Access Control is used, a user’s permissions change dynamically without additional administrator intervention if the user’s job or role changes (resulting in changes to the user’s account attributes in AD DS).
+
+Dynamic Access Control is not supported in Windows operating systems prior to Windows Server 2012 and Windows 8. When Dynamic Access Control is configured in environments with supported and non-supported versions of Windows, only the supported versions will implement the changes.
+
+Features and concepts associated with Dynamic Access Control include:
+
+-   [Central access rules](#bkmk-rules)
+
+-   [Central access policies](#bkmk-policies)
+
+-   [Claims](#bkmk-claims)
+
+-   [Expressions](#bkmk-expressions2)
+
+-   [Proposed permissions](#bkmk-permissions2)
+
+### <a href="" id="bkmk-rules"></a>Central access rules
+
+A central access rule is an expression of authorization rules that can include one or more conditions involving user groups, user claims, device claims, and resource properties. Multiple central access rules can be combined into a central access policy.
+
+If one or more central access rules have been defined for a domain, file share administrators can match specific rules to specific resources and business requirements.
+
+### <a href="" id="bkmk-policies"></a>Central access policies
+
+Central access policies are authorization policies that include conditional expressions. For example, let’s say an organization has a business requirement to restrict access to personally identifiable information (PII) in files to only the file owner and members of the human resources (HR) department who are allowed to view PII information. This represents an organization-wide policy that applies to PII files wherever they are located on file servers across the organization. To implement this policy, an organization needs to be able to:
+
+-   Identify and mark the files that contain the PII.
+
+-   Identify the group of HR members who are allowed to view the PII information.
+
+-   Add the central access policy to a central access rule, and apply the central access rule to all files that contain the PII, wherever they are located amongst the file servers across the organization.
+
+Central access policies act as security umbrellas that an organization applies across its servers. These policies are in addition to (but do not replace) the local access policies or discretionary access control lists (DACLs) that are applied to files and folders.
+
+### <a href="" id="bkmk-claims"></a>Claims
+
+A claim is a unique piece of information about a user, device, or resource that has been published by a domain controller. The user’s title, the department classification of a file, or the health state of a computer are valid examples of a claim. An entity can involve more than one claim, and any combination of claims can be used to authorize access to resources. The following types of claims are available in the supported versions of Windows:
+
+-   **User claims**   Active Directory attributes that are associated with a specific user.
+
+-   **Device claims**   Active Directory attributes that are associated with a specific computer object.
+
+-   **Resource attributes**  Global resource properties that are marked for use in authorization decisions and published in Active Directory.
+
+Claims make it possible for administrators to make precise organization- or enterprise-wide statements about users, devices, and resources that can be incorporated in expressions, rules, and policies.
+
+### <a href="" id="bkmk-expressions2"></a>Expressions
+
+Conditional expressions are an enhancement to access control management that allow or deny access to resources only when certain conditions are met, for example, group membership, location, or the security state of the device. Expressions are managed through the Advanced Security Settings dialog box of the ACL Editor or the Central Access Rule Editor in the Active Directory Administrative Center (ADAC).
+
+Expressions help administrators manage access to sensitive resources with flexible conditions in increasingly complex business environments.
+
+### <a href="" id="bkmk-permissions2"></a>Proposed permissions
+
+Proposed permissions enable an administrator to more accurately model the impact of potential changes to access control settings without actually changing them.
+
+Predicting the effective access to a resource helps you plan and configure permissions for those resources before implementing those changes.
+
+## Additional changes
+
+
+Additional enhancements in the supported versions of Windows that support Dynamic Access Control include:
+
+### Support in the Kerberos authentication protocol to reliably provide user claims, device claims, and device groups.
+
+By default, devices running any of the supported versions of Windows are able to process Dynamic Access Control-related Kerberos tickets, which include data needed for compound authentication. Domain controllers are able to issue and respond to Kerberos tickets with compound authentication-related information. When a domain is configured to recognize Dynamic Access Control, devices receive claims from domain controllers during initial authentication, and they receive compound authentication tickets when submitting service ticket requests. Compound authentication results in an access token that includes the identity of the user and the device on the resources that recognize Dynamic Access Control.
+
+### Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.
+
+Every domain controller needs to have the same Administrative Template policy setting, which is located at **Computer Configuration\\Policies\\Administrative Templates\\System\\KDC\\Support Dynamic Access Control and Kerberos armoring**.
+
+### Support for using the Key Distribution Center (KDC) Group Policy setting to enable Dynamic Access Control for a domain.
+
+Every domain controller needs to have the same Administrative Template policy setting, which is located at **Computer Configuration\\Policies\\Administrative Templates\\System\\KDC\\Support Dynamic Access Control and Kerberos armoring**.
+
+### Support in Active Directory to store user and device claims, resource properties, and central access policy objects.
+
+### Support for using Group Policy to deploy central access policy objects.
+
+The following Group Policy setting enables you to deploy central access policy objects to file servers in your organization: **Computer Configuration\\Policies\\ Windows Settings\\Security Settings\\File System\\Central Access Policy**.
+
+### Support for claims-based file authorization and auditing for file systems by using Group Policy and Global Object Access Auditing
+
+You must enable staged central access policy auditing to audit the effective access of central access policy by using proposed permissions. You configure this setting for the computer under **Advanced Audit Policy Configuration** in the **Security Settings** of a Group Policy Object (GPO). After you configure the security setting in the GPO, you can deploy the GPO to computers in your network.
+
+### Support for transforming or filtering claim policy objects that traverse Active Directory forest trusts
+
+You can filter or transform incoming and outgoing claims that traverse a forest trust. There are three basic scenarios for filtering and transforming claims:
+
+-   **Value-based filtering**  Filters can be based on the value of a claim. This allows the trusted forest to prevent claims with certain values from being sent to the trusting forest. Domain controllers in trusting forests can use value-based filtering to guard against an elevation-of-privilege attack by filtering the incoming claims with specific values from the trusted forest.
+
+-   **Claim type-based filtering**  Filters are based on the type of claim, rather than the value of the claim. You identify the claim type by the name of the claim. You use claim type-based filtering in the trusted forest, and it prevents Windows from sending claims that disclose information to the trusting forest.
+
+-   **Claim type-based transformation**  Manipulates a claim before sending it to the intended target. You use claim type-based transformation in the trusted forest to generalize a known claim that contains specific information. You can use transformations to generalize the claim-type, the claim value, or both.
+
+## <a href="" id="software-requirements-"></a>Software requirements
+
+
+Because claims and compound authentication for Dynamic Access Control require Kerberos authentication extensions, any domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows to support authentication from Dynamic Access Control-aware Kerberos clients. By default, devices must use domain controllers in other sites. If no such domain controllers are available, authentication will fail. Therefore, you must support one of the following conditions:
+
+-   Every domain that supports Dynamic Access Control must have enough domain controllers running the supported versions of Windows Server to support authentication from all devices running the supported versions of Windows or Windows Server.
+
+-   Devices running the supported versions of Windows or that do not protect resources by using claims or compound identity, should disable Kerberos protocol support for Dynamic Access Control.
+
+For domains that support user claims, every domain controller running the supported versions of Windows server must be configured with the appropriate setting to support claims and compound authentication, and to provide Kerberos armoring. Configure settings in the KDC Administrative Template policy as follows:
+
+-   **Always provide claims**   Use this setting if all domain controllers are running the supported versions of Windows Server. In addition, set the domain functional level to Windows Server 2012 or higher.
+
+-   **Supported**   When you use this setting, monitor domain controllers to ensure that the number of domain controllers running the supported versions of Windows Server is sufficient for the number of client computers that need to access resources protected by Dynamic Access Control.
+
+If the user domain and file server domain are in different forests, all domain controllers in the file server’s forest root must be set at the Windows Server 2012 or higher functional level.
+
+If clients do not recognize Dynamic Access Control, there must be a two-way trust relationship between the two forests.
+
+If claims are transformed when they leave a forest, all domain controllers in the user’s forest root must be set at the Windows Server 2012 or higher functional level.
+
+A file server running a server operating system that supports Dyamic Access Control must have a Group Policy setting that specifies whether it needs to get user claims for user tokens that do not carry claims. This setting is set by default to **Automatic**, which results in this Group Policy setting to be turned **On** if there is a central policy that contains user or device claims for that file server. If the file server contains discretionary ACLs that include user claims, you need to set this Group Policy to **On** so that the server knows to request claims on behalf of users that do not provide claims when they access the server.
+
+## See also
+
+- [Access control overview](access-control.md)
diff --git a/windows/keep-secure/event-1102.md b/windows/keep-secure/event-1102.md
index ed03fdf472..388c844391 100644
--- a/windows/keep-secure/event-1102.md
+++ b/windows/keep-secure/event-1102.md
@@ -70,7 +70,7 @@ This event generates every time Windows Security audit log was cleared.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that cleared the system security audit log. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that cleared the system security audit log.
 
diff --git a/windows/keep-secure/event-4611.md b/windows/keep-secure/event-4611.md
index 4cd9e414e5..a60837e067 100644
--- a/windows/keep-secure/event-4611.md
+++ b/windows/keep-secure/event-4611.md
@@ -75,7 +75,7 @@ You typically see these events during operating system startup or user logon and
 
 -   **Security ID** \[Type = SID\]**:** SID of account that registered the trusted logon process. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that registered the trusted logon process.
 
diff --git a/windows/keep-secure/event-4616.md b/windows/keep-secure/event-4616.md
index 3be067d588..c1a78f4055 100644
--- a/windows/keep-secure/event-4616.md
+++ b/windows/keep-secure/event-4616.md
@@ -82,7 +82,7 @@ You will typically see these events with “**Subject\\Security ID**” = “**L
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change system time” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change system time” operation.
 
diff --git a/windows/keep-secure/event-4624.md b/windows/keep-secure/event-4624.md
index 3cb4f0c190..69598d3991 100644
--- a/windows/keep-secure/event-4624.md
+++ b/windows/keep-secure/event-4624.md
@@ -115,7 +115,7 @@ This event generates when a logon session is created (on destination machine). I
 
 -   **Security ID** \[Type = SID\]**:** SID of account that reported information about successful logon or invokes it. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that reported information about successful logon.
 
@@ -175,7 +175,7 @@ This event generates when a logon session is created (on destination machine). I
 
 -   **Security ID** \[Type = SID\]**:** SID of account for which logon was performed. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account for which logon was performed.
 
diff --git a/windows/keep-secure/event-4625.md b/windows/keep-secure/event-4625.md
index 9a040ff053..a615f8b796 100644
--- a/windows/keep-secure/event-4625.md
+++ b/windows/keep-secure/event-4625.md
@@ -89,7 +89,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that reported information about logon failure. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that reported information about logon failure.
 
@@ -125,7 +125,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of the account that was specified in the logon attempt. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that was specified in the logon attempt.
 
diff --git a/windows/keep-secure/event-4626.md b/windows/keep-secure/event-4626.md
index 83fa8fe837..68599c7060 100644
--- a/windows/keep-secure/event-4626.md
+++ b/windows/keep-secure/event-4626.md
@@ -85,7 +85,7 @@ This event generates on the computer to which the logon was performed (target co
 
 -   **Security ID** \[Type = SID\]**:** SID of account that reported information about claims. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that reported information about claims.
 
@@ -121,7 +121,7 @@ This event generates on the computer to which the logon was performed (target co
 
 -   **Security ID** \[Type = SID\]**:** SID of account for which logon was performed. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account for which logon was performed.
 
diff --git a/windows/keep-secure/event-4627.md b/windows/keep-secure/event-4627.md
index 811fd6f830..88500872dc 100644
--- a/windows/keep-secure/event-4627.md
+++ b/windows/keep-secure/event-4627.md
@@ -80,7 +80,7 @@ Multiple events are generated if the group membership information cannot fit in
 
 -   **Security ID** \[Type = SID\]**:** SID of account that reported information about successful logon or invokes it. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that reported information about successful logon or invokes it.
 
@@ -116,7 +116,7 @@ Multiple events are generated if the group membership information cannot fit in
 
 -   **Security ID** \[Type = SID\]**:** SID of account for which logon was performed. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account for which logon was performed.
 
diff --git a/windows/keep-secure/event-4634.md b/windows/keep-secure/event-4634.md
index 10b678d329..d84431bf79 100644
--- a/windows/keep-secure/event-4634.md
+++ b/windows/keep-secure/event-4634.md
@@ -75,7 +75,7 @@ It may be positively correlated with a “[4624](event-4624.md): An account was
 
 -   **Security ID** \[Type = SID\]**:** SID of account that was logged off. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that was logged off.
 
diff --git a/windows/keep-secure/event-4647.md b/windows/keep-secure/event-4647.md
index 16537024f3..21155852f6 100644
--- a/windows/keep-secure/event-4647.md
+++ b/windows/keep-secure/event-4647.md
@@ -74,7 +74,7 @@ It may be positively correlated with a “[4624](event-4624.md): An account was
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “logoff” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “logoff” operation.
 
diff --git a/windows/keep-secure/event-4648.md b/windows/keep-secure/event-4648.md
index 0f371abb75..48250044e9 100644
--- a/windows/keep-secure/event-4648.md
+++ b/windows/keep-secure/event-4648.md
@@ -82,7 +82,7 @@ It is also a routine event which periodically occurs during normal operating sys
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the new logon session with explicit credentials. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the new logon session with explicit credentials.
 
diff --git a/windows/keep-secure/event-4656.md b/windows/keep-secure/event-4656.md
index b7e3893812..7c7116e953 100644
--- a/windows/keep-secure/event-4656.md
+++ b/windows/keep-secure/event-4656.md
@@ -93,7 +93,7 @@ This event shows that access was requested, and the results of the request, but
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested a handle to an object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested a handle to an object.
 
diff --git a/windows/keep-secure/event-4657.md b/windows/keep-secure/event-4657.md
index 5b669ccb0d..31aa191a81 100644
--- a/windows/keep-secure/event-4657.md
+++ b/windows/keep-secure/event-4657.md
@@ -80,7 +80,7 @@ This event generates only if “Set Value" auditing is set in registry key’s [
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “modify registry value” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify registry value” operation.
 
diff --git a/windows/keep-secure/event-4658.md b/windows/keep-secure/event-4658.md
index 3de6b3da02..9dd8b57d2e 100644
--- a/windows/keep-secure/event-4658.md
+++ b/windows/keep-secure/event-4658.md
@@ -76,7 +76,7 @@ Typically this event is needed if you need to know how long the handle to the ob
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “close object’s handle” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “close object’s handle” operation.
 
diff --git a/windows/keep-secure/event-4660.md b/windows/keep-secure/event-4660.md
index 901bc15ae8..3b0fccc294 100644
--- a/windows/keep-secure/event-4660.md
+++ b/windows/keep-secure/event-4660.md
@@ -79,7 +79,7 @@ The advantage of this event is that it’s generated only during real delete ope
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete object” operation.
 
diff --git a/windows/keep-secure/event-4661.md b/windows/keep-secure/event-4661.md
index 278c77f651..6485f5b65a 100644
--- a/windows/keep-secure/event-4661.md
+++ b/windows/keep-secure/event-4661.md
@@ -84,7 +84,7 @@ This event generates only if Success auditing is enabled for the [Audit Handle M
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested a handle to an object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested a handle to an object.
 
diff --git a/windows/keep-secure/event-4662.md b/windows/keep-secure/event-4662.md
index 83640072e0..3dd3acf69f 100644
--- a/windows/keep-secure/event-4662.md
+++ b/windows/keep-secure/event-4662.md
@@ -84,7 +84,7 @@ You will get one 4662 for each operation type which was performed.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the operation.
 
diff --git a/windows/keep-secure/event-4663.md b/windows/keep-secure/event-4663.md
index 46cdac8cb0..0ba031b8a9 100644
--- a/windows/keep-secure/event-4663.md
+++ b/windows/keep-secure/event-4663.md
@@ -87,7 +87,7 @@ The main difference with “[4656](event-4656.md): A handle to an object was req
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to access an object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to access an object.
 
diff --git a/windows/keep-secure/event-4664.md b/windows/keep-secure/event-4664.md
index a62808d16d..f25e16f565 100644
--- a/windows/keep-secure/event-4664.md
+++ b/windows/keep-secure/event-4664.md
@@ -71,7 +71,7 @@ This event generates when an NTFS hard link was successfully created.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to create the hard link. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to create the hard link.
 
diff --git a/windows/keep-secure/event-4670.md b/windows/keep-secure/event-4670.md
index a7de5be046..61af502eb4 100644
--- a/windows/keep-secure/event-4670.md
+++ b/windows/keep-secure/event-4670.md
@@ -80,7 +80,7 @@ Before this event can generate, certain ACEs might need to be set in the object
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change object’s permissions” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change object’s permissions” operation.
 
diff --git a/windows/keep-secure/event-4672.md b/windows/keep-secure/event-4672.md
index bf0fff94de..fba1851afe 100644
--- a/windows/keep-secure/event-4672.md
+++ b/windows/keep-secure/event-4672.md
@@ -97,7 +97,7 @@ You typically will see many of these events in the event log, because every logo
 
 -   **Security ID** \[Type = SID\]**:** SID of account to which special privileges were assigned. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account to which special privileges were assigned.
 
diff --git a/windows/keep-secure/event-4673.md b/windows/keep-secure/event-4673.md
index 5282a6658e..6ef7b29b77 100644
--- a/windows/keep-secure/event-4673.md
+++ b/windows/keep-secure/event-4673.md
@@ -77,7 +77,7 @@ Failure event generates when service call attempt fails.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested privileged operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested privileged operation.
 
diff --git a/windows/keep-secure/event-4674.md b/windows/keep-secure/event-4674.md
index 41518d4e2b..d4a8792d03 100644
--- a/windows/keep-secure/event-4674.md
+++ b/windows/keep-secure/event-4674.md
@@ -80,7 +80,7 @@ Failure event generates when operation attempt fails.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested privileged operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested privileged operation.
 
diff --git a/windows/keep-secure/event-4675.md b/windows/keep-secure/event-4675.md
index dc8a19e120..ef1b726917 100644
--- a/windows/keep-secure/event-4675.md
+++ b/windows/keep-secure/event-4675.md
@@ -19,7 +19,7 @@ This event generates when SIDs were filtered for specific Active Directory trust
 
 See more information about SID filtering here: <https://technet.microsoft.com/en-us/library/cc772633(v=ws.10).aspx>.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 There is no example of this event in this document.
 
diff --git a/windows/keep-secure/event-4688.md b/windows/keep-secure/event-4688.md
index b152e305fb..d7d29f4334 100644
--- a/windows/keep-secure/event-4688.md
+++ b/windows/keep-secure/event-4688.md
@@ -95,7 +95,7 @@ This event generates every time a new process starts.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create process” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create process” operation.
 
@@ -119,7 +119,7 @@ This event generates every time a new process starts.
 
 -   **Security ID** \[Type = SID\] \[Version 2\]**:** SID of target account. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\] \[Version 2\]**:** the name of the target account.
 
diff --git a/windows/keep-secure/event-4689.md b/windows/keep-secure/event-4689.md
index e5f97fe698..bbfbbe6382 100644
--- a/windows/keep-secure/event-4689.md
+++ b/windows/keep-secure/event-4689.md
@@ -71,7 +71,7 @@ This event generates every time a process has exited.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “terminate process” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “terminate process” operation.
 
diff --git a/windows/keep-secure/event-4690.md b/windows/keep-secure/event-4690.md
index d7ac11d773..3ca6589561 100644
--- a/windows/keep-secure/event-4690.md
+++ b/windows/keep-secure/event-4690.md
@@ -72,7 +72,7 @@ This event generates if an attempt was made to duplicate a handle to an object.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to duplicate a handle to an object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to duplicate a handle to an object.
 
diff --git a/windows/keep-secure/event-4691.md b/windows/keep-secure/event-4691.md
index ba22553755..cd0e7d930c 100644
--- a/windows/keep-secure/event-4691.md
+++ b/windows/keep-secure/event-4691.md
@@ -75,7 +75,7 @@ These events are generated for [ALPC Ports](https://msdn.microsoft.com/en-us/lib
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested an access to the object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested an access to the object.
 
diff --git a/windows/keep-secure/event-4692.md b/windows/keep-secure/event-4692.md
index aba10585e3..4bd3aec488 100644
--- a/windows/keep-secure/event-4692.md
+++ b/windows/keep-secure/event-4692.md
@@ -82,7 +82,7 @@ Failure event generates when a Master Key backup operation fails for some reason
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested backup operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested backup operation.
 
diff --git a/windows/keep-secure/event-4693.md b/windows/keep-secure/event-4693.md
index 3134110a5c..c3563c431a 100644
--- a/windows/keep-secure/event-4693.md
+++ b/windows/keep-secure/event-4693.md
@@ -79,7 +79,7 @@ Failure event generates when a Master Key restore operation fails for some reaso
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “recover” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “recover” operation.
 
diff --git a/windows/keep-secure/event-4696.md b/windows/keep-secure/event-4696.md
index e4746f74c9..ced7a1d990 100644
--- a/windows/keep-secure/event-4696.md
+++ b/windows/keep-secure/event-4696.md
@@ -78,7 +78,7 @@ This event generates every time a process runs using the non-current access toke
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “assign token to process” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “assign token to process” operation.
 
@@ -120,7 +120,7 @@ This event generates every time a process runs using the non-current access toke
 
 -   **Security ID** \[Type = SID\]**:** SID of account through which the security token will be assigned to the new process. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account through which the security token will be assigned to the new process.
 
diff --git a/windows/keep-secure/event-4697.md b/windows/keep-secure/event-4697.md
index 0213aa9f0a..2493207abb 100644
--- a/windows/keep-secure/event-4697.md
+++ b/windows/keep-secure/event-4697.md
@@ -73,7 +73,7 @@ This event generates when new service was installed in the system.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that was used to install the service. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that was used to install the service.
 
diff --git a/windows/keep-secure/event-4698.md b/windows/keep-secure/event-4698.md
index 5d522281cb..495d00ad2f 100644
--- a/windows/keep-secure/event-4698.md
+++ b/windows/keep-secure/event-4698.md
@@ -70,7 +70,7 @@ This event generates every time a new scheduled task is created.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create scheduled task” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create scheduled task” operation.
 
diff --git a/windows/keep-secure/event-4699.md b/windows/keep-secure/event-4699.md
index a1c58890d6..885f708f76 100644
--- a/windows/keep-secure/event-4699.md
+++ b/windows/keep-secure/event-4699.md
@@ -70,7 +70,7 @@ This event generates every time a scheduled task was deleted.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete scheduled task” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete scheduled task” operation.
 
diff --git a/windows/keep-secure/event-4700.md b/windows/keep-secure/event-4700.md
index fa5a54c164..97ec3d2bcf 100644
--- a/windows/keep-secure/event-4700.md
+++ b/windows/keep-secure/event-4700.md
@@ -70,7 +70,7 @@ This event generates every time a scheduled task is enabled.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “enable scheduled task” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “enable scheduled task” operation.
 
diff --git a/windows/keep-secure/event-4701.md b/windows/keep-secure/event-4701.md
index 5c1cafe14f..7997ce6cf3 100644
--- a/windows/keep-secure/event-4701.md
+++ b/windows/keep-secure/event-4701.md
@@ -70,7 +70,7 @@ This event generates every time a scheduled task is disabled.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “enable scheduled task” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “enable scheduled task” operation.
 
diff --git a/windows/keep-secure/event-4702.md b/windows/keep-secure/event-4702.md
index 3d0071fd39..0fb4d69eea 100644
--- a/windows/keep-secure/event-4702.md
+++ b/windows/keep-secure/event-4702.md
@@ -70,7 +70,7 @@ This event generates every time scheduled task was updated/changed.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change/update scheduled task” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change/update scheduled task” operation.
 
diff --git a/windows/keep-secure/event-4703.md b/windows/keep-secure/event-4703.md
index bdce298519..154f3a9fe6 100644
--- a/windows/keep-secure/event-4703.md
+++ b/windows/keep-secure/event-4703.md
@@ -80,7 +80,7 @@ Token privileges provide the ability to take certain system-level actions that y
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “enable” or “disable” operation for **Target Account** privileges. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “enable” or “disable” operation for **Target Account** privileges.
 
@@ -102,7 +102,7 @@ Token privileges provide the ability to take certain system-level actions that y
 
 -   **Security ID** \[Type = SID\]**:** SID of account for which privileges were enabled or disabled. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account for which privileges were enabled or disabled.
 
diff --git a/windows/keep-secure/event-4704.md b/windows/keep-secure/event-4704.md
index ee98fd4712..234edaa3ac 100644
--- a/windows/keep-secure/event-4704.md
+++ b/windows/keep-secure/event-4704.md
@@ -72,7 +72,7 @@ You will see unique event for every user.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to local user right policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to local user right policy.
 
diff --git a/windows/keep-secure/event-4705.md b/windows/keep-secure/event-4705.md
index 7a5f1008fc..007bdc4ec3 100644
--- a/windows/keep-secure/event-4705.md
+++ b/windows/keep-secure/event-4705.md
@@ -72,7 +72,7 @@ You will see unique event for every user.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to local user right policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to local user right policy.
 
diff --git a/windows/keep-secure/event-4706.md b/windows/keep-secure/event-4706.md
index c6eba5f6a8..3eb6bdda15 100644
--- a/windows/keep-secure/event-4706.md
+++ b/windows/keep-secure/event-4706.md
@@ -76,7 +76,7 @@ This event is generated only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create domain trust” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create domain trust” operation.
 
diff --git a/windows/keep-secure/event-4707.md b/windows/keep-secure/event-4707.md
index 9a77188b80..011e640b52 100644
--- a/windows/keep-secure/event-4707.md
+++ b/windows/keep-secure/event-4707.md
@@ -72,7 +72,7 @@ This event is generated only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “remove domain trust” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “remove domain trust” operation.
 
diff --git a/windows/keep-secure/event-4713.md b/windows/keep-secure/event-4713.md
index f87013f4a6..482ad0768e 100644
--- a/windows/keep-secure/event-4713.md
+++ b/windows/keep-secure/event-4713.md
@@ -71,7 +71,7 @@ This event is generated only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to Kerberos policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to Kerberos policy.
 
diff --git a/windows/keep-secure/event-4715.md b/windows/keep-secure/event-4715.md
index d0e5dd0ef3..fea15f35d7 100644
--- a/windows/keep-secure/event-4715.md
+++ b/windows/keep-secure/event-4715.md
@@ -72,7 +72,7 @@ This event is always logged regardless of the "Audit Policy Change" sub-category
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change local audit policy security descriptor (SACL)” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change local audit policy security descriptor (SACL)” operation.
 
diff --git a/windows/keep-secure/event-4716.md b/windows/keep-secure/event-4716.md
index 373d14519b..8140c94b16 100644
--- a/windows/keep-secure/event-4716.md
+++ b/windows/keep-secure/event-4716.md
@@ -76,7 +76,7 @@ This event is generated only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “modify domain trust settings” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify domain trust settings” operation.
 
diff --git a/windows/keep-secure/event-4717.md b/windows/keep-secure/event-4717.md
index dbe74fada2..476501f806 100644
--- a/windows/keep-secure/event-4717.md
+++ b/windows/keep-secure/event-4717.md
@@ -72,7 +72,7 @@ You will see unique event for every user if logon user rights were granted to mu
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to local logon right user policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to local logon right user policy.
 
diff --git a/windows/keep-secure/event-4718.md b/windows/keep-secure/event-4718.md
index 44f5fc4624..af30328c64 100644
--- a/windows/keep-secure/event-4718.md
+++ b/windows/keep-secure/event-4718.md
@@ -72,7 +72,7 @@ You will see unique event for every user if logon user rights were removed for m
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to local logon right user policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to local logon right user policy.
 
diff --git a/windows/keep-secure/event-4719.md b/windows/keep-secure/event-4719.md
index 7a274992c8..69b248ec50 100644
--- a/windows/keep-secure/event-4719.md
+++ b/windows/keep-secure/event-4719.md
@@ -74,7 +74,7 @@ This event is always logged regardless of the "Audit Policy Change" sub-category
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to local audit policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to local audit policy.
 
diff --git a/windows/keep-secure/event-4720.md b/windows/keep-secure/event-4720.md
index 157b9b01a3..d333e12f03 100644
--- a/windows/keep-secure/event-4720.md
+++ b/windows/keep-secure/event-4720.md
@@ -92,7 +92,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create user account” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create user account” operation.
 
diff --git a/windows/keep-secure/event-4722.md b/windows/keep-secure/event-4722.md
index 6c96fd0b4a..37b03dbe77 100644
--- a/windows/keep-secure/event-4722.md
+++ b/windows/keep-secure/event-4722.md
@@ -75,7 +75,7 @@ For computer accounts, this event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “enable account” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “enable account” operation.
 
diff --git a/windows/keep-secure/event-4723.md b/windows/keep-secure/event-4723.md
index 8c23919260..cf74611ba8 100644
--- a/windows/keep-secure/event-4723.md
+++ b/windows/keep-secure/event-4723.md
@@ -82,7 +82,7 @@ Typically you will see 4723 events with the same **Subject\\Security ID** and **
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to change Target’s Account password. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to change Target’s Account password.
 
diff --git a/windows/keep-secure/event-4724.md b/windows/keep-secure/event-4724.md
index 977955100e..f0257228f4 100644
--- a/windows/keep-secure/event-4724.md
+++ b/windows/keep-secure/event-4724.md
@@ -81,7 +81,7 @@ For local accounts, a Failure event generates if the new password fails to meet
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to reset Target’s Account password. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to reset Target’s Account password.
 
diff --git a/windows/keep-secure/event-4725.md b/windows/keep-secure/event-4725.md
index 7dacfe0813..b5926a2941 100644
--- a/windows/keep-secure/event-4725.md
+++ b/windows/keep-secure/event-4725.md
@@ -75,7 +75,7 @@ For computer accounts, this event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “disable account” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “disable account” operation.
 
diff --git a/windows/keep-secure/event-4726.md b/windows/keep-secure/event-4726.md
index ab110e118d..b27daa7dd0 100644
--- a/windows/keep-secure/event-4726.md
+++ b/windows/keep-secure/event-4726.md
@@ -74,7 +74,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete user account” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete user account” operation.
 
diff --git a/windows/keep-secure/event-4731.md b/windows/keep-secure/event-4731.md
index 0f6116aca5..b92e02d280 100644
--- a/windows/keep-secure/event-4731.md
+++ b/windows/keep-secure/event-4731.md
@@ -76,7 +76,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create group” operation.
 
diff --git a/windows/keep-secure/event-4732.md b/windows/keep-secure/event-4732.md
index f688280574..41cf2a4a08 100644
--- a/windows/keep-secure/event-4732.md
+++ b/windows/keep-secure/event-4732.md
@@ -80,7 +80,7 @@ You will typically see “[4735](event-4735.md): A security-enabled local group
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “add member to the group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “add member to the group” operation.
 
diff --git a/windows/keep-secure/event-4733.md b/windows/keep-secure/event-4733.md
index b2de4567ac..40629bb96c 100644
--- a/windows/keep-secure/event-4733.md
+++ b/windows/keep-secure/event-4733.md
@@ -80,7 +80,7 @@ You will typically see “[4735](event-4735.md): A security-enabled local group
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “remove member from the group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “remove member from the group” operation.
 
diff --git a/windows/keep-secure/event-4734.md b/windows/keep-secure/event-4734.md
index 023be2969c..120da30815 100644
--- a/windows/keep-secure/event-4734.md
+++ b/windows/keep-secure/event-4734.md
@@ -74,7 +74,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete group” operation.
 
diff --git a/windows/keep-secure/event-4735.md b/windows/keep-secure/event-4735.md
index b6dac600b9..928905449d 100644
--- a/windows/keep-secure/event-4735.md
+++ b/windows/keep-secure/event-4735.md
@@ -84,7 +84,7 @@ From 4735 event you can get information about changes of **sAMAccountName** and
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change group” operation.
 
diff --git a/windows/keep-secure/event-4738.md b/windows/keep-secure/event-4738.md
index 98f22cb17c..f2992c4a97 100644
--- a/windows/keep-secure/event-4738.md
+++ b/windows/keep-secure/event-4738.md
@@ -99,7 +99,7 @@ Some changes do not invoke a 4738 event.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change user account” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change user account” operation.
 
diff --git a/windows/keep-secure/event-4739.md b/windows/keep-secure/event-4739.md
index b5873a99e3..8b692f1ea3 100644
--- a/windows/keep-secure/event-4739.md
+++ b/windows/keep-secure/event-4739.md
@@ -102,7 +102,7 @@ This event generates when one of the following changes was made to local compute
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to specific local policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to specific local policy.
 
diff --git a/windows/keep-secure/event-4740.md b/windows/keep-secure/event-4740.md
index 7ab01449c8..7e35c73f98 100644
--- a/windows/keep-secure/event-4740.md
+++ b/windows/keep-secure/event-4740.md
@@ -73,7 +73,7 @@ For user accounts, this event generates on domain controllers, member servers, a
 
 -   **Security ID** \[Type = SID\]**:** SID of account that performed the lockout operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that performed the lockout operation.
 
diff --git a/windows/keep-secure/event-4741.md b/windows/keep-secure/event-4741.md
index 52d8a70a84..ed9cddfc2c 100644
--- a/windows/keep-secure/event-4741.md
+++ b/windows/keep-secure/event-4741.md
@@ -94,7 +94,7 @@ This event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create Computer object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create Computer object” operation.
 
diff --git a/windows/keep-secure/event-4742.md b/windows/keep-secure/event-4742.md
index b09dba8333..9f318856ed 100644
--- a/windows/keep-secure/event-4742.md
+++ b/windows/keep-secure/event-4742.md
@@ -105,7 +105,7 @@ You might see this event without any changes inside, that is, where all **Change
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change Computer object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change Computer object” operation.
 
diff --git a/windows/keep-secure/event-4743.md b/windows/keep-secure/event-4743.md
index 42f7e90f14..beaa8afbe9 100644
--- a/windows/keep-secure/event-4743.md
+++ b/windows/keep-secure/event-4743.md
@@ -74,7 +74,7 @@ This event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete Computer object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete Computer object” operation.
 
diff --git a/windows/keep-secure/event-4749.md b/windows/keep-secure/event-4749.md
index 321a4a3e52..d2c6a567d6 100644
--- a/windows/keep-secure/event-4749.md
+++ b/windows/keep-secure/event-4749.md
@@ -76,7 +76,7 @@ This event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create group” operation.
 
diff --git a/windows/keep-secure/event-4750.md b/windows/keep-secure/event-4750.md
index 17f5d8eb84..206195ae89 100644
--- a/windows/keep-secure/event-4750.md
+++ b/windows/keep-secure/event-4750.md
@@ -84,7 +84,7 @@ From 4750 event you can get information about changes of **sAMAccountName** and
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change group” operation.
 
diff --git a/windows/keep-secure/event-4751.md b/windows/keep-secure/event-4751.md
index ea37165fce..8f224051a1 100644
--- a/windows/keep-secure/event-4751.md
+++ b/windows/keep-secure/event-4751.md
@@ -80,7 +80,7 @@ You will typically see “[4750](event-4750.md): A security-disabled global grou
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “add member to the group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “add member to the group” operation.
 
diff --git a/windows/keep-secure/event-4752.md b/windows/keep-secure/event-4752.md
index 28d38b44a5..d9ef0f8d52 100644
--- a/windows/keep-secure/event-4752.md
+++ b/windows/keep-secure/event-4752.md
@@ -78,7 +78,7 @@ For every removed member you will get separate 4752 event.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “remove member from the group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “remove member from the group” operation.
 
diff --git a/windows/keep-secure/event-4753.md b/windows/keep-secure/event-4753.md
index 5cc018f286..c8375231e2 100644
--- a/windows/keep-secure/event-4753.md
+++ b/windows/keep-secure/event-4753.md
@@ -74,7 +74,7 @@ This event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete group” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete group” operation.
 
diff --git a/windows/keep-secure/event-4764.md b/windows/keep-secure/event-4764.md
index e5bcc13c9a..3942742122 100644
--- a/windows/keep-secure/event-4764.md
+++ b/windows/keep-secure/event-4764.md
@@ -76,7 +76,7 @@ This event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “change group type” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “change group type” operation.
 
diff --git a/windows/keep-secure/event-4767.md b/windows/keep-secure/event-4767.md
index a189b84db0..7eb768b001 100644
--- a/windows/keep-secure/event-4767.md
+++ b/windows/keep-secure/event-4767.md
@@ -73,7 +73,7 @@ For user accounts, this event generates on domain controllers, member servers, a
 
 -   **Security ID** \[Type = SID\]**:** SID of account that performed the unlock operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that performed the unlock operation.
 
diff --git a/windows/keep-secure/event-4768.md b/windows/keep-secure/event-4768.md
index edcc1952bc..48c81eea57 100644
--- a/windows/keep-secure/event-4768.md
+++ b/windows/keep-secure/event-4768.md
@@ -104,7 +104,7 @@ This event doesn't generate for **Result Codes**: 0x10, 0x17 and 0x18. Event “
 
     -   **NULL SID** – this value shows in [4768](event-4768.md) Failure events.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 **Service Information:**
 
diff --git a/windows/keep-secure/event-4769.md b/windows/keep-secure/event-4769.md
index ecb3b28900..e41de7fd26 100644
--- a/windows/keep-secure/event-4769.md
+++ b/windows/keep-secure/event-4769.md
@@ -112,7 +112,7 @@ You will typically see many Failure events with **Failure Code** “**0x20**”,
 
     -   **NULL SID** – this value shows in Failure events.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 **Network Information:**
 
diff --git a/windows/keep-secure/event-4770.md b/windows/keep-secure/event-4770.md
index 1c353eb67f..65966234c0 100644
--- a/windows/keep-secure/event-4770.md
+++ b/windows/keep-secure/event-4770.md
@@ -98,7 +98,7 @@ This event generates only on domain controllers.
 
 -   **Service ID** \[Type = SID\]**:** SID of the account or computer object for which the TGS ticket was renewed. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 **Network Information:**
 
diff --git a/windows/keep-secure/event-4771.md b/windows/keep-secure/event-4771.md
index ae81985175..233040c8f3 100644
--- a/windows/keep-secure/event-4771.md
+++ b/windows/keep-secure/event-4771.md
@@ -81,7 +81,7 @@ This event is not generated if “Do not require Kerberos preauthentication” o
 
     For example: CONTOSO\\dadmin or CONTOSO\\WIN81$.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name:** \[Type = UnicodeString\]**:** the name of account, for which (TGT) ticket was requested. Computer account name ends with **$** character.
 
diff --git a/windows/keep-secure/event-4781.md b/windows/keep-secure/event-4781.md
index 34064992de..fa151fbb39 100644
--- a/windows/keep-secure/event-4781.md
+++ b/windows/keep-secure/event-4781.md
@@ -77,7 +77,7 @@ For computer accounts, this event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that performed the “change account name” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that performed the “change account name” operation.
 
diff --git a/windows/keep-secure/event-4782.md b/windows/keep-secure/event-4782.md
index 6d0804b3b3..2c04b9ab81 100644
--- a/windows/keep-secure/event-4782.md
+++ b/windows/keep-secure/event-4782.md
@@ -72,7 +72,7 @@ Typically **“Subject\\Security ID”** is the SYSTEM account.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested hash migration operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested hash migration operation.
 
diff --git a/windows/keep-secure/event-4793.md b/windows/keep-secure/event-4793.md
index 079c4317df..ea2cc8090b 100644
--- a/windows/keep-secure/event-4793.md
+++ b/windows/keep-secure/event-4793.md
@@ -79,7 +79,7 @@ Note that starting with Microsoft SQL Server 2005, the “SQL Server password po
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested Password Policy Checking API operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested Password Policy Checking API operation.
 
diff --git a/windows/keep-secure/event-4794.md b/windows/keep-secure/event-4794.md
index c3ce16e165..131254b61b 100644
--- a/windows/keep-secure/event-4794.md
+++ b/windows/keep-secure/event-4794.md
@@ -72,7 +72,7 @@ This event generates only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to set Directory Services Restore Mode administrator password. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to set Directory Services Restore Mode administrator password.
 
diff --git a/windows/keep-secure/event-4798.md b/windows/keep-secure/event-4798.md
index 3423f5319b..3d3ddee0ce 100644
--- a/windows/keep-secure/event-4798.md
+++ b/windows/keep-secure/event-4798.md
@@ -73,7 +73,7 @@ This event generates when a process enumerates a user's security-enabled local g
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “enumerate user's security-enabled local groups” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “enumerate user's security-enabled local groups” operation.
 
diff --git a/windows/keep-secure/event-4799.md b/windows/keep-secure/event-4799.md
index 2084212f59..686f00f99f 100644
--- a/windows/keep-secure/event-4799.md
+++ b/windows/keep-secure/event-4799.md
@@ -75,7 +75,7 @@ This event doesn't generate when group members were enumerated using Active Dire
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “enumerate security-enabled local group members” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “enumerate security-enabled local group members” operation.
 
diff --git a/windows/keep-secure/event-4800.md b/windows/keep-secure/event-4800.md
index 3eb3482649..30cddc53d4 100644
--- a/windows/keep-secure/event-4800.md
+++ b/windows/keep-secure/event-4800.md
@@ -69,7 +69,7 @@ This event is generated when a workstation was locked.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “lock workstation” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “lock workstation” operation.
 
diff --git a/windows/keep-secure/event-4801.md b/windows/keep-secure/event-4801.md
index b0b69a6e24..274fd1ba5c 100644
--- a/windows/keep-secure/event-4801.md
+++ b/windows/keep-secure/event-4801.md
@@ -69,7 +69,7 @@ This event is generated when workstation was unlocked.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “unlock workstation” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “unlock workstation” operation.
 
diff --git a/windows/keep-secure/event-4802.md b/windows/keep-secure/event-4802.md
index 691f558b08..ebce359a9c 100644
--- a/windows/keep-secure/event-4802.md
+++ b/windows/keep-secure/event-4802.md
@@ -69,7 +69,7 @@ This event is generated when screen saver was invoked.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “invoke screensaver” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “invoke screensaver” operation.
 
diff --git a/windows/keep-secure/event-4803.md b/windows/keep-secure/event-4803.md
index 8cfb6407c8..62ffc7f753 100644
--- a/windows/keep-secure/event-4803.md
+++ b/windows/keep-secure/event-4803.md
@@ -69,7 +69,7 @@ This event is generated when screen saver was dismissed.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “dismiss screensaver” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “dismiss screensaver” operation.
 
diff --git a/windows/keep-secure/event-4817.md b/windows/keep-secure/event-4817.md
index c1bc5e42d5..7980c341af 100644
--- a/windows/keep-secure/event-4817.md
+++ b/windows/keep-secure/event-4817.md
@@ -75,7 +75,7 @@ Separate events will be generated for “Registry” and “File system” polic
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to Global Object Access Auditing policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to Global Object Access Auditing policy.
 
diff --git a/windows/keep-secure/event-4818.md b/windows/keep-secure/event-4818.md
index f219c35d82..aad25bb594 100644
--- a/windows/keep-secure/event-4818.md
+++ b/windows/keep-secure/event-4818.md
@@ -76,7 +76,7 @@ This event generates when Dynamic Access Control Proposed [Central Access Policy
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an access request. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an access request.
 
diff --git a/windows/keep-secure/event-4819.md b/windows/keep-secure/event-4819.md
index b9311464ea..5ef9d2b4dc 100644
--- a/windows/keep-secure/event-4819.md
+++ b/windows/keep-secure/event-4819.md
@@ -76,7 +76,7 @@ For example, it generates when a new [Central Access Policy](https://technet.mic
 
 -   **Security ID** \[Type = SID\]**:** SID of account that changed the Central Access Policies on the machine. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that changed the Central Access Policies on the machine.
 
diff --git a/windows/keep-secure/event-4826.md b/windows/keep-secure/event-4826.md
index fd9ab17f16..989ba1f6e1 100644
--- a/windows/keep-secure/event-4826.md
+++ b/windows/keep-secure/event-4826.md
@@ -82,7 +82,7 @@ This event is always logged regardless of the "Audit Other Policy Change Events"
 
 -   **Security ID** \[Type = SID\]**:** SID of account that reported this event. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event. Always “S-1-5-18” for this event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that reported this event. Always “-“ for this event.
 
diff --git a/windows/keep-secure/event-4865.md b/windows/keep-secure/event-4865.md
index 90f686c80b..fc96c3a543 100644
--- a/windows/keep-secure/event-4865.md
+++ b/windows/keep-secure/event-4865.md
@@ -79,7 +79,7 @@ This event is generated only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “add a trusted forest information entry” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “add a trusted forest information entry” operation.
 
diff --git a/windows/keep-secure/event-4866.md b/windows/keep-secure/event-4866.md
index 1fc701f4d1..45e828eb01 100644
--- a/windows/keep-secure/event-4866.md
+++ b/windows/keep-secure/event-4866.md
@@ -79,7 +79,7 @@ This event is generated only on domain controllers.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “remove a trusted forest information entry” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “remove a trusted forest information entry” operation.
 
diff --git a/windows/keep-secure/event-4867.md b/windows/keep-secure/event-4867.md
index 57fc10f7da..376f18a47f 100644
--- a/windows/keep-secure/event-4867.md
+++ b/windows/keep-secure/event-4867.md
@@ -81,7 +81,7 @@ This event contains new values only, it doesn’t contains old values and it doe
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “modify/change a trusted forest information entry” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify/change a trusted forest information entry” operation.
 
diff --git a/windows/keep-secure/event-4904.md b/windows/keep-secure/event-4904.md
index 85d903d952..a3d21b731a 100644
--- a/windows/keep-secure/event-4904.md
+++ b/windows/keep-secure/event-4904.md
@@ -74,7 +74,7 @@ You can typically see this event during system startup, if specific roles (Inter
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to register a security event source. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to register a security event source.
 
diff --git a/windows/keep-secure/event-4905.md b/windows/keep-secure/event-4905.md
index 1bc58fabcc..0cb79afd08 100644
--- a/windows/keep-secure/event-4905.md
+++ b/windows/keep-secure/event-4905.md
@@ -74,7 +74,7 @@ You typically see this event if specific roles were removed, for example, Intern
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made an attempt to unregister a security event source. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made an attempt to unregister a security event source.
 
diff --git a/windows/keep-secure/event-4907.md b/windows/keep-secure/event-4907.md
index 0867cad21e..a7c610e28a 100644
--- a/windows/keep-secure/event-4907.md
+++ b/windows/keep-secure/event-4907.md
@@ -78,7 +78,7 @@ This event doesn't generate for Active Directory objects.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to object’s auditing settings. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to object’s auditing settings.
 
diff --git a/windows/keep-secure/event-4908.md b/windows/keep-secure/event-4908.md
index c76f86b814..dfe71ca9a8 100644
--- a/windows/keep-secure/event-4908.md
+++ b/windows/keep-secure/event-4908.md
@@ -73,7 +73,7 @@ More information about Special Groups auditing can be found here:
 
 **Special Groups** \[Type = UnicodeString\]**:** contains current list of SIDs (groups or accounts) which are members of Special Groups. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 “HKEY\_LOCAL\_MACHINE\\SYSTEM\\ControlSet001\\Control\\Lsa\\Audit\\SpecialGroups” registry value contains current list of SIDs which are included in Special Groups:
 
diff --git a/windows/keep-secure/event-4911.md b/windows/keep-secure/event-4911.md
index 20a174c857..173c322a13 100644
--- a/windows/keep-secure/event-4911.md
+++ b/windows/keep-secure/event-4911.md
@@ -78,7 +78,7 @@ Resource attributes for file or folder can be changed, for example, using Window
 
 -   **Security ID** \[Type = SID\]**:** SID of account that changed the resource attributes of the file system object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that changed the resource attributes of the file system object.
 
diff --git a/windows/keep-secure/event-4912.md b/windows/keep-secure/event-4912.md
index bc9856672a..269bdcd27d 100644
--- a/windows/keep-secure/event-4912.md
+++ b/windows/keep-secure/event-4912.md
@@ -75,7 +75,7 @@ This event is always logged regardless of the "Audit Policy Change" sub-category
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made a change to per-user audit policy. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made a change to per-user audit policy.
 
diff --git a/windows/keep-secure/event-4913.md b/windows/keep-secure/event-4913.md
index 96a27d5f9f..bab7781b60 100644
--- a/windows/keep-secure/event-4913.md
+++ b/windows/keep-secure/event-4913.md
@@ -78,7 +78,7 @@ This event always generates, regardless of the object’s [SACL](https://msdn.mi
 
 -   **Security ID** \[Type = SID\]**:** SID of account that changed the Central Access Policy on the object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that changed the Central Access Policy on the object.
 
diff --git a/windows/keep-secure/event-4964.md b/windows/keep-secure/event-4964.md
index 96d32ccc21..6c989c94e3 100644
--- a/windows/keep-secure/event-4964.md
+++ b/windows/keep-secure/event-4964.md
@@ -97,7 +97,7 @@ This event occurs when an account that is a member of any defined [Special Group
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested logon for **New Logon** account. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested logon for **New Logon** account.
 
diff --git a/windows/keep-secure/event-4985.md b/windows/keep-secure/event-4985.md
index f9737372fc..914a8b1dfe 100644
--- a/windows/keep-secure/event-4985.md
+++ b/windows/keep-secure/event-4985.md
@@ -73,7 +73,7 @@ This is an informational event from file system [Transaction Manager](https://ms
 
 -   **Security ID** \[Type = SID\]**:** SID of account through which the state of the transaction was changed. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that changed the state of the transaction.
 
diff --git a/windows/keep-secure/event-5058.md b/windows/keep-secure/event-5058.md
index b8b0f16ef4..0f645ddfd2 100644
--- a/windows/keep-secure/event-5058.md
+++ b/windows/keep-secure/event-5058.md
@@ -81,7 +81,7 @@ You can see these events, for example, during certificate renewal or export oper
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested key file operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested key file operation.
 
diff --git a/windows/keep-secure/event-5059.md b/windows/keep-secure/event-5059.md
index 3a1b397f62..f07301148a 100644
--- a/windows/keep-secure/event-5059.md
+++ b/windows/keep-secure/event-5059.md
@@ -78,7 +78,7 @@ This event generates when a cryptographic key is exported or imported using a [K
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested key migration operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested key migration operation.
 
diff --git a/windows/keep-secure/event-5061.md b/windows/keep-secure/event-5061.md
index 886a4d7aba..47baeb41ab 100644
--- a/windows/keep-secure/event-5061.md
+++ b/windows/keep-secure/event-5061.md
@@ -78,7 +78,7 @@ This event generates when a cryptographic operation (open key, create key, creat
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested specific cryptographic operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested specific cryptographic operation.
 
diff --git a/windows/keep-secure/event-5136.md b/windows/keep-secure/event-5136.md
index 3350dca361..7ff77e2c64 100644
--- a/windows/keep-secure/event-5136.md
+++ b/windows/keep-secure/event-5136.md
@@ -83,7 +83,7 @@ For a change operation you will typically see two 5136 events for one action, wi
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “modify object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify object” operation.
 
diff --git a/windows/keep-secure/event-5137.md b/windows/keep-secure/event-5137.md
index 892245d530..6811c8a0cf 100644
--- a/windows/keep-secure/event-5137.md
+++ b/windows/keep-secure/event-5137.md
@@ -77,7 +77,7 @@ This event only generates if the parent object has a particular entry in its [SA
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “create object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “create object” operation.
 
diff --git a/windows/keep-secure/event-5138.md b/windows/keep-secure/event-5138.md
index 84e80ff027..74f1c3211e 100644
--- a/windows/keep-secure/event-5138.md
+++ b/windows/keep-secure/event-5138.md
@@ -78,7 +78,7 @@ This event only generates if the container to which the Active Directory object
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested that the object be undeleted or restored. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** name of account that requested that the object be undeleted or restored.
 
diff --git a/windows/keep-secure/event-5139.md b/windows/keep-secure/event-5139.md
index 7399a33b15..e596740636 100644
--- a/windows/keep-secure/event-5139.md
+++ b/windows/keep-secure/event-5139.md
@@ -78,7 +78,7 @@ This event only generates if the destination object has a particular entry in it
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “move object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “move object” operation.
 
diff --git a/windows/keep-secure/event-5140.md b/windows/keep-secure/event-5140.md
index be40b7a2d5..44b1805626 100644
--- a/windows/keep-secure/event-5140.md
+++ b/windows/keep-secure/event-5140.md
@@ -79,7 +79,7 @@ This event generates once per session, when first access attempt was made.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested access to network share object.
 
diff --git a/windows/keep-secure/event-5141.md b/windows/keep-secure/event-5141.md
index 238b70281d..6ead5872b1 100644
--- a/windows/keep-secure/event-5141.md
+++ b/windows/keep-secure/event-5141.md
@@ -78,7 +78,7 @@ This event only generates if the deleted object has a particular entry in its [S
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete object” operation.
 
diff --git a/windows/keep-secure/event-5142.md b/windows/keep-secure/event-5142.md
index 418a6387f7..b9b90bbcae 100644
--- a/windows/keep-secure/event-5142.md
+++ b/windows/keep-secure/event-5142.md
@@ -70,7 +70,7 @@ This event generates every time network share object was added.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “add network share object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “add network share object” operation.
 
diff --git a/windows/keep-secure/event-5143.md b/windows/keep-secure/event-5143.md
index 30c4977b0c..1ed2dbad97 100644
--- a/windows/keep-secure/event-5143.md
+++ b/windows/keep-secure/event-5143.md
@@ -79,7 +79,7 @@ This event generates every time network share object was modified.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “modify network share object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify network share object” operation.
 
diff --git a/windows/keep-secure/event-5144.md b/windows/keep-secure/event-5144.md
index d74e6e0c0e..ae5d2876a3 100644
--- a/windows/keep-secure/event-5144.md
+++ b/windows/keep-secure/event-5144.md
@@ -70,7 +70,7 @@ This event generates every time a network share object is deleted.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete network share object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete network share object” operation.
 
diff --git a/windows/keep-secure/event-5145.md b/windows/keep-secure/event-5145.md
index 1370cc6fe1..5982d03bce 100644
--- a/windows/keep-secure/event-5145.md
+++ b/windows/keep-secure/event-5145.md
@@ -79,7 +79,7 @@ This event generates every time network share object (file or folder) was access
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested access to network share object. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested access to network share object.
 
diff --git a/windows/keep-secure/event-5168.md b/windows/keep-secure/event-5168.md
index 44c9fe20cc..dd270b6b5f 100644
--- a/windows/keep-secure/event-5168.md
+++ b/windows/keep-secure/event-5168.md
@@ -75,7 +75,7 @@ It often happens because of NTLMv1 or LM protocols usage from client side when 
 
 -   **Security ID** \[Type = SID\]**:** SID of account for which SPN check operation was failed. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account for which SPN check operation was failed.
 
diff --git a/windows/keep-secure/event-5376.md b/windows/keep-secure/event-5376.md
index 16034db84c..0b315361cf 100644
--- a/windows/keep-secure/event-5376.md
+++ b/windows/keep-secure/event-5376.md
@@ -72,7 +72,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that performed the backup operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that performed the backup operation.
 
diff --git a/windows/keep-secure/event-5377.md b/windows/keep-secure/event-5377.md
index c50b35c2f4..48cda08bc0 100644
--- a/windows/keep-secure/event-5377.md
+++ b/windows/keep-secure/event-5377.md
@@ -72,7 +72,7 @@ This event generates on domain controllers, member servers, and workstations.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that performed the restore operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that performed the restore operation.
 
diff --git a/windows/keep-secure/event-5378.md b/windows/keep-secure/event-5378.md
index 066229425a..ed01eb2676 100644
--- a/windows/keep-secure/event-5378.md
+++ b/windows/keep-secure/event-5378.md
@@ -74,7 +74,7 @@ It typically occurs when [CredSSP](https://msdn.microsoft.com/en-us/library/cc22
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested credentials delegation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested credentials delegation.
 
diff --git a/windows/keep-secure/event-5888.md b/windows/keep-secure/event-5888.md
index 4e35780a9c..cb5a4a5432 100644
--- a/windows/keep-secure/event-5888.md
+++ b/windows/keep-secure/event-5888.md
@@ -73,7 +73,7 @@ For some reason this event belongs to [Audit System Integrity](event-5890.md) su
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “modify/change object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “modify/change object” operation.
 
diff --git a/windows/keep-secure/event-5889.md b/windows/keep-secure/event-5889.md
index 7e24a156f3..a49c9b83d0 100644
--- a/windows/keep-secure/event-5889.md
+++ b/windows/keep-secure/event-5889.md
@@ -73,7 +73,7 @@ For some reason this event belongs to [Audit System Integrity](event-5890.md) su
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “delete object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “delete object” operation.
 
diff --git a/windows/keep-secure/event-5890.md b/windows/keep-secure/event-5890.md
index 896689a521..3618c15b54 100644
--- a/windows/keep-secure/event-5890.md
+++ b/windows/keep-secure/event-5890.md
@@ -73,7 +73,7 @@ For some reason this event belongs to [Audit System Integrity](event-5890.md) su
 
 -   **Security ID** \[Type = SID\]**:** SID of account that requested the “add object” operation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that requested the “add object” operation.
 
diff --git a/windows/keep-secure/event-6416.md b/windows/keep-secure/event-6416.md
index 9f93d86eb0..3b770a8e88 100644
--- a/windows/keep-secure/event-6416.md
+++ b/windows/keep-secure/event-6416.md
@@ -87,7 +87,7 @@ This event generates, for example, when a new external device is connected or en
 
 -   **Security ID** \[Type = SID\]**:** SID of account that registered the new device. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that registered the new device.
 
diff --git a/windows/keep-secure/event-6419.md b/windows/keep-secure/event-6419.md
index b874b2ea54..9dffec1741 100644
--- a/windows/keep-secure/event-6419.md
+++ b/windows/keep-secure/event-6419.md
@@ -77,7 +77,7 @@ This event doesn’t mean that device was disabled.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made the request. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made the request.
 
diff --git a/windows/keep-secure/event-6420.md b/windows/keep-secure/event-6420.md
index ec339814ea..0ff9a1dab6 100644
--- a/windows/keep-secure/event-6420.md
+++ b/windows/keep-secure/event-6420.md
@@ -75,7 +75,7 @@ This event generates every time specific device was disabled.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that disabled the device. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that disabled the device.
 
diff --git a/windows/keep-secure/event-6421.md b/windows/keep-secure/event-6421.md
index ea9ce9c6a5..cf2110f150 100644
--- a/windows/keep-secure/event-6421.md
+++ b/windows/keep-secure/event-6421.md
@@ -77,7 +77,7 @@ This event doesn’t mean that device was enabled.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that made the request. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that made the request.
 
diff --git a/windows/keep-secure/event-6422.md b/windows/keep-secure/event-6422.md
index fb59fad3bf..c0eec81d34 100644
--- a/windows/keep-secure/event-6422.md
+++ b/windows/keep-secure/event-6422.md
@@ -75,7 +75,7 @@ This event generates every time specific device was enabled.
 
 -   **Security ID** \[Type = SID\]**:** SID of account that enabled the device. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that enabled the device.
 
diff --git a/windows/keep-secure/event-6423.md b/windows/keep-secure/event-6423.md
index 09e75dc4cd..0e43d751c3 100644
--- a/windows/keep-secure/event-6423.md
+++ b/windows/keep-secure/event-6423.md
@@ -77,7 +77,7 @@ Device installation restriction group policies are located here: **\\Computer Co
 
 -   **Security ID** \[Type = SID\]**:** SID of account that forbids the device installation. Event Viewer automatically tries to resolve SIDs and show the account name. If the SID cannot be resolved, you will see the source data in the event.
 
-> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security Identifiers](https://msdn.microsoft.com/en-us/library/windows/desktop/aa379571(v=vs.85).aspx).
+> **Note**&nbsp;&nbsp;A **security identifier (SID)** is a unique value of variable length used to identify a trustee (security principal). Each account has a unique SID that is issued by an authority, such as an Active Directory domain controller, and stored in a security database. Each time a user logs on, the system retrieves the SID for that user from the database and places it in the access token for that user. The system uses the SID in the access token to identify the user in all subsequent interactions with Windows security. When a SID has been used as the unique identifier for a user or group, it cannot ever be used again to identify another user or group. For more information about SIDs, see [Security identifiers](security-identifiers.md).
 
 -   **Account Name** \[Type = UnicodeString\]**:** the name of the account that forbids the device installation.
 
diff --git a/windows/keep-secure/event-error-codes-windows-defender-advanced-threat-protection.md b/windows/keep-secure/event-error-codes-windows-defender-advanced-threat-protection.md
index 6e239a2aea..f019d14fdf 100644
--- a/windows/keep-secure/event-error-codes-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/event-error-codes-windows-defender-advanced-threat-protection.md
@@ -242,9 +242,6 @@ See [Configure Windows Defender ATP endpoints](configure-endpoints-windows-defen
 
 
 ## Related topics
-<!--- [Windows Defender ATP service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md)-->
 - [Configure Windows Defender ATP endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md)
 - [Configure endpoint proxy and Internet connectivity settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md)
-- [Additional Windows Defender ATP configuration settings](additional-configuration-windows-defender-advanced-threat-protection.md)
-- [Monitor the Windows Defender ATP onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md)
 - [Troubleshoot Windows Defender ATP](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
diff --git a/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md b/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md
index 9f8709dce5..1a19780713 100644
--- a/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md
+++ b/windows/keep-secure/get-started-with-windows-defender-for-windows-10.md
@@ -110,8 +110,8 @@ You can also enable email scanning using the following PowerShell parameter:
 2.  Type **Set-MpPreference -DisableEmailScanning $false**.
 
 Read more about this in:
--   • [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
--   • [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
+-   [Scripting with Windows PowerShell](https://technet.microsoft.com/library/bb978526.aspx)
+-   [Defender Cmdlets](https://technet.microsoft.com/library/dn433280.aspx)
 
 ## Manage archive scans in Windows Defender
 
diff --git a/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md b/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md
index 42e7d1cff1..542e85c56f 100644
--- a/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md
+++ b/windows/keep-secure/getting-apps-to-run-on-device-guard-protected-devices.md
@@ -1,256 +1,4 @@
 ---
 title: Get apps to run on Device Guard-protected devices (Windows 10)
-description: Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard.
-ms.assetid: E62B68C3-8B9F-4842-90FC-B4EE9FF8A67E
-keywords: Package Inspector, packageinspector.exe, sign catalog file
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.sitesec: library
-ms.pagetype: security
-author: brianlic-msft
+redirect_url: device-guard-deployment-guide.md
 ---
-
-# Get apps to run on Device Guard-protected devices
-
-**Applies to**
--   Windows 10
-
-Windows 10 introduces several new features and settings that when combined all equal what we're calling, Device Guard. Device Guard can help to protect your enterprise devices against the accidental running of malicious apps by requiring all of your apps to be signed by a trusted entity.
-
-To use Device Guard in an enterprise, you must be able to get your existing line-of-business and Independent Software Vendor (ISV)-developed apps to run on a protected device. Unfortunately, many line-of-business apps aren't signed, and in many cases, aren't even being actively developed. Similarly, you may have unsigned software from an ISV that you want to run, or you want to run certain applications from an ISV while not trusting all applications from that ISV. As part of the Device Guard features, Windows 10 includes a new tool called Package Inspector. Package Inspector scans your unsigned apps, and creates catalog files of the installed and running binaries, which can then be signed by the Sign Tool Windows SDK utility and distributed using Group Policy so that your apps will run on Device Guard-protected devices.
-
-## What you need to run your apps on Device-Guard protected devices
-
-Before you can get your apps to run on Device Guard-protected devices, you must have:
-
--   A device running Windows 10 Enterprise, Windows 10 Education, or Windows Server 2016 Technical Preview.
--   Determined which unsigned apps you need to include in your catalog file.
--   Created a code integrity policy for use by Device Guard.
--   A [code signing certificate](http://go.microsoft.com/fwlink/p/?LinkId=619282), created using an internal public key infrastructure (PKI).
--   [SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283). A command-line tool that digitally signs files, verifies signatures in files, or time stamps files. The tool is installed in the \\Bin folder of the Microsoft Windows Software Development Kit (SDK) installation path.
-
-## Create a catalog file for unsigned apps
-
-You must run Package Inspector on a device that's running a temporary Code Integrity Policy in audit mode, created explicitly for this purpose. Audit mode lets this policy catch any binaries missed by the inspection tool, but because it's audit mode, allows everything to continue running.
-> **Important:**  This temporary policy, shouldn't be used for normal business purposes.
- 
-**To create a catalog file for an existing app**
-1.  Start PowerShell as an administrator, and create your temporary policy file by typing:
-    ``` syntax
-    mkdir temp
-    New-CIPolicy -l FileName -f .\tempdeny.xml -s .\temp -u
-    ConvertFrom-CIPolicy .\tempdeny.xml .\tempdeny.bin
-    cp .\tempdeny.bin C:\Windows\System32\CodeIntegrity\SIPolicy.p7b
-    ```
-2.  Restart your device.
-3.  Start PowerShell as an administrator, and start scanning your file system by typing:
-    ``` syntax
-    PackageInspector.exe start c:
-    ```
-    Where:
-    <table>
-    <colgroup>
-    <col width="50%" />
-    <col width="50%" />
-    </colgroup>
-    <thead>
-    <tr class="header">
-    <th align="left">Option</th>
-    <th align="left">Description</th>
-    </tr>
-    </thead>
-    <tbody>
-    <tr class="odd">
-    <td align="left"><p>start &lt;<em>drive_letter</em>&gt;:</p></td>
-    <td align="left"><p>Specifies to start a scan. For example, starting to scan the C: drive.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>-path</p></td>
-    <td align="left"><p>File path to the package being inspected.</p></td>
-    </tr>
-    </tbody>
-    </table>
-     
-4.  Copy the app installation media to your C:\\ drive, and then install and run the program.
-
-    Copying the media to your local drive helps to make sure that the installer and its related files are included in your catalog file. If you miss the install files, your Code Integrity Policy might trust the app to run, but not to install. After you've installed the app, you should check for updates. If updates happen while the app is open, you should close and restart the app to make sure everything is caught during the inspection process.
-    
-    > **Note:**  Because the Package Inspector creates a log entry in the catalog for every binary laid down on the file system, we recommend that you don't run any other installations or updates during the scanning process.
-     
-5.  **Optional:** If you want to create a multi-app catalog (many apps included in a single catalog file), you can continue to run Steps 2-3 for each additional app. After you've added all of the apps you want to add, you can continue to Step 5.
-    > **Note: **  To streamline your process, we suggest:
-    -   **Actively supported and updated apps.** Create a single catalog file for each app.
-    -   **Legacy apps, non-active or not updated.** Create a single catalog file for all of your legacy apps.
-     
-6.  Stop the scanning process and create the .\\InspectedPackage.cat and InspectedPackage.cdf files for your single app in your specified location, by typing:
-    ``` syntax
-    PackageInspector.exe stop c:
-    ```
-You can also use the `scan` command in place of using both `start` and `stop` if you want to create a catalog of files that are already present on your hard drive. The `scan` command recursively scans a specified directory and includes all signable files in the catalog. You can scan a specified directory by typing:
-``` syntax
-PackageInspector.exe scan c:\<insert directory path>
-```
-The following table shows the available options for both the `scan` and `stop` commands.
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">Option</th>
-<th align="left">Description</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><p>stop &lt;<em>drive_letter</em>&gt;:</p></td>
-<td align="left"><p>Specifies that a scan of the specified location is complete, creating either a catalog or a definition file. For example, <em>C:</em></p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>scan <em>&lt;path to scan&gt;</em></p></td>
-<td align="left"><p>Specifies a directory path to scan. This command recursively scans a specified directory and includes all signable files in the catalog.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>-out</p></td>
-<td align="left"><p>Specifies what type of info should be created by the tool. You can use either <code>CAT</code> for a catalog file, <code>CDF</code> for a catalog definition file or <code>list</code> for a delimited list of files.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>-listpath</p></td>
-<td align="left"><p>Specifies the location where the installer will output the list of files for <code>-out list</code>.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>-cdfPath &lt;<em>file_name</em>&gt;</p></td>
-<td align="left"><p>Specifies where the tool should put the created .cdf file. If you use this option, you must also specify the file name.</p>
-<p>We recommend that you use the full path to the file. However, relative paths are supported.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>-resdir</p></td>
-<td align="left"><p>This option isn't currently supported.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>-name</p></td>
-<td align="left"><p>This option isn't currently supported.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>-ph <code>[true|false]</code></p></td>
-<td align="left"><p>Specifies whether to include page hashes in the catalog. You can use either <code>True</code> to add the hashes or <code>False</code> to not add the hashes.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>-en</p></td>
-<td align="left"><p>Specifies the catalog's encoding type. By default, it's PKCS_7_ASN_ENCODING | X509_ASN_ENCODING, 0x00010001.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>-ca1</p></td>
-<td align="left"><p>Specifies the CATATTR1 in the catalog and catalog definition files.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>-ca2</p></td>
-<td align="left"><p>Specifies the CATATTR2 in the catalog and catalog definition files.</p></td>
-</tr>
-</tbody>
-</table>
- 
-You can add additional parameters to your catalog beyond what's listed here. For more info, see the [MakeCat](http://go.microsoft.com/fwlink/p/?LinkId=618024) topic.
-
-## Sign your catalog file using Sign Tool
-
-You can sign your catalog file using Sign Tool, located in the Windows 7 or later Windows Software Development Kit (SDK) or by using the Device Guard signing portal. For details on using the Device Guard signing portal, see [Device Guard signing](http://go.microsoft.com/fwlink/p/?LinkID=698760).
-This process shows how to use a password-protected Personal Information Exchange (.pfx) file to sign the catalog file.
-
-> **Important:**  To use this tool, you must have an internal certificate authority code signing certificate, or a code signing certificate issued by an external third-party certificate authority.
- 
-**To use Sign Tool**
-
-1.  Check that your code signing certificates have been imported into your certificate store or that they're on the file system.
-2.  Open SignTool.exe and sign the catalog file, based on where your certificate is stored.
-    If you are using the PFX from a file system location:
-    ``` syntax
-    signtool sign /f <\\SignCertLocation> /p <\\password> /fd sha256 /v
-    ```
-    If you have imported the certificate into your cert store:
-    ``` syntax
-    signtool sign /n <\\CertSubjectName> /fd sha256 /v <CatalogNameAndLocation>
-    ```
-    Where:
-    <table>
-    <colgroup>
-    <col width="50%" />
-    <col width="50%" />
-    </colgroup>
-    <thead>
-    <tr class="header">
-    <th align="left">Option</th>
-    <th align="left">Description</th>
-    </tr>
-    </thead>
-    <tbody>
-    <tr class="odd">
-    <td align="left"><p>signtool</p></td>
-    <td align="left"><p>Specifies the full path location to SignTool.exe.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>sign</p></td>
-    <td align="left"><p>Digitally signs files. For a list of the options supported by the sign command, see the [SignTool options](http://go.microsoft.com/fwlink/p/?LinkId=619283).</p></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>/n <em>SubjectName</em></p></td>
-    <td align="left"><p>Specifies the name of the subject of the signing certificate. This value can be a substring of the entire subject name.</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>/f <em>SignCertFileLocation</em></p></td>
-    <td align="left"><p>Specifies the signing certificate in a file.</p>
-    <p>If the file is in .pfx format and protected by a password, use the /p option to specify the password. If the file does not contain private keys, use the /csp and /k options to specify the .csp and private key container name.</p></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>/p <em>Password</em></p></td>
-    <td align="left"><p>Specifies the password to use when opening a PFX file. (Use the /f option to specify a PFX file.)</p></td>
-    </tr>
-    <tr class="even">
-    <td align="left"><p>/fd <em>Algorithm</em></p></td>
-    <td align="left"><p>Specifies the file digest algorithm to use for creating file signatures. The default is SHA2.</p></td>
-    </tr>
-    <tr class="odd">
-    <td align="left"><p>/v</p></td>
-    <td align="left"><p>Displays verbose output regardless of whether the command runs successfully or fails, and displays warning messages.</p></td>
-    </tr>
-    </tbody>
-    </table>
-     
-    For more detailed info and examples using the available options, see the [SignTool.exe (Sign Tool)](http://go.microsoft.com/fwlink/p/?LinkId=618026) topic.
-    
-3.  In File Explorer, right-click your catalog file, click **Properties**, and then click the **Digital Signatures** tab to make sure your catalog file's digital signature is accurate.
-4.  Copy your catalog file to C:\\Windows\\System32\\catroot\\{F750E6C3-38EE-11D1-85E5-00C04FC295EE} and test the file.
-
-    >**Note:**  For testing purposes, you can manually copy your file to this location. However, we recommend that you use Group Policy to copy the catalog file to all of your devices for large-scale implementations.
-    
-## Troubleshooting the Package Inspector
-
-If you see "Error 1181" while stopping the Package Inspector, you'll need to increase your USN journal size and then clear all of the cached data before re-scanning the impacted apps.
-
-You must make sure that you clear the cache by creating and setting a new temporary policy. If you reuse the same policy, the Package Inspector will fail.
-
-**To increase your journal size**
-1.  Open a command-prompt window, and then type:
-    ``` syntax
-    fsutil usn createjournal m=0x8000000 a=0x800000 C:
-    ```
-    Where the "m" value needs to be increased. We recommend that you change the value to at least 4 times the default value of m=0x2000000.
-2.  Re-run the failed app installation(s).
-
-**To clear your cached data and re-scan your apps**
-
-1.  Delete the SIPolicy.p7b file from the C:\\Windows\\System32\\CodeIntegrity\\ folder.
-2.  Create a new temporary Code Integrity Policy to clear all of the cached data by starting Windows Powershell as an administrator and typing:
-    ``` syntax
-    mkdir temp
-    cp C:\Windows\System32\PackageInspector.exe .\temp\
-    New-CIPolicy -l Hash -f .\DenyPackageInspector.xml -s .\temp -u -deny
-    ConvertFrom-CIPolicy .\DenyPackageInspector.xml .\DenyPackageInspector.bin
-    cp .\DenyPackageInspector.bin C:\Windows\System32\SIPolicy.p7b
-    ```
-3.  Restart your device and follow the steps in the [Create a catalog file for unsigned apps](#create-a-catalog-file-for-unsigned-apps) section.
-
-## Related topics
-
-[Download SignTool]( http://go.microsoft.com/fwlink/p/?LinkId=619283)
diff --git a/windows/keep-secure/guidance-and-best-practices-edp.md b/windows/keep-secure/guidance-and-best-practices-edp.md
index 805ac84dfc..fd1ffe2dcd 100644
--- a/windows/keep-secure/guidance-and-best-practices-edp.md
+++ b/windows/keep-secure/guidance-and-best-practices-edp.md
@@ -23,6 +23,7 @@ This section includes info about the enlightened Microsoft apps, including how t
 ## In this section
 |Topic |Description |
 |------|------------|
+|[Mandatory settings for Windows Information Protection (WIP)](mandatory-settings-for-wip.md) |A list of all of the tasks and settings that are required for the operating system to turn on Windows Information Protection (WIP), formerly known as enterprise data protection (EDP), in your enterprise. |
 |[Enlightened apps for use with enterprise data protection (EDP)](enlightened-microsoft-apps-and-edp.md) |Learn the difference between enlightened and unenlightened apps, and then review the list of enlightened apps provided by Microsoft along with the text you will need to use to add them to your **Protected Apps** list. |
 |[Testing scenarios for enterprise data protection (EDP)](testing-scenarios-for-edp.md) |We've come up with a list of suggested testing scenarios that you can use to test EDP in your company. |
 
diff --git a/windows/keep-secure/images/adlocalaccounts-proc1-sample1.gif b/windows/keep-secure/images/adlocalaccounts-proc1-sample1.gif
new file mode 100644
index 0000000000..fb60cd5599
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc1-sample1.gif differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc1-sample2.png b/windows/keep-secure/images/adlocalaccounts-proc1-sample2.png
new file mode 100644
index 0000000000..93e5e8e098
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc1-sample2.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc1-sample3.png b/windows/keep-secure/images/adlocalaccounts-proc1-sample3.png
new file mode 100644
index 0000000000..7aad6b6a7b
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc1-sample3.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc1-sample4.png b/windows/keep-secure/images/adlocalaccounts-proc1-sample4.png
new file mode 100644
index 0000000000..2b6c1394b9
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc1-sample4.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc1-sample5.png b/windows/keep-secure/images/adlocalaccounts-proc1-sample5.png
new file mode 100644
index 0000000000..65508e5cf4
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc1-sample5.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc1-sample6.png b/windows/keep-secure/images/adlocalaccounts-proc1-sample6.png
new file mode 100644
index 0000000000..4653a66f29
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc1-sample6.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc1-sample7.png b/windows/keep-secure/images/adlocalaccounts-proc1-sample7.png
new file mode 100644
index 0000000000..b4e379a357
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc1-sample7.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc2-sample1.png b/windows/keep-secure/images/adlocalaccounts-proc2-sample1.png
new file mode 100644
index 0000000000..c725fd4f55
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc2-sample1.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc2-sample2.png b/windows/keep-secure/images/adlocalaccounts-proc2-sample2.png
new file mode 100644
index 0000000000..999303a2d6
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc2-sample2.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc2-sample3.png b/windows/keep-secure/images/adlocalaccounts-proc2-sample3.png
new file mode 100644
index 0000000000..b80fc69397
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc2-sample3.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc2-sample4.png b/windows/keep-secure/images/adlocalaccounts-proc2-sample4.png
new file mode 100644
index 0000000000..412f425ccf
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc2-sample4.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc2-sample5.png b/windows/keep-secure/images/adlocalaccounts-proc2-sample5.png
new file mode 100644
index 0000000000..b80fc69397
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc2-sample5.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc2-sample6.png b/windows/keep-secure/images/adlocalaccounts-proc2-sample6.png
new file mode 100644
index 0000000000..b2f6d3e1e2
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc2-sample6.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc2-sample7.png b/windows/keep-secure/images/adlocalaccounts-proc2-sample7.png
new file mode 100644
index 0000000000..8dda5403cf
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc2-sample7.png differ
diff --git a/windows/keep-secure/images/adlocalaccounts-proc3-sample1.png b/windows/keep-secure/images/adlocalaccounts-proc3-sample1.png
new file mode 100644
index 0000000000..e96b26abe1
Binary files /dev/null and b/windows/keep-secure/images/adlocalaccounts-proc3-sample1.png differ
diff --git a/windows/keep-secure/images/authorizationandaccesscontrolprocess.gif b/windows/keep-secure/images/authorizationandaccesscontrolprocess.gif
new file mode 100644
index 0000000000..d8a4d99dd2
Binary files /dev/null and b/windows/keep-secure/images/authorizationandaccesscontrolprocess.gif differ
diff --git a/windows/keep-secure/images/edp-sccm-add-network-domain.png b/windows/keep-secure/images/edp-sccm-add-network-domain.png
new file mode 100644
index 0000000000..505a3ca5fe
Binary files /dev/null and b/windows/keep-secure/images/edp-sccm-add-network-domain.png differ
diff --git a/windows/keep-secure/images/edp-sccm-addapplockerfile.png b/windows/keep-secure/images/edp-sccm-addapplockerfile.png
new file mode 100644
index 0000000000..36d4508747
Binary files /dev/null and b/windows/keep-secure/images/edp-sccm-addapplockerfile.png differ
diff --git a/windows/keep-secure/images/edp-sccm-adddesktopapp.png b/windows/keep-secure/images/edp-sccm-adddesktopapp.png
index 5ceed9bc66..18b1970f81 100644
Binary files a/windows/keep-secure/images/edp-sccm-adddesktopapp.png and b/windows/keep-secure/images/edp-sccm-adddesktopapp.png differ
diff --git a/windows/keep-secure/images/edp-sccm-additionalsettings.png b/windows/keep-secure/images/edp-sccm-additionalsettings.png
new file mode 100644
index 0000000000..3bd31c8e27
Binary files /dev/null and b/windows/keep-secure/images/edp-sccm-additionalsettings.png differ
diff --git a/windows/keep-secure/images/edp-sccm-adduniversalapp.png b/windows/keep-secure/images/edp-sccm-adduniversalapp.png
index bd5009afdc..cd8b78c72d 100644
Binary files a/windows/keep-secure/images/edp-sccm-adduniversalapp.png and b/windows/keep-secure/images/edp-sccm-adduniversalapp.png differ
diff --git a/windows/keep-secure/images/edp-sccm-appmgmt.png b/windows/keep-secure/images/edp-sccm-appmgmt.png
index 0a9d23f405..52a6ef5fd9 100644
Binary files a/windows/keep-secure/images/edp-sccm-appmgmt.png and b/windows/keep-secure/images/edp-sccm-appmgmt.png differ
diff --git a/windows/keep-secure/images/edp-sccm-corp-identity.png b/windows/keep-secure/images/edp-sccm-corp-identity.png
new file mode 100644
index 0000000000..940d60acf1
Binary files /dev/null and b/windows/keep-secure/images/edp-sccm-corp-identity.png differ
diff --git a/windows/keep-secure/images/edp-sccm-devicesettings.png b/windows/keep-secure/images/edp-sccm-devicesettings.png
index 3056cc1c96..1573ef06d7 100644
Binary files a/windows/keep-secure/images/edp-sccm-devicesettings.png and b/windows/keep-secure/images/edp-sccm-devicesettings.png differ
diff --git a/windows/keep-secure/images/edp-sccm-dra.png b/windows/keep-secure/images/edp-sccm-dra.png
new file mode 100644
index 0000000000..d823ecb78d
Binary files /dev/null and b/windows/keep-secure/images/edp-sccm-dra.png differ
diff --git a/windows/keep-secure/images/edp-sccm-generalscreen.png b/windows/keep-secure/images/edp-sccm-generalscreen.png
index 788cef4b8a..e0013f5b2d 100644
Binary files a/windows/keep-secure/images/edp-sccm-generalscreen.png and b/windows/keep-secure/images/edp-sccm-generalscreen.png differ
diff --git a/windows/keep-secure/images/edp-sccm-network-domain.png b/windows/keep-secure/images/edp-sccm-network-domain.png
new file mode 100644
index 0000000000..0fff54b6d2
Binary files /dev/null and b/windows/keep-secure/images/edp-sccm-network-domain.png differ
diff --git a/windows/keep-secure/images/edp-sccm-optsettings.png b/windows/keep-secure/images/edp-sccm-optsettings.png
index d786610c07..65365356da 100644
Binary files a/windows/keep-secure/images/edp-sccm-optsettings.png and b/windows/keep-secure/images/edp-sccm-optsettings.png differ
diff --git a/windows/keep-secure/images/edp-sccm-primarydomain2.png b/windows/keep-secure/images/edp-sccm-primarydomain2.png
deleted file mode 100644
index 5cb9990baf..0000000000
Binary files a/windows/keep-secure/images/edp-sccm-primarydomain2.png and /dev/null differ
diff --git a/windows/keep-secure/images/edp-sccm-summaryscreen.png b/windows/keep-secure/images/edp-sccm-summaryscreen.png
index 2e9d7b138b..2cbb827d7a 100644
Binary files a/windows/keep-secure/images/edp-sccm-summaryscreen.png and b/windows/keep-secure/images/edp-sccm-summaryscreen.png differ
diff --git a/windows/keep-secure/images/edp-sccm-supportedplat.png b/windows/keep-secure/images/edp-sccm-supportedplat.png
index dc72f15692..7add4926a9 100644
Binary files a/windows/keep-secure/images/edp-sccm-supportedplat.png and b/windows/keep-secure/images/edp-sccm-supportedplat.png differ
diff --git a/windows/keep-secure/images/intune-add-applocker-xml-file.png b/windows/keep-secure/images/intune-add-applocker-xml-file.png
new file mode 100644
index 0000000000..8829c070a6
Binary files /dev/null and b/windows/keep-secure/images/intune-add-applocker-xml-file.png differ
diff --git a/windows/keep-secure/images/intune-add-classic-apps.png b/windows/keep-secure/images/intune-add-classic-apps.png
new file mode 100644
index 0000000000..bf4e5792c1
Binary files /dev/null and b/windows/keep-secure/images/intune-add-classic-apps.png differ
diff --git a/windows/keep-secure/images/intune-add-desktop-app.png b/windows/keep-secure/images/intune-add-desktop-app.png
deleted file mode 100644
index 8d8186398a..0000000000
Binary files a/windows/keep-secure/images/intune-add-desktop-app.png and /dev/null differ
diff --git a/windows/keep-secure/images/intune-add-uwp-apps.png b/windows/keep-secure/images/intune-add-uwp-apps.png
new file mode 100644
index 0000000000..933cd9addf
Binary files /dev/null and b/windows/keep-secure/images/intune-add-uwp-apps.png differ
diff --git a/windows/keep-secure/images/intune-add-uwp.png b/windows/keep-secure/images/intune-add-uwp.png
new file mode 100644
index 0000000000..7b226b7edd
Binary files /dev/null and b/windows/keep-secure/images/intune-add-uwp.png differ
diff --git a/windows/keep-secure/images/intune-addapps.png b/windows/keep-secure/images/intune-addapps.png
index f6569723de..52e3983adf 100644
Binary files a/windows/keep-secure/images/intune-addapps.png and b/windows/keep-secure/images/intune-addapps.png differ
diff --git a/windows/keep-secure/images/intune-applocker-before-begin.png b/windows/keep-secure/images/intune-applocker-before-begin.png
new file mode 100644
index 0000000000..3f6a79c8d6
Binary files /dev/null and b/windows/keep-secure/images/intune-applocker-before-begin.png differ
diff --git a/windows/keep-secure/images/intune-applocker-permissions.png b/windows/keep-secure/images/intune-applocker-permissions.png
new file mode 100644
index 0000000000..901c861793
Binary files /dev/null and b/windows/keep-secure/images/intune-applocker-permissions.png differ
diff --git a/windows/keep-secure/images/intune-applocker-publisher-with-app.png b/windows/keep-secure/images/intune-applocker-publisher-with-app.png
new file mode 100644
index 0000000000..29f08e03f0
Binary files /dev/null and b/windows/keep-secure/images/intune-applocker-publisher-with-app.png differ
diff --git a/windows/keep-secure/images/intune-applocker-publisher.png b/windows/keep-secure/images/intune-applocker-publisher.png
new file mode 100644
index 0000000000..42da98610a
Binary files /dev/null and b/windows/keep-secure/images/intune-applocker-publisher.png differ
diff --git a/windows/keep-secure/images/intune-applocker-select-apps.png b/windows/keep-secure/images/intune-applocker-select-apps.png
new file mode 100644
index 0000000000..38ba06d474
Binary files /dev/null and b/windows/keep-secure/images/intune-applocker-select-apps.png differ
diff --git a/windows/keep-secure/images/intune-corporate-identity.png b/windows/keep-secure/images/intune-corporate-identity.png
new file mode 100644
index 0000000000..4ffb6223ea
Binary files /dev/null and b/windows/keep-secure/images/intune-corporate-identity.png differ
diff --git a/windows/keep-secure/images/intune-createnewpolicy.png b/windows/keep-secure/images/intune-createnewpolicy.png
index 02a989d8ae..26ab066343 100644
Binary files a/windows/keep-secure/images/intune-createnewpolicy.png and b/windows/keep-secure/images/intune-createnewpolicy.png differ
diff --git a/windows/keep-secure/images/intune-data-recovery.png b/windows/keep-secure/images/intune-data-recovery.png
index 0913c7a22b..32d7282110 100644
Binary files a/windows/keep-secure/images/intune-data-recovery.png and b/windows/keep-secure/images/intune-data-recovery.png differ
diff --git a/windows/keep-secure/images/intune-edpsettings.png b/windows/keep-secure/images/intune-edpsettings.png
deleted file mode 100644
index 882bf0d46b..0000000000
Binary files a/windows/keep-secure/images/intune-edpsettings.png and /dev/null differ
diff --git a/windows/keep-secure/images/intune-empty-addapps.png b/windows/keep-secure/images/intune-empty-addapps.png
new file mode 100644
index 0000000000..7987e91454
Binary files /dev/null and b/windows/keep-secure/images/intune-empty-addapps.png differ
diff --git a/windows/keep-secure/images/intune-encryption-level.png b/windows/keep-secure/images/intune-encryption-level.png
deleted file mode 100644
index f094fae2f9..0000000000
Binary files a/windows/keep-secure/images/intune-encryption-level.png and /dev/null differ
diff --git a/windows/keep-secure/images/intune-generalinfo.png b/windows/keep-secure/images/intune-generalinfo.png
new file mode 100644
index 0000000000..c740cad913
Binary files /dev/null and b/windows/keep-secure/images/intune-generalinfo.png differ
diff --git a/windows/keep-secure/images/intune-local-security-export.png b/windows/keep-secure/images/intune-local-security-export.png
new file mode 100644
index 0000000000..56b27c2387
Binary files /dev/null and b/windows/keep-secure/images/intune-local-security-export.png differ
diff --git a/windows/keep-secure/images/intune-local-security-snapin-updated.png b/windows/keep-secure/images/intune-local-security-snapin-updated.png
new file mode 100644
index 0000000000..d794b8976c
Binary files /dev/null and b/windows/keep-secure/images/intune-local-security-snapin-updated.png differ
diff --git a/windows/keep-secure/images/intune-local-security-snapin.png b/windows/keep-secure/images/intune-local-security-snapin.png
new file mode 100644
index 0000000000..492f3fc50a
Binary files /dev/null and b/windows/keep-secure/images/intune-local-security-snapin.png differ
diff --git a/windows/keep-secure/images/intune-namedescription.png b/windows/keep-secure/images/intune-namedescription.png
deleted file mode 100644
index 874b8b52a5..0000000000
Binary files a/windows/keep-secure/images/intune-namedescription.png and /dev/null differ
diff --git a/windows/keep-secure/images/intune-network-detection-boxes.png b/windows/keep-secure/images/intune-network-detection-boxes.png
new file mode 100644
index 0000000000..256b586c70
Binary files /dev/null and b/windows/keep-secure/images/intune-network-detection-boxes.png differ
diff --git a/windows/keep-secure/images/intune-networklocation.png b/windows/keep-secure/images/intune-networklocation.png
index 3b1ec39b7c..058aaec38e 100644
Binary files a/windows/keep-secure/images/intune-networklocation.png and b/windows/keep-secure/images/intune-networklocation.png differ
diff --git a/windows/keep-secure/images/intune-optional-settings.png b/windows/keep-secure/images/intune-optional-settings.png
new file mode 100644
index 0000000000..2d2bf90bb1
Binary files /dev/null and b/windows/keep-secure/images/intune-optional-settings.png differ
diff --git a/windows/keep-secure/images/intune-primary-domain.png b/windows/keep-secure/images/intune-primary-domain.png
deleted file mode 100644
index 72105fab7c..0000000000
Binary files a/windows/keep-secure/images/intune-primary-domain.png and /dev/null differ
diff --git a/windows/keep-secure/images/intune-protection-mode.png b/windows/keep-secure/images/intune-protection-mode.png
new file mode 100644
index 0000000000..80804f7946
Binary files /dev/null and b/windows/keep-secure/images/intune-protection-mode.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc1-sample1.png b/windows/keep-secure/images/localaccounts-proc1-sample1.png
new file mode 100644
index 0000000000..e70fa02c92
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc1-sample1.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc1-sample2.png b/windows/keep-secure/images/localaccounts-proc1-sample2.png
new file mode 100644
index 0000000000..085993f92c
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc1-sample2.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc1-sample3.png b/windows/keep-secure/images/localaccounts-proc1-sample3.png
new file mode 100644
index 0000000000..282cdb729d
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc1-sample3.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc1-sample4.png b/windows/keep-secure/images/localaccounts-proc1-sample4.png
new file mode 100644
index 0000000000..89fc916400
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc1-sample4.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc1-sample5.png b/windows/keep-secure/images/localaccounts-proc1-sample5.png
new file mode 100644
index 0000000000..d8d5af1336
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc1-sample5.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc1-sample6.png b/windows/keep-secure/images/localaccounts-proc1-sample6.png
new file mode 100644
index 0000000000..ba3f15f597
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc1-sample6.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc2-sample1.png b/windows/keep-secure/images/localaccounts-proc2-sample1.png
new file mode 100644
index 0000000000..2d44e29e1b
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc2-sample1.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc2-sample2.png b/windows/keep-secure/images/localaccounts-proc2-sample2.png
new file mode 100644
index 0000000000..89136d1ba0
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc2-sample2.png differ
diff --git a/windows/keep-secure/images/localaccounts-proc2-sample3.png b/windows/keep-secure/images/localaccounts-proc2-sample3.png
new file mode 100644
index 0000000000..f2d3a7596b
Binary files /dev/null and b/windows/keep-secure/images/localaccounts-proc2-sample3.png differ
diff --git a/windows/keep-secure/images/oma-uri.png b/windows/keep-secure/images/oma-uri.png
new file mode 100644
index 0000000000..00cfe55d01
Binary files /dev/null and b/windows/keep-secure/images/oma-uri.png differ
diff --git a/windows/keep-secure/images/security-identifider-architecture.jpg b/windows/keep-secure/images/security-identifider-architecture.jpg
new file mode 100644
index 0000000000..cd7d341065
Binary files /dev/null and b/windows/keep-secure/images/security-identifider-architecture.jpg differ
diff --git a/windows/keep-secure/index.md b/windows/keep-secure/index.md
index b605acb372..08feae0e2e 100644
--- a/windows/keep-secure/index.md
+++ b/windows/keep-secure/index.md
@@ -18,17 +18,18 @@ Learn about keeping Windows 10 and Windows 10 Mobile secure.
 | - | - |
 | [Change history for Keep Windows 10 secure](change-history-for-keep-windows-10-secure.md) | This topic lists new and updated topics in the Keep Windows 10 secure documentation for [Windows 10 and Windows 10 Mobile](../index.md). |
 | [Block untrusted fonts in an enterprise](block-untrusted-fonts-in-enterprise.md) | To help protect your company from attacks which may originate from untrusted or attacker controlled font files, we’ve created the Blocking Untrusted Fonts feature. Using this feature, you can turn on a global setting that stops your employees from loading untrusted fonts processed using the Graphics Device Interface (GDI) onto your network. Untrusted fonts are any font installed outside of the %windir%/Fonts directory. Blocking untrusted fonts helps prevent both remote (web-based or email-based) and local EOP attacks that can happen during the font file-parsing process. |
-| [Device Guard certification and compliance](device-guard-certification-and-compliance.md) | Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when. |
 | [Manage identity verification using Microsoft Passport](manage-identity-verification-using-microsoft-passport.md) | In Windows 10, Microsoft Passport replaces passwords with strong two-factor authentication on PCs and mobile devices. This authentication consists of a new type of user credential that is tied to a device and a Windows Hello (biometric) or PIN. |
 | [Windows Hello biometrics in the enterprise](windows-hello-in-enterprise.md) | Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition. |
 | [Configure S/MIME for Windows 10 and Windows 10 Mobile](configure-s-mime.md) | In Windows 10, S/MIME lets users encrypt outgoing messages and attachments so that only intended recipients who have a digital identification (ID), also known as a certificate, can read them. Users can digitally sign a message, which provides the recipients with a way to verify the identity of the sender and that the message hasn't been tampered with. |
 | [Install digital certificates on Windows 10 Mobile](installing-digital-certificates-on-windows-10-mobile.md) | Digital certificates bind the identity of a user or computer to a pair of keys that can be used to encrypt and sign digital information. Certificates are issued by a certification authority (CA) that vouches for the identity of the certificate holder, and they enable secure client communications with websites and services. |
+| [Device Guard deployment guide](device-guard-deployment-guide.md) | Device Guard is a combination of hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when. |
 | [Protect derived domain credentials with Credential Guard](credential-guard.md) | Introduced in Windows 10 Enterprise, Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them. Unauthorized access to these secrets can lead to credential theft attacks, such as Pass-the-Hash or Pass-The-Ticket. Credential Guard prevents these attacks by protecting NTLM password hashes and Kerberos Ticket Granting Tickets. |
 | [Protect your enterprise data using enterprise data protection (EDP)](protect-enterprise-data-using-edp.md) | With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage. |
 | [Use Windows Event Forwarding to help with intrusion detection](use-windows-event-forwarding-to-assist-in-instrusion-detection.md) | Learn about an approach to collect events from devices in your organization. This article talks about events in both normal operations and when an intrusion is suspected. |
 | [VPN profile options](vpn-profile-options.md) | Virtual private networks (VPN) let you give your users secure remote access to your company network. Windows 10 adds useful new VPN profile options to help you manage how users connect. |
+| [Windows security baselines](windows-security-baselines.md) | Learn why you should use security baselines in your organization. |
 | [Security technologies](security-technologies.md) | Learn more about the different security technologies that are available in Windows 10 and Windows 10 Mobile. |
-| [Enterprise security guides](windows-10-enterprise-security-guides.md) | Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. |
+| [Enterprise security guides](windows-10-enterprise-security-guides.md) | Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides. |
  
 ## Related topics
 
diff --git a/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md b/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md
new file mode 100644
index 0000000000..f0e196b799
--- /dev/null
+++ b/windows/keep-secure/introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md
@@ -0,0 +1,78 @@
+---
+title: Introduction to Device Guard - virtualization-based security and code integrity policies (Windows 10)
+description: Microsoft Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating system’s security.
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Introduction to Device Guard: virtualization-based security and code integrity policies
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+With thousands of new malicious files created every day, using traditional methods like antivirus solutions—signature-based detection to fight against malware—provides an inadequate defense against new attacks. Device Guard on Windows 10 Enterprise changes from a mode where apps are trusted unless blocked by an antivirus or other security solution, to a mode where the operating system trusts only apps authorized by your enterprise. You designate these trusted apps by creating *code integrity policies*.
+
+Like the operating system, code integrity contains two primary components: kernel mode code integrity (KMCI) and user mode code integrity (UMCI). KMCI has been available in previous versions of the Windows operating system, and protects the kernel mode from running unsigned drivers. In Windows 10 and Windows Server 2016, UMCI is also available, to help protect against viruses and malware.
+
+To increase the security level offered by code integrity policies, Device Guard can leverage advanced hardware features on hardware that supports them. These features include CPU virtualization extensions (called "Intel VT-x" or "AMD-V") and second-level address translation (SLAT). In addition, hardware that includes input/output memory management units (IOMMUs) provides even stronger protections. When you enable the features associated with CPU virtualization extensions and SLAT, the Code Integrity service can run alongside the kernel in a Windows hypervisor-protected container. The following table provides more information about how Device Guard and these hardware features can help protect against various threats.
+
+For an overview of the process of deploying Device Guard features, see [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+
+## How Device Guard features help protect against threats
+
+The following table lists security threats and describes the corresponding Device Guard features:
+
+| Security threat in the enterprise | How a Device Guard feature helps protect against the threat |
+| --------------------------------- | ----------------------------------------------------------- |
+| **Exposure to new malware**, for which the "signature" is not yet known | **Code integrity policies**:&nbsp;&nbsp;You can maintain a whitelist of software that is allowed to run (a configurable code integrity policy), rather than trying to stay ahead of attackers by maintaining a constantly-updated list of "signatures" of software that should be blocked. This approach uses the trust-nothing model well known in mobile device operating systems.<br>Only code that is verified by Code Integrity, usually through the digital signature that you have identified as being from a trusted signer, is allowed to run. This allows full control over allowed code in both kernel and user mode.<br><br>**Specialized hardware required?** No security-related hardware features are required, although code integrity policies are strengthened by such features, as described in the last three rows of this table. |
+| **Exposure to unsigned code** (most malware is unsigned) | **Code integrity policies, plus catalog files as needed**:&nbsp;&nbsp;Because most malware is unsigned, using a code integrity policy (which in most cases requires signed code) can immediately help protect against a large number of threats. However, many organizations use unsigned line-of-business (LOB) applications, for which the process of signing might be difficult. This has changed in Windows 10, because you can use a tool called Package Inspector to create a *catalog* of all deployed and executed binary files for your trusted applications. After you sign and distribute the catalog, your trusted applications can be handled by code integrity policies in the same way as any other signed application. With this foundation, you can more easily block all unsigned applications, allowing only signed applications to run.<br><br>**Specialized hardware required?** No security-related hardware features are required for creating and using code integrity policies and catalogs. However, code integrity policies and catalogs are strengthened by the hardware features, as described in later rows of this table. |
+| **Malware that gains access to the kernel** and then, from within the kernel, captures sensitive information or damages the system | **Virtualization-based security (VBS)**:&nbsp;&nbsp;This is protection that uses the hypervisor to help protect the kernel and other parts of the operating system. When VBS is enabled, it strengthens either the default kernel-mode code integrity policy (which protects against bad drivers or system files), or the configurable code integrity policy that you deploy.<br>With VBS, even if malware gains access to the kernel, the effects can be severely limited, because the hypervisor can prevent the malware from executing code. The hypervisor, the most privileged level of system software, enforces R/W/X permissions across system memory.  Code integrity checks are performed in a secure environment which is resistant to attack from kernel mode software, and page permissions for kernel mode are set and maintained by the hypervisor. Even if there are vulnerabilities that allow memory modification, like a buffer overflow, the modified memory cannot be executed.<br><br>**Specialized hardware required?** Yes, VBS requires at least CPU virtualization extensions and SLAT, 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). |
+| **DMA-based attacks**, for example, attacks launched from a malicious device that reads secrets from memory, making the enterprise more vulnerable to attack | **Virtualization-based security (VBS) using IOMMUs**:&nbsp;&nbsp;With this type of VBS protection, when the DMA-based attack makes a memory request, input/output memory management units (IOMMUs) will evaluate the request and deny access.<br><br>**Specialized hardware required?** Yes, IOMMUs are a hardware feature that supports the hypervisor, and if you choose hardware that includes them, they can help protect against malicious attempts to access memory. |
+| **Exposure to boot kits or to a physically present attacker at boot time** | **Universal Extensible Firmware Interface (UEFI) Secure Boot**:&nbsp;&nbsp; Secure Boot and related methods protect the boot process and firmware from tampering. This tampering can come from a physically present attacker or from forms of malware that run early in the boot process or in kernel after startup. UEFI is locked down (Boot order, Boot entries, Secure Boot, Virtualization extensions, IOMMU, Microsoft UEFI CA), so the settings in UEFI cannot be changed to compromise Device Guard security.<br><br>**Specialized hardware required?** With UEFI Secure Boot, the requirements are firmware requirements. For more information, see [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).  | 
+
+In this guide, you learn about the individual features found within Device Guard as well as how to plan for, configure, and deploy them. Device Guard with configurable code integrity is intended for deployment alongside additional threat-mitigating Windows features such as [Credential Guard](credential-guard.md) and [AppLocker](applocker-overview.md).
+
+## Tools for managing Device Guard features
+
+You can easily manage Device Guard features by using familiar enterprise and client-management tools that IT pros use every day:
+
+<!-- The item about "Intune" below could be updated at some point, when more information and a link are available. -->
+
+-   **Group Policy**. Windows 10 provides an administrative template to configure and deploy the configurable code integrity policies for your organization. This template also allows you to specify which hardware-based security features you would like to enable and deploy. You can manage these settings along with your existing Group Policy Objects (GPOs), which makes it simpler to implement Device Guard features. In addition to these code integrity and hardware-based security features, you can use Group Policy to help you manage your catalog files.
+
+    - For a description of catalog files, see the table row describing **Exposure to unsigned code** in [How Device Guard features help protect against threats](#how-device-guard-features-help-protect-against-threats), earlier in this topic.
+    - For information about using Group Policy as a deployment tool, see:<br>[Deploy catalog files with Group Policy](deploy-catalog-files-to-support-code-integrity-policies.md#deploy-catalog-files-with-group-policy)<br>[Deploy and manage code integrity policies with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-code-integrity-policies-with-group-policy)
+
+-   **Microsoft System Center Configuration Manager**. You can use System Center Configuration Manager to simplify deployment and management of catalog files, code integrity policies, and hardware-based security features, as well as provide version control. For more information, see [Deploy catalog files with System Center Configuration Manager](deploy-catalog-files-to-support-code-integrity-policies.md#deploy-catalog-files-with-system-center-configuration-manager).
+
+- **Microsoft Intune**. In a future release of Microsoft Intune, Microsoft is considering including features that will support the deployment and management of code integrity policies and catalog files.
+
+-   **Windows PowerShell**. You can use Windows PowerShell to create and service code integrity policies. For more information, see [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md) and [Configurable Code Integrity Policy for Windows PowerShell](https://technet.microsoft.com/library/mt634481.aspx).
+
+These options provide the same experience you're used to in order to manage your existing enterprise management solutions. 
+
+For more information about the deployment of Device Guard features, see:
+- [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+- [Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md)
+
+## Other features that relate to Device Guard
+
+### Device Guard with AppLocker
+
+Although [AppLocker](applocker-overview.md) is not considered a new Device Guard feature, it complements Device Guard functionality when enforced code integrity cannot be fully implemented or its functionality does not cover every desired scenario. There are many scenarios in which code integrity policies would be used alongside AppLocker rules. As a best practice, you should enforce code integrity policies at the most restrictive level possible for your organization, and then you can use AppLocker to fine-tune the restrictions to an even lower level.
+
+> **Note**&nbsp;&nbsp;One example of how Device Guard functionality can be enhanced by AppLocker is when you want to limit universal applications. Universal applications have already been validated by Microsoft to be trustworthy to run, but an organization may not want to allow specific universal applications to run in their environment. You can accomplish this enforcement by using an AppLocker rule.
+
+AppLocker and Device Guard should run side-by-side in your organization, which offers the best of both security features at the same time and provides the most comprehensive security to as many devices as possible. In addition to these features, we recommend that you continue to maintain an enterprise antivirus solution for a well-rounded enterprise security portfolio.
+
+### Device Guard with Credential Guard
+
+Another Windows 10 feature that employs VBS is [Credential Guard](credential-guard.md). Credential Guard provides additional protection to Active Directory domain users by storing domain credentials within the same type of VBS virtualization container that hosts code integrity. By isolating these domain credentials from the active user mode and kernel mode, they have a much lower risk of being stolen. For more information about Credential Guard (which is not a feature within Device Guard), see [Protect derived domain credentials with Credential Guard](credential-guard.md).
+
+Credential Guard is targeted at resisting pass-the-hash and pass-the-ticket techniques. By employing multifactor authentication with Credential Guard, organizations can gain additional protection against such threats. 
+
+In addition to the client-side enabling of Credential Guard, organizations can deploy mitigations at both the CA and domain controller level to help prevent credential theft. For more information, see the [Additional mitigations](https://technet.microsoft.com/en-us/itpro/windows/keep-secure/credential-guard#additional-mitigations) section in “Protect derived domain credentials with Credential Guard.”
+
diff --git a/windows/keep-secure/investigate-files-windows-defender-advanced-threat-protection.md b/windows/keep-secure/investigate-files-windows-defender-advanced-threat-protection.md
index 2f82d6927e..5dfb3959f9 100644
--- a/windows/keep-secure/investigate-files-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/investigate-files-windows-defender-advanced-threat-protection.md
@@ -84,7 +84,7 @@ When the sample is collected, Windows Defender ATP runs the file in is a secure
 
 A progress bar is displayed and provides information on the different stages of the analysis. You can then view the report when the analysis is done.
 
-> **Note**&nbsp;&nbsp;Depending on machine availability, sample collection time can vary. There is a 1-hour timeout for sample collection. The collection will fail and the operation will abort if there is no online Windows 10 machine reporting at that time. You can re-submit files for deep analysis to get fresh data on the file.
+> **Note**&nbsp;&nbsp;Depending on machine availability, sample collection time can vary. There is a 3-hour timeout for sample collection. The collection will fail and the operation will abort if there is no online Windows 10 machine reporting at that time. You can re-submit files for deep analysis to get fresh data on the file.
 
 ## View deep analysis report
 
@@ -121,7 +121,7 @@ HKLM\SOFTWARE\Policies\Microsoft\Sense\AllowSampleCollection
   Value = 0 - block sample collection
   Value = 1 - allow sample collection
 ```
-5. Change the organizational unit through the Group Policy. See [Configure with Group Policy](additional-configuration-windows-defender-advanced-threat-protection.md#configure-with-group-policy).
+5. Change the organizational unit through the Group Policy. See [Configure endpoints using Group Policy](configure-endpoints-gp-windows-defender-advanced-threat-protection.md).
 6. If these steps do not resolve the issue, contact [winatp@microsoft.com](mailto:winatp@microsoft.com).
 
 > **Note**&nbsp;&nbsp;If the value *AllowSampleCollection* is not available, the client will allow sample collection by default.
diff --git a/windows/keep-secure/local-accounts.md b/windows/keep-secure/local-accounts.md
new file mode 100644
index 0000000000..3e94ade971
--- /dev/null
+++ b/windows/keep-secure/local-accounts.md
@@ -0,0 +1,495 @@
+---
+title: Local Accounts (Windows 10)
+description: Local Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Local Accounts
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This reference topic for the IT professional describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server. This topic does not describe the default local user accounts for an Active Directory domain controller.
+
+**Did you mean…**
+
+-   [Active Directory Accounts](active-directory-accounts.md)
+
+-   [Microsoft Accounts](microsoft-accounts.md)
+
+## <a href="" id="about-local-user-accounts-"></a>About local user accounts
+
+
+Local user accounts are stored locally on the server. These accounts can be assigned rights and permissions on a particular server, but on that server only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
+
+This topic describes the following:
+
+-   [Default local user accounts](#sec-default-accounts)
+
+    -   [Administrator account](#sec-administrator)
+
+    -   [Guest Account](#sec-guest)
+
+    -   [HelpAssistant account (installed by using a Remote Assistance session)](#sec-helpassistant)
+
+-   [Default local system accounts](#sec-localsystem)
+
+-   [How to manage local accounts](#sec-manage-accounts)
+
+    -   [Restrict and protect local accounts with administrative rights](#sec-restrict-protect-accounts)
+
+    -   [Enforce local account restrictions for remote access](#sec-enforce-account-restrictions)
+
+    -   [Deny network logon to all local Administrator accounts](#sec-deny-network-logon)
+
+    -   [Create unique passwords for local accounts with administrative rights](#sec-create-unique-passwords)
+
+For information about security principals, see [Security Principals](security-principals.md).
+
+## <a href="" id="sec-default-accounts"></a>Default local user accounts
+
+
+The default local user accounts are built-in accounts that are created automatically when you install the Windows Server operating system on a stand-alone server or member server. The **Applies To** list at the beginning of this article designates the Windows operating systems to which this topic applies.
+
+After the Windows Server operating system is installed, the default local user accounts cannot be removed or deleted. In addition, default local user accounts do not provide access to network resources.
+
+Default local user accounts are used to manage access to the local server’s resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see [How to manage local accounts](#sec-manage-accounts) later in this topic.
+
+The default local user accounts that are provided include the Administrator account, Guest account and HelpAssistant account. Each of these default local user accounts is described in the following sections.
+
+### <a href="" id="sec-administrator"></a>Administrator account
+
+The default local Administrator account is a user account for the system administrator. Every computer has an Administrator account (SID S-1-5-*domain*-500, display name Administrator). The Administrator account is the first account that is created during the installation for all Windows Server operating systems, and for Windows client operating systems.
+
+For Windows Server operating systems, the Administrator account gives the user full control of the files, directories, services, and other resources that are under the control of the local server. The Administrator account can be used to create local users, and assign user rights and access control permissions. The Administrator account can also be used take control of local resources at any time simply by changing the user rights and permissions.
+
+The default Administrator account cannot be deleted or locked out, but it can be renamed or disabled.
+
+The default Administrator account is initially installed differently for Windows Server operating systems, and the Windows client operating systems. The following table provides a comparison.
+
+| Default restriction | Windows Server operating systems | Windows client operating systems |
+|---------------------|----------------------------------|----------------------------------|
+| Administrator account is disabled on installation | No | Yes |
+| Administrator account is set up on first sign-in | Yes | No, keep disabled |
+| Administrator account is used to set up the local server or client computer | Yes | No, use a local user account with **Run as administrator** to obtain administrative rights |
+| Administrator account requires a strong password when it is enabled | Yes | Yes |
+| Administrator account can be disabled, locked out, or renamed | Yes | Yes |
+
+In summary, for Windows Server operating systems, the Administrator account is used to set up the local server only for tasks that require administrative rights. The default Administrator account is set up by using the default settings that are provided on installation. Initially, the Administrator account is not associated with a password. After installation, when you first set up Windows Server, your first task is to set up the Administrator account properties securely. This includes creating a strong password and securing the **Remote control** and **Remote Desktop Services Profile** settings. You can also disable the Administrator account when it is not required.
+
+In comparison, for the Windows client operating systems, the Administrator account has access to the local system only. The default Administrator account is initially disabled by default, and this account is not associated with a password. It is a best practice to leave the Administrator account disabled. The default Administrator account is considered only as a setup and disaster recovery account, and it can be used to join the computer to a domain. When administrator access is required, do not sign in as an administrator. You can sign in to your computer with your local (non-administrator) credentials and use **Run as administrator**. For more information, see [Security considerations](#sec-administrator-security).
+
+**Account group membership**
+
+By default, the Administrator account is installed as a member of the Administrators group on the server. It is a best practice to limit the number of users in the Administrators group because members of the Administrators group on a local server have Full Control permissions on that computer.
+
+The Administrator account cannot be deleted or removed from the Administrators group, but it can be renamed or disabled.
+
+**Security considerations**
+
+Because the Administrator account is known to exist on many versions of the Windows operating system, it is a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to to the server or client computer.
+
+You can rename the Administrator account. However, a renamed Administrator account continues to use the same automatically assigned security identifier (SID), which can be discovered by malicious users. For more information about how to rename or disable a user account, see [Disable or activate a local user account](http://technet.microsoft.com/library/cc732112.aspx) and [Rename a local user account](http://technet.microsoft.com/library/cc725595.aspx).
+
+As a security best practice, use your local (non-Administrator) account to sign in and then use **Run as administrator** to accomplish tasks that require a higher level of rights than a standard user account. Do not use the Administrator account to sign in to your computer unless it is entirely necessary. For more information, see [Run a program with administrative credentials](https://technet.microsoft.com/en-us/library/cc732200.aspx).
+
+In comparison, on the Windows client operating system, a user with a local user account that has Administrator rights is considered the system administrator of the client computer. The first local user account that is created during installation is placed in the local Administrators group. However, when multiple users run as local administrators, the IT staff has no control over these users or their client computers.
+
+In this case, Group Policy can be used to enable secure settings that can control the use of the local Administrators group automatically on every server or client computer. For more information about Group Policy, see [Group Policy Overview](http://technet.microsoft.com/library/hh831791.aspx).
+
+**Note**  
+Blank passwords are not allowed in the versions designated in the **Applies To** list at the beginning of this topic.
+
+ 
+
+**Important**  
+Even when the Administrator account has been disabled, it can still be used to gain access to a computer by using safe mode. In the Recovery Console or in safe mode, the Administrator account is automatically enabled. When normal operations are resumed, it is disabled.
+
+ 
+
+### <a href="" id="sec-guest"></a>Guest account
+
+The Guest account (SID S-1-5-32-546) is disabled by default on installation. The Guest account lets occasional or one-time users, who do not have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it is a security risk. For this reason, it is a best practice to leave the Guest account disabled, unless its use is entirely necessary.
+
+**Account group membership**
+
+By default, the Guest account is the only member of the default Guests group, which lets a user sign in to a server. On occasion, an administrator who is a member of the Administrators group can set up a user with a Guest account on one or more computers.
+
+**Security considerations**
+
+When an administrator enables the Guest account, it is a best practice to create a strong password for this account. In addition, the administrator on the computer should also grant only limited rights and permissions for the Guest account. For security reasons, the Guest account should not be used over the network and made accessible to other computers.
+
+When a computer is shutting down or starting up, it is possible that a guest user or anyone with local access could gain unauthorized access to the computer. To help prevent this risk, do not grant the Guest account the [Shut down the system](shut-down-the-system.md) user right.
+
+In addition, the guest user in the Guest account should not be able to view the event logs. After the Guest account is enabled, it is a best practice to monitor the Guest account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
+
+### <a href="" id="sec-helpassistant"></a>HelpAssistant account (installed by using a Remote Assistance session)
+
+The default HelpAssistant account is enabled when a Windows Remote Assistance session is run. The Windows Remote Assistance session can be used to connect from the server to another computer running the Windows operating system. For solicited remote assistance, a user initiates a Windows Remote Assistance session, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance.
+
+After the user’s invitation for a Windows Remote Assistance session is accepted, the default HelpAssistant account is automatically created. The HelpAssistant account provides limited access to the computer to the person who provides assistance. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service. The HelpAssistant account is automatically deleted after there are no Remote Assistance requests are pending.
+
+The security identifiers (SIDs) that pertain to the default HelpAssistant account include:
+
+-   SID: S-1-5-13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled.
+
+-   SID: S-1-5-14, display name Remote Interactive Logon. This group includes all users who sign in to the computer by using Remote Desktop Connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
+
+For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
+
+In comparison, for the Windows client operating system, the HelpAssistant account is enabled on installation by default.
+
+## <a href="" id="sec-localsystem"></a>Default local system accounts
+
+
+The system account and the Administrator account of the Administrators group have the same file rights and permissions, but they have different functions. The system account is used by the operating system and by services that run under Windows. There are many services and processes in the Windows operating system that need the capability to sign in internally, such as during a Windows installation. The system account was designed for that purpose. It is an internal account that does not show up in User Manager, it cannot be added to any groups, and it cannot have user rights assigned to it.
+
+On the other hand, the system account does appear on an NTFS file system volume in File Manager in the **Permissions** portion of the **Security** menu. By default, the system account is granted Full Control permissions to all files on an NTFS volume. Here the system account has the same functional rights and permissions as the Administrator account.
+
+**Note**  
+To grant the account Administrators group file permissions does not implicitly give permission to the system account. The system account's permissions can be removed from a file, but we do not recommend removing them.
+
+ 
+
+## <a href="" id="sec-manage-accounts"></a>How to manage local user accounts
+
+
+The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC), a collection of administrative tools that you can use to manage a single local or remote computer. For more information about creating and managing local user accounts, see [Manage Local Users](http://technet.microsoft.com/library/cc731899.aspx).
+
+You can use Local Users and Groups to assign rights and permissions on the local server, and that server only, to limit the ability of local users and groups to perform certain actions. A right authorizes a user to perform certain actions on a server, such as backing up files and folders or shutting down a server. An access permission is a rule that is associated with an object, usually a file, folder, or printer. It regulates which users can have access to an object on the server and in what manner.
+
+You cannot use Local Users and Groups to view local users and groups after a member server is used as a domain controller. However, you can use Local Users and Groups on a domain controller to target remote computers that are not domain controllers on the network.
+
+**Note**  
+You use Active Directory Users and Computers to manage users and groups in Active Directory.
+
+ 
+
+### <a href="" id="sec-restrict-protect-accounts"></a>Restrict and protect local accounts with administrative rights
+
+An administrator can use a number of approaches to prevent malicious users from using stolen credentials, such as a stolen password or password hash, for a local account on one computer from being used to authenticate on another computer with administrative rights; this is also called "lateral movement".
+
+The simplest approach is to sign in to your computer with a standard user account, instead of using the Administrator account for tasks, for example, to browse the Internet, send email, or use a word processor. When you want to perform an administrative task, for example, to install a new program or to change a setting that affects other users, you don't have to switch to an Administrator account. You can use User Account Control (UAC) to prompt you for permission or an administrator password before performing the task, as described in the next section.
+
+The other approaches that can be used to restrict and protect user accounts with administrative rights include:
+
+-   Enforce local account restrictions for remote access.
+
+-   Deny network logon to all local Administrator accounts.
+
+-   Create unique passwords for local accounts with administrative rights.
+
+Each of these approaches is described in the following sections.
+
+**Note**  
+These approaches do not apply if all administrative local accounts are disabled.
+
+ 
+
+### <a href="" id="sec-enforce-account-restrictions"></a>Enforce local account restrictions for remote access
+
+The User Account Control (UAC) is a security feature in Windows that has been in use in Windows Server 2008 and in Windows Vista, and the operating systems to which the **Applies To** list refers. UAC enables you to stay in control of your computer by informing you when a program makes a change that requires administrator-level permission. UAC works by adjusting the permission level of your user account. By default, UAC is set to notify you when applications try to make changes to your computer, but you can change how often UAC notifies you.
+
+UAC makes it possible for an account with administrative rights to be treated as a standard user non-administrator account until full rights, also called elevation, is requested and approved. For example, UAC lets an administrator enter credentials during a non-administrator's user session to perform occasional administrative tasks without having to switch users, sign out, or use the **Run as** command.
+
+In addition, UAC can require administrators to specifically approve applications that make system-wide changes before those applications are granted permission to run, even in the administrator's user session.
+
+For example, a default feature of UAC is shown when a local account signs in from a remote computer by using Network logon (for example, by using NET.EXE USE). In this instance, it is issued a standard user token with no administrative rights, but with the ability to request or receive elevation. Consequently, local accounts that sign in by using Network logon cannot access administrative shares such as C$, or ADMIN$, or perform any remote administration.
+
+For more information about UAC, see [User Account Control](user-account-control-overview.md).
+
+The following table shows the Group Policy and registry settings that are used to enforce local account restrictions for remote access.
+
+<table>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<tbody>
+<tr class="odd">
+<td><p><strong>No.</strong></p></td>
+<td><p><strong>Setting</strong></p></td>
+<td><p><strong>Detailed Description</strong></p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options</p></td>
+</tr>
+<tr class="odd">
+<td><p>1</p></td>
+<td><p>Policy name</p></td>
+<td><p>[User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>Enabled</p></td>
+</tr>
+<tr class="odd">
+<td><p>2</p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy name</p></td>
+<td><p>[User Account Control: Run all administrators in Admin Approval Mode](user-account-control-run-all-administrators-in-admin-approval-mode.md)</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>Enabled</p></td>
+</tr>
+<tr class="even">
+<td><p>3</p></td>
+<td><p>Registry key</p></td>
+<td><p><strong>HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System</strong></p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Registry value name</p></td>
+<td><p>LocalAccountTokenFilterPolicy</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Registry value type</p></td>
+<td><p>DWORD</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Registry value data</p></td>
+<td><p>0</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+**To enforce local account restrictions for remote access**
+
+1.  Start the **Group Policy Management** Console (GPMC).
+
+2.  In the console tree, expand &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;, and then **Group Policy Objects** where *forest* is the name of the forest, and *domain* is the name of the domain where you want to set the Group Policy Object (GPO).
+
+3.  In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
+
+    ![local accounts 1](images/localaccounts-proc1-sample1.png)
+
+4.  In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and &gt; **OK** where *gpo\_name* is the name of the new GPO. The GPO name indicates that the GPO is used to restrict local administrator rights from being carried over to another computer.
+
+    ![local accounts 2](images/localaccounts-proc1-sample2.png)
+
+5.  In the details pane, right-click &lt;**gpo\_name**&gt;, and &gt; **Edit**.
+
+    ![local accounts 3](images/localaccounts-proc1-sample3.png)
+
+6.  Ensure that UAC is enabled and that UAC restrictions apply to the default Administrator account by doing the following:
+
+    1.  Navigate to the Computer Configuration\\Policies\\Windows Settings, and &gt; **Security Options**.
+
+    2.  Double-click **User Account Control: Run all administrators in Admin Approval Mode** &gt; **Enabled** &gt; **OK**.
+
+    3.  Double-click **User Account Control: Admin Approval Mode for the Built-in Administrator account** &gt; **Enabled** &gt; **OK**.
+
+7.  Ensure that the local account restrictions are applied to network interfaces by doing the following:
+
+    1.  Navigate to Computer Configuration\\Preferences and Windows Settings, and &gt; **Registry**.
+
+    2.  Right-click **Registry**, and &gt; **New** &gt; **Registry Item**.
+
+        ![local accounts 4](images/localaccounts-proc1-sample4.png)
+
+    3.  In the **New Registry Properties** dialog box, on the **General** tab, change the setting in the **Action** box to **Replace**.
+
+    4.  Ensure that the **Hive** box is set to **HKEY\_LOCAL\_MACHINE**.
+
+    5.  Click (**…**), browse to the following location for **Key Path** &gt; **Select** for: **SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Policies\\System**.
+
+    6.  In the **Value name** area, type **LocalAccountTokenFilterPolicy**.
+
+    7.  In the **Value type** box, from the drop-down list, select **REG\_DWORD** to change the value.
+
+    8.  In the **Value data** box, ensure that the value is set to **0**.
+
+    9.  Verify this configuration, and &gt; **OK**.
+
+        ![local accounts 5](images/localaccounts-proc1-sample5.png)
+
+8.  Link the GPO to the first **Workstations** organizational unit (OU) by doing the following:
+
+    1.  Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path.
+
+    2.  Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
+
+        ![local accounts 6](images/localaccounts-proc1-sample6.png)
+
+    3.  Select the GPO that you just created, and &gt; **OK**.
+
+9.  Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
+
+10. Create links to all other OUs that contain workstations.
+
+11. Create links to all other OUs that contain servers.
+
+### <a href="" id="sec-deny-network-logon"></a>Deny network logon to all local Administrator accounts
+
+Denying local accounts the ability to perform network logons can help prevent a local account password hash from being reused in a malicious attack. This procedure helps to prevent lateral movement by ensuring that the credentials for local accounts that are stolen from a compromised operating system cannot be used to compromise additional computers that use the same credentials.
+
+**Note**  
+In order to perform this procedure, you must first identify the name of the local, default Administrator account, which might not be the default user name "Administrator", and any other accounts that are members of the local Administrators group.
+
+ 
+
+The following table shows the Group Policy settings that are used to deny network logon for all local Administrator accounts.
+
+<table>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<tbody>
+<tr class="odd">
+<td><p><strong>No.</strong></p></td>
+<td><p><strong>Setting</strong></p></td>
+<td><p><strong>Detailed Description</strong></p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment</p></td>
+</tr>
+<tr class="odd">
+<td><p>1</p></td>
+<td><p>Policy name</p></td>
+<td><p>[Deny access to this computer from the network](deny-access-to-this-computer-from-the-network.md)</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>User name of the default Administrator account</p>
+<p>(Might be renamed through policy.)</p></td>
+</tr>
+<tr class="odd">
+<td><p>2</p></td>
+<td><p>Policy location</p></td>
+<td><p>Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment</p></td>
+</tr>
+<tr class="even">
+<td><p></p></td>
+<td><p>Policy name</p></td>
+<td><p>[Deny log on through Remote Desktop Services](deny-log-on-through-remote-desktop-services.md)</p></td>
+</tr>
+<tr class="odd">
+<td><p></p></td>
+<td><p>Policy setting</p></td>
+<td><p>User name of the default Administrator account</p>
+<p>(Might be renamed through policy).</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+**To deny network logon to all local administrator accounts**
+
+1.  Start the **Group Policy Management** Console (GPMC).
+
+2.  In the console tree, expand &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;, and then **Group Policy Objects**, where *forest* is the name of the forest, and *domain* is the name of the domain where you want to set the Group Policy Object (GPO).
+
+3.  In the console tree, right-click **Group Policy Objects**, and &gt; **New**.
+
+4.  In the **New GPO** dialog box, type &lt;**gpo\_name**&gt;, and then &gt; **OK** where *gpo\_name* is the name of the new GPO indicates that it is being used to restrict the local administrative accounts from interactively signing in to the computer.
+
+    ![local accounts 7](images/localaccounts-proc2-sample1.png)
+
+5.  In the details pane, right-click &lt;**gpo\_name**&gt;, and &gt; **Edit**.
+
+    ![local accounts 8](images/localaccounts-proc2-sample2.png)
+
+6.  Configure the user rights to deny network logons for administrative local accounts as follows:
+
+    1.  Navigate to the Computer Configuration\\Policies\\Windows Settings, and &gt; **User Rights Assignment**.
+
+    2.  Double-click **Deny access to this computer from the network**, and &gt; **Define these policy settings**.
+
+    3.  Click **Add User or Group**, type the name of the default Administrator account, and &gt; **OK**. The default name is Administrator on US English installations, but it can be renamed either by policy or manually.
+
+        ![local accounts 9](images/localaccounts-proc2-sample3.png)
+
+        **Important**  
+        In the **User and group names** box, type the user name of the account that you identified at the start of this process. Do not click **Browse** and do not type the domain name or the local computer name in this dialog box. For example, type only **Administrator**. If the text that you typed resolved to a name that is underlined, includes a computer name, or includes the domain, it restricts the wrong account and causes this mitigation to work incorrectly. Also, be careful that you do not enter the group name Administrator to prevent blocking domain accounts in that group.
+
+         
+
+    4.  For any additional local accounts in the Administrators group on all of the workstations that you are configuring, click **Add User or Group**, type the user names of these accounts in the dialog box in the same manner as described in the previous step, and then click **OK**.
+
+7.  Configure the user rights to deny Remote Desktop (Remote Interactive) logons for administrative local accounts as follows:
+
+    1.  Navigate to Computer Configuration\\Policies\\Windows Settings and Local Policies, and then click **User Rights Assignment**.
+
+    2.  Double-click **Deny log on through Remote Desktop Services**, and then select **Define these settings**.
+
+    3.  Click **Add User or Group**, type the user name of the default Administrator account, and &gt; **OK**. (The default name is Administrator on US English installations, but it can be renamed either by policy or manually.
+
+        **Important**  
+        In the **User and group names** box, type the user name of the account that you identified at the start of this process. Do not click **Browse** and do not type the domain name or the local computer name in this dialog box. For example, type only **Administrator**. If the text that you typed resolves to a name that is underlined or includes a domain name, it restricts the wrong account and causes this mitigation to work incorrectly. Also, be careful that you do not enter the group name Administrator because this also blocks domain accounts in that group.
+
+         
+
+    4.  For any additional local accounts in the Administrators group on all of the workstations that you are setting up, click **Add User or Group**, type the user names of these accounts in the dialog box in the same manner as the previous step, and &gt; **OK**.
+
+8.  Link the GPO to the first **Workstations** OU as follows:
+
+    1.  Navigate to the &lt;*Forest*&gt;\\Domains\\&lt;*Domain*&gt;\\OU path.
+
+    2.  Right-click the **Workstations** OU, and &gt; **Link an existing GPO**.
+
+    3.  Select the GPO that you just created, and &gt; **OK**.
+
+9.  Test the functionality of enterprise applications on the workstations in that first OU and resolve any issues caused by the new policy.
+
+10. Create links to all other OUs that contain workstations.
+
+11. Create links to all other OUs that contain servers.
+
+    **Note**  
+    You might have to create a separate GPO if the user name of the default Administrator account is different on workstations and servers.
+
+     
+
+### <a href="" id="sec-create-unique-passwords"></a>Create unique passwords for local accounts with administrative rights
+
+Passwords should be unique per individual account. While this is generally true for individual user accounts, many enterprises have identical passwords for common local accounts, such as the default Administrator account. This also occurs when the same passwords are used for local accounts during operating system deployments.
+
+Passwords that are left unchanged or changed synchronously to keep them identical add a significant risk for organizations. Randomizing the passwords mitigates "pass-the-hash" attacks by using different passwords for local accounts, which hampers the ability of malicious users to use password hashes of those accounts to compromise other computers.
+
+Passwords can be randomized by:
+
+-   Purchasing and implementing an enterprise tool to accomplish this task. These tools are commonly referred to as "privileged password management" tools.
+
+-   Configuring, customizing and implementing a free tool to accomplish this task. A sample tool with source code is available at [Solution for management of built-in Administrator account’s password via GPO](http://code.msdn.microsoft.com/windowsdesktop/Solution-for-management-of-ae44e789).
+
+    **Note**  
+    This tool is not supported by Microsoft. There are some important considerations to make before deploying this tool because this tool requires client-side extensions and schema extensions to support password generation and storage.
+
+     
+
+-   Create and implement a custom script or solution to randomize local account passwords.
+
+## <a href="" id="dhcp-references"></a>See also
+
+
+The following resources provide additional information about technologies that are related to local accounts.
+
+-   [Security Principals](security-principals.md)
+
+-   [Security Identifiers](security-identifiers.md)
+
+-   [Access Control Overview](access-control.md)
diff --git a/windows/keep-secure/mandatory-settings-for-wip.md b/windows/keep-secure/mandatory-settings-for-wip.md
new file mode 100644
index 0000000000..56b79bc283
--- /dev/null
+++ b/windows/keep-secure/mandatory-settings-for-wip.md
@@ -0,0 +1,32 @@
+---
+title: Mandatory tasks and settings required to turn on Windows Information Protection (WIP) (Windows 10)
+description: This list provides all of the tasks that are required for the operating system to turn on Windows Information Protection (WIP), formerly known as enterprise data protection (EDP) in your enterprise.
+keywords: Windows Information Protection, WIP, EDP, Enterprise Data Protection, protected apps, protected app list, App Rules, Allowed apps list
+ms.prod: w10
+ms.mktglfcycl: explore
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Mandatory tasks and settings required to turn on Windows Information Protection (WIP)
+**Applies to:**
+
+-   Windows 10 Insider Preview
+-   Windows 10 Mobile Preview
+
+<span style="color:#ED1C24;">[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
+
+This list provides all of the tasks and settings that are required for the operating system to turn on Windows Information Protection (WIP), formerly known as enterprise data protection (EDP), in your enterprise.
+
+>**Important**<br>
+All sections provided for more info appear in either the [Create a Windows Information Protection (WIP) policy using Microsoft Intune](create-edp-policy-using-intune.md) or [Create a Windows Information Protection (WIP) policy using System Center Configuration Manager](create-edp-policy-using-sccm.md), based on the tool you're using in your enterprise.
+
+
+|Task                                |Description               |
+|------------------------------------|--------------------------|
+|Add at least one app rule in the **App Rules** area in your WIP policy. |You must have at least one app rule specified in the **App Rules** area of your WIP policy. For more info about where this area is and how to add an app rule, see the **Add individual apps to your Protected App list** section of the policy creation topics.|
+|Pick your WIP protection level. |You must choose the level of protection level you want to apply to your WIP-protected content, including Override, Silent, or Block. For more info about where this area is and how to decide on your protection level, see the **Manage the EDP protection level for your enterprise data** section of the policy creation topics.|
+|Specify your corporate identity. |You must specify your corporate identity, usually expressed as your primary Internet domain (for example, contoso.com). For more info about where this area is and what it means, see the **Define your enterprise-managed corporate identity** section of the policy creation topics. |
+|Specify your Enterprise Network Domain Names. |You must specify the DNS suffixes used in your environment. All traffic to the fully-qualified domains appearing in this list will be protected. For more info about where this area is and how to add your suffixes, see the table that appears in the **Choose where apps can access enterprise data** section of the policy creation topics. |
+|Specify your Enterprise IPv4 or IPv6 Ranges. |Specify the addresses for a valid IPv4 or IPv6 value range within your intranet. These addresses, used with your Enterprise Network Domain Names, define your corporate network boundaries. For more info about where this area is and what it means, see the table that appears in the **Define your enterprise-managed corporate identity** section of the policy creation topics. |
+|Include your Data Recovery Agent (DRA) certificate. |This certificate makes sure that any of your WIP-encrypted data can be decrypted, even if the security keys are lost. For more info about where this area is and what it means, see the **Create and verify an Encrypting File System (EFS) DRA certificate for EDP** section of the policy creation topics. |
\ No newline at end of file
diff --git a/windows/keep-secure/microsoft-accounts.md b/windows/keep-secure/microsoft-accounts.md
new file mode 100644
index 0000000000..910e6fac1f
--- /dev/null
+++ b/windows/keep-secure/microsoft-accounts.md
@@ -0,0 +1,160 @@
+---
+title: Microsoft Accounts (Windows 10)
+description: Microsoft Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Microsoft Accounts
+
+**Applies to**
+-   Windows 10
+
+This topic for the IT professional explains how a Microsoft account works to enhance security and privacy for users, and how you can manage this consumer account type in your organization.
+
+Microsoft sites, services, and properties such as Windows Live, MSN, Xbox LIVE, Zune, Windows Phone, and computers running Windows 10, Windows 8.1, Windows 8, and Windows RT use a Microsoft account as a mean of identifying users. Microsoft account is the name for what was previously called Windows Live ID. It has user-defined secrets associated with it, and it consists of a unique email address and a password.
+
+There are some benefits and considerations when using Microsoft accounts in the enterprise. For more information, see [Microsoft account in the enterprise](#bkmk-msaccountintheenterprise) later in this topic.
+
+When a user signs in with a Microsoft account, their device is connected to cloud services, and many of the settings, preferences, and apps associated with that user account can roam between devices.
+
+**Note**  
+This content applies to the operating system versions that are designated in the **Applies To** list at the beginning of this topic.
+
+ 
+
+## <a href="" id="bkmk-benefits"></a>How a Microsoft account works
+
+
+The Microsoft account allows users to sign in to websites that support this service by using a single set of credentials. Users' credentials are validated by a Microsoft account authentication server that is associated with a website. The Windows Store is an example of this association. When new users sign in to websites that are enabled to use Microsoft accounts, they are redirected to the nearest authentication server, which asks for a user name and password. Windows uses the Schannel Security Support Provider to open a Transport Level Security/Secure Sockets Layer (TLS/SSL) connection for this function. Users then have the option to use Credential Manager to store their credentials.
+
+When users sign in to websites that are enabled to use a Microsoft account, a time-limited cookie is installed on their computers, which includes a triple DES encrypted ID tag. This encrypted ID tag has been agreed upon between the authentication server and the website. This ID tag is sent to the website, and the website plants another time-limited encrypted HTTP cookie on the user’s computer. When these cookies are valid, users are not required to supply a user name and password. If a user actively signs out of their Microsoft account, these cookies are removed.
+
+**Important**  
+Local Windows account functionality has not been removed, and it is still an option to use in managed environments.
+
+ 
+
+### How Microsoft accounts are created
+
+To prevent fraud, the Microsoft system verifies the IP address when a user creates an account. If a user tries to create multiple Microsoft accounts with the same IP address, they are stopped.
+
+Microsoft accounts are not designed to be created in batches, for example, for a group of domain users within your enterprise.
+
+There are two methods for creating a Microsoft account:
+
+-   **Use an existing email address**.
+
+    Users are able to use their valid email addresses to sign up for Microsoft accounts. The service turns the requesting user's email address into a Microsoft account. Users can also choose their personal password.
+
+-   **Sign up for a Microsoft email address**.
+
+    Users can sign up for an email account with Microsoft's webmail services. This account can be used to sign in to websites that are enabled to use Microsoft accounts.
+
+### How the Microsoft account information is safeguarded
+
+Credential information is encrypted twice. The first encryption is based on the account’s password. Credentials are encrypted again when they are sent across the Internet. The data that is stored is not available to other Microsoft or non-Microsoft services.
+
+-   **Strong password is required**.
+
+    Blank passwords are not allowed.
+
+    For more information, see [Microsoft Account Security Overview](http://www.microsoft.com/account/security/default.aspx).
+
+-   **Secondary proof of identity is required**.
+
+    Before user profile information and settings can be accessed on a second supported Windows computer for the first time, trust must established for that device by providing secondary proof of identity. This can be accomplished by providing Windows with a code that is sent to a mobile phone number or by following the instructions that are sent to an alternate email address that a user specifies in the account settings.
+
+-   **All user profile data is encrypted on the client before it is transmitted to the cloud**.
+
+    User data does not roam over a wireless wide area network (WWAN) by default, thereby protecting profile data. All data and settings that leave a device are transmitted through the TLS/SSL protocol.
+
+**Microsoft account security information is added**.
+
+Users can add security information to their Microsoft accounts through the **Accounts** interface on computers running the supported versions of Windows. This feature allows the user to update the security information that they provided when they created their accounts. This security information includes an alternate email address or phone number so if their password is compromised or forgotten, a verification code can be sent to verify their identity. Users can potentially use their Microsoft accounts to store corporate data on a personal OneDrive or email app, so it is safe practice for the account owner to keep this security information up-to-date.
+
+## <a href="" id="bkmk-msaccountintheenterprise"></a>The Microsoft account in the enterprise
+
+
+Although the Microsoft account was designed to serve consumers, you might find situations where your domain users can benefit by using their personal Microsoft account in your enterprise. The following list describes some advantages.
+
+-   **Download Windows Store apps**:
+
+    If your enterprise chooses to distribute software through the Windows Store, your users can use their Microsoft accounts to download and use them on up to five devices running any version of Windows 10, Windows 8.1, Windows 8, or Windows RT.
+
+-   **Single sign-on**:
+
+    Your users can use Microsoft account credentials to sign in to devices running Windows 10, Windows 8.1, Windows 8 or Windows RT. When they do this, Windows works with your Windows Store app to provide authenticated experiences for them. Users can associate a Microsoft account with their sign-in credentials for Windows Store apps or websites, so that these credentials roam across any devices running these supported versions.
+
+-   **Personalized settings synchronization**:
+
+    Users can associate their most commonly used operating-system settings with a Microsoft account. These settings are available whenever a user signs in with that account on any device that is running a supported version of Windows and is connected to the cloud. After a user signs in, the device automatically attempts to get the user's settings from the cloud and apply them to the device.
+
+-   **App synchronization**:
+
+    Windows Store apps can store user-specific settings so that these settings are available to any device. As with operating system settings, these user-specific app settings are available whenever the user signs in with the same Microsoft account on any device that is running a supported version of Windows and is connected to the cloud. After the user signs in, that device automatically downloads the settings from the cloud and applies them when the app is installed.
+
+-   **Integrated social media services**:
+
+    Contact information and status for your users’ friends and associates automatically stay up-to-date from sites such as Hotmail, Outlook, Facebook, Twitter, and LinkedIn. Users can also access and share photos, documents, and other files from sites such as SkyDrive, Facebook, and Flickr.
+
+### Managing the Microsoft account in the domain
+
+Depending on your IT and business models, introducing Microsoft accounts into your enterprise might add complexity or it might provide solutions. You should address the following considerations before you allow the use of these account types in your enterprise:
+
+-   [Restrict the use of the Microsoft account](#bkmk-restrictuse)
+
+-   [Configure connected accounts](#bkmk-cfgconnectedaccounts)
+
+-   [Provision Microsoft accounts in the enterprise](#bkmk-provisionaccounts)
+
+-   [Audit account activity](#bkmk-audit)
+
+-   [Perform password resets](#bkmk-passwordresets)
+
+-   [Restrict app installation and usage](#bkmk-restrictappinstallationandusage)
+
+### <a href="" id="bkmk-restrictuse"></a>Restrict the use of the Microsoft account
+
+If employees are allowed to join the domain with their personal devices, they might expect to connect to enterprise resources by using their Microsoft accounts. If you want to prevent any use of Microsoft accounts within your enterprise, you can configure the local security policy setting [Accounts: Block Microsoft accounts](accounts-block-microsoft-accounts.md). However, this setting can prevent the users from signing in to their Windows devices with their Microsoft accounts (if they had set them up to do so) when they are joined to the domain.
+
+The default for this setting is **Disabled**, which enables users to use their Microsoft accounts on devices that are joined to your domain. Other options in the setting can:
+
+1.  Prevent users from creating new Microsoft accounts on a computer, switch a local account to a Microsoft account, or connect a domain account to a Microsoft account. This is the preferred option if you need to limit the use of Microsoft accounts in your enterprise.
+
+2.  Prevent users with an existing Microsoft account from signing in to Windows. Selecting this option might make it impossible for an existing administrator to sign in to a computer and manage the system.
+
+### <a href="" id="bkmk-cfgconnectedaccounts"></a>Configure connected accounts
+
+Users can connect a Microsoft account to their domain account and synchronize the settings and preferences between them. This enables users to see the same desktop background, app settings, browser history and favorites, and other Microsoft account settings on their other devices.
+
+Users can disconnect a Microsoft account from their domain account at any time as follows: In **PC settings**, tap or click **Users**, tap or click **Disconnect**, and then tap or click **Finish**.
+
+**Note**  
+Connecting Microsoft accounts with domain accounts can limit access to some high-privileged tasks in Windows. For example, Task Scheduler will evaluate the connected Microsoft account for access and fail. In these situations, the account owner should disconnect the account.
+
+ 
+
+### <a href="" id="bkmk-provisionaccounts"></a>Provision Microsoft accounts in the enterprise
+
+Microsoft accounts are private user accounts. There are no methods provided by Microsoft to provision Microsoft accounts for an enterprise. Enterprises should use domain accounts.
+
+### <a href="" id="bkmk-audit"></a>Audit account activity
+
+Because Microsoft accounts are Internet-based, Windows does not have a mechanism to audit their use until the account is associated with a domain account. But this association does not restrict the user from disconnecting the account or disjoining from the domain. It is not possible to audit the activity of accounts that are not associated with your domain.
+
+### <a href="" id="bkmk-passwordresets"></a>Perform password resets
+
+Only the owner of the Microsoft account can change the password. Passwords can be changed in the [Microsoft account sign-in portal](https://login.live.com).
+
+### <a href="" id="bkmk-restrictappinstallationandusage"></a>Restrict app installation and usage
+
+Within your organization, you can set application control policies to regulate app installation and usage for Microsoft accounts. For more information, see [AppLocker](applocker-overview.md) and [Packaged Apps and Packaged App Installer Rules in AppLocker](packaged-apps-and-packaged-app-installer-rules-in-applocker.md).
+
+## See also
+
+- [Managing Privacy: Using a Microsoft Account to Logon and Resulting Internet Communication](https://technet.microsoft.com/library/jj884082(v=ws.11).aspx)
+
+- [Access Control Overview](access-control.md)
diff --git a/windows/keep-secure/minimum-requirements-windows-defender-advanced-threat-protection.md b/windows/keep-secure/minimum-requirements-windows-defender-advanced-threat-protection.md
index 91db7537e8..1bc9344b78 100644
--- a/windows/keep-secure/minimum-requirements-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/minimum-requirements-windows-defender-advanced-threat-protection.md
@@ -43,15 +43,4 @@ Internet connectivity on endpoints is also required. See [Configure Windows Defe
 
 Before you configure endpoints, the telemetry and diagnostics service must be enabled. The service is enabled by default in Windows 10, but if it has been disabled you can turn it on by following the instructions in the [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md) section.
 
-### Deployment channel operating system requirements
 
-You can choose to onboard endpoints with a scheduled Group Policy (GP) or System Center Configuration Manager (SCCM) update (using a configuration package that you download from the portal or during the service onboarding wizard), or by manually running a script to modify the registry.
-
-The following describes the minimum operating system or software version
-required for each deployment channel.
-
-Deployment channel | Minimum server requirements
-:---|:---
-Group Policy settings | Windows Server 2008 R2
-System Center Configuration Manager | SCCM 2012
-Manual (script) | No minimum requirements
diff --git a/windows/keep-secure/monitor-onboarding-windows-defender-advanced-threat-protection.md b/windows/keep-secure/monitor-onboarding-windows-defender-advanced-threat-protection.md
deleted file mode 100644
index 8babe1f172..0000000000
--- a/windows/keep-secure/monitor-onboarding-windows-defender-advanced-threat-protection.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-title: Monitor Windows Defender ATP onboarding
-description: Monitor the onboarding of the Windows Defender ATP service to ensure your endpoints are correctly configured and are sending telemetry reports.
-keywords: monitor onboarding, monitor Windows Defender ATP onboarding, monitor Windows Defender Advanced Threat Protection onboarding
-search.product: eADQiWindows 10XVcnh
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.sitesec: library
-ms.pagetype: security
-author: mjcaparas
----
-
-# Monitor Windows Defender Advanced Threat Protection onboarding
-
-**Applies to:**
-
-- Windows 10 Insider Preview Build 14322 or later
-- Windows Defender Advanced Threat Protection (Windows Defender ATP)
-
-<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
-
-You can monitor the onboarding of the Windows Defender ATP service to ensure your endpoints are correctly configured and are sending telemetry reports.
-
-You might need to monitor the onboarding if the package did not configure the registry correctly, or the reporting client did not start or execute correctly.
-
-Monitoring can be done directly on the portal, or by using System Center Configuration Manager (SCCM).
-
-## Monitor with the portal
-
-1.  Go to the [Windows Defender ATP portal](https://securitycenter.windows.com/).
-
-2.  Click **Machines view**.
-
-3.  Verify that endpoints are appearing.
-
-
-> **Note**&nbsp;&nbsp;It can take several days for endpoints to start showing on the **Machines view**. This includes the time it takes for the policies to be distributed to the endpoint, the time it takes before the user logs on, and the time it takes for the endpoint to start reporting.
-
-## Monitor with System Center Configuration Manager
-
-Monitoring with SCCM consists of two parts:
-
-1. Confirming the configuration package has been correctly deployed and is running (or has successfully run) on the endpoints in your network.
-
-2. Checking that the endpoints are compliant with the Windows Defender ATP service (this ensures the endpoint can complete the onboarding process and can continue to report data to the service).
-
-**To confirm the configuration package has been correctly deployed:**
-
-1. In the SCCM console, click **Monitoring** at the bottom of the navigation pane.
-
-2. Click **Overview** and then **Deployments**.
-
-3. Click on the deployment with the package name.
-
-4. Review the status indicators under **Completion Statistics** and **Content Status**.
-
-If there are failed deployments (endpoints with **Error**, **Requirements Not Met**, or **Failed statuses**), you may need to  troubleshoot the endpoints. See the [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md) topic for more information.
-
-![SCCM showing successful deployment with no errors](images/sccm-deployment.png)
-
-## Related topics
-<!--- [Windows Defender ATP service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md)-->
-- [Configure Windows Defender ATP endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md)
-- [Configure endpoint proxy and Internet connectivity settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md)
-- [Additional Windows Defender ATP configuration settings](additional-configuration-windows-defender-advanced-threat-protection.md)
-- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
diff --git a/windows/keep-secure/onboard-configure-windows-defender-advanced-threat-protection.md b/windows/keep-secure/onboard-configure-windows-defender-advanced-threat-protection.md
index eaaa736c69..942dfa02ee 100644
--- a/windows/keep-secure/onboard-configure-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/onboard-configure-windows-defender-advanced-threat-protection.md
@@ -14,28 +14,16 @@ author: iaanw
 
 **Applies to:**
 
-- Windows 10 TAP program
+- Windows 10 Insider Preview Build 14332 or later
 - Windows Defender Advanced Threat Protection (Windows Defender ATP)
 
 <span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
 
 You need to onboard to Windows Defender ATP before you can use the service.
 
-<!--There are two stages to onboarding:
-
-1.  Set up user access in AAD and use a wizard to create a dedicated
-    cloud instance for your network (known as “service onboarding”).
-
-2.  Add endpoints to the service with System Center Configuration Manager, scheduled GP updates, or manual
-    registry changes.-->
-
-<!--[Service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md) | Learn about managing user access to the Windows Defender ATP portal by assigning users to the Windows Defender ATP service application in Azure Active Directory (AAD).-->
-
 ## In this section
 Topic | Description
 :---|:---
-[Configure endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md) | You'll need to configure endpoints for it to report to the Windows Defender ATP service. Learn how you can use the configuration package to configure endpoints in your enterprise.
+[Configure endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md) | You'll need to configure endpoints for it to report to the Windows Defender ATP service. Learn about the tools and methods you can use to configure endpoints in your enterprise.
 [Configure proxy and Internet settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md)| Enable communication with the Windows Defender ATP cloud service by configuring the proxy and Internet connectivity settings.
-[Additional configuration settings] (additional-configuration-windows-defender-advanced-threat-protection.md) | Learn how to configure settings for sample sharing used in the deep analysis feature.
-[Monitor onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md) | Learn how you can monitor the onboarding to ensure your endpoints are correctly configured and are sending telemetry reports.
 [Troubleshoot onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md) | Learn about resolving issues that might arise during onboarding.
diff --git a/windows/keep-secure/optional-create-a-code-signing-certificate-for-code-integrity-policies.md b/windows/keep-secure/optional-create-a-code-signing-certificate-for-code-integrity-policies.md
new file mode 100644
index 0000000000..f915647f15
--- /dev/null
+++ b/windows/keep-secure/optional-create-a-code-signing-certificate-for-code-integrity-policies.md
@@ -0,0 +1,101 @@
+---
+title: Optional - Create a code signing certificate for code integrity policies (Windows 10)
+description: This article describes how to create a code signing certificate for code integrity policies, one of the main features that are part of Device Guard in Windows 10. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Optional: Create a code signing certificate for code integrity policies
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+As you deploy code integrity policies (part of Device Guard), 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 or an internal CA. If you have purchased a code signing certificate, you can skip this topic and instead follow other topics listed in [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md). 
+
+If you have not purchased a certificate but have an internal CA, complete these steps to create a code signing certificate:
+
+1.  Open the Certification Authority Microsoft Management Console (MMC) snap-in, and then select your issuing CA.
+
+2.  When connected, right-click **Certificate Templates**, and then click **Manage** to open the Certification Templates Console.
+
+    ![CA snap-in showing Certificate Templates](images/dg-fig27-managecerttemp.png)
+
+    Figure 1. Manage the certificate templates
+
+3.  In the navigation pane, right-click the Code Signing certificate, and then click **Duplicate Template**.
+
+4.  On the **Compatibility** tab, clear the **Show resulting changes** check box. Select **Windows Server 2012** from the **Certification Authority** list, and then select **Windows 8 / Windows Server 2012** from the **Certificate recipient** list.
+
+5.  On the **General** tab, specify the **Template display name** and **Template name**. This example uses the name **DG Catalog Signing Certificate**.
+
+6.  On the **Request Handling** tab, select the **Allow private key to be exported** check box.
+
+7.  On the **Extensions** tab, select the **Basic Constraints** check box, and then click **Edit**.
+
+8.  In the **Edit Basic Constraints Extension** dialog box, select **Enable this extension**, as shown in Figure 2.
+
+    ![Edit Basic Constraints Extension](images/dg-fig29-enableconstraints.png)
+
+    Figure 2. Select constraints on the new template
+
+9.  If a certificate manager is required to approve any issued certificates, on the **Issuance Requirements** tab, select **CA certificate manager approval**.
+
+10. On the **Subject Name** tab, select **Supply in the request**.
+
+11. On the **Security** tab, verify that whatever account will be used to request the certificate has the right to enroll the certificate.
+
+12. Click **OK** to create the template, and then close the Certificate Template Console.
+
+When this certificate template has been created, you must publish it to the CA published template store. To do so, complete the following steps:
+
+1.  In the Certification Authority MMC snap-in, right-click **Certification Templates**, point to **New**, and then click **Certificate Template to Issue**, as shown in Figure 3.
+
+    ![Select Certificate Template to Issue](images/dg-fig30-selectnewcert.png)
+
+    Figure 3. Select the new certificate template to issue
+
+    A list of available templates to issue appears, including the template you just created.
+
+2.  Select the DG Catalog signing certificate, and then click **OK**.
+
+Now that the template is available to be issued, you must request one from the computer running Windows 10 on which you create and sign catalog files. To begin, open the MMC, and then complete the following steps:
+
+1.  In MMC, from the **File** menu, click **Add/Remove Snap-in**. Double-click **Certificates**, and then select **My user account**.
+
+2.  In the Certificates snap-in, right-click the Personal store folder, point to **All Tasks**, and then click **Request New Certificate**.
+
+3.  Click **Next** twice to get to the certificate selection list.
+
+4.  In the **Request Certificate** list, select your newly created code signing certificate, and then select the blue text that requests additional information, as shown in Figure 4.
+
+    ![Request Certificates: more information required](images/dg-fig31-getmoreinfo.png)
+
+    Figure 4. Get more information for your code signing certificate
+
+5.  In the **Certificate Properties** dialog box, for **Type**, select **Common name**. For **Value**, select **ContosoDGSigningCert**, and then click **Add**. When added, click **OK.**
+
+6.  Enroll and finish.
+
+> **Note**&nbsp;&nbsp;If a certificate manager is required to approve any issued certificates and you selected to require management approval on the template, the request will need to be approved in the CA before it will be issued to the client.
+
+This certificate must be installed in the user’s personal store on the computer that will be signing the catalog files and code integrity policies. If the signing is going to be taking place on the computer on which you just requested the certificate, exporting the certificate to a .pfx file will not be required because it already exists in your personal store. If you are signing on another computer, you will need to export the .pfx certificate with the necessary keys and properties. To do so, complete the following steps:
+
+1.  Right-click the certificate, point to **All Tasks**, and then click **Export**.
+
+2.  Click **Next**, and then select **Yes, export the private key**.
+
+3.  Choose the default settings, and then select **Export all extended properties**.
+
+4.  Set a password, select an export path, and then select **DGCatSigningCert.pfx** as the file name.
+
+When the certificate has been exported, import it into the personal store for the user who will be signing the catalog files or code integrity policies on the specific computer that will be signing them.
+
+## Related topics
+
+- [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md)
+
+- [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+
diff --git a/windows/keep-secure/overview-create-edp-policy.md b/windows/keep-secure/overview-create-edp-policy.md
index 0ca5b7cbd1..02e9e28ec7 100644
--- a/windows/keep-secure/overview-create-edp-policy.md
+++ b/windows/keep-secure/overview-create-edp-policy.md
@@ -1,6 +1,6 @@
 ---
 title: Create an enterprise data protection (EDP) policy (Windows 10)
-description: Microsoft Intune and System Center Configuration Manager (version 1511 or later) helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
+description: Microsoft Intune and System Center Configuration Manager Technical Preview version 1605 or later helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
 ms.assetid: d2059e74-94bd-4e54-ab59-1a7b9b52bdc6
 ms.prod: w10
 ms.mktglfcycl: explore
@@ -17,13 +17,13 @@ author: eross-msft
 
 <span style="color:#ED1C24;">[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
 
-Microsoft Intune and System Center Configuration Manager (version 1511 or later) helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
+Microsoft Intune and System Center Configuration Manager Technical Preview version 1605 or later helps you create and deploy your enterprise data protection (EDP) policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network.
 
 ## In this section
 |Topic |Description |
 |------|------------|
 |[Create an enterprise data protection (EDP) policy using Microsoft Intune](create-edp-policy-using-intune.md) |Intune helps you create and deploy your EDP policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network. |
-|[Create and deploy an enterprise data protection (EDP) policy using System Center Configuration Manager](create-edp-policy-using-sccm.md) |Configuration Manager (version 1511 or later) helps you create and deploy your EDP policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network. |
+|[Create and deploy an enterprise data protection (EDP) policy using System Center Configuration Manager](create-edp-policy-using-sccm.md) |System Center Configuration Manager Technical Preview version 1605 or later helps you create and deploy your EDP policy, including letting you choose your protected apps, your EDP-protection level, and how to find enterprise data on the network. |
  
 
  
diff --git a/windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md b/windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md
new file mode 100644
index 0000000000..2715141f20
--- /dev/null
+++ b/windows/keep-secure/planning-and-getting-started-on-the-device-guard-deployment-process.md
@@ -0,0 +1,56 @@
+---
+title: Planning and getting started on the Device Guard deployment process (Windows 10)
+description: To help you plan and begin the initial test stages of a deployment of Microsoft Device Guard, this article outlines how to gather information, create a plan, and begin to create and test initial code integrity policies. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Planning and getting started on the Device Guard deployment process
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+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**
+
+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). 
+
+2. **Group devices by degree of control needed**. Group devices according to the table in [Device Guard deployment in different scenarios: types of devices](requirements-and-deployment-planning-guidelines-for-device-guard.md#device-guard-deployment-in-different-scenarios-types-of-devices). Do most devices fit neatly into a few categories, or are they scattered across all categories? Are users allowed to install any application or must they choose from a list? Are users allowed to use their own peripheral devices?<br>Deployment is simpler if everything is locked down in the same way, but meeting individual departments’ needs, and working with a wide variety of devices, may require a more complicated and flexible deployment.
+
+3. **Review how much variety in software and hardware is needed by roles or departments**. When several departments all use the same hardware and software, you might need to deploy only one code integrity policy for them. More variety across departments might mean you need to create and manage more code integrity policies. The following questions can help you clarify how many code integrity policies to create:
+    - How standardized is the hardware?<br>This can be relevant because of drivers. You could create a code integrity policy on hardware that uses a particular set of drivers, and if other drivers in your environment use the same signature, they would also be allowed to run. However, you might need to create several code integrity policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
+
+    - Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline code integrity policy.
+        
+    - What software does each department or role need? Should they be able to install and run other departments’ software?<br>If multiple departments are allowed to run the same list of software, you might be able to merge several code integrity policies to simplify management.
+         
+    - Are there departments or roles where unique, restricted software is used?<br>If one department needs to run an application that no other department is allowed, it might require a separate code integrity policy. Similarly, if only one department must run an old version of an application (while other departments allow only the newer version), it might require a separate code integrity policy.
+
+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**
+
+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).
+
+2.  **Create code integrity policies from “golden” computers**. When you have identified departments or roles that use distinctive or partly-distinctive sets of hardware and software, you can set up “golden” computers containing that software and hardware. In this respect, creating and managing code integrity policies to align with the needs of roles or departments can be similar to managing corporate images. From each “golden” computer, you can create a code integrity policy, and decide how to manage that policy. You can merge code integrity policies to create a broader policy or a master policy, or you can manage and deploy each policy individually. For more information, see:
+    - [Deploy code integrity policies: policy rules and file rules](deploy-code-integrity-policies-policy-rules-and-file-rules.md)
+    - [Deploy code integrity policies: steps](deploy-code-integrity-policies-steps.md)<br>
+
+3.  **Audit the code integrity policy and capture information about applications that are outside the policy**. We recommend that you use “audit mode” to carefully test each code integrity policy before you enforce it. With audit mode, no application is blocked—the policy just logs an event whenever an application outside the policy is started. Later, you can expand the policy to allow these applications, as needed. For more information, see [Audit code integrity policies](deploy-code-integrity-policies-steps.md#audit-code-integrity-policies).
+
+4.  **Create a “catalog file” for unsigned LOB applications**. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. For more information, review step 4 **Identify LOB applications that are currently unsigned**, earlier in this list, and see [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md). In later steps, you can merge the catalog file's signature into your code integrity policy, so that applications in the catalog will be allowed by the policy. 
+
+6.  **Capture needed policy information from the event log, and merge information into the existing policy as needed**. After a code integrity policy has been running for a time in audit mode, the event log will contain information about applications that are outside the policy. To expand the policy so that it allows for these applications, use Windows PowerShell commands to capture the needed policy information from the event log, and then merge that information into the existing policy. You can merge code integrity policies from other sources also, for flexibility in how you create your final code integrity policies. For more information, see:
+    - [Create a code integrity policy that captures audit information from the event log](deploy-code-integrity-policies-steps.md#create-a-code-integrity-policy-that-captures-audit-information-from-the-event-log)
+    - [Merge code integrity policies](deploy-code-integrity-policies-steps.md#merge-code-integrity-policies)<br>
+
+7.  **Deploy code integrity policies and catalog files**. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking code integrity policies out of auditing mode. We strongly recommend that you begin this process with a test group of users. This provides a final quality-control validation before you deploy the catalog files and code integrity policies more broadly. For more information, see:
+    - [Enforce code integrity policies](deploy-code-integrity-policies-steps.md#enforce-code-integrity-policies)
+    - [Deploy and manage code integrity policies with Group Policy](deploy-code-integrity-policies-steps.md#deploy-and-manage-code-integrity-policies-with-group-policy)<br>
+
+8.  **Enable desired hardware (VBS) security features**. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by code integrity policies, as 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). For information about enabling VBS features, see [Deploy Device Guard: enable virtualization-based security](deploy-device-guard-enable-virtualization-based-security.md).
+
diff --git a/windows/keep-secure/portal-overview-windows-defender-advanced-threat-protection.md b/windows/keep-secure/portal-overview-windows-defender-advanced-threat-protection.md
index 4eaf0224ec..6363ce613d 100644
--- a/windows/keep-secure/portal-overview-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/portal-overview-windows-defender-advanced-threat-protection.md
@@ -1,7 +1,7 @@
 ---
 title: Windows Defender Advanced Threat Protection portal overview
 description: Use the Windows Defender ATP portal to monitor your enterprise network and assist in responding to alerts to potential advanced persistent threat (APT) activity or data breaches.
-keywords: Windows Defender ATP portal, portal, cybersecurity threat intelligence, dashboard, alerts queue, machines view, preferences setup, client onboarding, advanced attacks
+keywords: Windows Defender ATP portal, portal, cybersecurity threat intelligence, dashboard, alerts queue, machines view, preferences setup, endpoint management, advanced attacks
 search.product: eADQiWindows 10XVcnh
 ms.prod: w10
 ms.mktglfcycl: deploy
@@ -44,12 +44,12 @@ You can navigate through the portal using the menu options available in all sect
 Area | Description
 :---|:---
 (1) Settings | Provides access to configuration settings such as time zone, alert suppression rules, and license information.
-(2) Navigation pane | Use the navigation pane to move between the **Dashboard**, **Alerts queue**, **Machines view**, **Preferences setup**, and **Client onboarding**.
+(2) Navigation pane | Use the navigation pane to move between the **Dashboard**, **Alerts queue**, **Machines view**, **Preferences setup**, and **Endpoint Management**.
 **Dashboard**	| Provides clickable tiles that open detailed information on various alerts that have been detected in your organization.
 **Alerts queue** | Enables you to view separate queues of new, in progress, and resolved alerts.
 **Machines view**| Displays the list of machines that are onboarded to Windows Defender ATP, some information about them, and the corresponding number of alerts.
 **Preferences setup**|	Shows the settings you selected <!--during [service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md),-->and lets you update your industry preferences and retention policy period.
-**Client onboarding**|	Allows you to download the onboarding configuration package.
+**Endpoint Management**|	Allows you to download the onboarding configuration package.
 (3) Main portal| Main area where you will see the different views such as the Dashboard, Alerts queue, and Machines view.
 (4) Search | Search for machines, files, external IP Addresses, or domains across endpoints. The drop-down combo box allows you to select the entity type.
 
diff --git a/windows/keep-secure/protect-enterprise-data-using-edp.md b/windows/keep-secure/protect-enterprise-data-using-edp.md
index e3da331f91..9e052274d5 100644
--- a/windows/keep-secure/protect-enterprise-data-using-edp.md
+++ b/windows/keep-secure/protect-enterprise-data-using-edp.md
@@ -27,7 +27,7 @@ You’ll need this software to run EDP in your enterprise:
 
 |Operating system | Management solution |
 |-----------------|---------------------|
-|Windows 10 Insider Preview | Microsoft Intune<br>-OR-<br>System Center Configuration Manager (version 1511 or later)<br>-OR-<br>Your current company-wide 3rd party mobile device management (MDM) solution. For info about 3rd party MDM solutions, see the documentation that came with your product. If your 3rd party MDM does not have UI support for the policies, refer to the [EnterpriseDataProtection CSP](https://msdn.microsoft.com/en-us/library/windows/hardware/mt697634.aspx) documentation.|
+|Windows 10 Insider Preview | Microsoft Intune<br>-OR-<br>System Center Configuration Manager Technical Preview version 1605 or later<br>-OR-<br>Your current company-wide 3rd party mobile device management (MDM) solution. For info about 3rd party MDM solutions, see the documentation that came with your product. If your 3rd party MDM does not have UI support for the policies, refer to the [EnterpriseDataProtection CSP](https://msdn.microsoft.com/en-us/library/windows/hardware/mt697634.aspx) documentation.|
 
 ## How EDP works
 EDP helps address your everyday challenges in the enterprise. Including:
@@ -60,7 +60,7 @@ EDP gives you a new way to manage data policy enforcement for apps and documents
 
     -   **Copying or downloading enterprise data.** When an employee or an app downloads content from a location like SharePoint, a network share, or an enterprise web location, while using an EDP-protected device, EDP encrypts the data on the device.
 
-    -   **Using protected apps.** Managed apps (apps that you've included on the **Protected Apps** list in your EDP policy) are allowed to access your enterprise data and will interact differently when used with unallowed, non-enterprise aware, or personal-only apps. For example, if EDP management is set to **Block**, your employees can copy and paste from one protected app to another protected app, but not to personal apps. Imagine an HR person wants to copy a job description from a protected app to the internal career website, an enterprise-protected location, but goofs and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that the app couldn’t paste because of a policy restriction. The HR person then correctly pastes to the career website without a problem.
+    - **Using allowed apps.** Managed apps (apps that you've included on the protected apps list in your EDP policy) are allowed to access your enterprise data and will interact differently when used with unallowed, non-enterprise aware, or personal-only apps. For example, if EDP management is set to **Block**, your employees can copy and paste from one protected app to another protected app, but not to personal apps. Imagine an HR person wants to copy a job description from a protected app to the internal career website, an enterprise-protected location, but goofs and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that the app couldn’t paste because of a policy restriction. The HR person then correctly pastes to the career website without a problem.
 
     -   **Managed apps and restrictions.** With EDP you can control which apps can access and use your enterprise data. After adding an app to your **Protected App** list, the app is trusted with enterprise data. All apps that aren’t on this list are blocked from accessing your enterprise network resources and your EDP-protected data.<p>
     You don’t have to modify line-of-business apps that never touch personal data to list them as protected apps; just include them in the **Protected App** list.
@@ -89,13 +89,4 @@ Use the following table to identify the scenarios that require Azure Rights Mana
 ## Next steps
 After deciding to use EDP in your enterprise, you need to:
 
--   [Create an enterprise data protection (EDP) policy](overview-create-edp-policy.md)
-
- 
-
- 
-
-
-
-
-
+-   [Create an enterprise data protection (EDP) policy](overview-create-edp-policy.md)
\ No newline at end of file
diff --git a/windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard.md b/windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard.md
new file mode 100644
index 0000000000..9db41d44f1
--- /dev/null
+++ b/windows/keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard.md
@@ -0,0 +1,124 @@
+---
+title: Requirements and deployment planning guidelines for Device Guard (Windows 10)
+description: To help you plan a deployment of Microsoft Device Guard, this article describes hardware requirements for Device Guard, outlines deployment approaches, and describes methods for code signing and the deployment of code integrity policies. 
+keywords: virtualization, security, malware
+ms.prod: w10
+ms.mktglfcycl: deploy
+author: brianlic-msft
+---
+
+# Requirements and deployment planning guidelines for Device Guard
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This article describes the following:
+
+- [Hardware, firmware, and software requirements for Device Guard](#hardware-firmware-and-software-requirements-for-device-guard)
+    - [Device Guard requirements for baseline protections](#device-guard-requirements-for-baseline-protections)
+    - [Device Guard requirements for improved security](#device-guard-requirements-for-improved-security)
+- [Device Guard deployment in different scenarios: types of devices](#device-guard-deployment-in-different-scenarios-types-of-devices)	
+- [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).
+
+## Hardware, firmware, and software requirements for Device Guard
+
+To deploy Device Guard in a way that uses all of its virtualization-based security (VBS) features, the computers you are protecting must meet certain hardware, firmware, and software requirements. However, computers lacking some of the hardware and firmware requirements will still receive some protection when you deploy code integrity policies—the difference is that those computers will not be as hardened against certain threats. 
+
+For example, hardware that includes CPU virtualization extensions and SLAT will be hardened against malware that attempts to gain access to the kernel, but without protected BIOS options such as “Boot only from internal hard drive,” the computer could be booted (by a malicious person who has physical access) into an operating system on bootable media. For an outline of how VBS-related hardware strengthens the hardening offered by Device Guard, see [Introduction to Device Guard: virtualization-based security and code integrity policies](introduction-to-device-guard-virtualization-based-security-and-code-integrity-policies.md).
+
+You can deploy Device Guard in phases, and plan these phases in relation to the computer purchases you plan for your next hardware refresh.
+
+The following tables provide more information about the hardware, firmware, and software required for deployment of various Device Guard features.
+
+<!-- POTENTIAL FUTURE ADDITION--PUT RIGHT AFTER PREVIOUS SENTENCE: The tables describe baseline protections, plus protections for improved security that are associated with hardware and firmware options available in 2015, available in 2016, and announced as options for 2017. -->
+
+> **Notes**
+> - To understand the requirements in the following tables, you will need to be familiar with the main features in Device Guard: configurable code integrity policies, virtualization-based security (VBS), and Universal Extensible Firmware Interface (UEFI) Secure Boot. For information about these features, 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).
+> - For new computers running Windows 10, Trusted Platform Module (TPM 2.0) must be enabled by default. This requirement is not restated in the tables that follow.
+
+## Device Guard requirements for baseline protections
+
+|Baseline Protections - requirement           | Description                                        |
+|---------------------------------------------|----------------------------------------------------|
+| Hardware: **64-bit CPU**              | A 64-bit computer is required for the Windows hypervisor to provide VBS. |
+| Hardware: **CPU virtualization extensions**,<br>plus **extended page tables** | **Requirements**: These hardware features are required for VBS:<br>One of the following virtualization extensions:<br>- VT-x (Intel) or<br>- AMD-V<br>And:<br>- Extended page tables, also called Second Level Address Translation (SLAT).<br><br>**Security benefits**: VBS provides isolation of secure kernel from normal operating system. Vulnerabilities and Day 0s in normal operating system cannot be exploited because of this isolation. |
+| Firmware: **UEFI firmware version 2.3.1.c or higher with UEFI Secure Boot** | **Requirements**: See the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot)<br><br>**Security benefits**: UEFI Secure Boot helps ensure that the device boots only authorized code. This can prevent boot kits and root kits from installing and persisting across reboots.  |
+| Firmware: **Secure firmware update process**      | **Requirements**: UEFI firmware must support secure firmware update found under the following Windows Hardware Compatibility Program requirement: [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot).<br><br>**Security benefits**: UEFI firmware just like software can have security vulnerabilities that, when found, need to be patched through firmware updates. Patching helps prevent root kits from getting installed. |
+| Software: **HVCI compatible drivers**       | **Requirements**: See the Windows Hardware Compatibility Program requirements under [Filter.Driver.DeviceGuard.DriverCompatibility](https://msdn.microsoft.com/library/windows/hardware/mt589732(v=vs.85).aspx).<br><br>**Security benefits**: [HVCI Compatible](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10/) drivers help ensure that VBS can maintain appropriate memory permissions. This increases resistance to bypassing vulnerable kernel drivers and helps ensure that malware cannot run in kernel. Only code verified through code integrity can run in kernel mode. |
+| Software: Qualified **Windows operating system**  | **Requirement**: Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT<br><br>**Security benefits**: Support for VBS and for management features that simplify configuration of Device Guard. |
+
+<!-- When additional tables are added, change "The following table lists" to "The following tables list" in the Important just below. -->
+
+> **Important**&nbsp;&nbsp;The preceding table lists requirements for baseline protections. The following table lists requirements for improved security. You can use Device Guard with hardware, firmware, and software that support baseline protections, even if they do not support protections for improved security. However, we strongly recommend meeting the requirements for improved security, to significantly strengthen the level of security that Device Guard can provide.
+
+## Device Guard requirements for improved security
+
+The following tables describes additional hardware and firmware requirements, and the improved security that is available when those requirements are met.
+
+### 2015 Additional Qualification Requirements for Device Guard (Windows 10, version 1507 and Windows 10, version 1511)
+
+| Protections for Improved Security - requirement         | Description                                        |
+|---------------------------------------------|----------------------------------------------------|
+| Firmware: **Securing Boot Configuration and Management** | **Requirements**:<br>- BIOS password or stronger authentication must be supported.<br>- In the BIOS configuration, BIOS authentication must be set.<br>- There must be support for protected BIOS option to configure list of permitted boot devices (for example, “Boot only from internal hard drive”) and boot device order, overriding BOOTORDER modification made by operating system.<br>- In the BIOS configuration, BIOS options related to security and boot options (list of permitted boot devices, boot order) must be secured to prevent other operating systems from starting and to prevent changes to the BIOS settings.<br><br>**Security benefits**:<br>- BIOS password or stronger authentication helps ensure that only authenticated Platform BIOS administrators can change BIOS settings. This helps protect against a physically present user with BIOS access.<br>- Boot order when locked provides protection against the computer being booted into WinRE or another operating system on bootable media. |
+
+## Device Guard deployment in different scenarios: types of devices
+
+Typically, deployment of Device Guard happens best in phases, rather than being a feature that you simply “turn on.” The choice and sequence of phases depends on the way various computers and other devices are used in your organization, and to what degree IT manages those devices. The following table can help you begin to develop a plan for deploying Device Guard in your organization.
+
+| **Type of device**                 | **How Device Guard relates to this type of device**  | **Device Guard components that you can use to protect this kind of device**    |
+|------------------------------------|------------------------------------------------------|--------------------------------------------------------------------------------|
+| **Fixed-workload devices**: Perform same tasks every day.<br>Lists of approved applications rarely change.<br>Examples: kiosks, point-of-sale systems, call center computers. | Device Guard can be deployed fully, and deployment and ongoing administration are relatively straightforward.<br>After Device Guard deployment, only approved applications can run. This is because of protections offered by the Hypervisor Code Integrity (HVCI) service. | - VBS (hardware-based) protections, enabled.<br><br>- Code integrity policies in enforced mode, with UMCI enabled. |
+| **Fully managed devices**: Allowed software is restricted by IT department.<br>Users can request additional software, or install from a list of applications provided by IT department.<br>Examples: locked-down, company-owned desktops and laptops. | An initial baseline code integrity policy can be established and enforced. Whenever the IT department approves additional applications, it will update the code integrity policy and (for unsigned LOB applications) the catalog.<br>Code integrity policies are supported by the HVCI service. | - VBS (hardware-based) protections, enabled.<br><br>- Code integrity policies in enforced mode, with UMCI enabled. |
+| **Lightly managed devices**: Company-owned, but users are free to install software.<br>Devices are required to run organization's antivirus solution and client management tools. | Device Guard can be used to help protect the kernel, and to monitor (audit) for problem applications rather than limiting the applications that can be run. | - VBS (hardware-based) protections, enabled. When enabled with a code integrity policy in audit mode only, VBS means the hypervisor helps enforce the default kernel-mode code integrity policy, which protects against unsigned drivers or system files.<br><br>- Code integrity policies, with UMCI enabled, but running in audit mode only. This means applications are not blocked—the policy just logs an event whenever an application outside the policy is started.  |
+| **Bring Your Own Device**: Employees are allowed to bring their own devices, and also use those devices away from work. | Device Guard does not apply. Instead, you can explore other hardening and security features with MDM-based conditional access solutions, such as Microsoft Intune. | N/A | 
+
+## Reviewing your applications: application signing and catalog files 
+
+Typically, code integrity policies are configured to use the application's signing certificate as part or all of what identifies the application as trusted. This means that applications must either use embedded signing—where the signature is part of the binary—or catalog signing, where you generate a “catalog file” from the applications, sign it, and through the signed catalog file, configure the code integrity policy to recognize the applications as signed.
+
+Catalog files can be very useful for unsigned LOB applications that cannot easily be given an embedded signature. However, catalogs need to be updated each time an application is updated. In contrast, with embedded signing, your code integrity policies typically do not have to be updated when an application is updated. For this reason, if code-signing is or can be included in your in-house application development process, it can simplify the management of your code integrity policies (compared to using catalog signing).
+
+To obtain signed applications or embed signatures in your in-house applications, you can choose from a variety of methods:
+
+- Using the Windows Store publishing process. All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
+
+- Using your own digital certificate or public key infrastructure (PKI). ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
+
+- Using a non-Microsoft signing authority. ISV's and enterprises can use a trusted non-Microsoft signing authority to sign all of their own Classic Windows applications.
+
+To use catalog signing, you can choose from the following options:
+
+- Use the Device Guard signing portal available in the Windows Store for Business. The portal is a Microsoft web service that you can use to sign your Classic Windows applications. For more information, see [Device Guard signing](https://technet.microsoft.com/itpro/windows/manage/device-guard-signing-portal).
+
+- Create your own catalog files, which are described in the next section. For information about how creating catalog files fits into Device Guard deployment, see [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md).
+
+### Catalog files
+
+Catalog files (which you can create in Windows 10 with a tool called Package Inspector) contain information about all deployed and executed binary files associated with your trusted but unsigned applications. When you create catalog files, you can also include signed applications for which you do not want to trust the signer but rather the specific application. After creating a catalog, you must sign the catalog file itself by using enterprise public key infrastructure (PKI), or a purchased code signing certificate. Then you can distribute the catalog, so that your trusted applications can be handled by code integrity policies in the same way as any other signed application.
+
+Catalog files are simply Secure Hash Algorithm 2 (SHA2) hash lists of discovered binaries. These binaries’ hash values are updated each time an application is updated, which requires the catalog file to be updated also.
+
+After you have created and signed your catalog files, you can configure your code integrity policies to trust the signer or signing certificate of those files.
+
+> **Note**&nbsp;&nbsp;Package Inspector only works on operating systems that support Device Guard, such as Windows 10 Enterprise, Windows 10 Education, Windows 2016 Server, or Windows Enterprise IoT.
+
+For information about how creating catalog files fits into Device Guard deployment, see [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md). For procedures for working with catalog files, see [Deploy catalog files to support code integrity policies](deploy-catalog-files-to-support-code-integrity-policies.md).
+
+## Code integrity policy formats and signing
+
+When you generate a code integrity policy, you are generating a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on Windows 10 script hosts. You can view your original XML document in a text editor, for example if you want to check the rule options that are present in the **&lt;Rules&gt;** section of the file.
+
+We recommend that you keep the original XML file for use when you need to merge the code integrity policy with another policy or update its rule options. For deployment purposes, the file is converted to a binary format, which can be done using a simple Windows PowerShell command.
+
+When the code integrity policy is deployed, it restricts the software that can run on a device. The XML document can be signed, helping to add additional protection against administrative users changing or removing the policy. 
+
+## Related topics
+
+- [Planning and getting started on the Device Guard deployment process](planning-and-getting-started-on-the-device-guard-deployment-process.md)
+- [Deploy Device Guard: deploy code integrity policies](deploy-device-guard-deploy-code-integrity-policies.md)
+
+
diff --git a/windows/keep-secure/security-identifiers.md b/windows/keep-secure/security-identifiers.md
new file mode 100644
index 0000000000..72f2b8e95b
--- /dev/null
+++ b/windows/keep-secure/security-identifiers.md
@@ -0,0 +1,279 @@
+---
+title: Security identifiers (Windows 10)
+description: Security identifiers
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Security identifiers
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This topic for the IT professional describes security identifiers and how they work in regards to accounts and groups in the Windows operating system.
+
+## What are security identifiers?
+
+A security identifier (SID) is used to uniquely identify a security principal or security group. Security principals can represent any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account.
+
+Each account or group, or process running in the security context of the account, has a unique SID that is issued by an authority, such as a Windows domain controller. It is stored in a security database. The system generates the SID that identifies a particular account or group at the time the account or group is created. When a SID has been used as the unique identifier for a user or group, it can never be used again to identify another user or group.
+
+Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the SIDs for any groups the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
+
+In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and World SIDs identify a group that includes all users. Well-known SIDs have values that remain constant across all operating systems.
+
+SIDs are a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
+
+The content in this topic applies to computers that are running the supported versions of the Windows operating system as designated in the **Applies To** list at the beginning of this topic.
+
+## How security identifiers work
+
+Users refer to accounts by using the account name, but the operating system internally refers to accounts and processes that run in the security context of the account by using their security identifiers (SIDs). For domain accounts, the SID of a security principal is created by concatenating the SID of the domain with a relative identifier (RID) for the account. SIDs are unique within their scope (domain or local), and they are never reused.
+
+The operating system generates a SID that identifies a particular account or group at the time the account or group is created. The SID for a local account or group is generated by the Local Security Authority (LSA) on the computer, and it is stored with other account information in a secure area of the registry. The SID for a domain account or group is generated by the domain security authority, and it is stored as an attribute of the User or Group object in Active Directory Domain Services.
+
+For every local account and group, the SID is unique for the computer where it was created. No two accounts or groups on the computer ever share the same SID. Likewise, for every domain account and group, the SID is unique within an enterprise. This means that the SID for an account or group that is created in one domain will never match the SID for an account or group created in any other domain in the enterprise.
+
+SIDs always remain unique. Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts. For example, if a user with a user account in a Windows domain leaves her job, an administrator deletes her Active Directory account, including the SID that identifies the account. If she later returns to a different job at the same company, an administrator creates a new account, and the Windows Server operating system generates a new SID. The new SID does not match the old one; so none of the user's access from her old account is transferred to the new account. Her two accounts represent two completely different security principals.
+
+## Security identifier architecture
+
+A security identifier is a data structure in binary format that contains a variable number of values. The first values in the structure contain information about the SID structure. The remaining values are arranged in a hierarchy (similar to a telephone number), and they identify the SID-issuing authority (for example, “NT Authority”), the SID-issuing domain, and a particular security principal or group. The following image illustrates the structure of a SID.
+
+![](images/security-identifider-architecture.jpg)
+
+The individual values of a SID are described in the following table.
+
+| Comment | Description |
+| - | - |
+|  Revision | Indicates the version of the SID structure that is used in a particular SID. |
+| Identifier authority | Identifies the highest level of authority that can issue SIDs for a particular type of security principal. For example, the identifier authority value in the SID for the Everyone group is 1 (World Authority). The identifier authority value in the SID for a specific Windows Server account or group is 5 (NT Authority). |
+| Subauthorities | >Holds the most important information in a SID, which is contained in a series of one or more subauthority values. All values up to, but not including, the last value in the series collectively identify a domain in an enterprise. This part of the series is called the domain identifier. The last value in the series, which is called the relative identifier (RID), identifies a particular account or group relative to a domain. |
+
+The components of a SID are easier to visualize when SIDs are converted from a binary to a string format by using standard notation:
+```
+S-R-X-Y1-Y2-Yn-1-Yn
+```
+
+In this notation, the components of a SID are represented as shown in the following table.
+
+| Comment | Description |
+| - | - |
+| S | Indicates that the string is a SID |
+| R | Indicates the revision level |
+| X | Indicates the identifier authority value |
+| Y | Represents a series of subauthority values, where *n* is the number of values |
+
+The SID's most important information is contained in the series of subauthority values. The first part of the series (-Y1-Y2-Y*n*-1) is the domain identifier. This element of the SID becomes significant in an enterprise with several domains, because the domain identifier differentiates SIDs that are issued by one domain from SIDs that are issued by all other domains in the enterprise. No two domains in an enterprise share the same domain identifier.
+
+The last item in the series of subauthority values (-Y*n*) is the relative identifier. It distinguishes one account or group from all other accounts and groups in the domain. No two accounts or groups in any domain share the same relative identifier.
+
+For example, the SID for the built-in Administrators group is represented in standardized SID notation as the following string:
+
+```
+S-1-5-32-544
+```
+
+This SID has four components:
+
+-   A revision level (1)
+
+-   An identifier authority value (5, NT Authority)
+
+-   A domain identifier (32, Builtin)
+
+-   A relative identifier (544, Administrators)
+
+SIDs for built-in accounts and groups always have the same domain identifier value: 32. This value identifies the domain **Builtin**, which exists on every computer that is running a version of the Windows Server operating system. It is never necessary to distinguish one computer's built-in accounts and groups from another computer's built-in accounts and groups because they are local in scope. They are local to a single computer, or in the case of domain controllers for a network domain, they are local to several computers that are acting as one.
+
+Built-in accounts and groups need to be distinguished from one another within the scope of the **Builtin** domain. Therefore, the SID for each account and group has a unique relative identifier. A relative identifier value of 544 is unique to the built-in Administrators group. No other account or group in the **Builtin** domain has a SID with a final value of 544.
+
+In another example, consider the SID for the global group, Domain Admins. Every domain in an enterprise has a Domain Admins group, and the SID for each group is different. The following example represents the SID for the Domain Admins group in the Contoso, Ltd. domain (Contoso\\Domain Admins):
+
+```
+S-1-5-21-1004336348-1177238915-682003330-512
+```
+
+The SID for Contoso\\Domain Admins has:
+
+-   A revision level (1)
+
+-   An identifier authority (5, NT Authority)
+
+-   A domain identifier (21-1004336348-1177238915-682003330, Contoso)
+
+-   A relative identifier (512, Domain Admins)
+
+The SID for Contoso\\Domain Admins is distinguished from the SIDs for other Domain Admins groups in the same enterprise by its domain identifier: 21-1004336348-1177238915-682003330. No other domain in the enterprise uses this value as its domain identifier. The SID for Contoso\\Domain Admins is distinguished from the SIDs for other accounts and groups that are created in the Contoso domain by its relative identifier, 512. No other account or group in the domain has a SID with a final value of 512.
+
+## Relative identifier allocation
+
+When accounts and groups are stored in an account database that is managed by a local Security Accounts Manager (SAM), it is fairly easy for the system to generate a unique relative identifier for each account and in a group that it creates on a stand-alone computer. The SAM on a stand-alone computer can track the relative identifier values that it has used before and make sure that it never uses them again.
+
+In a network domain, however, generating unique relative identifiers is a more complex process. Windows Server network domains can have several domain controllers. Each domain controller stores Active Directory account information. This means that, in a network domain, there are as many copies of the account database as there are domain controllers. In addition to this, every copy of the account database is a master copy. New accounts and groups can be created on any domain controller. Changes that are made to Active Directory on one domain controller are replicated to all other domain controllers in the domain. The process of replicating changes in one master copy of the account database to all other master copies is called a multimaster operation.
+
+The process of generating unique relative identifiers is a single-master operation. One domain controller is assigned the role of relative identifier (RID) master, and it allocates a sequence of relative identifiers to each domain controller in the domain. When a new domain account or group is created in one domain controller's replica of Active Directory, it is assigned a SID. The relative identifier for the new SID is taken from the domain controller's allocation of relative identifiers. When its supply of relative identifiers begins to run low, the domain controller requests another block from the RID master.
+
+Each domain controller uses each value in a block of relative identifiers only once. The RID master allocates each block of relative identifier values only once. This process assures that every account and group created in the domain has a unique relative identifier.
+
+## Security identifiers and globally unique identifiers
+
+When a new domain user or group account is created, Active Directory stores the account's SID in the **ObjectSID** property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that is unique not only in the enterprise, but also across the world. GUIDs are assigned to every object that is created by Active Directory, not only User and Group objects. Each object's GUID is stored in its **ObjectGUID** property.
+
+Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that is published in the global catalog. Searching the global catalog for a User object GUID produces results if the user has an account somewhere in the enterprise. In fact, searching for any object by **ObjectGUID** might be the most reliable way of finding the object you want to locate. The values of other object properties can change, but the **ObjectGUID** property never changes. When an object is assigned a GUID, it keeps that value for life.
+
+If a user moves from one domain to another, the user gets a new SID. The SID for a group object does not change because groups stay in the domain where they were created. However, if people move, their accounts can move with them. If an employee moves from North America to Europe, but stays in the same company, an administrator for the enterprise can move the employee's User object from, for example, Contoso\\NoAm to Contoso\\Europe. If the administrator does this, the User object for the account needs a new SID. The domain identifier portion of a SID that is issued in NoAm is unique to NoAm; so the SID for the user's account in Europe has a different domain identifier. The relative identifier portion of a SID is unique relative to the domain; so if the domain changes, the relative identifier also changes.
+
+When a User object moves from one domain to another, a new SID must be generated for the user account and stored in the **ObjectSID** property. Before the new value is written to the property, the previous value is copied to another property of a User object, **SIDHistory**. This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the **ObjectSID** property, and another value is added to the list of old SIDs in **SIDHistory**. When a user signs in and is successfully authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user, including the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All these SIDs are returned to the authentication client, and they are included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token (including one of the SIDs in **SIDHistory**), can allow or deny the user access.
+
+If you allow or deny users' access to a resource based on their jobs, you should allow or deny access to a group, not to an individual. That way, when users change jobs or move to other departments, you can easily adjust their access by removing them from certain groups and adding them to others.
+
+However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter how many times the user's account domain changes. The **SIDHistory** property makes this possible. When a user changes domains, there is no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID, but not the new one, the old SID is still in the user's access token. It is listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.
+
+## Well-known SIDs
+
+The values of certain SIDs are constant across all systems. They are created when the operating system or domain is installed. They are called well-known SIDs because they identify generic users or generic groups.
+
+There are universal well-known SIDs that are meaningful on all secure systems that use this security model, including operating systems other than Windows. In addition, there are well-known SIDs that are meaningful only on Windows operating systems.
+
+The following table lists the universal well-known SIDs.
+
+| Value | Universal Well-Known SID | Identifies |
+| - | - | - |
+| S-1-0-0 | Null SID | A group with no members. This is often used when a SID value is not known.|
+| S-1-1-0 | World | A group that includes all users. |
+| S-1-2-0 | Local | Users who log on to terminals that are locally (physically) connected to the system. |
+| S-1-2-1 | Console Logon | A group that includes users who are logged on to the physical console. |
+| S-1-3-0 | Creator Owner ID | A security identifier to be replaced by the security identifier of the user who created a new object. This SID is used in inheritable ACEs. |
+| S-1-3-1 | Creator Group ID | A security identifier to be replaced by the primary-group SID of the user who created a new object. Use this SID in inheritable ACEs. |
+| S-1-3-2 | Creator Owner Server | |
+| S-1-3-3 | Creator Group Server | |
+| S-1-3-4 | Owner Rights | A group that represents the current owner of the object. When an ACE that carries this SID is applied to an object, the system ignores the implicit READ_CONTROL and WRITE_DAC permissions for the object owner. |
+| S-1-4 | Non-unique Authority | A SID that represents an identifier authority. |
+| S-1-5 | NT Authority | A SID that represents an identifier authority. |
+| S-1-5-80-0 | All Services | A group that includes all service processes configured on the system. Membership is controlled by the operating system.|
+
+The following table lists the predefined identifier authority constants. The first four values are used with universal well-known SIDs, and the last value is used with well-known SIDs in Windows operating systems designated in the **Applies To** list.
+
+| Identifier Authority | Value | SID String Prefix |
+| - | - | - |
+| SECURITY_NULL_SID_AUTHORITY | 0 | S-1-0 |
+| SECURITY_WORLD_SID_AUTHORITY | 1 | S-1-1 |
+| SECURITY_LOCAL_SID_AUTHORITY | 2 | S-1-2 |
+| SECURITY_CREATOR_SID_AUTHORITY | 3 | S-1-3 |
+
+The following RID values are used with universal well-known SIDs. The Identifier authority column shows the prefix of the identifier authority with which you can combine the RID to create a universal well-known SID.
+
+| Relative Identifier Authority | Value | Identifier Authority |
+| - | - | - |
+| SECURITY_NULL_RID | 0 | S-1-0 |
+| SECURITY_WORLD_RID | 0 | S-1-1 |
+| SECURITY_LOCAL_RID | 0 | S-1-2 |
+| SECURITY_CREATOR_OWNER_RID | 0 | S-1-3 |
+| SECURITY_CREATOR_GROUP_RID | 1 | S-1-3 |
+
+The SECURITY\_NT\_AUTHORITY (S-1-5) predefined identifier authority produces SIDs that are not universal and are meaningful only in installations of the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic. The following table lists the well-known SIDs.
+
+| SID | Display Name | Description |
+| - | - | - |
+| S-1-5-1 | Dialup | A group that includes all users who are logged on to the system by means of a dial-up connection.| 
+| S-1-5-113 | Local account| You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named.|
+| S-1-5-114| Local account and member of Administrators group | You can use this SID when restricting network logon to local accounts instead of "administrator" or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named. |
+| S-1-5-2 | Network | A group that includes all users who are logged on by means of a network connection. Access tokens for interactive users do not contain the Network SID.|
+| S-1-5-3 | Batch | A group that includes all users who have logged on by means of a batch queue facility, such as task scheduler jobs.| 
+| S-1-5-4 | Interactive| A group that includes all users who log on interactively. A user can start an interactive logon session by logging on directly at the keyboard, by opening a Remote Desktop Services connection from a remote computer, or by using a remote shell such as Telnet. In each case, the user's access token contains the Interactive SID. If the user signs in by using a Remote Desktop Services connection, the user's access token also contains the Remote Interactive Logon SID.| 
+| S-1-5-5- *X *- *Y * | Logon Session| The  *X * and  *Y * values for these SIDs uniquely identify a particular logon session.| 
+| S-1-5-6 | Service| A group that includes all security principals that have signed in as a service.|
+| S-1-5-7 | Anonymous Logon| A user who has connected to the computer without supplying a user name and password.<br/>The Anonymous Logon identity is different from the identity that is used by Internet Information Services (IIS) for anonymous web access. IIS uses an actual account—by default, IUSR_ *ComputerName *, for anonymous access to resources on a website. Strictly speaking, such access is not anonymous because the security principal is known even though unidentified people are using the account. IUSR_ *ComputerName * (or whatever you name the account) has a password, and IIS logs on the account when the service starts. As a result, the IIS "anonymous" user is a member of Authenticated Users but Anonymous Logon is not.| 
+| S-1-5-8| Proxy| Does not currently apply: this SID is not used.| 
+| S-1-5-9 | Enterprise Domain Controllers| A group that includes all domain controllers in a forest of domains.|
+| S-1-5-10 | Self| A placeholder in an ACE for a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal that is represented by the object.| 
+| S-1-5-11 | Authenticated Users| A group that includes all users and computers with identities that have been authenticated. Authenticated Users does not include Guest even if the Guest account has a password.<br/>This group includes authenticated security principals from any trusted domain, not only the current domain.|
+| S-1-5-12 | Restricted Code| An identity that is used by a process that is running in a restricted security context. In Windows and Windows Server operating systems, a software restriction policy can assign one of three security levels to code: unrestricted, restricted, or disallowed. When code runs at the restricted security level, the Restricted SID is added to the user's access token.| 
+| S-1-5-13 | Terminal Server User| A group that includes all users who sign in to a server with Remote Desktop Services enabled.| 
+| S-1-5-14 | Remote Interactive Logon| A group that includes all users who log on to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.| 
+| S-1-5-15| This Organization| A group that includes all users from the same organization. Only included with Active Directory accounts and only added by a domain controller.| 
+| S-1-5-17 | IIS_USRS| An account that is used by the default Internet Information Services (IIS) user.| 
+| S-1-5-18 | System (or LocalSystem)| An identity that is used locally by the operating system and by services that are configured to sign in as LocalSystem.<br/>System is a hidden member of Administrators. That is, any process running as System has the SID for the built-in Administrators group in its access token.<br/>When a process that is running locally as System accesses network resources, it does so by using the computer's domain identity. Its access token on the remote computer includes the SID for the local computer's domain account plus SIDs for security groups that the computer is a member of, such as Domain Computers and Authenticated Users.| 
+| S-1-5-19 | NT Authority (LocalService)| An identity that is used by services that are local to the computer, have no need for extensive local access, and do not need authenticated network access. Services that run as LocalService access local resources as ordinary users, and they access network resources as anonymous users. As a result, a service that runs as LocalService has significantly less authority than a service that runs as LocalSystem locally and on the network.| 
+| S-1-5-20 | Network Service| An identity that is used by services that have no need for extensive local access but do need authenticated network access. Services running as NetworkService access local resources as ordinary users and access network resources by using the computer's identity. As a result, a service that runs as NetworkService has the same network access as a service that runs as LocalSystem, but it has significantly reduced local access.| 
+| S-1-5-*domain*-500 | Administrator| A user account for the system administrator. Every computer has a local Administrator account and every domain has a domain Administrator account.<br/>The Administrator account is the first account created during operating system installation. The account cannot be deleted, disabled, or locked out, but it can be renamed.<br/>By default, the Administrator account is a member of the Administrators group, and it cannot be removed from that group.| 
+| S-1-5-*domain*-501 | Guest| A user account for people who do not have individual accounts. Every computer has a local Guest account, and every domain has a domain Guest account.<br/>By default, Guest is a member of the Everyone and the Guests groups. The domain Guest account is also a member of the Domain Guests and Domain Users groups.<br/>Unlike Anonymous Logon, Guest is a real account, and it can be used to log on interactively. The Guest account does not require a password, but it can have one.| 
+| S-1-5-*domain*-502| krbtgt| A user account that is used by the Key Distribution Center (KDC) service. The account exists only on domain controllers.| 
+| S-1-5-*domain*-512| Domain Admins| A global group with members that are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined the domain, including domain controllers.<br/>Domain Admins is the default owner of any object that is created in the domain's Active Directory by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.| 
+| S-1-5-*domain*-513| Domain Users| A global group that includes all users in a domain. When you create a new User object in Active Directory, the user is automatically added to this group.| 
+| S-1-5-*domain*-514| Domain Guests| A global group, which by default, has only one member: the domain's built-in Guest account.| 
+| S-1-5-*domain*-515 | Domain Computers| A global group that includes all computers that have joined the domain, excluding domain controllers.| 
+| S-1-5-*domain*-516| Domain Controllers| A global group that includes all domain controllers in the domain. New domain controllers are added to this group automatically.| 
+| S-1-5-*domain*-517 | Cert Publishers| A global group that includes all computers that host an enterprise certification authority.<br/>Cert Publishers are authorized to publish certificates for User objects in Active Directory.| 
+| S-1-5-*root domain*-518| Schema Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode. The Schema Admins group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.| 
+| S-1-5-*root domain*-519| Enterprise Admins| A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode.<br/>The Enterprise Admins group is authorized to make changes to the forest infrastructure, such as adding child domains, configuring sites, authorizing DHCP servers, and installing enterprise certification authorities.<br/>By default, the only member of Enterprise Admins is the Administrator account for the forest root domain. The group is a default member of every Domain Admins group in the forest. |
+| S-1-5-*domain*-520| Group Policy Creator Owners| A global group that is authorized to create new Group Policy Objects in Active Directory. By default, the only member of the group is Administrator.<br/>Objects that are created by members of Group Policy Creator Owners are owned by the individual user who creates them. In this way, the Group Policy Creator Owners group is unlike other administrative groups (such as Administrators and Domain Admins). Objects that are created by members of these groups are owned by the group rather than by the individual.| 
+| S-1-5-*domain*-553| RAS and IAS Servers| A local domain group. By default, this group has no members. Computers that are running the Routing and Remote Access service are added to the group automatically.<br/>Members of this group have access to certain properties of User objects, such as Read Account Restrictions, Read Logon Information, and Read Remote Access Information.| 
+| S-1-5-32-544 | Administrators| A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.| 
+| Users | S-1-5-32-545| A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group.| 
+| S-1-5-32-546 | Guests| A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.| 
+| S-1-5-32-547 | Power Users| A built-in group. By default, the group has no members. Power users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power users also can install programs; create, manage, and delete local printers; and create and delete file shares. |
+| S-1-5-32-548| Account Operators| A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account Operators have permission to create, modify, and delete accounts for users, groups, and computers in all containers and organizational units of Active Directory except the Builtin container and the Domain Controllers OU. Account Operators do not have permission to modify the Administrators and Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.| 
+| S-1-5-32-549| Server Operators| Description: A built-in group that exists only on domain controllers. By default, the group has no members. Server Operators can log on to a server interactively; create and delete network shares; start and stop services; back up and restore files; format the hard disk of the computer; and shut down the computer.| 
+| S-1-5-32-550 | Print Operators| A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group. Print Operators can manage printers and document queues.| 
+| S-1-5-32-551 | Backup Operators| A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to the computer and shut it down. 
+| S-1-5-32-552 | Replicators | A built-in group that is used by the File Replication service on domain controllers. By default, the group has no members. Do not add users to this group.|
+| S-1-5-64-10| NTLM Authentication| A SID that is used when the NTLM authentication package authenticated the client| 
+| S-1-5-64-14 | SChannel Authentication| A SID that is used when the SChannel authentication package authenticated the client.| 
+| S-1-5-64-21 | Digest Authentication| A SID that is used when the Digest authentication package authenticated the client.| 
+| S-1-5-80 | NT Service | A SID that is used as an NT Service account prefix.| 
+| S-1-5-80-0 | All Services| A group that includes all service processes that are configured on the system. Membership is controlled by the operating system. SID S-1-5-80-0 equals NT SERVICES\ALL SERVICES. This SID was introduced in Windows Server 2008 R2.| 
+| S-1-5-83-0| NT VIRTUAL MACHINE\Virtual Machines| A built-in group. The group is created when the Hyper-V role is installed. Membership in the group is maintained by the Hyper-V Management Service (VMMS). This group requires the **Create Symbolic Links** right (SeCreateSymbolicLinkPrivilege), and also the **Log on as a Service** right (SeServiceLogonRight). | 
+| S-1-16-0| Untrusted Mandatory Level| A SID that represents an untrusted integrity level.| 
+| S-1-16-4096 | Low Mandatory Level| A SID that represents a low integrity level.| 
+| S-1-16-8192 | Medium Mandatory Level| This SID represents a medium integrity level.| 
+| S-1-16-8448 | Medium Plus Mandatory Level| A SID that represents a medium plus integrity level.| 
+| S-1-16-12288 | High Mandatory Level| A SID that represents a high integrity level.| 
+| S-1-16-16384 | System Mandatory Level| A SID that represents a system integrity level.| 
+| S-1-16-20480 | Protected Process Mandatory Level| A SID that represents a protected-process integrity level.| 
+| S-1-16-28672 | Secure Process Mandatory Level| A SID that represents a secure process integrity level.| 
+
+The following RIDs are relative to each domain.
+
+| RID | Identifies |
+| - | - |
+| DOMAIN_USER_RID_ADMIN | The administrative user account in a domain. |
+| DOMAIN_USER_RID_GUEST| The guest-user account in a domain. Users who do not have an account can automatically sign in to this account.| 
+| DOMAIN_GROUP_RID_USERS | A group that contains all user accounts in a domain. All users are automatically added to this group.| 
+| DOMAIN_GROUP_RID_GUESTS | The group Guest account in a domain.| 
+| DOMAIN_GROUP_RID_COMPUTERS | The Domain Computer group. All computers in the domain are members of this group.| 
+| DOMAIN_GROUP_RID_CONTROLLERS | The Domain Controller group. All domain controllers in the domain are members of this group.| 
+| DOMAIN_GROUP_RID_CERT_ADMINS | The certificate publishers' group. Computers running Active Directory Certificate Services are members of this group.| 
+| DOMAIN_GROUP_RID_SCHEMA_ADMINS | The schema administrators' group. Members of this group can modify the Active Directory schema.| 
+| DOMAIN_GROUP_RID_ENTERPRISE_ADMINS | The enterprise administrators' group. Members of this group have full access to all domains in the Active Directory forest. Enterprise administrators are responsible for forest-level operations such as adding or removing new domains.| 
+| DOMAIN_GROUP_RID_POLICY_ADMINS| The policy administrators' group.| 
+
+The following table provides examples of domain-relative RIDs that are used to form well-known SIDs for local groups.
+
+
+| RID | Identifies |
+| - | - |
+| DOMAIN_ALIAS_RID_ADMINS | Administrators of the domain.| 
+| DOMAIN_ALIAS_RID_USERS | All users in the domain.| 
+| DOMAIN_ALIAS_RID_GUESTS | Guests of the domain.| 
+| DOMAIN_ALIAS_RID_POWER_USERS | A user or a set of users who expect to treat a system as if it were their personal computer rather than as a workstation for multiple users.| 
+| DOMAIN_ALIAS_RID_BACKUP_OPS | A local group that is used to control the assignment of file backup-and-restore user rights.| 
+| DOMAIN_ALIAS_RID_REPLICATOR | A local group that is responsible for copying security databases from the primary domain controller to the backup domain controllers. These accounts are used only by the system.| 
+| DOMAIN_ALIAS_RID_RAS_SERVERS | A local group that represents remote access and servers running Internet Authentication Service (IAS). This group permits access to various attributes of User objects.| 
+
+## Changes in security identifier's functionality
+
+The following table describes changes in SID implementation in the Windows operating systems that are designated in the list.
+
+| Change | Operating system version | Description and resources |
+| - | - | - |
+| Most of the operating system files are owned by the TrustedInstaller security identifier (SID)| Windows Server 2008, Windows Vista| The purpose of this change is to prevent a process that is running as an administrator or under the LocalSystem account from automatically replacing the operating system files. |
+| Restricted SID checks are implemented| Windows Server 2008, Windows Vista| When restricting SIDs are present, Windows performs two access checks. The first is the normal access check, and the second is the same access check against the restricting SIDs in the token. Both access checks must pass to allow the process to access the object. |
+
+## See also
+
+- [Access Control Overview](access-control.md)
diff --git a/windows/keep-secure/security-principals.md b/windows/keep-secure/security-principals.md
new file mode 100644
index 0000000000..8bf4f7abd7
--- /dev/null
+++ b/windows/keep-secure/security-principals.md
@@ -0,0 +1,143 @@
+---
+title: Security Principals (Windows 10)
+description: Security Principals
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Security Principals
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This reference topic for the IT professional describes security principals in regards to Windows accounts and security groups, in addition to security technologies that are related to security principals.
+
+## <a href="" id="w2k3tr-princ-what"></a>What are security principals?
+
+
+Security principals are any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account, or the security groups for these accounts. Security principals have long been a foundation for controlling access to securable resources on Windows computers. Each security principal is represented in the operating system by a unique security identifier (SID).
+
+The following content applies to the versions of Windows that are designated in the **Applies To** list at the beginning of this topic.
+
+## How security principals work
+
+
+Security principals that are created in an Active Directory domain are Active Directory objects, which can be used to manage access to domain resources. Each security principal is assigned a unique identifier, which it retains for its entire lifetime. Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are managed by the Security Accounts Manager (SAM) on the local computer.
+
+### <a href="" id="bkmk-authzandac"></a>Authorization and access control components
+
+The following diagram illustrates the Windows authorization and access control process. In this diagram, the subject (a process that is initiated by a user) attempts to access an object, such as a shared folder. The information in the user’s access token is compared to the access control entries (ACEs) in the object’s security descriptor, and the access decision is made. The SIDs of security principals are used in the user’s access token and in the ACEs in the object’s security descriptor.
+
+**Authorization and access control process**
+
+![authorization and access control process](images/authorizationandaccesscontrolprocess.gif)
+
+Security principals are closely related to the following components and technologies:
+
+-   [Security identifiers](#bkmk-sids)
+
+-   [Access tokens](#bkmk-accesstokens)
+
+-   [Security descriptors and access control lists](#bkmk-sdandacls)
+
+-   [Permissions](#bkmk-permissions)
+
+### <a href="" id="bkmk-sids"></a>Security identifiers
+
+Security identifiers (SIDs) provide a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
+
+A SID is a value of variable length that is used to uniquely identify a security principal that represents any entity that can be authenticated by the system. These entities include a user account, a computer account, or a thread or process that runs in the security context of a user or computer account. Each security principal is automatically assigned a SID when it is created. The SID is stored in a security database. When a SID is used as the unique identifier for a user or group, it can never be used to identify another user or group.
+
+Each time a user signs in, the system creates an access token for that user. The access token contains the user’s SID, user rights, and the SIDs for groups that the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
+
+In addition to the uniquely created, domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and the World SIDs identify groups that includes all users. Well-known SIDs have values that remain constant across all operating systems.
+
+### <a href="" id="bkmk-accesstokens"></a>Access tokens
+
+An access token is a protected object that contains information about the identity and user rights that are associated with a user account.
+
+When a user signs in interactively or tries to make a network connection to a computer running Windows, the sign-in process authenticates the user’s credentials. If authentication is successful, the process returns a SID for the user and a list of SIDs for the user’s security groups. The Local Security Authority (LSA) on the computer uses this information to create an access token (in this case, the primary access token). This includes the SIDs that are returned by the sign-in process and a list of user rights that are assigned by the local security policy to the user and to the user’s security groups.
+
+After the LSA creates the primary access token, a copy of the access token is attached to every thread and process that executes on the user’s behalf. Whenever a thread or process interacts with a securable object or tries to perform a system task that requires user rights, the operating system checks the access token that is associated with the thread to determine the level of authorization.
+
+There are two kinds of access tokens, primary and impersonation. Every process has a primary token that describes the security context of the user account that is associated with the process. A primary access token is typically assigned to a process to represent the default security information for that process. Impersonation tokens, on the other hand, are usually used for client and server scenarios. Impersonation tokens enable a thread to run in a security context that differs from the security context of the process that owns the thread.
+
+### <a href="" id="bkmk-sdandacls"></a>Security descriptors and access control lists
+
+A security descriptor is a data structure that is associated with each securable object. All objects in Active Directory and all securable objects on a local computer or on the network have security descriptors to help control access to the objects. Security descriptors include information about who owns an object, who can access it and in what way, and what types of access are audited. Security descriptors contain the access control list (ACL) of an object, which includes all of the security permissions that apply to that object. An object’s security descriptor can contain two types of ACLs:
+
+-   A discretionary access control list (DACL), which identifies the users and groups who are allowed or denied access
+
+-   A system access control list (SACL), which controls how access is audited
+
+You can use this access control model to individually secure objects and attributes such as files and folders, Active Directory objects, registry keys, printers, devices, ports, services, processes, and threads. Because of this individual control, you can adjust the security of objects to meet the needs of your organization, delegate authority over objects or attributes, and create custom objects or attributes that require unique security protections to be defined.
+
+### <a href="" id="bkmk-permissions"></a>Permissions
+
+Permissions enable the owner of each securable object, such as a file, Active Directory object, or registry key, to control who can perform an operation or a set of operations on the object or object property. Permissions are expressed in the security architecture as access control entries (ACEs). Because access to an object is at the discretion of the object’s owner, the type of access control that is used in Windows is called discretionary access control.
+
+Permissions are different from user rights in that permissions are attached to objects, and user rights apply to user accounts. Administrators can assign user rights to groups or users. These rights authorize users to perform specific actions, such as signing in to a system interactively or backing up files and directories.
+
+On computers, user rights enable administrators to control who has the authority to perform operations that affect an entire computer, rather than a particular object. Administrators assign user rights to individual users or groups as part of the security settings for the computer. Although user rights can be managed centrally through Group Policy, they are applied locally. Users can (and usually do) have different user rights on different computers.
+
+For information about which user rights are available and how they can be implemented, see [User Rights Assignment](user-rights-assignment.md).
+
+### <a href="" id="bkmk-authn"></a> Security context in authentication
+
+A user account enables a user to sign in to computers, networks, and domains with an identity that can be authenticated by the computer, network, or domain.
+
+In Windows, any user, service, group, or computer that can initiate action is a security principal. Security principals have accounts, which can be local to a computer or domain-based. For example, domain-joined Windows client computers can participate in a network domain by communicating with a domain controller, even when no user is signed in.
+
+To initiate communications, the computer must have an active account in the domain. Before accepting communications from the computer, the Local Security Authority on the domain controller authenticates the computer’s identity and then defines the computer’s security context just as it would for a user’s security principal.
+
+This security context defines the identity and capabilities of a user or service on a particular computer, or of a user, service, group or computer on a network. For example, it defines the resources (such as a file share or printer) that can be accessed and the actions (such as Read, Write, or Modify) that can be performed by a user, service, or computer on that resource.
+
+The security context of a user or computer can vary from one computer to another, such as when a user authenticates to a server or a workstation other than the user’s primary workstation. It can also vary from one session to another, such as when an administrator modifies the user’s rights and permissions. In addition, the security context is usually different when a user or computer is operating on a stand-alone basis, in a mixed network domain, or as part of an Active Directory domain.
+
+## <a href="" id="w2k3tr-princ-what-vblj"></a>Accounts and security groups
+
+
+Accounts and security groups that are created in an Active Directory domain are stored in the Active Directory database and managed by using Active Directory tools. These security principals are directory objects, and they can be used to manage access to domain resources.
+
+Local user accounts and security groups are created on a local computer, and they can be used to manage access to resources on that computer. Local user accounts and security groups are stored in and managed by the Security Accounts Manager (SAM) on the local computer.
+
+### User accounts
+
+A user account uniquely identifies a person who is using a computer system. The account signals the system to enforce the appropriate authorization to allow or deny that user access to resources. User accounts can be created in Active Directory and on local computers, and administrators use them to:
+
+-   Represent, identify, and authenticate the identity of a user. A user account enables a user to sign in to computers, networks, and domains with a unique identifier that can be authenticated by the computer, network, or domain.
+
+-   Authorize (grant or deny) access to resources. After a user has been authenticated, the user is authorized access to resources based on the permissions that are assigned to that user for the resource.
+
+-   Audit the actions that are carried out on a user account.
+
+Windows and the Windows Server operating systems have built-in user accounts, or you can create user accounts to meet the requirements of your organization.
+
+### Security groups
+
+A security group is a collection of user accounts, computer accounts, and other groups of accounts that can be managed as a single unit from a security perspective. In Windows operating systems, there are several built-in security groups that are preconfigured with the appropriate rights and permissions for performing specific tasks. Additionally, you can (and, typically, will) create a security group for each unique combination of security requirements that applies to multiple users in your organization.
+
+Groups can be Active Directory-based or local to a particular computer:
+
+-   Active Directory security groups are used to manage rights and permissions to domain resources.
+
+-   Local groups exist in the SAM database on local computers (on all Windows-based computers) except domain controllers. You use local groups to manage rights and permissions only to resources on the local computer.
+
+By using security groups to manage access control, you can:
+
+-   Simplify administration. You can assign a common set of rights, a common set of permissions, or both to many accounts at one time, rather than assigning them to each account individually. Also, when users transfer jobs or leave the organization, permissions are not tied to their user accounts, making permission reassignment or removal easier.
+
+-   Implement a role-based access-control model. You can use this model to grant permissions by using groups with different scopes for appropriate purposes. Scopes that are available in Windows include local, global, domain local, and universal.
+
+-   Minimize the size of access control lists (ACLs) and speed security checking. A security group has its own SID; therefore, the group SID can be used to specify permissions for a resource. In an environment with more than a few thousand users, if the SIDs of individual user accounts are used to specify access to a resource, the ACL of that resource can become unmanageably large, and the time that is needed for the system to check permissions to the resource can become unacceptable.
+
+For descriptions and settings information about the domain security groups that are defined in Active Directory, see [Active Directory Security Groups](active-directory-security-groups.md).
+
+For descriptions and settings information about the Special Identities group, see [Special Identities](special-identities.md).
+
+## See also
+
+- [Access Control Overview](access-control.md)
\ No newline at end of file
diff --git a/windows/keep-secure/security-technologies.md b/windows/keep-secure/security-technologies.md
index 19a6af38ba..8bd5183126 100644
--- a/windows/keep-secure/security-technologies.md
+++ b/windows/keep-secure/security-technologies.md
@@ -15,6 +15,7 @@ Learn more about the different security technologies that are available in Windo
 
 | Topic | Description |
 |-|-|
+| [Access control](access-control.md) | Describes access control in Windows, which is the process of authorizing users, groups, and computers to access objects on the network or computer. Key concepts that make up access control are permissions, ownership of objects, inheritance of permissions, user rights, and object auditing. |
 | [AppLocker](applocker-overview.md)| This topic provides a description of AppLocker and can help you decide if your organization can benefit from deploying AppLocker application control policies. AppLocker helps you control which apps and files users can run. These include executable files, scripts, Windows Installer files, dynamic-link libraries (DLLs), packaged apps, and packaged app installers.|
 | [BitLocker](bitlocker-overview.md)| This topic provides a high-level overview of BitLocker, including a list of system requirements, practical applications, and deprecated features.|
 | [Encrypted Hard Drive](encrypted-hard-drive.md) | Encrypted Hard Drive uses the rapid encryption that is provided by BitLocker Drive Encryption to enhance data security and management.|
diff --git a/windows/keep-secure/service-accounts.md b/windows/keep-secure/service-accounts.md
new file mode 100644
index 0000000000..e326562c98
--- /dev/null
+++ b/windows/keep-secure/service-accounts.md
@@ -0,0 +1,109 @@
+---
+title: Service Accounts (Windows 10)
+description: Service Accounts
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Service Accounts
+
+**Applies to**
+-   Windows 10
+-   Windows Server 2016
+
+This topic for the IT professional explains group and standalone managed service accounts, and the computer-specific virtual computer account, and it points to resources about these service accounts.
+
+## Overview
+
+
+A service account is a user account that is created explicitly to provide a security context for services running on Windows Server operating systems. The security context determines the service's ability to access local and network resources. The Windows operating systems rely on services to run various features. These services can be configured through the applications, the Services snap-in, or Task Manager, or by using Windows PowerShell.
+
+This topic contains information about the following types of service accounts:
+
+-   [Standalone managed service accounts](#bkmk-standalonemanagedserviceaccounts)
+
+-   [Group managed service accounts](#bkmk-groupmanagedserviceaccounts)
+
+-   [Virtual accounts](#bkmk-virtualserviceaccounts)
+
+### <a href="" id="bkmk-standalonemanagedserviceaccounts"></a>Standalone managed service accounts
+
+A managed service account is designed to isolate domain accounts in crucial applications, such as Internet Information Services (IIS), and eliminate the need for an administrator to manually administer the service principal name (SPN) and credentials for the accounts.
+
+To use managed service accounts, the server on which the application or service is installed must be running at least Windows Server 2008 R2. One managed service account can be used for services on a single computer. Managed service accounts cannot be shared between multiple computers, and they cannot be used in server clusters where a service is replicated on multiple cluster nodes. For this scenario, you must use a group managed service account. For more information, see [Group Managed Service Accounts Overview](https://technet.microsoft.com/library/hh831782(v=ws.11).aspx).
+
+In addition to the enhanced security that is provided by having individual accounts for critical services, there are four important administrative benefits associated with managed service accounts:
+
+-   You can create a class of domain accounts that can be used to manage and maintain services on local computers.
+
+-   Unlike domain accounts in which administrators must reset manually passwords, the network passwords for these accounts are automatically reset.
+
+-   You do not have to complete complex SPN management tasks to use managed service accounts.
+
+-   Administrative tasks for managed service accounts can be delegated to non-administrators.
+
+### Software requirements
+
+Managed service accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
+
+### <a href="" id="bkmk-groupmanagedserviceaccounts"></a>Group managed service accounts
+
+Group managed service accounts are an extension of the standalone managed service accounts, which were introduced in Windows Server 2008 R2. These are managed domain accounts that provide automatic password management and simplified service principal name (SPN) management, including delegation of management to other administrators.
+
+The group managed service account provides the same functionality as a standalone managed service account within the domain, but it extends that functionality over multiple servers. When connecting to a service that is hosted on a server farm, such as Network Load Balancing, the authentication protocols that support mutual authentication require all instances of the services to use the same principal. When group managed service accounts are used as service principals, the Windows Server operating system manages the password for the account instead of relying on the administrator to manage the password.
+
+The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. This service was introduced in Windows Server 2012, and it does not run on previous versions of the Windows Server operating system. The Key Distribution Service shares a secret, which is used to create keys for the account. These keys are periodically changed. For a group managed service account, the domain controller computes the password on the key that is provided by the Key Distribution Services, in addition to other attributes of the group managed service account.
+
+### <a href="" id="bkmk-app"></a>Practical applications
+
+Group managed service accounts provide a single identity solution for services running on a server farm, or on systems that use Network Load Balancing. By providing a group managed service account solution, services can be configured for the group managed service account principal, and the password management is handled by the operating system.
+
+By using a group managed service account, services or service administrators do not need to manage password synchronization between service instances. The group managed service account supports hosts that are kept offline for an extended time period and the management of member hosts for all instances of a service. This means that you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.
+
+Failover clusters do not support group managed service account s. However, services that run on top of the Cluster service can use a group managed service account or a standalone managed service account if they are a Windows service, an App pool, a scheduled task, or if they natively support group managed service account or standalone managed service accounts.
+
+### <a href="" id="bkmk-soft"></a>Software requirements
+
+Group managed service accounts can only be configured and administered on computers running at least Windows Server 2012, but they can be deployed as a single service identity solution in domains that still have domain controllers running operating systems earlier than Windows Server 2012. There are no domain or forest functional level requirements.
+
+A 64-bit architecture is required to run the Windows PowerShell commands that are used to administer group managed service accounts.
+
+A managed service account is dependent on encryption types supported by Kerberos. When a client computer authenticates to a server by using Kerberos protocol, the domain controller creates a Kerberos service ticket that is protected with encryption that the domain controller and the server support. The domain controller uses the account’s **msDS-SupportedEncryptionTypes** attribute to determine what encryption the server supports, and if there is no attribute, it assumes that the client computer does not support stronger encryption types. The Advanced Encryption Standard (AES) should always be explicitly configured for managed service accounts. If computers that host the managed service account are configured to not support RC4, authentication will always fail.
+
+**Note**  
+Introduced in Windows Server 2008 R2, the Data Encryption Standard (DES) is disabled by default. For more information about supported encryption types, see [Changes in Kerberos Authentication](http://technet.microsoft.com/library/dd560670(WS.10).aspx).
+
+ 
+
+Group managed service accounts are not applicable in Windows operating systems prior to Windows Server 2012.
+
+### <a href="" id="bkmk-virtualserviceaccounts"></a>Virtual accounts
+
+Virtual accounts were introduced in Windows Server 2008 R2 and Windows 7, and are managed local accounts that provide the following features to simplify service administration:
+
+-   The virtual account is automatically managed.
+
+-   The virtual account can access the network in a domain environment.
+
+-   No password management is required. For example, if the default value is used for the service accounts during SQL Server setup on Windows Server 2008 R2, a virtual account that uses the instance name as the service name is established in the format NT SERVICE\\&lt;SERVICENAME&gt;.
+
+Services that run as virtual accounts access network resources by using the credentials of the computer account in the format &lt;domain\_name&gt;\\&lt;computer\_name&gt;$.
+
+For information about how to configure and use virtual service accounts, see [Service Accounts Step-by-Step Guide](http://technet.microsoft.com/library/dd548356.aspx).
+
+### Software requirements
+
+Virtual accounts apply to the Windows operating systems that are designated in the **Applies To** list at the beginning of this topic.
+
+## <a href="" id="bkmk-links"></a>See also
+
+
+The following table provides links to additional resources that are related to standalone managed service accounts, group managed service accounts, and virtual accounts.
+
+| Content type  | References  |
+|---------------|-------------|
+| **Product evaluation** | [What's New for Managed Service Accounts](https://technet.microsoft.com/library/hh831451(v=ws.11).aspx)<br>[Getting Started with Group Managed Service Accounts](https://technet.microsoft.com/library/jj128431(v=ws.11).aspx) |
+| **Deployment** | [Windows Server 2012: Group Managed Service Accounts - Ask Premier Field Engineering (PFE) Platforms - Site Home - TechNet Blogs](http://blogs.technet.com/b/askpfeplat/archive/2012/12/17/windows-server-2012-group-managed-service-accounts.aspx) |
+| **Related technologies** | [Security Principals](security-principals.md)<br>[What's new in Active Directory Domain Services](https://technet.microsoft.com/library/mt163897.aspx) |
\ No newline at end of file
diff --git a/windows/keep-secure/service-onboarding-windows-defender-advanced-threat-protection.md b/windows/keep-secure/service-onboarding-windows-defender-advanced-threat-protection.md
deleted file mode 100644
index fb5e5d5cbf..0000000000
--- a/windows/keep-secure/service-onboarding-windows-defender-advanced-threat-protection.md
+++ /dev/null
@@ -1,121 +0,0 @@
----
-title: Windows Defender ATP service onboarding
-description: Assign users to the Windows Defender ATP service application in Azure Active Directory to grant access to the portal.
-keywords: service onboarding, Windows Defender Advanced Threat Protection service onboarding, manage users,
-search.product: eADQiWindows 10XVcnh
-ms.prod: w10
-ms.mktglfcycl: deploy
-ms.sitesec: library
-ms.pagetype: security
-author: mjcaparas
----
-
-# Windows Defender ATP service onboarding
-
-**Applies to:**
-
-- Windows 10 Insider Preview Build 14332 or later
-- Azure Active Directory
-- Windows Defender Advanced Threat Protection (Windows Defender ATP)
-
-<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
-
-You have to assign users to the Windows Defender ATP Service application in Azure Active Directory (AAD) before they can access the portal.
-
-**Manage user access to the Windows Defender ATP portal**:
-
-1.  When you first go to the [Windows Defender ATP portal](https://securitycenter.windows.com/) and your directory does not
-    have users assigned to the Windows ATP Service application, you will
-    be directed to open the [Microsoft Azure Dashboard](https://portal.azure.com) to manage user access.
-
-    > **Note**&nbsp;&nbsp;In AAD, a directory is essentially a tenant. See the [Azure AD documentation](https://msdn.microsoft.com/en-us/library/azure/jj573650.aspx) for more information on how tenants work with AAD.
-
-2.  Ensure you have logged in to Microsoft Azure with an account that
-    has permissions to assign users to an application in AAD. You might
-    need to sign out of Microsoft Azure and then sign back in again if
-    you used a different account to sign in to the Windows Defender ATP
-    portal:
-
-    a.  On the top menu, click the signed-in user’s name.
-
-    b.  Click **Sign out**.
-
-    ![Azure sign out](images/azure-signout.png)
-
-    c.	Go the [Microsoft Azure Dashboard](https://portal.azure.com) again where you will be asked to sign in.
-
-    d.	Sign in with the correct user name and password for an account that has permissions to assign users in AAD.
-
-3. On the **Microsoft Azure Dashboard**, click **Browse** in the navigation pane and then click **Active Directory** to open the [Azure Management Portal](https://manage.windowsazure.com/).
-
-    ![Azure Active Directory menu](images/azure-browse.png)
-
-4. You might need to open the **Directory** section of the [Azure Management Portal](https://manage.windowsazure.com/) so you can access your directory. There are two ways you can do this:
-
-    a.  Click the arrow icon above the list of directories to see the full list of directories in the main area of the portal.
-
-    ![Azure organization menu](images/azure-org-directory.png)
-
-    b. Scroll down in the navigation pane and click **Active Directory**.
-
-    ![Azure active directory](images/azure-active-directory.png)
-
-5. Click the directory that contains the Windows Defender ATP application. In the following example, the directory is
-    called **Contoso**.
-
-     ![Azure active directory list](images/azure-active-directory-list.png)
-
-    > **Note**&nbsp;&nbsp;You can also access your directory by going straight to the [Azure Management Portal](https://manage.windowsazure.com/), clicking Active Directory and then finding your directory in the list.
-
-6. Click **Applications** from the top menu bar.
-
-    ![Example organization in Azure Active Directory](images/contoso.png)
-
-7. Click the **Windows ATP Service** application. The dashboard for the application is shown.
-
-    ![Example selected organization in Azure Active Directory](images/contoso-application.png)
-
-    > **Note**&nbsp;&nbsp;The application might have a slightly different name than the one shown here. It might be called **Windows Defender ATP Service**.
-
-8. Click **Users** from the top menu bar. A list of users that are in the directory is displayed.
-
-    ![Example windows atp service users](images/windows-atp-service.png)
-
-    ![Example user assignment to the windows atp service](images/assign-users.png)
-
-    > **Note**&nbsp;&nbsp;If you do not normally work with AAD, you might not see any users in the directory, or we might have created a test tenant specifically for a single user’s account. See the [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md) section for instructions on adding users to a directory.
-
-9. Select the user you want manage.
-
-10. Click **Assign**.
-
-11. Confirm that you want to enable access for the user from the notification bar. If you click **Yes**, the user is given access to the Windows Defender ATP portal.  One or more progress bars will appear that indicates the user is being assigned a role, and you will see confirmation messages. You don’t need to do anything with the messages, they will go away after a short period of time.
-
-    ![Confirmation page to enable access to users](images/confirm-user-access.png)
-
-12. To remove the user's access, click **Remove**.
-
-13. Select the **Disable access to this app for the selected users** checkbox, and then click **Complete** ![Complete icon](images/check-icon.png). One or more progress bars will appear, followed by confirmation messages. The messages will disappear after a short period.
-
-    ![Remove menu](images/remove-menu.png)
-
-14. To remove the access for all users, click **Manage access**. If you click **Complete** ![Complete icon](images/check-icon.png), you will not see the Windows ATP Service in the list of applications in your directory.
-
-    > **Note**&nbsp;&nbsp;If you want to give access to users again, see the Manage access for all users in Azure Active Directory topic in [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md).
-
-15. You can continue assigning roles for other users in your organization now, or you can return to the Windows Defender ATP portal to complete the service onboarding wizard.
-
-    > **Note**&nbsp;&nbsp;You need to assign roles for every user in your organization that requires access to the Windows Defender ATP portal. You can assign roles at any time by going to the Azure Management Portal, clicking **Active Directory**, and then finding your directory in the list and following the steps above.
-
-When you have finished assigning roles, return to the [Windows Defender ATP portal](https://securitycenter.windows.com) and refresh the
-page.
-
-Follow the steps in the onboarding wizard to complete the onboarding process.
-
-At the end of the wizard, you can download the Group Policy configuration package which you will use to configure endpoints on your network. You can also download the package from the **Client onboarding** menu on the portal after you have completed the onboarding wizard.
-
-## Related topics
-- [Configure Windows Defender ATP endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md)
-- [Monitor the Windows Defender ATP onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md)
-- [Additional Windows Defender ATP configuration settings](additional-configuration-windows-defender-advanced-threat-protection.md)
-- [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](troubleshoot-onboarding-windows-defender-advanced-threat-protection.md)
diff --git a/windows/keep-secure/special-identities.md b/windows/keep-secure/special-identities.md
new file mode 100644
index 0000000000..2e3aa71e3e
--- /dev/null
+++ b/windows/keep-secure/special-identities.md
@@ -0,0 +1,1011 @@
+---
+title: Special Identities (Windows 10)
+description: Special Identities
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+---
+
+# Special Identities
+
+**Applies to**
+-   Windows Server 2016
+
+This reference topic for the IT professional describes the special identity groups (which are sometimes referred to as security groups) that are used in Windows access control.
+
+Special identity groups are similar to Active Directory security groups as listed in the users and built-in containers. Special identity groups can provide an efficient way to assign access to resources in your network. By using special identity groups, you can:
+
+-   Assign user rights to security groups in Active Directory.
+
+-   Assign permissions to security groups for the purpose of accessing resources.
+
+Servers that are running the supported Windows Server operating systems designated in the **Applies To** list at the beginning of this topic include several special identity groups. These special identity groups do not have specific memberships that can be modified, but they can represent different users at different times, depending on the circumstances.
+
+Although the special identity groups can be assigned rights and permissions to resources, the memberships cannot be modified or viewed. Group scopes do not apply to special identity groups. Users are automatically assigned to these special identity groups whenever they sign in or access a particular resource.
+
+For information about security groups and group scope, see [Active Directory Security Groups](active-directory-security-groups.md).
+
+The special identity groups are described in the following tables.
+
+-   [Anonymous Logon](#bkmk-anonymouslogon)
+
+-   [Authenticated User](#bkmk-authenticateduser)
+
+-   [Batch](#bkmk-batch)
+
+-   [Creator Group](#bkmk-creatorgroup)
+
+-   [Creator Owner](#bkmk-creatorowner)
+
+-   [Dialup](#bkmk-dialup)
+
+-   [Digest Authentication](#bkmk-digestauth)
+
+-   [Enterprise Domain Controllers](#bkmk-entdcs)
+
+-   [Everyone](#bkmk-everyone)
+
+-   [Interactive](#bkmk-interactive)
+
+-   [Local Service](#bkmk-localservice)
+
+-   [LocalSystem](#bkmk-localsystem)
+
+-   [Network](#bkmk-network)
+
+-   [Network Service](#bkmk-networkservice)
+
+-   [NTLM Authentication](#bkmk-ntlmauth)
+
+-   [Other Organization](#bkmk-otherorganization)
+
+-   [Principal Self](#bkmk-principalself)
+
+-   [Remote Interactive Logon](#bkmk-remoteinteractivelogon)
+
+-   [Restricted](#bkmk-restrictedcode)
+
+-   [SChannel Authentication](#bkmk-schannelauth)
+
+-   [Service](#bkmk-service)
+
+-   [Terminal Server User](#bkmk-terminalserveruser)
+
+-   [This Organization](#bkmk-thisorg)
+
+-   [Window Manager\\Window Manager Group](#bkmk-windowmanager)
+
+## <a href="" id="bkmk-anonymouslogon"></a>Anonymous Logon
+
+
+Any user who accesses the system through an anonymous logon has the Anonymous Logon identity. This identity allows anonymous access to resources, such as a web page that is published on corporate servers. The Anonymous Logon group is not a member of the Everyone group by default.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-7</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-authenticateduser"></a>Authenticated Users
+
+
+Any user who accesses the system through a sign-in process has the Authenticated Users identity. This identity allows access to shared resources within the domain, such as files in a shared folder that should be accessible to all the workers in the organization. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-11</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>[Access this computer from the network](access-this-computer-from-the-network.md): SeNetworkLogonRight</p>
+<p>[Add workstations to domain](add-workstations-to-domain.md): SeMachineAccountPrivilege</p>
+<p>[Bypass traverse checking](bypass-traverse-checking.md): SeChangeNotifyPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-batch"></a>Batch
+
+
+Any user or process that accesses the system as a batch job (or through the batch queue) has the Batch identity. This identity allows batch jobs to run scheduled tasks, such as a nightly cleanup job that deletes temporary files. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-3</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-creatorgroup"></a>Creator Group
+
+
+The person who created the file or the directory is a member of this special identity group. Windows Server operating systems use this identity to automatically grant access permissions to the creator of a file or directory.
+
+A placeholder security identifier (SID) is created in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces this SID with the SID for the primary group of the object’s current owner. The primary group is used only by the Portable Operating System Interface for UNIX (POSIX) subsystem.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-3-1</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-creatorowner"></a>Creator Owner
+
+
+The person who created the file or the directory is a member of this special identity group. Windows Server operating systems use this identity to automatically grant access permissions to the creator of a file or directory. A placeholder SID is created in an inheritable ACE. When the ACE is inherited, the system replaces this SID with the SID for the object’s current owner.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-3-0</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-dialup"></a>Dialup
+
+
+Any user who accesses the system through a dial-up connection has the Dial-Up identity. This identity distinguishes dial-up users from other types of authenticated users.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-1</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-digestauth"></a>Digest Authentication
+
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-64-21</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-entdcs"></a>Enterprise Domain Controllers
+
+
+This group includes all domain controllers in an Active Directory forest. Domain controllers with enterprise-wide roles and responsibilities have the Enterprise Domain Controllers identity. This identity allows them to perform certain tasks in the enterprise by using transitive trusts. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-9</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights Assignment</p></td>
+<td><p>[Access this computer from the network](access-this-computer-from-the-network.md): SeNetworkLogonRight</p>
+<p>[Allow log on locally](allow-log-on-locally.md): SeInteractiveLogonRight</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-everyone"></a>Everyone
+
+
+All interactive, network, dial-up, and authenticated users are members of the Everyone group. This special identity group gives wide access to system resources. Whenever a user logs on to the network, the user is automatically added to the Everyone group.
+
+On computers running Windows 2000 and earlier, the Everyone group included the Anonymous Logon group as a default member, but as of Windows Server 2003, the Everyone group contains only Authenticated Users and Guest; and it no longer includes Anonymous Logon by default (although this can be changed).
+
+Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-1-0</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>[Access this computer from the network](access-this-computer-from-the-network.md): SeNetworkLogonRight</p>
+<p>[Act as part of the operating system](act-as-part-of-the-operating-system.md): SeTcbPrivilege</p>
+<p>[Bypass traverse checking](bypass-traverse-checking.md): SeChangeNotifyPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-interactive"></a>Interactive
+
+
+Any user who is logged on to the local system has the Interactive identity. This identity allows only local users to access a resource. Whenever a user accesses a given resource on the computer to which they are currently logged on, the user is automatically added to the Interactive group. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-4</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-localservice"></a>Local Service
+
+
+The Local Service account is similar to an Authenticated User account. The Local Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Local Service account access network resources as a null session with anonymous credentials. The name of the account is NT AUTHORITY\\LocalService. This account does not have a password.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-19</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default user rights</p></td>
+<td><p>[Adjust memory quotas for a process](adjust-memory-quotas-for-a-process.md): SeIncreaseQuotaPrivilege</p>
+<p>[Bypass traverse checking](bypass-traverse-checking.md): SeChangeNotifyPrivilege</p>
+<p>[Change the system time](change-the-system-time.md): SeSystemtimePrivilege</p>
+<p>[Change the time zone](change-the-time-zone.md): SeTimeZonePrivilege</p>
+<p>[Create global objects](create-global-objects.md): SeCreateGlobalPrivilege</p>
+<p>[Generate security audits](generate-security-audits.md): SeAuditPrivilege</p>
+<p>[Impersonate a client after authentication](impersonate-a-client-after-authentication.md): SeImpersonatePrivilege</p>
+<p>[Replace a process level token](replace-a-process-level-token.md): SeAssignPrimaryTokenPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-localsystem"></a>LocalSystem
+
+
+This is a service account that is used by the operating system. The LocalSystem account is a powerful account that has full access to the system and acts as the computer on the network. If a service logs on to the LocalSystem account on a domain controller, that service has access to the entire domain. Some services are configured by default to log on to the LocalSystem account. Do not change the default service setting. The name of the account is LocalSystem. This account does not have a password.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-18</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-network"></a>Network
+
+
+This group implicitly includes all users who are logged on through a network connection. Any user who accesses the system through a network has the Network identity. This identity allows only remote users to access a resource. Whenever a user accesses a given resource over the network, the user is automatically added to the Network group. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-2</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-networkservice"></a>Network Service
+
+
+The Network Service account is similar to an Authenticated User account. The Network Service account has the same level of access to resources and objects as members of the Users group. This limited access helps safeguard your system if individual services or processes are compromised. Services that run as the Network Service account access network resources by using the credentials of the computer account. The name of the account is NT AUTHORITY\\NetworkService. This account does not have a password.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-20</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>[Adjust memory quotas for a process](adjust-memory-quotas-for-a-process.md): SeIncreaseQuotaPrivilege</p>
+<p>[Bypass traverse checking](bypass-traverse-checking.md): SeChangeNotifyPrivilege</p>
+<p>[Create global objects](create-global-objects.md): SeCreateGlobalPrivilege</p>
+<p>[Generate security audits](generate-security-audits.md): SeAuditPrivilege</p>
+<p>[Impersonate a client after authentication](impersonate-a-client-after-authentication.md): SeImpersonatePrivilege</p>
+<p>[Restore files and directories](restore-files-and-directories.md): SeRestorePrivilege</p>
+<p>[Replace a process level token](replace-a-process-level-token.md): SeAssignPrimaryTokenPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-ntlmauth"></a>NTLM Authentication
+
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-64-10</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-otherorganization"></a>Other Organization
+
+
+This group implicitly includes all users who are logged on to the system through a dial-up connection. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-1000</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-principalself"></a>Principal Self
+
+
+This identify is a placeholder in an ACE on a user, group, or computer object in Active Directory. When you grant permissions to Principal Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal that is represented by the object.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-10</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-remoteinteractivelogon"></a>Remote Interactive Logon
+
+
+This identity represents all users who are currently logged on to a computer by using a Remote Desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-14</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-restrictedcode"></a>Restricted
+
+
+Users and computers with restricted capabilities have the Restricted identity. This identity group is used by a process that is running in a restricted security context, such as running an application with the RunAs service. When code runs at the Restricted security level, the Restricted SID is added to the user’s access token.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-12</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-schannelauth"></a>SChannel Authentication
+
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-64-14</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-service"></a>Service
+
+
+Any service that accesses the system has the Service identity. This identity group includes all security principals that are signed in as a service. This identity grants access to processes that are being run by Windows Server services. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-6</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>[Create global objects](create-global-objects.md): SeCreateGlobalPrivilege</p>
+<p>[Impersonate a client after authentication](impersonate-a-client-after-authentication.md): SeImpersonatePrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-terminalserveruser"></a>Terminal Server User
+
+
+Any user accessing the system through Terminal Services has the Terminal Server User identity. This identity allows users to access Terminal Server applications and to perform other necessary tasks with Terminal Server services. Membership is controlled by the operating system.
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-13</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-thisorg"></a>This Organization
+
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p>S-1-5-15</p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p>Foreign Security Principal</p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>None</p></td>
+</tr>
+</tbody>
+</table>
+
+ 
+
+## <a href="" id="bkmk-windowmanager"></a>Window Manager\\Window Manager Group
+
+
+<table>
+<colgroup>
+<col width="50%" />
+<col width="50%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th>Attribute</th>
+<th>Value</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td><p>Well-Known SID/RID</p></td>
+<td><p></p></td>
+</tr>
+<tr class="even">
+<td><p>Object Class</p></td>
+<td><p></p></td>
+</tr>
+<tr class="odd">
+<td><p>Default Location in Active Directory</p></td>
+<td><p>cn=WellKnown Security Principals, cn=Configuration, dc=&lt;forestRootDomain&gt;</p></td>
+</tr>
+<tr class="even">
+<td><p>Default User Rights</p></td>
+<td><p>[Bypass traverse checking](bypass-traverse-checking.md): SeChangeNotifyPrivilege</p>
+<p>[Increase a process working set](increase-a-process-working-set.md): SeIncreaseWorkingSetPrivilege</p></td>
+</tr>
+</tbody>
+</table>
+
+## See also
+
+- [Active Directory Security Groups](active-directory-security-groups.md)
+
+- [Security Principals](security-principals.md)
+
+- [Access Control Overview](access-control.md)
\ No newline at end of file
diff --git a/windows/keep-secure/troubleshoot-onboarding-windows-defender-advanced-threat-protection.md b/windows/keep-secure/troubleshoot-onboarding-windows-defender-advanced-threat-protection.md
index 7db942d7ba..b9baeb947e 100644
--- a/windows/keep-secure/troubleshoot-onboarding-windows-defender-advanced-threat-protection.md
+++ b/windows/keep-secure/troubleshoot-onboarding-windows-defender-advanced-threat-protection.md
@@ -55,6 +55,29 @@ HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Advanced Threat Protection
 
 If the **OnboardingState** value is not set to **1**, you can use Event Viewer to review errors on the endpoint.
 
+If you configured your endpoints with a deployment tool that required a script, you can check  the event viewer for the onboarding script results.
+<br>
+**Check the result of the script**:
+
+1. Click **Start**, type **Event Viewer**, and press **Enter**.
+
+2. Go to **Windows Logs** > **Application**.
+
+3. Look for an event from **WDATPOnboarding** event source.
+
+If the script fails and the event is an error, you can check the event ID in the following table to help you troubleshoot the issue.
+> **Note**&nbsp;&nbsp;The following event IDs are specific to the onboarding script only. 
+
+Event ID | Error Type | Resolution steps
+:---|:---|:---
+5 | Offboarding data was found but couldn't be deleted | Check the permissions on the registry, specifically ```HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection```
+10 | Onboarding data couldn't be written to registry |  Check the permissions on the registry, specifically ```HKLM\SOFTWARE\Policies\Microsoft\Windows Advanced Threat```. Verify that the script was ran as an administrator.
+15 |  Failed to start SENSE service |Check the service status (```sc query sense``` command). Make sure it's not in an intermediate state (*'Pending_Stopped'*, *'Pending_Running'*) and try to run the script again (with administrator rights). 
+30 |  The script failed to wait for the service to start running | The service could have taken more time to start or has encountered errors while trying to start. For more information on events and errors related to SENSE, see [Review events and errors on endpoints with Event viewer](event-error-codes-windows-defender-advanced-threat-protection.md).
+35 |  The script failed to find needed onboarding status registry value | When the SENSE service starts for the first time, it writes onboarding status to the registry location ```HKLM\SOFTWARE\Microsoft\Windows Advanced Threat Protection\Status```. The script failed to find it after several seconds. You can manually test it and check if it's there. For more information on events and errors related to SENSE, see [Review events and errors on endpoints with Event viewer].(event-error-codes-windows-defender-advanced-threat-protection.md). 
+40 | SENSE service onboarding status is not set to **1** | The SENSE service has failed to onboard properly. For more information on events and errors related to SENSE, see [Review events and errors on endpoints with Event viewer](event-error-codes-windows-defender-advanced-threat-protection.md). 
+
+<br>
 **Use Event Viewer to identify and adress onboarding errors**:   
 
 1. Click **Start**, type **Event Viewer**, and press **Enter**.
@@ -76,9 +99,10 @@ If the **OnboardingState** value is not set to **1**, you can use Event Viewer t
 Event ID | Message | Resolution steps
 :---|:---|:---
 5 | Windows Advanced Threat Protection service failed to connect to the server at _variable_ | [Ensure the endpoint has Internet access](#ensure-the-endpoint-has-an-internet-connection).
-6 | Windows Advanced Threat Protection service failed to read the onboarding parameters. Failure code: _variable_ | [Run the onboarding script again](configure-endpoints-windows-defender-advanced-threat-protection.md#manual).
-7 |  Windows Advanced Threat Protection service failed to read the onboarding parameters. Failure code: _variable_ | [Ensure the endpoint has Internet access](#ensure-the-endpoint-has-an-internet-connection), then [run the onboarding script again](configure-endpoints-windows-defender-advanced-threat-protection.md#manual).
+6 | Windows Advanced Threat Protection service is not onboarded and no onboarding parameters were found. Failure code: _variable_ | [Run the onboarding script again](configure-endpoints-windows-defender-advanced-threat-protection.md#manual).
+7 |  Windows Advanced Threat Protection service failed to read the onboarding parameters. Failure code: _variable_ | [Ensure the endpoint has Internet access](#ensure-the-endpoint-has-an-internet-connection), then run the entire onboarding process again.
 15 | Windows Advanced Threat Protection cannot start command channel with URL: _variable_ | [Ensure the endpoint has Internet access](#ensure-the-endpoint-has-an-internet-connection).
+25 | Windows Defender Advanced Threat Protection service failed to reset health status in the registry. Failure code: _variable_ | Contact support.
 
 
 ### Ensure the Windows Defender ATP service is enabled
@@ -104,7 +128,7 @@ If the the service is running, then the result should look like the following sc
 
   ![Result of the sq query sense command](images/sc-query-sense-autostart.png)
 
-If the service **START_TYPE** is not set to **AUTO_START**, then you'll need to set the service to automatically start.
+If the service ```START_TYPE``` is not set to ```AUTO_START```, then you'll need to set the service to automatically start.
 
 **Change the Windows Defender ATP service startup type from the command line:**
 
@@ -192,7 +216,7 @@ If the service is enabled, then the result should look like the following screen
 
 ![Result of the sc query command for diagtrack](images/windefatp-sc-qc-diagtrack.png)
 
-If the **START_TYPE** is not set to **AUTO_START**, then you'll need to set the service to automatically start.
+If the ```START_TYPE``` is not set to ```AUTO_START```, then you'll need to set the service to automatically start.
 
 
 
@@ -330,6 +354,55 @@ To ensure that sensor has service connectivity, follow the steps described in th
 
 If the verification fails and your environment is using a proxy to connect to the Internet, then follow the steps described in [Configure proxy and Internet connectivity settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md) topic.    
 
+## Troubleshoot onboarding issues using Microsoft Intune
+You can use Microsoft Intune to check error codes and attempt to troubleshoot the cause of the issue.
+
+Use the following tables to understand the possible causes of issues while onboarding:
+
+- Microsoft Intune error codes and OMA-URIs table
+- Known issues with non-compliance table
+- Mobile Device Management (MDM) event logs table
+
+If none of the event logs and troubleshooting steps work, download the Local script from the **Endpoint Management** section of the portal, and run it in an elevated command prompt.  
+
+**Microsoft Intune error codes and OMA-URIs**:
+
+Error Code Hex | Error Code Dec | Error Description | OMA-URI | Possible cause and troubleshooting steps
+:---|:---|:---|:---|:---
+0x87D1FDE8 | -2016281112 | Remediation failed | Onboarding <br> Offboarding |  **Possible cause:** Onboarding or offboarding failed on a wrong blob: wrong signature or missing PreviousOrgIds fields. <br><br> **Troubleshooting steps:** <br> Check the event IDs in the [Ensure the endpoint is onboarded successfully](#ensure-the-endpoint-is-onboarded-successfully) section. <br><br> Check the MDM event logs in the following table or follow the instructions in [Diagnose MDM failures in Windows 10](https://msdn.microsoft.com/en-us/library/windows/hardware/mt632120%28v=vs.85%29.aspx).
+ | | | Onboarding <br> Offboarding <br> SampleSharing | **Possible cause:** Windows Defender ATP Policy registry key does not exist or the OMA DM client doesn't have permissions to write to it. <br><br> **Troubleshooting steps:** Ensure that the following registry key exists: ```HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Advanced Threat Protection```. <br> <br> If it doesn't exist, open an elevated command and add the key. 
+  | | | SenseIsRunning <br> OnboardingState <br> OrgId |  **Possible cause:** An attempt to remediate by read-only property. Onboarding has failed. <br><br> **Troubleshooting steps:** Check the troubleshooting steps in [Troubleshoot Windows Defender Advanced Threat Protection onboarding issues](#troubleshoot-windows-defender-advanced-threat-protection-onboarding-issues). <br><br> Check the MDM event logs in the following table or follow the instructions in [Diagnose MDM failures in Windows 10](https://msdn.microsoft.com/en-us/library/windows/hardware/mt632120%28v=vs.85%29.aspx).
+   | | | All | **Possible cause:** Attempt to deploy Windows Defender ATP on non-supported SKU/Platform, particularly Holographic SKU. <br><br> Currently is supported platforms:  Enterprise, Education, and Professional. <br> Server is not supported. 
+   0x87D101A9 | -2016345687 |Syncml(425): The requested command failed because the sender does not have adequate access control permissions (ACL) on the recipient.  | All |  **Possible cause:** Attempt to deploy Windows Defender ATP on non-supported SKU/Platform, particularly Holographic SKU. <br><br> Currently is supported platforms:  Enterprise, Education, and Professional. 
+
+<br>
+**Known issues with non-compliance**
+
+The following table provides information on issues with non-compliance and how you can address the issues.
+
+Case | Symptoms | Possible cause and troubleshooting steps
+:---|:---|:---
+1 | Machine is compliant by SenseIsRunning OMA-URI. But is non-compliant by OrgId, Onboarding and OnboardingState OMA-URIs. | **Possible cause:** Check that user passed OOBE after Windows installation or upgrade. During OOBE onboarding couldn't be completed but SENSE is running already. <br><br> **Troubleshooting steps:** Wait for OOBE to complete.
+2 |  Machine is compliant by OrgId, Onboarding, and OnboardingState OMA-URIs, but is non-compliant by SenseIsRunning OMA-URI. |  **Possible cause:** Sense service's startup type is set as "Delayed Start". Sometimes this causes the Microsoft Intune server to report the machine as non-compliant by SenseIsRunning when DM session occurs on system start. <br><br> **Troubleshooting steps:** The issue should automatically be fixed within 24 hours.
+3 | Machine is non-compliant | **Troubleshooting steps:** Ensure that Onboarding and Offboarding policies are not deployed on the same machine at same time.
+
+<br>
+**Mobile Device Management (MDM) event logs**
+
+View the MDM event logs to troubleshoot issues that might arise during onboarding:
+
+Log name: Microsoft\Windows\DeviceManagement-EnterpriseDiagnostics-Provider 
+
+Channel name: Admin
+
+ID | Severity | Event description | Description
+:---|:---|:---|:---
+1801 | Error | Windows Defender Advanced Threat Protection CSP: Failed to Get Node's Value. NodeId: (%1), TokenName: (%2), Result: (%3) | Windows Defender ATP has failed to get specific node's value. <br> TokenName: Contains node name that caused the error. <br> Result: Error details.  
+1802 | Information | Windows Defender Advanced Threat Protection CSP: Get Node's Value complete. NodeId: (%1), TokenName: (%2), Result: (%3) |  Windows Defender ATP has completed to get specific node's value. <br> TokenName: Contains node name <br><br> Result: Error details or succeeded.
+1819 | Error | Windows Defender Advanced Threat Protection CSP: Failed to Set Node's Value. NodeId: (%1), TokenName: (%2), Result: (%3). | Windows Defender ATP has completed to get specific node's value. <br><br> TokenName: Contains node name that caused the error <br><br> Result: Error details.
+1820 | Information | Windows Defender Advanced Threat Protection CSP: Set Nod's Value complete. NodeId: (%1), TokenName: (%2), Result: (%3). | Windows Defender ATP has completed to get specific node's value. <br><br> TokenName: Contains node name <br><br> Result: Error details or succeeded.
+
+
 <!--
 
 ## There are no users in the Azure Active Directory
@@ -363,8 +436,6 @@ Log in to the application in the Azure Management Portal again:
 -->
 
 ## Related topics
-<!--- [Windows Defender ATP service onboarding](service-onboarding-windows-defender-advanced-threat-protection.md)-->
 - [Configure Windows Defender ATP endpoints](configure-endpoints-windows-defender-advanced-threat-protection.md)
 - [Configure endpoint proxy and Internet connectivity settings](configure-proxy-internet-windows-defender-advanced-threat-protection.md)
-- [Additional Windows Defender ATP configuration settings](additional-configuration-windows-defender-advanced-threat-protection.md)
-- [Monitor the Windows Defender ATP onboarding](monitor-onboarding-windows-defender-advanced-threat-protection.md)
+
diff --git a/windows/keep-secure/use-powershell-cmdlets-windows-defender-for-windows-10.md b/windows/keep-secure/use-powershell-cmdlets-windows-defender-for-windows-10.md
new file mode 100644
index 0000000000..e81dff792a
--- /dev/null
+++ b/windows/keep-secure/use-powershell-cmdlets-windows-defender-for-windows-10.md
@@ -0,0 +1,43 @@
+---
+title: Use PowerShell cmdlets to configure and run Windows Defender in Windows 10
+description: In Windows 10, you can use PowerShell cmdlets to run scans, update definitions, and change settings in Windows Defender.
+keywords: scan, command line, mpcmdrun, defender
+search.product: eADQiWindows 10XVcnh
+ms.pagetype: security
+ms.prod: w10
+ms.mktglfcycl: manage
+ms.sitesec: library
+ms.pagetype: security
+author: iaanw
+---
+
+# Use PowerShell cmdlets to configure and run Windows Defender
+
+**Applies to:**
+
+- Windows 10
+
+You can use PowerShell to perform various functions in Windows Defender. Similar to the command prompt or command line, PowerShell is a task-based command-line shell and scripting language designed especially for system administration, and you can read more about it at the [PowerShell hub on MSDN](https://msdn.microsoft.com/en-us/powershell/mt173057.aspx).
+
+For a list of the cmdlets and their functions and available parameters, see the [Defender cmdlets](https://technet.microsoft.com/en-us/library/dn433280.aspx) topic.
+
+PowerShell cmdlets are most useful in Windows Server environments that don't rely on a graphical user interface (GUI) to configure software. 
+
+> **Note:**&nbsp;&nbsp;PowerShell cmdlets should not be used as a replacement for a full network policy management infrastructure, such as [System Center Configuration Manager](https://technet.microsoft.com/en-us/library/gg682129.aspx), [Group Policy Management Console](https://technet.microsoft.com/en-us/library/cc731212.aspx), or [Windows Defender Group Policy ADMX templates](https://support.microsoft.com/en-us/kb/927367).
+
+PowerShell is typically installed under the folder _%SystemRoot%\system32\WindowsPowerShell_.
+
+
+**Use Windows Defender PowerShell cmdlets**
+
+1. Click **Start**, type **powershell**, and press **Enter**.
+2. Click **Windows PowerShell** to open the interface. 
+    > **Note:**&nbsp;&nbsp;You may need to open an administrator-level version of PowerShell. Right-click the item in the Start menu, click **Run as administrator** and click **Yes** at the permissions prompt.
+3. Enter the command and parameters.
+
+To open online help for any of the cmdlets type the following:
+
+```text
+Get-Help <cmdlet> -Online
+```
+Omit the `-online` parameter to get locally cached help.
diff --git a/windows/keep-secure/windows-10-enterprise-security-guides.md b/windows/keep-secure/windows-10-enterprise-security-guides.md
index 30f130d499..a5c487491c 100644
--- a/windows/keep-secure/windows-10-enterprise-security-guides.md
+++ b/windows/keep-secure/windows-10-enterprise-security-guides.md
@@ -1,6 +1,6 @@
 ---
 title: Enterprise security guides (Windows 10)
-description: Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides.
+description: Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides.
 ms.assetid: 57134f84-bd4b-4b1d-b663-4a2d36f5a7f8
 ms.prod: w10
 ms.mktglfcycl: deploy
@@ -14,7 +14,7 @@ author: challum
 
 ## Purpose
 
-Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Device Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides.
+Get proven guidance to help you better secure and protect your enterprise by using technologies such as Credential Guard, Microsoft Passport, and Windows Hello. This section offers technology overviews and step-by-step guides.
 
 ## In this section
 
@@ -34,10 +34,6 @@ Get proven guidance to help you better secure and protect your enterprise by usi
 <td align="left"><p>[Control the health of Windows 10-based devices](protect-high-value-assets-by-controlling-the-health-of-windows-10-based-devices.md)</p></td>
 <td align="left"><p>This article details an end-to-end solution that helps you protect high-value assets by enforcing, controlling, and reporting the health of Windows 10-based devices.</p></td>
 </tr>
-<tr class="even">
-<td align="left"><p>[Device Guard deployment guide](device-guard-deployment-guide.md)</p></td>
-<td align="left"><p>Microsoft Device Guard is a feature set that consists of both hardware and software system integrity hardening features that revolutionize the Windows operating system’s security. Windows 10 employs Device Guard as well as code integrity and advanced hardware features such as CPU virtualization extensions, Trusted Platform Module, and second-level address translation to offer comprehensive modern security to its users. This guide explores the individual features in Device Guard as well as how to plan for, configure, and deploy them.</p></td>
-</tr>
 <tr class="odd">
 <td align="left"><p>[Microsoft Passport guide](microsoft-passport-guide.md)</p></td>
 <td align="left"><p>This guide describes the new Windows Hello and Microsoft Passport technologies that are part of the Windows 10 operating system. It highlights specific capabilities of these technologies that help mitigate threats from conventional credentials and provides guidance about how to design and deploy these technologies as part of your Windows 10 rollout.</p></td>
diff --git a/windows/keep-secure/windows-defender-in-windows-10.md b/windows/keep-secure/windows-defender-in-windows-10.md
index 2dc00afede..0f5d4d28f0 100644
--- a/windows/keep-secure/windows-defender-in-windows-10.md
+++ b/windows/keep-secure/windows-defender-in-windows-10.md
@@ -19,7 +19,7 @@ This topic provides an overview of Windows Defender, including a list of system
 
 For more important information about running Windows Defender on a server platform, see [Windows Defender Overview for Windows Server Technical Preview](https://technet.microsoft.com/library/dn765478.aspx).
 
-Take advantage of Windows Defender by configuring the settings and definitions using the following tools:
+Take advantage of Windows Defender by configuring settings and definitions using the following tools:
 -   Microsoft Active Directory *Group Policy* for settings
 -   Windows Server Update Services (WSUS) for definitions
 
diff --git a/windows/keep-secure/windows-security-baselines.md b/windows/keep-secure/windows-security-baselines.md
new file mode 100644
index 0000000000..d9f379c2a6
--- /dev/null
+++ b/windows/keep-secure/windows-security-baselines.md
@@ -0,0 +1,62 @@
+---
+title: Windows security baselines (Windows 10)
+description: Use this topic to learn what security baselines are and how you can use them in your organization to help keep your devices secure.
+ms.prod: w10
+ms.mktglfcycl: deploy
+ms.sitesec: library
+ms.pagetype: security
+author: brianlic-msft
+---
+
+# Windows security baselines
+
+Microsoft is dedicated to provide our customers with a secure operating system, such as Windows 10 and Windows Server, as well as secure apps, such as Microsoft Edge. In addition to the security assurance of its products, Microsoft also enables you to have fine control of your environments by providing various configuration capabilities. Even though Windows and Windows Server are designed to be secure out-of-the-box, a large number of organizations still want more granular control of their security configurations. To navigate these large number of controls, organizations need guidance for configuring various security features. Microsoft provides this guidance in the form of security baselines.
+
+We recommend implementing an industry-standard configuration that is broadly known and well-tested, such as a Microsoft security baseline, as opposed to creating one yourself. This helps increase flexibility and reduce costs.  
+
+## What are security baselines?
+
+Every organization faces security threats. However, the types of security threats that are of most concern to one organization can be completely different from another organization. For example, an e-commerce company may focus on protecting their Internet-facing web apps, while a hospital may focus on protecting confidential patient information. The one thing that all organizations have in common is a need to keep their apps and devices secure. These devices must be compliant with the security standards (or security baselines) defined by the organization.
+
+A security baseline is a collection of settings that have a security impact and include Microsoft’s recommended value for configuring those settings along with guidance on the security impact of those settings. These settings are based on feedback from Microsoft security engineering teams, product groups, partners, and 
+customers.  
+
+## Why are security baselines needed?
+
+Security baselines are an essential benefit to customers because they bring together expert knowlege from Microsoft, partners, and customers.
+
+For example, there are over 3,000 Group Policy settings for Windows 10, which does not include over 1,800 Internet Explorer 11 settings. Of those 4,800 settings, only some of them are security-related. While Microsoft provides extensive guidance on different security features, going through each of them can take a long time. You would have to determine the security impact of each setting on your own. After you've done that, you still need to determine what values each of these settings should be. 
+
+In modern organizations, the security threat landscape is constantly evolving. IT pros and policy makers must keep current with security threats and changes to Windows security settings to help mitigate these threats. 
+
+To help faster deployments and increase the ease of managing Windows, Microsoft provides customers with security baselines that are available in formats that can be consumed, such as Group Policy Objects backups.
+ 
+ ## How can you use security baselines?
+ 
+ You can use security baselines to:
+ 
+ - Ensure that user and device configuration settings are compliant with the baseline. 
+ - Set configuration settings. For example, you can use Group Policy, System Center Configuration Manager, or Microsoft Intune to configure a device with the setting values specified in the baseline. 
+ 
+ ## Where can I get the security baselines?
+ 
+ Here's a list of security baselines that are currently available.
+
+ > **Note:**  If you want to know what has changed with each security baseline, or if you want to stay up-to-date on what’s happening with them, check out the [Microsoft Security Guidance](http://blogs.technet.microsoft.com/secguide) blog.
+
+### Windows 10 security baselines
+ 
+ -  [Windows 10, Version 1511 security baseline](http://go.microsoft.com/fwlink/p/?LinkID=799381)
+ -  [Windows 10, Version 1507 security baseline](http://go.microsoft.com/fwlink/p/?LinkID=799380)
+
+
+### Windows Server security baselines
+
+ -  [Windows Server 2012 R2 security baseline](http://go.microsoft.com/fwlink/p/?LinkID=799382)
+
+## How can I monitor security baseline deployments?
+
+Microsoft’s Operation Management Services (OMS) helps you monitor security baseline deployments across your servers. To find out more, check out [Operations Management Suite](https://aka.ms/omssecscm).
+
+You can use [System Center Configuration Manager](https://www.microsoft.com/cloud-platform/system-center-configuration-manager) to monitor security baseline deployments on client devices within your organization.
+ 
\ No newline at end of file
diff --git a/windows/manage/TOC.md b/windows/manage/TOC.md
index 9a7fe85b18..4c43c597ce 100644
--- a/windows/manage/TOC.md
+++ b/windows/manage/TOC.md
@@ -28,7 +28,7 @@
 ### [Reset a Windows 10 Mobile device](reset-a-windows-10-mobile-device.md)
 ## [Join Windows 10 Mobile to Azure Active Directory](join-windows-10-mobile-to-azure-active-directory.md)
 ## [Configure devices without MDM](configure-devices-without-mdm.md)
-## [Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md)
+## [Windows 10 servicing options](introduction-to-windows-10-servicing.md)
 ## [Application development for Windows as a service](application-development-for-windows-as-a-service.md)
 ## [Windows Store for Business](windows-store-for-business.md)
 ### [Sign up and get started](sign-up-windows-store-for-business-overview.md)
diff --git a/windows/manage/app-inventory-managemement-windows-store-for-business.md b/windows/manage/app-inventory-managemement-windows-store-for-business.md
index d58572c900..ca7d24b2a2 100644
--- a/windows/manage/app-inventory-managemement-windows-store-for-business.md
+++ b/windows/manage/app-inventory-managemement-windows-store-for-business.md
@@ -23,7 +23,7 @@ The **Inventory** page in Windows Store for Business shows all apps in your inve
 
 All of these apps are treated the same once they are in your inventory and you can perform app lifecycle tasks for them: distribute apps, add apps to private store, review license details, and reclaim app licenses.
 
-![](images/wsfb-inventoryaddprivatestore.png)
+![Image shows Inventory page in Windows Store for Business with status status options for an app.](images/wsfb-inventoryaddprivatestore.png)
 
 Store for Business shows this info for each app in your inventory:
 
@@ -168,13 +168,13 @@ For each app in your inventory, you can view and manage license details. This gi
 
 2.  Click **Manage**, and then choose **Inventory**.
 
-3.  Click the ellipses for and app, and then choose **View license details**.
+3.  Click the ellipses for an app, and then choose **View license details**.
 
-    ![](images/wsfb-inventory-viewlicense.png)
+    ![Image showing Inventory page in Windows Store for Business.](images/wsfb-inventory-viewlicense.png)
 
     You'll see the names of people in your organization who have installed the app and are using one of the licenses.
 
-    ![](images/wsfb-licensedetails.png)
+    ![Image showing assigned licenses for an app.](images/wsfb-licensedetails.png)
 
     On **Assigned licenses**, you can do several things:
 
@@ -190,9 +190,9 @@ For each app in your inventory, you can view and manage license details. This gi
 
     **To assign an app to more people**
 
-    -   Click Assign to people, type the email address for the employee that you're assigning the app to, and click **Assign**.
+    -   Click **Assign to people**, type the email address for the employee that you're assigning the app to, and click **Assign**.
 
-        ![](images/wsfb-licenseassign.png)
+        ![Image showing Assign to people dialog for assigning app licenses to people in your organization.](images/wsfb-licenseassign.png)
 
         Store for Business updates the list of assigned licenses.
 
@@ -200,7 +200,7 @@ For each app in your inventory, you can view and manage license details. This gi
 
     -   Choose the person you want to reclaim the license from, click **Reclaim licenses**, and then click **Reclaim licenses**.
 
-        ![](images/wsfb-licensereclaim.png)
+        ![Image showing Assign to people dialog for reclaiming app licenses from people in your organization.](images/wsfb-licensereclaim.png)
 
         Store for Business updates the list of assigned licenses.
 
diff --git a/windows/manage/change-history-for-manage-and-update-windows-10.md b/windows/manage/change-history-for-manage-and-update-windows-10.md
index 603af6fbde..fe90ebb58f 100644
--- a/windows/manage/change-history-for-manage-and-update-windows-10.md
+++ b/windows/manage/change-history-for-manage-and-update-windows-10.md
@@ -12,6 +12,12 @@ author: jdeckerMS
 
 This topic lists new and updated topics in the [Manage and update Windows 10](index.md) documentation for [Windows 10 and Windows 10 Mobile](../index.md).
 
+## July 2016
+
+| New or changed topic | Description |
+| ---|---|
+| [Windows 10 servicing options](introduction-to-windows-10-servicing.md)  | Added detailed content on servicing branches, moved from [Windows 10 servicing overview](../plan/windows-10-servicing-options.md). |
+
 ## June 2016
 
 | New or changed topic | Description |
diff --git a/windows/manage/configure-windows-telemetry-in-your-organization.md b/windows/manage/configure-windows-telemetry-in-your-organization.md
index 1d4f6b116f..db19b958a4 100644
--- a/windows/manage/configure-windows-telemetry-in-your-organization.md
+++ b/windows/manage/configure-windows-telemetry-in-your-organization.md
@@ -6,6 +6,7 @@ ms.prod: w10
 ms.mktglfcycl: manage
 ms.sitesec: library
 ms.pagetype: security
+localizationpriority: high
 author: brianlic-msft
 ---
 
@@ -17,34 +18,118 @@ author: brianlic-msft
 -   Windows 10 Mobile
 -   Windows Server 2016 Technical Preview
 
-Use this article to make informed decisions about how you can configure telemetry in your organization. Telemetry is a term that means different things to different people and organizations. For the purpose of this article, we discuss telemetry as system data that is uploaded by the Connected User Experience and Telemetry component. The telemetry data is used to keep Windows devices secure, and to help Microsoft improve the quality of Windows and Microsoft services.
+At Microsoft, we use Windows telemetry to inform our decisions and focus our efforts in providing the most robust, most valuable platform for your business and the people who count on Windows to enable them to be as productive as possible. Telemetry gives users a voice in the operating system’s development. This guide describes the importance of Windows telemetry and how we protect that data. Additionally, it differentiates between telemetry and functional data. It also describes the telemetry levels that Windows supports. Of course, you can choose how much telemetry is shared with Microsoft, and this guide demonstrates how.
 
->**Note:**  This article does not apply to System Center Configuration Manager, System Center Endpoint Protection, or System Center Data Protection Manager because those components use a different telemetry service than Windows and Windows Server.
+To frame a discussion about telemetry, it is important to understand Microsoft’s privacy principles. We earn customer trust every day by focusing on six key privacy principles as described at [privacy.microsoft.com](https://privacy.microsoft.com/). These principles guided the implementation of the Windows telemetry system in the following ways:
 
-It describes the types of telemetry we gather and the ways you can manage its telemetry. This article also lists some examples of how telemetry can provide you with valuable insights into your enterprise deployments, and how Microsoft uses the data to quickly identify and address issues affecting its customers.
+-	**Control.** We offer customers control of the telemetry they share with us by providing easy-to-use management tools.
+-	**Transparency.** We provide information about the telemetry that Windows and Windows Server collects so our customers can make informed decisions.
+-	**Security.** We encrypt telemetry in transit from your device and protect that data at our secure data centers.
+-	**Strong legal protections.** We respect customers’ local privacy laws and fight for legal protection of their privacy as a fundamental human right.
+-	**No content-based targeting.** We take steps to avoid and minimize the collection of customer content, such as the content of files, chats, or emails, through the Windows telemetry system.  Customer content inadvertently collected is kept confidential and not used for user targeting.
+-	**Benefits to you.** We collect Windows telemetry to help provide you with an up-to-date, more secure, reliable and performant product, and to improve Windows for all of our customers.
 
-We understand that the privacy and security of our customers’ information is important and we have taken a thoughtful and comprehensive approach to customer privacy and the protection of their data with Windows 10, Windows Server 2016 Technical Preview, and System Center 2016.
+This article applies to Windows and Windows Server telemetry only. Other Microsoft or third-party apps, such as System Center Configuration Manager, System Center Endpoint Protection, or System Center Data Protection Manager, might send data to their cloud services in ways that are inconsistent with this guide. Their publishers are responsible for notifying users of their privacy policies, telemetry controls, and so on. This article describes the types of telemetry we may gather, the ways you might manage it in your organization, and some examples of how telemetry can provide you with valuable insights into your enterprise deployments. Microsoft uses the data to quickly identify and address issues affecting its customers.
+
+
+Use this article to make informed decisions about how you might configure telemetry in your organization. Telemetry is a term that means different things to different people and organizations. For the purpose of this article, we discuss telemetry as system data that is uploaded by the Connected User Experience and Telemetry component. The telemetry data is used to help keep Windows devices secure by identifying malware trends and other threats and to help Microsoft improve the quality of Windows and Microsoft services.
 
 ## Overview
 
-In previous versions of Windows and Windows Server, Microsoft used telemetry to check for updated or new Windows Defender signatures, check whether Windows Update installations were successful, gather reliability information through the Reliability Analysis Component (RAC) on Windows Server, and gather reliability information through the Windows Customer Experience Improvement Program (CEIP) on Windows. In Windows 10 and Windows Server 2016 Technical Preview, you can control telemetry streams by using Settings &gt; Privacy, Group Policy, or MDM.
-
-Microsoft is committed to improving customer experiences in a mobile-first and cloud-first world, and it all starts with our customers. Telemetry is one critical way Microsoft is using data to improve our products and services. Telemetry gives every enterprise customer a voice that helps us shape future versions of Windows, Windows Server and System Center, allowing us to respond quickly to your feedback and providing new features and improved quality to our customers.
-
-Our goal is to leverage the aggregated data to drive changes in the product and ecosystem to improve our customer experiences. We are also partnering with enterprises to provide added value from the telemetry information shared by their devices. Some examples include identifying outdated patches and downloading the latest antimalware signatures to help keep their devices secure, identifying application compatibility issues prior to upgrades, and gaining insights into driver reliability issues affecting other customers.
+In previous versions of Windows and Windows Server, Microsoft used telemetry to check for updated or new Windows Defender signatures, check whether Windows Update installations were successful, gather reliability information through the Reliability Analysis Component (RAC), and gather reliability information through the Windows Customer Experience Improvement Program (CEIP) on Windows. In Windows 10 and Windows Server 2016 Technical Preview, you can control telemetry streams by using the Privacy option in Settings, Group Policy, or MDM.
 
 For Windows 10, we invite IT pros to join the [Windows Insider Program](http://insider.windows.com) to give us feedback on what we can do to make Windows work better for your organization.
 
+## Understanding Windows telemetry
+
+Windows as a Service is a fundamental change in how Microsoft plans, builds, and delivers the operating system. Historically, we released a major Windows version every few years. The effort required to deploy large and infrequent Windows versions was substantial. That effort included updating the infrastructure to support the upgrade. Windows as a Service accelerates the cadence to provide rich updates more frequently, and these updates require substantially less effort to roll out than earlier versions of Windows. Since it provides more value to organizations in a shorter timeframe, delivering Windows as a Service is a top priority for us.
+
+The release cadence of Windows may be fast, so feedback is critical to its success. We rely on telemetry at each stage of the process to inform our decisions and prioritize our efforts. 
+
+### What is Windows telemetry?
+Windows telemetry is vital technical data from Windows devices about the device and how Windows and related software are performing. It's used in the following ways:
+
+- 	Keep Windows up to date
+-	Keep Windows secure, reliable, and performant
+-	Improve Windows – through the aggregate analysis of the use of Windows
+-	Personalize Windows engagement surfaces
+
+Here are some specific examples of Windows telemetry data:
+
+-	Type of hardware being used
+-	Applications installed and usage details
+-	Reliability information on device drivers
+
+### What is NOT telemetry?
+
+Telemetry can sometimes be confused with functional data. Some Windows components and apps connect to Microsoft services directly, but the data they exchange is not telemetry. For example, exchanging a user’s location for local weather or news is not an example of telemetry—it is functional data that the app or service requires to satisfy the user’s request.
+
+There are subtle differences between telemetry and functional data. Windows collects and sends telemetry in the background automatically. You can control how much information is gathered by setting the telemetry level. Microsoft tries to avoid collecting personal information wherever possible (for example, if a crash dump is collected and a document was in memory at the time of the crash).    On the other hand, functional data can contain personal information. However, a user action, such as requesting news or asking Cortana a question, usually triggers collection and transmission of functional data.
+
+If you’re an IT pro that wants to manage Windows functional data sent from your organization to Microsoft, see [Manage connections from Windows operating system components to Microsoft services](https://technet.microsoft.com/en-us/itpro/windows/manage/manage-connections-from-windows-operating-system-components-to-microsoft-services).
+
+The following are specific examples of functional data:
+
+- Current location for weather
+- Bing searches
+- Wallpaper and desktop settings synced across multiple devices
+
+### Telemetry gives users a voice
+
+Windows and Windows Server telemetry gives every user a voice in the operating system’s development and ongoing improvement. It helps us understand how Windows 10 and Windows Server 2016 behaves in the real world, focus on user priorities, and make informed decisions that benefit them. For our enterprise customers, representation in the dataset on which we will make future design decisions is a real benefit. The following sections offer real examples of these benefits.
+
+### Drive higher app and driver quality
+
+Our ability to collect telemetry that drives improvements to Windows and Windows Server helps raise the bar for app and device driver quality. Telemetry helps us to quickly identify and fix critical reliability and security issues with apps and device drivers on given configurations. For example, we can identify an app that hangs on devices using a specific version of a video driver, allowing us to work with the app and device driver vendor to quickly fix the issue. The result is less downtime and reduced costs and increased productivity associated with troubleshooting these issues.
+
+A real-world example of how Windows telemetry helps us quickly identify and fix issues is a particular version of a video driver that was crashing on some devices running Windows 10, causing the device to reboot. We detected the problem in our telemetry, and immediately contacted the third-party developer who builds the video driver. Working with the developer, we provided an updated driver to Windows Insiders within 24 hours. Based on telemetry from the Windows Insiders’ devices, we were able to validate the new version of the video driver, and rolled it out to the broad public as an update the next day. Telemetry helped us find, fix, and resolve this problem in just 48 hours, providing a better user experience and reducing costly support calls.
+
+### Improve end-user productivity
+
+Windows telemetry also helps Microsoft better understand how customers use (or do not use) the operating system’s features and related services. The insights we gain from this data helps us prioritize our engineering effort to directly impact our customers’ experiences. Examples are:
+
+-	**Start menu.** How do people change the Start menu layout? Do they pin other apps to it? Are there any apps that they frequently unpin? We use this dataset to adjust the default Start menu layout to better reflect people’s expectations when they turn on their device for the first time.
+-	**Cortana.** We use telemetry to monitor the scalability of our cloud service, improving search performance.
+-	**Application switching.**  Research and observations from earlier Windows versions showed that people rarely used Alt+Tab to switch between applications.  After discussing this with some users, we learned they loved the feature, saying that it would be highly productive, but they did not know about it previously. Based on this, we created the Task View button in Windows 10 to make this feature more discoverable. Later telemetry showed significantly higher usage of this feature.
+
+**These examples show how the use of telemetry data enables Microsoft to build or enhance features which can help organizations increase employee productivity while lowering help desk calls.**
+
+<!--
+### Insights into your own organization
+
+Sharing information with Microsoft helps make Windows and other products better, but it can also help make your internal processes and user experiences better, as well.  Microsoft is in the process of developing a set of analytics customized for your internal use.  The first of these, called Windows 10 Upgrade Analytics, will be available in Summer 2016.
+
+#### Windows 10 Upgrade Analytics
+
+Upgrading to new operating system versions has traditionally been a challenging, complex, and slow process for many enterprises. Discovering applications and drivers and then testing them for potential compatibility issues have been among the biggest pain points. 
+ 
+To better help customers through this difficult process, Microsoft developed Upgrade Analytics to give enterprises the tools to plan and manage the upgrade process end to end and allowing them to adopt new Windows releases more quickly and on an ongoing basis. 
+
+With Windows telemetry enabled, Microsoft collects computer, application, and driver compatibility-related information for analysis. We then identify compatibility issues that can block your upgrade and suggest fixes when they are known to Microsoft. 
+
+Use Upgrade Analytics to get:
+
+- A visual workflow that guides you from pilot to production
+- Detailed computer, driver, and application inventory
+- Powerful computer level search and drill-downs 
+- Guidance and insights into application and driver compatibility issues with suggested fixes 
+- Data driven application rationalization tools
+- Application usage information, allowing targeted validation; workflow to track validation progress and decisions
+- Data export to commonly used software deployment tools 
+
+The Upgrade Analytics workflow steps you through the discovery and rationalization process until you have a list of computers that are ready to be upgraded.
+
+-->
 ## How is telemetry data handled by Microsoft?
 
 ### Data collection
 
-Windows 10 and Windows Server 2016 Technical Preview includes the Connected User Experience and Telemetry component, which uses Event Tracing for Windows (ETW) tracelogging technology to gather and store telemetry events and data. The operating system and some Microsoft management solutions, such as System Center, use the same logging technology.
+Windows 10 and Windows Server 2016 Technical Preview includes the Connected User Experience and Telemetry component, which uses Event Tracing for Windows (ETW) tracelogging technology that gathers and stores telemetry events and data. The operating system and some Microsoft management solutions, such as System Center, use the same logging technology.
 
 1. Operating system features and some management applications are instrumented to publish events and data. Examples of management applications include Virtual Machine Manager (VMM), Server Manager, and Storage Spaces.
 2. Events are gathered using public operating system event logging and tracing APIs.
 3. You can configure the telemetry level by using an MDM policy, Group Policy, or registry settings.
-4. The Connected User Experience and Telemetry component transmits telemetry data over HTTPS to Microsoft and uses certificate pinning.
+4. The Connected User Experience and Telemetry component transmits the telemetry data.
 
 Info collected at the Enhanced and Full levels of telemetry is typically gathered at a fractional sampling rate, which can be as low as 1% of devices reporting data at those levels.
 
@@ -56,21 +141,21 @@ All telemetry data is encrypted using SSL and uses certificate pinning during tr
 
 The Microsoft Data Management Service routes data back to our secure cloud storage. Only Microsoft personnel with a valid business justification are permitted access.
 
-The Connected User Experience and Telemetry component connects to the Microsoft Data Management service at v10.vortex-win.data.microsoft.com.
+The following table defines the endpoints for telemetry services:
 
-The Connected User Experience and Telemetry component also connects to settings-win.data.microsoft.com to download configuration information.
-
-[Windows Error Reporting](http://msdn.microsoft.com/library/windows/desktop/bb513641.aspx) connects to watson.telemetry.microsoft.com.
-
-[Online Crash Analysis](http://msdn.microsoft.com/library/windows/desktop/ee416349.aspx) connects to oca.telemetry.microsoft.com.
+| Service | Endpoint |
+| - | - |
+| Connected User Experience and Telemetry component | v10.vortex-win.data.microsoft.com<br />settings-win.data.microsoft.com |
+| [Windows Error Reporting](http://msdn.microsoft.com/library/windows/desktop/bb513641.aspx) | watson.telemetry.microsoft.com |
+| [Online Crash Analysis](http://msdn.microsoft.com/library/windows/desktop/ee416349.aspx) | oca.telemetry.microsoft.com |
 
 ### Data use and access
 
-Data gathered from telemetry is used by Microsoft teams primarily to improve our customer experiences, and for security, health, quality, and performance analysis. The principle of least privileged guides access to telemetry data.  Only Microsoft personnel with a valid business need are permitted access to the telemetry data. Microsoft does not share personal data of our customers with third parties, except at the customer’s discretion or for the limited purposes described in the Privacy Statement. We do share business reports with OEMs and third party partners that include aggregated, anonymized telemetry information. Data-sharing decisions are made by an internal team including privacy, legal, and data management.
+The principle of least privileged access guides access to telemetry data. Microsoft does not share personal data of our customers with third parties, except at the customer’s discretion or for the limited purposes described in the [Privacy Statement](https://privacy.microsoft.com/en-us/privacystatement). Microsoft may share business reports with OEMs and third party partners that include aggregated and anonymized telemetry information. Data-sharing decisions are made by an internal team including privacy, legal, and data management.
 
 ### Retention
 
-Microsoft believes in and practices information minimization. We strive to gather only the info we need, and store it for as long as it’s needed to provide a service or for analysis. Much of the info about how Windows and apps are functioning is deleted within 30 days. Other info may be retained longer, such as error reporting data or Store purchase history. 
+Microsoft believes in and practices information minimization. We strive to gather only the info we need, and store it for as long as it’s needed to provide a service or for analysis. Much of the info about how Windows and apps are functioning is deleted within 30 days. Other info may be retained longer, such as error reporting data or Windows Store purchase history. 
 
 ## Telemetry levels
 
@@ -81,19 +166,19 @@ The telemetry data is categorized into four levels:
 
 -   **Security**. Information that’s required to help keep Windows, Windows Server, and System Center secure, including data about the Connected User Experience and Telemetry component settings, the Malicious Software Removal Tool, and Windows Defender.
 
--   **Basic**. Basic device info, including: quality-related data, app compat, app usage data, and data from the **Security** level.
+-   **Basic**. Basic device info, including: quality-related data, app compatibility, app usage data, and data from the **Security** level.
 
 -   **Enhanced**. Additional insights, including: how Windows, Windows Server, System Center, and apps are used, how they perform, advanced reliability data, and data from both the **Basic** and the **Security** levels.
 
 -   **Full**. All data necessary to identify and help to fix problems, plus data from the **Security**, **Basic**, and **Enhanced** levels.
 
-The levels are cumulative and are illustrated in the following diagram. These levels apply to all editions of Windows Server 2016 Technical Preview.
+The levels are cumulative and are illustrated in the following diagram. Also, these levels apply to all editions of Windows Server 2016 Technical Preview.
 
 ![breakdown of telemetry levels and types of administrative controls](images/priv-telemetry-levels.png)
 
 ### Security level
 
-The Security level gathers only the telemetry info that is required to keep Windows devices, Windows Server, and guests secure with the latest security updates. This level is only available on Windows Server 2016, Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile Enterprise, and IoT Core editions.
+The Security level gathers only the telemetry info that is required to keep Windows devices, Windows Server, and guests protected with the latest security updates. This level is only available on Windows Server 2016, Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile Enterprise, and Windos IoT Core editions.
 
 > **Note:**  If your organization relies on Windows Update for updates, you shouldn’t use the **Security** level. Because no Windows Update information is gathered at this level, important information about update failures is not sent. Microsoft uses this information to fix the causes of those failures and improve the quality of our updates.
 
@@ -103,7 +188,7 @@ Windows Server Update Services (WSUS) and System Center Configuration Manager fu
 
 The data gathered at this level includes:
 
--   **Connected User Experience and Telemetry component settings**. If data has been gathered and is queued to be sent, the Connected User Experience and Telemetry component downloads its settings file from Microsoft’s servers. The data gathered by the client for this request includes OS information, device id (used to identify what specific device is requesting settings) and device class (for example, whether the device is server or desktop).
+-   **Connected User Experience and Telemetry component settings**. If general telemetry data has been gathered and is queued, it is sent to Microsoft. Along with this telemetry, the Connected User Experience and Telemetry component may download a configuration settings file from Microsoft’s servers. This file is used to configure the Connected User Experience and Telemetry component itself. The data gathered by the client for this request includes OS information, device id (used to identify what specific device is requesting settings) and device class (for example, whether the device is server or desktop).
 
 -   **Malicious Software Removal Tool (MSRT)** The MSRT infection report contains information, including device info and IP address.
 
@@ -126,11 +211,11 @@ No user content, such as user files or communications, is gathered at the **Secu
 
 ### Basic level
 
-The Basic level gathers a limited set of data that’s critical for understanding the device and its configuration. This level also includes the **Security** level data. This level helps to identify problems that can occur on a particular device hardware or software configuration. For example, it can help determine if crashes are more frequent on devices with a specific amount of memory or that are running a particular driver version. The Connected User Experience and Telemetry component does not gather telemetry data about System Center, but it can transmit telemetry for other non-Windows applications if they have user consent.
+The Basic level gathers a limited set of data that’s critical for understanding the device and its configuration. This level also includes the **Security** level data. This level helps to identify problems that can occur on a particular hardware or software configuration. For example, it can help determine if crashes are more frequent on devices with a specific amount of memory or that are running a particular driver version. The Connected User Experience and Telemetry component does not gather telemetry data about System Center, but it can transmit telemetry for other non-Windows applications if they have user consent.
 
 The data gathered at this level includes:
 
--   **Basic device data**. Helps provide an understanding about the types of Windows devices and the configurations and types of native and virtualized Windows Server 2016 Technical Preview instances in the ecosystem, including:
+-   **Basic device data**. Helps provide an understanding about the types of Windows devices and the configurations and types of native and virtualized Windows Server 2016 Technical Preview in the ecosystem. Examples include:
 
     -   Device attributes, such as camera resolution and display type
 
@@ -156,7 +241,7 @@ The data gathered at this level includes:
 
     -   **General app data and app data for Internet Explorer add-ons**. Includes a list of apps that are installed on a native or virtualized instance of the OS and whether these apps function correctly after an upgrade. This app data includes the app name, publisher, version, and basic details about which files have been blocked from usage.
 
-    -   **App usage data**. Includes how an app is used, including how long an app is used for, when the app has focus, and when the app is started
+    -   **App usage data**. Includes how an app is used, including how long an app is used, when the app has focus, and when the app is started
 
     -   **Internet Explorer add-ons**. Includes a list of Internet Explorer add-ons that are installed on a device and whether these apps will work after an upgrade.
 
@@ -166,13 +251,13 @@ The data gathered at this level includes:
 
     -   **Driver data**. Includes specific driver usage that’s meant to help figure out whether apps and devices will function after upgrading to a new version of the operating system. This can help to determine blocking issues and then help Microsoft and our partners apply fixes and improvements.
 
--   **Store**. Provides information about how the Windows Store performs, including app downloads, installations, and updates. It also includes Windows Store launches, page views, suspend and resumes, and obtaining licenses.
+-   **Windows Store**. Provides information about how the Windows Store performs, including app downloads, installations, and updates. It also includes Windows Store launches, page views, suspend and resumes, and obtaining licenses.
 
 ### Enhanced level
 
 The Enhanced level gathers data about how Windows and apps are used and how they perform. This level also includes data from both the **Basic** and **Security** levels. This level helps to improve the user experience with the operating system and apps. Data from this level can be abstracted into patterns and trends that can help Microsoft determine future improvements.
 
-This is the default level, and the minimum level needed to quickly identify and address Windows, Windows Server, and System Center quality issues.
+This is the default level for Windows 10 Enterprise and Windows 10 Education editions, and the minimum level needed to quickly identify and address Windows, Windows Server, and System Center quality issues.
 
 The data gathered at this level includes:
 
@@ -202,6 +287,15 @@ However, before more data is gathered, Microsoft’s privacy governance team, in
 
 -   All crash dump types, including heap dumps and full dumps.
 
+## Enterprise management
+
+Sharing telemetry data with Microsoft provides many benefits to enterprises, so we do not recommend turning it off. For most enterprise customers, simply adjusting the telemetry level and managing specific components is the best option.
+
+Customers can set the telemetry level in both the user interface and with existing management tools. Users can change the telemetry level in the **Diagnostic and usage data** setting. In the Settings app, it is in **Privacy\Feedback & diagnostics**. They can choose between Basic, Enhanced, and Full. The Security level is not available.
+
+IT pros can use various methods, including Group Policy and Mobile Device Management (MDM), to choose a telemetry level.  If you’re using Windows 10 Enterprise, Windows 10 Education, or Windows Server 2016, the Security telemetry level is available when managing the policy. Setting the telemetry level through policy overrides users’ choices. The remainder of this section describes how to do that.
+
+
 ### Manage your telemetry settings
 
 We do not recommend that you turn off telemetry in your organization as valuable functionality may be impacted, but we recognize that in some scenarios this may be required. Use the steps in this section to do so for Windows, Windows Server, and System Center.
@@ -210,7 +304,7 @@ We do not recommend that you turn off telemetry in your organization as valuable
 
 You can turn on or turn off System Center telemetry gathering. The default is on and the data gathered at this level represents what is gathered by default when System Center telemetry is turned on. However, setting the operating system telemetry level to **Basic** will turn off System Center telemetry, even if the System Center telemetry switch is turned on.
 
-The lowest telemetry setting level supported through management policies is **Security**. The lowest telemetry setting supported through the Settings UI is **Basic**. The default telemetry setting for Windows Server 2016 Technical Preview is **Enhanced.**
+The lowest telemetry setting level supported through management policies is **Security**. The lowest telemetry setting supported through the Settings UI is **Basic**. The default telemetry setting for Windows Server 2016 Technical Preview is **Enhanced**.
 
 ### Configure the operating system telemetry level
 
@@ -218,14 +312,13 @@ You can configure your operating system telemetry settings using the management
 
 Use the appropriate value in the table below when you configure the management policy.
 
-| Value | Level    | Data gathered                                                                                                             |
-|-------|----------|---------------------------------------------------------------------------------------------------------------------------|
-| **0** | Security | Security data only.                                                                                                       |
-| **1** | Basic    | Security data, and basic system and quality data.                                                                         |
-| **2** | Enhanced | Security data, basic system and quality data, and enhanced insights and advanced reliability data.                        |
-| **3** | Full     | Security data, basic system and quality data, enhanced insights and advanced reliability data, and full diagnostics data. |
+| Level    | Data gathered | Value |
+| - | - | -  |
+| Security | Security data only. | **0** |
+| Basic | Security data, and basic system and quality data. | **1** |
+| Enhanced | Security data, basic system and quality data, and enhanced insights and advanced reliability data. | **2** |
+| Full | Security data, basic system and quality data, enhanced insights and advanced reliability data, and full diagnostics data. | **3** |
 
- 
 
 ### Use Group Policy to set the telemetry level
 
@@ -277,19 +370,32 @@ There are a few more settings that you can turn off that may send telemetry info
 
     >**Note:**  Microsoft does not intend to gather sensitive information, such as credit card numbers, usernames and passwords, email addresses, or other similarly sensitive information for Linguistic Data Collection. We guard against such events by using technologies to identify and remove sensitive information before linguistic data is sent from the user's device. If we determine that sensitive information has been inadvertently received, we delete the information.
 
-     
+## Additional resources
 
-## Examples of how Microsoft uses the telemetry data
+FAQs
 
+- [Cortana, Search, and privacy](http://windows.microsoft.com/en-us/windows-10/cortana-privacy-faq)
+- [Windows 10 feedback, diagnostics, and privacy](http://windows.microsoft.com/en-us/windows-10/feedback-diagnostics-privacy-faq)
+- [Windows 10 camera and privacy](http://windows.microsoft.com/en-us/windows-10/camera-privacy-faq)
+- [Windows 10 location service and privacy](http://windows.microsoft.com/en-us/windows-10/location-service-privacy)
+- [Microsoft Edge and privacy](http://windows.microsoft.com/en-us/windows-10/edge-privacy-faq)
+- [Windows 10 speech, inking, typing, and privacy](http://windows.microsoft.com/en-us/windows-10/speech-inking-typing-privacy-faq)
+- [Windows Hello and privacy](http://windows.microsoft.com/en-us/windows-10/windows-hello-privacy-faq)
+- [Wi-Fi Sense](http://windows.microsoft.com/en-us/windows-10/wi-fi-sense-faq)
+- [Windows Update Delivery Optimization](http://windows.microsoft.com/en-us/windows-10/windows-update-delivery-optimization-faq)
 
-### Drive higher application and driver quality in the ecosystem
+Blogs
 
-Telemetry plays an important role in quickly identifying and fixing critical reliability and security issues in our customers’ deployments and configurations. Insights into the telemetry data we gather helps us to quickly identify crashes or hangs associated with a certain application or driver on a given configuration, like a particular storage type (for example, SCSI) or a memory size. For System Center, job usages and statuses can also help us enhance the job workload and the communication between System Center and its managed products. Microsoft’s ability to get this data from customers and drive improvements into the ecosystem helps raise the bar for the quality of System Center, Windows Server applications, Windows apps, and drivers. Real-time data about Windows installations reduces downtime and the cost associated with troubleshooting unreliable drivers or unstable applications.
+- [Privacy and Windows 10](https://blogs.windows.com/windowsexperience/2015/09/28/privacy-and-windows-10)
 
-### Reduce your total cost of ownership and downtime
+Privacy Statement
 
-Telemetry provides a view of which features and services customers use most. For example, the telemetry data provides us with a heat map of the most commonly deployed Windows Server roles, most used Windows features, and which ones are used the least. This helps us make informed decisions on where we should invest our engineering resources to build a leaner operating system. For System Center, understanding the customer environment for management and monitoring will help drive the support compatibilities matrix, such as host and guest OS. This can help you use existing hardware to meet your business needs and reduce your total cost of ownership, as well as reducing downtime associated with security updates.
+- [Microsoft Privacy Statement](https://privacy.microsoft.com/en-us/privacystatement)
 
-### Build features that address our customers’ needs
+TechNet
 
-Telemetry also helps us better understand how customers deploy components, use features, and use services to achieve their business goals. Getting insights from that information helps us prioritize our engineering investments in areas that can directly affect our customers’ experiences and workloads. Some examples include customer usage of containers, storage, and networking configurations associated with Windows Server roles like Clustering and Web. Another example could be to find out when is CPU hyper-threading turned off and the resulting impact. We use the insights to drive improvements and intelligence into some of our management and monitoring solutions, to help customers diagnose quality issues, and save money by making fewer help calls to Microsoft.
\ No newline at end of file
+- [Manage connections from Windows operating system components to Microsoft services](https://technet.microsoft.com/en-us/itpro/windows/manage/manage-connections-from-windows-operating-system-components-to-microsoft-services)
+
+Web Pages
+
+- [Privacy at Microsoft](http://privacy.microsoft.com)
diff --git a/windows/manage/distribute-apps-from-your-private-store.md b/windows/manage/distribute-apps-from-your-private-store.md
index c81973c29f..500ff0c7b4 100644
--- a/windows/manage/distribute-apps-from-your-private-store.md
+++ b/windows/manage/distribute-apps-from-your-private-store.md
@@ -23,29 +23,29 @@ You can make an app available in your private store when you acquire the app, or
 
 **To acquire an app and make it available in your private store**
 
-1.  Sign in to the Store for Business.
+1.  Sign in to the [Store for Business](https://businessstore.microsoft.com).
 
 2.  Click an app and then click **Get the app** to acquire the app for your organization.
 
 3.  You'll have a few options for distributing the app -- choose **Add to your private store where all people in your organization can find and install it.**
 
-    ![](images/wsfb-distribute.png)
+    ![Image showing Distribute options for app in the Windows Store for Business.](images/wsfb-distribute.png)
 
     It will take approximately twelve hours before the app is available in the private store.
 
 **To make an app in inventory available in your private store**
 
-1.  Sign in to the Store for Business.
+1.  Sign in to the [Store for Business](https://businessstore.microsoft.com).
 
 2.  Click **Manage**, and then choose **Inventory**.
 
-    ![](images/wsfb-manageinventory.png)
+    ![Image showing Manage menu in Windows Store for Business.](images/wsfb-manageinventory.png)
 
 3.  Click **Refine**, and then choose **Online**. Store for Business will update the list of apps on the **Inventory** page.
 
 4.  From an app in **Inventory**, click the ellipses under **Action**, and then choose **Add to private store**.
 
-    ![](images/wsfb-inventoryaddprivatestore.png)
+    ![Image showing options from Action for each app in Inventory.](images/wsfb-inventoryaddprivatestore.png)
 
 The value under **Private store** for the app will change to pending. It will take approximately twelve hours before the app is available in the private store.
 
diff --git a/windows/manage/distribute-apps-with-management-tool.md b/windows/manage/distribute-apps-with-management-tool.md
index 484fa6b93b..102b4d6d01 100644
--- a/windows/manage/distribute-apps-with-management-tool.md
+++ b/windows/manage/distribute-apps-with-management-tool.md
@@ -48,14 +48,14 @@ If your vendor doesn’t support the ability to synchronize applications from th
 
 This diagram shows how you can use a management tool to distribute offline-licensed app to employees in your organization. Once synchronized from Store for Business, management tools can use the Windows Management framework to distribute applications to devices.
 
-![](images/wsfb-offline-distribute-mdm.png)
+![Image showing flow for distributing offline-licensed app from Windows Store for Business to employees in your organization.](images/wsfb-offline-distribute-mdm.png)
 
 ## Distribute online-licensed apps
 
 
 This diagram shows how you can use a management tool to distribute an online-licensed app to employees in your organization. Once synchronized from Store for Business, management tools use the Windows Management framework to distribute applications to devices. For Online licensed applications, the management tool calls back in to Store for Business management services to assign an application prior to issuing the policy to install the application.
 
-![](images/wsfb-online-distribute-mdm.png)
+![Image showing flow for distributing online-licensed app from Wndows Store for Business.](images/wsfb-online-distribute-mdm.png)
 
 ## Related topics
 
diff --git a/windows/plan/images/fig1-deferupgrades.png b/windows/manage/images/fig1-deferupgrades.png
similarity index 100%
rename from windows/plan/images/fig1-deferupgrades.png
rename to windows/manage/images/fig1-deferupgrades.png
diff --git a/windows/plan/images/fig2-deploymenttimeline.png b/windows/manage/images/fig2-deploymenttimeline.png
similarity index 100%
rename from windows/plan/images/fig2-deploymenttimeline.png
rename to windows/manage/images/fig2-deploymenttimeline.png
diff --git a/windows/plan/images/fig3-overlaprelease.png b/windows/manage/images/fig3-overlaprelease.png
similarity index 100%
rename from windows/plan/images/fig3-overlaprelease.png
rename to windows/manage/images/fig3-overlaprelease.png
diff --git a/windows/manage/index.md b/windows/manage/index.md
index fa16723bc3..570fd79769 100644
--- a/windows/manage/index.md
+++ b/windows/manage/index.md
@@ -57,7 +57,7 @@ Learn about managing and updating Windows 10.
 <td align="left"><p>Create a runtime provisioning package to apply settings, profiles, and file assets to a device running Windows 10 Pro, Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile, or Windows 10 Mobile Enterprise.</p></td>
 </tr>
 <tr class="odd">
-<td align="left"><p>[Windows 10 servicing options for updates and upgrades](introduction-to-windows-10-servicing.md)</p></td>
+<td align="left"><p>[Windows 10 servicing options](introduction-to-windows-10-servicing.md)</p></td>
 <td align="left"><p>This article describes the new servicing options available in Windows 10, Windows 10 Mobile, and Windows 10 IoT Core (IoT Core) and how they enable enterprises to keep their devices current with the latest feature upgrades. It also covers related topics, such as how enterprises can make better use of Windows Update, and what the new servicing options mean for support lifecycles.</p></td>
 </tr>
 <tr class="even">
diff --git a/windows/manage/introduction-to-windows-10-servicing.md b/windows/manage/introduction-to-windows-10-servicing.md
index 0325ebfeac..8e531b3827 100644
--- a/windows/manage/introduction-to-windows-10-servicing.md
+++ b/windows/manage/introduction-to-windows-10-servicing.md
@@ -10,27 +10,46 @@ ms.pagetype: security, servicing
 author: greg-lindsay
 ---
 
-# Windows 10 servicing options for updates and upgrades
+# Windows 10 servicing options
 
 **Applies to**
 -   Windows 10
 -   Windows 10 IoT Core (IoT Core)
 
-This article describes the new servicing options available in Windows 10 and IoT Core and how they enable enterprises to keep their devices current with the latest feature upgrades. It also covers related topics, such as how enterprises can make better use of Windows Update, and what the new servicing options mean for support lifecycles.
+This article provides detailed information about new servicing options available in Windows 10 and IoT Core. It also provides information on how enterprises can make better use of Windows Update, and what the new servicing options mean for support lifecycles. Before reading this article, you should understand the new Windows 10 servicing model. For an overview of this servicing model, see: [Windows 10 servicing overview](../plan/windows-10-servicing-options.md). 
 
 For Windows 10 current version numbers by servicing option see: [Windows 10 release information](https://technet.microsoft.com/en-us/windows/mt679505.aspx).
-
-**Note**  
-Several of the figures in this article show multiple feature upgrades of Windows being released by Microsoft over time. Be aware that these figures were created with dates that were chosen for illustrative clarity, not for release roadmap accuracy, and should not be used for planning purposes.
  
-## Introduction
+## Key terminology
 
-In enterprise IT environments, the desire to provide users with the latest technologies needs to be balanced with the need for manageability and cost control. In the past, many enterprises managed their Windows deployments homogeneously and performed large-scale upgrades to new releases of Windows (often in parallel with large-scale hardware upgrades) about every three to six years. Today, the rapid evolution of Windows as a platform for device-like experiences is causing businesses to rethink their upgrade strategies. Especially with the release of Windows 10, there are good business reasons to keep a significant portion of your enterprise's devices *current* with the latest release of Windows. For example, during the development of Windows 10, Microsoft:
--   Streamlined the Windows product engineering and release cycle so that Microsoft can deliver the features, experiences, and functionality customers want, more quickly than ever.
--   Created new ways to deliver and install feature upgrades and servicing updates that simplify deployments and on-going management, broaden the base of employees who can be kept current with the latest Windows capabilities and experiences, and lower total cost of ownership.
--   Implemented new servicing options – referred to as Current Branch (CB), Current Branch for Business (CBB), and Long-Term Servicing Branch (LTSB) – that provide pragmatic solutions to keep more devices more current in enterprise environments than was previously possible.
+The following terms are used When discussing the new Windows 10 servicing model:
 
-The remainder of this article provides additional information about each of these areas. This article also provides an overview of the planning implications of the three Windows 10 servicing options (summarized in Table 1) so that IT administrators can be well-grounded conceptually before they start a Windows 10 deployment project.
+<table border="1" cellpadding="2">
+    <tr>
+        <td BGCOLOR="#a0e4fa">**Term**</td>
+        <td BGCOLOR="#a0e4fa">**Description**</td>
+    </tr>
+    <tr>
+        <td>Upgrade</td>
+        <td>A new Windows 10 release that contains additional features and capabilities, released two to three times per year.</td>
+    </tr>
+    <tr>
+        <td>Update</td>
+        <td>Packages of security fixes, reliability fixes, and other bug fixes that are released periodically, typically once a month on Update Tuesday (sometimes referred to as Patch Tuesday). With Windows 10, these are cumulative in nature.</td>
+    </tr>
+    <tr>
+        <td>Branch</td>
+        <td>The windows servicing branch is one of four choices: Windows Insider, Current Branch, Current Branch for Business, or Long-Term Servicing Branch. Branches are determined by the frequency with which the computer is configured to receive feature updates.</td>
+    </tr>
+    <tr>
+        <td>Ring</td>
+        <td>A ring is a groups of PCs that are all on the same branch and have the same update settings. Rings can be used internally by organizations to better control the upgrade rollout process.</td>
+    </tr>
+</table>
+
+## Windows 10 servicing
+
+The following table provides an overview of the planning implications of the three Windows 10 servicing options so that IT administrators can be well-grounded conceptually before they start a Windows 10 deployment project.
 
 Table 1. Windows 10 servicing options
 
@@ -91,7 +110,7 @@ At the end of each approximately four month period, Microsoft executes a set of
 
 Although Windows 10 will enable IT administrators to defer installation of new feature upgrades using Windows Update, enterprises may also want additional control over how and when Windows Update installs releases. With this need in mind, Microsoft [announced Windows Update for Business](http://go.microsoft.com/fwlink/p/?LinkId=624798) in May of 2015. Microsoft designed Windows Update for Business to provide IT administrators with additional Windows Update-centric management capabilities, such as the ability to deploy updates to groups of devices and to define maintenance windows for installing releases. This article will be updated with additional information about the role of Windows Update for Business in servicing Windows 10 devices as it becomes available.
 
-## Windows 10 servicing options
+## Windows 10 servicing branches
 
 Historically, because of the length of time between releases of new Windows versions, and the relatively low number of enterprise devices that were upgraded to newer versions of Windows during their deployment lifetimes, most IT administrators defined servicing as installing the updates that Microsoft published every month. Looking forward, because Microsoft will be publishing new feature upgrades on a continual basis, *servicing* will also include (on some portion of an enterprise's devices) installing new feature upgrades as they become available.
 In fact, when planning to deploy Windows 10 on a device, one of the most important questions for IT administrators to ask is, “What should happen to this device when Microsoft publishes a new feature upgrade?” This is because Microsoft designed Windows 10 to provide businesses with multiple servicing options, centered on enabling different rates of feature upgrade adoption. In particular, IT administrators can configure Windows 10 devices to:
@@ -100,6 +119,144 @@ In fact, when planning to deploy Windows 10 on a device, one of the most import
 -   Receive only servicing updates for the duration of their Windows 10 deployment in order to reduce the number of non-essential changes made to the device. For more information, see [Install servicing updates only by using Long-Term Servicing Branch (LTSB) servicing](#install-updates-ltsb).
 The breakout of a company’s devices by the categories above is likely to vary significantly by industry and other factors. What is most important is that companies can decide what works best for them and can choose different options for different devices.
 
+## Current Branch versus Current Branch for Business
+
+When the development of a new Windows 10 feature upgrade is complete, it is initially offered to Current Branch computers; those computers configured for Current Branch for Business will receive the feature upgrade (with additional fixes) at a later date, generally at least four months later. An additional deferral of at least eight months is available to organizations that use tools to control the update process. During this time, monthly security updates will continue to be made available to machines not yet upgraded.
+
+The process to configure a PC for Current Branch for Business is simple. The **Defer upgrades** setting needs to be configured, either manually (through the Settings app), by using Group Policy, or by using mobile device management (MDM).
+
+![figure 1](images/fig1-deferupgrades.png)
+
+Figure 1. Configure the **Defer upgrades** setting
+
+Most organizations today leverage Windows Server Update Services (WSUS) or System Center Configuration Manager to update their PCs. With Windows 10, this does not need to change; all updates are controlled through approvals or automatic deployment rules configured in those products, so new upgrades will not be deployed until the organization chooses. The **Defer upgrades** setting can function as an additional validation check, so that Current Branch for Business machines that are targeted with a new upgrade prior to the end of the initial four-month deferral period will decline to install it; they can install the upgrade any time within the eight-month window after that initial four-month deferral period.
+
+For computers configured to receive updates from Windows Update directly, the **Defer upgrades** setting directly controls when the PC will be upgraded. Computers that are not configured to defer upgrades will be upgraded at the time of the initial Current Branch release; computers that are configured to defer upgrades will be upgraded four months later.
+
+With Windows 10 it is now possible to manage updates for PCs and tablets that have a higher degree of mobility and are not joined to a domain. For these PCs, you can leverage mobile device management (MDM) services or Windows Update for Business to provide the same type of control provided today with WSUS or Configuration Manager.
+
+For PCs enrolled in a mobile device management (MDM) service, Windows 10 provides new update approval mechanisms that could be leveraged to delay the installation of a new feature upgrade or any other update. Windows Update for Business will eventually provide these and other capabilities to manage upgrades and updates; more details on these capabilities will be provided when they are available later in 2015.
+
+With the release of each Current Branch feature update, new ISO images will be made available. You can use these images to upgrade existing machines or to create new custom images. These feature upgrades will also be published with WSUS to enable simple deployment to devices already running Windows 10.
+
+Unlike previous versions of Windows, the servicing lifetime of Current Branch or Current Branch for Business is finite. You must install new feature upgrades on machines running these branches in order to continue receiving monthly security updates. This requires new ways of thinking about software deployment. It is best to align your deployment schedule with the Current Branch release schedule:
+
+-   Begin your evaluation process with the Windows Insider Program releases.
+-   Perform initial pilot deployments by using the Current Branch.
+-   Expand to broad deployment after the Current Branch for Business is available.
+-   Complete deployments by using that release in advance of the availability of the next Current Branch.
+
+![figure 2](images/fig2-deploymenttimeline.png)
+
+Figure 2. Deployment timeline
+
+Some organizations may require more than 12 months to deploy Windows 10 to all of their existing PCs. To address this, it may be necessary to deploy multiple Windows 10 releases, switching to these new releases during the deployment project. Notice how the timelines can overlap, with the evaluation of one release happening during the pilot and deployment of the previous release:
+
+![figure 3](images/fig3-overlaprelease.png)
+
+Figure 3. Overlapping releases
+
+As a result of these overlapping timelines, organizations can choose which release to deploy. Note though that by continuing for longer with one release, that gives you less time to deploy the subsequent release (to both existing Windows 10 PCs as well as newly-migrated ones), so staying with one release for the full lifetime of that release can be detrimental overall.
+
+## Long-Term Servicing Branch
+
+For specialized devices, Windows 10 Enterprise Long Term Servicing Branch (LTSB) ISO images will be made available. These are expected to be on a variable schedule, less often than CB and CBB releases. Once released, these will be supported with security and reliability fixes for an extended period; no new features will be added over its servicing lifetime. Note that LTSB images will not contain most in-box Universal Windows Apps (for example, Microsoft Edge, Cortana, the Windows Store, the Mail and Calendar apps) because the apps or the services that they use will be frequently updated with new functionality and therefore cannot be supported on PCs running the LTSB OS.
+
+These LTSB images can be used to upgrade existing machines or to create new custom images.
+
+Note that Windows 10 Enterprise LTSB installations fully support the Universal Windows Platform, with the ability to run line-of-business apps created using the Windows SDK, Visual Studio, and related tools capable of creating Universal Windows apps. For apps from other ISVs (including those published in the Windows Store), contact the ISV to confirm if they will provide long-term support for their specific apps.
+
+As mentioned previously, there are few, if any, scenarios where an organization would use the Long-Term Servicing Branch for every PC – or even for a majority of them.
+
+## Windows Insider Program
+
+During the development of a new Windows 10 feature update, preview releases will be made available to Windows Insider Program participants. This enables those participants to try out new features, check application compatibility, and provide feedback during the development process.
+
+To obtain Windows Insider Program builds, the Windows Insider Program participants must opt in through the Settings app, and specify their Microsoft account.
+
+Occasionally (typically as features are made available to those in the Windows Insider Program “slow” ring), new ISO images will be released to enable deployment validation, testing, and image creation.
+
+## Switching between branches
+
+During the life of a particular PC, it may be necessary or desirable to switch between the available branches. Depending on the branch you are using, the exact mechanism for doing this can be different; some will be simple, others more involved.
+
+<table>
+<colgroup>
+<col width="33%" />
+<col width="33%" />
+<col width="33%" />
+</colgroup>
+<thead>
+<tr class="header">
+<th align="left">For a PC that uses…</th>
+<th align="left">Changing to…</th>
+<th align="left">You need to:</th>
+</tr>
+</thead>
+<tbody>
+<tr class="odd">
+<td align="left">Windows Insider Program</td>
+<td align="left">Current Branch</td>
+<td align="left">Wait for the final Current Branch release.</td>
+</tr>
+<tr class="even">
+<td align="left"></td>
+<td align="left">Current Branch for Business</td>
+<td align="left">Not directly possible, because Windows Insider Program machines are automatically upgraded to the Current Branch release at the end of the development cycle.</td>
+</tr>
+<tr class="odd">
+<td align="left"></td>
+<td align="left">Long-Term Servicing Branch</td>
+<td align="left">Not directly possible (requires wipe-and-load).</td>
+</tr>
+<tr class="even">
+<td align="left">Current Branch</td>
+<td align="left">Insider</td>
+<td align="left">Use the Settings app to enroll the device in the Windows Insider Program.</td>
+</tr>
+<tr class="odd">
+<td align="left"></td>
+<td align="left">Current Branch for Business</td>
+<td align="left">Select the <strong>Defer upgrade</strong> setting, or move the PC to a target group or flight that will not receive the next upgrade until it is business ready. Note that this change will not have any immediate impact; it only prevents the installation of the next Current Branch release.</td>
+</tr>
+<tr class="even">
+<td align="left"></td>
+<td align="left">Long-Term Servicing Branch</td>
+<td align="left">Not directly possible (requires wipe-and-load).</td>
+</tr>
+<tr class="odd">
+<td align="left">Current Branch for Business</td>
+<td align="left">Insider</td>
+<td align="left">Use the Settings app to enroll the device in the Windows Insider Program.</td>
+</tr>
+<tr class="even">
+<td align="left"></td>
+<td align="left">Current Branch</td>
+<td align="left">Disable the <strong>Defer upgrade</strong> setting, or move the PC to a target group or flight that will receive the latest Current Branch release.</td>
+</tr>
+<tr class="odd">
+<td align="left"></td>
+<td align="left">Long-Term Servicing Branch</td>
+<td align="left">Not directly possible (requires wipe-and-load).</td>
+</tr>
+<tr class="even">
+<td align="left">Long-Term Servicing Branch</td>
+<td align="left">Insider</td>
+<td align="left">Use media to upgrade to the latest Windows Insider Program build.</td>
+</tr>
+<tr class="odd">
+<td align="left"></td>
+<td align="left">Current Branch</td>
+<td align="left">Use media to upgrade to a later Current Branch build. (Note that the Current Branch build must be a later build.)</td>
+</tr>
+<tr class="even">
+<td align="left"></td>
+<td align="left">Current Branch for Business</td>
+<td align="left">Use media to upgrade to a later Current Branch for Business build (Current Branch build plus fixes). Note that it must be a later build.</td>
+</tr>
+</tbody>
+</table>
+
 ## Plan for Windows 10 deployment
 
 The remainder of this article focuses on the description of the three options outlined above, and their planning implications, in more detail. In practice, IT administrators have to focus on two areas when planning a Windows 10 device deployment:
@@ -111,19 +268,21 @@ The content that follows will provide IT administrators with the context needed
 
 **How Microsoft releases Windows 10 feature upgrades**
 
-When it is time to release a build as a new feature upgrade for Windows 10, Microsoft performs several processes in sequence. The first process involves creating either one or two servicing branches in a source code management system. These branches (shown in Figure 1) are required to produce feature upgrade installation media and servicing update packages that can be deployed on different Windows 10 editions, running in different configurations.
+>Some figures in this article show multiple feature upgrades of Windows being released by Microsoft over time. Be aware that these figures were created with dates that were chosen for illustrative clarity, not for release roadmap accuracy, and should not be used for planning purposes.
 
-![figure 1](images/w10servicing-f1-branches.png)
+When it is time to release a build as a new feature upgrade for Windows 10, Microsoft performs several processes in sequence. The first process involves creating either one or two servicing branches in a source code management system. These branches (shown in Figure 4) are required to produce feature upgrade installation media and servicing update packages that can be deployed on different Windows 10 editions, running in different configurations.
 
-Figure 1. Feature upgrades and servicing branches
+![figure 4](images/w10servicing-f1-branches.png)
 
-In all cases, Microsoft creates a servicing branch (referred to in Figure 1 as Servicing Branch \#1) that is used to produce releases for approximately one year (although the lifetime of the branch will ultimately depend on when Microsoft publishes subsequent feature upgrade releases). If Microsoft has selected the feature upgrade to receive long-term servicing-only support, Microsoft also creates a second servicing branch (referred to in Figure 1 as Servicing Branch \#2) that is used to produce servicing update releases for up to 10 years.
+Figure 4. Feature upgrades and servicing branches
 
-As shown in Figure 2, when Microsoft publishes a new feature upgrade, Servicing Branch \#1 is used to produce the various forms of media needed by OEMs, businesses, and consumers to install Windows 10 Home, Pro, Education, and Enterprise editions. Microsoft also produces the files needed by Windows Update to distribute and install the feature upgrade, along with *targeting* information that instructs Windows Update to only install the files on devices configured for *immediate* installation of feature upgrades.
+In all cases, Microsoft creates a servicing branch (referred to in Figure 4 as Servicing Branch \#1) that is used to produce releases for approximately one year (although the lifetime of the branch will ultimately depend on when Microsoft publishes subsequent feature upgrade releases). If Microsoft has selected the feature upgrade to receive long-term servicing-only support, Microsoft also creates a second servicing branch (referred to in Figure 4 as Servicing Branch \#2) that is used to produce servicing update releases for up to 10 years.
 
-![figure 2](images/win10servicing-fig2-featureupgrade.png)
+As shown in Figure 5, when Microsoft publishes a new feature upgrade, Servicing Branch \#1 is used to produce the various forms of media needed by OEMs, businesses, and consumers to install Windows 10 Home, Pro, Education, and Enterprise editions. Microsoft also produces the files needed by Windows Update to distribute and install the feature upgrade, along with *targeting* information that instructs Windows Update to only install the files on devices configured for *immediate* installation of feature upgrades.
 
-Figure 2. Producing feature upgrades from servicing branches
+![figure 5](images/win10servicing-fig2-featureupgrade.png)
+
+Figure 5. Producing feature upgrades from servicing branches
 
 Approximately four months after publishing the feature upgrade, Microsoft uses Servicing Branch \#1 again to *republish* updated installation media for Windows 10 Pro, Education, and Enterprise editions. The updated media contains the exact same feature upgrade as contained in the original media except Microsoft also includes all the servicing updates that were published since the feature upgrade was first made available. This enables the feature upgrade to be installed on a device more quickly, and in a way that is potentially less obtrusive to users.
 
@@ -131,15 +290,15 @@ Concurrently, Microsoft also changes the way the feature upgrade is published in
 
 **How Microsoft publishes the Windows 10 Enterprise LTSB Edition**
 
-If Microsoft has selected the feature upgrade to receive long-term servicing support, Servicing Branch \#2 is used to publish the media needed to install the Windows 10 Enterprise LTSB edition. The time between releases of feature upgrades with long-term servicing support will vary between one and three years, and is strongly influenced by input from customers regarding the readiness of the release for long-term enterprise deployment. Figure 2 shows the Windows 10 Enterprise LTSB edition being published at the same time as the other Windows 10 editions, which mirrors the way editions were actually published for Windows 10 in July of 2015. It is important to note that this media is never published to Windows Update for deployment. Installations of the Enterprise LTSB edition on devices must be performed another way.
+If Microsoft has selected the feature upgrade to receive long-term servicing support, Servicing Branch \#2 is used to publish the media needed to install the Windows 10 Enterprise LTSB edition. The time between releases of feature upgrades with long-term servicing support will vary between one and three years, and is strongly influenced by input from customers regarding the readiness of the release for long-term enterprise deployment. Figure 5 shows the Windows 10 Enterprise LTSB edition being published at the same time as the other Windows 10 editions, which mirrors the way editions were actually published for Windows 10 in July of 2015. It is important to note that this media is never published to Windows Update for deployment. Installations of the Enterprise LTSB edition on devices must be performed another way.
 
 **How Microsoft releases Windows 10 servicing updates**
 
-As shown in Figure 3, servicing branches are also used by Microsoft to produce servicing updates containing fixes for security vulnerabilities and other important issues. Servicing updates are published in a way that determines the Windows 10 editions on which they can be installed. For example, servicing updates produced from a given servicing branch can only be installed on devices running a Windows 10 edition produced from the same servicing branch. In addition, because Windows 10 Home does not support deferred installation of feature upgrades, servicing updates produced from Servicing Branch \#1 are targeted at devices running Windows 10 Home only until Microsoft publishes feature upgrades for deferred installation.
+As shown in Figure 6, servicing branches are also used by Microsoft to produce servicing updates containing fixes for security vulnerabilities and other important issues. Servicing updates are published in a way that determines the Windows 10 editions on which they can be installed. For example, servicing updates produced from a given servicing branch can only be installed on devices running a Windows 10 edition produced from the same servicing branch. In addition, because Windows 10 Home does not support deferred installation of feature upgrades, servicing updates produced from Servicing Branch \#1 are targeted at devices running Windows 10 Home only until Microsoft publishes feature upgrades for deferred installation.
 
-![figure 3](images/win10servicing-fig3.png)
+![figure 6](images/win10servicing-fig3.png)
 
-Figure 3. Producing servicing updates from servicing branches
+Figure 6. Producing servicing updates from servicing branches
 
 **Release installation alternatives**
 
@@ -162,24 +321,24 @@ Because there is a one-to-one mapping between servicing options and servicing br
 
 Although Microsoft is currently planning to release approximately two to three feature upgrades per year, the actual frequency and timing of releases will vary. Because the servicing lifetimes of feature upgrades typically end when the servicing lifetimes of other, subsequent feature upgrades begin, the lengths of servicing lifetimes will also vary.
 
-![figure 4](images/win10servicing-fig4-upgradereleases.png)
+![figure 7](images/win10servicing-fig4-upgradereleases.png)
 
-Figure 4. Example release cadence across multiple feature upgrades
+Figure 7. Example release cadence across multiple feature upgrades
 
 To show the variability of servicing lifetimes, and show the paths that feature upgrade installations will take when Windows Update and Windows Server Update Services are used for deployments, Figure 4 contains three feature upgrade releases (labeled *X*, *Y*, and *Z*) and their associated servicing branches. The time period between publishing X and Y is four months, and the time period between publishing Y and Z is six months. X and Z have long-term servicing support, and Y has shorter-term servicing support only.
 
-The same underlying figure will be used in subsequent figures to show all three servicing options in detail. It is important to note that Figure 4 is provided for illustration of servicing concepts only and should not be used for actual Windows 10 release planning.
+The same underlying figure will be used in subsequent figures to show all three servicing options in detail. It is important to note that Figure 7 is provided for illustration of servicing concepts only and should not be used for actual Windows 10 release planning.
 
 To simplify the servicing lifetime and feature upgrade behavior explanations that follow, this document refers to branch designations for a specific feature upgrade as the +0 versions, the designations for the feature upgrade after the +0 version as the +1 (or successor) versions, and the designation for the feature upgrade after the +1 version as the +2 (or second successor) versions.
 
 ### <a href="" id="immediate-upgrade-cb"></a>
 
 **Immediate feature upgrade installation with Current Branch (CB) servicing**
-As shown in Figure 5, the Current Branch (CB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft publishes a feature upgrade targeted for devices configured for *immediate* installation and ends when Microsoft publishes the *successor* feature upgrade targeted for devices configured for *immediate* installation.
+As shown in Figure 8, the Current Branch (CB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft publishes a feature upgrade targeted for devices configured for *immediate* installation and ends when Microsoft publishes the *successor* feature upgrade targeted for devices configured for *immediate* installation.
 
-![figure 5](images/win10servicing-fig5.png)
+![figure 8](images/win10servicing-fig5.png)
 
-Figure 5. Immediate installation with Current Branch Servicing
+Figure 8. Immediate installation with Current Branch Servicing
 
 The role of Servicing Branch \#1 during the CB period is to produce feature upgrades and servicing updates for Windows 10 devices configured for *immediate* installation of new feature upgrades. Microsoft refers to devices configured this way as being *serviced from CBs*. The Windows 10 editions that support servicing from CBs are Home, Pro, Education, and Enterprise. The Current Branch designation is intended to reflect the fact that devices serviced using this approach will be kept as current as possible with respect to the latest Windows 10 feature upgrade release.
 Windows 10 Home supports Windows Update for release deployment. Windows 10 editions (Pro, Education, and Enterprise) support Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
@@ -191,11 +350,11 @@ It is important to note that devices serviced from CBs must install two to three
 ### <a href="" id="deferred-upgrade-cbb"></a>
 
 **Deferred feature upgrade installation with Current Branch for Business (CBB) servicing**
-As shown in Figure 6, the Current Branch for Business (CBB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft republishes a feature upgrade targeted for devices configured for *deferred* installation and ends when Microsoft republishes the *second successor* feature upgrade targeted for devices configured for *deferred* installation.
+As shown in Figure 9, the Current Branch for Business (CBB) designation refers to Servicing Branch \#1 during the period that starts when Microsoft republishes a feature upgrade targeted for devices configured for *deferred* installation and ends when Microsoft republishes the *second successor* feature upgrade targeted for devices configured for *deferred* installation.
 
-![figure 6](images/win10servicing-fig6.png)
+![figure 9](images/win10servicing-fig6.png)
 
-Figure 6. Deferred installation with Current Branch for Business Servicing
+Figure 9. Deferred installation with Current Branch for Business Servicing
 
 The role of Servicing Branch \#1 during the CBB period is to produce feature upgrades and servicing updates for Windows 10 devices configured for *deferred* installation of new feature upgrades. Microsoft refers to devices configured this way as being *serviced from CBBs*. The Windows 10 editions that support servicing from CBBs are Pro, Education, and Enterprise. The Current Branch for Business designation is intended to reflect the fact that many businesses require IT administrators to test feature upgrades prior to deployment, and servicing devices from CBBs is a pragmatic solution for businesses with testing constraints to remain as current as possible.
 Windows 10 (Pro, Education, and Enterprise editions) support release deployment by using Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
@@ -208,11 +367,11 @@ Microsoft designed Windows 10 servicing lifetime policies so that CBBs will rec
 
 **Install servicing updates only by using Long-Term Servicing Branch (LTSB) servicing**
 
-As shown in Figure 7, the Long-Term Servicing Branch (LTSB) designation refers to Servicing Branch \#2 from beginning to end. LTSBs begin when a feature upgrade with long-term support is published by Microsoft and end after 10 years. It is important to note that only the Windows 10 Enterprise LTSB edition supports long-term servicing, and there are important differences between this edition and other Windows 10 editions regarding upgradability and feature set (described below in the [Considerations when configuring devices for servicing updates only](#servicing-only) section).
+As shown in Figure 10, the Long-Term Servicing Branch (LTSB) designation refers to Servicing Branch \#2 from beginning to end. LTSBs begin when a feature upgrade with long-term support is published by Microsoft and end after 10 years. It is important to note that only the Windows 10 Enterprise LTSB edition supports long-term servicing, and there are important differences between this edition and other Windows 10 editions regarding upgradability and feature set (described below in the [Considerations when configuring devices for servicing updates only](#servicing-only) section).
 
-![figure 7](images/win10servicing-fig7.png)
+![figure 10](images/win10servicing-fig7.png)
 
-Figure 7. Servicing updates only using LTSB Servicing
+Figure 10. Servicing updates only using LTSB Servicing
 
 The role of LTSBs is to produce servicing updates for devices running Windows 10 configured to install servicing updates only. Devices configured this way are referred to as being *serviced from LTSBs*. The Long-Term Servicing Branch designation is intended to reflect the fact that this servicing option is intended for scenarios where changes to software running on devices must be limited to essential updates (such as those for security vulnerabilities and other important issues) for the duration of deployments.
 Windows 10 Enterprise LTSB supports release deployment by using Windows Update, Windows Server Update Services, Configuration Manager, and other configuration management systems:
diff --git a/windows/manage/manage-access-to-private-store.md b/windows/manage/manage-access-to-private-store.md
index 47ddaea3ef..8e2f813d33 100644
--- a/windows/manage/manage-access-to-private-store.md
+++ b/windows/manage/manage-access-to-private-store.md
@@ -23,7 +23,7 @@ Organizations might want control the set of apps that are available to their emp
 
 The private store is a feature in Store for Business that organizations receive during the sign up process. When admins add apps to the private store, all employees in the organization can view and download the apps. Your private store is available as a tab in the Windows Store, and is usually named for your company or organization. Only apps with online licenses can be added to the private store. Your private store looks something like this:
 
-![](images/wsfb-wsappprivatestore.png)
+![Image showing the Windows Store app, with a private store tab highlighted.](images/wsfb-wsappprivatestore.png)
 
 Organizations using an MDM to manage apps can use a policy to show only the private store. When your MDM supports the Store for Business, the MDM can use the [Policy CSP](https://msdn.microsoft.com/library/windows/hardware/dn904962.aspx#group-policy-table). More specifically, the **ApplicationManagement/RequirePrivateStoreOnly** policy.
 
diff --git a/windows/manage/manage-connections-from-windows-operating-system-components-to-microsoft-services.md b/windows/manage/manage-connections-from-windows-operating-system-components-to-microsoft-services.md
index f3194a4699..f127fe3045 100644
--- a/windows/manage/manage-connections-from-windows-operating-system-components-to-microsoft-services.md
+++ b/windows/manage/manage-connections-from-windows-operating-system-components-to-microsoft-services.md
@@ -6,6 +6,7 @@ keywords: privacy, manage connections to Microsoft
 ms.prod: w10
 ms.mktglfcycl: manage
 ms.sitesec: library
+LocalizationPriority: High
 author: brianlic-msft
 ---
 
@@ -309,7 +310,7 @@ You can prevent Windows from setting the time automatically.
 
     -or-
 
--   Create a REG\_SZ registry setting in **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\Parameters** with a value of **NoSync**.
+-   Create a REG\_SZ registry setting in **HKEY\_LOCAL\_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\W32Time\\Parameters\\Type** with a value of **NoSync**.
 
 ### <a href="" id="bkmk-devinst"></a>3. Device metadata retrieval
 
diff --git a/windows/manage/manage-corporate-devices.md b/windows/manage/manage-corporate-devices.md
index 901a3beb11..dbc5ed0c8a 100644
--- a/windows/manage/manage-corporate-devices.md
+++ b/windows/manage/manage-corporate-devices.md
@@ -97,7 +97,7 @@ For more information about the MDM protocols, see [Mobile device management](htt
 
 [How to bulk-enroll devices with On-premises Mobile Device Management in System Center Configuration Manager](https://technet.microsoft.com/en-us/library/mt627898.aspx)
 
-[Windows 10, Azure AD and Microsoft Intune: Automatic MDM Enrollment](http://go.microsoft.com/fwlink/p/?LinkId=623321)
+[Azure AD, Microsoft Intune and Windows 10 - Using the cloud to modernize enterprise mobility](https://blogs.technet.microsoft.com/enterprisemobility/2015/06/12/azure-ad-microsoft-intune-and-windows-10-using-the-cloud-to-modernize-enterprise-mobility/)
 
 [Microsoft Intune End User Enrollment Guide](http://go.microsoft.com/fwlink/p/?LinkID=617169)
 
diff --git a/windows/manage/manage-private-store-settings.md b/windows/manage/manage-private-store-settings.md
index 1eb1190a30..6132f1e513 100644
--- a/windows/manage/manage-private-store-settings.md
+++ b/windows/manage/manage-private-store-settings.md
@@ -19,9 +19,9 @@ author: TrudyHa
 
 The private store is a feature in the Windows Store for Business that organizations receive during the sign up process. When admins add apps to the private store, all employees in the organization can view and download the apps. Only online-licensed apps can be distributed from your private store.
 
-The name of your private store is shown on a tab in the Windows Store.
+The name of your private store is shown on a tab in the Windows Store app.
 
-![](images/wsfb-wsappprivatestore.png)
+![Image showing Windows Store app with private store tab highlighted.](images/wsfb-wsappprivatestore.png)
 
 You can change the name of your private store in Store for Business.
 
@@ -33,13 +33,13 @@ You can change the name of your private store in Store for Business.
 
     You'll see your private store name.
 
-    ![](images/wsfb-privatestore.png)
+    ![Image showing Private store page in Windows Store for Business.](images/wsfb-privatestore.png)
 
 3.  Click **Change**.
 
 4.  Type a new display name for your private store, and click **Save**.
 
-    ![](images/wsfb-renameprivatestore.png)
+    ![Image showing Private store dialog used to change private store display name.](images/wsfb-renameprivatestore.png)
 
  
 
diff --git a/windows/manage/roles-and-permissions-windows-store-for-business.md b/windows/manage/roles-and-permissions-windows-store-for-business.md
index 4fbfcc521e..92d9f7e5e8 100644
--- a/windows/manage/roles-and-permissions-windows-store-for-business.md
+++ b/windows/manage/roles-and-permissions-windows-store-for-business.md
@@ -204,11 +204,11 @@ These permissions allow people to:
 
 2.  Click **Settings**, and then choose **Permissions**.
 
-    ![](images/wsfb-settings-permissions.png)
+    ![Image showing Permissions page in Windows Store for Business.](images/wsfb-settings-permissions.png)
 
 3.  Click **Add people**, type a name, choose the role you want to assign, and click **Save** .
 
-    ![](images/wsfb-permissions-assignrole.png)
+    ![Image showing Assign roles to people box in Windows Store for Business.](images/wsfb-permissions-assignrole.png)
 
 4.  
 
diff --git a/windows/manage/sign-up-windows-store-for-business.md b/windows/manage/sign-up-windows-store-for-business.md
index 89ca4e135b..643d42eddf 100644
--- a/windows/manage/sign-up-windows-store-for-business.md
+++ b/windows/manage/sign-up-windows-store-for-business.md
@@ -34,7 +34,7 @@ Before signing up for the Store for Business, make sure you're the global admini
 
     -   If you already have an Azure AD directory, you'll [sign in to Store for Business](#sign-in), and then accept Store for Business terms.
 
-    ![](images/wsfb-landing.png)
+    ![Image showing Windows Store for Business page with invitation to sign up, or sign in.](images/wsfb-landing.png)
 
     **To sign up for Azure AD accounts through Office 365 for Business**
 
@@ -44,43 +44,43 @@ Before signing up for the Store for Business, make sure you're the global admini
 
         Type the required info and click **Next.**
 
-        ![](images/wsfb-onboard-1.png)
+        ![Image showing Welcome page for sign up process.](images/wsfb-onboard-1.png)
 
     -   Step 2: Create an ID.
 
         We'll use info you provided on the previous page to build your user ID. Check the info and click **Next**.
 
-        ![](images/wsfb-onboard-2.png)
+        ![Image showing Create your user ID page for sign up process.](images/wsfb-onboard-2.png)
 
     -   Step 3: You're in.
 
         Let us know how you'd like to receive a verification code, and click either **Text me**, or **Call me**. We'll send you a verification code
 
-        ![](images/wsfb-onboard-3.png)
+        ![Image showing confirmation page as part of sign up process.](images/wsfb-onboard-3.png)
 
     -   Verification.
 
         Type your verification code and click **Create my account**.
 
-        ![](images/wsfb-onboard-4.png)
+        ![Image showing verification code step.](images/wsfb-onboard-4.png)
 
     -   Save this info.
 
         Be sure to save the portal sign-in page and your user ID info. Click **You're ready to go**.
 
-        ![](images/wsfb-onboard-5.png)
+        ![Image showing sign-in page and user ID for Windows Store for Business. ](images/wsfb-onboard-5.png)
 
     -   At this point, you'll have an Azure AD directory created with one user account. That user account is the global administrator. You can use that account to sign in to Store for Business.
 
 2.  <a href="" id="sign-in"></a>Sign in with your Azure AD account.
 
-    ![](images/wsfb-onboard-7.png)
+    ![Image showing sign-in page for Windows Store for Business.](images/wsfb-onboard-7.png)
 
 3.  <a href="" id="accept-terms"></a>Read through and accept Store for Business terms.
 
 4.  Welcome to the Store for Business. Click **Next** to continue.
 
-    ![](images/wsfb-firstrun.png)
+    ![Image showing welcome message for Windows Store for Business.](images/wsfb-firstrun.png)
 
 ### Next steps
 
diff --git a/windows/plan/TOC.md b/windows/plan/TOC.md
index d6212238a6..fc128ba315 100644
--- a/windows/plan/TOC.md
+++ b/windows/plan/TOC.md
@@ -1,6 +1,6 @@
 # [Plan for Windows 10 deployment](index.md)
 ## [Change history for Plan for Windows 10 deployment](change-history-for-plan-for-windows-10-deployment.md)
-## [Windows 10 servicing options](windows-10-servicing-options.md)
+## [Windows 10 servicing overview](windows-10-servicing-options.md)
 ## [Windows 10 deployment considerations](windows-10-deployment-considerations.md)
 ## [Windows 10 compatibility](windows-10-compatibility.md)
 ## [Windows 10 infrastructure requirements](windows-10-infrastructure-requirements.md)
diff --git a/windows/plan/best-practice-recommendations-for-windows-to-go.md b/windows/plan/best-practice-recommendations-for-windows-to-go.md
index c9cc2ac741..33789da365 100644
--- a/windows/plan/best-practice-recommendations-for-windows-to-go.md
+++ b/windows/plan/best-practice-recommendations-for-windows-to-go.md
@@ -5,7 +5,7 @@ ms.assetid: 05e6e0ab-94ed-4c0c-a195-0abd006f0a86
 keywords: best practices, USB, device, boot
 ms.prod: w10
 ms.mktglfcycl: plan
-pagetype: mobility
+ms.pagetype: mobility
 ms.sitesec: library
 author: mtniehaus
 ---
diff --git a/windows/plan/change-history-for-plan-for-windows-10-deployment.md b/windows/plan/change-history-for-plan-for-windows-10-deployment.md
index 4f0b96a684..51c36c6953 100644
--- a/windows/plan/change-history-for-plan-for-windows-10-deployment.md
+++ b/windows/plan/change-history-for-plan-for-windows-10-deployment.md
@@ -13,6 +13,13 @@ author: TrudyHa
 
 This topic lists new and updated topics in the [Plan for Windows 10 deployment](index.md) documentation for [Windows 10 and Windows 10 Mobile](../index.md).
 
+## July 2016
+
+
+| New or changed topic                                                                                                                             | Description |
+|--------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
+| [Windows 10 servicing overview](windows-10-servicing-options.md) | Content on this page was summarized. Detailed content about servicing branches was moved to the [Windows 10 servicing options](../manage/introduction-to-windows-10-servicing.md) page. |
+
 ## May 2016
 
 
diff --git a/windows/plan/index.md b/windows/plan/index.md
index e57a04c1cb..e8c8cdb020 100644
--- a/windows/plan/index.md
+++ b/windows/plan/index.md
@@ -16,7 +16,7 @@ Windows 10 provides new deployment capabilities, scenarios, and tools by buildi
 |Topic |Description |
 |------|------------|
 |[Change history for Plan for Windows 10 deployment](change-history-for-plan-for-windows-10-deployment.md) |This topic lists new and updated topics in the Plan for Windows 10 deployment documentation for [Windows 10 and Windows 10 Mobile](../index.md). |
-|[Windows 10 servicing options](windows-10-servicing-options.md) |Windows 10 provides a new model for organizations to deploy and upgrade Windows by providing updates to features and capabilities through a continual process. |
+|[Windows 10 servicing overview](windows-10-servicing-options.md) |Windows 10 provides a new model for organizations to deploy and upgrade Windows by providing updates to features and capabilities through a continual process. |
 |[Windows 10 deployment considerations](windows-10-deployment-considerations.md) |There are new deployment options in Windows 10 that help you simplify the deployment process and automate migration of existing settings and applications. |
 |[Windows 10 compatibility](windows-10-compatibility.md) |Windows 10 will be compatible with most existing PC hardware; most devices running Windows 7, Windows 8, or Windows 8.1 will meet the requirements for Windows 10. |
 |[Windows 10 infrastructure requirements](windows-10-infrastructure-requirements.md) |There are specific infrastructure requirements to deploy and manage Windows 10 that should be in place prior to significant Windows 10 deployments within your organization. |
diff --git a/windows/plan/windows-10-servicing-options.md b/windows/plan/windows-10-servicing-options.md
index 2e67c97c04..6ac55f7ffc 100644
--- a/windows/plan/windows-10-servicing-options.md
+++ b/windows/plan/windows-10-servicing-options.md
@@ -7,56 +7,42 @@ ms.prod: w10
 ms.mktglfcycl: plan
 ms.pagetype: servicing
 ms.sitesec: library
-author: mtniehaus
+author: greg-lindsay
 ---
 
-# Windows 10 servicing options
-
+# Windows 10 servicing overview
 
 **Applies to**
-
 -   Windows 10
 -   Windows 10 Mobile
 
-Windows 10 provides a new model for organizations to deploy and upgrade Windows by providing updates to features and capabilities through a continual process.
+This topic provides an overview of the new servicing model for Windows 10. For more detailed information about this model, refer to [Windows 10 servicing options](../manage/introduction-to-windows-10-servicing.md).
 
-Traditionally, new versions of Windows have been released every few years. The deployment of those new versions within an organization would then become a project, either by leveraging a “wipe and load” process to deploy the new operating system version to existing machines, or by migrating to the new operating system version as part of the hardware replacement cycle. Either way, organizations would invest significant time and effort to complete the required tasks.
+## The Windows servicing model
 
-With Windows 10, a new model is being adopted. Instead of new features being added only in new releases that happen every few years, the goal is to provide new features two to three times per year, continually providing new capabilities while maintaining a high level of hardware and application compatibility. This new model, referred to as Windows as a service, requires organizations to rethink how they deploy and upgrade Windows. It is no longer a project that happens “every few years”; it is a continual process.
+Traditionally, new versions of Windows have been released every few years. The deployment of those new versions within an organization would then become a project, either by leveraging a "wipe and load" process to deploy the new operating system version to existing computers, or by migrating to the new operating system version as part of the hardware replacement cycle. Either way, a significant amount of time and effort was required to complete these tasks.
 
-To support this process, you need to use simpler deployment methods. By combining these simpler methods (for example, in-place upgrade) with new techniques to deploy in phases to existing devices, you can reduce the amount of effort required overall, by taking the effort that used to be performed as part of a traditional deployment project and spreading it across a broad period of time.
+With Windows 10, a new model is being adopted. This new model, referred to as "Windows as a service," requires organizations to rethink how they deploy and upgrade Windows. It is no longer a project that happens every few years, it is a continual process. 
 
-## Key terminology
+## Windows as a service
 
+Instead of new features being added only in new releases that happen every few years, the goal of Windows as a service is to continually provide new capabilities. New features are provided or updated two to three times per year, while maintaining a high level of hardware and application compatibility. 
 
-With the shift to this new Windows as a service model, it is important to understand the distinction between two key terms:
+This new model uses simpler deployment methods, reducing the overall amount of effort required for Windows servicing. By combining these simpler methods (such as in-place upgrade) with new techniques to deploy upgrades in phases to existing devices, the effort that used to be performed as part of a traditional deployment project is spread across a broad period of time.
 
--   **Upgrade**. A new Windows 10 release that contains additional features and capabilities, released two to three times per year.
+## Windows 10 servicing branches
 
--   **Update**. Packages of security fixes, reliability fixes, and other bug fixes that are released periodically, typically once a month on Update Tuesday (sometimes referred to as Patch Tuesday). With Windows 10, these are cumulative in nature.
+The concept of branching goes back many years, and represents how Windows has traditionally been written and serviced. Each release of Windows was from a particular branch of the Windows code, and updates would be made to that release for the lifecycle of that release. This concept still applies now with Windows 10, but is much more visible because it is incorporated directly into the servicing model.
 
-In addition to these terms, some additional concepts need to be understood:
-
--   **Branches**. The concept of “branching” goes back many years, and represents how Windows has traditionally been written and serviced: Each release was from a particular branch of the Windows code, and updates would be made to that release for the lifecycle of that release. This concept still applies now with Windows 10, but is much more visible because of the increased frequency of upgrades.
-
--   **Rings**. The concept of “rings” defines a mechanism for Windows 10 deployment to targeted groups of PCs; each ring represents another group. These are used as part of the release mechanism for new Windows 10 upgrades, and should be used internally by organizations to better control the upgrade rollout process.
-
-## Windows 10 branch overview
-
-
-To support different needs and use cases within your organization, you can select among different branches:
+Microsoft has implemented the following new servicing options in Windows 10:
 
+**Windows Insider Program**: To see new features before they are released, to provide feedback on those new features, and to initially validate compatibility with existing applications and hardware, a small number of PCs can leverage the Windows Insider Program branch. These are typically dedicated lab machines used for IT testing, secondary PCs used by IT administrators, and other non-critical devices.<BR>
+**Current Branch (CB)**: For early adopters, IT teams, and other broader piloting groups, the Current Branch (CB) can be used to further validate application compatibility and newly-released features.<BR>
+**Current Branch for Business (CBB)**. For the majority of people in an organization, the Current Branch for Business (CBB) allows for a staged deployment of new features over a longer period of time.<BR>
+**Long-Term Servicing Branch (LTSB)**: For critical or specialized devices (for example, operation of factory floor machinery, point-of-sale systems, automated teller machines), the Long-Term Servicing Branch (LTSB) provides a version of Windows 10 Enterprise that receives no new features, while continuing to be supported with security and other updates for a long time. (Note that the Long-Term Servicing Branch is a separate Windows 10 Enterprise image, with many in-box apps, including Microsoft Edge, Cortana, and Windows Store, removed.)<BR>
 ![branches](images/branch.png)
 
--   **Windows Insider Program**. To see new features before they are released, to provide feedback on those new features, and to initially validate compatibility with existing applications and hardware, small numbers of PCs can leverage the Windows Insider Program branch. These would typically be dedicated lab machines used for IT testing, secondary PCs used by IT administrators, and other non-critical devices.
-
--   **Current Branch**. For early adopters, IT teams, and other broader piloting groups, the Current Branch (CB) can be used to further validate application compatibility and newly-released features.
-
--   **Current Branch for Business**. For the majority of people in an organization, the Current Branch for Business (CBB) allows for a staged deployment of new features over a longer period of time.
-
--   **Long-Term Servicing Branch**. For critical or specialized devices (for example, operation of factory floor machinery, point-of-sale systems, automated teller machines), the Long-Term Servicing Branch (LTSB) provides a version of Windows 10 Enterprise that receives no new features, while continuing to be supported with security and other updates for a long time. (Note that the Long-Term Servicing Branch is a separate Windows 10 Enterprise image, with many in-box apps, including Microsoft Edge, Cortana, and Windows Store, removed.)
-
-Most organizations will leverage all of these choices, with the mix determined by how individual PCs are used. Some examples:
+These servicing options provide pragmatic solutions to keep more devices more current in enterprise environments than was previously possible. Most organizations will leverage all of these choices, with the mix determined by how individual PCs are used. Some examples are shown in the table below:
 
 | Industry           | Windows Insider Program | Current Branch | Current Branch for Business | Long-Term Servicing Branch |
 |--------------------|-------------------------|----------------|-----------------------------|----------------------------|
@@ -65,10 +51,8 @@ Most organizations will leverage all of these choices, with the mix determined b
 | Pharmaceuticals    | &lt;1%                  | 10%            | 50%                         | 40%                        |
 | Consulting         | 10%                     | 50%            | 35%                         | 5%                         |
 | Software developer | 30%                     | 60%            | 5%                          | 5%                         |
-
- 
-
-Because every organization is different, the exact breakdown will vary even within a specific industry; these should be considered only examples, not specific recommendations. To determine the appropriate mix for a specific organization, profile how individual PCs are used within the organization, and target them with the appropriate branch.
+<BR>
+Because every organization is different, the exact breakdown will vary even within a specific industry. The examples shown above should not be taken as specific recommendations. To determine the appropriate mix for a specific organization, profile how individual PCs are used within the organization, and target them with the appropriate branch.
 
 -   Retailers often have critical devices (for example, point-of-sale systems) in stores which results in higher percentages of PCs on the Long-Term Servicing Branch. But those used by information workers in support of the retail operations would leverage Current Branch for Business to receive new features.
 
@@ -82,169 +66,12 @@ Because every organization is different, the exact breakdown will vary even with
 
 Note that there are few, if any, scenarios where an entire organization would use the Long-Term Servicing Branch for all PCs – or even for a majority of them.
 
-For more information about the Windows as a service model, refer to [Windows 10 servicing options for updates and upgrades](../manage/introduction-to-windows-10-servicing.md).
+With these new servicing options, Microsoft streamlined the Windows product engineering and release cycle so that Microsoft can deliver new features, experiences, and functionality more quickly than ever. Microsoft also created new ways to deliver and install feature upgrades and servicing updates that simplify deployments and on-going management, broaden the base of employees who can be kept current with the latest Windows capabilities and experiences, and lower total cost of ownership.
 
-## Current Branch versus Current Branch for Business
-
-
-When the development of a new Windows 10 feature upgrade is complete, it is initially offered to Current Branch computers; those computers configured for Current Branch for Business will receive the feature upgrade (with additional fixes) at a later date, generally at least four months later. An additional deferral of at least eight months is available to organizations that use tools to control the update process. During this time, monthly security updates will continue to be made available to machines not yet upgraded.
-
-The process to configure a PC for Current Branch for Business is simple. The **Defer upgrades** setting needs to be configured, either manually (through the Settings app), by using Group Policy, or by using mobile device management (MDM).
-
-![figure 1](images/fig1-deferupgrades.png)
-
-Figure 1. Configure the **Defer upgrades** setting
-
-Most organizations today leverage Windows Server Update Services (WSUS) or System Center Configuration Manager to update their PCs. With Windows 10, this does not need to change; all updates are controlled through approvals or automatic deployment rules configured in those products, so new upgrades will not be deployed until the organization chooses. The **Defer upgrades** setting can function as an additional validation check, so that Current Branch for Business machines that are targeted with a new upgrade prior to the end of the initial four-month deferral period will decline to install it; they can install the upgrade any time within the eight-month window after that initial four-month deferral period.
-
-For computers configured to receive updates from Windows Update directly, the **Defer upgrades** setting directly controls when the PC will be upgraded. Computers that are not configured to defer upgrades will be upgraded at the time of the initial Current Branch release; computers that are configured to defer upgrades will be upgraded four months later.
-
-With Windows 10 it is now possible to manage updates for PCs and tablets that have a higher degree of mobility and are not joined to a domain. For these PCs, you can leverage mobile device management (MDM) services or Windows Update for Business to provide the same type of control provided today with WSUS or Configuration Manager.
-
-For PCs enrolled in a mobile device management (MDM) service, Windows 10 provides new update approval mechanisms that could be leveraged to delay the installation of a new feature upgrade or any other update. Windows Update for Business will eventually provide these and other capabilities to manage upgrades and updates; more details on these capabilities will be provided when they are available later in 2015.
-
-With the release of each Current Branch feature update, new ISO images will be made available. You can use these images to upgrade existing machines or to create new custom images. These feature upgrades will also be published with WSUS to enable simple deployment to devices already running Windows 10.
-
-Unlike previous versions of Windows, the servicing lifetime of Current Branch or Current Branch for Business is finite. You must install new feature upgrades on machines running these branches in order to continue receiving monthly security updates. This requires new ways of thinking about software deployment. It is best to align your deployment schedule with the Current Branch release schedule:
-
--   Begin your evaluation process with the Windows Insider Program releases.
-
--   Perform initial pilot deployments by using the Current Branch.
-
--   Expand to broad deployment after the Current Branch for Business is available.
-
--   Complete deployments by using that release in advance of the availability of the next Current Branch.
-
-![figure 2](images/fig2-deploymenttimeline.png)
-
-Figure 2. Deployment timeline
-
-Some organizations may require more than 12 months to deploy Windows 10 to all of their existing PCs. To address this, it may be necessary to deploy multiple Windows 10 releases, switching to these new releases during the deployment project. Notice how the timelines can overlap, with the evaluation of one release happening during the pilot and deployment of the previous release:
-
-![figure 3](images/fig3-overlaprelease.png)
-
-Figure 3. Overlapping releases
-
-As a result of these overlapping timelines, organizations can choose which release to deploy. Note though that by continuing for longer with one release, that gives you less time to deploy the subsequent release (to both existing Windows 10 PCs as well as newly-migrated ones), so staying with one release for the full lifetime of that release can be detrimental overall.
-
-## Long-Term Servicing Branch
-
-
-For specialized devices, Windows 10 Enterprise Long Term Servicing Branch (LTSB) ISO images will be made available. These are expected to be on a variable schedule, less often than CB and CBB releases. Once released, these will be supported with security and reliability fixes for an extended period; no new features will be added over its servicing lifetime. Note that LTSB images will not contain most in-box Universal Windows Apps (for example, Microsoft Edge, Cortana, the Windows Store, the Mail and Calendar apps) because the apps or the services that they use will be frequently updated with new functionality and therefore cannot be supported on PCs running the LTSB OS.
-
-These LTSB images can be used to upgrade existing machines or to create new custom images.
-
-Note that Windows 10 Enterprise LTSB installations fully support the Universal Windows Platform, with the ability to run line-of-business apps created using the Windows SDK, Visual Studio, and related tools capable of creating Universal Windows apps. For apps from other ISVs (including those published in the Windows Store), contact the ISV to confirm if they will provide long-term support for their specific apps.
-
-As mentioned previously, there are few, if any, scenarios where an organization would use the Long-Term Servicing Branch for every PC – or even for a majority of them.
-
-## Windows Insider Program
-
-
-During the development of a new Windows 10 feature update, preview releases will be made available to Windows Insider Program participants. This enables those participants to try out new features, check application compatibility, and provide feedback during the development process.
-
-To obtain Windows Insider Program builds, the Windows Insider Program participants must opt in through the Settings app, and specify their Microsoft account.
-
-Occasionally (typically as features are made available to those in the Windows Insider Program “slow” ring), new ISO images will be released to enable deployment validation, testing, and image creation.
-
-## Switching between branches
-
-
-During the life of a particular PC, it may be necessary or desirable to switch between the available branches. Depending on the branch you are using, the exact mechanism for doing this can be different; some will be simple, others more involved.
-
-<table>
-<colgroup>
-<col width="33%" />
-<col width="33%" />
-<col width="33%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">For a PC that uses…</th>
-<th align="left">Changing to…</th>
-<th align="left">You need to:</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left">Windows Insider Program</td>
-<td align="left">Current Branch</td>
-<td align="left">Wait for the final Current Branch release.</td>
-</tr>
-<tr class="even">
-<td align="left"></td>
-<td align="left">Current Branch for Business</td>
-<td align="left">Not directly possible, because Windows Insider Program machines are automatically upgraded to the Current Branch release at the end of the development cycle.</td>
-</tr>
-<tr class="odd">
-<td align="left"></td>
-<td align="left">Long-Term Servicing Branch</td>
-<td align="left">Not directly possible (requires wipe-and-load).</td>
-</tr>
-<tr class="even">
-<td align="left">Current Branch</td>
-<td align="left">Insider</td>
-<td align="left">Use the Settings app to enroll the device in the Windows Insider Program.</td>
-</tr>
-<tr class="odd">
-<td align="left"></td>
-<td align="left">Current Branch for Business</td>
-<td align="left">Select the <strong>Defer upgrade</strong> setting, or move the PC to a target group or flight that will not receive the next upgrade until it is business ready. Note that this change will not have any immediate impact; it only prevents the installation of the next Current Branch release.</td>
-</tr>
-<tr class="even">
-<td align="left"></td>
-<td align="left">Long-Term Servicing Branch</td>
-<td align="left">Not directly possible (requires wipe-and-load).</td>
-</tr>
-<tr class="odd">
-<td align="left">Current Branch for Business</td>
-<td align="left">Insider</td>
-<td align="left">Use the Settings app to enroll the device in the Windows Insider Program.</td>
-</tr>
-<tr class="even">
-<td align="left"></td>
-<td align="left">Current Branch</td>
-<td align="left">Disable the <strong>Defer upgrade</strong> setting, or move the PC to a target group or flight that will receive the latest Current Branch release.</td>
-</tr>
-<tr class="odd">
-<td align="left"></td>
-<td align="left">Long-Term Servicing Branch</td>
-<td align="left">Not directly possible (requires wipe-and-load).</td>
-</tr>
-<tr class="even">
-<td align="left">Long-Term Servicing Branch</td>
-<td align="left">Insider</td>
-<td align="left">Use media to upgrade to the latest Windows Insider Program build.</td>
-</tr>
-<tr class="odd">
-<td align="left"></td>
-<td align="left">Current Branch</td>
-<td align="left">Use media to upgrade to a later Current Branch build. (Note that the Current Branch build must be a later build.)</td>
-</tr>
-<tr class="even">
-<td align="left"></td>
-<td align="left">Current Branch for Business</td>
-<td align="left">Use media to upgrade to a later Current Branch for Business build (Current Branch build plus fixes). Note that it must be a later build.</td>
-</tr>
-</tbody>
-</table>
-
- 
+Windows 10 enables organizations to fulfill the desire to provide users with the latest features while balancing the need for manageability and cost control. To keep pace with technology, there are good business reasons to keep a significant portion of your enterprise's devices *current* with the latest release of Windows. 
 
 ## Related topics
 
-
-[Windows 10 deployment considerations](windows-10-deployment-considerations.md)
-
-[Windows 10 compatibility](windows-10-compatibility.md)
-
-[Windows 10 infrastructure requirements](windows-10-infrastructure-requirements.md)
-
- 
-
- 
-
-
-
-
-
+[Windows 10 deployment considerations](windows-10-deployment-considerations.md)<BR>
+[Windows 10 compatibility](windows-10-compatibility.md)<BR>
+[Windows 10 infrastructure requirements](windows-10-infrastructure-requirements.md)
\ No newline at end of file
diff --git a/windows/whats-new/credential-guard.md b/windows/whats-new/credential-guard.md
index 5bd63a42af..48f7a4f853 100644
--- a/windows/whats-new/credential-guard.md
+++ b/windows/whats-new/credential-guard.md
@@ -13,6 +13,7 @@ author: brianlic-msft
 
 **Applies to**
 -   Windows 10
+-   Windows Server 2016
 
 Credential Guard uses virtualization-based security to isolate secrets so that only privileged system software can access them.
 
diff --git a/windows/whats-new/device-guard-overview.md b/windows/whats-new/device-guard-overview.md
index ed8847ee60..28e92f028b 100644
--- a/windows/whats-new/device-guard-overview.md
+++ b/windows/whats-new/device-guard-overview.md
@@ -15,96 +15,19 @@ author: brianlic-msft
 **Applies to**
 -   Windows 10
 -   Windows 10 Mobile
+-   Windows Server 2016
 
 Device Guard is a combination of enterprise-related hardware and software security features that, when configured together, will lock a device down so that it can only run trusted applications. If the app isn’t trusted it can’t run, period. It also means that even if an attacker manages to get control of the Windows kernel, he or she will be much less likely to be able to run malicious executable code after the computer restarts because of how decisions are made about what can run and when.
+
 Device Guard uses the new virtualization-based security in Windows 10 Enterprise to isolate the Code Integrity service from the Microsoft Windows kernel itself, letting the service use signatures defined by your enterprise-controlled policy to help determine what is trustworthy. In effect, the Code Integrity service runs alongside the kernel in a Windows hypervisor-protected container.
+
 For details on how to implement Device Guard, see [Device Guard deployment guide](../keep-secure/device-guard-deployment-guide.md).
+
 ## Why use Device Guard
 With thousands of new malicious files created every day, using traditional methods like signature-based detection to fight against malware provides an inadequate defense against new attacks. Device Guard on Windows 10 Enterprise changes from a mode where apps are trusted unless blocked by an antivirus or other security solutions, to a mode where the operating system trusts only apps authorized by your enterprise.
 Device Guard also helps protect against [zero day attacks](http://go.microsoft.com/fwlink/p/?linkid=534209) and works to combat the challenges of [polymorphic viruses](http://go.microsoft.com/fwlink/p/?LinkId=534210).
-### Advantages to using Device Guard
-You can take advantage of the benefits of Device Guard, based on what you turn on and use:
--   Helps provide strong malware protection with enterprise manageability
--   Helps provide the most advanced malware protection ever offered on the Windows platform
--   Offers improved tamper resistance
-## How Device Guard works
-Device Guard restricts the Windows 10 Enterprise operating system to only running code that’s signed by trusted signers, as defined by your Code Integrity policy through specific hardware and security configurations, including:
--   User Mode Code Integrity (UMCI)
--   New kernel code integrity rules (including the new Windows Hardware Quality Labs (WHQL) signing constraints)
--   Secure Boot with database (db/dbx) restrictions
--   Virtualization-based security to help protect system memory and kernel mode apps and drivers from possible tampering.
--   **Optional:** Trusted Platform Module (TPM) 1.2 or 2.0
-Device Guard works with your image-building process, so you can turn the virtualization-based security feature on for capable devices, configure your Code Integrity policy, and set any other operating system settings you require for Windows 10 Enterprise. After that, Device Guard works to help protect your devices:
-1.  Your device starts up using Universal Extensible Firmware Interface (UEFI) Secure Boot, so that boot kits can’t run and so that Windows 10 Enterprise starts before anything else.
-2.  After securely starting up the Windows boot components, Windows 10 Enterprise can start the Hyper-V virtualization-based security services, including Kernel Mode Code Integrity. These services help protect the system core (kernel), privileged drivers, and system defenses, like anti-malware solutions, by preventing malware from running early in the boot process, or in kernel after startup.
-3.  Device Guard uses UMCI to make sure that anything that runs in User mode, such as a service, a Universal Windows Platform (UWP) app, or a Classic Windows application is trusted, allowing only trusted binaries to run.
-4.  At the same time that Windows 10 Enterprise starts up, so too does the trusted platform module (TPM). TPM provides an isolated hardware component that helps protect sensitive information, such as user credentials and certificates.
-## Required hardware and software
-The following table shows the hardware and software you need to install and configure to implement Device Guard.
-<table>
-<colgroup>
-<col width="50%" />
-<col width="50%" />
-</colgroup>
-<thead>
-<tr class="header">
-<th align="left">Requirement</th>
-<th align="left">Description</th>
-</tr>
-</thead>
-<tbody>
-<tr class="odd">
-<td align="left"><p>Windows 10 Enterprise</p></td>
-<td align="left"><p>The PC must be running Windows 10 Enterprise.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>UEFI firmware version 2.3.1 or higher and Secure Boot</p></td>
-<td align="left"><p>To verify that the firmware is using UEFI version 2.3.1 or higher and Secure Boot, you can validate it against the [System.Fundamentals.Firmware.CS.UEFISecureBoot.ConnectedStandby](http://msdn.microsoft.com/library/windows/hardware/dn932807.aspx#system-fundamentals-firmware-cs-uefisecureboot-connectedstandby) Windows Hardware Compatibility Program requirement.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>Virtualization extensions</p></td>
-<td align="left"><p>The following virtualization extensions are required to support virtualization-based security:</p>
-<ul>
-<li>Intel VT-x or AMD-V</li>
-<li>Second Level Address Translation</li>
-</ul></td>
-</tr>
-<tr class="even">
-<td align="left"><p>Firmware lock</p></td>
-<td align="left"><p>The firmware setup should be locked to prevent other operating systems from starting and to prevent changes to the UEFI settings. You should also disable boot methods other than from the hard drive.</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>x64 architecture</p></td>
-<td align="left"><p>The features that virtualization-based security uses in the Windows hypervisor can only run on a 64-bit PC.</p></td>
-</tr>
-<tr class="even">
-<td align="left"><p>A VT-d or AMD-Vi IOMMU (Input/output memory management unit)</p></td>
-<td align="left"><p>In Windows 10, an IOMMU enhances system resiliency against memory attacks. ¹</p></td>
-</tr>
-<tr class="odd">
-<td align="left"><p>Secure firmware update process</p></td>
-<td align="left"><p>To verify that the firmware complies with the secure firmware update process, you can validate it against the [System.Fundamentals.Firmware.UEFISecureBoot](http://msdn.microsoft.com/library/windows/hardware/dn932805.aspx#system-fundamentals-firmware-uefisecureboot) Windows Hardware Compatibility Program requirement.</p><p>Device Guard relies on the security of the underlying hardware and firmware. It is critical to keep the firmware updated with the latest security fixes.</p></td>
-</tr>
-</tbody>
-</table>
- 
-## <a href="" id="before-you-begin"></a>Before using Device Guard in your company
-Before you can successfully use Device Guard, you must set up your environment and your policies.
-### Signing your apps
-Device Guard mode supports both UWP apps and Classic Windows applications. Trust between Device Guard and your apps happen when your apps are signed using a signature that you determine to be trustworthy. Not just any signature will work.
-This signing can happen by:
--   **Using the Windows Store publishing process.** All apps that come out of the Microsoft Store are automatically signed with special signatures that can roll-up to our certificate authority (CA) or to your own.
--   **Using your own digital certificate or public key infrastructure (PKI).** ISV's and enterprises can sign their own Classic Windows applications themselves, adding themselves to the trusted list of signers.
--   **Using a non-Microsoft signing authority.** ISV's and enterprises can use a trusted non-Microsoft signing authority to sign all of their own Classic Windows applications.
--   **Use the Device Guard signing portal**. Available in the Windows Store for Business, you can use a Microsoft web service to sign your Classic Windows applications. For more info, see [Device Guard signing](../manage/device-guard-signing-portal.md).
-### Code Integrity policy
-Before you can use the app protection included in Device Guard, you must create a Code Integrity policy using tools provided by Microsoft, but deployed using your current management tools, like Group Policy. The Code Integrity policy is a binary-encoded XML document that includes configuration settings for both the User and Kernel-modes of Windows 10 Enterprise, along with restrictions on Windows 10 script hosts. This policy restricts what code can run on a device.
-For the Device Guard feature, devices should only have Code Integrity pre-configured if the settings are provided by a customer for a customer-provided image.
-**Note**  This XML document can be signed in Windows 10 Enterprise, helping to add additional protection against administrative users changing or removing this policy.
- 
-### <a href="" id="virtualization-based-security-using-windows-10-hypervisor"></a>Virtualization-based security using Windows 10 Enterprise Hypervisor
-Windows 10 Enterprise Hypervisor introduces new capabilities around virtual trust levels, which helps Windows 10 Enterprise services to run in a protected environment, in isolation from the running operating system. Windows 10 Enterprise virtualization-based security helps protect kernel code integrity and helps to provide credential isolation for the local security authority (LSA). Letting the Kernel Code Integrity service run as a hypervisor-hosted service increases the level of protection around the root operating system, adding additional protections against any malware that compromises the kernel layer.
-**Important**  Device Guard devices that run Kernel Code Integrity with virtualization-based security must have compatible drivers - legacy drivers can be updated - and have all virtualization capabilities turned on. This includes virtualization extensions and input/output memory management unit (IOMMU) support.
- 
- 
- 
+## Virtualization-based security using Windows 10 Enterprise Hypervisor
+
+Windows 10 Enterprise Hypervisor introduces new capabilities around virtual trust levels, which helps Windows 10 Enterprise services to run in a protected environment, in isolation from the running operating system. Windows 10 Enterprise virtualization-based security helps protect kernel code integrity and helps to provide credential isolation for the local security authority (LSA). Letting the Kernel Code Integrity service run as a hypervisor-hosted service increases the level of protection around the root operating system, adding additional protections against any malware that compromises the kernel layer. 
+
+>**Important**&nbsp;&nbsp;Device Guard devices that run Kernel Code Integrity with virtualization-based security (VBS) must have compatible drivers (legacy drivers can be updated) and meet requirements for the hardware and firmware that support virtualization-based security. For more information, see [Hardware, firmware, and software requirements for Device Guard](../keep-secure/requirements-and-deployment-planning-guidelines-for-device-guard.md#hardware-firmware-and-software-requirements-for-device-guard)
diff --git a/windows/whats-new/edp-whats-new-overview.md b/windows/whats-new/edp-whats-new-overview.md
index cc29c76faa..4b157c50e8 100644
--- a/windows/whats-new/edp-whats-new-overview.md
+++ b/windows/whats-new/edp-whats-new-overview.md
@@ -16,76 +16,61 @@ author: eross-msft
 -   Windows 10 Insider Preview
 -   Windows 10 Mobile Preview
 
-<span style="color:#ED1C24;">[Some information relates to pre-released product which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here. An app that calls an API introduced in Windows 10 Anniversary SDK Preview Build 14295 cannot be ingested into the Windows Store during the Preview period.]</span>
+<span style="color:#ED1C24;">[Some information relates to pre-released product, which may be substantially modified before it's commercially released. Microsoft makes no warranties, express or implied, with respect to the information provided here.]</span>
 
-With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data disclosure through apps and services that are outside of the enterprise’s control like email, social media, and the public cloud.
+With the increase of employee-owned devices in the enterprise, there’s also an increasing risk of accidental data leak through apps and services, like email, social media, and the public cloud, which are outside of the enterprise’s control. For example, when an employee sends the latest engineering pictures from their personal email account, copies and pastes product info into a tweet, or saves an in-progress sales report to their public cloud storage.
 
-Many of the existing solutions try to address this issue by requiring employees to switch between personal and work containers and apps, which can lead to a less than optimal user experience. The feature code-named enterprise data protection (EDP) offers a better user experience, while helping to better separate and protect enterprise apps and data against disclosure risks across both company and personal devices, without requiring changes in environments or apps. Additionally, EDP when used with Rights Management Services (RMS), can help to protect your enterprise data locally, persisting the protection even when your data roams or is shared.
+Enterprise data protection (EDP) helps to protect against this potential data leakage without otherwise interfering with the employee experience. EDP also helps to protect enterprise apps and data against accidental data leak on enterprise-owned devices and personal devices that employees bring to work without requiring changes to your environment or other apps.
 
 ## Benefits of EDP
 
 EDP provides:
--   Additional protection against enterprise data leakage, with minimal impact on employees’ regular work practices.
--   Obvious separation between personal and corporate data, without requiring employees to switch environments or apps.
--   Additional data protection for existing line-of-business apps without a need to update the apps.
--   Ability to wipe corporate data from devices while leaving personal data alone.
--   Use of audit reports for tracking issues and remedial actions.
--   Integration with your existing management system (Microsoft Intune, System Center Configuration Manager (version 1511 or later)’, or your current mobile device management (MDM) system) to configure, deploy, and manage EDP for your company.
--   Additional protection for your data (through RMS integration) while roaming and sharing, like when you share encrypted content through Outlook or move encrypted files to USB keys.
--   Ability to manage Office universal apps on Windows 10 devices using an MDM solution to help protect corporate data. To manage Office mobile apps for Android and iOS devices, see technical resources [here]( http://go.microsoft.com/fwlink/p/?LinkId=526490).
+- Obvious separation between personal and corporate data, without requiring employees to switch environments or apps.
+
+- Additional data protection for existing line-of-business apps without a need to update the apps.
+
+- Ability to wipe corporate data from devices while leaving personal data alone.
+
+- Use of audit reports for tracking issues and remedial actions.
+
+- Integration with your existing management system (Microsoft Intune, System Center Configuration Manager (version 1511 or later), or your current mobile device management (MDM) system) to configure, deploy, and manage EDP for your company.
 
 ## Enterprise scenarios
-
 EDP currently addresses these enterprise scenarios:
--   You can encrypt enterprise data on employee-owned and corporate-owned devices.
--   You can remotely wipe enterprise data off managed computers, including employee-owned computers, without affecting the personal data.
--   You can select specific apps that can access enterprise data, called "protected apps" that are clearly recognizable to employees. You can also block non-protected apps from accessing enterprise data.
--   Your employees won't have their work otherwise interrupted while switching between personal and enterprise apps while the enterprise policies are in place. Switching environments or signing in multiple times isn’t required.
+- You can encrypt enterprise data on employee-owned and corporate-owned devices.
 
-### Enterprise data security
+- You can remotely wipe enterprise data off managed computers, including employee-owned computers, without affecting the personal data.
 
-As an enterprise admin, you need to maintain the security and confidentiality of your corporate data. Using EDP you can help ensure that your corporate data is protected on your employee-owned computers, even when the employee isn’t actively using it. In this case, when the employee initially creates the content on a managed device he’s asked whether it’s a work document. If it's a work document, it becomes locally-protected as enterprise data.
+- You can select specific apps that can access enterprise data, called "allowed apps" that are clearly recognizable to employees. You can also block non-protected apps from accessing enterprise data.
 
-### Persistent data encryption
+- Your employees won't have their work otherwise interrupted while switching between personal and enterprise apps while the enterprise policies are in place. Switching environments or signing in multiple times isn’t required.
 
-EDP helps keep your enterprise data protected, even when it roams. Apps like Office and OneNote work with EDP to persist your data encryption across locations and services. For example, if an employee opens EDP-encrypted content from Outlook, edits it, and then tries to save the edited version with a different name to remove the encryption, it won’t work. Outlook automatically applies EDP to the new document, keeping the data encryption in place.
+## Why use EDP?
+EDP gives you a new way to manage data policy enforcement for apps and documents, along with the ability to remove access to enterprise data from both enterprise and personal devices (after enrollment in an enterprise management solution, like Intune).
 
-### Remotely wiping devices of enterprise data
-EDP also offers the ability to remotely wipe your corporate data from all devices managed by you and used by an employee, while leaving personal data alone. This is a benefit when an employee leaves your company, or in the case of a stolen computer.
-In this case, documents are stored locally, and encrypted with an enterprise identity. When you verify that you have to wipe the device, you can send a remote wipe command through your mobile device management system so when the device connects to the network, the encryption keys are revoked and the enterprise data is removed. This action only affects devices that have been targeted by the command. All other devices will continue to work normally.
+- **Change the way you think about data policy enforcement.** As an enterprise admin, you need to maintain compliance in your data policy and data access. EDP helps make sure that your enterprise data is protected on both corporate and employee-owned devices, even when the employee isn’t using the device. When employees create content on an enterprise-protected device, they can choose to save it as a work document. If it's a work document, it becomes locally-maintained as enterprise data.
 
-### Protected apps and restrictions
+- **Manage your enterprise documents, apps, and encryption modes.**
 
-Using EDP you can control the set of apps that are made "protected apps", or apps that can access and use your enterprise data. After you add an app to your **Protected App** list, it’s trusted to use enterprise data. All apps not on this list are treated as personal and are potentially blocked from accessing your corporate data, depending on your EDP protection-mode.
-As a note, your existing line-of-business apps don’t have to change to be included as protected apps. You simply have to include them in your list.
+    - **Copying or downloading enterprise data.** When an employee or an app downloads content from a location like SharePoint, a network share, or an enterprise web location, while using an EDP-protected device, EDP encrypts the data on the device.
 
-### Great employee experiences
+    - **Using allowed apps.** Managed apps (apps that you've included on the allowed apps list in your EDP policy) are allowed to access your enterprise data and will interact differently when used with unallowed, non-enterprise aware, or personal-only apps. For example, if EDP management is set to **Block**, your employees can copy and paste from one protected app to another protected app, but not to personal apps. Imagine an HR person wants to copy a job description from a protected app to the internal career website, an enterprise-protected location, but goofs and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that the app couldn’t paste because of a policy restriction. The HR person then correctly pastes to the career website without a problem.
 
-EDP can offer a great user experience by not requiring employees to switch between apps to protect corporate data. For example, while checking work emails in Microsoft Outlook, an employee gets a personal message. Instead of having to leave Outlook, both the work and personal messages appear on the screen, side-by-side.
+    - **Managed apps and restrictions.** With EDP you can control which apps can access and use your enterprise data. After adding an app to your protected apps list, the app is trusted with enterprise data. All apps not on this list are blocked from accessing your enterprise data, depending on your EDP management-mode.
+    
+    You don’t have to modify line-of-business apps that never touch personal data to list them as protected apps; just include them in your protected apps list.
 
-#### Using protected apps
+    - **Deciding your level of data access.** EDP lets you block, allow overrides, or audit employees' data sharing actions. Blocking the action stops it immediately. Allowing overrides let the employee know there's a risk, but lets him or her continue to share the data while recording and auditing the action. Silent just logs the action without blocking anything that the employee could've overridden while using that setting; collecting info that can help you to see patterns of inappropriate sharing so you can take educative action or find apps that should be added to your protected apps list.
 
-Protected apps are allowed to access your enterprise data and will react differently with other non-protected or personal apps. For example, if your EDP-protection mode is set to block, your protected apps will let the employee copy and paste information between other protected apps, but not with personal apps. Imagine an HR person wants to copy a job description from a protected app to an internal career website, an enterprise-protected location, but goofs and tries to paste into a personal app instead. The paste action fails and a notification pops up, saying that it couldn’t paste because of a policy restriction. The HR person then correctly pastes to the career website and it works without a problem.
+    - **Data encryption at rest.** EDP helps protect enterprise data on local files and on removable media.
+    
+    Apps such as Microsoft Word work with EDP to help continue your data protection across local files and removable media. These apps are being referred to as, enterprise aware. For example, if an employee opens EDP-encrypted content from Word, edits the content, and then tries to save the edited version with a different name, Word automatically applies EDP to the new document.
 
-#### Copying or downloading enterprise data
+    - **Helping prevent accidental data disclosure to public spaces.** EDP helps protect your enterprise data from being accidentally shared to public spaces, such as public cloud storage. For example, if Dropbox™ isn’t on your protected apps list, employees won’t be able to sync encrypted files to their personal cloud storage. Instead, if the employee stores the content to an app on your protected apps list, like Microsoft OneDrive for Business, the encrypted files can sync freely to the business cloud, while maintaining the encryption locally.
 
-Downloading content from a location like SharePoint or a network file share, or an enterprise web location, such as Office365.com automatically determines that the content is enterprise data and is encrypted as such, while it’s stored locally. The same applies to copying enterprise data to something like a USB drive. Because the content is already marked as enterprise data locally, the encryption is persisted on the new device.
+    - **Helping prevent accidental data disclosure to removable media.** EDP helps prevent enterprise data from leaking when it's copied or transferred to removable media. For example, if an employee puts enterprise data on a Universal Serial Bus (USB) drive that also has personal data, the enterprise data remains encrypted while the personal data doesn’t.
 
-#### Changing the EDP protection
-
-Employees can change enterprise data protected documents back to personal if the document is wrongly marked as enterprise. However, this requires the employee to take an action and is audited and logged for you to review
-
-### Deciding your level of data access
-
-EDP lets you decide to block, allow overrides, or silently audit your employee's data sharing actions. Blocking the action stops it immediately, while allowing overrides let the employee know there's a problem, but lets the employee continue to share the info, and silent just logs the action without stopping it, letting you start to see patterns of inappropriate sharing so you can take educative action.
-
-### Helping prevent accidental data disclosure to public spaces
-
-EDP helps protect your enterprise data from being shared to public spaces, like the public cloud, accidentally. For example, if an employee stores content in the **Documents** folder, which is automatically synched with OneDrive (an app on your Protected Apps list), then the document is encrypted locally and not synched it to the user’s personal cloud. Likewise, if other synching apps, like Dropbox™, aren’t on the Protected Apps list, they also won’t be able to sync encrypted files to the user’s personal cloud.
-
-### Helping prevent accidental data disclosure to other devices
-
-EDP helps protect your enterprise data from leaking to other devices while transferring or moving between them. For example, if an employee puts corporate data on a USB key that also includes personal data, the corporate data remains encrypted even though the personal information remains open. Additionally, the encryption continues when the employee copies the encrypted content back to another corporate-managed device.
+    - **Remove access to enterprise data from enterprise-protected devices.** EDP gives admins the ability to revoke enterprise data from one or many MDM-enrolled devices, while leaving personal data alone. This is a benefit when an employee leaves your company, or in the case of a stolen device. After determining that the data access needs to be removed, you can unenroll the device so when it connects to the network, the user's encryption key for the device is revoked and the enterprise data becomes unreadable.
 
 ## Turn off EDP
 
diff --git a/windows/whats-new/security-auditing.md b/windows/whats-new/security-auditing.md
index 15350dc9c4..13c6a7e5b8 100644
--- a/windows/whats-new/security-auditing.md
+++ b/windows/whats-new/security-auditing.md
@@ -10,9 +10,11 @@ ms.pagetype: security, mobile
 ---
 
 # What's new in security auditing?
+
 **Applies to**
 -   Windows 10
 -   Windows 10 Mobile
+-   Windows Server 2016
 
 Security auditing is one of the most powerful tools that you can use to maintain the integrity of your system. As part of your overall security strategy, you should determine the level of auditing that is appropriate for your environment. Auditing should identify attacks (successful or not) that pose a threat to your network, and attacks against resources that you have determined to be valuable in your risk assessment.
 
diff --git a/windows/whats-new/trusted-platform-module.md b/windows/whats-new/trusted-platform-module.md
index 9937fada56..18a325aa7f 100644
--- a/windows/whats-new/trusted-platform-module.md
+++ b/windows/whats-new/trusted-platform-module.md
@@ -14,6 +14,7 @@ author: brianlic-msft
 **Applies to**
 -   Windows 10
 -   Windows 10 Mobile
+-   Windows Server 2016
 
 This topic for the IT professional describes new features for the Trusted Platform Module (TPM) in Windows 10.