Fix FWP_E_BUILTIN_OBJECT (0x80320017) in Windows Firewall

The 30-Second Fix: Disable the Rule Instead

You're getting FWP_E_BUILTIN_OBJECT (0x80320017) because you're trying to delete a rule that's baked into Windows. The firewall service literally won't let you remove it — it's part of the operating system's core configuration. Think of it like trying to delete the "Program Files" folder with a right-click. Not gonna happen.

The quickest way around this: disable the rule. It's the same end result — the rule stops blocking or allowing traffic — but doesn't trigger the error.

1. Open Windows Defender Firewall with Advanced Security (type wf.msc in Run or Start menu).
2. Go to Inbound Rules or Outbound Rules depending on where your rule lives.
3. Find the rule that's causing the error. It'll usually have a gray icon or say "Built-in" in the description.
4. Right-click it and select Disable Rule.

That's it. The rule stops working. No error. You're done in 30 seconds.

Common scenario: you're trying to delete a Core Networking rule or a default Windows Service Hardening rule. Those are all built-in. Disable 'em and move on.

The 5-Minute Fix: Override with a Higher-Priority Rule

If disabling the rule isn't enough — maybe you need it to allow traffic that it's blocking, or block traffic it's allowing — you can create a new rule that overrides the built-in one. Windows Firewall processes rules by priority: more specific rules win over general ones, and explicit allow/block overrides the default.

Here's how to override a built-in rule that's blocking RDP (port 3389), for example:

1. In Windows Defender Firewall with Advanced Security, right-click Inbound Rules and select New Rule...
2. Choose Port and click Next.
3. Select TCP, then Specific local ports and enter 3389. Click Next.
4. Select Allow the connection. Click Next.
5. Check all profiles (Domain, Private, Public) unless you want to scope it. Click Next.
6. Give it a name like "Override-RDP-Allow" and click Finish.

Because your new rule is more specific (targeting a single port) and explicitly allows, it'll take precedence over the built-in rule that's blocking it. The built-in rule stays in the list but won't interfere.

If you need to block a built-in allow rule, create a block rule with a higher priority. Same logic works.

The 15+ Minute Fix: Use PowerShell to Remove the Rule Anyway

Alright, you really want it gone. I get it — sometimes you need to clean up Group Policy leftovers or script a deployment where the built-in rule just gets in the way. There's a trick: you can't delete it via the GUI, but you can use NETSH or PowerShell to force-remove it. But be careful — removing a built-in rule can break system services or expose ports you didn't mean to open.

First, identify the exact rule name. Open PowerShell as Administrator and run:

netsh advfirewall firewall show rule name=all verbose | findstr /i "Rule Name:.*YourRuleName"

Or list all built-in rules with:

Get-NetFirewallRule | Where-Object {$_.BuiltIn -eq $true} | Select-Object Name, DisplayName

Once you have the exact name, try to delete it with:

netsh advfirewall firewall delete rule name="Core Networking - DNS (UDP-Out)"

This might work depending on the rule — some built-in rules in Windows 10/11 and Server 2019/2022 are actually removable with NETSH if they're not pinned to a service. But more often than not, you'll get the same 0x80320017 error again.

If that fails, the nuclear option: disable the firewall service or the rule's associated service. For example, if a built-in rule belongs to the Windows Time Service or Remote Desktop Services, stopping that service will deactivate the rule. But this can break functionality — only do this if you know exactly what you're disabling.

Alternatively, you can export the firewall policy to an XML file, strip out the offending rule, and re-import. Here's the command chain:

netsh advfirewall export "C:\backup-firewall.wfw"
netsh advfirewall import "C:\modified-firewall.wfw"

But honestly? This is overkill for 99% of cases. Stick to disabling or overriding rules. The built-in rules exist for a reason — Windows relies on them for secure out-of-box behavior.

One last thing: if you're dealing with a domain-joined machine and the rule was pushed via Group Policy, you can't remove it locally. Talk to your domain admin to modify the GPO. That's a whole other rabbit hole.