1. 内网自建 WSUS 这件事先想清楚它的边界在哪里如果你管过几百台以上的 Windows Server 和终端大概都经历过这种场景每个月的补丁日一到出口带宽瞬间被抽干业务系统访问变慢几个小时后运维群里开始刷屏谁在下载东西。去查流量发现全是各台机器各自跑外网更新服务彼此之间没有任何协同。这套机制本身没问题问题在于它默认假设你的出口带宽和终端数量是匹配的——而在绝大多数内网环境里这个假设根本不成立。WSUSWindows Server Update Services要解决的就是这件事把每台机器自己去外网拿补丁改成内网一台机器去外网拿一次剩下的机器从这台机器拿。听起来简单但真正落地时你会发现它牵扯到服务搭建、数据库选型、内容存储规划、组策略下发、审批规则设计、客户端分组、日常清理这一整条链路。任何一个环节想岔了最后的结果就是控制台上要么空空如也要么塞满了几十万条无用记录。这篇东西写给三类人一是第一次要在 Windows Server 上部署 WSUS 的运维需要一份从零到可用的完整路径二是已经搭起来但管得乱七八糟、控制台卡到打不开的人需要知道哪里最容易出问题三是负责内网整体规划、需要判断到底该不该上 WSUS、上什么规模的技术负责人。全文基于常见企业内网实践展开涉及具体参数和容量的部分我会把推算过程写出来你可以按自己的实际情况套。2. 部署前的规划版本、容量、数据库三件事定不下来就别动手2.1 系统版本与角色定位的选择WSUS 这个角色从 Windows Server 2003 时代一路延续下来在 2016、2019、2022 上都还能正常部署安装方式和控制台界面差异不大。真正需要留意的是它在新版本里的定位变化——在更新的系统版本中这个角色已经被官方标记为不再推荐新部署微软更倾向于把补丁管理往云端服务或者第三方统一终端管理方案上引导。所以如果你现在是在做三年以上的长期规划建议把 WSUS 当成过渡期方案来看待架构上别做得太重、太耦合尤其是别把业务逻辑写死在 WSUS 的 API 上。如果只是解决眼前的带宽和合规审计问题那 2016 之后的版本随便挑一个都行。我的建议是尽量靠近现有服务器池的版本理由很实际组策略模板、PowerShell 模块、IIS 组件版本都是跟着系统走的混版本管理会带来一堆无谓的兼容问题。另外补丁本身的授权要合规——服务器操作系统和客户端系统的授权走正规采购渠道别在这上面省事后面审计的时候解释不清。2.2 内容目录容量的推算过程这是新手最容易低估的一块。很多人装 WSUS 的时候随手在 C 盘建了个目录结果半年后系统盘告急服务直接起不来。我们把账算一遍。WSUS 存储的是更新文件本体按更新分类划分主要吃空间的是这几类更新类型单个文件大致体积月均新增数量月均占用Windows 月度累积更新x64400MB ~ 1.2GB2~4 个含不同版本约 2~4GB.NET Framework 累积更新100MB ~ 250MB2~3 个约 0.5GBOffice 月度更新300MB ~ 800MB2~3 个约 1.5GBDefender 定义更新100MB ~ 200MB每天 1~4 次约 5~15GB驱动程序差异极大单个可到 500MB不定极易失控注意最后一行。驱动程序分类是内容目录膨胀的头号元凶一个显卡驱动包轻松吃掉几百兆而你的服务器上大概率根本不需要它。如果内网没有明确的驱动统一分发需求这一类直接不要勾选同步。按上面的口径一个覆盖 Windows Office 定义更新、保留 12 个月历史的场景内容目录稳定在 150GB 到 400GB 之间。我的规划习惯是内容目录单独放一块盘起步 300GB并且开好配额监控。数据库盘另外给 50GB。系统盘只放服务本体别掺和进来。2.3 WID 和 SQL Server 到底怎么选WSUS 支持两种后端Windows Internal DatabaseWID和完整的 SQL Server。WID 的优点是零额外成本、安装即用、不用单独维护实例。它的短板也很清楚单一实例、扩展能力有限、不方便做多台 WSUS 服务器共享数据库的负载分担。中小企业几百台终端以内的场景WID 完全够用别为了显得专业硬上一个 SQL Server 实例那只会给你增加一个需要打补丁、需要备份、需要盯内存的组件。一旦出现下面任意一种情况就该考虑 SQL Server 了客户端规模上千台且增长中需要部署多台 WSUS 前端做负载均衡、共用一份数据库需要把 WSUS 数据库纳入统一的数据库备份和监控体系。这里插一个和 SQL Server 相关的经典坑SQL Server 默认会尽可能占用物理内存做缓冲池在一台同时还跑着 WSUS 和 IIS 的服务器上你会看到 sqlservr.exe 把内存吃到 90% 以上然后 w3wp.exe 开始频繁换页整个控制台卡到转圈。解决办法是给 SQL Server 实例设置最大服务器内存按服务器总内存减去系统和其他服务需要留出至少 4GB 的余量。这个设置很多人装完就忘了属于典型的不报错但很难受的问题。3. 从零安装把 WSUS 角色干净地装起来3.1 前置准备与依赖组件安装之前先把几件事做掉顺序别乱。第一固定主机名和 IP不要用 DHCP 地址。WSUS 的地址会被写进所有客户端的组策略里换一次地址意味着几百台机器的策略要重刷非常痛苦。第二确认服务器能正常解析外网更新源的域名。这一步决定了后面能不能同步成功很多同步失败的问题根源其实在这里。你可以用浏览器或者简单的连通性测试工具验证一下出网路径是否通畅注意不要在生产环境上折腾网络策略。第三规划好内容目录路径比如D:\WSUS\Content提前建好目录并确认磁盘配额充足。第四服务器管理器的添加角色和功能向导会自动带上需要的 IIS 组件你不用手工去装 IIS但要知道它会装上什么静态内容、默认文档、目录浏览、HTTP 错误、ASP.NET、.NET 扩展性、Windows 身份验证、请求筛选、动态内容压缩、IIS 管理控制台。其中动态内容压缩这个组件是个双刃剑后面调优章节我会专门说它。还有一点经常被忽略这台服务器最好不要兼任其他重活。WSUS 在客户端集中上报的时候会产生明显的 CPU 和磁盘 IO 尖峰跟域控、文件服务器挤在一台机器上出问题的时候你连是谁的锅都分不清。3.2 安装过程与数据库配置打开服务器管理器添加角色和功能一路到服务器角色勾选Windows Server Update Services。向导会提示你添加所需功能确认即可。紧接着会要求选择角色服务WID Connectivity用内置数据库。SQL Server Connectivity用外部 SQL 实例选这个需要填实例名。WSUS Services核心服务必选。Windows PowerShell 的 WSUS 模块建议勾上后面做自动审批和清理脚本用得到。Database在新版本里可能合并显示按实际数据库选。内容位置那一步改成你规划好的独立磁盘路径。这一步填错了后面改起来要用wsusutil movecontent虽然能改但迁移几十上百 G 的文件要停服务没必要给自己找事。安装完成后向导通常会提示你运行安装后任务。如果没有自动触发手动执行 C:\Program Files\Update Services\Tools\wsusutil.exe postinstall CONTENT_DIRD:\WSUS\Content这条命令做两件事初始化数据库结构创建内容目录的虚拟目录映射。执行完看到Post install is starting之类的输出并且退出码为 0才算真正完成。如果你追求一次配置到位、不想点鼠标也可以用 PowerShell 装Install-WindowsFeature -Name UpdateServices, UpdateServices-WidDB, UpdateServices-Services -IncludeManagementTools C:\Program Files\Update Services\Tools\wsusutil.exe postinstall CONTENT_DIRD:\WSUS\Content对于批量部署多个站点 WSUS 的场景这种方式明显更省事也更容易做成标准化脚本。3.3 首次启动向导里的四个关键选择第一次打开 WSUS 控制台会弹出配置向导四项内容每一项都值得停下来想一想。第一项是上游更新源。从外网直接同步Microsoft Update还是从上级 WSUS 同步。选外网的话需要确认出口策略允许这台机器访问更新源选上级的话要填上级服务器的地址和端口。这里顺便提一句 HTTP 和 HTTPS 的选择WSUS 从早期版本之后默认使用 8530HTTP和 8531HTTPS端口不再占用 80 和 443。内网环境用 HTTP 就够了除非有明确的安全审计要求。如果非要上 HTTPS记得 WSUS 自身对证书的要求比较挑SAN 里主机名要对得上自签证书部署起来会有一堆客户端不信任的问题非必要不折腾。第二项是代理服务器。如果内网出口需要经过代理才能访问外网在这里配置。用户名密码填的是能通过代理的账号注意这个配置在同步失败排查时经常是罪魁祸首。第三项是产品与分类。这一步我建议先只勾必需的后面再补。原因很实际一旦勾选了大量产品第一次同步可能持续十几个小时中间你连控制台都点不动。具体怎么选下一章展开。第四项是同步计划。默认是手动同步建议改成每天固定时间自动同步比如凌晨两点。手动同步适合调试阶段稳定之后一定要自动化否则很容易忘记。4. 控制台里的配置艺术少即是多4.1 产品和分类的取舍逻辑产品列表长得吓人几十上百项。全选的后果是内容目录和数据库同时膨胀控制台响应变慢你在一堆无关更新里找真正要审批的那一条眼睛都花了。分类这边五个选项逐个说关键更新必选。安全更新必选这是 WSUS 存在的主要理由。定义更新看你用不用 WSUS 管杀毒软件的特征库。用的话选上但要意识到它更新频率极高会给数据库带来持续写入压力。更新汇总也就是累积更新必选。Service Pack现在很少见了可选可不选。驱动程序除非有明确需求否则不要选。这一条我踩过坑某个客户现场全选了驱动分类一年后内容目录 700 多 GB最后清理花了两天时间。功能包视需求。升级这个大版本升级包体积惊人单个好几个 G如果是 Windows 10 到 11 这种跨版本升级通过 WSUS 分发要慎之又慎网络和客户端磁盘都吃不消。产品这边只勾你环境里真实存在的系统和办公套件版本。比如你内网全是 Windows Server 2019/2022 加 Windows 10 22H2 和 Windows 11 23H2就只勾这几个。多勾一个不存在的版本只会多一堆永远不会被审批的垃圾数据。4.2 同步计划与上游源设置同步的核心参数就两个什么时候同步、同步完之后要不要自动审批。在选项 - 同步计划里把自动批准新更新留给人来做不要开自动化同步到审批。这条经验非常重要补丁管理是个需要留痕的动作谁批准的、什么时候批的、批给了哪一组机器都要能追溯。全自动审批一旦遇到问题补丁就是全网范围的事故。同步时间建议选在业务低峰避开和其他备份任务、杀毒扫描任务撞车。同步本身会占用带宽和 CPU如果你的内网还有多个下游 WSUS 服务器最好把它们的同步时间错开半小时以上避免同时向上游拉数据。对于有多站点的场景可以采用上游/下游结构总部一台 WSUS 从外网同步各地分公司的 WSUS 从总部同步。下游分两种模式——副本模式更新审批状态完全跟随上游只读和自治模式同步更新内容但自己独立审批。副本模式管理最省心适合网络管理员人手不足的情况自治模式灵活但管理成本翻倍需要想清楚再选。4.3 自动审批规则怎么建才算合理完全不自动审批几百个补丁一个个点人会崩溃。合理做法是分类分级让低风险的、确定要打的类别自动走高风险的留在人工审批环节。我的建议是这样的更新类别审批方式理由安全更新Critical / Important自动批准设置截止时间属于必打项拖延无意义关键更新自动批准同上定义更新自动批准频率太高人工跟不上更新汇总累积更新人工审批体积大重启影响明显需要排期驱动程序人工审批或不启用风险高可能与现有硬件冲突功能更新/升级人工审批影响面大需要单独评估已拒绝列表内的自动拒绝处理已知问题补丁自动审批规则在选项 - 自动审批里配置可以按当更新属于特定分类时或当更新属于特定产品时来设。设置的时候顺手把截止时间填上比如批准后 7 天强制安装比单纯的通知更有效很多终端的自动更新服务因为各种原因处于等待用户确认状态不设截止时间就一直挂着。再聊一个细节审批针对的是组不是服务器。所以在做审批之前计算机分组必须已经建好否则所有审批都是全局生效等于没有分组。分组这件事最好在同步开始之前就规划好比如测试组生产服务器办公终端财务终端。4.4 计算机分组与目标定位分组有两种方式。一种是服务器端手动把计算机拖进组适合小规模另一种是靠客户端自己上报目标组名也就是在组策略里配置启用客户端目标设定让客户端在向 WSUS 注册时报上自己的组别。后者的好处是免维护尤其适合有多个站点、多批机器陆续上线的情况。手动拖拽这种方式在几百台规模下很快就变成噩梦而且一旦客户端超过一段时间不上报WSUS 会把它标记成未活动需要定期清理。用组策略上报组名客户端重装或者换机之后会自动归位管理成本低得多。分组粒度我的建议是按补丁风险来分而不是按部门分。因为你的核心诉求是先测后推一组用来验证补丁兼容性一组是普通终端一组是业务关键服务器。按部门分的好处是出问题的时候能定位到具体人群但代价是组数量爆炸、审批工作量成倍上升。折中方案是两级分组一级按风险分测试/生产二级在审批时用额外的组名标记实际管理中用得最多的还是风险维度。5. 客户端接入组策略和注册表两条路5.1 组策略方式的标准配置项域环境下的标准操作在计算机配置 - 策略 - 管理模板 - Windows 组件 - Windows 更新这个路径下有几个策略是必须配的配置自动更新设为已启用选项选4 - 自动下载并计划安装然后设定安装时间。指定 Intranet Microsoft 更新服务位置设为已启用两个地址都填成http://你的WSUS主机名:8530。注意这两个地址通常填同一个一个是检测更新的地址一个是上报状态的地址。启用客户端目标设定设为已启用组名填成测试组;风险测试这种格式。这里有个坑——组名区分大小写而且必须和 WSUS 控制台里创建的计算机组名字完全一致。我遇到过一次死活不上报组名的情况最后发现是控制台里写的是TestGroup策略里写的是testgroup。自动更新检测频率这个策略值得单独提。默认值在旧版本里是 22 小时但很多环境里没人管它导致客户端频繁扫描给 WSUS 服务器带来不必要的压力。把它明确设成 22 小时配合 WSUS 范围内的随机延迟能显著平滑服务器负载。对于已登录用户的自动重启通知建议设成已启用避免服务器在业务时间自动重启。重新计划自动更新计划的安装设为已启用并指定不相邻的间隔减少多台机器同时重启造成的服务中断。组策略下发之后客户端不会立刻生效。想立刻验证可以在客户端上手动执行刷新然后触发一次更新检测。较新的 Windows 系统里原来的命令行工具行为有所调整更可靠的方式是# 刷新策略 gpupdate /force # 触发检测新系统 usoclient StartScan # 查看更新日志 Get-WindowsUpdateLog -LogPath C:\temp\wu.log老的wuauclt /detectnow在部分版本上仍然能用但已经不推荐依赖它做验证了。5.2 非域环境的注册表方式工作组环境或者临时机器用注册表直接写。核心是两个位置$wu HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate New-Item -Path $wu -Force | Out-Null Set-ItemProperty -Path $wu -Name WUServer -Value http://wsus.contoso.local:8530 Set-ItemProperty -Path $wu -Name WUStatusServer -Value http://wsus.contoso.local:8530 Set-ItemProperty -Path $wu -Name TargetGroupEnabled -Value 1 -Type DWord Set-ItemProperty -Path $wu -Name TargetGroup -Value Production $au HKLM:\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU New-Item -Path $au -Force | Out-Null Set-ItemProperty -Path $au -Name UseWUServer -Value 1 -Type DWord Set-ItemProperty -Path $au -Name NoAutoUpdate -Value 0 -Type DWord Set-ItemProperty -Path $au -Name AUOptions -Value 4 -Type DWord Set-ItemProperty -Path $au -Name ScheduledInstallDay -Value 0 -Type DWord Set-ItemProperty -Path $au -Name ScheduledInstallTime -Value 3 -Type DWord写完之后必须重启更新服务注册表才会被读取Restart-Service wuauserv usoclient StartScan注意AUOptions的取值含义2 是通知下载通知安装3 是自动下载通知安装4 是自动下载计划安装5 是允许本地管理员选择。生产环境一般用 4服务器上用 3 更稳妥一些避免在你不知道的时候重启。5.3 怎么确认客户端真的连上了最直接的方式是在 WSUS 控制台看计算机 - 所有计算机里有没有这台机器。如果十分钟后还没出现按这个顺序排查策略是否真正生效用gpresult /h导出看、注册表键值是否写进去了、客户端能不能解析 WSUS 的主机名、8530 端口是否放通。还有一个容易忽略的点客户端上如果已经配置了其他更新源比如某些终端管理软件改写了更新策略组策略会覆盖失败。这时候需要先确认策略的实际生效结果而不是只看配置界面。6. 运维期的坑这些问题几乎每个环境都会遇到6.1 同步失败和客户端不出现的排查顺序同步失败最常见的原因按出现频率排域名解析不通、代理配置不对、出口策略拦截、上游源地址写错、WSUS 服务或 IIS 应用池挂掉。排查的时候别乱猜按层来先看控制台的同步日志和事件日志再看服务器自身能不能访问更新源最后看服务状态。客户端不注册的问题我总结过一个顺序先看组策略生效结果再看注册表再看网络最后才怀疑 WSUS 服务器。绝大多数情况问题在客户端侧而不是服务器。另外要注意客户端首次注册和上报是分两步的注册可能很快但上次状态报告时间可能要等到下一次扫描周期才会更新别把状态时间没更新误判成没连上。6.2 内容目录暴涨和数据库瘦身哪怕你只勾了必需分类内容目录依然会持续增长因为每个月的累积更新都会进来被取代的旧更新依然占着空间。这时候要用服务器清理向导Server Cleanup Wizard。清理向导里几个选项的取舍删除已过期的更新安全可以删。删除被取代的更新安全旧的累积更新被新的取代后没有保留价值。删除不需要的更新文件这个能把磁盘空间真正释放出来可以删。删除未使用的更新谨慎可能删掉还没审批但你打算用的更新。删除过期的计算机建议保留策略超过 30 天或者 90 天不上报的机器删掉否则计算机列表会越来越长。清理向导跑起来很慢第一次在积压严重的环境上可能要几个小时而且会占用大量 CPU 和 IO。建议安排在业务低峰并且不要和控制台操作同时进行。清理完之后数据库会留下大量空闲空间需要收缩才能释放磁盘但收缩操作本身会产生碎片不建议频繁做——我的经验是每年做一到两次就够了。如果积压太多、清理向导已经跑不动了可以考虑重建拒绝所有更新跑一次清理然后重新同步必需的产品和分类。这个操作动静不小做之前一定确认数据可重建。6.3 补丁下发了却不装、装完反复重启更新显示了但客户端不装这个现象背后通常有三种原因。一是更新被审批给了错误的组。检查审批是批给所有计算机还是批给了目标组如果客户端上报的组名和审批组不一致更新就不会安装。二是客户端上的更新代理出了问题。常见表现是软件分发目录里堆满了下载失败的临时文件更新代理自己也更新不了自己。处理方式是停止更新服务、清理分发缓存目录、重启服务让它重新走一遍。三是更新被挂起重启阻塞。前一批更新装完状态是等待重启后面的更新排队等重启完成后才继续。这是正常行为但如果你没意识到就会觉得补丁卡住了。解决办法是尽快安排重启窗口别让它一直挂着。至于装完反复重启多半是某个更新安装失败后不断重试。这种要去看客户端的更新日志找到具体是哪个 KB 在失败然后把这条更新拒绝掉等下一个累积更新修复它。6.4 IIS 和应用池的性能调优WSUS 控制台卡顿、客户端上报超时很大一部分原因在 IIS 的WsusPool应用池配置上。默认情况下这个应用池有一个私有内存限制客户端规模一上来就会触发回收表现就是请求堆积、超时。调优动作有这么几个调优项默认值建议值作用WsusPool 私有内存限制有限制0无限制避免频繁回收导致请求失败队列长度100010000承载客户端并发上报空闲超时20 分钟0防止应用池被空闲回收定期重启时间1740 分钟0 或业务低峰避免业务时间回收appConcurrentRequestLimit500025000提升并发处理能力其中appConcurrentRequestLimit需要在 IIS 的配置里改!-- 在 ApplicationHost.config 的 system.webServer 节点下 -- serverRuntime appConcurrentRequestLimit25000 /还有一个专门针对 WSUS 的动态压缩问题IIS 的动态内容压缩组件在处理 WSUS 的大响应体时会出现内存占用飙升但仍然报错的情况。在客户端规模较大的环境里直接把这个组件卸掉问题往往就消失了。这个经验在官方文档里不明显但在实际运维中相当管用。6.5 常见问题速查表现象优先排查方向处理动作控制台打不开或转圈IIS 应用池状态、内存限制调整 WsusPool 配置、重启应用池客户端不出现组策略、注册表、DNS、端口逐层验证先客户端后服务端同步报错代理、出网策略、上游地址查看同步日志确认具体阶段失败内容目录增长过快分类勾选、驱动是否开启关闭驱动分类跑清理向导数据库过大、控制台慢历史记录堆积、未活动计算机清理过期更新与计算机记录补丁不安装审批目标组、挂起重启核对组名、安排重启窗口服务器内存被吃满SQL Server 缓冲池、IIS 应用池限制 SQL 最大内存调整应用池更新完成后反复重启安装失败重试定位失败更新并拒绝客户端上报状态不更新扫描周期未到、网络抖动触发一次手动扫描验证组策略不生效策略作用域、组名大小写导出生效结果核对6.6 一点实测心得WSUS 这个服务最大的特点是配置正确的时候它几乎不打扰你配置有问题的时候它会持续地、缓慢地消耗你的精力。我见过太多环境搭起来三年没动过某天突然发现电脑上跑的是几十个 G 的内容目录和一堆没清理过的记录。所以我的建议是给自己定一个简单的维护节奏每周看一眼同步状态和未审批更新数量每月跑一次清理向导每季度检查一次客户端的上次状态报告时间把长期不上报的机器清出去。把这些动作固化成例行工作比等到出问题再救火轻松得多。另外提醒一句WSUS 自身的补丁更新要单独处理它不会通过自己给自己下发。如果你连 WSUS 服务器自己也纳入了同一个 WSUS 的审批范围会遇到一个先有鸡还是先有蛋的循环——它需要更新才能保持健康但更新审批权在它自己手里。稳妥的做法是给 WSUS 服务器单独制定一套手工更新流程。
