Which Phone Book Does a SYSTEM Task Search for VPN Profiles?

Your VPN profile is right there in Settings, and the scheduled task still reports that it cannot find the connection. Nothing is corrupted: the native Windows VPN store is per-user unless the profile was created as an all-user one, and a task runs as whatever account its principal names. The task is usually reading a phone book that never held your profile. Two commands and one task setting are enough to prove that, and they are worth running before anyone rebuilds the connection.

Two Stores Hold the Same Profile Name

A native Windows VPN profile lives in the store of the account that created it. The global store is a different phone book, populated only when the profile is created with the all-user switch in an elevated session. Both can hold a profile with the same name, and neither is a view of the other.

Read both stores from the same session and compare the names they return. The switch selects the global store, and reading it generally requires an elevated session:

Get-VpnConnection | Select-Object Name, ServerAddress, TunnelType
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress, TunnelType

If the first command lists the profile and the second does not, no credential change will help a task running under another account, because membership is the problem rather than authentication. If both list it, the store is not the cause and the next section applies. That single comparison closes half of these tickets. Record which store answered, and under which account you ran the check, because the answer is meaningless without both facts.

Read the Task's Principal Before Its Credentials

Open the task and read the principal, because it tells you which store the task can see. A task set to run as SYSTEM is not your account with extra rights: it has its own profile and no access to the per-user phone book you created while signed in. A service account behaves in exactly the same way.

The run-whether-logged-on-or-not option changes this too, since the task then has no interactive session whose credentials it could borrow. Have the action write whoami into a file and read the answer instead of assuming it.

Diagnostics from your own terminal say nothing about this problem, because they show what your account sees. Run the comparison under the task's identity through whatever approved process you have for that. Output pasted from an administrator console is a different dataset, not a more privileged one. If no such process exists, the task has to log the answer itself, which is what the last section sets up.

Finding the Profile Is Not Signing In

An all-user profile makes the configuration visible more broadly. It does not carry the saved password from the account that created it, and it does not hand another account the private key stored in your user profile. Visibility and usable credentials are two separate tests, and passing the first says nothing about the second.

If the task now finds the profile and fails at authentication, that is progress and the stage belongs in the record. Move the certificate to the machine store, or supply the secret through the deployment's own mechanism, instead of recreating the connection name again. Recreating it produces the same failure with a newer timestamp. Microsoft documents the two scopes that the cmdlet switch selects between.

Noninteractive challenges are the trap behind that stage. A PIN prompt or a one-time code cannot be answered by a task with no desktop, so a profile that dials perfectly by hand can be unusable under automation.

Four Fields the Task Record Needs

Keep the values that decide the outcome together in one place, because three of them are usually left implicit. The record needs four lines:

• Action path: the script or executable the task runs, not a shortcut that resolves differently for another account.
• Profile name: the exact string, since two stores can hold the same name pointing at different servers.
• Principal: the account the task runs as, and whether it has an interactive session.
• Authentication method: what that principal can actually complete, such as a machine-store certificate rather than a key in your user profile.

Those four lines answer the question the ticket is really asking, which is which configuration the automation used. They also survive the next rebuild of the task, when the original author is not around to explain why the name mattered. Without them the same failure returns after the next deployment and costs the same hours again.

Locate the Stage the Task Reached

Instrument the action instead of guessing from the last-run result. A short wrapper records the identity, the store it can see and the dial outcome in one place:

whoami
Get-VpnConnection -AllUserConnection | Select-Object Name, ServerAddress
rasdial "Office"
schtasks /query /tn "VPN Connect" /v /fo LIST

The dial command prints its own error, which is usually clearer than a generic task failure. The query returns the principal and the last result code side by side, so identity and outcome are visible in one view. Those two facts decide whether the next step is a store change or a credential change.

Finally, separate a task that connects after a user signs in from a device tunnel or a supported pre-logon workflow. Sharing one profile is not a design for either, and the principal field is what tells you which of the three you have built. If connectivity has to exist before logon, the per-user profile store is the wrong layer to be fixing.