Two rules disagree about Teams, one blocking and one allowing, and Intune sends both anyway.
That example comes from the vendor documentation, not from us. Rules profiles do not follow the conflict resolution model the rest of Intune uses. Nothing is arbitrated in the service. Both rules go out, and whatever happens next happens on the endpoint.
- 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 behavior on current Windows
An invalid rule on an older Windows build can leave the machine holding half a firewall configuration.
Few documented firewall behaviors matter as much as the move to atomic application, and it cuts your estate cleanly along build lines.
- Windows 11 21H2, Windows 11 22H2 and Windows 10 21H2 brought a revised CSP behavior that treats each atomic block as indivisible. The block lands in full or it does not land at all.
- Older versions work through the block rule by rule. Hit a problem on any one of them and the CSP abandons everything that was still queued behind it, while leaving every rule that had already succeeded exactly where it is.
- The result on the machine is a rule set with holes in it, some rules present and some missing, and no indication anywhere in the console of which is which. Diagnosing it is genuinely hard, because from the service side the policy looks perfectly well assigned.
- Where builds are mixed, that means testing every firewall rule profile on a physical device drawn from each build family rather than on one modern machine, and doing it before anybody treats the resulting configuration as trustworthy.
Eight behaviors that determine what your devices actually enforce.
Firewall settings without the surrounding template
You will find the same settings inside endpoint protection profiles under device configuration, bundled together with a range of categories that have nothing to do with firewalls. Going through the dedicated firewall policy instead narrows what you are looking at to what you are actually managing, and it works the same way for Windows and macOS.
Two profile families, two behaviors
The Windows Firewall profile configures the firewall as a whole, giving you host-based filtering in both directions. The Windows Firewall rules profile is where the detail lives: individual rules covering ports, protocols, applications and networks. One helpful guarantee from the documentation is that the two never conflict with each other.
Conflicting rules are both delivered
Two rules that address the same thing in incompatible ways are both delivered, and the disagreement is resolved on the endpoint rather than in the service. The documented illustration is one rule blocking Teams while another allows it, and the documentation is careful to flag that this is not how conflicts behave elsewhere in firewall policy.
Non-conflicting rules merge, usefully
Non-conflicting rules coming from several rules profiles are merged on the device into one combined configuration. That merge behavior is the sanctioned route past the 150 custom rule ceiling on any single profile: break a large rule set into multiple profiles and let the device assemble it.
Atomic blocks and partial deployment
On Windows 11 21H2, Windows 11 22H2 and Windows 10 21H2 and later, the firewall CSP treats each atomic block of rules as all or nothing. Anything older behaves differently and worse: rules are processed one after another, processing halts at the first error, and nothing already written gets rolled back. What you are left with is a machine holding part of a rule set.
Reusable settings groups, and one gap
Reusable settings groups are in public preview for Windows firewall rule profiles, covering remote IP address ranges and fully qualified domain name definitions with automatic resolution. Before you design a rule set around them, note the gap: inbound FQDN rules have no native support.
Three errors with documented causes
Most errors resolve to one of three causes. Port range complaints normally mean the range is not ascending, falls outside 0 to 65535, or has no protocol set to TCP or UDP alongside it. A name parameter error nearly always means edge traversal was enabled on a rule with no inbound direction. And an interface type error means All has been picked at the same time as specific types.
Reporting that finds the devices with it off
Three views come with it: a summary carrying a single count of devices running with the firewall off, a detail report naming each of those devices sourced from the DeviceStatus CSP, and an organizational status report that separates enabled, disabled, limited, temporarily disabled and not applicable rather than lumping them together.
Conflicting firewall rules are not arbitrated by Intune. Both of them go out.
The documentation singles this out as behaving unlike every other firewall policy conflict, and that difference reshapes how a rule set has to be governed.
- Where two rules cover the same thing with different settings, both reach the device and the conflict surfaces there. The example on record has one rule blocking Teams at the firewall and another permitting it, with the client receiving each of them.
- Windows Firewall profiles handle the same situation in the opposite way, and the documentation says so directly. If two policy instances or two policy types set the same value differently, that setting is withheld from the device entirely. Same product, two families, two opposite outcomes.
- There is a genuine benefit hiding in the same behavior. Rules spread across several profiles that do not contradict each other get merged on the device into one configuration, and that merge is the documented mechanism for going beyond the 150 custom rules any single profile will hold.
- Which means what you need to govern is an inventory of rules, not an inventory of policies. Since rules merge across profiles and conflicts are settled on the endpoint rather than in the service, the only dependable picture of what a machine enforces is one you build by hand.
Four things that make a host firewall rule set trustworthy.
We assemble the merged rule set
Because rules coming from several profiles combine on the device into one configuration, you can carry more than the 150 rules a single profile allows. The same mechanism has a cost: no individual profile represents what the device enforces, so the effective set has to be built rather than looked up.
We find contradictory rules before devices do
Two rules covering the same thing with different settings are both delivered, and the disagreement plays out on the endpoint. Blocking and allowing Teams is the documented illustration. Catching those centrally, before delivery, is the only route to enforcement you can predict.
We check the three errors with known causes
A port range error means one of three things: the range does not ascend, it strays outside 0 to 65535, or no TCP or UDP protocol was set alongside it. A name error means edge traversal was enabled on a rule with no inbound direction. An interface error means All was selected together with specific types.
We check for the partial deployment case
Any Windows version predating the atomic block change works through rules sequentially, gives up when one fails, and leaves everything already written in place. The machine ends up partly configured, and neither the console nor the device itself gives you an obvious signal that this happened.
Four phases across roughly four weeks.
- 01Week 1
Assemble the effective rule set
We take every firewall rules profile assigned to a device group and assemble the merged set the device genuinely receives. Conflicting rules get called out by name, because those are not resolved anywhere upstream. They arrive at the endpoint and the endpoint is left to work them out.
- 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
Every Windows version in the estate is checked against the atomic block behavior. Anything older applies rules sequentially, halts at the first error and rolls nothing back, which is how you end up with a half-applied rule set. Devices below Windows 10 21H2 or Windows 11 21H2 sit in that category.
- 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
We validate each port range for ascending order, for staying inside 0 to 65535, and for having TCP or UDP set wherever a range appears. Anything with edge traversal enabled is checked for an inbound direction. And every interface type rule is checked in case All has been selected next to specific types.
- 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 get divided across profiles as a design decision so the merge works in your favor instead of by chance, reusable settings groups are evaluated for remote IP ranges, and the reporting is used to prove that nothing in the estate is running with its firewall switched 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 organization whose firewall rules have accumulated
Every rule went in to unblock one application, they are spread across several profiles, and they merge on the device. Since no single profile reflects the merged result, nobody in the organization can state what is currently permitted. That is an uncomfortable answer to give in a review.
A business with unpredictable application behavior
When an application runs on some machines and not others, contradictory rules arriving together is a leading suspect, because both get delivered and the device is left to reconcile them. It behaves unlike other policy conflicts, and nothing in the console makes it apparent.
A company that has hit the 150 rule ceiling
A single firewall rules profile instance tops out at 150 custom rules. The documented route past that is to split the set across profiles, relying on non-conflicting rules merging into one configuration on the device. Treat that as an intentional part of the design, not a workaround.
An operator running older Windows on site machines
Anything running below Windows 10 21H2 or Windows 11 21H2 falls under the older behavior, applying rules one after another and stopping on error with nothing rolled back. Machines out at sites and in plants tend to be both the oldest hardware in the estate and the least likely to be checked.
A regulated firm asked to evidence host firewall state
Five states appear in the organizational status report rather than two: enabled, disabled, limited where the firewall is not watching every network or some rules are off, temporarily disabled, and not applicable. Handing a SOC 2 auditor, a HIPAA assessment or an insurance questionnaire that level of detail is a materially better answer than a headline count of on versus off.
A team managing rules for many remote IP ranges
Currently in public preview, reusable settings groups handle remote IP address ranges and fully qualified domain name definitions with automatic resolution. A range set then lives in one place instead of being copied into every rule that needs it. Design around one constraint: inbound FQDN rules have no native support.
How US organizations 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.
Behavior
What it configures
- Windows Firewall profile
- The firewall itself and its settings
- Windows Firewall rules profile
- Granular allow and block rules
Behavior
Conflict with the other family
- Windows Firewall profile
- Does not conflict with rules profiles
- Windows Firewall rules profile
- Does not conflict with firewall profiles
Behavior
Conflict within the family
- Windows Firewall profile
- Setting is not sent to the device
- Windows Firewall rules profile
- Both rules are sent, conflict lands on the device
Behavior
Multiple profiles on one device
- Windows Firewall profile
- Creates conflicts
- Windows Firewall rules profile
- Supported, and rules merge when they do not conflict
Behavior
Rule limit
- Windows Firewall profile
- Not applicable
- Windows Firewall rules profile
- 150 custom rules per profile instance
Behavior
Exceeding the limit
- Windows Firewall profile
- Not applicable
- Windows Firewall rules profile
- Split across profiles, which merge on the device
Behavior
Reusable settings groups
- Windows Firewall profile
- Not applicable
- Windows Firewall rules profile
- Preview, for remote IP ranges and FQDN definitions
Behavior
Inbound FQDN rules
- Windows Firewall profile
- Not applicable
- Windows Firewall rules profile
- Not natively supported
Behavior
Hyper-V container rules
- Windows Firewall profile
- Separate profile
- Windows Firewall rules profile
- Separate profile, covering WSL and WSA
Behavior
macOS
- Windows Firewall profile
- A dedicated macOS firewall profile
- Windows Firewall rules profile
- Not applicable
Five steps, and the first produces the artifact nobody has.
- 1
Assemble the effective merged rule set
We take each rules profile assigned to a device group and combine them the way the device would. Non-conflicting rules from separate profiles fold into one configuration, which means the effective set is consistently wider than any single profile would lead you to believe.
- 2
Identify rules that contradict each other
Any two rules that configure the same thing differently both get delivered, and the endpoint inherits the disagreement. That is peculiar to rules profiles. Windows Firewall profile conflicts go the other way, with the setting withheld from the device entirely.
- 3
Find the rules that were never going to apply
The documentation names three: a port range that does not ascend, strays beyond 0 to 65535, or carries no TCP or UDP protocol setting; edge traversal switched on with no inbound direction; and the All interface type chosen at the same time as specific ones.
- 4
Assess partial deployment exposure
We check every Windows version against the atomic block change, because everything older processes rules sequentially, halts at the first failure and rolls back nothing. Devices in that bracket may already be running a partly applied rule set that nobody has spotted.
- 5
Restructure, then verify with the reports
Profiles are divided by purpose so the merge is something you designed rather than something that happened, reusable settings groups take over wherever the same range set repeats, and the status reports are used to prove nothing in the estate is sitting with its firewall off or in a limited state.
What organizations 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 behavior 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.
Take one device group, count the firewall rules profiles on it, and try writing out what they add up to.
Since profiles merge on the endpoint, no one profile tells you what is being enforced. Struggling to assemble that list is itself the finding, and it explains why contradictory rules sit undetected for years.
Related Services
Explore more solutions that work great with this service
Intune Endpoint Security Antivirus Policy
Intune antivirus policy consolidation for US organizations: every
Learn moreIntune Security Baselines
Security baseline design and management for US organizations: stating
Learn moreAttack Surface Reduction Rules Deployment
Attack surface reduction rules deployment for US organizations:
Learn moreMicrosoft Defender for Endpoint Services
EDR plan selection, onboarding and zero-gap AV migration
Learn moreEndpoint Security
Endpoint security for US businesses using Microsoft Defender for
Learn moreMicrosoft Intune
Device management and endpoint security
Learn more