Why Get-VpnConnection Misses Some Windows VPN Profiles

Type Get-VpnConnection, get nothing back, and the investigation usually stops there. That empty output gets read as proof the machine has no VPN at all, even while a tunnel is carrying traffic. The command is fine; the assumption about what it inventories is not. It reads one native store in one scope, and it knows nothing about clients that keep their own profiles.

One native store per call

Start with the bare call, which targets the profiles that belong to the signed-in account. This is the invocation most people run first:

Get-VpnConnection

Every returned object carries Name, ServerAddress, TunnelType and ConnectionStatus, and those four fields are enough to tell two entries apart in a ticket. A profile can sit disconnected for months and still be listed, because the object describes stored configuration rather than live traffic. An empty result here means the per-user store held nothing for that account. That is a much smaller claim than the one people usually read into it.

The all-user phone book needs its own query

Profiles that serve every account live in a separate list, and the default call never reads it. You request that store explicitly:

Get-VpnConnection -AllUserConnection

When the session lacks the rights, expect an access-denied error rather than an empty result, and treat the two outcomes differently: one means you may not look, the other means nothing is stored. Note the scope next to each name while the output is in front of you, because a later command will not remind you which store it queried. Permissions are the usual reason a colleague sees a profile that you cannot. The parameter sets are documented on the Get-VpnConnection reference page, including which switches belong to which set.

Same name, two different stores

A profile name is unique inside its store, not across the machine, so the per-user and all-user lists can each hold a profile called Office. The two entries may point at different servers, use different tunnel types, and carry different credentials. Only one of them is the entry the user double-clicks. Record the scope before you touch either one.

Deleting the copy that nobody launches looks harmless in a change window. It turns into a support call when the user's shortcut stops working.

Clients that never touch the native list

An OpenVPN or WireGuard profile imported into a vendor client lives in that client's own configuration, so it never becomes a native Windows entry. The client runs its own service, keeps its own list, and passes traffic through its own adapter. None of that is what the cmdlet reports, and no scope switch will make it appear. A machine can have three working tunnels and an empty native list.

When you need the adapter view instead, query the adapters. Vendor interfaces name themselves, so match a fragment rather than an exact string:

Get-NetAdapter | Where-Object InterfaceDescription -match 'WireGuard|OpenVPN|TAP'

Native profiles created by hand end up in the phone book file under the user profile, and the all-user equivalents sit in the machine-wide copy. That is why copying one user's profile store to another account rarely reproduces the same list. The file explains where a stray native connection came from. It says nothing about a vendor client's store.

What to capture before removing a profile

The cheap insurance is a five-field note: name, scope, server address, status, and the exact error text from the user's attempt. Add the client they actually launch, because that detail decides whether the native entry matters at all. Without it, a correct deletion still looks like the cause of the next failure. Keep the note in the ticket rather than in a chat window.

Removal is one command, and it deletes configuration rather than disabling it. Run it only after that note exists:

Remove-VpnConnection -Name "Office" -Force

Add -AllUserConnection when the target sits in the all-user store, and keep the approved configuration source somewhere else first. Then reconnect once and read the route table, because a listing proves only that configuration is saved. Whether traffic reaches the server is a separate question that no amount of Get-VpnConnection output will answer. If the user still fails after a clean re-add, the profile was never the problem.