How to manage Windows Firewall using Group Policy

What is Windows Firewall, and why manage it through Group Policy?

Windows Defender Firewall, released originally as Windows Firewall and renamed in Windows 10 version 1709, is the host-based firewall built into every supported Windows desktop and Windows Server edition. It filters inbound and outbound network traffic using a stateful rule set, with separate configurations applied to the Domain, Private, and Public network profiles depending on the connection the operating system detects.

Configuring the firewall one machine at a time isn't scalable, and local settings tend to drift out of compliance over time. Using Group Policy Objects (GPOs), you can define the firewall configuration once in the Group Policy Management Console (GPMC), link the GPO to the appropriate OU, site, or domain, and every computer in scope receives the same enforced configuration at the next refresh interval. Rule changes propagate through normal Group Policy replication, and users without local administrator rights cannot override what the GPO enforces.

Where Windows Firewall settings live in Group Policy

There are two relevant nodes in the Group Policy Management Editor. For any new deployment, use the first one.

1. Windows Firewall with Advanced Security

This is the modern node. It exposes profile-level settings, inbound and outbound rules, connection security rules, and logging configuration. The hierarchy is the same as what wf.msc shows on the local machine. Navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Windows Firewall with Advanced Security.

2. Windows Defender Firewall (Administrative Templates)

This older node controls the firewall through legacy Administrative Template settings, split into Domain Profile and Standard Profile subfolders. It exists for backwards compatibility and is less granular. Avoid mixing the two nodes in the same GPO, as settings from each are evaluated independently and can produce confusing results. Navigate to Computer Configuration > Policies > Administrative Templates > Network > Network Connections > Windows Defender Firewall.

Managing Windows firewall using Group Policy

To create, edit, or link GPOs, you must have appropriate permissions in AD—such as membership in Domain Admins or Group Policy Creator Owners—or delegated rights on the target OU/domain (create, edit, and link GPOs). You also need access to the GPMC on a domain-joined machine.

Common troubleshooting issues

When a firewall rule doesn't behave as expected, the issue is usually one of policy precedence, scope, or merge behavior. Use gpresult, wf.msc, and the Application event log to narrow down the cause before making changes.

1. GPO is linked but rules are missing on the client.

   The computer object is likely in a different OU, or a higher-precedence GPO is overriding the rules. Run gpresult /h report.html and check the Resultant Set of Policy to see which GPO won, then adjust link scope or precedence accordingly.

2. Rule appears in wf.msc but traffic is still blocked.

   A higher-precedence rule is blocking the same traffic, or the rule scope, such as remote IP or profile, excludes the client. Check rule order, since explicit Block rules always take precedence over Allow rules regardless of where they sit in the list.

3. Local admins report the firewall toggle is grayed out, with the message "For your security, some settings are controlled by Group Policy."

   This is expected behavior. GPO enforcement disables local override by design. Document this for end users so they know to contact IT rather than fixing it.

4. gpupdate /force starts failing after the firewall GPO applies.

   The firewall is now blocking inbound RPC, SMB, or WMI traffic from the domain controller or management hosts. Add inbound Allow rules for Core Networking, File and Printer Sharing, and Remote Administration scoped to your DCs and management subnets (see Step 4).

5. Connection security rules (IPsec) do not apply on some clients.

   The policy is applying to legacy clients that don't support all IPsec proposals in the rule. Lower the IPsec proposal version, or scope the rule to only the OS versions known to support it.

6. Firewall service (mpssvc) is stopped on the client.

   The service has been disabled by malware or by another policy. Re-enable the Windows Defender Firewall service through a separate Services GPO, then investigate why it was stopped in the first place.

7. Inbound rules merge from local policy when they should not.

   Rule merging is enabled in the profile properties. In Windows Defender Firewall Properties > [profile] > Settings, set Apply local firewall rules to No so only your GPO-defined rules apply.

Disabling Windows Firewall through Group Policy

In most cases, you should leave the firewall on and use rules to permit the traffic you need. If a specific scenario requires the firewall off (for example, a lab segment, a security appliance using its own host firewall, or temporary troubleshooting), you can do this through GPO rather than touching each machine.

In the same GPO under Windows Firewall with Advanced Security > Windows Defender Firewall Properties, set Firewall state to Off for the relevant profile and click OK. Link the GPO only to the OU that should have the firewall disabled, and document the exception. Do not disable the firewall domain-wide as a workaround for a misconfigured rule; fix the rule instead.

Best practices for firewall GPO design

A few patterns worth following from the start:

• Separate baseline from exceptions. One GPO defines the baseline state and core rules. Separate, narrowly scoped GPOs add exceptions for specific server roles. This makes the link audit far easier than packing every rule into one large GPO.
• Use security filtering for role-specific rules. Linking a SQL-specific firewall GPO to the entire Servers OU and filtering by a SQL Servers security group is cleaner than maintaining a separate sub-OU for every role.
• Set "Apply local firewall rules" to No for production endpoints. Letting local rules merge with GPO rules makes it harder to reason about what is actually allowed.
• Be deliberate about outbound filtering. Most environments run with outbound traffic in default-allow mode and only block specific high-risk ports (SMB 445 outbound to the internet, RDP 3389 outbound, common C2 ports). Switching to default-deny outbound is genuinely useful for limiting command-and-control callbacks and data exfiltration, but it requires testing every legitimate application and ongoing maintenance as software updates change network behavior. Pick a stance and document it.
• Test in a scoped OU first. Link any new firewall GPO to a small test OU containing one workstation and one server, run gpupdate /force and gpresult /r to confirm it applied, and let it soak for at least 48 hours of clean operation before linking it to production OUs. Confirm management agents, backup, and line-of-business apps still work.
• Document the rule purpose in the description. The Description field is the only place a future admin will know why a rule exists. Include the requesting team, the application, and the date the rule was added.

Limitations of native GPO firewall management

Native GPO firewall management works, but it has friction at scale:

• No bulk linking. Linking the same firewall GPO to 30 OUs is 30 right-click operations in the GPMC.
• No version comparison built in. Comparing two versions of a firewall GPO to see what changed requires manual gpresult /h exports or a third-party tool.
• No scoped delegation for firewall-only changes. Granting a help desk technician the right to edit firewall rules in one GPO without granting broader rights is awkward; the native model delegates GPO editing as a whole.
• No scheduled or audit-ready reporting. GPO scope, settings, and link reports are manual exports, with no built-in scheduling to deliver them to a compliance inbox.
• No central console across forests. Multi-forest environments require switching contexts in the GPMC for each forest.
• Stale rules accumulate. Without a regular review process, rules added for a project that ended two years ago tend to stay forever.

How ADManager Plus simplifies GPO management at scale

Once your firewall GPO is configured in the GPMC, ManageEngine ADManager Plus extends what you can do with it across the rest of the domain through a single web console:

• Bulk linking across OUs: Link a firewall baseline GPO to multiple workstation or server-tier OUs in a single action, instead of right-clicking each container in the GPMC.
• On-demand policy refresh: Force an immediate GPO refresh on selected computers when an emergency firewall rule (a new Block for a disclosed C2 address, an Allow for a business-critical application) needs to apply before the default 90-minute interval.
• Link order management: Adjust GPO precedence so role-specific firewall policies (SQL servers, RDS hosts, jump boxes) layer cleanly over the workstation or server baseline rather than fighting it.
• Cross-domain rule reuse: Copy or merge firewall GPOs to reuse the same inbound and outbound rule set across domains without rebuilding rules by hand.
• GPO version comparison: Compare two versions of a firewall GPO side by side to see exactly which rules were added, modified, or removed. This is the fastest way to identify what changed when a recent edit broke management traffic.
• Audit unauthorized GPO changes: Identify all containers linked to the Firewall GPO, flag unauthorized 'Block Inheritance' settings that bypass security baselines, and verify OU alignment with the approved configuration standard.
• Delegated help desk access: Technicians can add or remove firewall exceptions through scoped role-based delegation without domain admin rights, and every change moves through an audit-logged workflow before it applies to AD.
• Comprehensive visibility: 200+ prebuilt reports across users, computers, GPOs, and permissions keep firewall changes cross-referenced with the rest of the AD environment.