Windows VPN Profile Scope: Current User or All Users?
Scope decides where a native Windows VPN profile is stored and who can see it. It does not make the connection a device tunnel or share credentials.
You run a command against a VPN profile, it returns no error, and the connection the user starts behaves exactly as before. Nothing is broken. Windows keeps native VPN profiles in two stores, and you edited the one that is not in play. The same display name can exist in both, which is how a script appears to succeed while the user's connection ignores every change you made.
The fix is not a better script; it is naming the scope before you name the profile.
The symptom, and the two stores
Windows keeps native VPN profiles in a per-user phone book and in a machine-wide all-user phone book. Get-VpnConnection reads the current user's store, and Get-VpnConnection -AllUserConnection reads the machine one.
A profile created with -AllUserConnection appears for every account on the machine and needs an elevated session to create or remove. A profile created without it belongs to the account that ran the command, and another user signing in sees nothing at all. Both can carry the same name, and neither one warns you that the other exists. That is why the symptom looks like a silent failure instead of an error message.
What the scope actually decides
Scope answers two questions and refuses to answer a third:
| Question | Current user | All users |
|---|---|---|
| Who can see the profile | The account that created it | Every account on the machine |
| Elevation to create or remove | Not required | Required |
| Where the profile lives | Per-user phone book | Machine-wide phone book |
| Does it authenticate a device | No | No |
| Does it start before sign-in | No | No, that needs a device tunnel |
The last two rows are the ones people get wrong. An all-user profile is machine-scoped storage, not a machine identity, and it does not by itself make the connection available before anyone signs in. A Windows Always On device tunnel is a separate configuration with its own certificate and profile requirements. Scope is about who can see a profile, not about who the machine is.
Visibility is not authentication
An all-user profile still needs a supported identity and credential arrangement. Making the profile visible to every account does not make every account the same authenticated user, and it does not pool credentials.
If the design needs the tunnel up before sign-in, the answer is a device tunnel rather than a wider profile scope. If the design needs each person to present their own certificate, a per-user profile matches that model better, because a machine-wide profile cannot present a credential that belongs to somebody else.
Deployment and policy ownership
On managed machines, an EMM or a configuration profile can recreate the saved state after your change.
That is not a bug in your script; it is two owners writing the same store. Coordinate the scope with whoever owns the policy, and prefer changing the policy over re-running your command on a schedule. A local fix that competes with policy produces a machine where the profile looks correct until the next sync.
What to record when it breaks
Log three things together: the profile name, the scope you targeted, and the actual connection error.
A route or certificate applied to a profile in the other store will not fix the one the user starts, and the error text will keep pointing at the connection rather than at your edit. After an approved change, reconnect through the intended entry point and inspect the applied routing as well as the saved settings. The profile store answers what is available, while the active connection answers what the device is doing now.
The Microsoft documentation for Add-VpnConnection lists the scope switch next to the parameters it modifies, which is a useful reminder that scope is a creation-time decision rather than a setting you flip later.