VPN 连接时运行任务：事件、轮询还是凭据？
登录脚本在隧道建立之前运行。比较网络事件触发器、资源轮询和已保存的凭据，看各自能保证什么。
映射驱动器或启动同步作业的登录脚本在隧道获得地址之前运行，因此它会静默失败，用户每天早上都要手动修复。对于大多数客户端，Windows 不提供按 VPN 的连接回调，但它会记录网络变化，而那条记录可以在合适的时刻启动工作。选择介于响应那条记录、轮询资源，以及移除让故障可见的提示之间。
按各自能保证什么来比较这三种机制，胜过按优雅程度给它们排名。每一种的失败方式都不同，而失败方式正是你事后要与之相处的东西。
为什么登录触发得太早
登录和启动在 VPN 适配器获得地址之前运行，因此那一刻尝试的驱动器映射、内部 URL 或数据库连接既没有路由也没有解析器。请求失败，会话停留在用户必须手动修复的状态。把同一个脚本移到启动文件夹也无济于事，因为顺序问题会随之而来。触发器必须是网络变化，而不是会话事件。
登录时带任意延迟的计划任务看起来像修复，实际上只是猜测。它在快链路上有效，在慢链路上失败，这是最没用的一种可靠性。
三种挂钩的比较
这些机制在观察什么、反应多快，以及当天稍后重新连接时怎么做上各不相同。表格比较的是这三点，而不是哪个听起来更聪明。
| Mechanism | Reacts to | Covers a mid-session reconnect | Typical failure |
|---|---|---|---|
| Network profile event | A network connect record | Yes, when the event repeats | Runs on the wrong network |
| Resource poll with backoff | The resource becoming reachable | Yes | Log noise and a wasted window |
| Stored credentials alone | Nothing; it removes a prompt | No | Still fires before the tunnel |
逐行阅读表格。事件挂钩最快也最嘈杂，因为 Windows 会记录每个网络，包括咖啡馆的 Wi-Fi，所以操作必须先验证资源再动手。轮询更慢也更精确，因为它在共享或主机名响应的那一刻才成功，而且不需要知道装了哪个客户端。保存的凭据完全不是竞争选项：它移除密码提示，而这是登录时映射失败的第二个、独立的原因。
在前两种之间选择，取决于客户端上是否存在可用的事件。存在时，事件加资源检查是更好的默认做法。
正确构建事件触发器
记录位于 Microsoft-Windows-NetworkProfile/Operational 日志中，ID 10001 标记刚刚连接的网络。用针对该日志、该提供程序名称和该标识符的“发生事件时”触发器创建任务。机器加入的每个网络都会触发它，因此操作需要保护子句而不是假设；如果工作涉及映射驱动器，它只应在用户登录期间运行。
保护子句应测试任务真正需要的东西，例如共享路径或服务端口，并在无法访问时安静退出。测试适配器名称不够，因为客户端可能在一个适配器上复用多个配置文件。安静退出让日志保持可读，并防止针对永远不提供该资源的网络的重试风暴。
测试任务是否在正确的时刻运行
证明时机，而不是配置。下面的命令显示任务定义、最近的网络配置文件事件，以及从任务运行所用账户能否访问资源。请在真正的重新连接之后运行它们，而不是在手动启动之后。
schtasks /query /tn "VpnPostConnect" /v /fo LIST
Get-WinEvent -LogName Microsoft-Windows-NetworkProfile/Operational -MaxEvents 10
Test-Path \\fileserver\share
whoami没有网络事件与之对应却存在任务历史条目，说明触发器错了，而不是操作错了。如果事件出现而任务没运行，任务可能在以看不到该资源的账户运行，账户输出就是线索。映射仍然缺失时资源检查却通过，指向的是会话上下文而不是连通性。这三种观察各自把你引向不同的修复。
每次运行写一行日志，包含地址、资源结果和最终结果。这样下一次失败就会显示任务是运行得太早、在错误的网络上运行，还是根本没运行。