deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-13 13:57:22 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

Merge branch 'main' into patch-1

Browse Source
This commit is contained in:
Aaron Czechowski 2022-05-02 16:11:54 -07:00 committed by GitHub
commit b129b3b98b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
15 changed files with 375 additions and 67 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
education/includes/education-content-updates.md
View File

@ -8,6 +8,7 @@
| Published On |Topic title | Change |
|------|------------|--------|
| 4/25/2022 | [Deploy Windows 10 in a school district (Windows 10)](/education/windows/deploy-windows-10-in-a-school-district) | modified |
| 4/25/2022 | [Deploy Windows 10 in a school district (Windows 10)](/education/windows/deploy-windows-10-in-a-school-district) | modified |
## Week of April 18, 2022

1
store-for-business/includes/store-for-business-content-updates.md
View File

@ -8,3 +8,4 @@
| Published On |Topic title | Change |
|------|------------|--------|
| 4/28/2022 | [Prerequisites for Microsoft Store for Business and Education (Windows 10)](/microsoft-store/prerequisites-microsoft-store-for-business) | modified |
| 4/28/2022 | [Prerequisites for Microsoft Store for Business and Education (Windows 10)](/microsoft-store/prerequisites-microsoft-store-for-business) | modified |

86
windows/client-management/mdm/enroll-a-windows-10-device-automatically-using-group-policy.md
View File

@ -6,7 +6,7 @@ ms.topic: article
ms.prod: w10
ms.technology: windows
author: dansimp
ms.date: 03/02/2022
ms.date: 04/30/2022
ms.reviewer:
manager: dansimp
ms.collection: highpri
@ -18,7 +18,7 @@ ms.collection: highpri
- Windows 10
Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to MDM for Active Directory (AD) domain-joined devices.
Starting in Windows 10, version 1709, you can use a Group Policy to trigger auto-enrollment to Mobile Device Management (MDM) for Active Directory (AD) domain-joined devices.
The enrollment into Intune is triggered by a group policy created on your local AD and happens without any user interaction. This means you can automatically mass-enroll a large number of domain-joined corporate devices into Microsoft Intune. The enrollment process starts in the background once you sign in to the device with your Azure AD account.
@ -42,9 +42,9 @@ The auto-enrollment relies on the presence of an MDM service and the Azure Activ
When the auto-enrollment Group Policy is enabled, a task is created in the background that initiates the MDM enrollment. The task will use the existing MDM service configuration from the Azure Active Directory information of the user. If multi-factor authentication is required, the user will get a prompt to complete the authentication. Once the enrollment is configured, the user can check the status in the Settings page.
In Windows 10, version 1709 or later, when the same policy is configured in GP and MDM, the GP policy wins (GP policy takes precedence over MDM). Since Windows 10, version 1803, a new setting allows you to change the policy conflict winner to MDM. For additional information, see [Windows 10 Group Policy vs. Intune MDM Policy who wins?](/archive/blogs/cbernier/windows-10-group-policy-vs-intune-mdm-policy-who-wins)
In Windows 10, version 1709 or later, when the same policy is configured in Group Policy and MDM, Group Policy policy takes precedence over MDM. Since Windows 10, version 1803, a new setting allows you to change precedence to MDM. For additional information, see [Windows 10 Group Policy vs. Intune MDM Policy who wins?](/archive/blogs/cbernier/windows-10-group-policy-vs-intune-mdm-policy-who-wins)
For this policy to work, you must verify that the MDM service provider allows the GP triggered MDM enrollment for domain joined devices.
For this policy to work, you must verify that the MDM service provider allows Group Policy initiated MDM enrollment for domain-joined devices.
## Verify auto-enrollment requirements and settings
@ -60,12 +60,13 @@ The following steps demonstrate required settings using the Intune service:
![Auto-enrollment activation verification.](images/auto-enrollment-activation-verification.png)
> [!IMPORTANT]
> For BYOD devices, the MAM user scope takes precedence if both MAM user scope and MDM user scope (automatic MDM enrollment) are enabled for all users (or the same groups of users). The device will use Windows Information Protection (WIP) Policies (if you configured them) rather than being MDM enrolled.
> For bring-your-own devices (BYOD devices), the Mobile Application Management (MAM) user scope takes precedence if both MAM user scope and MDM user scope (automatic MDM enrollment) are enabled for all users (or the same groups of users). The device will use Windows Information Protection (WIP) Policies (if you configured them) rather than being MDM enrolled.
>
> For corporate devices, the MDM user scope takes precedence if both scopes are enabled. The devices get MDM enrolled.
> For corporate-owned devices, the MDM user scope takes precedence if both scopes are enabled. The devices get MDM enrolled.
3. Verify that the device OS version is Windows 10, version 1709 or later.
4. Auto-enrollment into Intune via Group Policy is valid only for devices which are hybrid Azure AD joined. This means that the device must be joined into both local Active Directory and Azure Active Directory. To verify that the device is hybrid Azure AD joined, run `dsregcmd /status` from the command line.
4. Auto-enrollment into Intune via Group Policy is valid only for devices which are hybrid Azure AD joined. The device must be joined into both local Active Directory and Azure Active Directory. To verify that the device is hybrid Azure AD joined, run `dsregcmd /status` from the command line.
You can confirm that the device is properly hybrid-joined if both **AzureAdJoined** and **DomainJoined** are set to **YES**.
@ -87,7 +88,7 @@ The following steps demonstrate required settings using the Intune service:
:::image type="content" alt-text="Mobility setting MDM intune." source="images/auto-enrollment-microsoft-intune-setting.png" lightbox="images/auto-enrollment-microsoft-intune-setting.png":::
7. Verify that the *Enable Automatic MDM enrollment using default Azure AD credentials* group policy (**Local Group Policy Editor > Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is properly deployed to all devices which should be enrolled into Intune.
7. Verify that the *Enable Automatic MDM enrollment using default Azure AD credentials* group policy (**Local Group Policy Editor** > **Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **MDM**) is properly deployed to all devices which should be enrolled into Intune.
You may contact your domain administrators to verify if the group policy has been deployed successfully.
8. Verify that the device is not enrolled with the old Intune client used on the Intune Silverlight Portal (this is the Intune portal used before the Azure portal).
@ -105,35 +106,31 @@ Requirements:
- Enterprise has MDM service already configured
- Enterprise AD must be registered with Azure AD
1. Run GPEdit.msc
Click Start, then in the text box type gpedit.
1. Run `GPEdit.msc`. Choose **Start**, then in the text box type `gpedit`.
![GPEdit desktop app search result.](images/autoenrollment-gpedit.png)
2. Under **Best match**, click **Edit group policy** to launch it.
2. Under **Best match**, select **Edit group policy** to launch it.
3. In **Local Computer Policy**, click **Administrative Templates** > **Windows Components** > **MDM**.
3. In **Local Computer Policy**, select **Administrative Templates** > **Windows Components** > **MDM**.
:::image type="content" alt-text="MDM policies." source="images/autoenrollment-mdm-policies.png" lightbox="images/autoenrollment-mdm-policies.png":::
4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the Selected Credential Type to use.
4. Double-click **Enable automatic MDM enrollment using default Azure AD credentials** (previously called **Auto MDM Enrollment with AAD Token** in Windows 10, version 1709). For ADMX files in Windows 10, version 1903 and later, select **User Credential** as the **Selected Credential Type to use**.
:::image type="content" alt-text="MDM autoenrollment policy." source="images/autoenrollment-policy.png" lightbox="images/autoenrollment-policy.png":::
5. Click **Enable**, and select **User Credential** from the dropdown **Select Credential Type to Use**, then click **OK**.
5. Select **Enable**, select **User Credential** from the dropdown **Select Credential Type to Use**, then select **OK**.
> [!NOTE]
> In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later.
>
> The default behavior for older releases is to revert to **User Credential**.
> **Device Credential** is only supported for Microsoft Intune enrollment in scenarios with Co-management or Azure Virtual Desktop.
> In Windows 10, version 1903, the MDM.admx file was updated to include an option to select which credential is used to enroll the device. **Device Credential** is a new option that will only have an effect on clients that have installed Windows 10, version 1903 or later. The default behavior for older releases is to revert to **User Credential**.
> **Device Credential** is only supported for Microsoft Intune enrollment in scenarios with Co-management or Azure Virtual Desktop because the Intune subscription is user centric.
When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called " Schedule created by enrollment client for automatically enrolling in MDM from AAD."
When a group policy refresh occurs on the client, a task is created and scheduled to run every 5 minutes for the duration of one day. The task is called "Schedule created by enrollment client for automatically enrolling in MDM from AAD."
To see the scheduled task, launch the [Task Scheduler app](#task-scheduler-app).
If two-factor authentication is required, you will be prompted to complete the process. Here is an example screenshot.
If two-factor authentication is required, you'll be prompted to complete the process. Here is an example screenshot.
![Two-factor authentication notification.](images/autoenrollment-2-factor-auth.png)
@ -141,33 +138,33 @@ Requirements:
> You can avoid this behavior by using Conditional Access Policies in Azure AD.
Learn more by reading [What is Conditional Access?](/azure/active-directory/conditional-access/overview).
6. To verify successful enrollment to MDM , click **Start > Settings > Accounts > Access work or school**, then select your domain account.
6. To verify successful enrollment to MDM, go to **Start** > **Settings** > **Accounts** > **Access work or school**, then select your domain account.
7. Click **Info** to see the MDM enrollment information.
7. Select **Info** to see the MDM enrollment information.
![Work School Settings.](images/autoenrollment-settings-work-school.png)
If you do not see the **Info** button or the enrollment information, it is possible that the enrollment failed. Check the status in [Task Scheduler app](#task-scheduler-app).
If you do not see the **Info** button or the enrollment information, enrollment might have failed. Check the status in [Task Scheduler app](#task-scheduler-app).
### Task Scheduler app
1. Click **Start**, then in the text box type **task scheduler**.
1. Select **Start**, then in the text box type `task scheduler`.
![Task Scheduler search result.](images/autoenrollment-task-schedulerapp.png)
2. Under **Best match**, click **Task Scheduler** to launch it.
2. Under **Best match**, select **Task Scheduler** to launch it.
3. In **Task Scheduler Library**, open **Microsoft > Windows** , then click **EnterpriseMgmt**.
3. In **Task Scheduler Library**, open **Microsoft > Windows** , then select **EnterpriseMgmt**.
:::image type="content" alt-text="Auto-enrollment scheduled task." source="images/autoenrollment-scheduled-task.png" lightbox="images/autoenrollment-scheduled-task.png":::
To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED). You can see the logs in the **History** tab.
To see the result of the task, move the scroll bar to the right to see the **Last Run Result**. Note that **0x80180026** is a failure message (`MENROLL\_E_DEVICE\_MANAGEMENT_BLOCKED`). You can see the logs in the **History** tab.
If the device enrollment is blocked, your IT admin may have enabled the **Disable MDM Enrollment** policy.
If the device enrollment is blocked, your IT admin might have enabled the **Disable MDM Enrollment** policy.
> [!NOTE]
> The GPEdit console does not reflect the status of policies set by your IT admin on your device. It is only used by the user to set policies.
> The GPEdit console does not reflect the status of policies set by your IT admin on your device. GPEdit is only used by the user to set policies.
## Configure the auto-enrollment for a group of devices
@ -178,7 +175,7 @@ Requirements:
- Ensure that PCs belong to same computer group.
> [!IMPORTANT]
> If you do not see the policy, it may be because you don't have the ADMX for Windows 10, version 1803, version 1809, or version 1903 installed. To fix the issue, use the following procedures. Note that the latest MDM.admx is backwards compatible.
> If you do not see the policy, you might not have the ADMX for Windows 10, version 1803, version 1809, or version 1903 installed. To fix the issue, use the following procedures. Note that the latest MDM.admx is backwards compatible.
1. Download:
@ -219,9 +216,9 @@ Requirements:
- 21H2 --> **C:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2021 Update (21H2)**
4. Rename the extracted Policy Definitions folder to **PolicyDefinitions**.
4. Rename the extracted Policy Definitions folder to `PolicyDefinitions`.
5. Copy PolicyDefinitions folder to **\\SYSVOL\contoso.com\policies\PolicyDefinitions**.
5. Copy the PolicyDefinitions folder to `\\SYSVOL\contoso.com\policies\PolicyDefinitions`.
If this folder does not exist, then be aware that you will be switching to a [central policy store](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for your entire domain.
@ -238,12 +235,14 @@ This procedure will work for any future version as well.
4. Filter using Security Groups.
## Troubleshoot auto-enrollment of devices
Investigate the log file if you have issues even after performing all the mandatory verification steps. The first log file to investigate is the event log on the target Windows 10 device.
To collect Event Viewer logs:
1. Open Event Viewer.
2. Navigate to **Applications and Services Logs > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostic-Provider > Admin**.
2. Navigate to **Applications and Services Logs** > **Microsoft** > **Windows** > **DeviceManagement-Enterprise-Diagnostic-Provider** > **Admin**.
> [!Tip]
> For guidance on how to collect event logs for Intune, see [Collect MDM Event Viewer Log YouTube video](https://www.youtube.com/watch?v=U_oCe2RmQEc).
@ -260,18 +259,17 @@ To collect Event Viewer logs:
To troubleshoot, check the error code that appears in the event. See [Troubleshooting Windows device enrollment problems in Microsoft Intune](/troubleshoot/mem/intune/troubleshoot-windows-enrollment-errors) for more information.
- The auto-enrollment did not trigger at all. In this case, you will not find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described in the following section.
- The auto-enrollment did not initiate at all. In this case, you will not find either event ID 75 or event ID 76. To know the reason, you must understand the internal mechanisms happening on the device as described in the following section.
The auto-enrollment process is triggered by a task (**Microsoft > Windows > EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration > Policies > Administrative Templates > Windows Components > MDM**) is successfully deployed to the target machine as shown in the following screenshot:
The auto-enrollment process is triggered by a task (**Microsoft** > **Windows** > **EnterpriseMgmt**) within the task-scheduler. This task appears if the *Enable automatic MDM enrollment using default Azure AD credentials* group policy (**Computer Configuration** > **Policies** > **Administrative Templates** > **Windows Components** > **MDM**) is successfully deployed to the target machine as shown in the following screenshot:
:::image type="content" alt-text="Task scheduler." source="images/auto-enrollment-task-scheduler.png" lightbox="images/auto-enrollment-task-scheduler.png":::
> [!Note]
> This task isn't visible to standard users - run Scheduled Tasks with administrative credentials to find the task.
> This task isn't visible to standard users, run Scheduled Tasks with administrative credentials to find the task.
This task runs every 5 minutes for the duration of 1 day. To confirm if the task succeeded, check the task scheduler event logs:
**Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational**.
Look for an entry where the task scheduler created by enrollment client for automatically enrolling in MDM from AAD is triggered by event ID 107.
This task runs every 5 minutes for the duration of one day. To confirm if the task succeeded, check the task scheduler event logs:
**Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational**. Look for an entry where the task scheduler created by enrollment client for automatically enrolling in MDM from AAD is triggered by event ID 107.
:::image type="content" alt-text="Event ID 107." source="images/auto-enrollment-event-id-107.png" lightbox="images/auto-enrollment-event-id-107.png":::
@ -279,14 +277,14 @@ To collect Event Viewer logs:
:::image type="content" alt-text="Event ID 102." source="images/auto-enrollment-event-id-102.png" lightbox="images/auto-enrollment-event-id-102.png":::
Note that the task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. This means that the task scheduler log is only useful to confirm if the auto-enrollment task is triggered or not. It does not indicate the success or failure of auto-enrollment.
Note that the task scheduler log displays event ID 102 (task completed) regardless of the auto-enrollment success or failure. The task scheduler log is only useful to confirm if the auto-enrollment task is initiated or not. It does not indicate the success or failure of auto-enrollment.
If you cannot see from the log that task Schedule created by enrollment client for automatically enrolling in MDM from AAD is initiated, there is possibly issue with the group policy. Immediately run the command `gpupdate /force` in command prompt to get the GPO applied. If this still does not help, further troubleshooting on the Active Directory is required.
One frequently seen error is related to some outdated enrollment entries in the registry on the target client device (**HKLM > Software > Microsoft > Enrollments**). If a device has been enrolled (can be any MDM solution and not only Intune), some enrollment information added into the registry is seen:
If you cannot see from the log that task Schedule created by enrollment client for automatically enrolling in MDM from AAD is initiated, there might be an issue with Group Policy. Immediately run the command `gpupdate /force` in command prompt to get the Group Policy Object applied. If you still have an issue, further troubleshooting on the Active Directory is required.
One frequently seen error is related to some outdated enrollment entries in the registry on the target client device (**HKLM > Software > Microsoft > Enrollments**). If a device has been enrolled (in any MDM solution and not only Intune), some enrollment information added into the registry is seen:
:::image type="content" alt-text="Outdated enrollment entries." source="images/auto-enrollment-outdated-enrollment-entries.png" lightbox="images/auto-enrollment-outdated-enrollment-entries.png":::
By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs > Microsoft > Windows > Task Scheduler > Operational** event log file under event ID 7016.
By default, these entries are removed when the device is un-enrolled, but occasionally the registry key remains even after un-enrollment. In this case, `gpupdate /force` fails to initiate the auto-enrollment task and error code 2149056522 is displayed in the **Applications and Services Logs** > **Microsoft** > **Windows** > **Task Scheduler** > **Operational** event log file under event ID 7016.
A resolution to this issue is to remove the registry key manually. If you do not know which registry key to remove, go for the key which displays most entries as the screenshot above. All other keys will display fewer entries as shown in the following screenshot:

56
windows/security/threat-protection/windows-defender-application-control/AppIdTagging/debugging-operational-guide-appid-tagging-policies.md Normal file
View File

@ -0,0 +1,56 @@
---
title: Testing and Debugging AppId Tagging Policies
description: Testing and Debugging AppId Tagging Policies to ensure your policies are deployed successfully.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jgeurten
ms.reviewer: jsuther1974
ms.author: dansimp
manager: dansimp
ms.date: 04/29/2022
ms.technology: windows-sec
---
# Testing and Debugging AppId Tagging Policies
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
After deployment of the WDAC AppId Tagging policy, WDAC will log a 3099 policy deployed event in the [Event Viewer logs](../event-id-explanations.md). You first should ensure that the policy has been successfully deployed onto the system by verifying the presence of the 3099 event.
## Verifying Tags on Running Processes
After verifying the policy has been deployed, the next step is to verify that the application processes you expect to pass the AppId Tagging policy have your tag set. Note that processes running at the time of policy deployment will need to be restarted since WDAC can only tag processes created after the policy has been deployed.
1. Download and Install the Windows Debugger
[Microsoft's WinDbg Preview application](https://www.microsoft.com/store/productId/9PGJGD53TN86) can be downloaded from the Store and used to verify tags on running processes.
2. Get the Process ID (PID) of the process under validation
Using Task Manager, or an equivalent process monitoring tool, locate the PID of the process you wish to inspect. In the example below, we've located the PID for the running process for Microsoft Edge to be 2260. The PID will be used in the next step.
![Using Task Manager to locate the process ID - PID.](../images/appid-pid-task-mgr.png)
3. Use WinDbg to inspect the process
After opening WinDbg. select File followed by `Attach to Process`, and select the process with the PID identified in the step prior. Finally, select `Attach` to connect to the process.
![Attach to the process using WinDbg.](../images/appid-pid-windbg.png)
Lastly, in the textbox, type `!token` and then press the Enter key to dump the security attributes on the process, including the _POLICYAPPID://_ followed by the key you set in the policy, and its corresponding value in the Value[0] field.
![Dump the security attributes on the process using WinDbg.](../images/appid-pid-windbg-token.png)

60
windows/security/threat-protection/windows-defender-application-control/AppIdTagging/deploy-appid-tagging-policies.md Normal file
View File

@ -0,0 +1,60 @@
---
title: Deploying Windows Defender Application Control AppId Tagging policies (Windows)
description: How to deploy your WDAC AppId Tagging policies locally and globally within your managed environment
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jgeurten
ms.reviewer: jsuther1974
ms.author: dansimp
manager: dansimp
ms.date: 04/29/2022
ms.technology: windows-sec
---
# Deploying Windows Defender Application Control AppId Tagging policies (Windows)
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
Similar to WDAC Application Control policies, WDAC AppId Tagging policies can be deployed locally and to your managed endpoints several ways. Once you've created your AppId Tagging policy, use one of the following methods to deploy:
1. [Deploy AppId Tagging Policies with MDM](#deploy-appid-tagging-policies-with-mdm)
1. [Deploy policies with MEMCM](#deploy-appid-tagging-policies-with-memcm)
1. [Deploy policies using scripting](#deploy-appid-tagging-policies-via-scripting)
1. [Deploy using the ApplicationControl CSP](#deploying-policies-via-the-applicationcontrol-csp)
## Deploy AppId Tagging Policies with MDM
Custom AppId Tagging policies can be deployed to endpoints using [the OMA-URI feature in MDM](../deploy-windows-defender-application-control-policies-using-intune.md#deploy-wdac-policies-with-custom-oma-uri).
## Deploy AppId Tagging Policies with MEMCM
Custom AppId Tagging policies can deployed via MEMCM using the [deployment task sequences](/deployment/deploy-windows-defender-application-control-policies-with-memcm.md#deploy-custom-wdac-policies-using-packagesprograms-or-task-sequences), policies can be deployed to your managed endpoints and users.
### Deploy AppId Tagging Policies via Scripting
Scripting hosts can be used to deploy AppId Tagging policies as well. This approach is often best suited for local deployment, but works for deployment to managed endpoints and users too. The [Deploy WDAC policies using script article](/deployment/deploy-wdac-policies-with-script.md) describes how to deploy WDAC AppId Tagging policies via scripting. Only the method for deploying to version 1903 and above is applicable for AppId Tagging policies.
### Deploying policies via the ApplicationControl CSP
Multiple WDAC policies can be managed from an MDM server through ApplicationControl configuration service provider (CSP). The CSP also provides support for rebootless policy deployment.
However, when policies are unenrolled from an MDM server, the CSP will attempt to remove every policy from devices, not just the policies added by the CSP. The reason for this is that the ApplicationControl CSP doesn't track enrollment sources for individual policies, even though it will query all policies on a device, regardless if they were deployed by the CSP.
For more information, see [ApplicationControl CSP](/windows/client-management/mdm/applicationcontrol-csp) to deploy multiple policies, and optionally use MEM Intune's Custom OMA-URI capability.
> [!NOTE]
> WMI and GP do not currently support multiple policies. Instead, customers who can't directly access the MDM stack should use the [ApplicationControl CSP via the MDM Bridge WMI Provider](/windows/client-management/mdm/applicationcontrol-csp#powershell-and-wmi-bridge-usage-guidance) to manage Multiple Policy Format WDAC policies.

119
windows/security/threat-protection/windows-defender-application-control/AppIdTagging/design-create-appid-tagging-policies.md Normal file
View File

@ -0,0 +1,119 @@
---
title: Create your Windows Defender Application Control AppId Tagging Policies
description: Create your Windows Defender Application Control AppId tagging policies for Windows devices.
keywords: security, malware
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jgeurten
ms.reviewer: jsuther1974
ms.author: dansimp
manager: dansimp
ms.date: 04/29/2022
ms.technology: windows-sec
---
# Creating your WDAC AppId Tagging Policies
**Applies to:**
- Windows 10
- Windows 11
- Windows Server 2016 and above
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
## Create the policy using the WDAC Wizard
You can use the WDAC Wizard and the PowerShell commands to create an application control policy and convert it to an AppIdTagging policy. The WDAC Wizard is available for download at the [WDAC Wizard Installer site](https://aka.ms/wdacwizard). These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md).
1. Create a new base policy using the templates:
Start with the Policy Creator task and select Multiple Policy Format and Base Policy. Select the Base Template to use for the policy. The example below shows beginning with the [Default Windows Mode](../wdac-wizard-create-base-policy.md#template-base-policies) template and build on top of these rules.
![Configuring the policy base and template.](../images/appid-wdac-wizard-1.png)
2. Set the following rule-options using the Wizard toggles:
![Configuring the policy rule-options.](../images/appid-wdac-wizard-2.png)
3. Create custom rules:
Selecting the `+ Custom Rules` button will open the Custom Rules panel. The Wizard supports five types of file rules:
- Publisher rules: Create a rule based off the signing certificate hierarchy. Additionally, the original filename and version can be combined with the signing certificate for added security.
- Path rules: Create a rule based off the path to a file or a parent folder path. Path rules support wildcards.
- File attribute rules: Create a rule based off a file's immutable properties like the original filename, file description, product name or internal name.
- Package app name rules: Create a rule based off the package family name of an appx/msix.
- Hash rules: Create a rule based off the PE Authenticode hash of a file.
For more information on creating new policy file rules, see the guidelines provided in the [creating policy file rules section](../wdac-wizard-create-base-policy.md#creating-custom-file-rules).
4. Convert to AppId Tagging Policy:
After the Wizard builds the policy file, open the file in a text editor and remove the entire "Value=131" SigningScenario text block. The only remaining signing scenario should be "Value=12" which is the usermode application section. Next, open PowerShell in an elevated prompt and run the following command. Replace the AppIdTagging Key-Value pair for your scenario:
```powershell
Set-CIPolicyIdInfo -ResetPolicyID -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
The policyID GUID will be returned by PowerShell if successful.
## Create the policy using PowerShell
Using this method, you'll create an AppId Tagging policy directly using the WDAC PowerShell commands. These PowerShell commands are only available on the supported platforms listed in [AppId Tagging Guide](./windows-defender-application-control-appid-tagging-guide.md). In an elevate PowerShell instance:
1. Create an AppId rule for the policy based on a combination of the signing certificate chain and version of the application. In the example below, the level has been set to SignedVersion. Any of the [WDAC File Rule Levels](../select-types-of-rules-to-create.md#table-2-windows-defender-application-control-policy---file-rule-levels) can be used in AppId rules:
```powershell
$rule = New-CiPolicyRule -Level SignedVersion -DriverFilePath <path_to_application>
```
2. Create the AppId Tagging Policy. Replace the AppIdTagging Key-Value pair for your scenario:
```powershell
New-CIPolicy -rules $rule -FilePath .\AppIdPolicy.xml -AppIdTaggingPolicy -AppIdTaggingKey "MyKey" -AppIdTaggingValue "MyValue"
```
3. Set the rule-options for the policy:
```powershell
Set-RuleOption -Option 0 .\AppIdPolicy.xml # Usermode Code Integrity (UMCI)
Set-RuleOption -Option 16 .\AppIdPolicy.xml # Refresh Policy no Reboot
Set-RuleOption -Option 18 .\AppIdPolicy.xml # (Optional) Disable FilePath Rule Protection
```
If you're using filepath rules, you'll likely want to set option 18. Otherwise, there's no need.
4. Set the name and ID on the policy, which is helpful for future debugging:
```powershell
Set-CIPolicyIdInfo -ResetPolicyId -PolicyName "MyPolicyName" -PolicyId "MyPolicyId"" -AppIdTaggingPolicy -FilePath ".\AppIdPolicy.xml"
```
The policyID GUID will be returned by PowerShell if successful.
## Deploy for Local Testing
After creating your AppId Tagging policy in the above steps, you can deploy the policy to your local machine for testing before broadly deploying the policy to your endpoints:
1. Depending on your deployment method, convert the xml to binary:
```powershell
Convertfrom-CIPolicy .\policy.xml ".\{PolicyIDGUID}.cip"
```
2. Optionally, deploy it for local testing:
```powershell
copy ".\{Policy ID}.cip" c:\windows\system32\codeintegrity\CiPolicies\Active\
./RefreshPolicy.exe
```
RefreshPolicy.exe is available for download from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=102925).
## Next Steps
For more information on debugging and broad deployment of the AppId Tagging policy, see [Debugging AppId policies](./debugging-operational-guide-appid-tagging-policies.md) and [Deploying AppId policies](deploy-appid-tagging-policies.md).

53
windows/security/threat-protection/windows-defender-application-control/AppIdTagging/windows-defender-application-control-appid-tagging-guide.md Normal file
View File

@ -0,0 +1,53 @@
---
title: Designing, creating, managing and troubleshooting Windows Defender Application Control AppId Tagging policies (Windows)
description: How to design, create, manage and troubleshoot your WDAC AppId Tagging policies
keywords: security, malware, firewall
ms.assetid: 8d6e0474-c475-411b-b095-1c61adb2bdbb
ms.prod: m365-security
ms.mktglfcycl: deploy
ms.sitesec: library
ms.pagetype: security
ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: jgeurten
ms.reviewer: jsuther1974
ms.author: dansimp
manager: dansimp
ms.date: 04/27/2022
ms.technology: windows-sec
---
# WDAC Application ID (AppId) Tagging guide
**Applies to**
- Windows 10
- Windows 11
- Windows Server 2022 and above
> [!NOTE]
> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [Windows Defender Application Control feature availability](../feature-availability.md).
## AppId Tagging Feature Overview
The Application ID (AppId) Tagging Policy feature, while based off WDAC, does not control whether applications will run. AppId Tagging policies can be used to mark the processes of the running application with a customizable tag defined in the policy. Application processes that pass the AppId policy will receive the tag while failing applications won't.
## AppId Tagging Feature Availability
The WDAC AppId Tagging feature is available on the following versions of the Windows platform:
Client:
- Windows 10 20H1, 20H2 and 21H1 versions only
- Windows 11
Server:
- Windows Server 2022
## In this section
| Topic | Description |
| - | - |
| [Designing and Creating AppId Policies](design-create-appid-tagging-policies.md) | This topic covers how to design and create AppId Tagging policies. |
| [Deploying AppId Policies](deploy-appid-tagging-policies.md) | This topic covers how to deploy AppId Tagging policies. |
| [Debugging AppId Policies](debugging-operational-guide-appid-tagging-policies.md) | This topic covers how to debug and view events from AppId Tagging policies. |

15
windows/security/threat-protection/windows-defender-application-control/TOC.yml
View File

@ -46,9 +46,9 @@
- name: Policy creation for common WDAC usage scenarios
href: types-of-devices.md
items:
- name: Create a WDAC policy for lightly-managed devices
- name: Create a WDAC policy for lightly managed devices
href: create-wdac-policy-for-lightly-managed-devices.md
- name: Create a WDAC policy for fully-managed devices
- name: Create a WDAC policy for fully managed devices
href: create-wdac-policy-for-fully-managed-devices.md
- name: Create a WDAC policy for fixed-workload devices
href: create-initial-default-policy.md
@ -101,7 +101,7 @@
href: disable-windows-defender-application-control-policies.md
- name: LOB Win32 Apps on S Mode
href: LOB-win32-apps-on-s.md
- name: Windows Defender Application Control operational guide
- name: WDAC operational guide
href: windows-defender-application-control-operational-guide.md
items:
- name: Understanding Application Control event tags
@ -114,6 +114,15 @@
href: operations/known-issues.md
- name: Managed installer and ISG technical reference and troubleshooting guide
href: configure-wdac-managed-installer.md
- name: WDAC AppId Tagging guide
href: AppIdTagging/windows-defender-application-control-appid-tagging-guide.md
items:
- name: Creating AppId Tagging Policies
href: AppIdTagging/design-create-appid-tagging-policies.md
- name: Deploying AppId Tagging Policies
href: AppIdTagging/deploy-appid-tagging-policies.md
- name: Testing and Debugging AppId Tagging Policies
href: AppIdTagging/debugging-operational-guide-appid-tagging-policies.md
- name: AppLocker
href: applocker\applocker-overview.md
items:

48
windows/security/threat-protection/windows-defender-application-control/event-id-explanations.md
View File

@ -14,7 +14,7 @@ author: jsuther1974
ms.reviewer: jogeurte
ms.author: dansimp
manager: dansimp
ms.date: 02/01/2022
ms.date: 04/30/2022
ms.technology: windows-sec
---
@ -39,7 +39,7 @@ A Windows Defender Application Control (WDAC) policy logs events locally in Wind
| 3076 | This event is the main WDAC block event for audit mode policies. It indicates that the file would have been blocked if the WDAC policy was enforced. |
| 3077 | This event is the main WDAC block event for enforced policies. It indicates that the file did not pass your WDAC policy and was blocked. |
| 3089 | This event contains signature information for files that were blocked or would have been blocked by WDAC. One 3089 event is created for each signature of a file. The event shows the total number of signatures found and an index value to identify the current signature. Unsigned files produce a single 3089 event with TotalSignatureCount 0. 3089 events are correlated with 3004, 3033, 3034, 3076 and 3077 events. You can match the events using the "Correlation ActivityID" found in the "System" portion of the event. |
| 3099 | Indicates that a policy has been loaded. This event also includes information about the policy options that were specified by the policy. Refer to the |
| 3099 | Indicates that a policy has been loaded. This event also includes information about the WDAC policy options that were specified by the WDAC policy. |
## WDAC events found in the Microsoft Windows AppLocker MSI and Script log
@ -57,7 +57,7 @@ Events 3090, 3091 and 3092 prove helpful diagnostic information when the ISG or
| Event ID | Explanation |
|--------|---------|
| 3090 | *Optional* This event indicates that a file was allowed to run based purely on ISG or managed installer. |
| 3091 | This event indicates that a file did not have ISG or managed installer authorization and the policy is in audit mode. |
| 3091 | This event indicates that a file did not have ISG or managed installer authorization and the WDAC policy is in audit mode. |
| 3092 | This event is the enforcement mode equivalent of 3091. |
The above events are reported per active policy on the system, so you may see multiple events for the same file.
@ -72,8 +72,8 @@ The following information is found in the details for 3090, 3091, and 3092 event
| PassesManagedInstaller | Indicates whether the file originated from a MI |
| SmartlockerEnabled | Indicates whether the specified policy enables ISG trust |
| PassesSmartlocker | Indicates whether the file had positive reputation according to the ISG |
| AuditEnabled | True if the policy is in audit mode, otherwise it is in enforce mode |
| PolicyName | The name of the policy to which the event applies |
| AuditEnabled | True if the WDAC policy is in audit mode, otherwise it is in enforce mode |
| PolicyName | The name of the WDAC policy to which the event applies |
### Enabling ISG and MI diagnostic events
@ -149,28 +149,38 @@ A list of other relevant event IDs and their corresponding description.
| 3023 | The driver file under validation did not meet the requirements to pass the application control policy. |
| 3024 | Windows application control was unable to refresh the boot catalog file. |
| 3026 | The catalog loaded is signed by a signing certificate that has been revoked by Microsoft and/or the certificate issuing authority. |
| 3032 | The file under validation is revoked by the system or the file has a signature that has been revoked.
| 3033 | The file under validation did not meet the requirements to pass the application control policy. |
| 3034 | The file under validation would not meet the requirements to pass the application control policy if the policy was enforced. The file was allowed since the policy is in audit mode. |
| 3034 | The file under validation would not meet the requirements to pass the application control policy if the WDAC policy was enforced. The file was allowed since the WDAC policy is in audit mode. |
| 3036 | The signed file under validation is signed by a code signing certificate that has been revoked by Microsoft or the certificate issuing authority. |
| 3064 | If the policy was enforced, a user mode DLL under validation would not meet the requirements to pass the application control policy. The DLL was allowed since the policy is in audit mode. |
| 3065 | [Ignored] If the policy was enforced, a user mode DLL under validation would not meet the requirements to pass the application control policy. |
| 3064 | If the WDAC policy was enforced, a user mode DLL under validation would not meet the requirements to pass the application control policy. The DLL was allowed since the WDAC policy is in audit mode. |
| 3065 | If the WDAC policy was enforced, a user mode DLL under validation would not meet the requirements to pass the application control policy. |
| 3074 | Page hash failure while hypervisor-protected code integrity was enabled. |
| 3075 | This event monitors the performance of the Code Integrity policy check a file. |
| 3075 | This event measures the performance of the WDAC policy check during file validation. |
| 3076 | This event is the main WDAC block event for audit mode policies. It indicates that the file would have been blocked if the WDAC policy was enforced. |
| 3077 | This event is the main WDAC block event for enforced policies. It indicates that the file did not pass your WDAC policy and was blocked. |
| 3079 | The file under validation did not meet the requirements to pass the application control policy. |
| 3080 | If the policy was in enforced mode, the file under validation would not have met the requirements to pass the application control policy. |
| 3080 | If the WDAC policy was in enforced mode, the file under validation would not have met the requirements to pass the application control policy. |
| 3081 | The file under validation did not meet the requirements to pass the application control policy. |
| 3082 | If the policy was in enforced mode, the non-WHQL driver would have been denied by the policy. |
| 3084 | Code Integrity will enforce the WHQL Required policy setting on this session. |
| 3085 | Code Integrity will not enforce the WHQL Required policy setting on this session. |
| 3082 | If the WDAC policy was in enforced mode, the non-WHQL driver would have been denied by the WDAC policy. |
| 3084 | Code Integrity will enforce the WHQL driver signing requirements on this boot session. |
| 3085 | Code Integrity will not enforce the WHQL driver signing requirements on this boot session. |
| 3086 | The file under validation does not meet the signing requirements for an isolated user mode (IUM) process. |
| 3095 | This Code Integrity policy cannot be refreshed and must be rebooted instead. |
| 3097 | The Code Integrity policy cannot be refreshed. |
| 3089 | This event contains signature information for files that were blocked or would have been blocked by WDAC. One 3089 event is created for each signature of a file. |
| 3090 | *Optional* This event indicates that a file was allowed to run based purely on ISG or managed installer. |
| 3091 | This event indicates that a file did not have ISG or managed installer authorization and the WDAC policy is in audit mode. |
| 3092 | This event is the enforcement mode equivalent of 3091. |
| 3095 | The WDAC policy cannot be refreshed and must be rebooted instead. |
| 3096 | The WDAC policy was not refreshed since it is already up-to-date. |
| 3097 | The WDAC policy cannot be refreshed. |
| 3099 | Indicates that a policy has been loaded. This event also includes information about the WDAC policy options that were specified by the WDAC policy. |
| 3100 | The application control policy was refreshed but was unsuccessfully activated. Retry. |
| 3101 | Code Integrity started refreshing the policy. |
| 3102 | Code Integrity finished refreshing the policy. |
| 3103 | Code Integrity is ignoring the policy refresh. |
| 3101 | The system started refreshing the WDAC policy. |
| 3102 | The system finished refreshing the WDAC policy. |
| 3103 | The system is ignoring the WDAC policy refresh. |
| 3104 | The file under validation does not meet the signing requirements for a PPL (protected process light) process. |
| 3105 | Code Integrity is attempting to refresh the policy. |
| 3105 | The system is attempting to refresh the WDAC policy. |
| 3108 | Windows mode change event was successful. |
| 3110 | Windows mode change event was unsuccessful. |
| 3111 | The file under validation did not meet the hypervisor-protected code integrity (HVCI) policy. |
| 3112 | The file under validation is signed by a certificate that has been explicitly revoked by Windows. |

3
windows/security/threat-protection/windows-defender-application-control/feature-availability.md
View File

@ -11,7 +11,7 @@ ms.localizationpriority: medium
audience: ITPro
ms.collection: M365-security-compliance
author: denisebmsft
ms.reviewer: isbrahm
ms.reviewer: jgeurten
ms.author: deniseb
manager: dansimp
ms.date: 07/29/2021
@ -45,3 +45,4 @@ ms.technology: windows-sec
| COM object configurability | [Available on 1903+](./allow-com-object-registration-in-windows-defender-application-control-policy.md) | Not available |
| Packaged app rules | [Available on RS5+](./manage-packaged-apps-with-windows-defender-application-control.md) | Available on Windows 8+ |
| Enforceable file types | <ul><li>Driver files: .sys</li><li>Executable files: .exe and .com</li><li>DLLs: .dll and .ocx</li><li>Windows Installer files: .msi, .mst, and .msp</li><li>Scripts: .ps1, .vbs, and .js</li><li>Packaged apps and packaged app installers: .appx</li></ul>| <ul><li>Executable files: .exe and .com</li><li>[Optional] DLLs: .dll and .ocx</li><li>Windows Installer files: .msi, .mst, and .msp</li><li>Scripts: .ps1, .bat, .cmd, .vbs, and .js</li><li>Packaged apps and packaged app installers: .appx</li></ul>|
| Application ID (AppId) Tagging | [Available on 20H1+](./AppIdTagging/windows-defender-application-control-appid-tagging-guide.md) | Not available |

BIN
windows/security/threat-protection/windows-defender-application-control/images/appid-pid-task-mgr.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 115 KiB

BIN
windows/security/threat-protection/windows-defender-application-control/images/appid-pid-windbg-token.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 134 KiB

BIN
windows/security/threat-protection/windows-defender-application-control/images/appid-pid-windbg.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 148 KiB

BIN
windows/security/threat-protection/windows-defender-application-control/images/appid-wdac-wizard-1.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 259 KiB

BIN
windows/security/threat-protection/windows-defender-application-control/images/appid-wdac-wizard-2.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 70 KiB