Windows 的 VPN 提示设备缺失：按顺序修复

两种看似无关的症状在 Windows 上有着同一个原因：已保存的连接报告设备缺失，以及 SSTP 服务在几秒内启动又停止。两者都不是密码问题，也都不能靠先重建配置文件来解决。任何登录尝试之前必须存在的本地组件，才是修复的起点。

按下面的顺序向外推进，并在第一个改变症状的阶段停下来。在设备尚不存在时就重建配置文件，只会多出一个提示相同信息的条目。

先查服务，而不是凭据

原生 Windows 连接背后有三个服务：Telephony、Remote Access Connection Manager 和 Remote Access Auto Connection Manager。拨出配置文件需要这三个服务都在运行，而其中任何一个都可能被早先的清理脚本或加固镜像留在禁用状态。把正在使用的服务设为 Manual 或 Automatic 而非 Disabled，并在动其他任何东西之前先启动它们。Routing and Remote Access 是另一个承载传入连接的组件，因此启用它并不是拨出的前提。

Get-Service -Name TapiSrv,RasMan,RasAuto | Format-Table Name,Status,StartType
Get-WinEvent -LogName System -MaxEvents 30 | Where-Object { $_.ProviderName -match 'Ras|RemoteAccess' }

启动后立即回到 Stopped 的服务，与仅仅被禁用的服务是两回事。对应的事件记录会指出拒绝继续运行的组件。

然后检查配置文件背后的微型端口

正常安装会为可用的协议列出 WAN Miniport 设备，包括 PPTP、L2TP、IKEv2 和 PPPoE。如果这些条目缺失或被禁用，Windows 就没有可绑定连接的设备，配置文件会一直报告设备缺失。以显示隐藏设备的方式打开 Device Manager，展开 Network adapters 查看真实清单而不是被筛选过的清单。启动连接管理器往往会重新枚举这些设备，所以服务故障可以伪装成硬件缺失。

启用微型端口是受支持的修复手段，而批量删除适配器不是。这个区别在远程机器上很重要，因为你每删掉一个适配器，就少了一条回去的路。

当 SSTP 在几秒内启动又停止时

两个共享组件位于 SSTP 之下：事件日志和 WMI 存储库。当该存储库损坏时，服务拒绝继续运行，而 VPN 配置文件里没有任何内容能解释这一点。以管理员会话启动到 Safe Mode，然后清空系统盘 WMI 日志文件夹内的 RtBackup 目录，同时保留目录本身。如果重命名被阻止，先清空内容再重命名，把旧文件带进替换项中。保存事件日志后再清空它们，因为在 RtBackup 为空时启动的服务，只要日志仍然损坏，下次启动往往还会失败。

如果 Event Viewer 完全打不开，问题在日志而不在 VPN 配置。改变另一项设置之前，先回到日志。

重建一个条目并单独测试

每个原生连接都存在于一个电话簿文件中，而每个用户的副本位于 Network/Connections 路径下的漫游应用程序数据文件夹。整台机器的电话簿是另一个文件，其中可能含有互不相关的条目。用向导添加一个新连接，或导入运营商提供的程序包，并在做其他任何事之前单独验证该条目。整体替换电话簿会把能用的连接和坏掉的一起带走。

rasdial "Office VPN"
rasdial "Office VPN" /disconnect
Get-PnpDevice -Class Net | Where-Object FriendlyName -like '*WAN Miniport*'

连接建立后却什么都传不了，说明已经超出这次修复的范围。在 Hyper-V 主机上，在虚拟适配器上启用 NetBIOS over TCP/IP 是若干已记录 SSTP 案例中缺失的一环，检查它没有任何代价。过期的密码要在保持连接的状态下修复，因为目录只有在成功登录后才会知道新值。继续之前先记录是哪一步失败，因为为回应身份验证错误而重建设备路径，只会带来折腾，不会带来进展。

服务，然后微型端口，然后一个配置文件，然后身份验证，最后是远程资源。这个顺序就是全部方法，而在第一个变化处停下来，正是让它保持简短的关键。