Intune firewall rules not applying: atomic blocks, conflicts, rule limits and MDM errors

You assign a Windows Firewall rules profile in Intune and the app is still blocked, or none of the rules show up on the device. Firewall rules fail in predictable ways: one invalid rule takes the whole profile down, two policies fight over the same setting, or a merge setting hides rules you expected to work. In this post I'll show how to find the failing rule, fix it, and prove which rules are active.

Symptoms#

• A rules profile reports errors, or reports success while traffic is still blocked.
• None of a profile's rules appear on the device, even though only one of them is wrong.
• A Windows Firewall setting, such as turning the firewall on for the public network profile, shows a conflict and never reaches the device.
• Reports › Firewall › MDM Firewall status for Windows lists devices as Disabled, Limited or Temporarily Disabled instead of Enabled.
• The Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin log shows event 404 for firewall rule nodes:

MDM ConfigurationManager: Command failure status. ...
CSP URI: (./Vendor/MSFT/Firewall/MdmStore/FirewallRules/<rule-id>/LocalPortRanges), Result: (The parameter is incorrect).

The last segment of the CSP URI names the property Windows rejected. The variants Microsoft documents are:

• ...LocalPortRanges), Result: (The parameter is incorrect)
• ...RemotePortRanges), Result: (The parameter is incorrect)
• ...Name), Result: (The parameter is incorrect)
• ...InterfaceTypes), Result: (The parameter is incorrect)

Why it happens#

• Atomic blocks are all or nothing. Intune delivers firewall rules to the Firewall configuration service provider (CSP) inside Atomic blocks. On Windows 11 and on Windows 10 21H2 and later, if any rule in a block fails, the CSP applies none of them. Older builds stopped at the failing rule and kept the ones already applied. A property the OS doesn't support fails the block too: ICMP types and codes, for example, aren't supported on Windows 10.
• Invalid values. Port ranges must be ascending and within 0–65535, and a rule with ports needs protocol 6 (TCP) or 17 (UDP). Edge traversal is only valid on inbound rules, and the All interface type can't be combined with other types.
• Setting conflicts. When two policies set the same Windows Firewall setting to different values (two Windows Firewall profiles, or one plus a security baseline, an Endpoint protection template or a settings catalog policy), Intune doesn't send that setting to the device. Windows Firewall profiles don't conflict with Windows Firewall rules profiles.
• Contradicting rules. Rules profiles merge on the device. If one profile blocks an app and another allows it, both rules are delivered, and in Windows Firewall a block rule normally beats an allow rule.
• Local policy merge. When Allow Local Policy Merge is false for a network profile, rules in the device's local store (created by installers, users or scripts) are ignored. If Group Policy also sets this value, the Group Policy value always wins.
• The rule limit. Each Windows Firewall rules profile supports up to 150 custom rules.

How to fix it#

1. Confirm the device received the profile#

In the Microsoft Intune admin center, open Endpoint security › Firewall, select the rules profile and check its device status. If the device isn't listed, fix the assignment (group, filter, platform Windows) first. Then sync from Settings › Accounts › Access work or school (select the account, Info, Sync) so the logs below are fresh.

2. Find the first failing rule#

$log = 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'
Get-WinEvent -FilterHashtable @{ LogName = $log; Id = 404 } -MaxEvents 300 -ErrorAction SilentlyContinue |
    Where-Object { $_.Message -like '*Firewall/MdmStore/FirewallRules*' } |
    Sort-Object TimeCreated |
    Select-Object TimeCreated, Message | Format-List

Read the earliest failure from the latest sync: rules after the bad one can be logged as failed even though they're valid, so fix the first real failure and sync again. The rule ID in the URI is generated by Intune; match it by the property instead and check every rule in the profile that sets it. If several are suspects, use Duplicate on the profile, assign the copy to a test device and remove rules until it applies. Microsoft's Intune support tip on tracing firewall rule creation also includes a Test-IntuneFirewallRules script for this.

3. Correct the rule#

To test a doubtful value, create the same rule by hand on a test device; if Windows rejects it, the policy will fail too.

4. Remove setting conflicts#

For a Windows Firewall setting in conflict, open the profile's per-setting status to find the setting, then find the other policy that manages it. Security baselines are the usual suspect because they set firewall values by default. Give each setting a single owner: set it to Not configured in the baseline or remove it from the extra policy. The MDM diagnostic report shows which source set what, and security baseline conflicts covers the baseline side.

5. Check merge settings and Group Policy#

Get-NetFirewallProfile -PolicyStore ActiveStore |
    Select-Object Name, Enabled, DefaultInboundAction, AllowLocalFirewallRules
gpresult /h "$env:USERPROFILE\Desktop\gpresult.html"

AllowLocalFirewallRules set to False explains apps whose self-created rules stop working. On hybrid joined devices, check the Group Policy report for firewall settings that override Intune.

6. Split large profiles#

Past 150 rules, create another rules profile. Non-conflicting rules from several profiles merge on the device, so splitting by application or team also keeps a bad rule's impact small.

Verify the fix#

Get-NetFirewallRule -PolicyStore ActiveStore |
    Where-Object { $_.PolicyStoreSourceType -eq 'MDM' } |
    Sort-Object DisplayName |
    Format-Table DisplayName, Enabled, Direction, Action, PrimaryStatus -AutoSize

Get-NetFirewallRule -PolicyStore ActiveStore -DisplayName 'Contoso agent inbound' |
    Get-NetFirewallPortFilter

Good looks like this:

• Every rule from the profile is listed with Enabled True and PrimaryStatus OK, and the port filter shows your protocol and ports.
• No new event 404 for MdmStore/FirewallRules after the next sync.
• The profile's device status shows success, and MDM Firewall status for Windows shows Enabled.
• The traffic works: for an outbound rule, Test-NetConnection -ComputerName app01 -Port 443 returns TcpTestSucceeded : True; test inbound rules from another machine.

Prevent it next time#

• Keep rules profiles small and themed, so one bad rule only blocks its own profile.
• Pilot rule changes on a test group that covers every Windows version you run.
• Give every firewall setting one owner, as described in choosing the right Intune policy type.
• If rules break across many devices without a change on your side, check service health and known issues before editing policies.

References#

• Firewall policy for endpoint security in Intune
• Firewall CSP
• Troubleshooting policies and profiles in Microsoft Intune