Firewall Configuration

Note: SenseOn detects and responds to malicious and suspicious activity. It is not a host firewall, and it does not enforce firewall rules for you. If you are retiring a third-party endpoint suite alongside a SenseOn deployment, the host firewall that suite provided can be moved onto native Microsoft tooling. This guide shows how to configure Microsoft Defender Firewall with Microsoft Intune, Active Directory Group Policy, or Microsoft Configuration Manager.

This guide applies to Windows 10 22H2 and Windows 11. Product versions, policy names and admin centre navigation change over time, so verify against the linked source before relying on any specific setting.

For the browser half of a third-party suite replacement (SmartScreen and Safe Browsing hardening, URL allow and block lists, extension control), see Browser Security Policy.

What this replaces, and what it does not

Microsoft Defender Firewall with Advanced Security is a genuine replacement for the firewall module of a third-party suite, configured centrally so the domain, private and public profiles behave consistently across the estate. It does not replace a perimeter firewall or a network content filter. This guide covers the host firewall only.

---

Choosing between Intune and Group Policy

Device estate	Recommended control plane	Reasoning
Microsoft Entra joined, Intune enrolled	Intune endpoint security policy	The only option. There is no domain to serve Group Policy from, and reporting is built in.
Domain joined only, no MDM	Group Policy	Mature, immediate, and no licensing dependency. Rules live in the GPO store and cannot be edited locally.
Hybrid joined and co-managed	Pick one authority per workload and stay with it	Both channels will deliver. Split ownership is the single most common cause of unexplained firewall behaviour.
Mixed estate, phased cloud migration	Group Policy for the domain joined population, Intune for the cloud population, with the same baseline expressed in both	Keep the two definitions in a single source document so they do not drift.
Configuration Manager (SCCM) estate	Co-manage to Intune, or use Configuration Items and baselines	Configuration Manager has no dedicated firewall profile. See Configuring with Microsoft Configuration Manager for the options and trade-offs.

Do not manage the same setting from both

Windows evaluates firewall rules from multiple stores. Group Policy rules and MDM rules both apply, and the effective rule set is the union of them. Profile level settings such as the default inbound action behave less predictably when two authorities configure them, and Intune reports a conflict rather than applying a value.

Common failure: A device receives an outbound block default from Group Policy and an allow list of outbound rules from Intune. The rules merge, the default action is contested, and the resulting behaviour differs between reboots and policy refreshes. Decide the owning authority per device group before you configure anything, and record that decision.

For co-managed devices, move the Endpoint Protection workload to Intune in Configuration Manager before you build Intune firewall policy, and remove or unlink the equivalent GPO from the same device population.

---

Preparing for the firewall migration

Decommissioning the incumbent firewall

Third-party firewalls register themselves with Windows as the active firewall and, in doing so, cause Windows Firewall to stand down. Removing the product does not always restore the native firewall cleanly, so treat the following as pre-flight checks rather than assumptions.

1. Confirm the vendor uninstall is complete. Run the vendor removal tool rather than relying on Add or Remove Programs. Leftover Windows Filtering Platform callout drivers will silently drop traffic that the Windows Firewall log shows as allowed.
2. Confirm the firewall service is running. MpsSvc should be set to Automatic and started. The Base Filtering Engine (BFE) must also be running, because MpsSvc depends on it.
3. Confirm Windows Firewall has taken back over. Get-NetFirewallProfile -All | Select-Object Name, Enabled should return True for all three profiles.
4. Check for orphaned local rules. Many suites write local firewall rules during install. Export and review them before you switch local rule merging off, because that action stops them applying.
5. Check network profile classification. Domain joined machines off the corporate network fall into Public. If the baseline for Public is materially stricter than Domain, remote workers feel it first. Verify with Get-NetConnectionProfile.

Sequencing: Deploy the firewall policy before the vendor product is removed where you can. The policy sits inactive while the third-party firewall is registered, then takes effect the moment the incumbent is uninstalled. This avoids a window where the endpoint has no host firewall at all.

Baseline design decisions

Four decisions shape everything that follows. Make them explicitly and write them down.

Decision	Recommendation	Why
Default inbound action	Block on all three profiles	This is the Windows default and the single highest-value control. Inbound blocking with a small allow list stops lateral movement, which is the threat a host firewall actually addresses.
Default outbound action	Allow initially. Move to Block only with a mature application inventory and a tested rule set.	Outbound blocking is where firewall projects fail. It requires an exhaustive allow list covering every line-of-business application, update service and agent. Plan it as a second phase, not a launch requirement.
Local rule merging	Off in production. Leave on during the pilot.	Turning merging off means only centrally defined rules apply, which gives a deterministic estate. Turning it off too early hides the local rules you have not yet catalogued.
Notifications	Off	Prompts encourage users to click through, and standard users cannot create a rule anyway, so the prompt is noise. Keep the signal in the logs instead.

The recommended baseline

This is a sensible starting baseline for a corporate Windows estate. It is deliberately conservative on outbound traffic and deliberately strict on inbound.

Setting	Domain	Private	Public
Firewall state	On	On	On
Inbound connections	Block	Block	Block
Outbound connections	Allow (phase 1)	Allow (phase 1)	Allow (phase 1)
Stealth mode	Enabled	Enabled	Enabled
Display a notification	No	No	No
Allow unicast response to multicast	Yes	Yes	No
Apply local firewall rules	No	No	No
Apply local connection security rules	No	No	No
Log dropped packets	Yes	Yes	Yes
Log successful connections	Pilot only	Pilot only	Pilot only
Log size limit	20,480 KB	20,480 KB	20,480 KB

Stealth mode should stay enabled, which means leaving the "disable stealth mode" style settings unset. The Intune setting names are phrased as negatives, so Block stealth mode set to Not configured is what leaves stealth mode on. The Intune profile mapping gives the exact wording.

---

Configuring the firewall with Microsoft Intune

Where the settings live

Intune splits firewall configuration into two separate profile types. You will normally deploy one of each.

Microsoft Intune admin centre > Endpoint security > Firewall > Create Policy > Platform: Windows > Profile

Profile	Purpose
Windows Firewall	Profile level configuration. Firewall on or off, default actions, stealth mode, notifications, merge behaviour, logging, and the global IPsec and packet queuing settings.
Windows Firewall Rules	The individual allow and block rules. Ports, protocols, applications, services, address ranges and interface types.
Windows Hyper-V Firewall Rules	Rules that apply to Hyper-V containers such as WSL and Windows Subsystem for Android. Only relevant where developers are running WSL.

Creating the Windows Firewall profile

Create the policy, give it a name that identifies the ring and the intent, for example WFW - Baseline - Pilot, then configure the following. The table maps the Intune setting names to the underlying Firewall CSP values so you can cross-check against a device.

Intune setting name	Set to	Firewall CSP node
Turn on Windows Firewall	True	EnableFirewall = true
Block inbound connections	True	DefaultInboundAction = 1
Block outbound connections	Not configured (phase 1)	DefaultOutboundAction = 0
Block stealth mode	Not configured	DisableStealthMode = false
Disable inbound notifications	True	DisableInboundNotifications = true
Block unicast responses to multicast broadcasts	True on Public only	DisableUnicastResponsesToMulticastBroadcast
Ignore all local firewall rules	True (phase 2)	AllowLocalPolicyMerge = false
Ignore connection security rules	True	AllowLocalIpsecPolicyMerge = false
Ignore authorised application firewall rules	True (phase 2)	AuthAppsAllowUserPrefMerge = false
Ignore global port firewall rules	True (phase 2)	GlobalPortsAllowUserPrefMerge = false
Enable shielded mode	Not configured	Shielded = false

These settings appear three times, once each under the Domain, Private and Public network sections. There is also a global section covering stateful FTP, security association idle time, pre-shared key encoding, IPsec exemptions, certificate revocation list verification and packet queuing. Leave those at Not configured unless you have a specific IPsec design.

Shielded mode: Enabling shielded mode blocks all inbound traffic regardless of any allow rule, including your remote management path. It is an incident response control, not a baseline setting. Do not put it in the standard profile.

Logging in Intune. The logging settings (EnableLogDroppedPackets, EnableLogSuccessConnections, LogFilePath, LogMaxFileSize) require Windows 11 22H2 or later. On Windows 10 you need Group Policy, a local script, or a Configuration Service Provider custom profile to set logging. Where the estate is mixed, configure logging by GPO for the Windows 10 population and accept that the Windows 11 population is covered by Intune.

Creating the Windows Firewall Rules profile

Each rules profile supports up to 150 custom rules. Non-conflicting rules across multiple profiles merge on the device, so you can exceed 150 rules in total by splitting them across several profiles. Structure them by purpose rather than filling one profile to capacity.

Suggested profile	Contents
WFW Rules - Core Management	Remote management inbound rules, endpoint agent traffic, patching and software distribution.
WFW Rules - Line of Business	Application specific rules, one profile per major application family.
WFW Rules - Blocks	Explicit deny rules. Keep these separate so they are easy to audit and easy to lift in an emergency.

For each rule, the fields you will normally set are name, direction, action, network types the rule applies to, protocol, local and remote port ranges, local and remote address ranges, application path or package family name, and service name.

Conflicting rules: Where two rules profiles configure the same item differently, both are delivered and the device reports a conflict. This differs from the Windows Firewall profile type, where a conflicting setting is simply not sent. Name rules consistently and keep a single owner per rule family to avoid this.

Reusable settings groups

Rather than repeating the same IP ranges or fully qualified domain names across dozens of rules, define them once.

Endpoint security > Firewall > Reusable settings > Add

A reusable settings group holds remote IP address ranges and domain name definitions with automatic resolution. Reference the group from a rule, and updating the group updates every rule that uses it. Inbound rules that target a name are not natively supported, so an inbound rule targeting a name needs a pre-resolution script that writes the resolved addresses into an IP based rule.

Assignment and conflict behaviour

• Assign to device groups, not user groups. Firewall configuration is a device property.
• Build one policy set per ring and assign each to its own dynamic device group rather than reusing a single policy with exclusions.
• Windows Firewall profiles conflict with each other and with firewall settings delivered through device configuration profiles. When a conflict is detected, the setting is not sent to the device at all, so a conflict means no protection rather than partial protection. Check the per setting status in the policy report after each ring.
• Windows Firewall profiles do not conflict with Windows Firewall Rules profiles, which is why the split exists.

---

Configuring the firewall with Active Directory Group Policy

Creating and linking the GPO

1. Open Group Policy Management on a domain controller or a management workstation with RSAT installed.
2. Right-click the OU containing your pilot computer objects and choose Create a GPO in this domain, and Link it here. Name it something self-describing, for example SEC - Windows Firewall - Baseline - Ring 1.
3. Edit the GPO and navigate to the firewall node:

Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security

There is a second, older node under Administrative Templates that also exposes firewall settings:

Computer Configuration > Policies > Administrative Templates > Network > Network Connections > Windows Defender Firewall

Use one node, not both: The Administrative Templates node is the legacy interface and uses a different profile model (Domain and Standard rather than Domain, Private and Public). Configuring both nodes produces settings that are difficult to reason about. Use the Security Settings node for everything and leave the Administrative Templates node Not Configured.

Profile properties

In the right-hand pane of the Security Settings node, click Windows Defender Firewall Properties. This opens a dialog with four tabs: Domain Profile, Private Profile, Public Profile and IPsec Settings. Configure each of the first three identically except where the baseline differs.

Field	Set to	Notes
Firewall state	On (recommended)	Explicitly set rather than left Not configured, so the setting is enforced and reported.
Inbound connections	Block (default)	"Block all connections" is the stricter option and ignores allow rules. Do not use it in a baseline.
Outbound connections	Allow (default)	Change to Block only in phase 2, and only after the outbound allow list is proven.
Protected network connections	Customise, all adapters ticked	Prevents a user or an installed virtual adapter from sitting outside the firewall.

Under Settings > Customise:

Field	Domain / Private	Public
Display a notification	No	No
Allow unicast response	Yes	No
Rule merging: Apply local firewall rules	No	No
Rule merging: Apply local connection security rules	No	No

Rule merging and local administrator lockout

Setting Apply local firewall rules to No is the control that makes the estate deterministic. With it set to No, rules created locally, including by a local administrator or by an application installer, are stored but never applied. Only rules delivered by the GPO take effect.

This is the correct end state, but it has two consequences worth planning for.

• Application installers that create their own firewall rules appear to succeed and then not work. Every such application needs a rule in the GPO.
• Support staff lose the ability to unblock something quickly on a single machine. Build a documented break-glass path, normally a separate GPO scoped to a security group that support can add a computer object to temporarily.

Logging

On each profile tab, under Logging, click Customise.

Field	Value
Name	%windir%\system32\logfiles\firewall\pfirewall_Domain.log (and _Private, _Public on the other tabs)
Size limit	20,480 KB. The maximum is 32,767 KB.
Log dropped packets	Yes
Log successful connections	Yes during pilot, No in steady state

Permissions: If the log folder does not already exist when the policy applies, logging silently fails. Create the folder and grant Full Control to NT SERVICE\mpssvc on the folder and its files. Deploy this as a startup script or a Configuration Manager step alongside the GPO.

Separate log files per profile are worth the small extra effort. When a laptop is on the wrong network profile, the profile specific log tells you immediately which rule set was in play.

Creating rules in the GPO

Under the same Security Settings node, expand Inbound Rules or Outbound Rules, right-click and choose New Rule. The wizard offers Program, Port, Predefined and Custom rule types.

• Prefer Program or Custom rules scoped to a specific executable over broad Port rules. A port rule opens the port for anything on the machine.
• Use Predefined rules for Windows roles such as File and Printer Sharing, Remote Desktop and Windows Management Instrumentation, because they carry the correct port and service scoping already.
• Scope every inbound rule with a remote address range wherever it is possible. A management rule that only accepts connections from the management subnet is dramatically stronger than the same rule left open.
• Rules delivered by GPO cannot be edited or deleted on the endpoint, which is the intended behaviour.

You can also author rules on a reference machine with PowerShell, export them, and import into the GPO, which is faster than the wizard for large rule sets.

# Export the current rule set from a reference machine
netsh advfirewall export "C:\Temp\firewall-baseline.wfw"

# Import into a GPO from the Group Policy Management Editor:
# right-click "Windows Defender Firewall with Advanced Security" > Import Policy

Import replaces: Importing a policy file into a GPO overwrites the entire firewall configuration in that GPO, including all existing rules. Export the current GPO configuration first.

Precedence, filtering and troubleshooting

• Firewall rules from multiple GPOs are cumulative. All rules from all applied GPOs are evaluated together, so there is no "last GPO wins" behaviour for rules.
• Profile settings such as the default inbound action do follow normal GPO precedence, which means the GPO with the highest link order at the closest OU wins.
• Deny rules always beat allow rules, regardless of which GPO delivered them.
• Use security filtering or a WMI filter to keep servers out of a client baseline. A WMI filter on ProductType = 1 restricts a GPO to client operating systems.
• gpresult /h report.html on an affected endpoint shows which GPOs applied. Get-NetFirewallRule -PolicyStore ActiveStore shows the merged, effective rule set.

---

Configuring with Microsoft Configuration Manager (SCCM)

Configuration Manager (formerly SCCM, now Microsoft Configuration Manager) has no dedicated firewall policy profile of the kind Intune's endpoint security provides. If Configuration Manager is your management plane rather than Intune, there are three realistic routes, in order of preference. The same routes apply to browser policy, covered in Browser Security Policy.

Co-manage and use Intune for these workloads

This is the least effort for the richest policy set, and is the recommended route where devices are co-managed. In the Configuration Manager console, move the Endpoint Protection workload (which carries Windows Firewall) to Intune, then follow the Configuring the firewall with Microsoft Intune section above (and, for browsers, the Intune sections in Browser Security Policy). Both channels will deliver, so keep a single owner per device group and unlink any equivalent GPO from the same population.

Configuration Items and baselines

For estates that must stay on Configuration Manager, express the settings as Configuration Items grouped into a Configuration Baseline, deployed with remediation enabled so drift is corrected on a schedule.

• Firewall profile settings. The built-in Windows Defender Firewall Policies node (Assets and Compliance > Endpoint Protection > Windows Defender Firewall Policies) sets the per-profile state and the default inbound and outbound actions. It requires the Endpoint Protection point site system role, and it covers profile-level settings only, not individual rules.
• Firewall rules. Rules are awkward to express as Configuration Items. The reliable pattern is to author the rule set on a reference machine, export it with netsh advfirewall export, and deploy the .wfw file with a script-based Configuration Item that imports it using netsh advfirewall import. Version the exported file so you can redeploy a known-good baseline.

For browser policy under Configuration Manager, see Deploying browser policy with Configuration Manager.

Deploy Group Policy alongside Configuration Manager

Most Configuration Manager estates are also domain joined. Where that is true, the Group Policy sections are the simplest way to deliver firewall policy, with Configuration Manager used only for software distribution and reporting. This avoids re-expressing rules as Configuration Items.

Which route? Co-management gives you the Intune policy set for the least effort. Configuration Items and baselines keep everything inside Configuration Manager but need scripts for firewall rules. Group Policy is the least work where the estate is domain joined. Pick one owner per setting either way: the rule against managing the same setting from two authorities applies here too.

---

Rule baseline and exception handling

Inbound rule baseline

With inbound blocked by default, the following is a typical minimum allow list for a managed corporate client. Scope each one to the smallest sensible remote address range.

Rule	Scope	Notes
Core Networking (predefined group)	All profiles	DHCP, DNS, IPv6 transition, ICMPv6 neighbour discovery. Breaking these breaks the machine.
Remote Desktop	Domain only, management subnets	Only where RDP to clients is genuinely required. Consider removing entirely.
Windows Management Instrumentation	Domain only, management subnets	Needed by inventory and remote administration tooling.
Remote Assistance / Quick Assist	Domain only	Only if the service desk uses it.
File and Printer Sharing	Domain only, or removed	Client to client SMB is a lateral movement path. Block it unless a business process depends on it.
Endpoint agent management channel	Domain and Private	Check the vendor documentation for whether an inbound rule is needed at all. Most agents are outbound only.
Configuration Manager / remote control	Domain only, site server ranges	Where Configuration Manager is in use.

Highest-value inbound restriction: Blocking inbound SMB, RPC and RDP between clients, while leaving them open from server and management ranges, removes the most commonly abused lateral movement paths in a Windows estate. If you do only one thing with the host firewall, this is the thing.

Outbound rules and the path to outbound blocking

Outbound blocking is worth doing and is frequently attempted too early. A workable sequence is as follows.

1. Instrument. Turn on logging of successful connections across a representative sample of endpoints for two to four weeks, covering month end and any periodic processes.
2. Inventory. Build the allow list from the logs plus the application catalogue. Expect to find agents, update services, licensing check-ins and telemetry that nobody documented.
3. Model. Deploy the outbound allow rules with the default action still set to Allow. Nothing changes for users, and you can confirm the rules match the traffic you expect.
4. Flip a ring. Change the default outbound action to Block for the pilot ring only. Keep the change in its own policy so it can be withdrawn in isolation.
5. Expand. Move ring by ring with a defined soak period between each.

If your goal is stopping command and control traffic rather than general egress control, DNS filtering and proxy egress control usually deliver more for less operational cost than host based outbound blocking.

Running an exception process

Once local rule merging is off, every exception is a central change. Without a process this becomes the bottleneck that stalls the project.

• Standard exceptions get a named rule in the appropriate rules profile or GPO, with an owner and a review date.
• Temporary exceptions go into a clearly named short-lived policy scoped to a specific group, with a diary entry to remove it.
• Break glass is a pre-built policy that relaxes a specific control, unassigned by default, that a named group can assign under change control.
• Review the full rule set at least twice a year. Rules accumulate and nobody removes them unless it is scheduled.

A minimal exception record should capture the application, the direction, the protocol and ports, the remote scope, the business justification, the requester, the approver and the review date.

---

Deployment and rollout

The ring model and audit-first approach below apply to browser policy too. If you are rolling out both at once, run them through the same rings. Browser Security Policy covers the browser-specific audit and monitoring steps.

Ring model

Ring	Population	Soak	Purpose
Ring 0	IT team, 5 to 20 devices	1 week	Catch outright breakage. The people affected can diagnose it themselves.
Ring 1	Volunteers across departments, 5 per cent	2 weeks	Cover the variety of applications and working patterns. Must include remote workers and at least one of every laptop build.
Ring 2	25 to 30 per cent	2 weeks	Load test the exception process, not the technology.
Ring 3	Remainder	Ongoing	Full deployment.

Include at least one device in each ring that is normally off the corporate network, because the Public profile baseline is the one that catches people out.

Audit first, enforce second

For each control, deploy in an observable but non-blocking state before you enforce.

Control	Audit state	Enforced state
Inbound blocking	Already the Windows default, so this is effectively already enforced. Review dropped packet logs before tightening the allow list.	Allow list trimmed to the inbound baseline.
Outbound blocking	Rules deployed, default action still Allow, successful connections logged.	Default action Block.
Local rule merging	Merging still on. Inventory local rules across the estate.	Merging off.

Monitoring and reporting

Intune

• Endpoint security > Firewall > Summary gives the aggregate assignment status. The MDM Firewall status for Windows report shows per device firewall state.
• Reports > Endpoint security > Firewall for detailed device and setting level status.
• Open each policy and check Per setting status. A setting in Conflict is not being applied at all, so treat conflicts as failures rather than warnings.

Group Policy

• gpresult /h or the Group Policy Results wizard for per device confirmation.
• The Microsoft-Windows-Windows Firewall With Advanced Security/Firewall event log records rule and profile changes.
• The pfirewall_*.log files hold the actual traffic decisions. Ship these to your SIEM or endpoint platform rather than reading them on the box.

Troubleshooting

Symptom	Likely cause and check
Policy shows as applied but the firewall is off	A third-party firewall is still registered with Windows as the active firewall, or MpsSvc is stopped. Check Get-NetFirewallProfile -All and the service state.
An application worked in the pilot and broke at enforcement	It relied on a local rule created by its installer. Local rule merging is now off. Add a central rule.
Rules apply on some devices and not others	Ring assignment overlap, or the device is receiving both GPO and Intune firewall policy. Check Get-NetFirewallRule -PolicyStore ActiveStore for the merged set and gpresult for GPO sources.
Logging configured but no log file	The log folder did not exist when policy applied, or NT SERVICE\mpssvc lacks Full Control on it.
Intune setting shows Conflict	Two policies configure the same setting. The setting is not delivered at all. Remove the duplicate assignment.
Remote workers lose connectivity to something after rollout	They are on the Public profile, which has a stricter baseline. Confirm with Get-NetConnectionProfile.

Rollback

Design the rollback before the rollout, and keep each enforcement step in its own policy object so it can be withdrawn without taking the whole baseline with it.

• Intune. Removing an assignment retracts the policy at the next check-in, which can take up to eight hours. For urgency, use a device sync from the admin centre or Company Portal. Some firewall settings do not revert to their prior value on removal, they revert to the Windows default, so document what the prior state was.
• Group Policy. Unlink rather than delete, so the configuration is preserved. Then run gpupdate /force, or wait for the standard refresh interval of 90 minutes plus up to 30 minutes of random offset.
• Emergency local override. Have a documented, approved procedure for a local administrator to run Set-NetFirewallProfile on a single machine, understanding that a policy refresh overwrites it.

Go live checklist

• [ ] Owning control plane decided and recorded per device group, with no overlap between Intune and Group Policy
• [ ] Third-party firewall uninstall verified on a sample, including absence of leftover filtering drivers
• [ ] MpsSvc and BFE running and set to Automatic across the sample
• [ ] All three profiles confirmed enabled with Get-NetFirewallProfile
• [ ] Baseline profile settings deployed and reporting clean, with zero settings in Conflict
• [ ] Inbound allow list agreed, scoped to remote address ranges, and documented with owners
• [ ] Logging configured, log folder created, permissions granted, log files confirmed to be writing
• [ ] Firewall logs forwarded to the SIEM or endpoint platform
• [ ] Break-glass procedure written, tested and communicated to the service desk
• [ ] Exception request process live with a named approver
• [ ] Rollback procedure documented and tested in Ring 0
• [ ] Review date set for the full rule set, no more than six months out

---

Appendix A: verification commands

Firewall state and profiles

# Are all three profiles on, and what are the default actions?
Get-NetFirewallProfile -All |
  Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction,
    AllowLocalFirewallRules, AllowLocalIPsecRules,
    LogAllowed, LogBlocked, LogFileName, LogMaxSizeKilobytes |
  Format-List

# Which network profile is this adapter using right now?
Get-NetConnectionProfile

# Firewall service and its dependency
Get-Service MpsSvc, BFE | Select-Object Name, Status, StartType

Rules and their source store

# The effective, merged rule set
Get-NetFirewallRule -PolicyStore ActiveStore |
  Where-Object Enabled -eq 'True' |
  Select-Object DisplayName, Direction, Action, Profile |
  Sort-Object Direction, DisplayName

# Only rules delivered by Group Policy
Get-NetFirewallRule -PolicyStore RSOP

# Locally defined rules, which will not apply once merging is off
Get-NetFirewallRule -PolicyStore PersistentStore |
  Select-Object DisplayName, Direction, Action, Enabled

# Resolve a rule to its ports and addresses
Get-NetFirewallRule -DisplayName 'Remote Desktop*' |
  ForEach-Object {
    [PSCustomObject]@{
      Name    = $_.DisplayName
      Ports   = ($_ | Get-NetFirewallPortFilter).LocalPort -join ','
      Remote  = ($_ | Get-NetFirewallAddressFilter).RemoteAddress -join ','
      Program = ($_ | Get-NetFirewallApplicationFilter).Program
    }
  }

Policy delivery

# Which GPOs applied to this machine
gpresult /h C:\Temp\gpo-report.html /f

# Force a Group Policy refresh
gpupdate /force

# Read the MDM firewall configuration from the registry
Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\PolicyManager\current\device\Firewall' -Recurse -ErrorAction SilentlyContinue

Reading the firewall log

# Last 50 dropped packets from the domain profile log
Get-Content "$env:windir\system32\logfiles\firewall\pfirewall_Domain.log" -Tail 50 |
  Where-Object { $_ -match ' DROP ' }

# Top blocked destination ports over the whole log
Get-Content "$env:windir\system32\logfiles\firewall\pfirewall_Domain.log" |
  Where-Object { $_ -match ' DROP ' } |
  ForEach-Object { ($_ -split '\s+')[7] } |
  Group-Object | Sort-Object Count -Descending | Select-Object -First 20

---

Appendix B: registry and CSP reference

Component	Location
Firewall CSP (MDM)	./Vendor/MSFT/Firewall/MdmStore/DomainProfile/ (also PrivateProfile and PublicProfile)
Firewall CSP rules	./Vendor/MSFT/Firewall/MdmStore/FirewallRules/
Group Policy Central Store	%systemroot%\sysvol\domain\policies\PolicyDefinitions
Firewall logs (recommended)	%windir%\system32\logfiles\firewall\pfirewall_Domain.log (also _Private and _Public)

---

Related pages

• Browser Security Policy for the browser half of a third-party suite replacement.
• USB Controls for restricting removable media with Group Policy.
• Deployment with Intune (Windows) for deploying the SenseOn Universal Sensor through the same admin centre.

Sources

All URLs verified on 17 August 2026.

Windows Defender Firewall

• Firewall policy for endpoint security in Intune
• Firewall profile settings for Intune
• Firewall CSP
• Configure Windows Firewall logging
• Configure Windows Firewall rules