为什么用户关闭 Always On，而配置文件让它保持关闭

用户取消勾选“自动连接”，配置文件便停止连接。几个月后，部署团队发布同名更新配置文件，指望触发器回归，结果并没有。原因在于这项选择从来就不只存在于配置文件中：Windows 把用户针对该配置文件名的决定记录在自己的状态里，重新安装并不会清除它。配置文件只是配置的一半。

复选框究竟写入了什么

取消自动连接选项是一项按设备保存的决定，存放在配置文件 XML 之外。Microsoft 将其记录为一份“已禁用自动触发器的配置文件名称”列表，因此即使删除并重新添加该配置文件，这项设置依然保留。

从用户角度看，这个设计是合理的。在按流量计费的连接上关闭自动连接的人，不会希望下一次策略刷新悄悄把它重新打开。

这也意味着配置文件名称是一种身份，而不是标签。两个同名配置文件对该列表而言就是同一条记录，而改名会创建一个全新的身份，完全不带任何已保存的偏好。

为什么重新安装配置文件不会重置它

删除 VPN 连接并从更新文件重新添加，会移除并重新创建配置文件对象。它不会移除用户决定的记录，因为该记录以名称为键，而不是以配置文件的内部标识符为键。

于是更新到位，配置文件存在且配置正确，触发器却依然不触发。配置文件里没有任何东西能解释这一点，因此它会被当作部署故障上报。

同样的行为也可以有意利用：当更新意图保留同一连接时，保持配置文件名称不变；只有想要全新开始时才改名。为绕开已保存偏好而改名确实有效，但它也会留下旧记录，于是设备上会积累一堆不再对应任何东西的名称。

在动 XML 之前先决定你要哪一种，因为名称就是那个开关。

一个活动配置文件，多个合格配置文件

Windows 只对有限的配置文件集合应用自动触发器，存在多个合格配置文件并不意味着它们都会作为相互竞争的默认项去连接。只有一个处于活动状态，其余的在等待。

这一点在以下情况下很重要：设备同时收到用户范围和设备范围的、名称相近的配置文件。它们不是同一个连接，自动连接的是选择规则挑中的那个，不一定是你测试过的那个。在另一个配置文件上通过的测试，并不能证明触发器的情况。改动之前，先记录是哪个配置文件应答的。

在更新前读取已存储的状态

在发布任何配置文件更改之前，先看看设备当前持有什么：连接对象、它的状态，以及已禁用自动触发器的存储列表。

以下命令列出 VPN 连接，并在注册表中搜索文档中记载的值：

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

如果存在与你要部署的配置文件匹配的条目，就说明用户的选择已被记录。这不是需要悄悄修复的故障；这是你的策略必须纳入考虑的状态。

决定你要采用哪种策略

有两种站得住脚的策略，还有一种坏习惯。第一种尊重用户的退出选择，直到用户自行更改，并说明在受管设备上触发器只是建议性的。第二种把自动连接当作合规要求，那么一开始就不该提供退出选项。

坏习惯是通过改写无关状态来强行把触发器恢复，这能撑到下一次刷新，并给设备留下一堆谁也解释不清的设置。

把选择记录在维护配置文件的地方，并列出值得复查的四个转变：首次配置、正常触发、被允许的用户更改，以及更新到同一名称。自动化、路由范围和断开状态强制是彼此独立的控制项，Always On 这个标签并不保证其中任何一项。