Why users turn off Always On and the profile keeps it off

A user unticks Connect automatically, and the profile stops connecting. Months later the deployment team ships an updated profile with the same name, expects the trigger to return, and it does not. The reason is that the choice was never only in the profile: Windows recorded the user's decision against that profile name in its own state, and a reinstall does not clear it. The profile file is only half of the configuration.

What the checkbox actually writes

Clearing the automatic connection option is a per-device decision stored outside the profile XML. Microsoft documents it as a list of profile names whose automatic trigger is disabled, which is why the setting survives the profile being removed and re-added.

That design makes sense from the user's side. Someone on a metered connection who turns off automatic connection does not expect the next policy refresh to switch it back on silently.

It also means the profile name is an identity, not a label. Two profiles with the same name are the same entry as far as that list is concerned, and a rename creates a new identity with no stored preference at all.

Why reinstalling the profile does not reset it

Deleting a VPN connection and adding it back from an updated file removes and recreates the profile object. It does not remove the record of the user's decision, because that record is keyed by name rather than by the profile's internal identifier.

So the update arrives, the profile is present and correctly configured, and the trigger still does not fire. Nothing in the profile explains it, which is why this gets escalated as a broken deployment.

The same behaviour can be used deliberately: keep the profile name stable when the update is meant to preserve the same connection, and change it only when you intend a fresh start. Renaming to escape a stored preference works, and it also leaves the old entry behind, so the device accumulates names that no longer correspond to anything.

Decide which of those you want before you touch the XML, because the name is the switch.

One active profile, several eligible ones

Windows applies automatic triggers to a limited set of profiles, and having several eligible profiles does not make them all connect as competing defaults. One is active, and the others wait.

That matters when a device receives both a user-scoped and a device-scoped profile with similar names. They are not the same connection, and the one that auto-connects is the one the selection rules chose, not necessarily the one you tested. A test that passed on the other profile proves nothing about the trigger. Record which profile answered before you change anything.

Read the stored state before an update

Before shipping any profile change, look at what the device currently holds: the connection object, its status and the stored list of disabled automatic triggers.

These commands list the VPN connections and search the registry for the documented value:

Get-VpnConnection | Select-Object Name,ConnectionStatus,SplitTunneling
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Network /s /f AutoTriggerDisabledProfilesList

An entry matching the profile you are about to deploy tells you the user's choice is already recorded. That is not a fault to repair silently; it is the state your policy has to account for.

Decide the policy you want

There are two defensible policies and one bad habit. The first honours a user's opt-out until the user changes it, and documents that the trigger is advisory on managed devices. The second treats automatic connection as a compliance requirement, and then the opt-out should not be offered in the first place.

The bad habit is rewriting unrelated state to force the trigger back on, which works until the next refresh and leaves the device with settings nobody can explain.

Write the choice down where the profile is maintained, alongside the four transitions worth reviewing: first provision, a normal trigger, an allowed user change and an update to the same name. Automation, routing scope and disconnected-state enforcement are separate controls, and the Always On label is not a guarantee about any of them.