如果你想直接查看问题现象描述，请跳到下一节。
我们拥有一个活动目录域（Active Directory Domain）环境，域名为jx.local。
在此域中，有一台域控制器（Domain Controller）兼Windows服务器更新服务（Windows Server Update Services，WSUS）器，还有一台客户端电脑。客户端电脑被设置为从WSUS服务器获取Windows更新。
域中每一台设备的详细信息如下。
| 设备名（带域名） | IP地址 | 操作系统 | 角色 |
|---|---|---|---|
| DC1.jx.local | 192.168.1.250/24 | Windows Server 2022 数据中心版 | 活动目录域服务、Windows服务器更新服务 |
| C1.jx.local | DHCP | Windows 11 专业版 | 客户端机器 |
我们通过组策略指定C1使用DC1作为WSUS服务器。启用了的组策略如下（位于Computer Configuration\Policies\Administrative Templates\Windows Components\Windows Update），剩余均未配置。
经过了很长时间，WSUS服务器DC1的WSUS控制台中始终未见客户机C1显示出来。
Windows服务器更新服务（Windows Server Update Services，WSUS）一直是一个令系统管理员们讨厌的服务，因其经常出现怪异的错误。
其中，最常见的错误就是客户机始终不在WSUS服务器的控制台中出现。这令人抓狂，因为
无论哪种，Windows都不会给出任何提示或错误。除非你有意去排查，否则毫无头绪。
了解WSUS的工作逻辑有助于我们排查。
WSUS的运作逻辑是，只有当客户机主动去连接服务器且连接成功时，该客户机才会出现在WSUS控制台中。
在默认设置下，客户机每22小时自动连接一次服务器。这绝对是我们不想要的，起码在排故阶段。
此外，客户机有可能在新策略，即设置，被初次应用时连接一次服务器，但这不是确定的行为。就像在域中应用组策略一样，有时使用命令gpupdate /force都不能强行使客户机应用新的策略，就非得重启不可。
WSUS客户机使用HTTP协议与WSUS服务器通信。客户机会尝试与服务器的8530端口通信。
我们需要确认新的组策略，即设置，真的有被应用到了客户机上，因为我们通过部署组策略的方式告诉客户机如何连接到WSUS服务器。
我们将登录到客户机C1上，通过查看一个叫做组策略结果（Group Policy Result）的排故报告的方式，检查新的组策略的应用情况。
我们使用具有域管理员（Domain Admins）权限的账号JX\Administrator登录到客户机C1上，因为使用普通域用户（Domain Users）生成的组策略结果可能信息不全。
登录后，我们在命令提示符（Command Prompt）中执行下面的代码，查看当前组策略应用的情况。这将在桌面上生成一个叫做result.html的报告文件，我们可以通过浏览器打开阅读。
cd desktop
gpresult /h result.html
class="hljs-button signin active add_def" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">我们发现我们用来部署WSUS的组策略WSUS Updates被成功应用。组策略的应用上没有问题。
如前所述，WSUS客户机每22小时尝试连接一次服务器。为了保险起见，我们在组策略中将间隔更改为1小时，然后重新应用组策略，重启客户机。
这份日志详细地记录了Windows更新服务运作的细节。在老旧的Windows版本上，你可以打开文本文件C:\Windows\WindowsUpdate.log直接查看。但在新的版本上，你需要执行Powershell命令
Get-WindowsUpdateLog
class="hljs-button signin active add_def" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">查看。这将导出所有的Windows更新服务日志到桌面。
我们打开日志仔细检查后，发现了如下错误。
客户机在尝试从WSUS服务器获取一个名为client.asmx的文件。这个文件对WSUS至关重要，它帮助客户机与WSUS服务器交流。然而，这个网络连接并不能建立。
如果观察够仔细，就会发现URL中的域名被误拼成了jx.lcoal，尽管其本应是jx.local。自然而然，域名无法解析，因此无法连接。
我们只需回到服务器上的组策略，将拼错的域名修正，然后重启客户机重新应用组策略即可。
然而，重启客户机C1以后，WSUS控制台里仍无变化。因此我们再次检查Windows更新服务日志，寻找线索。
再次检查，发现正确的WSUS服务器URL已被应用。然而，客户机在获取client.asmx时遇到了HTTP请求404错误。
这是因为正确的URL应该是http://dc1.jx.local:8530/ClientWebService/client.asmx。曾有谗言称你在WSUS组策略中指定WSUS服务器地址时不需要添加端口号，应用时Windows将自动使用端口号8530，看来这是个彻头彻尾的谎言。
重新更改组策略，加上端口号，然后再次应用，重启客户机。
然而，应用完以后，我们仍未见客户机在WSUS控制台中显示。
如果网络连接没有问题，此时应该强行让客户机联系服务器了。我们可没有闲工夫等上几个小时。
你可能会在网络上找到大量的建议——使用如下的命令强制让客户机联系服务器。
wuauclt /detectnow
wuauclt /reportnow
class="hljs-button signin active add_def" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">甚至是：
wuauclt /resetauthorization /detectnow
usoclient startscan
class="hljs-button signin active add_def" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">然而，这些命令不知因何原因，在执行后都如同石沉大海。使用Wireshark监测网络行为，等了很久也没有发现与WSUS服务器通信的HTTP流量产生。你甚至可以在这些命令后胡乱加上参数，例如
wuauclt /whattheheck
class="hljs-button signin active add_def" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">命令依然能被立刻执行，也不会提示成功和报错。这使得我很怀疑这些命令的有效性。
每次Windows更新服务被重启时，都有可能主动联系WSUS服务器。要想重启Windows更新服务，在命令提示符中执行下面的代码：
net stop wuauserv
net start wuauserv
class="hljs-button signin active add_def" data-title="登录复制" data-report-click="{"spm":"1001.2101.3001.4334"}">如果还不行（非常可能），尝试下面最简单粗暴的方法。
在Windows 11的设置应用中找到Windows更新，并点击检查更新。这将百分百确保Windows客户机尝试一次连接。
Wireshark显示通信流量产生。连接完美地执行。
客户机终于在WSUS控制台中出现。
有时，你可能在WSUS控制台中删除了一台客户机，却无法将它重新加回，尽管客户机和WSUS服务器仍能正常通信。对于此，请查看这篇文章。
还有时，在WSUS中，你可能一不小心下载了一堆不相关微软产品的更新、驱动等，却无法将它们移除。想要解决这个问题，请参照这篇文章。
评论记录：
回复评论：