Managing Windows Firewall at scale with GPO and Intune

Configuring Windows Firewall on one machine is easy. Keeping thousands of machines on a consistent, intended policy is where most programmes stall: rules pile up in many GPOs, installers add local rules, Intune and Group Policy both touch the same devices, and nobody can say which rule actually allows a given port.

The Windows Firewall hardening pillar defines what the policy should be. This guide covers how to run it at scale: how policy sources combine, how rules are evaluated, how to structure GPOs and Intune profiles, and how to prove what a device is enforcing. See the Windows Firewall topic for the full series.

How policy stores combine

Windows Firewall keeps rules in several stores and merges them into one active store that the engine enforces:

Two different merge behaviours apply:

• Rules are additive. Every rule from every GPO in scope ends up in the active store. There is no "last writer wins" for rules.
• Profile settings follow precedence. Firewall state, default inbound and outbound action, notifications, logging and the local merge switches are single values; for Group Policy the normal LSDOU order applies and the highest-precedence GPO wins per setting.

The consequence: an allow rule for TCP 3389 from Any in a forgotten legacy GPO linked at the domain root is enforced on every machine, no matter how carefully your new role GPOs scope RDP.

How rules are evaluated

When a packet arrives, the engine applies rules in this order:

1. Windows service hardening restrictions (built in, cannot be overridden).
2. Connection security rules (IPsec) that authenticate or protect traffic.
3. Authenticated bypass rules (allow rules with Override block rules, only usable with IPsec).
4. Block rules.
5. Allow rules.
6. The profile's default action.

Block always beats allow. A common mistake is a broad "Block SMB inbound" rule followed by an "Allow SMB from management servers" rule: the block wins and management breaks. With a default inbound action of Block you rarely need explicit inbound block rules at all; express intent with scoped allow rules, and keep explicit blocks for things that must never happen (for example outbound SMB to the internet).

Step 1: disable local rule merge everywhere

In the firewall GPO properties, for each profile, click Customize under Settings and set Apply local firewall rules to No, and Apply local connection security rules to No. In Intune, the equivalent settings in the firewall profile are Allow Local Policy Merge and Allow Local Ipsec Policy Merge, both set to False per profile (Firewall CSP MdmStore/<Profile>/AllowLocalPolicyMerge and AllowLocalIpsecPolicyMerge).

Local rules are not deleted; they stay in the PersistentStore and are simply ignored. That makes rollback easy, and it also means you need to know which of those local rules actually mattered. Before flipping the switch on a pilot group, export what installers created:

Get-NetFirewallRule -PolicyStore PersistentStore -Direction Inbound -Enabled True -Action Allow |
  ForEach-Object {
    $port = $_ | Get-NetFirewallPortFilter
    $app  = $_ | Get-NetFirewallApplicationFilter
    [pscustomobject]@{ Name=$_.DisplayName; Profile=$_.Profile; Protocol=$port.Protocol
                       LocalPort=$port.LocalPort; Program=$app.Program }
  } | Export-Csv "$env:TEMP\local-inbound-rules.csv" -NoTypeInformation

Collect that CSV from a representative sample, remove what nobody needs, and turn the rest into central rules.

Step 2: structure the GPOs

A layout that stays readable after years:

Guidelines that prevent drift:

• One owner per GPO, named in the GPO comment.
• Rule names carry the ticket or purpose (SQL-1433-from-AppTier-CHG1234), and the rule Group property is set so rules can be filtered and reported as a set.
• Never enable predefined rule groups (Remote Desktop, File and Printer Sharing) without editing their remote scope; they default to Any.
• Audit legacy GPOs for firewall rules. Exporting every GPO with Get-GPOReport -All -ReportType Xml and searching the output for firewall rule elements quickly finds forgotten policies.

GPO firewall rules can be scripted directly into a policy with a GPO session, which avoids hand-editing hundreds of rules:

$gpo = Open-NetGPO -PolicyStore 'corp.example.com\FW-Role-SQL'
New-NetFirewallRule -GPOSession $gpo -DisplayName 'SQL-1433-from-AppTier' `
  -Group 'Role-SQL' -Direction Inbound -Protocol TCP -LocalPort 1433 `
  -RemoteAddress 10.30.20.0/24 -Profile Domain -Action Allow
Save-NetGPO -GPOSession $gpo

Keep the scripts in source control. They become your documentation and your rollback.

Step 3: the Intune equivalent

In the Intune admin center, Endpoint security > Firewall offers two profile types for Windows:

• Windows Firewall (profile settings): state, default actions, local merge, logging, per profile.
• Windows Firewall Rules: individual rules. A single profile holds a limited number of rules (150 at the time of writing), so split by role, as with GPOs.

Assign rule profiles to device groups that mirror your GPO roles, and use assignment filters for exceptions rather than cloning profiles. Intune also supports reusable settings groups for remote IP ranges, so the "Tier 2 admin subnet" is defined once and referenced by every rule that needs it; change the range in one place and all rules follow.

For hybrid-joined devices that receive both GPO and Intune firewall policy, both rule sets land in the active store. Avoid overlapping profile settings: pick one authority per population and move devices between them explicitly. The MDMWinsOverGP policy only applies to settings in the Policy CSP, not to the Firewall CSP, so it does not resolve overlaps. The Firewall CSP documents its own merge law instead: for profile settings such as firewall state, default inbound action and log settings, a value configured by Group Policy wins over the MDM value, so on hybrid devices a leftover firewall GPO silently overrides your Intune profile.

Step 4: change management

Firewall changes break production faster than most policy changes. A workable process:

1. Request with evidence: which process, port, direction and source, ideally backed by pfirewall.log or 5157 events from firewall logging.
2. Pilot: link or assign to a pilot OU or group first. Intune rings or GPO security filtering both work.
3. Record the prior state: netsh advfirewall export on a reference host, and Backup-GPO for the policy.
4. Promote to broad scope after the pilot period.
5. Review quarterly: rules that have not matched traffic in months are candidates for removal. Temporarily enabling success logging on a sample makes this measurable.

What breaks

• Applications that create their own rules at install (collaboration clients, peer-to-peer update components, developer tools, virtualization and container platforms) stop receiving inbound traffic once local merge is off. Most modern clients work outbound-only; the rest need a central rule.
• Per-user program paths under %LocalAppData% are hard to express centrally. Prefer port- and protocol-based rules scoped to the right remote addresses for those applications.
• Explicit block rules that were meant as "block except" silently override allow rules added later.
• Mixed GPO and Intune policy causes rules to appear that neither team recognises.
• Delivery Optimization peer caching (TCP 7680) and similar features stop working between clients if you do not allow them; decide deliberately.

Verify it

The active store is the truth. Ask it where each rule came from:

Get-NetFirewallRule -PolicyStore ActiveStore |
  Group-Object PolicyStoreSourceType | Select-Object Name, Count

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound -Action Allow -Enabled True |
  Select-Object DisplayName, PolicyStoreSource, Profile |
  Sort-Object PolicyStoreSource

PolicyStoreSource names the GPO or store for each rule, so you can immediately spot an allow rule from a GPO you did not expect. Check the profile settings the same way:

Get-NetFirewallProfile -PolicyStore ActiveStore |
  Select-Object Name, Enabled, DefaultInboundAction, AllowLocalFirewallRules, AllowLocalIPsecRules

AllowLocalFirewallRules should be False on every profile. Complement this with gpresult /h for the GPO side and the Intune per-device policy status for MDM, and track security event 4954 (Group Policy firewall settings applied) from your event forwarding pipeline.

Checklist

• Local rule and connection security rule merge disabled in every profile
• Local installer rules exported, reviewed and replaced with central rules where needed
• Profile settings in one baseline GPO or Intune profile; rules split by role
• No inbound explicit block rules used as "block except"
• Predefined rule groups re-scoped; legacy GPOs audited for rules
• One policy authority (GPO or Intune) per device population
• Active store reviewed by PolicyStoreSource; changes piloted and backed up

A consistent, centrally owned policy is also the foundation for identity-based rules with IPsec domain and server isolation, and for the tiered access model in admin tiering.