Script an Azure P2S VPN Profile for Every Windows User

Handing out an Azure point-to-site package works for five laptops and falls apart at fifty. The scripted path has two traps that each cost an afternoon: a parameter error that reads like a certificate failure, and a route the connection never installs even when everything else is right. Neither one is fixed by downloading the client package again. Work the checks below in order and stop at the first one that fails.

I keep the order fixed because every step assumes the previous one is true.

1. Fix the profile scope before the first device

An all-user profile lives on the machine and appears in every session. A per-user profile follows one account and keeps its credentials in that account's context. Choose one and stay with it, because a machine carrying both shows two entries with the same name, and users connect to whichever one appears first. Changing scope later means removing the old profile first rather than editing it in place.

All-user profiles suit shared and kiosk devices where nobody signs in with a personal account. They are the wrong default when the certificate is issued per person, since a machine-wide profile cannot present a credential that belongs to somebody else. Write the choice into the deployment record before the second laptop exists.

2. Pass switches as switches

Add-VpnConnection takes switch parameters that are either present or absent. Passing $true to them raises an EapConfigXmlStream error, which is why so many threads about this end up inspecting certificate chains that were never the problem.

Add-VpnConnection -Name "Contoso P2S" `
  -ServerAddress "azuregateway-00000000-0000-0000-0000-000000000000.cloudapp.net" `
  -AllUserConnection -UseWinLogonCredential -RememberCredential `
  -TunnelType Automatic -EncryptionLevel Required -AuthenticationMethod MSChapv2

The gateway address above is illustrative; take the real one from the downloaded package and keep it quoted. -AllUserConnection requires an elevated session, and the profile it creates is machine-scoped even though you ran the command as an administrator. Read the parameter set with Get-Help Add-VpnConnection -Parameter * before you bolt on more switches.

3. Add the route the adapter does not add

The point-to-site adapter installs a route for the client address pool and nothing else.

A virtual network prefix outside that pool stays unreachable while the tunnel still reports Connected, which is the most confusing failure in this workflow. Add the route explicitly after the connection succeeds, and point it at the interface address the adapter received rather than at the public gateway name. That address comes from ipconfig after connecting, and it changes between sessions.

route add 10.0.0.0 mask 255.255.0.0 10.0.1.5
route print -4 | findstr /c:"10.0.0.0"

Delete the route on disconnect so a stale next hop cannot blackhole traffic later. Treat the command as a documented local deviation: if a future client release adds the route itself, your line becomes a duplicate competing with the package's own next hop.

4. Verify as a standard user

An administrator session hides scope mistakes, because elevation sometimes supplies a credential the real user would not have.

Sign in as a non-administrator, connect through the profile, and test one private service instead of the public internet. Confirm the profile appears in Get-VpnConnection -AllUserConnection, that the state reaches Connected, and that your added route points at the current adapter address. Then sleep the machine, wake it, and compare ipconfig again.

5. Remove a bad rollout cleanly

Remove-VpnConnection with -AllUserConnection and -Force deletes the machine-wide profile. Force matters because a connected profile otherwise refuses removal, and a half-removed profile is harder to diagnose than a clean reinstall.

Keep the profile name, gateway address and added routes in the deployment notes. Those three values are what a help-desk call needs before anyone opens a ticket, and they are also what the next script needs when the gateway address changes. Add the client package version to the same note, because the route behaviour belongs to that package rather than to Windows.