Windows Firewall Enable Disable

What the Windows Firewall baseline Worklet does

This Automox Worklet™ enforces a single Windows Firewall state across the Domain, Public, and Private profiles on every Windows endpoint under management. The evaluation script reads the live Enabled property from each of the three profiles using Get-NetFirewallProfile. The remediation script reconciles any mismatch with Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True (or False), so the three profiles always move together as a unified baseline rather than drifting independently.

The desired state is controlled by a single PowerShell variable, $fwEnabled, that lives at the top of both scripts. Set $fwEnabled = $true to keep the firewall on, or $fwEnabled = $false to disable it on endpoints where a sanctioned third-party host firewall has replaced the native stack. The two scripts must agree on the value, because the evaluation phase decides compliance from one $fwEnabled and the remediation phase writes the other. A mismatch will loop the policy.

The change applies immediately to new and existing network connections without a reboot. The Worklet is idempotent: once the Domain, Public, and Private profiles all report Enabled=$fwEnabled, the next evaluation exits 0 and no remediation runs, so the policy can sit on a daily cadence without producing remediation noise on endpoints already at baseline.

Why pin Windows Firewall state at fleet scale

Windows Firewall is the host-based stateful packet filter that gates inbound and outbound traffic on every Windows endpoint. It is the last line of defense when a perimeter firewall is bypassed, when a laptop leaves the corporate network for a hotel Wi-Fi, or when an attacker is already inside attempting lateral movement over SMB, RPC, or WinRM. A single endpoint with the Public profile disabled is an open hole in the segmentation story your network diagram promises. CIS Benchmark control 9.1 and NIST 800-53 SC-7 both call for a host-based firewall enabled on all three profiles, and Cyber Essentials Plus auditors check the Enabled property profile by profile.

Firewall profiles drift independently and quietly. A developer disables the Private profile to debug a local service and forgets to re-enable it, a vendor installer flips Public off during setup to test inbound connections, a Group Policy refresh silently overwrites the Domain state on a single OU. The Worklet calls Get-NetFirewallProfile on every evaluation, checks all three Enabled properties, and reconciles every profile that has diverged from $fwEnabled in a single Set-NetFirewallProfile call, so a misaligned profile is closed before it becomes an audit finding or a lateral-movement path.

How firewall baseline enforcement works

1. Evaluation phase: The Worklet reads the Enabled property of all three profiles by calling (Get-NetFirewallProfile -Name Domain).Enabled, (Get-NetFirewallProfile -Name Public).Enabled, and (Get-NetFirewallProfile -Name Private).Enabled. If $fwEnabled is $true and any profile returns False, the script exits 1 to schedule remediation. If $fwEnabled is $false and any profile returns True, the script also exits 1. When all three profiles already match the desired state, evaluation exits 0 and the policy reports the endpoint compliant.

2. Remediation phase: The Worklet runs Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True when $fwEnabled is $true, or the same cmdlet with -Enabled False when $fwEnabled is $false. The cmdlet touches all three profiles in a single call, so the baseline is applied atomically rather than profile-by-profile. The equivalent command for older shells is netsh advfirewall set allprofiles state on, which is useful as a manual fallback when remoting in to debug. The change is live on the next packet without a reboot.

Windows Firewall baseline requirements

• Windows 10, Windows 11, or Windows Server 2016 and later (workstation and server SKUs both supported)

• PowerShell 5.1 or later, which ships with all supported Windows versions

• The NetSecurity module (built in on every supported Windows release; no install needed)

• Administrative privileges to modify firewall profiles (the Automox agent runs as SYSTEM, which satisfies this)

• Set $fwEnabled to the same value ($true or $false) in both evaluation.ps1 and remediation.ps1; a mismatch will cause the policy to loop

• If a Group Policy Object also writes Windows Firewall state, resolve the conflict at the GPO layer first; GPO will overwrite Set-NetFirewallProfile at the next gpupdate cycle

Expected Windows Firewall state after remediation

When $fwEnabled is $true, every endpoint shows all three profiles enabled after remediation. Verify with Get-NetFirewallProfile | Select-Object Name, Enabled and confirm Domain, Public, and Private all return True. Windows Security Center reports firewall protection as active in the Defender Firewall pane, and Get-Service mpssvc shows the Windows Defender Firewall service in the Running state. Subsequent Automox policy runs report the endpoint compliant without applying remediation, because evaluation finds all three profiles already enabled.

When $fwEnabled is $false, every endpoint shows all three profiles disabled. Windows Security Center will display warnings about reduced protection unless a registered third-party firewall product takes over the host firewall responsibility. This configuration is appropriate only when a sanctioned host firewall replaces the native stack; otherwise leave $fwEnabled set to $true. Capture the policy run identifier and the post-remediation output of Get-NetFirewallProfile as evidence for the next CIS, NIST, or Cyber Essentials Plus audit cycle.