One rule blocks Teams and another allows it, and both are delivered to the device.
Microsoft uses that exact example. Firewall rules profiles behave differently from every other policy type in Intune: conflicting rules are not resolved centrally, they are both sent and the conflict lands on the device.
- 150 rulesPer firewall rules profile instance
- Rules mergeAcross profiles, so you can exceed 150
- Both deliveredWhen two rules conflict, not resolved
- All or nothingAtomic block behaviour on current Windows
On older Windows builds, a bad rule can leave a partial firewall configuration behind.
The change to atomic application is one of the more consequential firewall behaviours Microsoft has documented, and it splits your estate by build.
- Beginning with Windows 11 21H2, Windows 11 22H2 and Windows 10 21H2, the updated CSP behaviour enforces an all or nothing application of firewall rules from each atomic block. Either the whole block applies or none of it does.
- On earlier Windows versions the CSP processes rules one at a time, and if it encounters an issue applying any rule from the block it stops applying subsequent rules but does not roll back rules already applied successfully.
- That produces a partial deployment of firewall rules on the device: some rules present, some absent, and nothing in the console indicating which. It is a genuinely difficult state to diagnose because the policy itself looks correctly assigned.
- The practical consequence is that estates with a mix of builds need their firewall rule profiles validated on real devices from each build family, not just on a current one, before anybody relies on the resulting configuration.
Eight behaviours that determine what your devices actually enforce.
Firewall settings without the surrounding template
The same settings exist in endpoint protection profiles for device configuration, which also carry additional categories unrelated to firewalls. Using the dedicated firewall policy keeps the configuration surface to what you are actually managing, on both Windows and macOS.
Two profile families, two behaviours
Windows Firewall configures the firewall itself with host-based two-way traffic filtering. Windows Firewall rules defines granular rules covering ports, protocols, applications and networks. Microsoft states explicitly that Windows Firewall profiles do not conflict with Windows Firewall rules profiles.
Conflicting rules are both delivered
When different rules exist for the same thing with different configurations, both are sent to the device and the conflict occurs there. Microsoft gives the example of one rule blocking Teams and another allowing it, and notes this differs from how other firewall policy conflicts behave.
Non-conflicting rules merge, usefully
Where rules from multiple rules profiles do not conflict, devices merge them into a combined configuration. That is the documented way to exceed the 150 custom rules each individual profile supports, by splitting a large rule set across several profiles.
Atomic blocks and partial deployment
From Windows 11 21H2, Windows 11 22H2 and Windows 10 21H2 the firewall CSP applies each atomic block of rules all or nothing. On earlier versions it processes one rule at a time, stops on an error, and does not roll back what already applied, producing partial deployment.
Reusable settings groups, and one gap
In public preview, Windows firewall rule profiles support reusable settings groups for remote IP address ranges and for FQDN definitions with auto-resolution. Worth knowing before designing around them: inbound FQDN rules are not natively supported.
Three errors with documented causes
Port range errors are usually ascending order, the 0 to 65535 bound, or protocol not being set to TCP or UDP when a port range is configured. A name parameter error usually means edge traversal is enabled without an inbound direction. Interface type errors mean All is selected alongside others.
Reporting that finds the devices with it off
A summary view with an aggregate count of devices whose firewall is off, a report listing each of those devices from the DeviceStatus CSP, and an organisational status report distinguishing enabled, disabled, limited, temporarily disabled and not applicable.
Intune does not resolve conflicting firewall rules. It sends both.
Microsoft flags this as different from every other firewall policy conflict, and it changes how a rule set has to be governed.
- When different rules exist for the same thing with different configurations, both are sent to the device and create a conflict there. The documented example is one rule blocking Teams through the firewall while a second allows it, with both delivered to the client.
- That is explicitly different from how Windows Firewall profile conflicts behave. There, when two policy instances or policy types manage the same setting with different values, the setting is simply not sent to the device at all. Two families, two opposite outcomes.
- The upside of the rules behaviour is real though. Where rules across multiple profiles do not conflict, devices merge them into a combined configuration, and that is the documented way to deploy more than the 150 custom rules a single profile supports.
- So the governance requirement is a rule inventory rather than a policy inventory. With rules merging across profiles and conflicts landing on the device rather than being resolved centrally, the only reliable view of what a device enforces is one you assemble yourself.
Four things that make a host firewall rule set trustworthy.
We assemble the merged rule set
Rules from multiple profiles merge on the device into a combined configuration, which is what lets you exceed the 150 rules a single profile supports. It also means no single profile shows what a device enforces, so the effective set has to be assembled rather than read.
We find contradictory rules before devices do
Where different rules exist for the same thing with different configurations, both are sent to the device and the conflict occurs there. Microsoft gives blocking and allowing Teams as the example. Finding those centrally is the only way to prevent unpredictable enforcement.
We check the three errors with known causes
Port range errors come from non-ascending ranges, values outside 0 to 65535, or protocol not being set to TCP or UDP when a range is used. Name errors come from edge traversal without an inbound direction. Interface errors come from All being selected alongside others.
We check for the partial deployment case
On Windows versions before the atomic block change, the CSP applies rules one at a time, stops when one fails and does not roll back what already applied. That leaves a device partially configured in a way that neither the console nor the device makes obvious.
Four phases across roughly four weeks.
- 01Week 1
Assemble the effective rule set
Every firewall rules profile assigned to a device group, combined into the merged set that device actually receives. Conflicting rules identified specifically, since those are delivered to the device rather than resolved, and the device is left to reconcile them.
- Merged rule set assembled per device group
- Conflicting rules identified explicitly
- Rule count checked against the 150 per profile limit
- Windows Firewall profile conflicts identified separately
- 02Week 2
Check for partial deployment risk
Windows versions confirmed against the atomic block behaviour, since earlier versions apply rules one at a time, stop on error and do not roll back, producing partial deployment. Devices below Windows 10 21H2 or Windows 11 21H2 carry that risk.
- Windows version coverage established
- Devices at risk of partial rule deployment identified
- Rule errors in event logs reviewed
- Documented error causes checked against failing rules
- 03Week 3
Fix the rules that were never going to apply
Port ranges checked for ascending order, the 0 to 65535 bound and whether protocol is set to TCP or UDP where a range is configured. Edge traversal rules checked for inbound direction. Interface type rules checked for All being selected alongside others.
- Port range rules corrected against the three causes
- Edge traversal rules given inbound direction
- Interface type selections corrected
- Rules validated on a test device before wider assignment
- 04Week 4
Restructure and verify
Rules split across profiles deliberately so the merge behaviour works for you rather than by accident, reusable settings groups considered for remote IP ranges, and the reports used to confirm no device is running with the firewall off.
- Rule set restructured across profiles by purpose
- Reusable settings groups evaluated
- Devices with firewall off identified and remediated
- Ongoing rule review cadence agreed
Six situations where host firewall policy needs attention.
An organisation whose firewall rules have accumulated
Rules added one at a time to unblock an application, across several profiles, merging on the device. Because the merged set is not visible in any single profile, nobody can say what is currently permitted, which is a difficult position to defend in a review.
A business with unpredictable application behaviour
An application that works on some machines and not others is a classic symptom of contradictory rules being delivered together, since Intune sends both and the device reconciles them. That is different from other policy conflicts and it is not obvious from the console.
A company that has hit the 150 rule ceiling
Each firewall rules profile instance supports up to 150 custom rules. The documented answer is splitting across profiles, since non-conflicting rules merge on the device into a combined configuration. That is a design decision rather than a workaround.
An operator running older Windows on site machines
Devices below Windows 10 21H2 or Windows 11 21H2 use the older atomic block behaviour, applying rules one at a time and stopping without rollback on error. Site and plant machines are frequently the oldest in an estate and the least likely to be checked.
A regulated firm asked to evidence host firewall state
The organisational status report distinguishes enabled, disabled, limited where the firewall is not monitoring all networks or some rules are off, temporarily disabled, and not applicable. That granularity produces a far better answer than a simple on or off count.
A team managing rules for many remote IP ranges
Reusable settings groups, in public preview, cover remote IP address ranges and FQDN definitions with auto-resolution, so a range set is maintained once rather than in every rule. The constraint to design around is that inbound FQDN rules are not natively supported.
How UAE organisations manage the host firewall.
| Feature | Firewall policy, rule set governed | Rules added over time | Firewall off or default |
|---|---|---|---|
Effective rule set known | Yes | No | Not applicable |
Conflicting rules identified | Yes | Landed on devices | Not applicable |
Rule count managed against the limit | Yes | Unknown | Not applicable |
Partial deployment risk assessed | Yes | No | Not applicable |
Failing rules corrected | Yes | Unnoticed | Not applicable |
macOS firewall configured | Yes | Sometimes | No |
Devices with firewall off found | Reported | Occasionally | Not looked for |
Hyper-V container rules considered | Yes | No | No |
Reusable settings groups used | Where useful | No | No |
Auditable | Yes | Difficult | No |
Windows Firewall profiles against Windows Firewall rules profiles.
| Behaviour | Windows Firewall profile | Windows Firewall rules profile | |
|---|---|---|---|
| What it configures | The firewall itself and its settings | Granular allow and block rules | |
| Conflict with the other family | Does not conflict with rules profiles | Does not conflict with firewall profiles | |
| Conflict within the family | Setting is not sent to the device | Both rules are sent, conflict lands on the device | |
| Multiple profiles on one device | Creates conflicts | Supported, and rules merge when they do not conflict | |
| Rule limit | Not applicable | 150 custom rules per profile instance | |
| Exceeding the limit | Not applicable | Split across profiles, which merge on the device | |
| Reusable settings groups | Not applicable | Preview, for remote IP ranges and FQDN definitions | |
| Inbound FQDN rules | Not applicable | Not natively supported | |
| Hyper-V container rules | Separate profile | Separate profile, covering WSL and WSA | |
| macOS | A dedicated macOS firewall profile | Not applicable |
Five steps, and the first produces the artefact nobody has.
- 1
Assemble the effective merged rule set
Every rules profile assigned to a device group, combined as the device combines them. Rules from multiple profiles merge into a single configuration when they do not conflict, so the effective set is broader than any individual profile suggests.
- 2
Identify rules that contradict each other
Where different rules configure the same thing differently, both are delivered and the conflict lands on the device. That is specific to rules profiles and differs from Windows Firewall profile conflicts, where the setting is simply not sent at all.
- 3
Find the rules that were never going to apply
Three documented error causes: port ranges not ascending, outside 0 to 65535, or lacking a TCP or UDP protocol setting; edge traversal enabled without an inbound direction; and the All interface type selected alongside other interface types.
- 4
Assess partial deployment exposure
Windows versions checked against the atomic block change, since earlier versions apply rules one at a time and stop on error without rolling back what already applied. Devices in that category may be carrying a partially applied rule set nobody has noticed.
- 5
Restructure, then verify with the reports
Rules split across profiles by purpose so the merge behaviour is deliberate, reusable settings groups used where a range set repeats, and the firewall status reports used to confirm no device is running with the firewall turned off or in a limited state.
What organisations ask about Intune firewall policy.
Fifteen questions about your own firewall rules.
Structure
- How many rules profiles are assigned?They merge on the device.
- Is any profile near 150 rules?That is the per profile limit.
- Do any rules contradict each other?Both get delivered.
- Do we also use endpoint protection profiles?They configure the same settings.
- Are macOS devices covered?There is a dedicated profile.
Deployment
- Are devices on Windows 10 21H2 or later?Atomic block behaviour changed there.
- Could any device be partially configured?Earlier versions do not roll back.
- Have we checked event logs for rule errors?Causes are documented.
- Do we use Hyper-V firewall rules?For WSL and WSA containers.
- Do we use the Policy App Id setting?It requires application control tagging.
Common errors
- Are port ranges ascending?1 to 5, not 5 to 1.
- Are they within 0 to 65535?A stated bound.
- Is protocol set where ranges are used?TCP or UDP is required.
- Do edge traversal rules apply inbound?Required if enabled.
- Is All selected alongside other interface types?It must not be.
Count the firewall rules profiles assigned to one device group, then write down the combined rule set.
Rules merge across profiles on the device, so no single profile shows what is enforced. If assembling that list is hard, that is the finding, and it is the reason contradictory rules go unnoticed.
Related Services
Explore more solutions that work great with this service
Intune Antivirus Policy
What Defender settings actually reach the device
Firewall Rule Audit
What the rule base permits, and what should go
Security Baselines
Why deploying one does not make you CIS compliant
Intune Configuration Profiles
Settings catalog, templates and conflict management
Endpoint Security
Defender for Endpoint and Intune managed
Defender for Endpoint
Business, Plan 1 or Plan 2, and what each actually gives you
MDM Solutions Dubai
Device management across Windows, Apple and Android
Microsoft Intune
Device management and endpoint security