ERROR_IPSEC_QM_POLICY_PENDING_DELETION (0x32DF) fix

Quick answer

netsh ipsec static delete policy name="YourPolicyName"

What's actually happening here

Windows IPsec tracks quick mode policies (also called QM policies) as part of its security association database. When you remove a policy—either manually or via Group Policy—Windows marks it as pending deletion instead of deleting it immediately. This is a safety mechanism: if the policy is actively being used for active IPsec tunnels, Windows waits until those connections close before purging it.

The problem is, sometimes that cleanup never happens. The policy sits in limbo, and you can't create a new policy with the same name or modify the existing one. Windows 10 22H2 and Windows Server 2022 are the most common culprits—especially after a failed Group Policy refresh or when the IPsec service was restarted mid-operation.

You'll see error 0x000032DF in the event log, or when running netsh ipsec static show policy it lists the policy with Status: Pending Deletion.

Fix steps

1. Identify the stuck policy
   Open an admin command prompt and run:

   netsh ipsec static show policy all

   Look for the policy showing Status: Pending Deletion. Write down its exact name.
2. Force delete it
   Run:

   netsh ipsec static delete policy name="YourPolicyName"

   This tells Windows to skip the pending deletion state and remove it immediately. The reason this works: delete policy bypasses the graceful shutdown that the GUI or Group Policy engine uses.
3. Refresh group policy
   Even if you're not using Group Policy, force a refresh to clear cached state:

   gpupdate /force

4. Restart the IPsec service (only if step 2 returns "The system cannot find the file specified")
   This means the policy is already gone from the store but the reference is stuck in memory. Run:

   net stop PolicyAgent && net start PolicyAgent

   This kills the IPsec service and restarts it—it'll rebuild its list from scratch.
5. Reboot
   If nothing else works, a full reboot clears the pending deletion flag. It's brute force, but it works because the IPsec driver resets its state table on boot.

Alternative fixes if the main one fails

• Check for locked handles
  Run handle64.exe -a -p PolicyAgent.exe (from Sysinternals) to see if another process has a handle open on the policy. If you see anything like lsass.exe holding a reference, that's normal—it's the security subsystem. If it's a third-party VPN client, kill that process first.
• Remove via registry (advanced)
  Navigate to HKLM\SYSTEM\CurrentControlSet\Services\PolicyAgent\Policy\Local\QuickMode. Find the subkey matching your policy name and delete it. Backup the key first. After deletion, restart the PolicyAgent service. This is the nuclear option—only do this if the netsh commands fail, because you can break IPsec for all other policies.
• Disable and re-enable IPsec
  Run netsh ipsec static set policy name="YourPolicyName" assign=n to unassign it, then re-assign it. Sometimes the pending deletion flag only clears when the policy is no longer assigned to any network.

Prevention tip

Always remove IPsec policies using netsh ipsec static delete policy or the Group Policy Management Console—never delete the registry keys directly while the service is running. If you're scripting policy changes, add a timeout /t 5 between delete and create operations to let the service process the pending state.

Also, if you're using Windows Server with the IPsec Task Offload feature enabled on your NIC, disable it in the adapter properties. That offload can cause the policy pending deletion flag to stick because the hardware holds references to the old security associations.