WSUS 3.2清理不删除更新

即使在拒绝更新并运行“清理向导”之后，还有一些明显且不太明显的大内容文件夹的原因：

• 下游服务器。 如果您有下游服务器，则无论上游服务器上的审批状态如何，您都无法摆脱更新，除非每个下游服务器上的每个客户端都将其显示为不需要的更新。
• 快速安装文件。 如果您启用了这些（在更新文件和语言下），那么您的内容文件夹的大小将会增加很多。
• 其他语言。 如果您select的不仅仅是英文更新，那么您将看到语言特定更新文件的增加。
• Forefront客户端更新 – 这些都很大。 真的很大。

顺便提一下，你有多less次更新？ 对于我们来说，有大约1500个批准的更新，WsusContent文件夹只有大约16 GB。 SP和服务文件夹是额外的2.5 GB。

WSUS清理向导的标准问题超时而不删除任何不必要的更新。 SBS2K8。 WSUS 3.等待批准的6000多个不必要的更新。 巨大的数据库。 无响应的SQL服务器。 很多人都有这个问题。

驱动器在后台定期进行整理。 不会closures服务器，停下来的时间只是为了解决这个问题。

尝试从technet.microsoft.com/en-us/library/dd939795(WS.10).aspx，（不要复制命令行，它有奇怪的字符，只需手动input）reindexing脚本。它完成，但没有任何改善。

发现这个：wsus.codeplex.com/releases/view/17612，它也超​​时了。

发现这个评论：

对于任何正在使用过期更新的超时过期的用户。 我有一个解决scheme！ 使用服务器名称：“\。\ pipe \ MSSQL $ MICROSOFT ## SSEE \ sql \ query”连接到SQLpipe理工作室。 一旦连接手动运行“exec spGetObsoleteUpdatesToCleanup”。 这将返回一个过时的ID列表。 对于每个运行“exec spDeleteUpdate @ localUpdateID = 000000”，其中000000是ID。 对于我自己，我发现列表中的第一个ID需要37分钟的时间才能删除，之后我可以像往常一样通过GUI运行清理。

由jjdacl于4月23日12:55 PM

发现你确实需要这样做：

USE SUSDB GO exec spGetObsoleteUpdatesToCleanup 

首先要连接，我不得不点击选项，并从中间拉下来select命名pipe道。

第一次删除花费了6分钟，内存已经达到16GB物理内存的15GB左右。 但WSUS控制台（更新服务）仍然显示相同数量的旧更新。 失败？ 我不这么认为：我再次运行清理向导，到目前为止还没有超时……它已经运行了一个晚上，并取得了一些进展。 酒吧已经移动了5％。 所以…我的意思是，SQL服务器导致这个问题时，有太多的数据，因为索引devise不好（不是因为索引需要重新索引）导致第一个查询超时，导致清理失败。 一旦你完成了第一次删除操作，并将所有内容加载到内存中，清理工具可以保持足够长的时间以删除每个不需要的更新。 下一步将是find一个命令行方法，如： http : //wsus.codeplex.com/releases/view/17612，并把它放到像微软这样的任务调度程序应该在一开始做，以防止出的手。