Refactor to WDAC Deployment Guide

windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md

@@ -16,35 +16,33 @@ ms.technology: mde
 # Windows Defender Application Control and virtualization-based protection of code integrity
 
 **Applies to**
--   Windows 10
--   Windows Server 2016
 
-Windows 10 includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows 10 systems so they operate with many of the properties of mobile devices. In this configuration, specific technologies work together to restrict devices to only run authorized apps by using a feature called configurable code integrity, while simultaneously hardening the OS against kernel memory attacks by using virtualization-based protection of code integrity (more specifically, HVCI). 
+- Windows 10
+- Windows Server 2016
 
-Configurable code integrity policies and HVCI are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows 10 devices.  
+Windows 10 includes a set of hardware and OS technologies that, when configured together, allow enterprises to "lock down" Windows 10 systems so they operate with many of the properties of mobile devices. In this configuration, specific technologies work together to restrict devices to only run authorized apps by using a feature called Windows Defender Application Control (WDAC), while simultaneously hardening the OS against kernel memory attacks by using hypervisor-protected code integrity (HVCI). 
 
-Using configurable code integrity to restrict devices to only authorized apps has these advantages over other solutions:
+WDAC policies and HVCI are powerful protections that can be used separately. However, when these two technologies are configured to work together, they present a strong protection capability for Windows 10 devices.  
 
-1. Configurable code integrity policy is enforced by the Windows kernel itself. As such, the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run. 
+Using WDAC to restrict devices to only authorized apps has these advantages over other solutions:
-2. Configurable code integrity allows customers to set application control policy not only over code running in user mode, but also kernel mode hardware and software drivers and even code that runs as part of Windows. 
-3. Customers can protect the configurable code integrity policy even from local administrator tampering by digitally signing the policy. This would mean that changing the policy would require both administrative privilege and access to the organization’s digital signing process, making it difficult for an attacker with administrative privilege, or malicious software that managed to gain administrative privilege, to alter the application control policy. 
-4. The entire configurable code integrity enforcement mechanism can be protected by HVCI, where even if a vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise have enough privilege to disable most system defenses and override the application control policies enforced by configurable code integrity or any other application control solution.
 
-## Windows Defender Application Control
+1. WDAC policy is enforced by the Windows kernel itself. As such, the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
+2. WDAC allows customers to set application control policy not only over code running in user mode, but also kernel mode hardware and software drivers and even code that runs as part of Windows.
+3. Customers can protect the WDAC policy even from local administrator tampering by digitally signing the policy. This would mean that changing the policy would require both administrative privilege and access to the organization’s digital signing process, making it difficult for an attacker with administrative privilege, or malicious software that managed to gain administrative privilege, to alter the application control policy.
+4. The entire WDAC enforcement mechanism can be protected by HVCI, where even if a vulnerability exists in kernel mode code, the likelihood that an attacker could successfully exploit it is diminished. Why is this relevant? That’s because an attacker that compromises the kernel would otherwise have enough privilege to disable most system defenses and override the application control policies enforced by WDAC or any other application control solution.
 
-When we originally designed this configuration state, we did so with a specific security promise in mind. Although there were no direct dependencies between configurable code integrity and HVCI, we intentionally focused our discussion around the lockdown state you achieve when deploying them together. However, given that HVCI relies on Windows virtualization-based security, it comes with more hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. As a result, many IT Professionals assumed that because some systems couldn't use HVCI, they couldn’t use configurable code integrity either. 
+## Why we no longer use the Device Guard brand
 
-Configurable code integrity carries no specific hardware or software requirements other than running Windows 10, which means many IT professionals were wrongly denied the benefits of this powerful application control capability.
+When we originally designed this configuration state, we did so with a specific security promise in mind. Although there were no direct dependencies between WDAC and HVCI, we intentionally focused our discussion around the lockdown state you achieve when deploying them together. However, given that HVCI relies on Windows virtualization-based security, it comes with more hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. As a result, many IT Professionals assumed that because some systems couldn't use HVCI, they couldn’t use WDAC either. 
 
-Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we are discussing and documenting configurable code integrity as an independent technology within our security stack and giving it a name of its own: [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md). 
+WDAC carries no specific hardware or software requirements other than running Windows 10, which means many IT professionals were wrongly denied the benefits of this powerful application control capability.
+
+Since the initial release of Windows 10, the world has witnessed numerous hacking and malware attacks where application control alone could have prevented the attack altogether. With this in mind, we are discussing and documenting WDAC as an independent technology within our security stack and giving it a name of its own: [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md). 
 We hope this change will help us better communicate options for adopting application control within an organization.
 
 ## Related articles
 
 [Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md)
-
 [Dropping the Hammer Down on Malware Threats with Windows 10’s Windows Defender](https://channel9.msdn.com/Events/Ignite/2015/BRK2336)
-
 [Driver compatibility with Windows Defender in Windows 10](https://blogs.msdn.microsoft.com/windows_hardware_certification/2015/05/22/driver-compatibility-with-device-guard-in-windows-10)
-
 [Code integrity](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd348642(v=ws.10))

windows/security/threat-protection/windows-defender-application-control/TOC.md

@@ -1,7 +1,7 @@
 # [Application Control for Windows](windows-defender-application-control.md)
 ## [WDAC and AppLocker Overview](wdac-and-applocker-overview.md)
 ### [WDAC and AppLocker Feature Availability](feature-availability.md)
-### [Virtualization-based code integrity](../device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
+### [Virtualization-based protection of code integrity](../device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control.md)
 
 
 ## [WDAC design guide](windows-defender-application-control-design-guide.md)
@@ -14,8 +14,8 @@
 ##### [Allow reputable apps with Intelligent Security Graph (ISG)](use-windows-defender-application-control-with-intelligent-security-graph.md)
 ##### [Allow COM object registration](allow-com-object-registration-in-windows-defender-application-control-policy.md)
 ##### [Use WDAC with .NET hardening](use-windows-defender-application-control-with-dynamic-code-security.md)
-#### [Manage packaged apps with WDAC](manage-packaged-apps-with-windows-defender-application-control.md)
+##### [Manage packaged apps with WDAC](manage-packaged-apps-with-windows-defender-application-control.md)
-#### [Use WDAC to control specific plug-ins, add-ins, and modules](use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md)
+##### [Use WDAC to control specific plug-ins, add-ins, and modules](use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md)
 #### [Use multiple WDAC policies](deploy-multiple-windows-defender-application-control-policies.md)
 ### Create your WDAC policy
 #### [Example WDAC base policies](example-wdac-base-policies.md)
@@ -31,13 +31,14 @@
 ##### [Editing a WDAC policy with the Wizard](wdac-wizard-editing-policy.md)
 ##### [Merging multiple WDAC policies with the Wizard](wdac-wizard-merging-policies.md)
 
-
 ## [WDAC deployment guide](windows-defender-application-control-deployment-guide.md)
+### [Deploy WDAC policies using MDM](deploy-windows-defender-application-control-policies-using-intune.md)
+### [Deploy WDAC policies using MEMCM](deployment/deploy-wdac-policies-using-memcm.md)
+### [Deploy WDAC policies using script](deployment/deploy-wdac-policies-using-script.md)
+### [Deploy WDAC policies using Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)
 ### [Audit WDAC policies](audit-windows-defender-application-control-policies.md)
 ### [Merge WDAC policies](merge-windows-defender-application-control-policies.md)
 ### [Enforce WDAC policies](enforce-windows-defender-application-control-policies.md)
-### [Deploy WDAC policies using Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)
-### [Deploy WDAC policies using Intune](deploy-windows-defender-application-control-policies-using-intune.md)
 ### [Use code signing to simplify application control for classic Windows applications](use-code-signing-to-simplify-application-control-for-classic-windows-applications.md)
 #### [Optional: Use the WDAC Signing Portal in the Microsoft Store for Business](use-device-guard-signing-portal-in-microsoft-store-for-business.md)
 #### [Optional: Create a code signing cert for WDAC](create-code-signing-cert-for-windows-defender-application-control.md)
@@ -46,11 +47,11 @@
 ### [Disable WDAC policies](disable-windows-defender-application-control-policies.md)
 ### [LOB Win32 Apps on S Mode](LOB-win32-apps-on-s.md)
 
-
 ## [Windows Defender Application Control operational guide](windows-defender-application-control-operational-guide.md)
 ### [Understanding Application Control event IDs](event-id-explanations.md)
 ### [Understanding Application Control event tags](event-tag-explanations.md)
 ### [Query WDAC events with Advanced hunting](querying-application-control-events-centrally-using-advanced-hunting.md)
+### [Known Issues](operations/known-issues.md)
 
 ## [AppLocker](applocker\applocker-overview.md) 
 ### [Administer AppLocker](applocker\administer-applocker.md)
@@ -137,5 +138,3 @@
 #### [Tools to Use with AppLocker](applocker\tools-to-use-with-applocker.md)
 ##### [Using Event Viewer with AppLocker](applocker\using-event-viewer-with-applocker.md)
 #### [AppLocker Settings](applocker\applocker-settings.md)
-
-

windows/security/threat-protection/windows-defender-application-control/audit-windows-defender-application-control-policies.md

@@ -1,5 +1,5 @@
 ---
-title: Audit Windows Defender Application Control policies (Windows 10)
+title: Use audit events to create WDAC policy rules (Windows 10)
 description: Audits allow admins to discover apps that were missed during an initial policy scan and to identify new apps that were installed since the policy was created.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
@@ -11,94 +11,65 @@ ms.localizationpriority: medium
 audience: ITPro
 ms.collection: M365-security-compliance
 author: jsuther1974
-ms.reviewer: isbrahm
+ms.reviewer: jogeurte
 ms.author: dansimp
 manager: dansimp
 ms.date: 05/03/2018
 ms.technology: mde
 ---
 
-# Audit Windows Defender Application Control policies
+# Use audit events to create WDAC policy rules
 
 **Applies to:**
 
--   Windows 10
+- Windows 10
--   Windows Server 2016
+- Windows Server 2016 and above
 
-Running **Application Control** in audit mode 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 WDAC 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 WDAC policy. When the new exception policy is created, you can merge it with your existing WDAC policies.
+Running Application Control in audit mode allows administrators to discover applications, binaries, and scripts that were missed during the initial policy creation and to identify any new applications that have been installed and run since the original policy was created.
 
-Before you begin this process, you need to create a WDAC policy binary file. If you have not already done so, see [Create an initial Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md).
+While a WDAC 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 or, for script and MSI, in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to easily generate a new WDAC policy which can be merged with the original Base policy or, on Windows 10 1903+, included in a separate Supplemental policy when the Base policy allows supplemental policies.
 
-**To audit a Windows Defender Application Control policy with local policy:**
+## Overview of the process to create WDAC policy to allow apps using audit events
-
-1. Before you begin, find the *.bin policy file , for example, the DeviceGuardPolicy.bin. 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**.
-
-   > [!Note]
-   > 
-   > - 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 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 Windows Defender Application Control**. Enable this setting by using the appropriate file path, for example, C:\\Windows\\System32\\CodeIntegrity\\DeviceGuardPolicy.bin, as shown in Figure 1.
-
-   > [!Note]
-   > 
-   > - You can copy the WDAC policies to a file share to which all computer accounts have access rather than copy them to every system. 
-   > 
-   > - 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 WDAC 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 Windows Defender Application Control](images/dg-fig22-deploycode.png)
-
-   Figure 1. Deploy your Windows Defender Application Control policy
-
-4. Restart the reference system for the WDAC 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 WDAC 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 WDAC policy](images/dg-fig23-exceptionstocode.png)
-
-   Figure 2. Exceptions to the deployed WDAC 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 WDAC policy, this is a good time to create it. For information, see [Deploy catalog files to support Windows Defender Application Control](deploy-catalog-files-to-support-windows-defender-application-control.md).   
-
-Now that you have a WDAC 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 Windows Defender Application Control policy that captures audit information from the event log
-
-Use the following procedure after you have been running a computer with a WDAC 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 WDAC 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 WDAC 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 [Windows Defender Application Control file rule levels](select-types-of-rules-to-create.md) in "Deploy Windows Defender Application Control: policy rules and file rules."
-    
-   Your event log might also contain exceptions for applications that you eventually want your WDAC 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](/powershell/module/configci/new-cipolicy) to generate a new WDAC 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]
-   > 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 WDAC 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 WDAC policy, the policy will treat the applications as trusted, and allow them to run. 
-
-You can now use this file to update the existing WDAC policy that you ran in audit mode by merging the two policies. For instructions on how to merge this audit policy with the existing WDAC policy, see the next section, [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md).
 
 > [!Note]
-> You may have noticed that you did not generate a binary version of this policy as you did in [Create a Windows Defender Application Control policy from a reference computer](./create-initial-default-policy.md). This is because WDAC policies created from an audit log are not intended to run as stand-alone policies but rather to update existing WDAC policies.
+> You must have already deployed a WDAC audit mode policy to use this process. If you have not already done so, see [Deploying Windows Defender Application Control policies](windows-defender-application-control-deployment-guide.md).
+
+To familiarize yourself with the process to generate WDAC rules from audit events, follow these steps on a device with a WDAC audit mode policy in effect.
+
+1. Install and run an application that should not currently be allowed by the WDAC policy but which you want to allow.
+
+2. Review the **CodeIntegrity - Operational** and **AppLocker - MSI and Script** event logs to confirm events, like those shown in Figure 1, are generated related to the application. For information about the types of events you should see, refer to [Understanding Application Control events](event-id-explanations.md).
+
+   **Figure 1. Exceptions to the deployed WDAC policy**
+   ![Event showing exception to WDAC policy](images/dg-fig23-exceptionstocode.png)
+
+3. In an elevated Windows Powershell session, run the following commands to initialize variables used by this procedure. This builds upon the **Lamna_FullyManagedClients_Audit.xml** policy introduced in [Create a WDAC policy for fully-managed devices](create-wdac-policy-for-fully-managed-devices.md) and will produce a new policy called **EventsPolicy.xml**.
+
+   ```powershell
+   $PolicyName= "Lamna_FullyManagedClients_Audit"
+   $LamnaPolicy=$env:userprofile+"\Desktop\"+$PolicyName+".xml"
+   $EventsPolicy=$env:userprofile+"\Desktop\EventsPolicy.xml"
+   $EventsPolicyWarnings=$env:userprofile+"\Desktop\EventsPolicyWarnings.txt"
+   ```
+
+4. Use [New-CIPolicy](/powershell/module/configci/new-cipolicy) to generate a new WDAC policy from logged audit events. This example uses a file rule level of **FilePublisher** with a fallback level of **Hash** and redirects warning messages to a text file **EventsPolicyWarnings.txt**.
+
+   ```powershell
+   New-CIPolicy -FilePath $EventsPolicy -Audit -Level FilePublisher -Fallback Hash –UserPEs -MultiplePolicyFormat 3> $EventsPolicyWarnings
+   ```
+
+   > [!NOTE]
+   > 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 **FilePublisher** rule level with a fallback level of  **Hash**, which may be more specific than desired. You can re-run the above command using different **-Level** and **-Fallback** options to meet your needs. For more information about WDAC rule levels refer to [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md).
+
+5. Find and review the WDAC policy file **EventsPolicy.xml** which should be found on your desktop. Ensure that the file and signer rules that were created authorize only the applications, binaries, and scripts you wish to allow. You can remove rules by manually editing the policy XML or use the WDAC Policy Wizard tool (see [Editing existing base and supplemental WDAC policies with the Wizard](wdac-wizard-editing-policy.md)).
+
+6. Find and review the text file **EventsPolicyWarnings.txt** which should be found on your desktop. This will include a warning for any files that WDAC could not create a rule for at either the specified rule level or fallback rule level.
+
+   > [!NOTE]
+   > New-CIPolicy only creates rules for files that can still be found on disk. Files which are no longer present on the system will not have a rule created to allow them. However, the event log should have sufficient information to allow these files by manually editing the policy XML to add rules. You can use an existing rule as a template and verify your results against the WDAC policy schema definition found at **%windir%\schemas\CodeIntegrity\cipolicy.xsd**.
+
+7. Merge **EventsPolicy.xml** with the Base policy **Lamna_FullyManagedClients_Audit.xml** or convert it to a supplemental policy.
+
+    For information on merging policies, refer to [Merge Windows Defender Application Control policies](merge-windows-defender-application-control-policies.md) and for information on supplemental policies see [Use multiple Windows Defender Application Control Policies](deploy-multiple-windows-defender-application-control-policies.md).
+
+8. Convert the Base or Supplemental policy to binary and deploy using your preferred method.

windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies.md

@@ -11,7 +11,7 @@ ms.localizationpriority: medium
 audience: ITPro
 ms.collection: M365-security-compliance
 author: jsuther1974
-ms.reviewer: jsuther1974
+ms.reviewer: jogeurte
 ms.author: dansimp
 manager: dansimp
 ms.date: 11/13/2020
@@ -22,10 +22,10 @@ ms.technology: mde
 
 **Applies to:**
 
-- Windows 10 version 1903
+- Windows 10 version 1903 and above
-- Windows Server 2022
+- Windows Server 2022 and above
 
-The restriction of only having a single code integrity policy active on a system at any given time has felt limiting for customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
+Prior to Windows 10 1903, WDAC only supported a single active on a system at any given time. This significantly limited customers in situations where multiple policies with different intents would be useful. Beginning with Windows 10 version 1903, WDAC supports up to 32 active policies on a device at once in order to enable the following scenarios:
 
 1. Enforce and Audit Side-by-Side
     - To validate policy changes before deploying in enforcement mode, users can now deploy an audit-mode base policy side by side with an existing enforcement-mode base policy

windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-group-policy.md

@@ -11,7 +11,7 @@ ms.localizationpriority: medium
 audience: ITPro
 ms.collection: M365-security-compliance
 author: jsuther1974
-ms.reviewer: isbrahm
+ms.reviewer: jogeurte
 ms.author: dansimp
 manager: dansimp
 ms.date: 02/28/2018
@@ -22,39 +22,36 @@ ms.technology: mde
 
 **Applies to:**
 
--   Windows 10
+- Windows 10
--   Windows Server 2016
+- Windows Server 2016 and above
-
-WDAC policies can easily be deployed and managed with Group Policy. Windows Defender allows you to simplify deployment Windows Defender hardware-based security features and Windows Defender Application Control policies. The following procedure walks you through how to deploy a WDAC 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 WDAC policy and have a computer running Windows 10 on which to test a Group Policy deployment. For more information about how to create a WDAC policy, see [Create a Windows Defender Application Control policy from a reference computer](create-initial-default-policy.md), earlier in this topic.
+> Group Policy-based deployment of WDAC policies only supports single-policy format WDAC policies. To use WDAC on devices running Windows 10 1903 and greater, we recommend using an alternative method for policy deployment. 
 
-> [!NOTE]
+Single-policy format WDAC policies (pre-1903 policy schema) can be easily deployed and managed with Group Policy. The following procedure walks you through how to deploy a WDAC policy called **ContosoPolicy.bin** to a test OU called *WDAC Enabled PCs* by using a GPO called **Contoso GPO Test**.
-> Signed WDAC policies can cause boot failures when deployed. We recommend that signed WDAC policies be thoroughly tested on each hardware platform before enterprise deployment.
 
 To deploy and manage a WDAC policy with Group Policy:
 
-1.  On a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC** 
+1. On a client computer on which RSAT is installed, open the GPMC by running **GPMC.MSC**
 
-2.  Create a new GPO: right-click an OU and then click **Create a GPO in this domain, and Link it here**.
+2. Create a new GPO: right-click an OU and then click **Create a GPO in this domain, and Link it here**.
 
-    > [!NOTE]
+   > [!NOTE]
-    > You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in [Plan for Windows Defender Application Control policy management](plan-windows-defender-application-control-management.md).
+   > You can use any OU name. Also, security group filtering is an option when you consider different ways of combining WDAC policies (or keeping them separate), as discussed in [Plan for Windows Defender Application Control policy management](plan-windows-defender-application-control-management.md).
 
-    ![Group Policy Management, create a GPO](images/dg-fig24-creategpo.png)
+   ![Group Policy Management, create a GPO](images/dg-fig24-creategpo.png)
 
-3.  Name the new GPO. You can choose any name. 
+3. Name the new GPO. You can choose any name.
 
-4.  Open the Group Policy Management Editor: right-click the new GPO, and then click **Edit**.
+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 Windows Defender Application Control** and then click **Edit**.
+5. In the selected GPO, navigate to Computer Configuration\\Administrative Templates\\System\\Device Guard. Right-click **Deploy Windows Defender Application Control** and then click **Edit**.
 
     ![Edit the Group Policy for Windows Defender Application Control](images/wdac-edit-gp.png)
 
-6.  In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the code integrity policy deployment path.
+6. In the **Deploy Windows Defender Application Control** dialog box, select the **Enabled** option, and then specify the WDAC 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.
+    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 ContosoPolicy.bin on the test computer, the example file path would be C:\\Windows\\System32\\CodeIntegrity\\ContosoPolicy.bin.
 
     > [!NOTE]
     > This policy file does not need to be copied to every computer. You can instead copy the WDAC 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.
@@ -62,6 +59,6 @@ To deploy and manage a WDAC policy with Group Policy:
     ![Group Policy called Deploy Windows Defender Application Control](images/dg-fig26-enablecode.png)
 
     > [!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 client computer running Windows 10. Make your WDAC 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.
+    > 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. Give your WDAC policies friendly names 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 WDAC policy. For information about how to audit WDAC policies, see [Audit Windows Defender Application Control policies](audit-windows-defender-application-control-policies.md).
+7. Close the Group Policy Management Editor, and then restart the Windows 10 test computer. Restarting the computer updates the WDAC policy.

windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune.md

@@ -1,6 +1,6 @@
 ---
-title: Deploy Windows Defender Application Control (WDAC) policies by using Microsoft Intune (Windows 10)
+title: Deploy WDAC policies using Mobile Device Management (MDM) (Windows 10)
-description: You can use Microsoft Intune to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide.
+description: You can use an MDM like Microsoft Intune to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
 ms.prod: m365-security
@@ -18,54 +18,49 @@ ms.date: 04/29/2020
 ms.technology: mde
 ---
 
-# Deploy Windows Defender Application Control policies by using Microsoft Intune
+# Deploy WDAC policies using Mobile Device Management (MDM)
 
 **Applies to:**
 
 - Windows 10
 
-You can use Microsoft Endpoint Manager (MEM) Intune to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC, which allows you to configure Windows 10 client computers to only run Windows components and Microsoft Store apps, or to also allow reputable apps as defined by the Intelligent Security Graph (ISG). Using the built-in policies can be a helpful starting point, but many customers may find the available circle-of-trust options to be too limited. In order to deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI.
+You can use a Mobile Device Management (MDM) solution, like Microsoft Endpoint Manager (MEM) Intune, to configure Windows Defender Application Control (WDAC) on client machines. Intune includes native support for WDAC which can be a helpful starting point, but customers may find the available circle-of-trust options too limiting. To deploy a custom policy through Intune and define your own circle of trust, you can configure a profile using Custom OMA-URI. If your organization uses another MDM solution, check with your solution provider for WDAC policy deployment steps.
 
-## Using Intune's Built-In Policies
+## Use Intune's built-in policies
 
-Intune's built-in WDAC support enables you to deploy a policy which only allows Windows components and Microsoft Store apps to run. This policy is the non-Multiple Policy Format version of the DefaultWindows policy; the Multiple Policy Format version can be found at C:\Windows\schemas\CodeIntegrity\ExamplePolicies.
+Intune's built-in WDAC support allows you to configure Windows 10 client computers to only run:
 
-Setting "Trust apps with good reputation" to enabled is equivalent to adding [Option 14 (Enabled: Intelligent Security Graph Authorization)](./select-types-of-rules-to-create.md#windows-defender-application-control-policy-rules) to the DefaultWindows policy.
+- Windows components
-
+- 3rd party hardware and software kernel drivers
-1. Open the Microsoft Intune portal and click **Device configuration** > **Profiles** > **Create profile**.
+- Microsoft Store-signed apps
-
+- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
-2. Type a name for the new profile, select **Windows 10 and later** as the **Platform** and **Endpoint protection** as the **Profile type**.  
-
-   ![Configure profile](images/wdac-intune-create-profile-name.png)
-
-3. Click **Configure** > **Windows Defender Application Control**, choose from the following settings and then click **OK**:
-
-   - **Application control code integrity policies**: Select **Audit only** to log events but not block any apps from running or select **Enforce** to allow only Windows components and Store apps to run.  
-   - **Trust apps with good reputation**: Select **Enable** to allow reputable apps as defined by the Intelligent Security Graph to run in addition to Windows components and Store apps.
-
-   ![Configure built-in WDAC](images/wdac-intune-wdac-settings.png)
-
-## Using a Custom OMA-URI Profile
 
 > [!NOTE]
-> Policies deployed through Intune Custom OMA-URI are subject to a 350,000 byte limit. Customers whose devices are running 1903+ builds of Windows are encouraged to use [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) which are more streamlined and less than 350K bytes in size.
+> Intune's built-in policies use the pre-1903 single-policy format version of the DefaultWindows policy. You can use Intune's custom OMA-URI feature to deploy your own multiple-policy format WDAC policies and leverage features available on Windows 10 1903+ as described later in this topic.
 
-### For 1903+ systems
+> [!NOTE]
+> Intune currently uses the AppLocker CSP to deploy its built-in policies. The AppLocker CSP will always request a reboot when applying WDAC policies. You can use Intune's custom OMA-URI feature with the ApplicationControl CSP to deploy your own WDAC policies rebootlessly.
 
-Beginning in 1903, Custom OMA-URI policy deployment leverages the [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp), which has support for multiple policies and rebootless policies.
+To use Intune's built-in WDAC policies, configure [Endpoint Protection for Windows 10 (and later)](https://docs.microsoft.com/mem/intune/protect/endpoint-protection-windows-10?toc=/intune/configuration/toc.json&bc=/intune/configuration/breadcrumb/toc.json).
 
-#### Deploying policies
+## Deploy WDAC policies with custom OMA-URI
-The steps to use Intune's Custom OMA-URI functionality are:
+
+> [!NOTE]
+> Policies deployed through Intune custom OMA-URI are subject to a 350,000 byte limit. Customers should create WDAC policies that use signature-based rules, the Intelligent Security Graph, and managed installers where practical. Customers whose devices are running 1903+ builds of Windows are also encouraged to use [multiple policies](deploy-multiple-windows-defender-application-control-policies.md) which allow more granular policy.
+
+### Deploy custom WDAC policies on Windows 10 1903+
+
+Beginning with Windows 10 1903, custom OMA-URI policy deployment can use the [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp), which has support for multiple policies and rebootless policies.
+
+The steps to use Intune's custom OMA-URI functionality are:
 
 1. Know a generated policy's GUID, which can be found in the policy xml as `<PolicyID>`
 
 2. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned.
 
-3. Open the Microsoft Intune portal and click **Device configuration** > **Profiles** > **Create profile**.
+3. Open the Microsoft Intune portal and [create a profile with custom settings](https://docs.microsoft.com/mem/intune/configuration/custom-settings-windows-10).
 
-4. Type a name for the new profile, select **Windows 10 and later** as the **Platform** and **Custom** as the **Profile type**.
+4. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
-
-5. Add a row, then give your policy a name and use the following settings:
     - **OMA-URI**: ./Vendor/MSFT/ApplicationControl/Policies/_Policy GUID_/Policy
     - **Data type**: Base64
     - **Certificate file**: upload your binary format policy file. You do not need to upload a Base64 file, as Intune will convert the uploaded .bin file to Base64 on your behalf.
@@ -73,22 +68,21 @@ The steps to use Intune's Custom OMA-URI functionality are:
     > [!div class="mx-imgBorder"]
     > ![Configure custom WDAC](images/wdac-intune-custom-oma-uri.png)
 
-#### Removing policies
+### Remove WDAC policies on Windows 10 1903+
 
-Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to functionally do a rebootless delete, first replace the existing policy with an Allow All policy (found at C:\Windows\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml) and then delete the updated policy. This will immediately prevent anything from being blocked and fully deactive the policy on the next reboot.
+Upon deletion, policies deployed through Intune via the ApplicationControl CSP are removed from the system but stay in effect until the next reboot. In order to disable WDAC enforcement, first replace the existing policy with a new version of the policy that will "Allow *", like the rules in the example  policy at %windir%\schemas\CodeIntegrity\ExamplePolicies\AllowAll.xml. Once the updated policy is deployed, you can then delete the policy from the Intune portal. This will prevent anything from being blocked and fully remove the WDAC policy on the next reboot.
 
 ### For pre-1903 systems
 
 #### Deploying policies
+
 The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocker CSP](/windows/client-management/mdm/applocker-csp) and deploy a custom WDAC policy to pre-1903 systems are:
 
 1. Convert the policy XML to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned.
 
-2. Open the Microsoft Intune portal and click **Device configuration** > **Profiles** > **Create profile**.
+2. Open the Microsoft Intune portal and [create a profile with custom settings](https://docs.microsoft.com/mem/intune/configuration/custom-settings-windows-10).
 
-3. Type a name for the new profile, select **Windows 10 and later** as the **Platform** and **Custom** as the **Profile type**.
+3. Specify a **Name** and **Description** and use the following values for the remaining custom OMA-URI settings:
-
-4. Add a row, then give your policy a name and use the following settings:
     - **OMA-URI**: ./Vendor/MSFT/AppLocker/ApplicationLaunchRestrictions/_Grouping_/CodeIntegrity/Policy)
     - **Data type**: Base64
     - **Certificate file**: upload your binary format policy file
@@ -98,4 +92,4 @@ The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocke
 
 #### Removing policies
 
-Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable WDAC policy enforcement, either deploy an audit-mode policy and/or use a script to delete the existing policy.
+Policies deployed through Intune via the AppLocker CSP cannot be deleted through the Intune console. In order to disable WDAC policy enforcement, either deploy an audit-mode policy or use a script to delete the existing policy.

windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-using-memcm.md

@@ -0,0 +1,40 @@
+---
+title: Deploy Windows Defender Application Control (WDAC) policies by using Microsoft Endpoint Configuration Manager (MEMCM) (Windows 10)
+description: You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC). Learn how with this step-by-step guide.
+keywords: security, malware
+ms.prod: m365-security
+audience: ITPro
+ms.collection: M365-security-compliance
+author: jsuther1974
+ms.reviewer: jogeurte
+ms.author: jsuther
+manager: dansimp
+ms.date: 04/14/2021
+ms.technology: mde
+---
+
+# Deploy WDAC policies by using Microsoft Endpoint Configuration Manager (MEMCM)
+
+**Applies to:**
+
+- Windows 10
+- Windows Server 2016 and above
+
+You can use Microsoft Endpoint Configuration Manager (MEMCM) to configure Windows Defender Application Control (WDAC) on client machines.
+
+## Use MEMCM's built-in policies
+
+MEMCM includes native support for WDAC, which allows you to configure Windows 10 client computers with a policy that will only allow:
+
+- Windows components
+- Microsoft Store apps
+- Apps installed by MEMCM (MEMCM self-configured as a managed installer)
+- [Optional] Reputable apps as defined by the Intelligent Security Graph (ISG)
+- [Optional] Apps and executables already installed in admin-definable folder locations that MEMCM will allow through a one-time scan during policy creation on managed endpoints.
+
+For more information on using MEMCM's native WDAC policies, see [Windows Defender Application Control management with Configuration Manager](https://docs.microsoft.com/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager)
+
+## Deploy custom WDAC policies using Packages/Programs or Task Sequences
+<!-- Add step-by-step guide for SWD/OSD deployment -->
+
+Using MEMCM's built-in policies can be a helpful starting point, but customers may find the available circle-of-trust options available in MEMCM too limiting. To define your own circle-of-trust, you can use MEMCM to deploy custom WDAC policies using [script-based deployment](deploy-wdac-policies-using-script.md) via Software Distribution Packages and Programs or Operating System Deployment Task Sequences.

windows/security/threat-protection/windows-defender-application-control/deployment/deploy-wdac-policies-using-script.md

@@ -0,0 +1,54 @@
+---
+title: Deploy Windows Defender Application Control (WDAC) policies using script (Windows 10)
+description: Use scripts to deploy Windows Defender Application Control (WDAC) policies. Learn how with this step-by-step guide.
+keywords: security, malware
+ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
+ms.prod: m365-security
+audience: ITPro
+ms.collection: M365-security-compliance
+author: jsuther1974
+ms.reviewer: jogeurte
+ms.author: dansimp
+manager: dansimp
+ms.date: 04/12/2021
+ms.technology: mde
+---
+
+# Deploy WDAC policies using script
+
+**Applies to:**
+
+- Windows 10
+- Windows Server 2016 and above
+
+This topic describes how to deploy Windows Defender Application Control (WDAC) policies using script. The instructions below use Powershell but can work with any scripting host.
+
+> [!NOTE]
+> To use this procedure, download and distribute the [WDAC policy refresh tool](https://aka.ms/refreshpolicy) to all managed endpoints. Ensure your WDAC policies allow the WDAC policy refresh tool or use a managed installer to distribute the tool.
+
+## Script-based deployment process for WDAC policy
+
+1. Initialize the variables to be used by the script.
+
+    ```powershell
+    # Policy binary files should be named as {GUID}.cip for multiple policy format files (where {GUID} = <PolicyId> from the Policy XML)
+    # Single policy format binaries should be named as SiPolicy.p7b.
+    $PolicyBinary = "<Path to policy binary file to deploy>"
+    $DestinationFolder = $env:windir+"\System32\CodeIntegrity\CIPolicies\Active\"
+    $RefreshPolicyTool = "<Path where RefreshPolicy.exe can be found from managed endpoints>"
+    ```
+
+2. Copy WDAC policy binary to the destination folder.
+
+   ```powershell
+   cp $PolicyBinary $DestinationFolder
+   ```
+
+3. Repeat steps 1-2 as appropriate to deploy additional WDAC policies.
+4. Run RefreshPolicy.exe to activate and refresh all WDAC policies on the managed endpoint.
+
+   ```powershell
+   & $RefreshPolicyTool
+   ```
+
+5. If successful, you should see the message **Rebootless ConfigCI Policy Refreshing Succeeded!**

windows/security/threat-protection/windows-defender-application-control/operations/known-issues.md

@@ -0,0 +1,40 @@
+---
+title: WDAC Admin Tips & Known Issues
+description: WDAC Known Issues
+keywords: security, malware
+ms.prod: m365-security
+audience: ITPro
+ms.collection: M365-security-compliance
+author: jsuther1974
+ms.reviewer: jogeurte
+ms.author: deniseb
+manager: dansimp
+ms.date: 04/09/2021
+ms.custom: asr
+ms.technology: mde
+---
+
+# WDAC Admin Tips & Known Issues
+
+**Applies to:**
+
+- Windows 10
+- Windows Server 2016 and above
+
+This topic covers tips and tricks for admins as well as known issues with WDAC.
+Test this configuration in your lab before enabling it in production.
+
+## MSI Installations launched directly from the internet are blocked by WDAC
+
+Installing .msi files directly from the internet to a computer protected by WDAC will fail.
+For example, this command will not work:
+
+```code
+msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi
+```
+
+As a workaround, download the MSI file and run it locally:
+
+```code
+msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi  
+```

windows/security/threat-protection/windows-defender-application-control/plan-windows-defender-application-control-management.md

@@ -31,7 +31,6 @@ This topic describes the decisions you need to make to establish the processes f
 
 The first step in implementing application control is to consider how your policies will be managed and maintained over time. Developing a process for managing WDAC policies helps assure that WDAC continues to effectively control how applications are allowed to run in your organization.
 
-<!-- We should insert a diagram to show this visually -->
 Most WDAC policies will evolve over time and proceed through a set of identifiable phases during their lifetime. Typically, these phases include:
 
 1. [Define (or refine) the "circle-of-trust"](understand-windows-defender-application-control-policy-design-decisions.md) for the policy and build an audit mode version of the policy XML. In audit mode, block events are generated but files are not prevented from executing.
@@ -42,6 +41,8 @@ Most WDAC policies will evolve over time and proceed through a set of identifiab
 6. Deploy the enforced mode policy to intended devices. We recommend using staged rollouts for enforced policies to detect and respond to issues before deploying the policy broadly.
 7. Repeat steps 1-6 anytime the desired "circle-of-trust" changes.  
 
+![Recommended WDAC policy deployment process](images/PolicyFlow.png)
+
 ### Keep WDAC policies in a source control or document management solution
 
 To effectively manage WDAC policies, you should store and maintain your policy XML documents in a central repository that is accessible to everyone responsible for WDAC policy management. We recommend a source control solution such as [GitHub](https://github.com/) or a document management solution such as [Office 365 SharePoint](https://products.office.com/sharepoint/collaboration), which provide version control and allow you to specify metadata about the XML documents.

windows/security/threat-protection/windows-defender-application-control/windows-defender-application-control-deployment-guide.md

@@ -1,5 +1,5 @@
 ---
-title: Planning and getting started on the Windows Defender Application Control deployment process (Windows 10)
+title: Deploying Windows Defender Application Control policies (Windows 10)
 description: Learn how to gather information, create a plan, and begin to test initial code integrity policies for a Windows Defender Application Control deployment.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
@@ -11,83 +11,33 @@ ms.localizationpriority: medium
 audience: ITPro
 ms.collection: M365-security-compliance
 author: jsuther1974
-ms.reviewer: isbrahm
+ms.reviewer: jgeurten
 ms.author: dansimp
 manager: dansimp
 ms.date: 05/16/2018
 ms.technology: mde
 ---
 
-# Planning and getting started on the Windows Defender Application Control deployment process
+# Deploying Windows Defender Application Control policies
 
 **Applies to**
--   Windows 10
--   Windows Server 2016
 
-This topic provides a roadmap for planning and getting started on the Windows Defender Application Control (WDAC) deployment process, with links to topics that provide additional detail. Planning for WDAC deployment involves looking at both the end-user and the IT pro impact of your choices. 
+- Windows 10
+- Windows Server 2016 and above
 
-## Planning
+You should now have one or more WDAC policies ready to deploy to devices within your organization. If you have not yet completed the steps described in the [WDAC Design Guide](windows-defender-application-control-design-guide.md), do so now before proceeding.
 
-1. Review requirements, especially hardware requirements for VBS. 
+## Plan your deployment
 
-2. Group devices by degree of control needed. 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.
+As with any significant change to your environment, implementing application control can have unintended consequences. To ensure the best chance for success, you should follow safe deployment practices and plan your deployment carefully. Determine what set(s) of devices you will manage with WDAC and split them into deployment rings so you can control the scale of the deployment and be able to respond if anything should go wrong. Define the success criteria that will determine when it is safe to proceed from one ring to the next.
 
-3. Review how much variety in software and hardware is needed by roles or departments. The following questions can help you clarify how many WDAC policies to create:
+All WDAC policy changes should be deployed in audit mode before proceeding to enforcement. Carefully monitor events from devices where the policy has been deployed to ensure the block events you observe match your expectation before broadening the deployment to additional deployment rings. If your organization uses Microsoft Defender for Endpoint, you can use the Advanced Hunting feature to centrally monitor WDAC-related events. Otherwise, we recommend using an event log forwarding solution to collect relevant events from your managed endpoints.
 
-   - How standardized is the hardware?<br>This can be relevant because of drivers. You could create a WDAC 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 WDAC policies on different "reference" hardware, then merge the policies together, to ensure that the resulting policy recognizes all the drivers in your environment.
+## Choose how to deploy WDAC policies
-
-   - 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 WDAC 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 WDAC 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 WDAC policy.
-
-   - Is there already a list of accepted applications?<br>A list of accepted applications can be used to help create a baseline WDAC policy.<br>As of Windows 10, version 1703, it might also be useful to have a list of plug-ins, add-ins, or modules that you want to allow only in a specific app (such as a line-of-business app). Similarly, it might be useful to have a list of plug-ins, add-ins, or modules that you want to block in a specific app (such as a browser).
-
-   - As part of a threat review process, have you reviewed systems for software that can load arbitrary DLLs or run code or scripts? 
-     In day-to-day operations, your organization's security policy may allow certain applications, code, or scripts to run on your systems depending on their role and the context. However, if your security policy requires that you run only trusted applications, code, and scripts on your systems, you may decide to lock these systems down securely with Windows Defender Application Control policies. 
-    
-     Legitimate applications from trusted vendors provide valid functionality. However, an attacker could also potentially use that same functionality to run malicious executable code that could bypass WDAC.
-
-     For operational scenarios that require elevated security, certain applications with known Code Integrity bypasses may represent a security risk if you allow them in your WDAC policies. Other applications, where older versions of the application had vulnerabilities, also represent a risk. Therefore, you may want to deny or block such applications from your WDAC policies. For applications with vulnerabilities, once the vulnerabilities are fixed you can create a rule that only allows the fixed or newer versions of that application. The decision to allow or block applications depends on the context and on how the reference system is being used.
-
-     Security professionals collaborate with Microsoft continuously to help protect customers. With the help of their valuable reports, Microsoft has identified a list of known applications that an attacker could potentially use to bypass Windows Defender Application Control. Depending on the context, you may want to block these applications. To view this list of applications and for use case examples, such as disabling msbuild.exe, see [Microsoft recommended block rules](microsoft-recommended-block-rules.md).
-
-4. Identify LOB applications that are currently unsigned. Although requiring signed code (through WDAC) 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.
-
-## Getting started on the deployment process
-
-1.  Optionally, create a signing certificate for Windows Defender Application Control. As you deploy WDAC, you might need to sign catalog files or WDAC 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](create-code-signing-cert-for-windows-defender-application-control.md).
-
-2.  Create WDAC policies from reference computers. In this respect, creating and managing WDAC policies to align with the needs of roles or departments can be similar to managing corporate images. From each reference computer, you can create a WDAC policy, and decide how to manage that policy. You can [merge](merge-windows-defender-application-control-policies.md) WDAC policies to create a broader policy or a master policy, or you can manage and deploy each policy individually. 
-
-3.  Audit the WDAC policy and capture information about applications that are outside the policy. We recommend that you use [audit mode](audit-windows-defender-application-control-policies.md) to carefully test each WDAC 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.
-
-4.  Create a [catalog file](deploy-catalog-files-to-support-windows-defender-application-control.md) for unsigned LOB applications. Use the Package Inspector tool to create and sign a catalog file for your unsigned LOB applications. In later steps, you can merge the catalog file's signature into your WDAC 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 WDAC 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 WDAC policies from other sources also, for flexibility in how you create your final WDAC policies.
-
-7.  Deploy WDAC policies and catalog files. After you confirm that you have completed all the preceding steps, you can begin deploying catalog files and taking WDAC 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 WDAC policies more broadly. 
-
-8.  Enable desired virtualization-based security (VBS) features. Hardware-based security features—also called virtualization-based security (VBS) features—strengthen the protections offered by Windows Defender Application Control. 
-
-## Known issues
-
-This section covers known issues with WDAC. Virtualization-based protection of code integrity may be incompatible with some devices and applications, which might cause unexpected failures, data loss, or a blue screen error (also called a stop error). 
-Test this configuration in your lab before enabling it in production. 
-
-### MSI Installations are blocked by WDAC
-
-Installing .msi files directly from the internet to a computer protected by WDAC will fail. 
-For example, this command will not work:
- 
-```code
-msiexec –i https://download.microsoft.com/download/2/E/3/2E3A1E42-8F50-4396-9E7E-76209EA4F429/Windows10_Version_1511_ADMX.msi
-``` 
-
-As a workaround, download the MSI file and run it locally: 
-
- 
-```code
-msiexec –i c:\temp\Windows10_Version_1511_ADMX.msi  
-```
 
+There are several options to deploy WDAC policies to managed endpoints, including the following:
 
+1. [Deploy using a Mobile Device Management (MDM) solution](deploy-windows-defender-application-control-policies-using-intune.md), such as Microsoft Intune
+2. [Deploy using Microsoft Endpoint Configuration Manager (MEMCM)](deployment/deploy-wdac-policies-using-memcm.md)
+3. [Deploy via script](deployment/deploy-wdac-policies-using-script.md)
+4. [Deploy via Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)