Removing a Windows VPN Profile Doesn't Revoke Access

You delete the connection from Windows Settings, reopen the list, and it is back. Or it is gone from Settings but still answers to PowerShell. Or you uninstalled the VPN client and the entry never left. All three come from one bad assumption: that a Windows VPN profile is part of the VPN software.

It is not. A profile is a connection record in a phonebook file. Removing it deletes that record, in one scope, from one store. The client, its certificates and the gateway's trust in your credential stay exactly where they were.

What Remove-VpnConnection Actually Deletes

Native profiles live in rasphone.pbk: one phonebook under each user profile, one machine-wide under ProgramData. Get-VpnConnection lists the per-user entries; adding -AllUserConnection lists the machine-wide ones. The same name can exist in both lists, and the two records are separate objects.

Remove-VpnConnection -Name "Old Office" -Force deletes the matching per-user record. The same command with -AllUserConnection deletes the machine-wide record and needs an elevated shell. Either way the cmdlet touches only that record: no uninstall, no certificate cleanup, no message to the server. The Remove-VpnConnection reference lists the parameters, and both cmdlets support -WhatIf.

So the question before you run anything is not how to delete a VPN profile. It is which of the two records you are looking at. A preview answers it in one line:

Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
Remove-VpnConnection -Name "Old Office" -AllUserConnection -WhatIf

If the preview reports that nothing matches, you are in the wrong scope and the other command will find the entry. If it names the target, you have the right one.

Why the Entry Comes Back After You Delete It

A profile that reappears within minutes was never yours to delete. On a managed laptop the connection usually arrives from a deployment: an Intune or Group Policy VPN configuration, a CMAK package pushed by the network team, or a logon script. Delete the record and the next policy refresh writes it back.

The tell is timing. A managed profile returns on a refresh cycle, not at the next reboot, and it returns with the same server address and authentication method you just removed. A profile you added by hand stays gone.

Fix that at the source: get the assignment removed from the device or the user, then delete the local record. If you cannot, treat the entry as a managed object and leave it alone rather than scheduling a removal that keeps losing.

Uninstalling the Client Is a Different Job

Third-party clients keep their own stores. Cisco Secure Client, GlobalProtect, OpenVPN GUI and the WireGuard tunnel service each hold connection data outside the Windows phonebook. Removing the native entry leaves all of it untouched, and uninstalling the app can leave the native entry behind because the profile was imported separately.

Imports are the usual trap. If you added the connection from a .pbk, a .cmpbk or a downloaded configuration file, deleting that file does not delete the record it created, and opening the file again recreates it. Remove the entry first, delete the file second, then connect and disconnect once to confirm nothing came back.

Removal Is Not Revocation

If you are deleting the profile because a laptop was lost, a machine is shared or a configuration file leaked, local removal is close to cosmetic. The gateway still trusts the certificate or pre-shared key until the operator revokes it. Deleting the record stops this machine from starting a new connection; it does not stop a copy of the credential from connecting elsewhere.

Do the revocation on the side that grants access: pull the certificate from the trusted list, disable the account, rotate the key. Then clean the local profile. Reverse the order and you end up with a machine that has no profile and a credential that still works.

A Four-Step Check Before You Call It Done

The whole sequence takes about a minute and catches nearly every wrong-scope removal:

1. List both scopes and write down the exact name and server address.
2. Run the removal with -WhatIf against the scope that matched.
3. Run it again without -WhatIf, elevated if the entry is all-user.
4. Re-list both scopes, reopen Settings, and confirm your other connections still work.

If step 4 still shows the entry, the removal quietly targeted the other scope. If the entry returns after a while, you are looking at a deployment. If Settings still shows it while both cmdlet lists are empty, close and reopen the page, which caches its list longer than the phonebook keeps the record.

Next: decide whether the entry was a local leftover or a managed object. A leftover is safe to delete once and forget. A managed object needs the assignment changed first, or your removal is just a race you will lose. And if the real goal was cutting off access, the gateway change matters far more than anything you do to the profile.