Update WMI bridge info, correct per-app rule

windows/client-management/mdm/applicationcontrol-csp.md

@@ -13,17 +13,15 @@ ms.date: 05/21/2019
 
 # ApplicationControl CSP
 
-Windows Defender Application Control (WDAC) policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). This CSP provides expanded diagnostic capabilities and support for [multiple policies](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies) (introduced in Windows 10, version 1903). It also provides support for rebootless policy deployment (introduced in Windows 10, version 1709). Unlike [AppLocker CSP](applocker-csp.md), ApplicationControl CSP correctly detects the presence of no-reboot option and consequently does not schedule a reboot.
+Windows Defender Application Control (WDAC) policies can be managed from an MDM server or locally using PowerShell via the WMI Bridge through the ApplicationControl configuration service provider (CSP). The ApplicationControl CSP was added in Windows 10, version 1903. This CSP provides expanded diagnostic capabilities and support for [multiple policies](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/deploy-multiple-windows-defender-application-control-policies) (introduced in Windows 10, version 1903). It also provides support for rebootless policy deployment (introduced in Windows 10, version 1709). Unlike the [AppLocker CSP](applocker-csp.md), the ApplicationControl CSP correctly detects the presence of no-reboot option and consequently does not schedule a reboot.
-Existing WDAC policies deployed using AppLocker CSP’s CodeIntegrity node can now be deployed using ApplicationControl CSP URI. Although WDAC policy deployment via AppLocker CSP will continue to be supported, all new feature work will be done in ApplicationControl CSP only.
+Existing WDAC policies deployed using the AppLocker CSP's CodeIntegrity node can now be deployed using the ApplicationControl CSP URI. Although WDAC policy deployment via the AppLocker CSP will continue to be supported, all new feature work will be done in the ApplicationControl CSP only.
 
-ApplicationControl CSP was added in Windows 10, version 1903.
+The following diagram shows the ApplicationControl CSP in tree format.
-
-The following diagram shows ApplicationControl CSP in tree format.
 
 ![tree diagram for applicationcontrol csp](images/provisioning-csp-applicationcontrol.png)
 
 <a href="" id="vendor-msft-applicationcontrol"></a>**./Vendor/MSFT/ApplicationControl**  
-Defines the root node for ApplicationControl CSP.
+Defines the root node for the ApplicationControl CSP.
 
 Scope is permanent. Supported operation is Get.
 
@@ -33,7 +31,7 @@ An interior node that contains all the policies, each identified by their global
 Scope is permanent. Supported operation is Get.
 
 <a href="" id="applicationcontrol-policies-policyguid"></a>**ApplicationControl/Policies/_Policy GUID_**  
-ApplicationControl CSP enforces that the “ID” segment of a given policy URI is the same GUID as the policy ID in the policy blob. Each *Policy GUID* node contains a Policy node and a corresponding PolicyInfo node.
+The ApplicationControl CSP enforces that the "ID" segment of a given policy URI is the same GUID as the policy ID in the policy blob. Each *Policy GUID* node contains a Policy node and a corresponding PolicyInfo node.
 
 Scope is dynamic. Supported operation is Get.
 
@@ -121,11 +119,11 @@ Value type is char.
 
 For customers using Intune standalone or hybrid management with Configuration Manager (MEMCM) to deploy custom policies via the ApplicationControl CSP, refer to [Deploy Windows Defender Application Control policies by using Microsoft Intune](https://docs.microsoft.com/windows/security/threat-protection/windows-defender-application-control/deploy-windows-defender-application-control-policies-using-intune)
 
-## Non-Intune Usage Guidance
+## Generic MDM Server Usage Guidance
 
 In order to leverage the ApplicationControl CSP without using Intune, you must:
 
-1. Know a generated policy’s GUID, which can be found in the policy xml as <PolicyID> or <PolicyTypeID> for pre-1903 systems.
+1. Know a generated policy's GUID, which can be found in the policy xml as <PolicyID> or <PolicyTypeID> for pre-1903 systems.
 2. Convert the policies to binary format using the ConvertFrom-CIPolicy cmdlet in order to be deployed. The binary policy may be signed or unsigned.
 3. Create a policy node (a Base64-encoded blob of the binary policy representation) using the certutil -encode command line tool.
 
@@ -205,7 +203,7 @@ The following example shows the deployment of two base policies and a supplement
 
 ### Get policies
 
-Perform a GET using a deployed policy’s GUID to interrogate/inspect the policy itself or information about it.
+Perform a GET using a deployed policy's GUID to interrogate/inspect the policy itself or information about it.
 
 The following table displays the result of Get operation on different nodes:
 
@@ -265,3 +263,33 @@ The following is an example of Delete command:
         </Item>
    </Delete>
 ```
+
+## PowerShell and WMI Bridge Usage Guidance
+
+The ApplicationControl CSP can also be managed locally from PowerShell or via SCCM's task sequence scripting by leveraging the [WMI Bridge Provider](https://docs.microsoft.com/windows/client-management/mdm/using-powershell-scripting-with-the-wmi-bridge-provider).
+
+### Setup for using the WMI Bridge
+
+1. Convert your WDAC policy to Base64
+2. Open PowerShell in Local System context (through PSExec or something similar)
+3. Use WMI Interface:
+
+    ```powershell
+        $namespace = "root\cimv2\mdm\dmmap"
+        $policyClassName = "MDM_AppControl_Policies"
+        $policyBase64 = …
+    ```
+
+### Deploying a policy via WMI Bridge
+
+Run the following command. PolicyID is a GUID which can be found in the policy xml, and should be used here without braces.
+
+```powershell
+    New-CimInstance -Namespace $namespace -ClassName $policyClassName -Property @{ParentID="./Vendor/MSFT/ApplicationControl/Policies";InstanceID="<PolicyID>";Policy=$policyBase64}
+```
+
+### Querying all policies via WMI Bridge
+
+```powershell
+Get-CimInstance -Namespace $namespace -ClassName $policyClassName
+```

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

@@ -24,7 +24,7 @@ ms.date: 04/29/2020
 - Windows 10
 - Windows Server 2016
 
-You can use Microsoft Endpoint Manager (MEM) Intune to configure Windows Defender Application Control (WDAC). 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. 
+You can use Microsoft Endpoint Manager (MEM) Intune to configure Windows Defender Application Control (WDAC). 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. Beginning in 1903, Custom OMA-URI policy deployment leverages the [ApplicationControl CSP](https://docs.microsoft.com/windows/client-management/mdm/applicationcontrol-csp), which has support for multiple policies and rebootless policies. Custom OMA-URI can also be used on pre-1903 systems to deploy custom policies via the [AppLocker CSP](https://docs.microsoft.com/windows/client-management/mdm/applocker-csp).
 
@@ -50,6 +50,7 @@ Setting "Trust apps with good reputation" to enabled is equivalent to adding [Op
 ## Using a Custom OMA-URI Profile
 
 ### For 1903+ systems
+
 The steps to use Intune's Custom OMA-URI functionality to leverage the [ApplicationControl CSP](https://docs.microsoft.com/windows/client-management/mdm/applicationcontrol-csp) and deploy a custom WDAC policy to 1903+ systems are:
 
 1. Know a generated policy's GUID, which can be found in the policy xml as `<PolicyID>`
@@ -67,6 +68,7 @@ The steps to use Intune's Custom OMA-URI functionality to leverage the [Applicat
 > 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, 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.
 
 ### For pre-1903 systems
+
 The steps to use Intune's Custom OMA-URI functionality to leverage the [AppLocker CSP](https://docs.microsoft.com/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.

windows/security/threat-protection/windows-defender-application-control/use-windows-defender-application-control-policy-to-control-specific-plug-ins-add-ins-and-modules.md

@@ -34,20 +34,19 @@ As of Windows 10, version 1703, you can use WDAC policies not only to control ap
 | You can work from a list of plug-ins, add-ins, or modules that you want only a specific application to be able to run. Other applications would be blocked from running them. | Use `New-CIPolicyRule` with the `-AppID` option. |
 | In addition, you can work  from a list of plug-ins, add-ins, or modules that you want to block in a specific application. Other applications would be allowed to run them. | Use `New-CIPolicyRule` with the `-AppID` and `-Deny` options. |
 
-To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your ‘master’ policy (merging is described in the next section).
+To work with these options, the typical method is to create a policy that only affects plug-ins, add-ins, and modules, then merge it into your 'master' policy (merging is described in the next section).
 
-For example, to create a WDAC policy that allows **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization’s enterprise resource planning (ERP) application, but blocks those add-ins in other applications, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
+For example, to create a WDAC policy that allows **addin1.dll** and **addin2.dll** to run in **ERP1.exe**, your organization's enterprise resource planning (ERP) application, run the following commands. Note that in the second command, **+=** is used to add a second rule to the **$rule** variable:
 
-```
+```powershell
-$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin1.dll' -Level FileName -AppID '.\ERP1.exe'
+$rule = New-CIPolicyRule -DriverFilePath '.\ERP1.exe' -Level FileName -AppID '.\temp\addin1.dll'
-$rule += New-CIPolicyRule -DriverFilePath '.\temp\addin2.dll' -Level FileName -AppID '.\ERP1.exe'
+$rule += New-CIPolicyRule -DriverFilePath '.\ERP1.exe' -Level FileName -AppID '.\temp\addin2.dll'
 New-CIPolicy -Rules $rule -FilePath ".\AllowERPAddins.xml" -UserPEs
 ```
 
 As another example, to create a WDAC policy that blocks **addin3.dll** from running in Microsoft Word, run the following command. You must include the `-Deny` option to block the specified add-ins in the specified application:
 
-```
+```powershell
-$rule = New-CIPolicyRule -DriverFilePath '.\temp\addin3.dll' -Level FileName -Deny -AppID '.\winword.exe'
+$rule = New-CIPolicyRule -DriverFilePath '.\winword.exe' -Level FileName -Deny -AppID '.\temp\addin3.dll'
 New-CIPolicy -Rules $rule -FilePath ".\BlockAddins.xml" -UserPEs
 ```
-