微软11月补丁：Win10扩展支持设备修打印机87错误，远程桌面影子连接一并处理

2026-11-11 12:12 1001 次浏览

一台还在跑ESU的老机器，先等来的是打印机修复

11月10日的补丁星期二，微软把KB5131096推给了仍处于扩展支持（ESU）状态的Windows 10设备。22H2装完版本号到Build 19045.7846，21H2则是Build 19044.7846。

这个更新最受关注的地方，是它收掉了一个由10月更新带进来的毛病：在Active Directory里发布过的打印机，走“设置”里的添加设备流程会失败，弹出错误87，提示“参数错误”。

对企业IT来说，这类问题不算致命，但足够烦人。已经配好的打印机和日常打印不受影响，卡住的是新机器上线、新同事入职这类需要重新添加共享打印机的场景。10月打完补丁之后踩到这个坑的运维，这次可以顺势收尾。

同一批修复还覆盖了两处管理侧的问题，受影响的主要是运维和域环境。

通过Microsoft Intune配置“指定代表受信任.rdp发布者的证书指纹”策略时，此前无法成功下发，这一版已修复。
在Windows Server 2016和Windows Server 2012 R2上装过10月14日更新后，远程桌面影子连接可能失败并报“未指定的错误”，同样在这一版得到处理。

影子连接是不少服务台远程协助用户的手段，它挂掉意味着排障只能换路子。这类问题往往不会在监控大盘上冒红，而是靠一线人员反馈才浮出来。

另外，古巴的夏令时规则也做了调整。古巴继续采用UTC-04:00，原本定在2026年11月和2027年3月的两次时间切换不再执行，2027年11月改回UTC-05:00，2028年恢复常规的季节性切换。受影响的设备时区显示会跟着变，业务系统里如果硬编码了切换日期，值得顺手核一遍。

真正需要提前评估的，是这版更新带来的两项安全强化，它们改变的是默认行为。

PowerShell的脚本签名与签名验证引入了更严格的编码校验。带无效UTF-8编码的脚本，哪怕以前能通过验证，现在也可能被拦下。处理办法不复杂：把受影响的脚本另存为带字节顺序标记（BOM）的有效UTF-8编码，再重新签名。

NTLM这边，客户端在非匿名连接中默认提出使用NTLM消息签名。这个改动指向的是NTLM中继攻击，同时提供了审计能力，方便找出那些没有走签名的连接。对还在混用旧认证方式的环境，升级后可能出现零星认证失败，审计日志是排查的第一站。

按我的经验，这类默认值变化不会一次性爆出来，通常是在某些边缘业务系统上偶发报错，然后才被追到补丁头上。先把签名脚本和NTLM依赖方梳理一遍，比事后救火省事。

Windows 10进入扩展支持之后，累积更新的节奏没变，但可用的兜底手段变少了。功能层面的问题还能靠绕行方案顶一顶，安全默认值的收紧却很难回退。

对仍靠ESU续命的设备，比较稳妥的做法是先在小范围验证打印机添加流程和远程桌面影子连接，再确认关键脚本的编码与签名状态，最后观察NTLM审计里是否出现异常连接。三步走完，再决定是全量推送还是分批。

老系统的维护成本，正从“能不能打上补丁”转向“打完补丁业务还转不转”。这一版修复清单不长，但它把安全基线又往前推了一格，留给旧环境的适应时间只会越来越短。