From e72ed9d9f220d1167b5419aabce58651e28fcfb2 Mon Sep 17 00:00:00 2001 From: Liz Long <104389055+lizgt2000@users.noreply.github.com> Date: Wed, 18 Jan 2023 18:31:06 -0500 Subject: [PATCH 01/21] first draft --- .../mdm/diagnose-provisioning-packages.md | 60 +++++++++++++++++++ 1 file changed, 60 insertions(+) create mode 100644 windows/client-management/mdm/diagnose-provisioning-packages.md diff --git a/windows/client-management/mdm/diagnose-provisioning-packages.md b/windows/client-management/mdm/diagnose-provisioning-packages.md new file mode 100644 index 0000000000..f185f84356 --- /dev/null +++ b/windows/client-management/mdm/diagnose-provisioning-packages.md @@ -0,0 +1,60 @@ +--- +title: Diagnose Provisioning Packages +description: Diagnose general failures in provisioning. +ms.reviewer: +manager: aaroncz +ms.author: lizlong +ms.topic: article +ms.prod: windows-client +ms.technology: itpro-manage +author: lizgt2000 +ms.date: 01/18/2023 +ms.collection: highpri +--- + +# Diagnose Provisioning Packages + +## Unable to apply Power Settings +When applying certain provisioning packages containing power settings ([Configure power settings | Microsoft Learn](/windows-hardware/customize/power-settings/configure-power-settings?view=windows-11)) they require elevated permissions which are not applied when applying PPKGs after the initial setup as seen [Apply a provisioning package (Windows 10/11) - Configure Windows | Microsoft Learn](/windows/configuration/provisioning-packages/provisioning-apply-package#after-initial-setup). An error of STATUS_PRIVILEGE_NOT_HELD (HRESULT=0xc0000061) is given when applying these packages with the incorrect security context. + +Simply placing the PPKG into %WINDIR%/Provisioning/Packages and rebooting the machine will apply the packages with the correct security context (NT Authority\SYSTEM - [LocalSystem Account - Win32 apps | Microsoft Learn](/windows/win32/services/localsystem-account)) as stated in the note in [Configure power settings | Microsoft Learn](/windows-hardware/customize/power-settings/configure-power-settings?view=windows-11) + +## Unable to perform Bulk Enrollment in Azure AD +Provisioning packages allow enrollment into Azure AD as seen in [(Bulk join a Windows device to Azure AD and Microsoft Endpoint Manager using a provisioning package - Microsoft Community Hub)](https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400). A few issues can occur: + + + + +## Unable to apply a multivariant provisioning package +If creating a multivariant package [(Create a provisioning package with multivariant settings (Windows 10/11) - Configure Windows | Microsoft Learn)](/windows/configuration/provisioning-packages/provisioning-multivariant). It may be difficult to diagnose why a certain target did not get applied. There may be conditions improperly authored which, when applied to the target device may not be evaluated as expected. + + +Tooling has been included to surface these conditions in the event a certain target did not get applied. + +## Diagnosing general failures in provisioning +To help diagnose common problems, you can run the mdmdiagnosticstool and capture multivariant condition values, see [Diagnose MDM failures in Windows 10 - Windows Client Management | Microsoft Learn.](/windows/client-management/diagnose-mdm-failures-in-windows-10) + +## Diagnosing multivariant problems +When applying multivariant packages it may be difficult to see why a target was not applied. The MdmDiagnosticsTool [(Diagnose MDM failures in Windows 10 - Windows Client Management | Microsoft Learn)](/windows/client-management/diagnose-mdm-failures-in-windows-10) includes the multivariant condition values on the target system. + +(Zinc semester addition - Deliverable 41742231: [Hydra] [Tooling] Add MultiVariant handler values to MdmdiagnosticsTool diagnostics) which can be helpful when diagnosing why the PPKG was not applied in the target system. + +The MDMDiagReport.xml will contain the Multivariant Conditions in the report. Using powershell, we can get the values like so: +([XML](Get-Content MDMDiagReport.xml)).SelectNodes('//Multivariant') | Select -ExpandProperty Condition \ No newline at end of file From 2e35c04faa81b3539d1c80d2fa46df11d1c18dca Mon Sep 17 00:00:00 2001 From: Liz Long <104389055+lizgt2000@users.noreply.github.com> Date: Wed, 18 Jan 2023 19:03:40 -0500 Subject: [PATCH 02/21] draft provision --- .../client-management/mdm/diagnose-provisioning-packages.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/windows/client-management/mdm/diagnose-provisioning-packages.md b/windows/client-management/mdm/diagnose-provisioning-packages.md index f185f84356..bdae0a320d 100644 --- a/windows/client-management/mdm/diagnose-provisioning-packages.md +++ b/windows/client-management/mdm/diagnose-provisioning-packages.md @@ -15,7 +15,8 @@ ms.collection: highpri # Diagnose Provisioning Packages ## Unable to apply Power Settings @@ -51,7 +52,7 @@ To help diagnose common problems, you can run the mdmdiagnosticstool and capture When applying multivariant packages it may be difficult to see why a target was not applied. The MdmDiagnosticsTool [(Diagnose MDM failures in Windows 10 - Windows Client Management | Microsoft Learn)](/windows/client-management/diagnose-mdm-failures-in-windows-10) includes the multivariant condition values on the target system. (Zinc semester addition - Deliverable 41742231: [Hydra] [Tooling] Add MultiVariant handler values to MdmdiagnosticsTool diagnostics) which can be helpful when diagnosing why the PPKG was not applied in the target system. From 6a9d6d7f79e3eee80e21d73258cdd69c9ddf5d73 Mon Sep 17 00:00:00 2001 From: Liz Long <104389055+lizgt2000@users.noreply.github.com> Date: Thu, 19 Jan 2023 10:50:16 -0500 Subject: [PATCH 03/21] vinay review --- .../mdm/diagnose-provisioning-packages.md | 8 +------- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/windows/client-management/mdm/diagnose-provisioning-packages.md b/windows/client-management/mdm/diagnose-provisioning-packages.md index bdae0a320d..3450b93e86 100644 --- a/windows/client-management/mdm/diagnose-provisioning-packages.md +++ b/windows/client-management/mdm/diagnose-provisioning-packages.md @@ -13,21 +13,15 @@ ms.collection: highpri --- # Diagnose Provisioning Packages - ## Unable to apply Power Settings -When applying certain provisioning packages containing power settings ([Configure power settings | Microsoft Learn](/windows-hardware/customize/power-settings/configure-power-settings?view=windows-11)) they require elevated permissions which are not applied when applying PPKGs after the initial setup as seen [Apply a provisioning package (Windows 10/11) - Configure Windows | Microsoft Learn](/windows/configuration/provisioning-packages/provisioning-apply-package#after-initial-setup). An error of STATUS_PRIVILEGE_NOT_HELD (HRESULT=0xc0000061) is given when applying these packages with the incorrect security context. +When applying certain provisioning packages containing power settings ([Configure power settings | Microsoft Learn](/windows-hardware/customize/power-settings/configure-power-settings?view=windows-11)) they require elevated permissions which are not applied when applying PPKGs [after the initial setup](/windows/configuration/provisioning-packages/provisioning-apply-package#after-initial-setup). An error of STATUS_PRIVILEGE_NOT_HELD (HRESULT=0xc0000061) is given when applying these packages with the incorrect security context. Simply placing the PPKG into %WINDIR%/Provisioning/Packages and rebooting the machine will apply the packages with the correct security context (NT Authority\SYSTEM - [LocalSystem Account - Win32 apps | Microsoft Learn](/windows/win32/services/localsystem-account)) as stated in the note in [Configure power settings | Microsoft Learn](/windows-hardware/customize/power-settings/configure-power-settings?view=windows-11) ## Unable to perform Bulk Enrollment in Azure AD Provisioning packages allow enrollment into Azure AD as seen in [(Bulk join a Windows device to Azure AD and Microsoft Endpoint Manager using a provisioning package - Microsoft Community Hub)](https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400). A few issues can occur: - ## Unable to apply a multivariant provisioning package -If creating a multivariant package [(Create a provisioning package with multivariant settings (Windows 10/11) - Configure Windows | Microsoft Learn)](/windows/configuration/provisioning-packages/provisioning-multivariant). It may be difficult to diagnose why a certain target did not get applied. There may be conditions improperly authored which, when applied to the target device may not be evaluated as expected. +If creating a [multivariant package](../windows/configuration/provisioning-packages/provisioning-multivariant). It may be difficult to diagnose why a certain target did not get applied. There may be conditions improperly authored which when applied to the target device may not be evaluated as expected. - -## Unable to apply a multivariant provisioning package -If creating a [multivariant package](../windows/configuration/provisioning-packages/provisioning-multivariant). It may be difficult to diagnose why a certain target did not get applied. There may be conditions improperly authored which when applied to the target device may not be evaluated as expected. - - -Tooling has been included to surface these conditions in the event a certain target did not get applied. - -## Diagnosing general failures in provisioning -To help diagnose common problems, you can run the [MdmDiagnosticsTool](../windows/client-management/diagnose-mdm-failures-in-windows-10) and capture multivariant condition values. - -## Diagnosing multivariant problems -When applying multivariant packages it may be difficult to see why a target was not applied. The [MdmDiagnosticsTool](../windows/client-management/diagnose-mdm-failures-in-windows-10) includes the multivariant condition values on the target system. - -(Zinc semester addition - Deliverable 41742231: [Hydra] [Tooling] Add MultiVariant handler values to MdmdiagnosticsTool diagnostics) which can be helpful when diagnosing why the PPKG was not applied in the target system. - -The MDMDiagReport.xml will contain the Multivariant Conditions in the report. Using powershell, we can get the values like so: -([XML](Get-Content MDMDiagReport.xml)).SelectNodes('//Multivariant') | Select -ExpandProperty Condition \ No newline at end of file diff --git a/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md b/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md new file mode 100644 index 0000000000..55773531a2 --- /dev/null +++ b/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md @@ -0,0 +1,43 @@ +--- +title: Diagnose Provisioning Packages +description: Diagnose general failures in provisioning. +ms.reviewer: +manager: aaroncz +ms.author: lizlong +ms.topic: article +ms.prod: windows-client +ms.technology: itpro-manage +author: lizgt2000 +ms.date: 01/18/2023 +ms.collection: highpri +--- + +# Diagnose Provisioning Packages + +This article helps diagnose common issues with applying provisioning packages. You can use the [MdmDiagnosticsTool](/windows/client-management/diagnose-mdm-failures-in-windows-10) to diagnose general provisioning failures. + +## Unable to apply power settings + +When applying a provisioning package (PPKG) containing [power settings](/windows-hardware/customize/power-settings/update-power-settings), elevated permissions are required. Power settings applied using the user context after the [initial setup](/windows/configuration/provisioning-packages/provisioning-apply-package#after-initial-setup), results in the error `STATUS_PRIVILEGE_NOT_HELD (HRESULT=0xc0000061)` because an incorrect security context was used. + +To apply the power settings successfully with the [correct security context](/windows/win32/services/localsystem-account), place the PPKG in `%WINDIR%/Provisioning/Packages` directory, and reboot the device. For more information, see [Configure power settings](/windows-hardware/customize/power-settings/configure-power-settings). + +## Unable to perform bulk enrollment in Azure AD + +See [allow enrollment into Azure AD for provisioning packages](https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400). + + + +## Unable to apply a multivariant provisioning package + +When applying a [multivariant package](/windows/configuration/provisioning-packages/provisioning-multivariant), it may be difficult to diagnose why a certain target did not get applied. There may have been improperly authored conditions that did not evaluate as expected. + +To diagnose problems with multivariant packages, [MdmDiagnosticsTool](/windows/client-management/diagnose-mdm-failures-in-windows-10) (in Windows 11 version 22H2) includes multivariant condition values which can be helpful to determine why the PPKG was not applied. + +You can use the following PowerShell example to review the multivariant conditions in the `MDMDiagReport.xml` report: + +```powershell +([XML](Get-Content MDMDiagReport.xml)).SelectNodes('//Multivariant') | Select -ExpandProperty Condition +``` From b6e835f6b6320eaccfe5fc3235e3f8268792b3ed Mon Sep 17 00:00:00 2001 From: Vinay Pamnani <37223378+vinaypamnani-msft@users.noreply.github.com> Date: Wed, 25 Jan 2023 11:01:10 -0500 Subject: [PATCH 09/21] Update TOC.yml --- windows/configuration/TOC.yml | 2 ++ 1 file changed, 2 insertions(+) diff --git a/windows/configuration/TOC.yml b/windows/configuration/TOC.yml index 979f7648a6..b3887ade44 100644 --- a/windows/configuration/TOC.yml +++ b/windows/configuration/TOC.yml @@ -126,6 +126,8 @@ href: provisioning-packages/provisioning-multivariant.md - name: PowerShell cmdlets for provisioning Windows client (reference) href: provisioning-packages/provisioning-powershell.md + - name: Diagnose provisioning packages + href: provisioning-packages/diagnose-provisioning-packages.md - name: Windows Configuration Designer command-line interface (reference) href: provisioning-packages/provisioning-command-line.md From 5b17f1172a4f8b2f98e4dd0d1d9749e8a4db8075 Mon Sep 17 00:00:00 2001 From: Vinay Pamnani <37223378+vinaypamnani-msft@users.noreply.github.com> Date: Wed, 25 Jan 2023 11:26:20 -0500 Subject: [PATCH 10/21] Update diagnose-mdm-failures-in-windows-10.md --- .../client-management/diagnose-mdm-failures-in-windows-10.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/client-management/diagnose-mdm-failures-in-windows-10.md b/windows/client-management/diagnose-mdm-failures-in-windows-10.md index 67b61ceb3c..088c0df06a 100644 --- a/windows/client-management/diagnose-mdm-failures-in-windows-10.md +++ b/windows/client-management/diagnose-mdm-failures-in-windows-10.md @@ -46,9 +46,9 @@ The zip file will have logs according to the areas that were used in the command - DiagnosticLogCSP_Collector_Autopilot_*: Autopilot etls - DiagnosticLogCSP_Collector_DeviceProvisioning_*: Provisioning etls (Microsoft-Windows-Provisioning-Diagnostics-Provider) -- MDMDiagHtmlReport.html: Summary snapshot of MDM space configurations and policies. Includes, management url, MDM server device ID, certificates, policies. +- MDMDiagHtmlReport.html: Summary snapshot of MDM configurations and policies. Includes, management url, MDM server device ID, certificates, policies. - MdmDiagLogMetadata, json: mdmdiagnosticstool metadata file, contains command-line arguments used to run the tool -- MDMDiagReport.xml: contains a more detail view into the MDM space configurations, e.g enrollment variables +- MDMDiagReport.xml: contains a more detailed view into the MDM configurations, e.g enrollment variables, provisioning packages, multivariant conditions, etc. For more information about diagnosing provisioning packages, see [Diagnose provisioning packages](/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md). - MdmDiagReport_RegistryDump.reg: contains dumps from common MDM registry locations - MdmLogCollectorFootPrint.txt: mdmdiagnosticslog tool logs from running the command - *.evtx: Common event viewer logs microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx main one that contains MDM events. From b150241d06ea6d096be3b22c1f2c208dffe00383 Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Fri, 3 Mar 2023 09:47:27 -0800 Subject: [PATCH 11/21] updated whats new with baseline config update --- .../whats-new/windows-autopatch-whats-new-2023.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md index 3733426a2d..6cea21afbf 100644 --- a/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md +++ b/windows/deployment/windows-autopatch/whats-new/windows-autopatch-whats-new-2023.md @@ -1,7 +1,7 @@ --- title: What's new 2023 description: This article lists the 2023 feature releases and any corresponding Message center post numbers. -ms.date: 02/28/2023 +ms.date: 03/03/2023 ms.prod: windows-client ms.technology: itpro-updates ms.topic: whats-new @@ -37,6 +37,7 @@ Minor corrections such as typos, style, or formatting issues aren't listed. | Message center post number | Description | | ----- | ----- | +| [MC521882](https://admin.microsoft.com/adminportal/home#/MessageCenter) | February 2023 Windows Autopatch baseline configuration update | | [MC517330](https://admin.microsoft.com/adminportal/home#/MessageCenter) | Ability to opt out of Microsoft 365 App updates | | [MC517327](https://admin.microsoft.com/adminportal/home#/MessageCenter) | Planned service maintenance downtime for European Union (EU) Windows Autopatch customers enrolled before November 8, 2022 | From 86ae9d7fac8379938e89486187de7e3c22e3545f Mon Sep 17 00:00:00 2001 From: jsuther1974 Date: Fri, 3 Mar 2023 11:28:12 -0800 Subject: [PATCH 12/21] Update select-types-of-rules-to-create.md --- .../select-types-of-rules-to-create.md | 100 +++++++++++------- 1 file changed, 62 insertions(+), 38 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index 9672782041..30861c8e94 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -13,7 +13,7 @@ author: jgeurten ms.reviewer: jsuther1974 ms.author: vinpa manager: aaroncz -ms.date: 01/23/2023 +ms.date: 03/03/2023 ms.technology: itpro-security ms.topic: article --- @@ -27,21 +27,21 @@ ms.topic: article - 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). +> Some capabilities of Windows Defender Application Control are only available on specific Windows versions. Learn more about the [WDAC feature availability](feature-availability.md). Windows Defender Application Control (WDAC) can control what runs on Windows 10 and Windows 11, 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 is used to restrict devices to run only approved apps, while the operating system is hardened against kernel memory attacks using [hypervisor-protected code integrity (HVCI)](/windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control). +WDAC is used to restrict devices to run only approved apps, while the operating system is hardened against kernel memory attacks using [hypervisor-protected code integrity (HVCI)](/windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control). -## Windows Defender Application Control policy rules +## WDAC policy rules -To modify the policy rule options of an existing Windows Defender Application Control 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 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: `Set-RuleOption -FilePath -Option 0` - 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. + A policy created without the `-UserPEs` option has no rules for user mode code. If you enable UMCI (Option 0) for such a policy, all applications, including critical Windows user session code, are blocked. In audit mode, WDAC simply logs an event, but when enforced, all user mode code is 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: @@ -50,9 +50,9 @@ To modify the policy rule options of an existing Windows Defender Application Co You can set several rule options within a WDAC policy. Table 1 describes each rule option, and whether they have supplemental policies. However, option 5 isn't implemented as it's reserved for future work, and option 7 isn't supported. > [!NOTE] -> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new Windows Defender Application Control policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode. +> We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode. -### Table 1. Windows Defender Application Control policy - policy rule options +### Table 1. WDAC policy - policy rule options | Rule option | Description | Valid supplemental option | |------------ | ----------- | ----------- | @@ -60,49 +60,49 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru | **1 Enabled:Boot Menu Protection** | This option isn't currently supported. | No | | **2 Required:WHQL** | By default, legacy drivers that aren't 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. | No | | **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. | No | -| **4 Disabled:Flight Signing** | If enabled, WDAC policies won't trust flightroot-signed binaries. This option would be used by organizations that only want to run released binaries, not pre-release Windows builds. | No | +| **4 Disabled:Flight Signing** | If enabled, flightroot-signed binaries aren't trusted. This option is useful for organizations that only want to run released binaries, not pre-release Windows builds. | No | | **5 Enabled:Inherit Default Policy** | This option is reserved for future use and currently has no effect. | Yes | | **6 Enabled:Unsigned System Integrity Policy (Default)** | Allows the policy to remain unsigned. When this option is removed, the policy must be signed. The certificates that are trusted for future policy updates must be identified in the UpdatePolicySigners section. | Yes | | **7 Allowed:Debug Policy Augmented** | This option isn't currently supported. | Yes | | **8 Required:EV Signers** | This option isn't currently supported. | No | | **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. | No | -| **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. | No | +| **10 Enabled:Boot Audit on Failure** | Used when the WDAC policy is in enforcement mode. When a boot-critical driver fails during startup, the WDAC policy is placed in audit mode so that Windows loads. Administrators can validate the reason for the failure in the CodeIntegrity event log. | No | | **11 Disabled:Script Enforcement** | This option disables script enforcement options, covering PowerShell, Windows Based Script Host (wscript.exe), Windows Console Based Script Host (cscript.exe), HTA files run in Microsoft HTML Application Host (mshta.exe), and MSXML. For more information on script enforcement, see [Script enforcement with WDAC](/windows/security/threat-protection/windows-defender-application-control/design/script-enforcement).
NOTE: This option isn't supported on Windows Server 2016 and shouldn't be used on that operating system. | No | -| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies will also apply to Universal Windows applications. | No | +| **12 Required:Enforce Store Applications** | If this rule option is enabled, WDAC policies also apply to Universal Windows applications. | No | | **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](configure-authorized-apps-deployed-with-a-managed-installer.md) | Yes | | **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). | Yes | -| **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.| No | +| **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 causes WDAC to periodically revalidate the reputation for files previously authorized by the ISG.| No | | **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.| No | | **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. | No | | **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. | Yes | | **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. | No | | **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with expired and/or revoked certificates as "Unsigned binaries" for user-mode process/components, under enterprise signing scenarios. | No | -## Windows Defender Application Control file rule levels +## WDAC 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 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. +Each file rule level has advantages and disadvantages. Use Table 2 to select the appropriate protection level for your available administrative resources and WDAC deployment scenario. -### Table 2. Windows Defender Application Control policy - file rule levels +### Table 2. WDAC policy - file rule levels | Rule level | Description | |----------- | ----------- | | **Hash** | Specifies individual [Authenticode/PE image hash values](#more-information-about-hashes) for each discovered binary. This level is the most specific level, and requires more 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 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 it doesn't typically require a policy update when any binary is modified. | -| **FilePath** | Beginning with Windows 10 version 1903, this level allows binaries to run from specific file path locations. FilePath rules only apply to user mode binaries and can't be used to allow kernel mode drivers. More 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. FilePath rules only apply to user mode binaries and can't be used to allow kernel mode drivers. More information about FilePath level rules can be found later in this article. | | **SignedVersion** | This level combines the publisher rule with a version number. It allows anything to run from the specified publisher with a version at or above the specified version number. | | **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 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. When this level is used, 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 Windows Defender Application Control policy must be updated whenever these certificates change. | -| **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 doesn't validate anything beyond the certificates included in the provided signature (it doesn't go online or check local root stores). | +| **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. When this level is used, no policy update would be needed to run the new version of the application. However, leaf certificates typically have 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 level is typically one certificate below the root because the scan doesn't resolve the complete certificate chain via the local root stores or with an online check. | | **RootCertificate** | This level may produce an overly permissive policy and isn't recommended for most use cases. | -| **WHQL** | Trusts binaries if they've been validated and signed by WHQL. This level is primarily for kernel binaries. | +| **WHQL** | Only trusts binaries that have been submitted to Microsoft and signed by the Windows Hardware Qualification Lab (WHQL). This level 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 level is primarily for kernel binaries. | +| **WHQLFilePublisher** | This level combines the the "FileName" attribute of the signed file, plus "WHQLPublisher", plus a minimum version number. This level is primarily for kernel binaries. | > [!NOTE] -> When you create Windows Defender Application Control 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. +> 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. > [!NOTE] > @@ -120,65 +120,89 @@ Each file rule level has its benefit and disadvantage. Use Table 2 to select the 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 Windows Defender Application Control 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. With the help of the audit data, they update their WDAC policies to include any other software they want 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. With the help of the audit data, they update their WDAC policies to include any other software they want to run. Then they enable the WDAC policy in enforced mode for their servers. As part of normal operations, they'll 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 won't 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. ## File rule precedence order -Windows Defender Application Control has a built-in file rule conflict logic that translates to precedence order. It will first process all explicit deny rules it finds. Then, it will process all explicit allow rules. If no deny or allow rule exists, WDAC will check for [Managed Installer EA](deployment/deploy-wdac-policies-with-memcm.md). Lastly, if none of these sets exist, WDAC will fall back on [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md). +WDAC has a built-in file rule conflict logic that translates to precedence order. It first processes all explicit deny rules it finds. Then, it processes any explicit allow rules. If no deny or allow rule exists, WDAC checks for a [Managed Installer claim](deployment/deploy-wdac-policies-with-memcm.md) if allowed by the policy. Lastly, WDAC falls back to the [ISG](use-windows-defender-application-control-with-intelligent-security-graph.md) if allowed by the policy. > [!NOTE] -> For others to better understand the WDAC policies that have been deployed, we recommend maintaining separate ALLOW and DENY policies on Windows 10, version 1903 and later. +> To make it easier to reason over your WDAC policies, we recommend maintaining separate ALLOW and DENY policies on Windows 10, version 1903 and later. ## More information about filepath rules -Filepath rules don't provide the same security guarantees that explicit signer rules do, since they're 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. +Filepath rules don't provide the same security guarantees that explicit signer rules do, since they're 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 to remain admin-writeable only. You may want to avoid path rules for directories where standard users can modify ACLs on the folder. -By default, Windows Defender Application Control performs a user-writeability check at runtime that ensures that the current permissions on the specified filepath and its parent directories (recursively) don't allow standard users write access. +### User-writable filepaths -There's a defined list of SIDs that 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. +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) don't allow standard users write access. + +There's a defined list of SIDs that 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 earlier. WDAC's list of well-known admin SIDs are: 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 filepath rules are being generated 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 filepath rules are generated 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 aren't supported (ex. `C:\*\foo.exe`). Without a wildcard, the rule will allow only a specific file (ex. `C:\foo\bar.exe`). +### Using wildcards in WDAC filepath rules -You can also use the following macros when the exact volume may vary: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`. +The following wildcards can be used in WDAC filepath rules: + +| Wildcard character | Meaning | Supported operating systems | +|------------ | ----------- | ----------- | +| **`*`** | Matches zero or more characters. | Windows 11, Windows 10, and Windows Server 2022 | +| **`?`** | Matches a single character. | Windows 11 only | + +You can also use the following macros when the exact volume may vary: `%OSDRIVE%`, `%WINDIR%`, `%SYSTEM32%`. These macros can be used in combination with the wildcards above. > [!NOTE] -> When authoring WDAC policies with Microsoft Configuration Manager (MEMCM), you can instruct MEMCM to create rules for specified files and folders. These rules **aren't** WDAC filepath rules. Rather, MEMCM performs a one-time scan of the specified files and folders and builds rules for any binaries found in those locations at the time of that scan. File changes to those specified files and folders after that scan won't be allowed unless the MEMCM policy is reapplied. +> On Windows 11, you can use one or more wildcards anywhere within a filepath rule. +> +> On all other Windows and Windows Server versions, **only one** wildcard is allowed per path rule **and it must be at the beginning or end of a path rule**. + +#### Example filepath rules with wildcards + +| Examples | Description | Supported operating systems | +|------------ | ----------- | ----------- | +| **C:\\Windows\\\***
**D:\\EnterpriseApps\\MyApp\\\***
**%OSDRIVE%\\Windows\\\*** | Wildcards placed at the end of a path authorize all files in the immediate path and its subdirectories recursively. | Windows 11, Windows 10, and Windows Server 2022 | +| **\*\\bar.exe** | Wildcards placed at the beginning of a path allows the exact specified filename in any location. | Windows 11, Windows 10, and Windows Server 2022 | +| **C:\\\*\\CCMCACHE\\\*\\7z????-x64.exe**
**%OSDRIVE%\\\*\\CCMCACHE\\\*\\7z????-x64.exe** | Wildcards used in the middle of a path allows all files that match that pattern. Consider carefully all the possible matches, particularly if your policy disables the admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option. In this example both of these hypothetical paths would match:
*`C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe`*
*`C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe`* | Windows 11 only | + +Without a wildcard, the filepath rule allows only a specific file (ex. `C:\foo\bar.exe`). + +> [!NOTE] +> When authoring WDAC policies with Microsoft Configuration Manager (ConfigMgr), you can instruct ConfigMgr to create rules for specified files and folders. These rules **aren't** WDAC filepath rules. Rather, ConfigMgr performs a one-time scan of the specified files and folders and builds rules for any binaries found in those locations at the time of that scan. File changes to those specified files and folders after that scan won't be allowed unless the ConfigMgr policy is reapplied. > [!NOTE] > There is currently a bug where MSIs cannot be allow listed in file path rules. MSIs must be allow listed using other rule types, for example, publisher rules or file attribute rules. ## More information about hashes -WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more popular, but less secure, [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum and the Certificate Table and the Attribute Certificate Table. Therefore, the Authenticode hash of a file doesn't change when the file is re-signed or timestamped, or the digital signature is removed from the file. With the help of the Authenticode hash, WDAC provides added security and less management overhead so customers don't need to revise the policy hash rules when the digital signature on the file is updated. +WDAC uses the [Authenticode/PE image hash algorithm](https://download.microsoft.com/download/9/c/5/9c5b2167-8017-4bae-9fde-d599bac8184a/Authenticode_PE.docx) when calculating the hash of a file. Unlike the more commonly known [flat file hash](/powershell/module/microsoft.powershell.utility/get-filehash), the Authenticode hash calculation omits the file's checksum, the Certificate Table, and the Attribute Certificate Table. Therefore, the Authenticode hash of a file doesn't change when the file's signatures and timestamps are altered, or when a digital signature is removed from the file. With the help of the Authenticode hash, WDAC provides added security and less management overhead so customers don't need to revise the policy hash rules when the digital signature on the file is updated. The Authenticode/PE image hash can be calculated for digitally signed and unsigned files. ### Why does scan create four hash rules per XML file? -The PowerShell cmdlet will produce an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash. -During validation, CI will choose which hashes to calculate, depending on how the file is signed. For example, if the file is page-hash signed the entire file wouldn't get paged in to do a full sha256 authenticode, and we would just match using the first page hash. +The PowerShell cmdlet produces an Authenticode Sha1 Hash, Sha256 Hash, Sha1 Page Hash, Sha256 Page Hash. +During validation, WDAC selects which hashes are calculated based on how the file is signed and the scenario in which the file is used. For example, if the file is page-hash signed, WDAC validates each page of the file and avoids loading the entire file in memory to calculate the full sha256 authenticode hash. -In the cmdlets, rather than try to predict which hash CI will use, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This method is also resilient, if the signing status of the file changes and necessary for deny rules to ensure that changing/stripping the signature doesn't result in a different hash than what was in the policy being used by CI. +In the cmdlets, rather than try to predict which hash will be used, we pre-calculate and use the four hashes (sha1/sha2 authenticode, and sha1/sha2 of first page). This method is also resilient to changes in how the file is signed since your WDAC policy has more than one hash available for the file already. ### Why does scan create eight hash rules for certain XML files? -Separate rules are created for UMCI and KMCI. In some cases, files that are purely user-mode or purely kernel-mode may still generate both sets, since CI can't always precisely determine what is purely user vs. kernel mode, and errs on the side of caution. +Separate rules are created for UMCI and KMCI. If the cmdlets can't determine that a file will only run in user-mode or in the kernel, then rules are created for both signing scenarios out of an abundance of caution. If you know that a particular file will only load in either user-mode or kernel, then you can safely remove the extra rules. -## Windows Defender Application Control filename rules +## WDAC filename rules 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're 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 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 +### Table 3. WDAC policy - filename levels | Rule level | Description | |----------- | ----------- | From 1e033c17c3aa3bdf1f5316fd02af386d7e95845f Mon Sep 17 00:00:00 2001 From: jsuther1974 Date: Fri, 3 Mar 2023 11:40:25 -0800 Subject: [PATCH 13/21] Update select-types-of-rules-to-create.md --- .../select-types-of-rules-to-create.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index 30861c8e94..ca612437cd 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -52,7 +52,7 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru > [!NOTE] > We recommend that you use **Enabled:Audit Mode** initially because it allows you to test new WDAC policies before you enforce them. With audit mode, no application is blocked—instead the policy logs an event whenever an application outside the policy is started. To allow these applications, you can capture the policy information from the event log, and then merge that information into the existing policy. When the **Enabled:Audit Mode** is deleted, the policy runs in enforced mode. -### Table 1. WDAC policy - policy rule options +### Table 1. Windows Defender Application Control policy - policy rule options | Rule option | Description | Valid supplemental option | |------------ | ----------- | ----------- | @@ -78,13 +78,13 @@ You can set several rule options within a WDAC policy. Table 1 describes each ru | **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. | No | | **20 Enabled:Revoked Expired As Unsigned** | Use this option to treat binaries signed with expired and/or revoked certificates as "Unsigned binaries" for user-mode process/components, under enterprise signing scenarios. | No | -## WDAC file rule levels +## 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 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 advantages and disadvantages. Use Table 2 to select the appropriate protection level for your available administrative resources and WDAC deployment scenario. -### Table 2. WDAC policy - file rule levels +### Table 2. Windows Defender Application Control policy - file rule levels | Rule level | Description | |----------- | ----------- | @@ -196,13 +196,13 @@ In the cmdlets, rather than try to predict which hash will be used, we pre-calcu Separate rules are created for UMCI and KMCI. If the cmdlets can't determine that a file will only run in user-mode or in the kernel, then rules are created for both signing scenarios out of an abundance of caution. If you know that a particular file will only load in either user-mode or kernel, then you can safely remove the extra rules. -## WDAC filename rules +## Windows Defender Application Control filename rules 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're 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 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. WDAC policy - filename levels +### Table 3. Windows Defender Application Control policy - filename levels | Rule level | Description | |----------- | ----------- | From 4069b25df9c7774cd406136aedb25d75e9f756ff Mon Sep 17 00:00:00 2001 From: jsuther1974 Date: Fri, 3 Mar 2023 11:54:26 -0800 Subject: [PATCH 14/21] Update select-types-of-rules-to-create.md --- .../select-types-of-rules-to-create.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index ca612437cd..1945e7f623 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -33,7 +33,7 @@ Windows Defender Application Control (WDAC) can control what runs on Windows 10 WDAC is used to restrict devices to run only approved apps, while the operating system is hardened against kernel memory attacks using [hypervisor-protected code integrity (HVCI)](/windows/security/threat-protection/device-guard/introduction-to-device-guard-virtualization-based-security-and-windows-defender-application-control). -## WDAC policy rules +## 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: From d4df1feff3aafd99acbeb9b0c0af011386274027 Mon Sep 17 00:00:00 2001 From: jsuther1974 Date: Fri, 3 Mar 2023 12:08:58 -0800 Subject: [PATCH 15/21] Update select-types-of-rules-to-create.md --- .../select-types-of-rules-to-create.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index 1945e7f623..bfd2021af9 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -174,7 +174,7 @@ You can also use the following macros when the exact volume may vary: `%OSDRIVE% Without a wildcard, the filepath rule allows only a specific file (ex. `C:\foo\bar.exe`). > [!NOTE] -> When authoring WDAC policies with Microsoft Configuration Manager (ConfigMgr), you can instruct ConfigMgr to create rules for specified files and folders. These rules **aren't** WDAC filepath rules. Rather, ConfigMgr performs a one-time scan of the specified files and folders and builds rules for any binaries found in those locations at the time of that scan. File changes to those specified files and folders after that scan won't be allowed unless the ConfigMgr policy is reapplied. +> When authoring WDAC policies with Configuration Manager, there is an option to create rules for specified files and folders. These rules **aren't** WDAC filepath rules. Rather, Configuration Manager performs a one-time scan of the specified files and folders and builds rules for any binaries found in those locations at the time of that scan. File changes to those specified files and folders after that scan won't be allowed unless the Configuration Manager policy is reapplied. > [!NOTE] > There is currently a bug where MSIs cannot be allow listed in file path rules. MSIs must be allow listed using other rule types, for example, publisher rules or file attribute rules. From 15bf8559b1af6f2a6ad34bc38146208db6b127a5 Mon Sep 17 00:00:00 2001 From: Vinay Pamnani <37223378+vinaypamnani-msft@users.noreply.github.com> Date: Fri, 3 Mar 2023 15:32:00 -0500 Subject: [PATCH 16/21] Update diagnose-provisioning-packages.md --- .../diagnose-provisioning-packages.md | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md b/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md index 55773531a2..b3207522a4 100644 --- a/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md +++ b/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md @@ -18,23 +18,22 @@ This article helps diagnose common issues with applying provisioning packages. Y ## Unable to apply power settings -When applying a provisioning package (PPKG) containing [power settings](/windows-hardware/customize/power-settings/update-power-settings), elevated permissions are required. Power settings applied using the user context after the [initial setup](/windows/configuration/provisioning-packages/provisioning-apply-package#after-initial-setup), results in the error `STATUS_PRIVILEGE_NOT_HELD (HRESULT=0xc0000061)` because an incorrect security context was used. +When applying a provisioning package (PPKG) containing power settings, elevated permissions are required. Because elevated permissions are required, power settings applied using the user context after the [initial setup](/windows/configuration/provisioning-packages/provisioning-apply-package#after-initial-setup) results in the error `STATUS_PRIVILEGE_NOT_HELD (HRESULT=0xc0000061)` because an incorrect security context was used. To apply the power settings successfully with the [correct security context](/windows/win32/services/localsystem-account), place the PPKG in `%WINDIR%/Provisioning/Packages` directory, and reboot the device. For more information, see [Configure power settings](/windows-hardware/customize/power-settings/configure-power-settings). ## Unable to perform bulk enrollment in Azure AD -See [allow enrollment into Azure AD for provisioning packages](https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400). +When [enrolling devices into Azure AD using provisioning packages](https://techcommunity.microsoft.com/t5/intune-customer-success/bulk-join-a-windows-device-to-azure-ad-and-microsoft-endpoint/ba-p/2381400), the bulk token request will be rejected, if the user requesting a bulk token is not authorized to grant application consent. For more information, see [Configure how users consent to applications](/azure/active-directory/manage-apps/configure-user-consent). - +> [!NOTE] +> When obtaining the bulk token, you should select "No, sign in to this app only" when prompted for authentication. If you select "OK" instead without also selecting "Allow my organization to manage my device", the bulk token request may be rejected. ## Unable to apply a multivariant provisioning package When applying a [multivariant package](/windows/configuration/provisioning-packages/provisioning-multivariant), it may be difficult to diagnose why a certain target did not get applied. There may have been improperly authored conditions that did not evaluate as expected. -To diagnose problems with multivariant packages, [MdmDiagnosticsTool](/windows/client-management/diagnose-mdm-failures-in-windows-10) (in Windows 11 version 22H2) includes multivariant condition values which can be helpful to determine why the PPKG was not applied. +Starting in Windows 11, version 22H2, [MdmDiagnosticsTool](/windows/client-management/diagnose-mdm-failures-in-windows-10) includes multivariant condition values to diagnose problems with multivariant packages to determine why the package was not applied. You can use the following PowerShell example to review the multivariant conditions in the `MDMDiagReport.xml` report: From e00c4fe5241339943f6592bb0fcf7b094df4c552 Mon Sep 17 00:00:00 2001 From: tiaraquan Date: Fri, 3 Mar 2023 12:58:20 -0800 Subject: [PATCH 17/21] Word choice --- .../windows-autopatch-windows-feature-update-end-user-exp.md | 2 +- .../windows-autopatch-windows-quality-update-end-user-exp.md | 2 +- .../windows-autopatch-windows-update-unsupported-policies.md | 4 ++-- 3 files changed, 4 insertions(+), 4 deletions(-) diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-feature-update-end-user-exp.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-feature-update-end-user-exp.md index 011b6892d8..cdbcde747d 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-feature-update-end-user-exp.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-feature-update-end-user-exp.md @@ -14,7 +14,7 @@ ms.reviewer: hathind # Windows feature update end user experience -Windows Autopatch aims to deploy updates predictably while minimizing the effect to end users by preventing reboots during business hours. +Windows Autopatch aims to deploy updates predictably while minimizing the effect to end users by preventing restarts during business hours. ## User notifications diff --git a/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-quality-update-end-user-exp.md b/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-quality-update-end-user-exp.md index 7772457c57..e18ee9ef48 100644 --- a/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-quality-update-end-user-exp.md +++ b/windows/deployment/windows-autopatch/operate/windows-autopatch-windows-quality-update-end-user-exp.md @@ -14,7 +14,7 @@ ms.reviewer: hathind # Windows quality update end user experience -Windows Autopatch aims to deploy updates predictably while minimizing the effect to end users by preventing reboots during business hours. +Windows Autopatch aims to deploy updates predictably while minimizing the effect to end users by preventing restarts during business hours. ## User notifications diff --git a/windows/deployment/windows-autopatch/references/windows-autopatch-windows-update-unsupported-policies.md b/windows/deployment/windows-autopatch/references/windows-autopatch-windows-update-unsupported-policies.md index 4047120921..01ddeb4f2e 100644 --- a/windows/deployment/windows-autopatch/references/windows-autopatch-windows-update-unsupported-policies.md +++ b/windows/deployment/windows-autopatch/references/windows-autopatch-windows-update-unsupported-policies.md @@ -105,8 +105,8 @@ Window Autopatch deploys mobile device management (MDM) policies to configure de | Allowed policy | Policy CSP | Description | | ----- | ----- | ----- | -| [Active hours start](/windows/client-management/mdm/policy-csp-update#update-activehoursstart) | Update/ActiveHoursStart | This policy controls the end of the protected window where devices won't reboot.

Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. | -| [Active hours end](/windows/client-management/mdm/policy-csp-update#update-activehoursend) | Update/ActiveHoursEnd | This policy controls the end of the protected window where devices won't reboot.

Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. | +| [Active hours start](/windows/client-management/mdm/policy-csp-update#update-activehoursstart) | Update/ActiveHoursStart | This policy controls the end of the protected window where devices won't restart.

Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. | +| [Active hours end](/windows/client-management/mdm/policy-csp-update#update-activehoursend) | Update/ActiveHoursEnd | This policy controls the end of the protected window where devices won't restart.

Supported values are from zero through to 23, where zero is 12∶00AM, representing the hours of the day in local time on that device. This value can be no more than 12 hours after the time set in active hours start. | | [Active hours max range](/windows/client-management/mdm/policy-csp-update#update-activehoursmaxrange) | Update/ActiveHoursMaxRange | Allows the IT admin to specify the max active hours range.

This value sets the maximum number of active hours from the start time. Supported values are from eight through to 18. | ### Group policy and other policy managers From 7f9493db2bdb82e0cfc8a7d287c24dceba71ec38 Mon Sep 17 00:00:00 2001 From: Angela Fleischmann Date: Fri, 3 Mar 2023 14:20:57 -0700 Subject: [PATCH 18/21] Apply suggestions from code review Fix correctness issues from the [scorecard](https://microsoft-ce-csi.acrolinx.cloud/api/v1/checking/scorecards/cd08c039-89e1-47de-b9dc-fc5db7418bbe#CORRECTNESS). --- .../select-types-of-rules-to-create.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md index bfd2021af9..2fb47fdf33 100644 --- a/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md +++ b/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md @@ -99,7 +99,7 @@ Each file rule level has advantages and disadvantages. Use Table 2 to select the | **RootCertificate** | This level may produce an overly permissive policy and isn't recommended for most use cases. | | **WHQL** | Only trusts binaries that have been submitted to Microsoft and signed by the Windows Hardware Qualification Lab (WHQL). This level 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** | This level combines the the "FileName" attribute of the signed file, plus "WHQLPublisher", plus a minimum version number. This level is primarily for kernel binaries. | +| **WHQLFilePublisher** | This level combines the "FileName" attribute of the signed file, plus "WHQLPublisher", plus a minimum version number. 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. @@ -168,8 +168,8 @@ You can also use the following macros when the exact volume may vary: `%OSDRIVE% | Examples | Description | Supported operating systems | |------------ | ----------- | ----------- | | **C:\\Windows\\\***
**D:\\EnterpriseApps\\MyApp\\\***
**%OSDRIVE%\\Windows\\\*** | Wildcards placed at the end of a path authorize all files in the immediate path and its subdirectories recursively. | Windows 11, Windows 10, and Windows Server 2022 | -| **\*\\bar.exe** | Wildcards placed at the beginning of a path allows the exact specified filename in any location. | Windows 11, Windows 10, and Windows Server 2022 | -| **C:\\\*\\CCMCACHE\\\*\\7z????-x64.exe**
**%OSDRIVE%\\\*\\CCMCACHE\\\*\\7z????-x64.exe** | Wildcards used in the middle of a path allows all files that match that pattern. Consider carefully all the possible matches, particularly if your policy disables the admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option. In this example both of these hypothetical paths would match:
*`C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe`*
*`C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe`* | Windows 11 only | +| **\*\\bar.exe** | Wildcards placed at the beginning of a path allow the exact specified filename in any location. | Windows 11, Windows 10, and Windows Server 2022 | +| **C:\\\*\\CCMCACHE\\\*\\7z????-x64.exe**
**%OSDRIVE%\\\*\\CCMCACHE\\\*\\7z????-x64.exe** | Wildcards used in the middle of a path allow all files that match that pattern. Consider carefully all the possible matches, particularly if your policy disables the admin-writeable check with the **Disabled:Runtime FilePath Rule Protection** option. In this example, both of these hypothetical paths would match:
*`C:\WINDOWS\CCMCACHE\12345\7zabcd-x64.exe`*
*`C:\USERS\WDACUSER\Downloads\Malware\CCMCACHE\Pwned\7zhaha-x64.exe`* | Windows 11 only | Without a wildcard, the filepath rule allows only a specific file (ex. `C:\foo\bar.exe`). From 86af5a7ecb4d434aee6d74de19ee0d38cbb6912a Mon Sep 17 00:00:00 2001 From: Angela Fleischmann Date: Fri, 3 Mar 2023 15:47:16 -0700 Subject: [PATCH 19/21] Apply suggestions from code review Replace Latin abbreviations with English words and remove the slash before the URL. --- .../client-management/diagnose-mdm-failures-in-windows-10.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/client-management/diagnose-mdm-failures-in-windows-10.md b/windows/client-management/diagnose-mdm-failures-in-windows-10.md index f9829a3514..98dca55229 100644 --- a/windows/client-management/diagnose-mdm-failures-in-windows-10.md +++ b/windows/client-management/diagnose-mdm-failures-in-windows-10.md @@ -50,7 +50,7 @@ The zip file will have logs according to the areas that were used in the command - DiagnosticLogCSP_Collector_DeviceProvisioning_*: Provisioning etls (Microsoft-Windows-Provisioning-Diagnostics-Provider) - MDMDiagHtmlReport.html: Summary snapshot of MDM configurations and policies. Includes, management url, MDM server device ID, certificates, policies. - MdmDiagLogMetadata, json: mdmdiagnosticstool metadata file, contains command-line arguments used to run the tool -- MDMDiagReport.xml: contains a more detailed view into the MDM configurations, e.g enrollment variables, provisioning packages, multivariant conditions, etc. For more information about diagnosing provisioning packages, see [Diagnose provisioning packages](/windows/configuration/provisioning-packages/diagnose-provisioning-packages.md). +- MDMDiagReport.xml: contains a more detailed view into the MDM configurations, such as enrollment variables, provisioning packages, multivariant conditions, and others. For more information about diagnosing provisioning packages, see [Diagnose provisioning packages](windows/configuration/provisioning-packages/diagnose-provisioning-packages.md). - MdmDiagReport_RegistryDump.reg: contains dumps from common MDM registry locations - MdmLogCollectorFootPrint.txt: mdmdiagnosticslog tool logs from running the command - *.evtx: Common event viewer logs microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx main one that contains MDM events. From 6be0928995a550ca8121ab95951d6106538eb3f6 Mon Sep 17 00:00:00 2001 From: Angela Fleischmann Date: Fri, 3 Mar 2023 15:53:37 -0700 Subject: [PATCH 20/21] Update windows/client-management/diagnose-mdm-failures-in-windows-10.md Line 53: Change link to site-relative link. --- .../client-management/diagnose-mdm-failures-in-windows-10.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/client-management/diagnose-mdm-failures-in-windows-10.md b/windows/client-management/diagnose-mdm-failures-in-windows-10.md index 98dca55229..246e8babc9 100644 --- a/windows/client-management/diagnose-mdm-failures-in-windows-10.md +++ b/windows/client-management/diagnose-mdm-failures-in-windows-10.md @@ -50,7 +50,7 @@ The zip file will have logs according to the areas that were used in the command - DiagnosticLogCSP_Collector_DeviceProvisioning_*: Provisioning etls (Microsoft-Windows-Provisioning-Diagnostics-Provider) - MDMDiagHtmlReport.html: Summary snapshot of MDM configurations and policies. Includes, management url, MDM server device ID, certificates, policies. - MdmDiagLogMetadata, json: mdmdiagnosticstool metadata file, contains command-line arguments used to run the tool -- MDMDiagReport.xml: contains a more detailed view into the MDM configurations, such as enrollment variables, provisioning packages, multivariant conditions, and others. For more information about diagnosing provisioning packages, see [Diagnose provisioning packages](windows/configuration/provisioning-packages/diagnose-provisioning-packages.md). +- MDMDiagReport.xml: contains a more detailed view into the MDM configurations, such as enrollment variables, provisioning packages, multivariant conditions, and others. For more information about diagnosing provisioning packages, see [Diagnose provisioning packages](/windows/configuration/provisioning-packages/diagnose-provisioning-packages). - MdmDiagReport_RegistryDump.reg: contains dumps from common MDM registry locations - MdmLogCollectorFootPrint.txt: mdmdiagnosticslog tool logs from running the command - *.evtx: Common event viewer logs microsoft-windows-devicemanagement-enterprise-diagnostics-provider-admin.evtx main one that contains MDM events. From 7fb53acabf2df59b2953f277f0494e481d42996b Mon Sep 17 00:00:00 2001 From: Office Content Publishing 2 <44301038+officedocspr2@users.noreply.github.com> Date: Sat, 4 Mar 2023 23:31:37 -0800 Subject: [PATCH 21/21] Uploaded file: education-content-updates.md - 2023-03-04 23:31:37.5516 --- education/includes/education-content-updates.md | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/education/includes/education-content-updates.md b/education/includes/education-content-updates.md index 8de6af0540..bcc60c501f 100644 --- a/education/includes/education-content-updates.md +++ b/education/includes/education-content-updates.md @@ -2,6 +2,15 @@ +## Week of February 27, 2023 + + +| Published On |Topic title | Change | +|------|------------|--------| +| 2/28/2023 | [Configure federation between Google Workspace and Azure AD](/education/windows/configure-aad-google-trust) | modified | +| 2/28/2023 | [Configure federated sign-in for Windows devices](/education/windows/federated-sign-in) | modified | + + ## Week of February 20, 2023