Merge pull request #5069 from jsuther1974/master

Refactor deployment guide content for WDAC

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 behave more like mobile devices. In this configuration, Windows Defender Application Control (WDAC) is used to restrict devices to run only approved apps, while the OS is hardened against kernel memory attacks 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, and the policy takes effect early in the boot sequence before nearly all other OS code and before traditional antivirus solutions run.
+2. WDAC lets you set application control policy for code that runs in user mode, 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. To change signed policy requires both administrative privilege and access to the organization’s digital signing process. This makes it difficult for an attacker, including one who has managed to gain administrative privilege, to tamper with WDAC policy.
+4. You can protect the entire WDAC enforcement mechanism with HVCI. Even if a vulnerability exists in kernel mode code, HVCI greatly reduces the likelihood that an attacker could successfully exploit it. This is important because an attacker that compromises the kernel could normally disable most system defenses, including those 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 promoted Device Guard, 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 achieved when using them together. However, since HVCI relies on Windows virtualization-based security, it has hardware, firmware, and kernel driver compatibility requirements that some older systems can’t meet. This misled many people to assume that if 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 has no specific hardware or software requirements other than running Windows 10, which means customers were denied the benefits of this powerful application control capability due to Device Guard confusion.
-We hope this change will help us better communicate options for adopting application control within an organization.
+
+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 now discuss and document WDAC as an independent technology within our security stack and gave 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 your organizations.
 
 ## Related articles
 
-[Windows Defender Application Control](../windows-defender-application-control/windows-defender-application-control.md)
+- [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)
-[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))
-[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,44 +1,44 @@
 # [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)
 ### [Plan for WDAC policy lifecycle management](plan-windows-defender-application-control-management.md)
-### Design your initial WDAC policy
+### Design your WDAC policy
 #### [Understand WDAC policy design decisions](understand-windows-defender-application-control-policy-design-decisions.md)
 #### [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md)
-#### [Authorize apps deployed with a WDAC managed installer](use-windows-defender-application-control-with-managed-installer.md)
+##### [Allow apps installed by a managed installer](use-windows-defender-application-control-with-managed-installer.md)
-##### [Configure a WDAC managed installer](configure-wdac-managed-installer.md)
+##### [Configure managed installer rules](configure-wdac-managed-installer.md)
-#### [Authorize reputable apps with Intelligent Security Graph (ISG)](use-windows-defender-application-control-with-intelligent-security-graph.md)
+##### [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)
+##### [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)
-#### [Microsoft recommended block rules](microsoft-recommended-block-rules.md)
+### Create your WDAC policy
-#### [Microsoft recommended driver block rules](microsoft-recommended-driver-block-rules.md)
-### Create your initial WDAC policy
 #### [Example WDAC base policies](example-wdac-base-policies.md)
 #### [Policy creation for common WDAC usage scenarios](types-of-devices.md)
 ##### [Create a WDAC policy for lightly-managed devices](create-wdac-policy-for-lightly-managed-devices.md)
 ##### [Create a WDAC policy for fully-managed devices](create-wdac-policy-for-fully-managed-devices.md)
 ##### [Create a WDAC policy for fixed-workload devices](create-initial-default-policy.md)
 ##### [Microsoft recommended block rules](microsoft-recommended-block-rules.md)
-#### [Using the WDAC Wizard tool](wdac-wizard.md)
+##### [Microsoft recommended driver block rules](microsoft-recommended-driver-block-rules.md)
+#### [Use the WDAC Wizard tool](wdac-wizard.md)
 ##### [Create a base WDAC policy with the Wizard](wdac-wizard-create-base-policy.md)
 ##### [Create a supplemental WDAC policy with the Wizard](wdac-wizard-create-supplemental-policy.md)
 ##### [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)
-## [Windows Defender Application Control deployment guide](windows-defender-application-control-deployment-guide.md)
+### [Deploy WDAC policies with MDM](deploy-windows-defender-application-control-policies-using-intune.md)
+### [Deploy WDAC policies with MEMCM](deployment/deploy-wdac-policies-with-memcm.md)
+### [Deploy WDAC policies with script](deployment/deploy-wdac-policies-with-script.md)
+### [Deploy WDAC policies with 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)
-### [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)
-### [Use a Windows Defender Application Control policy 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 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)
@@ -47,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)
@@ -138,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,6 +1,6 @@
 ---
-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.
+description: Audits allow admins to discover apps, binaries, and scripts that should be added to the WDAC policy.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
 ms.prod: m365-security
@@ -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 lets you discover applications, binaries, and scripts that are missing from your WDAC policy but should be included.
 
-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 but would have been denied is logged in the **Applications and Services Logs\\Microsoft\\Windows\\CodeIntegrity\\Operational** event log. Script and MSI are logged in the **Applications and Services Logs\\Microsoft\\Windows\\AppLocker\\MSI and Script** event log. These events can be used to generate a new WDAC policy that can be merged with the original Base policy or deployed as a separate Supplemental policy, if allowed.
 
-**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 creating WDAC rules from audit events, follow these steps on a device with a WDAC audit mode policy.
+
+1. Install and run an application not allowed by the WDAC policy but that 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 PowerShell session, run the following commands to initialize variables used by this procedure. This procedure 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 **FilePublisher** file rule level and a **Hash** fallback level. Warning messages are redirected 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, see [Understand WDAC policy rules and file rules](select-types-of-rules-to-create.md).
+
+5. Find and review the WDAC policy file **EventsPolicy.xml** that should be found on your desktop. Ensure that it only includes file and signer rules for 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** that should be found on your desktop. This file will include a warning for any files that WDAC couldn't 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: isbrahm
+ms.reviewer: jogeurte
 ms.author: dansimp
 manager: dansimp
 ms.date: 11/13/2020
@@ -22,10 +22,10 @@ ms.technology: mde
 
 **Applies to:**
 
-- Windows 10
+- Windows 10 version 1903 and above
-- Windows Server 2016
+- 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
@@ -49,7 +49,7 @@ The restriction of only having a single code integrity policy active on a system
 
 ## Creating WDAC policies in Multiple Policy Format
 
-In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) random GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below is an example of creating a new policy in the multiple policy format.
+In order to allow multiple policies to exist and take effect on a single system, policies must be created using the new Multiple Policy Format. The "MultiplePolicyFormat" switch in [New-CIPolicy](/powershell/module/configci/new-cipolicy?preserve-view=true&view=win10-ps) results in 1) unique GUIDs being generated for the policy ID and 2) the policy type being specified as base. The below is an example of creating a new policy in the multiple policy format.
 
 ```powershell
 New-CIPolicy -MultiplePolicyFormat -ScanPath "<path>" -UserPEs -FilePath ".\policy.xml" -Level Publisher -Fallback Hash

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](/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](/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-with-memcm.md

@@ -0,0 +1,42 @@
+---
+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: jogeurte
+ms.manager: jsuther
+manager: dansimp
+ms.date: 04/14/2021
+ms.technology: mde
+ms.topic: article
+ms.localizationpriority: medium
+---
+
+# 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](/mem/configmgr/protect/deploy-use/use-device-guard-with-configuration-manager)
+
+## Deploy custom WDAC policies using Packages/Programs or Task Sequences
+
+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-with-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-with-script.md

@@ -0,0 +1,56 @@
+---
+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.prod: m365-security
+audience: ITPro
+ms.collection: M365-security-compliance
+author: jsuther1974
+ms.reviewer: jogeurte
+ms.author: jogeurte
+ms.manager: jsuther
+manager: dansimp
+ms.date: 04/14/2021
+ms.technology: mde
+ms.topic: article
+ms.localizationpriority: medium
+---
+
+# 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/example-wdac-base-policies.md

@@ -1,5 +1,5 @@
 ---
-title: Example WDAC base policies (Windows 10)
+title: Example Windows Defender Application Control (WDAC) base policies (Windows 10)
 description: When creating a WDAC policy for an organization, start from one of the many available example base policies.
 keywords: security, malware
 ms.topic: article
@@ -12,30 +12,30 @@ 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: 11/15/2019
 ms.technology: mde
 ---
 
-# Windows Defender Application Control example base policies
+# Windows Defender Application Control (WDAC) example base policies
 
 **Applies to:**
 
 - Windows 10
 - Windows Server 2016 and above
 
-When creating policies for use with Windows Defender Application Control (WDAC), it is recommended to start from an existing base policy and then add or remove rules to build your own custom policy XML files. Windows includes several example policies which can be used, or organizations which use the Device Guard Signing Service can download a starter policy from that service.
+When creating policies for use with Windows Defender Application Control (WDAC), start from an existing base policy and then add or remove rules to build your own custom policy. Windows includes several example policies that can be used, or organizations that use the Device Guard Signing Service can download a starter policy from that service.
 
 ## Example Base Policies
 
 | **Example Base Policy** | **Description** | **Where it can be found** |
 |----------------------------|---------------------------------------------------------------|--------|
-| **DefaultWindows.xml** | This example policy is available in either audit or enforce mode. It includes the rules necessary to ensure that Windows, 3rd party hardware and software kernel drivers, and Windows Store apps will run. Used as the basis for all [Microsoft Endpoint Manager(MEM)](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
+| **DefaultWindows.xml** | This example policy is available in both audit and enforced mode. It includes rules to allow Windows, third-party hardware and software kernel drivers, and Windows Store apps. Used as the basis for all [Microsoft Endpoint Manager(MEM)](https://www.microsoft.com/microsoft-365/microsoft-endpoint-manager) policies. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
 | **AllowMicrosoft.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed by the Microsoft product root certificate. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
-| **AllowAll.xml** | This example policy is useful when creating a block list policy. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
+| **AllowAll.xml** | This example policy is useful when creating a blocklist. All block policies should include rules allowing all other code to run and then add the DENY rules for your organization's needs. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
 | **AllowAll_EnableHVCI.xml** | This example policy can be used to enable [memory integrity](/windows/security/threat-protection/device-guard/memory-integrity) (also known as hypervisor-protected code integrity) using WDAC. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
-| **DenyAllAudit.xml** | This example policy should only be deployed in audit mode and can be used to audit all binaries running on critical systems or to comply with regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
+| **DenyAllAudit.xml** | Only deploy this example policy in audit mode to track all binaries running on critical systems or to meet regulatory requirements. | %OSDrive%\Windows\schemas\CodeIntegrity\ExamplePolicies |
-| **Device Guard Signing Service (DGSS) DefaultPolicy.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS. | [DGSS in the Microsoft Store for Business](https://businessstore.microsoft.com/manage/settings/devices) |
+| **Device Guard Signing Service (DGSS) DefaultPolicy.xml** | This example policy is available in audit mode. It includes the rules from DefaultWindows and adds rules to trust apps signed with your organization-specific certificates issued by the DGSS. | [Device Guard Signing Service NuGet Package](https://www.nuget.org/packages/Microsoft.Acs.Dgss.Client) |
-| **MEM Configuration Manager** | Customers who use MEM Configuration Manager (MEMCM), formerly known as System Center Configuration Manager, can deploy a policy to a device using MEMCM's built-in integration with WDAC and then copy the resulting policy XML to use as a custom base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |
+| **MEM Configuration Manager** | Customers who use MEM Configuration Manager (MEMCM) can deploy a policy with MEMCM's built-in WDAC integration, and then use the generated policy XML as an example base policy. | %OSDrive%\Windows\CCM\DeviceGuard on a managed endpoint |

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

@@ -0,0 +1,46 @@
+---
+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: jogeurte
+ms.manager: jsuther
+manager: dansimp
+ms.date: 04/14/2021
+ms.technology: mde
+ms.topic: article
+ms.localizationpriority: medium
+---
+
+# 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.
+
+## .NET native images may generate false positive block events
+
+In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, native image blocks are functionally benign as a blocked native image will fallback to its corresponding assembly and .NET will regenerate the native image at its next scheduled maintenance window.
+
+## 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/select-types-of-rules-to-create.md

@@ -1,6 +1,6 @@
 ---
-title: Understand WDAC policy rules and file rules (Windows 10)
+title: Understand Windows Defender Application Control (WDAC) policy rules and file rules (Windows 10)
-description: Learn how Windows Defender Application Control provides control over a computer running Windows 10 by using policies that include policy rules and file rules.
+description: Learn how WDAC policy rules and file rules can control your Windows 10 computers.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
 ms.prod: m365-security
@@ -18,26 +18,26 @@ ms.date: 03/04/2020
 ms.technology: mde
 ---
 
-# Understand WDAC policy rules and file rules
+# Understand Windows Defender Application Control (WDAC) policy rules and file rules
 
 **Applies to:**
 
--   Windows 10
+- Windows 10
--   Windows Server 2016 and above
+- Windows Server 2016 and above
 
-Windows Defender Application Control (WDAC) provides control over a computer running Windows 10 by using policies that specify whether a driver or application is trusted and can be run. A policy includes *policy rules* that control options such as audit mode or whether user mode code integrity (UMCI) is enabled in a WDAC policy, and *file rules* (or *file rule levels*) that specify the level at which applications will be identified and trusted.
+Windows Defender Application Control (WDAC) can control what runs on Windows 10 by setting policies that specify whether a driver or application is trusted. A policy includes *policy rules* that control options such as audit mode, and *file rules* (or *file rule levels*) that specify how applications are identified and trusted.
 
 ## Windows Defender Application Control policy rules
 
 To modify the policy rule options of an existing WDAC policy XML, use [Set-RuleOption](/powershell/module/configci/set-ruleoption). The following examples show how to use this cmdlet to add and remove a rule option on an existing WDAC policy:
 
--   To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
+- To ensure that UMCI is enabled for a WDAC policy that was created with the `-UserPEs` (user mode) option, add rule option 0 to an existing policy by running the following command:
 
     `Set-RuleOption -FilePath <Path to policy XML> -Option 0`
 
-    Note that a policy that was created without the `-UserPEs` option is empty of user mode executables, that is, applications. If you enable UMCI (Option 0) for such a policy and then attempt to run an application, Windows Defender Application Control will see that the application is not on its list (which is empty of applications), and respond. In audit mode, the response is logging an event, and in enforced mode, the response is blocking the application. To create a policy that includes user mode executables (applications), when you run `New-CIPolicy`, include the `-UserPEs` option. 
+    A policy created without the `-UserPEs` option has no rules for user mode code. If you enable UMCI (Option 0) for such a policy, WDAC will block all applications and even critical Windows user session code. In audit mode, WDAC simply logs an event, but when enforced, all user mode code will be blocked. To create a policy that includes user mode executables (applications), run `New-CIPolicy` with the `-UserPEs` option.
 
--   To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
+- To disable UMCI on an existing WDAC policy, delete rule option 0 by running the following command:
 
     `Set-RuleOption -FilePath <Path to policy XML> -Option 0 -Delete`
 
@@ -52,28 +52,28 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru
 |------------ | ----------- |
 | **0 Enabled:UMCI** | WDAC 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. |
+| **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. Kernel drivers built for Windows 10 should be WHQL certified. |
-| **3 Enabled:Audit Mode (Default)** | Enables the execution of binaries outside of the WDAC 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 WDAC policy, delete this option. |
+| **3 Enabled:Audit Mode (Default)** | Instructs WDAC to log information about applications, binaries, and scripts that would have been blocked if the policy was enforced. You can use this option to identify the potential impact of your WDAC policy, and use the audit events to refine the policy before enforcement. To enforce a WDAC policy, delete this option. |
-| **4 Disabled:Flight Signing** | If enabled, WDAC 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. |
+| **4 Disabled:Flight Signing** | If enabled, WDAC policies will not trust flightroot-signed binaries. This option would be used by organizations that only want to run released binaries, not pre-release Windows builds. |
 | **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. |
-| **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. |
+| **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed and the certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. |
 | **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. |
+| **8 Required:EV Signers** | This rule requires that drivers must be WHQL signed and have been submitted by a partner with an Extended Verification (EV) certificate. All 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 WDAC policies. Setting this rule option allows the F8 menu to appear to physically present users. |
 | **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a driver fails during startup, the WDAC 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. |
-| **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, as well as on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on pre-1903 versions of Windows 10 without the 10C or later LCU is not supported and may have unintended results. |
+| **11 Disabled:Script Enforcement** | This option disables script enforcement options. Unsigned PowerShell scripts and interactive PowerShell are no longer restricted to [Constrained Language Mode](/powershell/module/microsoft.powershell.core/about/about_language_modes). NOTE: This option is supported on 1709, 1803, and 1809 builds with the 2019 10C LCU or higher, and on devices with the Windows 10 May 2019 Update (1903) and higher. Using it on versions of Windows 10 without the proper update may have unintended results. |
 | **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. |
-| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager, that has been defined as a managed installer. |
+| **13 Enabled:Managed Installer** | Use this option to automatically allow applications installed by a managed installer. For more information, see [Authorize apps deployed with a WDAC managed installer](use-windows-defender-application-control-with-managed-installer.md) |
 | **14 Enabled:Intelligent Security Graph Authorization** | Use this option to automatically allow applications with "known good" reputation as defined by Microsoft’s Intelligent Security Graph (ISG). |
-| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically re-validate the reputation for files that were authorized by the ISG.| 
+| **15 Enabled:Invalidate EAs on Reboot** | When the Intelligent Security Graph option (14) is used, WDAC sets an extended file attribute that indicates that the file was authorized to run. This option will cause WDAC to periodically revalidate the reputation for files that were authorized by the ISG.|
 | **16 Enabled:Update Policy No Reboot** | Use this option to allow future WDAC policy updates to apply without requiring a system reboot. NOTE: This option is only supported on Windows 10, version 1709, and above.|
 | **17 Enabled:Allow Supplemental Policies** | Use this option on a base policy to allow supplemental policies to expand it. NOTE: This option is only supported on Windows 10, version 1903, and above. |
-| **18 Disabled:Runtime FilePath Rule Protection** | Disable default FilePath rule protection (apps and executables allowed based on file path rules must come from a file path that’s only writable by an administrator) for any FileRule that allows a file based on FilePath. NOTE: This option is only supported on Windows 10, version 1903, and above. |
+| **18 Disabled:Runtime FilePath Rule Protection** | This option disables the default runtime check that only allows FilePath rules for paths that are only writable by an administrator. NOTE: This option is only supported on Windows 10, version 1903, and above. |
-| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically-loaded libraries. NOTE: This option is only supported on Windows 10, version 1803, and above. |
+| **19 Enabled:Dynamic Code Security** | Enables policy enforcement for .NET applications and dynamically loaded libraries. NOTE: This option is only supported on Windows 10, version 1803, and above. |
 
 ## Windows Defender Application Control 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 WDAC 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, WDAC 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. 
+File rule levels allow administrators to specify the level at which they want to trust their applications. This level of trust could be as granular as the hash of each binary or as general as a CA certificate. You specify file rule levels when using WDAC PowerShell cmdlets to create and modify policies.
 
 Each file rule level has its benefit and disadvantage. Use Table 2 to select the appropriate protection level for your available administrative resources and Windows Defender Application Control deployment scenario.
 
@@ -81,18 +81,18 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
 
 | 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. |
+| **Hash** | Specifies individual hash values for each discovered binary. This is the most specific level and requires additional effort 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. |
+| **FileName** | Specifies the original filename for each binary. Although the hash values for an application are modified when updated, the file names are typically not. This level offers less specific security than the hash level but does not typically require a policy update when any binary is modified. |
-| **FilePath** | Beginning with Windows 10 version 1903, this specifies rules that allow execution of binaries contained under specific file path locations. Additional information about FilePath level rules can be found below. |
+| **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. Additional information about FilePath level rules can be found below. |
-| **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. |
+| **SignedVersion** | This level combines the publisher rule with a version number and allows anything to run from the specified publisher with a version at or above the specified version number. |
-| **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). |
+| **Publisher** | This level combines the PcaCertificate level (typically one certificate below the root) and the common name (CN) of the leaf certificate. You can use this rule level to trust a certificate issued by a particular CA and issued to a specific company you trust (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. |
+| **FilePublisher** | This level combines 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 WDAC policy when these certificates expire. |
+| **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 other certificate levels, so the WDAC policy must be updated whenever these certificates change. |
-| **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). |
+| **PcaCertificate** | Adds the highest available certificate in the provided certificate chain to signers. This level 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. |
+| **WHQL** | Trusts binaries if they have been validated and signed by WHQL. This level 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. |
+| **WHQLPublisher** | This level combines the WHQL level 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. |
+| **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 level is primarily for kernel binaries. |
 
 > [!NOTE]
 > When you create WDAC policies with [New-CIPolicy](/powershell/module/configci/new-cipolicy), 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.
@@ -102,37 +102,35 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the
 
 ## Example of file rule levels in use
 
-For example, consider some IT professionals in a department that runs many servers. They decide they want their servers to run only software signed by the providers of their software and drivers, that is, the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.
+For example, consider an IT professional in a department that runs many servers. They only want to run software signed by the companies that provide their hardware, operating system, antivirus, and other important software. They know that their servers also run an internally written application that is unsigned but is rarely updated. They want to allow this application to run.
 
-To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They enable the policy in auditing mode and gather information about any necessary software that was not included on the reference server. They merge WDAC policies into the original policy to allow that additional software to run. Then they enable the WDAC policy in enforced mode for their servers.
+To create the WDAC policy, they build a reference server on their standard hardware, and install all of the software that their servers are known to run. Then they run [New-CIPolicy](/powershell/module/configci/new-cipolicy) with **-Level Publisher** (to allow software from their software providers, the "Publishers") and **-Fallback Hash** (to allow the internal, unsigned application). They deploy the policy in auditing mode to determine the potential impact from enforcing the policy. Using the audit data, they update their WDAC policies to include any additional software they want to run. Then they enable the WDAC policy in enforced mode for their servers.
 
-As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If they come to a time when the internally-written, unsigned application must be updated, they must also update the WDAC policy so that the hash in the policy matches the hash of the updated internal application.
+As part of normal operations, they will eventually install software updates, or perhaps add software from the same software providers. Because the "Publisher" remains the same on those updates and software, they will not need to update their WDAC policy. If the unsigned, internal application is updated, they must also update the WDAC policy to allow the new version.
-
-They could also choose to create a catalog that captures information about the unsigned internal application, then sign and distribute the catalog. Then the internal application could be handled by WDAC policies in the same way as any other signed application. An update to the internal application would only require that the catalog be regenerated, signed, and distributed (no restarts would be required).
 
 ## More information about filepath rules
 
-Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. IT Pros should take care while crafting path rules to allow paths that they know are likely to remain to be admin-writeable only and deny execution from sub-directories where standard users can modify ACLs on the folder. 
+Filepath rules do not provide the same security guarantees that explicit signer rules do, as they are based on mutable access permissions. Filepath rules are best suited for environments where most users are running as standard rather than admin. Path rules are best suited to allow paths that you expect will remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder.
 
-By default, WDAC performs a user-writeability check at runtime which ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access. 
+By default, WDAC performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath and its parent directories (recursively) do not allow standard users write access.
 
-There is a defined list of SIDs which WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable even if the additional SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above. 
+There is a defined list of SIDs which WDAC recognizes as admins. If a filepath allows write permissions for any SID not in this list, the filepath is considered to be user-writeable even if the SID is associated to a custom admin user. To handle these special cases, you can override WDAC's runtime admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option described above.
+
+WDAC's list of well-known admin SIDs are:
 
-WDAC's list of well-known admin SIDs are: <br>
 S-1-3-0; S-1-5-18; S-1-5-19; S-1-5-20; S-1-5-32-544; S-1-5-32-549; S-1-5-32-550; S-1-5-32-551; S-1-5-32-577; S-1-5-32-559; S-1-5-32-568; S-1-15-2-1430448594-2639229838-973813799-439329657-1197984847-4069167804-1277922394; S-1-15-2-95739096-486727260-2033287795-3853587803-1685597119-444378811-2746676523.
 
-When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully-qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch. 
+When generating filepath rules using [New-CIPolicy](/powershell/module/configci/new-cipolicy), a unique, fully qualified path rule is generated for every file discovered in the scanned path(s). To create rules that instead allow all files under a specified folder path, use [New-CIPolicyRule](/powershell/module/configci/new-cipolicyrule) to define rules containing wildcards using the [-FilePathRules](/powershell/module/configci/new-cipolicyrule#parameters) switch.
 
-Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\\*` would include `C:\foo\\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path are not supported (ex. `C:\\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`). <br/> The use of macros is also supported and useful in scenarios where the system drive is different from the `C:\` drive. Supported macros: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`.
+Wildcards can be used at the beginning or end of a path rule; only one wildcard is allowed per path rule. Wildcards placed at the end of a path authorize all files in that path and its subdirectories recursively (ex. `C:\*` would include `C:\foo\*` ). Wildcards placed at the beginning of a path will allow the exact specified filename under any path (ex. `*\bar.exe` would allow `C:\bar.exe` and `C:\foo\bar.exe`). Wildcards in the middle of a path are not supported (ex. `C:\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`).
 
-> [!NOTE]
+You can also use the following macros when the exact volume may vary: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`.
-> Due to an existing bug, you can not combine Path-based ALLOW rules with any DENY rules in a single policy. Instead, either separate DENY rules into a separate Base policy or move the Path-based ALLOW rules into a supplemental policy as described in [Deploy multiple WDAC policies.](deploy-multiple-windows-defender-application-control-policies.md)
 
 ## Windows Defender Application Control filename rules
 
-File name rule levels provide administrators to specify the file attributes off which to base a file name rule. File name rules provide the same security guarantees that explicit signer rules do, as they are based on non-mutable file attributes. Specification of the file name level occurs when creating new policy rules. In addition, to combine file name levels found in multiple policies, you can merge multiple policies. 
+File name rule levels let you specify file attributes to base a rule on. File name rules provide the same security guarantees that explicit signer rules do, as they are based on non-mutable file attributes. Specification of the file name level occurs when creating new policy rules.
 
-Use Table 3 to select the appropriate file name level for your available administrative resources and Windows Defender Application Control deployment scenario. For instance, an LOB or production application and its binaries (eg. DLLs) may all share the same product name. This allows users to easily create targeted policies based on the Product Name filename rule level.  
+Use Table 3 to select the appropriate file name level for your use cases. For instance, an LOB or production application and its binaries may all share the same product name. This option lets you easily create targeted policies based on the Product Name filename rule level.
 
 **Table 3. Windows Defender Application Control policy - filename levels**
 

windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-intelligent-security-graph.md

@@ -25,33 +25,31 @@ ms.technology: mde
 - Windows 10
 - Windows Server 2016 and above
 
-Application execution control can be difficult to implement in enterprises that do not have processes to effectively control the deployment of applications centrally through an IT managed system. In such environments, users are empowered to acquire the applications they need for work, making accounting for all the applications that would need to be authorized for execution control a daunting task.  
+Application control can be difficult to implement in organizations that don't deploy and manage applications through an IT-managed system. In such environments, users can acquire the applications they want to use for work, making it hard to build an effective application control policy.
 
-Windows 10, version 1709 (also known as the Windows 10 Fall Creators Update) provides a new option, known as the Microsoft Intelligent Security Graph authorization, that allows IT administrators to automatically authorize applications that the Microsoft Intelligent Security Graph recognizes as having known good reputation. The Microsoft Intelligent Security Graph option helps IT organizations take a significant first step towards going from having no application control at all to a simple means of preventing the execution of unknown and known bad software. To learn more about the Microsoft Intelligent Security Graph, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services).
+Beginning with Windows 10, version 1709, you can set an option to automatically allow applications that the Microsoft Intelligent Security Graph recognizes as having known good reputation. The ISG option helps organizations begin to implement application control even when the organization has limited control over their app ecosystem. To learn more about the Microsoft Intelligent Security Graph, see the Security section in [Major services and features in Microsoft Graph](/graph/overview-major-services).
 
 ## How does the integration between WDAC and the Intelligent Security Graph work?
 
-The Microsoft Intelligent Security Graph relies on the same vast security intelligence and machine learning analytics which power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having known good, known bad, or unknown reputation. When an unevaluated file is run on a system with WDAC enabled with the Microsoft Intelligent Security Graph authorization option specified, WDAC queries the file's reputation by sending its hash and signing information to the cloud. If the Microsoft Intelligent Security Graph determines that the file has a known good reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the file tries to execute, if there are no explicit deny rules present for the file, it will be allowed to run based on its positive reputation. Conversely, a file that has unknown or known bad reputation will still be allowed to run in the presence of a rule that explicitly allows the file.
+The ISG uses the same vast security intelligence and machine learning analytics that power Microsoft Defender SmartScreen and Microsoft Defender Antivirus to help classify applications as having known good, known bad, or unknown reputation. When a binary runs on a system with WDAC enabled with the ISG option, WDAC checks the file's reputation by sending its hash and signing information to the cloud. If the ISG reports that the file has a known good reputation, the $KERNEL.SMARTLOCKER.ORIGINCLAIM kernel Extended Attribute (EA) is written to the file. Every time the binary runs, it is allowed based on its positive reputation unless there is an explicit deny rule set in the WDAC policy. Conversely, a file that has unknown or known bad reputation will be allowed if your WDAC policy explicitly allows it.
 
-Additionally, an application installer which is determined to have known good reputation will pass along that positive reputation to any files that it writes. This way, all the files needed to install and run an app are granted positive reputation data.
+If the file with good reputation is an application installer, its reputation will pass along to any files that it writes to disk. This way, all the files needed to install and run an app inherit the positive reputation data from the installer.
 
 WDAC periodically re-queries the reputation data on a file. Additionally, enterprises can specify that any cached reputation results are flushed on reboot by using the **Enabled:Invalidate EAs on Reboot** option.
 
 >[!NOTE]
 >Admins should make sure there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be classified as being known good by the Intelligent Security Graph, such as custom line-of-business (LOB) apps. Since the Intelligent Security Graph is powered by global prevalence data, internal LOB apps may not be recognized as being known good. Other mechanisms like managed installer and explicit rules will help cover internal applications. Both Microsoft Endpoint Manager Configuration Manager (MEMCM) and Microsoft Endpoint Manager Intune (MEM Intune) can be used to create and push a WDAC policy to your client machines.  
 
-Other examples of WDAC policies are available in `C:\Windows\schemas\CodeIntegrity\ExamplePolicies` and can help authorize Windows OS components, WHQL signed drivers and all Store apps. Admins can reference and customize them as needed for their Windows Defender Application Control deployment or [create a custom WDAC policy](./create-initial-default-policy.md). 
-
 ## Configuring Intelligent Security Graph authorization for Windows Defender Application Control
 
-Setting up the Microsoft Intelligent Security Graph authorization is easy regardless of what management solution you use. Configuring the Microsoft Intelligent Security Graph option involves these basic steps: 
+Setting up the ISG is easy using any management solution you wish. Configuring the Microsoft Intelligent Security Graph option involves these basic steps:
 
 - [Ensure that the Microsoft Intelligent Security Graph option is enabled in the WDAC policy XML](#ensure-that-the-intelligent-security-graph-option-is-enabled-in-the-wdac-policy-xml)
 - [Enable the necessary services to allow WDAC to use the Microsoft Intelligent Security Graph correctly on the client](#enable-the-necessary-services-to-allow-wdac-to-use-the-isg-correctly-on-the-client)
 
 ### Ensure that the Intelligent Security Graph option is enabled in the WDAC policy XML
 
-In order to enable trust for executables based on classifications in the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This can be done with the Set-RuleOption cmdlet. In addition, it is recommended from a security perspective to also enable the **Enabled:Invalidate EAs on Reboot** option to invalidate the cached Intelligent Security Graph results on reboot to force rechecking of applications against the Microsoft Intelligent Security Graph. Caution is advised if devices will regularly transition to and from environments that may not be able to access the Microsoft Intelligent Security Graph. The following example shows both options being set. 
+To allow apps and binaries based on the Microsoft Intelligent Security Graph, the **Enabled:Intelligent Security Graph authorization** option must be specified in the WDAC policy. This step can be done with the Set-RuleOption cmdlet. You should also enable the **Enabled:Invalidate EAs on Reboot** option so that ISG results are verified again after each reboot. The ISG option is not recommended for devices that don't have regular access to the internet. The following example shows both options being set.
 
 ```code
 <Rules> 
@@ -81,29 +79,27 @@ In order to enable trust for executables based on classifications in the Microso
 
 ### Enable the necessary services to allow WDAC to use the ISG correctly on the client
 
-In order for the heuristics used by the Microsoft Intelligent Security Graph to function properly, a number of component in Windows must be enabled. The easiest way to do this is to run the appidtel executable in `c:\windows\system32`.
+In order for the heuristics used by the ISG to function properly, a number of components in Windows must be enabled. You can configure these components by running the appidtel executable in `c:\windows\system32`.
 
 ```
 appidtel start
 ```
 
-This step is not required for WDAC policies deployed over MDM using the AppLocker CSP, as the CSP will enable the necessary components. This step is also not required when enabling the Microsoft Intelligent Security Graph through the MEMCM WDAC UX. However, if custom policies are being deployed outside of the WDAC UX through MEMCM, then this step is required.   
+This step isn't required for WDAC policies deployed over MDM, as the CSP will enable the necessary components. This step is also not required when the ISG is configured using MEMCM's WDAC integration.
 
 ## Security considerations with the Intelligent Security Graph
 
-Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do. It is best suited for deployment to systems where each user is configured as a standard user and there are other monitoring systems in place like Microsoft Defender for Endpoint to help provide optics into what users are doing. 
+Since the Microsoft Intelligent Security Graph is a heuristic-based mechanism, it doesn't provide the same security guarantees that explicit allow or deny rules do. It's best suited where users operate with standard user rights and where a security monitoring solution like Microsoft Defender for Endpoint is used.
 
-Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of WDAC when the Microsoft Intelligent Security Graph option is allowed by circumventing or corrupting the heuristics used to assign reputation to application executables. The Microsoft Intelligent Security Graph option uses the same heuristic tracking as managed installer and so for application installers that include an option to automatically run the application at the end of the installation process the heuristic may over-authorize.  
+Processes running with kernel privileges can circumvent WDAC by setting the ISG extended file attribute to make a binary appear to have known good reputation. Also, since the ISG option passes along reputation from application installers to the binaries they write to disk, it can over-authorize files in some cases where the installer launches the application upon completion.
 
 ## Known limitations with using the Intelligent Security Graph
 
-Since the Microsoft Intelligent Security Graph relies on identifying executables as being known good, there are cases where it may classify legitimate executables as unknown, leading to blocks that need to be resolved either with a rule in the WDAC policy, a catalog signed by a certificate trusted in the WDAC policy or by deployment through a WDAC managed installer. Typically, this is due to an installer or application using a dynamic file as part of execution. These files do not tend to build up known good reputation. Auto-updating applications have also been observed using this mechanism and may be flagged by the ISG.  
+Since the ISG only allows binaries that are known good, there are cases where legitimate software may be unknown to the ISG and will be blocked by WDAC. In this case, you need to allow the software with a rule in your WDAC policy, deploy a catalog signed by a certificate trusted in the WDAC policy, or install the software from a WDAC managed installer. Installers or applications that dynamically create binaries at runtime, as well as self-updating applications, may exhibit this symptom.
 
-Modern apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. As modern apps are signed by the Microsoft Store and Microsoft Store for Business, it is straightforward to authorize modern apps with signer rules in the WDAC policy.
+Packaged apps are not supported with the Microsoft Intelligent Security Graph heuristics and will need to be separately authorized in your WDAC policy. Since packaged apps have a strong app identity and must be signed, it is straightforward to authorize these apps with your WDAC policy.
 
-The Microsoft Intelligent Security Graph heuristics do not authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.  
+The ISG doesn't authorize kernel mode drivers. The WDAC policy must have rules that allow the necessary drivers to run.  
-
-In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies. Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted. Review for functionality and performance for the related applications using the native images maybe necessary in some cases. 
 
 >[!NOTE]
-> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. MEM Intune's built-in WDAC support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using [Intune's OMA-URI functionality](./deploy-windows-defender-application-control-policies-using-intune.md#using-a-custom-oma-uri-profile).
+> A rule that explicitly denies or allows a file will take precedence over that file's reputation data. MEM Intune's built-in WDAC support includes the option to trust apps with good reputation via the Microsoft Intelligent Security Graph, but it has no option to add explicit allow or deny rules. In most circumstances, customers enforcing application control need to deploy a custom WDAC policy (which can include the Microsoft Intelligent Security Graph option if desired) using [Intune's OMA-URI functionality](deploy-windows-defender-application-control-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).

windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-with-managed-installer.md

@@ -1,6 +1,6 @@
 ---
-title: Authorize apps deployed with a WDAC managed installer (Windows 10)
+title: Authorize apps installed by a managed installer (Windows 10)
-description: Explains how you can use a managed installer to automatically authorize applications deployed and installed by a designated software distribution solution, such as Microsoft Endpoint Configuration Manager.
+description: Explains how to automatically allow applications deployed and installed by a managed installer.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
 ms.prod: m365-security
@@ -11,63 +11,49 @@ 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: 08/14/2020
+ms.date: 04/20/2021
 ms.technology: mde
 ---
 
-# Authorize apps deployed with a WDAC managed installer
+# Authorize apps deployed by a managed installer
 
 **Applies to:**
 
 - Windows 10
 - Windows Server 2019
 
-Windows 10, version 1703 (also known as the Windows 10 Creators Update) provides a new option, known as a managed installer, that allows IT administrators to automatically authorize applications deployed and installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager.
+Windows 10, version 1703 introduced a new option for Windows Defender Application Control (WDAC), called managed installer, that helps balance security and manageability when enforcing application control policies. This option lets you automatically allow applications installed by a designated software distribution solution such as Microsoft Endpoint Configuration Manager.
-A managed installer helps an IT admin balance security and manageability requirements when employing application execution control policies by providing an option that does not require specifying explicit rules for software that is being managed through a software distribution solution.
 
 ## How does a managed installer work?
 
-A managed installer uses a new rule collection in AppLocker to specify one or more executables that are trusted by the organization as an authorized source for application deployment.
+A new rule collection in AppLocker specifies binaries that are trusted by the organization as an authorized source for application deployment. When one of these binaries runs, Windows will monitor the binary's process (and processes it launches) and tag all files it writes as having originated from a managed installer. The managed installer rule collection is configured using Group Policy and can be applied with the Set-AppLockerPolicy PowerShell cmdlet. You can't currently set managed installers with the AppLocker CSP through MDM.
 
-Specifying an executable as a managed installer will cause Windows to tag files that are written from the executable's process (or processes it launches) as having originated from a trusted installation authority. The Managed Installer rule collection is currently supported for AppLocker rules in Group Policy and in Configuration Manager, but not in the AppLocker CSP for OMA-URI policies.
+Having defined your managed installers using AppLocker, you can then configure WDAC to trust files installed by a managed installer by adding the Enabled:Managed Installer option to your WDAC policy. Once that option is set, WDAC will check for managed installer origin information when determining whether or not to allow a binary to run. As long as there are no deny rules present for the file, WDAC will allow a file to run based on its managed installer origin.
 
-Once the IT administrator adds the Allow: Managed Installer option to a WDAC policy, the WDAC component will subsequently check for the presence of the origin information when evaluating other application execution control rules specified in the policy. If there are no deny rules present for the file, it will be authorized based on the managed installer origin information.
+You should ensure that the WDAC policy allows the system to boot and any other authorized applications that can't be deployed through a managed installer.
 
-Admins needs to ensure that there is a WDAC policy in place to allow the system to boot and run any other authorized applications that may not be deployed through a managed installer.
+For an example of a managed installer use case, see [Creating a WDAC policy for fully managed devices](create-wdac-policy-for-fully-managed-devices.md).
-An example managed installer use-case can be seen in the guidance for [creating a WDAC policy for fully-managed devices](create-wdac-policy-for-fully-managed-devices.md).
-
-Note that a WDAC policy with managed installer configured will begin to tag files which originated from that managed installer, regardless of whether the policy is in audit or enforced mode.
 
 ## Security considerations with managed installer
 
-Since managed installer is a heuristic-based mechanism, it does not provide the same security guarantees that explicit allow or deny rules do.
+Since managed installer is a heuristic-based mechanism, it doesn't provide the same security guarantees that explicit allow or deny rules do.
-It is best suited for deployment to systems where each user is configured as a standard user and where all software is deployed and installed by a software distribution solution, such as  Microsoft Endpoint Configuration Manager.
+It is best suited for use where each user operates as a standard user and where all software is deployed and installed by a software distribution solution, such as Microsoft Endpoint Configuration Manager.
 
 Users with administrator privileges or malware running as an administrator user on the system may be able to circumvent the intent of Windows Defender Application Control when the managed installer option is allowed.
-If the authorized managed installer process performs installations in the context of a user with standard privileges, then it is possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
+
-Some application installers include an option to automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization may continue to apply to all files created during the first run of the application. This could result in over-authorization for executables that were not intended.
+If a managed installer process runs in the context of a user with standard privileges, then it is possible that standard users or malware running as standard user may be able to circumvent the intent of Windows Defender Application Control.
-To avoid this, ensure that the application deployment solution being used as a managed installer limits running applications as part of installation.
+
+Some application installers may automatically run the application at the end of the installation process. If this happens when the installer is run by a managed installer, then the managed installer's heuristic tracking and authorization will extend to all files created during the first run of the application. This could result in over-authorization for executables that were not intended. To avoid that outcome, ensure that the application deployment solution used as a managed installer limits running applications as part of installation.
 
 ## Known limitations with managed installer
 
-- Application execution control based on managed installer does not support applications that self-update/auto-update.
+- Application control based on managed installer does not support applications that self-update. If an application deployed by a managed installer later updates itself, the updated application files won't include the managed installer origin information and may not be able to run. When you rely on managed installers, you must deploy and install all application updates using a managed installer or include rules to authorize the app in the WDAC policy. In some cases, it may be possible to also designate an application binary that performs self-updates as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
-If an application deployed by a managed installer subsequently updates itself, the updated application files will no longer include the managed installer origin information and will not be authorized to run.
-Enterprises should deploy and install all application updates using the managed installer.
-In some cases, it may be possible to also designate an application binary that performs the self-updates as a managed installer.
-Proper review for functionality and security should be performed for the application before using this method.
 
-- Modern apps deployed through a managed installer will not be tracked by the managed installer heuristic and will need to be separately authorized in your WDAC policy.
+- [Packaged apps (MSIX)](/windows/msix/) deployed through a managed installer aren't tracked by the managed installer heuristic and will need to be separately authorized in your WDAC policy. See [Manage packaged apps with WDAC](manage-packaged-apps-with-windows-defender-application-control.md).
 
-- Executables that extract files and then attempt to execute may not be allowed by the managed installer heuristic.
+- Some applications or installers may extract, download, or generate binaries and immediately attempt to run them. Files run by such a process may not be allowed by the managed installer heuristic. In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer. Proper review for functionality and security should be performed for the application before using this method.
-In some cases, it may be possible to also designate an application binary that performs such an operation as a managed installer.
-Proper review for functionality and security should be performed for the application before using this method.
 
-- The managed installer heuristic does not authorize drivers.
+- The managed installer heuristic doesn't authorize kernel drivers. The WDAC policy must have rules that allow the necessary drivers to run.  
-The WDAC policy must have rules that allow the necessary drivers to run.  
-
-- In some cases, the code integrity logs where WDAC errors and warnings are written will contain error events for native images generated for .NET assemblies.
-Typically, the error is functionally benign as a blocked native image will result in the corresponding assembly being re-interpreted.
-Review for functionality and performance for the related applications using the native images maybe necessary in some cases.

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

@@ -1,6 +1,6 @@
 ---
-title: Planning and getting started on the Windows Defender Application Control deployment process (Windows 10)
+title: Deploying Windows Defender Application Control (WDAC) 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.
+description: Learn how to plan and implement a WDAC deployment.
 keywords: security, malware
 ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
 ms.prod: m365-security
@@ -11,83 +11,33 @@ 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/16/2018
 ms.technology: mde
 ---
 
-# Planning and getting started on the Windows Defender Application Control deployment process
+# Deploying Windows Defender Application Control (WDAC) 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. If you haven't 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. Decide what devices you will manage with WDAC and split them into deployment rings so you can control the scale of the deployment and respond if anything goes wrong. Define the success criteria that will determine when it's safe to continue 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 other 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:
 
+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-with-memcm.md)
+3. [Deploy via script](deployment/deploy-wdac-policies-with-script.md)
+4. [Deploy via Group Policy](deploy-windows-defender-application-control-policies-using-group-policy.md)