"混乱"的 Windows 10 更新系统代理(下)

《"混乱"的 Windows 10 更新系统代理(上)》介绍了 Windows中代理分类及基本的配置，本文介绍这些代理配置是如何影响 Windows 更新过程的。

Windows 更新过程涉及扫描、下载、安装过程，每一部分都采用独立的服务。Windows 更新客户端利用 Windows HTTP 服务(WinHTTP)扫描检查可用更新；利用 Background Intelligent Transfer Service (BITS)服务或者 Delivery Optimization (DO)服务下载更新。这些服务各自独立，需要针对它们分别进行代理配置，使其能够通过代理完成 Windows 系统更新。再加上不同组策略的影响，当用户为更新系统配置代理的时候，偶尔会出现明明已经开启代理，但更新服务就是没有工作，这不免会产生"混乱"的感觉。

扫描阶段代理配置

Windows 更新过程开始于更新客户端扫描更新服务器以发现适用于本机的更新包信息。

自动更新

在 Windows 采用自动更新的场景下，对于没有独立托管更新服务器的用户，客户端计算机直接连接 Windows Update服务器进行更新。更新服务运行在Local System账户的上下文中，不要求用户交互¹。从之前的文章中可知，相比WinINet，WinHttp的实现方案更适合此时场景应用，而且更新扫描阶段的确利用WinHttp实现。所以，自动更新场景下，通过使用netsh命令手动配置系统代理够被自动更新服务检测到。

netsh winhttp set proxy myproxy
netsh winhttp set proxy myproxy:80 "<local>bar"
netsh winhttp set proxy proxy-server="http=myproxy;https=sproxy:88" bypass-list="*.contoso.com"

在《How the Windows Update client determines which proxy server to use to connect to the Windows Update website》¹一文中提到，当 Windows 更新服务使用系统代理无法访问代理服务的时候，它会尝试使用用户代理。这一点与我们之前的理解有所出入，当然，从原理上讲，WinHttp在service中是有办法获得当前用户代理设置的。更新服务的dll文件引用情况可以验证这一点：wuaueng.dll是更新服务调用的dll，通过PE工具可以看到该dll会引入WinHttp.dll并调用了其中的WinHttpGetIEProxyConfigForCurrentUser函数和WinHttpGetDefaultProxyConfiguration函数。前者对应获取用户代理，当然不是直接获取，而是可以通过服务模拟(impersonate)当前用户的方式来实现；后者对应获取缺省代理配置，可以得到通过netsh所配置的系统代理信息。

下图是更新服务dll调用获取用户代理和系统代理的截图信息：

指定更新源

组织单位可能会内部部署WSUS更新服务器用于更精细管理更新包的审批应用情况，最终用户将不必通过防火墙获得更新，并允许在部署更新前对其进行测试。客户端计算机需要更改组策略设置来指定WSUS更新服务器地址。

组策略设置位置：“计算机配置” -> “管理模板” -> “Windows 组件” -> “Windows 更新”-> “指定 Intranet Microsoft 更新服务位置” -> “选择 Windows 更新客户端用于检测更新的代理行为”.

与自动更新的设置相比，"指定更新服务位置"中对使用代理做了进一步细分。

默认情况下，仅使用系统代理扫描检测更新。当需要使用用户代理检测更新时，必须将代理行为配置为“当使用系统代理进行检测时，允许将用户代理用作回退”。

DO下载更新代理配置

当扫描检测更新阶段获取到适用于本机的更新信息后，Windows 更新客户端利用BITS服务或者DO服务来下载更新。

更新服务默认采用DO进行更新下载。DO利用WinHttp实现文件下载，同时会将当前登录用户的token信息给到WinHttp，这时候WinHttp就可以使用"用户代理"的配置信息访问网络了。所以，默认情况下，如果有用户登录，DO服务会使用"用户代理"来下载更新；当没有用户登录的时候，这时候如果通过netsh配置了"系统代理"，DO将使用系统代理。但官方文档不建议使用netsh配置系统代理的方式，因为采用这种方式在处理代理需要用户认证的情况的时候，WinHttp的限制将导致认证失败²。

BITS下载更新代理配置

将组策略中的"传递优化"设置为"旁路"，则更新服务选用BITS下载更新。设置路径：“计算机配置” -> “管理模板” -> “Windows 组件” -> “传递优化”-> “下载模式”。

这里可能会给用户造成一点儿困扰：配置用户代理后调用BITS可以下载文件，为什么更新包下不来呢？原因是BITS作为系统中的服务可以为普通用户提供下载服务，比如用户通过PowerShell命令调用BITS服务下载文件，此时BITS接受用户上下文运行，默认使用IE代理设置，即使用"用户代理"。作为更新下载服务的时候，用户代理不再有效，所以更新包无法下载。

这时候可以利用bitsadmin工具来为服务的系统账户设置代理³：

bitsadmin /util /setieproxy localsystem MANUAL_PROXY proxy1:4556

小结

组策略中的配置选项，仅影响更新服务扫描检测阶段的行为:

使用 Windows Update 直接进行更新，更新服务可以使用系统代理和用户代理进行检查更新，且更新服务可以使用"Windows 凭据"中记录的代理认证信息进行代理连接时候的认证；

当通过组策略配置Intranet更新服务器的时候，根据选项决定是否仅使用系统代理还是将用户代理作为备选项。

更新服务下载阶段行为:

DO仅使用用户代理，支持携带认证信息，但DO无法处理更新包分发服务跳转场景(这点参考文章《哎，这是个 Windows 的Bug》)；

BITS下载更新不会使用用户代理，默认只能使用系统代理；可以通过bitsadmin单独对BITS进行设置，BITS使用系统代理不支持携带认证信息。

更新服务运行的扫描、下载阶段中，各个服务使用用户代理或者系统代理基本都可以工作。最大的区别在于二者底层实现中WinINet支持"凭据管理"而WinHttp不支持，这就导致了使用系统代理的时候，如果代理服务器要求认证，所有的访问就会失败。
针对BITS和DO在支持需认证的http代理的场景，可以有以下的解决方案：

在代理服务器端添加 “白名单”，能够放行访问某个域名的请求不验证；

利用WSUS 提供更新包托管服务的情况下，在内网中部署WSUS，利用WSUS通过代理获取更新后，供内部机器更新使用；

参考

How the Windows Update client determines which proxy server to use to connect to the Windows Update website

Using a proxy with Delivery Optimization

Specifying proxy settings for user accounts and service accounts