一个 VPN，两个 Windows 账户：另一个会话为什么会坏
路由和解析器都是整机范围的，所以一个账户的隧道会改写其他账户的走向。然后再找出是哪个策略或登录模块移除了“切换用户”入口。
两个人已登录，其中一人连上公司隧道，另一个账户的浏览器就开始打不开一分钟前还正常的网页。同一台机器上，登录屏幕里的“切换用户”入口也消失了，于是第二个人回不到自己的会话。从第二个会话向外追踪，是理解这件事最快的路径：第一个用户的连接里没有任何隐藏的东西，而一旦看清哪些对象是共享的，第二个用户的问题也就不再神秘。
从出问题的会话开始
走到第二个账户的桌面，而不是第一个。在那里打开终端，在另一个会话仍连接时查看路由表和解析器列表。你看到的一切都属于这台机器，而不属于另一个用户，这就是第一条线索。
Get-NetRoute -AddressFamily IPv4 | Sort-Object RouteMetric | Select-Object -First 12 DestinationPrefix,NextHop,InterfaceAlias
Get-DnsClientServerAddress -AddressFamily IPv4 | Select-Object InterfaceAlias,ServerAddresses
Get-NetConnectionProfile | Select-Object Name,NetworkCategory,IPv4Connectivity如果默认路由现在指向隧道接口，第二个用户的流量也会跟着走。如果解析器列表里多了一台私有服务器，他们的查询就会去往隧道断开后无法到达的地方。这两者都不是客户端的缺陷，而是同一个共享网络栈的后果。
第三条命令解释了第二类抱怨。当适配器把机器从公用网络类别切换为专用类别时，绑定到配置文件的防火墙规则会对所有账户同时改变，于是早上还被允许的应用，下午可能谁都没动规则就被挡住了。
连接是按用户的，网络不是
Windows 把连接对象保存在创建它的用户配置文件里。它产生的虚拟适配器、安装的路由，以及 它注册的 DNS 服务器都是整机范围的。这一分离正是标题里两个症状的源头。
这也解释了为什么注销第一个用户通常能修好第二个。移除连接会一并移除适配器和路由，整机状态回到任何人拨入之前的样子。这是一条有用的诊断：如果注销就能修好另一个账户，你面对的是共享状态，而不是损坏的配置文件。
你做不到的是给第二个会话一张不同的路由表。表只有一张，任意两个会话共用它。这是操作系统的性质，而不是某个客户端的局限。这也意味着任何假设相反的设计都会持续失败，而且这些失败看起来会像互不相关的应用缺陷。
按这个顺序找出是谁移除了“切换用户”
快速用户切换消失的原因完全不同，修复方式也与路由无关。按顺序排查四个候选，因为前两个几秒钟就能回退，后面的则有代价。
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System' -Name HideFastUserSwitching
gpresult /h $env:TEMP\gp.html
Get-Service | Where-Object { $_.DisplayName -match 'Logon|Access|Credential' } | Select-Object Status,Name,DisplayName注册表值是最简单的解释。如果它存在且读数为 1，该入口是被策略隐藏的，组策略路径是“计算机配置、管理模板、系统、登录”，以及用于隐藏快速用户切换入口点的设置。把它设为“未配置”，再用 gpupdate /force 刷新。
第二条命令告诉你这项策略是从域下发的，而不是本地写入的。如果它出现在报告里并附带获胜的 GPO，那么修改本地值只是临时修复，下次刷新就会回退，这件事应当去找策略的所有者。
第三条命令覆盖另一种机制。安装登录模块的凭据或网络访问提供程序会在运行时压制该入口，有些客户端还会注册一个在登录前启动、并占住登录屏幕的组件。禁用那个服务会恢复切换，但同时也会去掉该模块本应提供的登录前或 posture 功能。
| Cause | How to confirm | Cost of the fix |
|---|---|---|
| HideFastUserSwitching policy | Registry value present and set to 1 | None; remove the policy |
| Logon module service | Service running under a vendor name | Loses pre-logon and posture behaviour |
| GINA-era assumption | Only relevant on very old Windows | Nothing to fix; the mechanism is gone |
改的时候别把自己锁在外面
操作时保留一个管理会话，绝不要在一台只能通过该屏幕访问的机器上修改登录屏幕设置。先注销其他会话，应用改动，刷新，然后通过切换用户而不是重启来验证。
记录你禁用了哪些 posture 功能。客户端更新可能重新安装或重新启用登录模块，症状会在没有明显原因的情况下回来，通常是在支持窗口进行到一半、没人记得之前那次改动的时候。
在受管设备上，要假定设置是从上层下发的。先检查策略报告，能省下一小时注定回退的本地修改。它还能告诉你当答案是“不行”时该找谁。写明获胜策略的工单，处理速度是只描述某个已被改过的注册表键的工单的两倍。
验证两个账户，然后选定模型
按两个用户实际经历的次序测试结果。先断开第一个账户，以第二个账户登录并确认正常访问，然后连接第一个账户的隧道，确认第二个账户的预期路径仍然符合你的设定。
qwinsta
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Select-Object InterfaceAlias,NextHop,RouteMetric
Test-NetConnection -ComputerName intranet.example.internal -Port 443如果两个账户确实需要同时走不同的网络路径，诚实的答案就是两台机器、两台虚拟机，或只要求一条路径的策略。共享连接上的拆分隧道可以收窄经过的流量，却无法给每个会话一张自己的表。早点承认这一点，比试过三种变通之后才发现要便宜。
这是要明确做出的决定，而不是绕着打补丁。一张路由表、一份解析器列表、一个防火墙配置文件：其余一切由此推出，尊重这一点的修复下个月仍然有效。