• Intro
• Defender for Servers and MDE on Azure Local
• Requirements
• Why this happens
• The signer rule to add
• Add the rule to an Azure Local policy
• Locate MDE scripts and verify behavior
• Using a path-based rule as an alternative
• Recommendation

Intro

This article is part of a series: Navigate to series page

Microsoft Defender for Endpoint (MDE) uses built-in PowerShell scripts for some endpoint-security features. Without the required WDAC allow rule, MDE features that rely on these scripts might not work as expected. With the rule, trusted MDE scripts can run in FullLanguage mode while WDAC script enforcement remains enabled.

This part describes the Microsoft-documented signer rule and considerations for adding it to an Azure Local policy. It covers script compatibility only; it doesn’t mean that every MDE feature is supported on Azure Local.

Defender for Servers and MDE on Azure Local

Microsoft’s Azure Local guidance describes enabling Defender for Cloud and the Defender for Servers plan for individual Azure Local machines and Azure Local VMs enabled by Azure Arc. Defender for Servers integrates with MDE; they aren’t competing names for separate endpoint agents. Defender for Servers is the Defender for Cloud plan and onboarding path, while MDE provides endpoint protection and related capabilities.

The Azure Local Defender for Cloud integration is currently documented as a preview. Feature support is specific to Azure Local: for example, Microsoft’s Azure Local guidance says Microsoft Defender Vulnerability Management doesn’t currently support Azure Local. Don’t infer support for a particular MDE feature solely from the fact that MDE is onboarded or that its scripts are allowed.

Requirements

• Windows 10 or later, or Windows Server 2019 or later.
• Devices onboarded to Microsoft Defender for Endpoint.
• MDE sensor version 10.8804 or later.
• WDAC script enforcement enabled on the devices.

Why this happens

Under WDAC script enforcement, PowerShell runs trusted scripts in FullLanguage mode and untrusted scripts in ConstrainedLanguage mode. MDE’s built-in scripts are signed by the Microsoft Windows Defender Advanced Threat Protection publisher. Microsoft documents adding a narrowly scoped signer rule for this publisher to allow those scripts.

MDE’s ConstrainedLanguageCompatible sensor capability controls how it invokes PowerShell under script enforcement. The sensor capability and WDAC signer rule serve different roles; follow Microsoft’s current MDE guidance for your sensor configuration.

Don’t assume script enforcement is enabled just because Application Control is in Enforced mode. Azure Local’s documented default enforced base policy has Script Enforcement disabled; check the active policy before applying this guidance. This article applies when script enforcement is enabled in the policy you use.

The signer rule to add

Add the following signer rule to the <Signers> section of the WDAC policy:

<Signer Name="Microsoft Code Signing PCA 2011" ID="ID_SIGNER_MDE">
  <CertRoot Type="TBS" Value="F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E" />
  <CertPublisher Value="Microsoft Windows Defender Advanced Threat Protection" />
</Signer>

Also add a reference to this signer in the UMCI signing scenario and in <CiSigners>:

<!-- In SigningScenarios > SigningScenario Value="12" > ProductSigners > AllowedSigners -->
<AllowedSigner SignerId="ID_SIGNER_MDE" />

<!-- In CiSigners -->
<CiSigner SignerId="ID_SIGNER_MDE" />

Add the rule to an Azure Local policy

Microsoft’s MDE instructions show the signer rule added to an existing WDAC policy. On Azure Local, you can deploy a change through a supplemental policy, but it must be a valid policy in Multiple Policy Format and correctly associated with the Microsoft-provided base policy. Don’t hand-author a minimal XML policy from scratch; it needs valid policy metadata and a base-policy relationship. Use the App Control for Business Wizard or your approved policy-authoring process to add the MDE rule and create the supplemental policy.

For Azure Local, Microsoft’s documented workflow is to create a Multiple Policy Format policy, set its metadata, and pass the XML to the cluster supplemental-policy cmdlet. The policy-authoring step must include the MDE signer rule shown above; use the wizard or policy tooling rather than treating this deployment command as a complete policy-generation recipe.

$policyPath = "C:\wdac\MDE-supplemental.xml"
$policyVersion = "1.0.0.1"

Set-CIPolicyVersion -FilePath $policyPath -Version $policyVersion
Set-CIPolicyIdInfo -FilePath $policyPath `
  -PolicyName "MDE-Supplemental" `
  -PolicyID "MDE-Supplemental_$policyVersion"

# Azure Local 2610 and later
Add-ASAppControlSupplementalPolicy -Path $policyPath

# For Azure Local 2609 and earlier, use this command instead:
# Add-ASWDACSupplementalPolicy -Path $policyPath

The XML must already be generated as a valid Multiple Policy Format policy before these metadata and deployment commands are run. On Azure Local 2610 and later, use the AppControl cmdlet names; the older WDAC names remain aliases. On earlier releases, use the WDAC-named cmdlets. Check deployment with Get-ASLocalAppControlPolicyInfo on 2610 and later, or Get-ASLocalWDACPolicyInfo on earlier releases.

Locate MDE scripts and verify behavior

MDE’s built-in PowerShell scripts are stored in this protected folder:

C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection\

To access the folder, Microsoft instructs administrators to use PsExec to open a SYSTEM-level command shell, then list the scripts:

PsExec.exe -s cmd.exe
cd "C:\ProgramData\Microsoft\Windows Defender Advanced Threat Protection\DataCollection"
dir *.ps1

Use an MDE-signed script from this folder as the input when creating the publisher allow rule in the App Control for Business Wizard. The rule is intended for built-in MDE script content; it isn’t a general allow rule for arbitrary software.

After deployment, verify the MDE features that rely on PowerShell scripts. You can also review Code Integrity events on the nodes for blocks related to MDE:

Get-WinEvent -FilterHashtable @{
    LogName = 'Microsoft-Windows-CodeIntegrity/Operational'
    StartTime = (Get-Date).AddHours(-1)
} |
Where-Object { $_.Message -match "Defender" -or $_.Message -match "WindowsDefender" } |
Select-Object TimeCreated, Id, Message |
Sort-Object TimeCreated -Descending

An absence of matching events alone doesn’t prove that the feature is working; use it alongside a functional check of the affected MDE feature.

Using a path-based rule as an alternative

If you can’t use the publisher rule, Microsoft documents a path-based allow rule scoped to the MDE DataCollection folder as an alternative. Create it with the App Control for Business Wizard or appropriate ConfigCI policy-authoring cmdlets. Don’t use broad wildcards or user-writable locations; a path rule trusts matching files in that location, so its safety depends on the folder’s access controls.

Warning: Avoid broad wildcards like C:\ProgramData\* or any user-writable path. Scope the path as narrowly as possible.

Recommendation

Use the publisher (certificate-based) signer rule rather than a path-based rule when possible. The TBS value F6F717A43AD9ABDDC8CEFDDE1C505462535E7D1307E630F9544A2D14FE8BF26E identifies the Microsoft Code Signing PCA 2011 certificate used by this signer rule. Although the same TBS value appears in the WAC signer rule from Part 8, the distinct CertPublisher value scopes this rule to the MDE publisher.

If you are also deploying the WAC supplemental from Part 8, consider combining both signer rules into a single “Microsoft Management Supplemental” policy to reduce the number of policies deployed per node.

Official Microsoft references: Allow Microsoft Defender for Endpoint scripts with WDAC script enforcement, Manage Application Control for Azure Local, Manage system security with Microsoft Defender for Cloud on Azure Local, and Onboard servers to Microsoft Defender.