How IPsec errors can drag down RDP performance

I keep seeing IPsec errors on Windows boxes where RDP suddenly turns slow or flaky. The machine boots, the network looks fine, and Remote Desktop sits there dragging its feet or timing out. The same pattern usually shows up in the System event log.

Common error messages:

• “Could not start the IPSEC Services service on Local Computer. Error 2: The system cannot find the file specified.”
• Event ID 7023 with: “The IPSEC Services service terminated with the following error: The system cannot find the file specified.”

Typical symptoms:

• Slow RDP login or a long black screen before the desktop appears. Sessions can take 30–90 seconds to come up.
• Intermittent network failures from the affected host while other machines are fine.
• Services that depend on IPsec fail to start or sit at “starting”.

What I usually see in Services.msc and Event Viewer:

• “IPsec Policy Agent” (PolicyAgent) is stopped or will not start.
• Event Viewer shows repeated 7023 or 7000 entries for PolicyAgent.
• The network icon says connected, but RDP or domain resources do nothing useful.

If that exact error line appears alongside slow RDP, IPsec is the first place I look.

Where it happens

Common environments:

• Terminal servers and VM guests after a snapshot or after the host runs short of resources.
• Machines that had Group Policy changes or third-party security tools installed, then removed.
• Systems moved between networks, or systems with broken local policies.

I have seen this on older and newer Windows builds. It shows up a lot in Server 2003/2008-era notes, but I have also seen it on Windows Server 2016/2019 and Windows 10/11 when the local policy keys are damaged.

Problem cases tend to be hosts using L2TP/IPsec VPN or custom IPsec policies, domain-joined machines with Group Policy pushing IPsec settings, and systems where updates or image changes left the policy store in a bad state.

If RDP only falls apart on one host and PolicyAgent is not running, the network security stack is a likely culprit.

Finding the cause

These are the checks I run.

Check the service state:

sc query PolicyAgent

Healthy output shows STATE : 4 RUNNING. If it is stopped or will not start, Event ID 7023 usually appears with it.

Try starting the service:

net start PolicyAgent

A healthy system reports that the IPsec Policy Agent service started successfully. A broken one usually throws “System error 2 has occurred. The system cannot find the file specified.”

Check whether the policy registry key is there:

reg query "HKLMSOFTWAREPoliciesMicrosoftWindowsIPSecPolicyLocal"

If the policy is present, the command returns subkeys or values. If it is missing, Windows usually says it cannot find the specified registry key or value.

Run system file check:

sfc /scannow

If SFC reports unrepairable files, sort that out first.

The usual cause is a missing or corrupted local IPsec policy store. Microsoft documents that deletion or corruption of the IPSecPolicyLocal registry keys can break service start-up and connectivity. I have also seen the same Error 2 pattern in community write-ups that point back to the same registry issue.

Microsoft: Cannot connect to Internet or domain (IPSec policy store)
Fixing IPSec Error 2 — rebuild policy store

If the registry key is missing, PolicyAgent has nothing to open and exits with Error 2. That is usually the whole mess.

Fix

I take a cautious order here. Back up the registry before changing anything.

Back up HKLMSOFTWAREPoliciesMicrosoftWindowsIPSec to a .reg file, or make a full system restore point.

If HKLMSOFTWAREPoliciesMicrosoftWindowsIPSecPolicyLocal exists and looks corrupted, delete just that Local subkey:

reg delete "HKLMSOFTWAREPoliciesMicrosoftWindowsIPSecPolicyLocal" /f

If the whole IPSec key is missing, leave it alone and move on.

Re-register the policy store DLL:

regsvr32 polstore.dll

Expected output: DllRegisterServer in polstore.dll succeeded.

If that fails, check that polstore.dll exists in System32. If it does not, run sfc /scannow or restore it from a known-good image.

Start the service again:

net start PolicyAgent

If it starts, give it 10–30 seconds and check Event Viewer for new entries.

Check dependent services if RDP is still unhappy:

sc query IKEEXT
sc query RasMan

Reboot if needed. I usually restart the host once PolicyAgent starts cleanly.

This rebuilds the local policy store and restores the DLL registration so Windows can read the policies again.

This fix has cleared slow RDP logins in more than one case I have handled. If the service still refuses to start after this, the next checks are sfc /scannow, restoring polstore.dll from a clean image, and reviewing recent Group Policy changes.