Bootstrap 还是 GPO：Windows VPN 配置文件的两条路径

从域共享推一个 VPN 配置文件下去，一切正常——直到那台连不上域的笔记本出现。那一刻，交付反而依赖了配置文件本身要建立的那条连接。拿着这台笔记本的人，处在服务台看不见的地方。把首次安装和日常更新当成同一个包里的两条不同路径，因为它们的失败方式毫无共同之处。

首次安装是另一个问题

有两个事件值得关注，而只有一个发生在网络配合的时候。表格按可用条件、触发动作和常见故障把它们分开。

一份经过评审的构件可以同时服务两条路径；关于连通性的假设却不能共享。启动脚本在公司网络的办公桌上运行时把这个假设藏了起来，到了现场就把它暴露出来。脚本本身没有缺陷，只是被要求去运行在没人设计过的环境里。

包里必须包含什么

打包前先定五件事：支持哪种 Windows 配置文件机制，作用范围是按用户还是按设备，哪些证书或客户端组件属于前置条件，配置文件定义写了什么，以及哪个操作把它应用下去。ProfileXML 是表达 VPN 设置的支持方式，通过 VPNv2 CSP 下发，而 微软的配置文件选项指南 列出了它能承载的内容。清单之外的一切，都是你临时做出的决定。

辅助脚本的参数属于那个脚本。像 xmlFilePath 或 AllUserConnection 这样的名字是某位作者的选择，而不是每个安装器都遵守的标准；把它们抄进另一个脚本，得到的命令看起来正确，却什么也不做。

让脚本和定义处于同一个版本，并把两者的来源连同权限一起审计。一个恰好能从 SYSVOL 读取的提权启动脚本，仍然没有经过评审，而通过策略分发并不等于评审。

拿到第一次连接

首次安装发生在设备还能以别的方式被触达的时候：受批准的网络、已有的管理通道，或者为此设计的注册流程。所选认证方式的证书和信任前置条件属于同一个包，因为还没有建立的隧道里什么也取不回来。在任何人承诺日期之前，先问这三条通道里哪一条对这位用户是真实的。只存在于纸面上的通道，最后会变成一通来自现场的电话。

把技术员或用户在那个时刻实际做的事写下来。如果答案是 IT 远程连上来帮忙，那么首次安装这条路径就悄悄依赖了第二个远程访问工具，而它同样需要有人去准备和支持。

更新需要一个已知状态

一旦机器回到域里，常规的域或设备管理流程就可以接手。错误往往出在作用范围上，因为启动脚本以机器上下文运行，而用户登录操作和设备管理操作在范围和权限上都可能不同。

面向所有用户的连接条目并不是登录前的设备隧道，名字再怎么暗示也不是。设备隧道带有自己的平台、协议和凭据要求，读这些要求是唯一能知道此处能否实现登录前隧道的办法。登录时启动的用户隧道提供的保证不一样。

让更新路径可重复：找到那个已经在被管理的配置文件，保留原本打算保留的用户偏好，应用一份兼容的定义，并报告清楚的结果。每次策略刷新都新建一个配置文件，正是一台机器最后留下五条条目、用户挑错那一条的原因。

让这件事可被支撑的那份记录

交接里要有三个答案：新发放的设备如何拿到第一次连接，谁有权修改这个包，管理员如何从一次不兼容的变更中退出。把这些写下来，部署就不再依赖某个本来就持有待发放权限的人。

把这份记录存放在包版本旁边，并在同一次变更里更新两者。否则下一个人只能从一年前关闭的工单里重建 bootstrap 路径。