如何使用 SMS 执行修补程序管理 使用本模块可以：
| ? | 使用 Microsoft? Systems Management Server (SMS) 2003 实施修补程序管理过程的所有四个阶段。 |
如何使用本模块 本模块提供了有关如何使用 SMS 来实施有四个阶段的修补程序管理过程的详细信息。 为了充分理解本模块内容，请：
| ? | 请参阅“修补程序管理过程”模块。该模块概述了修补程序管理过程的所有四个阶段，并介绍了在 Windows? 操作系统环境中用于支持修补程序管理的工具。 |
| ? | 请参阅以下四个模块，它们详细描述了有四个阶段的修补程序管理过程： | ? | 请参阅模块修补程序管理阶段 1 ―评估。 | | ? | 请参阅模块修补程序管理阶段 2 ―识别。 | | ? | 请参阅模块修补程序管理阶段 3 ―评估和计划。 | | ? | 请参阅模块修补程序管理阶段 4 ―部署。 |
|
| ? | 请参阅“SMS 2003 Concepts, Planning and Deployment Guide”（英文），该指南位于 http://www.microsoft.com/smserver/techinfo/productdoc/default.asp。 |
概要 本模块讨论了如何使用 SMS 2003 进行企业修补程序管理。本模块提供的指南和信息将显示如何使用 SMS 2003 来实施 Microsoft 推荐的分四个阶段的修补程序管理过程。
准备工作 开始使用本模块之前的准备工作：
必备知识 使用此模块之前，应了解以下内容：
| ? | Security Update Inventory Tool 和 Microsoft Office Inventory Tool for Updates 是可下载的 SMS 2003 软件更新扫描工具的一部分，而且默认情况下不安装。 |
| ? | 要安装 SMS 2003 软件更新扫描工具，需能访问 Internet 以便下载最新文件： | ? | Invcm.exe，该文件包含可执行文件 | | ? | Invcif.exe，该文件包含 XML 文件以及所有 Office 更新文件名称的相关信息。 |
|
| ? | 如果 SMS 2003 服务器无法访问 Internet，可以从 http://www.microsoft.com/office/ork/2003/journ/offutoolv2.htm 下载 Invcm.exe 和 Invcif.exe，或者从 Office 2003 Editions Resource Kit Toolbox 获得这些文件，然后将其复制到服务器。 |
评估阶段 ― 扫描更新 在开始使用 SMS 2003 中的更新服务将软件更新部署到生产环境中之前，必须进行审核。有关背景信息，请参阅模块
修补程序管理阶段 1 - 评估的“列示/发现已有计算资产”部分。 识别硬件类型和版本 要确定需要如何安装特定软件更新，则必须了解环境中计算机的类型。例如，如果要修补服务器，则可能需要观察停工时间窗口。SMS 允许创建包含服务器的集合，这些服务器应在特定的停工时间窗口中进行修补，从而确保正常业务运营期间不会安装软件更新。如果创建一个数据库，列出服务器以及应用于这些服务器的停工时间窗口，即可创建能自动创建所需集合的程序。有关如何进行此项操作的详细信息，请参阅 SMS 2003 SDK，其网址是
http://www.microsoft.com/downloads/details.aspx?FamilyId=6150FB42-03D7-400C-92FD-A2FE3BE997D1&displaylang=en（英文）。 默认情况下，SMS 2003 Hardware Inventory Client Agent 收集的信息足以区分便携式计算机和其他类型的计算机。然而，尚不存在哪一个属性或哪一组属性可以明确识别计算机的类型或模型。 识别操作系统、应用程序和中间件 您需要了解部署在生产环境中的所有操作系统、Service Pack (SP)、软件应用程序及版本。SMS 2003 Hardware Inventory Client Agent 可以用于收集 Windows“添加/删除程序”程序中已经注册的所有已安装的应用程序、Service Pack 和软件更新的相关信息。 对于没有在“添加/删除程序”中注册的应用程序，应使用 SMS 2003 Software Inventory Client Agent 获得安装在客户端计算机上的每个可执行文件 (.exe) 的详细信息。此外还需另行分析此清单，以确定实际安装的产品。通常情况下，尽管个人需求可能不尽相同，但也应将生产环境中所有计算机的软件清查配置为每周进行。 对于某些应用程序，为了选择最为恰当的软件更新，可能需要扩展由 SMS 2003 Software Inventory Client Agent 收集的信息，以获得软件应用程序已安装版本的详细信息。例如清点 Internet Explorer 不仅仅是查看由 SMS 通过标准清查过程收集的 Iexplore.exe 文件的相关信息。检索 Internet Explorer 版本信息的唯一准确方法是让 SMS 清点保存 Internet Explorer 数据的计算机上的注册表项。SMS 可以使用注册表项包含的信息来清点已经安装的软件更新和 Service Pack。要允许 SMS 对注册表项进行清点，则必须修改 SMS_def.mof 文件，从而引入注册表提供程序（SMS 用于访问注册表的代码）。 下为 SMS_def.mof 示例文件，它显示了为了清点注册表而要进行的修改。 //------------------------------------------------------ // 识别在应用程序模式下运行 TS 的服务器 // 终端服务：从注册表获得 TSEnabled // 终端服务：从注册表获得 TSAppCompat //------------------------------------------------------ #pragma namespace ("\\\\.\\root\\cimv2") // 强行获得禁用的 TS 和应用程序模式下的 TS [DYNPROPS] class TSAPPMode { [key] string keyname=""; string TSEnabled; string TSAppCompat; }; [DYNPROPS] instance of TSAPPMode { keyname="TSAPPMode"; [PropertyContext("local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\ Terminal Server|TSEnabled"),Dynamic, Provider("RegPropProv")] TSEnabled; [PropertyContext("local|HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Control\\ Terminal Server|TSAppCompat"),Dynamic, Provider("RegPropProv")] TSAppCompat; }; #pragma namespace ("\\\\.\\root\\cimv2\\sms") [ SMS_Report(TRUE), SMS_Group_Name("TS Application Mode"), SMS_Class_ID("MICROSOFT|TSAPPMode|1.0") ] class TSAPPMode : SMS_Class_Template { [SMS_Report(TRUE),key] string keyname; [SMS_Report(TRUE)] string TSEnabled; [SMS_Report(TRUE)] string TSAppCompat; }; 确定角色 了解计算机的角色将有助于确定部署软件更新之后重新启动计算机所带来的影响。默认情况下，SMS 2003 Hardware Inventory Client Agent 收集的信息足以确定计算机中运行的服务。但可能需要修改 SMS_def.mof 文件，以便从注册表收集其他信息，如上所示。了解连接性,由于软件更新的大小不同，了解网络基础结构限制可能会减少此类更新分发过程中的任何延迟。可以使用 Microsoft SMS Network Discovery 来提供有关网络拓扑和连接到网络的设备的信息。更多信息可在以下位置的产品文档中获得：
http://www.microsoft.com/smserver/techinfo/productdoc/default.asp（英文）。 识别所需的软件更新 管理员可以使用 Security Updates Inventory Tool（在 SMS 2003 的软件更新管理功能中提供）扩展 SMS 硬件清查，以便对需要在一组客户端上安装的软件更新进行报告，如图 1 所示。
图 1
向 SMS 数据库添加安全更新信息 SMS 2003 客户端将已经安装的软件更新与从 Microsoft Update Web 站点下载的 XML 文件所含可用软件更新的列表进行比较。Security Updates Inventory Tool 的安装例程还可创建周期性通告（每 7 天运行一次），该通告从 Microsoft Update Web 站点下载最新的软件更新目录文件 (Mssecure.cab)。一旦完成下载，站点服务器即自动新建一个针对所有客户端系统集合的通告。此通告使用最新的软件更新目录文件来运行用于更新的 Security Updates Inventory Tool。
注意： SMS 2003 Security Updates Inventory Tool 不会报告缺少的 Service Pack。您需要使用 SMS 硬件和软件清查客户端代理来查找当前安装的 Service Pack。从现在开始，无论何时都请尽量在组织内使用最新的 Service Pack 和修补程序。另外，安全修补程序报告仅取决于当前 Service Pack 修订；例如，如果当前 Service Pack 是 SP2，与 SP1 相关的软件更新则不会显示在报告中。 识别所需的 Office 软件更新 SMS 2003 的 软件更新管理功能包括 Microsoft Office Inventory Tool for Updates，管理员可以使用后者扩展 SMS 硬件清查，以便对让 Office 保持最新状态所需的软件更新作出报告。如图 2 所示，客户端计算机将已经安装的软件更新与最新的 Office 更新数据库文件 (invcif.exe) 的内容进行对比，此过程类似于上文提及的 Security Updates Inventory Tool 的相应过程。
图 2
向 SMS 数据库添加 Office 更新信息
注意：Office Update Inventory Tool 使用 Office Update Tool (invcif.exe) 和 Office Update 数据库，来分析客户端计算机可以使用的 Office 更新。然后，Office Update Tool 收集的数据将转换为与 SMS 站点数据库兼容的格式。Office Update Sync Tool 定期自动下载该工具的最新版本，并使用 SMS 分发点将其分发至组织内的计算机。 有关 Microsoft Office Update Tool 的详细信息，请参阅
http://support.microsoft.com/?kbid=312982（英文）。 检查清点/审核 对于修补程序管理来说，关于环境内有什么配置的最新和准确的信息至关重要。在可以开始使用存储在 SMS 数据库中的信息来支持修补程序管理任务和活动之前，管理员需要检查审核是否已经完成。 检查审核是否成功的第一步是确定 SMS 2003 中的 Microsoft Office Inventory Tool for Updates 和 Security Updates Inventory Tool 是否成功运行。要达到此目的，SMS 管理员应检查通告的状态信息，查看是否曾经出现失败。应将没有运行更新清查工具的 SMS 客户端计算机报告给问题管理。 在确认扫描工具已成功运行之后，管理员应检查每个 SMS 客户端上的硬件和软件清单的状态。因此，管理员应创建 Web 报告，列出无法在其中安装硬件和软件清查客户端代理的 SMS 客户端计算机，或指定的时间段内（对于数据中心类计算机是每天，对于其他所有计算机是每周）无法在其中运行硬件和软件清查客户端代理的 SMS 客户端计算机。例如，可以将返回软件更新错误消息的计算机添加到 SMS 2003 的“Software Update-Infrastructure Health（软件更新-基础结构状况）”类别下的特定通告报告中。所有出现在此报告中的计算机应提交给问题管理。 一旦完成对缺失更新的扫描，为扫描工具的“加急”版本创建通告可以强制进行硬件清查。默认情况下，这些工具获得的信息将于下一个预先计划的硬件清查周期报告给 SMS 站点服务器。
评估阶段 ― 设计 SMS 基础结构 有效的软件分发基础结构是有效修补程序管理过程的关键部分。有关背景信息，请参阅修补程序管理阶段 1 ― 评估模块的“评估现有的软件分发基础结构”部分。要评估 SMS 基础结构是否得到了妥善维护，请参阅“Systems Management Server 2003 Operations Guide”，其下载地址为
http://www.microsoft.com/downloads/details.aspx?FamilyId=BD2B3619-4704-4C19-A00B-628E65F6F826&displaylang=en（英文）。 有关 SMS 2003 设计注意事项的详细信息，请参阅“Microsoft Solutions for Management (MSM) Management Architecture Guide”，其网址为
http://www.microsoft.com/business/reducecosts/efficiency/manageability/default.mspx（英文）。 SMS 站点服务器应位于存在大量客户端的地点，或者是需要管理或控制网络带宽的位置。可以要求该层次结构是较深的层次结构（由许多层组成），以反映底层网络体系结构或允许委托管理。 对于关键业务服务器，减少部署软件更新的所需时间十分重要。要达到此目的，需要更为直接且更具响应性的 SMS 结构，如图 3 所示。
图 3
设计 SMS 层次结构以支持修补程序管理 要创建此结构，管理员必须将新 SMS 站点服务器引入存在关键业务服务器的位置，并确保这些计算机成为新 SMS 站点服务器的客户端。
| ? | 在某些位置，可能存在两个 SMS 站点服务器：一个可支持工作站客户端，另一个可支持关键业务计算机。仅当计算机的 Internet 协议 (IP) 子网与某个 SMS 站点管理的 IP 子网匹配时，这些计算机才会成为此 SMS 站点的客户端。 |
| ? | 为了确保支持关键业务服务器的 SMS 站点服务器的快速响应时间，管理员不应对站点间发送人设置任何带宽限制，并且应允许在每天任何时间进行站点间通信。 |
在正常业务过程中，应在位于层次结构顶级的服务器中继续执行管理功能。如果组织需要部署用以处理数据中心服务器中重要安全漏洞的软件更新，管理员应在负责关键业务计算机的 SMS 站点服务器上创建 SMS 包和通告。由于通告无需经过较深的 SMS 层次结构才能到达这些计算机，而且各 SMS 站点之间没有带宽限制，因此安装软件更新所需的时间应显著减少。
识别阶段 ― 获得通知 完成环境评估之后，下一阶段将涉及问题识别和获得可用更新的相关信息。有关背景信息，请参阅模块修补程序管理阶段 2 ― 识别的“发现新的软件更新”部分。 Microsoft 安全通知服务 通过电子邮件发送的通知是修补程序通知最常见的形式。获得电子邮件通知的方法之一是订阅位于
http://www.microsoft.com/technet/security/bulletin/notify.asp 的 Microsoft 安全通知服务。
识别阶段 ― 处理通知 收到通知之后，即需要确定哪些软件更新可以使用，以及 SMS 软件更新服务能够处理通知的条件。有关背景信息，请参阅修补程序管理阶段 2 ― 识别模块的“发现新的软件更新”部分。 SMS 软件更新管理 收到新的电子邮件通知之后，首先需要确定 SMS 2003 中的软件更新管理工具能否检测此软件更新是否适用于生产环境中的各个系统。
| ? | 确定软件更新是否适用 | 1. | 确定过程的第一步是参阅知识库文章 306460“Microsoft Baseline Security Analyzer returns note messages for some updates”，其网址为 http://support.microsoft.com/default.aspx?scid=kb;en-us;306460（英文），然后检查是否可以通过 MBSA 检测此软件更新是已安装还是缺少。知识库文章将对此进行了说明。 | | 2. | 如果此产品在支持列表中，则需要检查软件更新本身是否可由 MBSA 检测到。知识库 (KB) 306460 对此也进行了说明。 | | 3. | 如果该软件更新应用于某个产品，而 MBSA 不支持此产品，或者 MBSA 无法检测到此产品，则需要使用由 SMS 2003 Hardware Inventory Client Agent 和 SMS 2003 Software Inventory Client Agent 收集的信息来确定在哪些计算机上应用此软件更新。 | | 4. | 如果 MBSA 可以检测到此软件更新，则可以使用 SMS 2003 中的软件更新管理工具来确定可以应用此软件更新的计算机。 | | 5. | 如果此软件更新是 Microsoft Office 应用程序更新，则应检查此软件更新是否包含在 Microsoft Office Inventory Tool for Updates 提供的更新列表中。如果此列表包含该软件更新，则可以使用软件更新管理工具来确定可应用此软件更新的计算机。否则，即需要根据使用 SMS 2003 软件和硬件清查客户端代理检索到的信息来创建报告。 |
|
图 4 显示了上述过程的决策树流程图。
使用 MBSA 1.1 识别新软件更新的决策树流程图
识别阶段 ― 漏洞扫描工具 可以使用 SMS 2003 软件更新管理功能的组件来扫描和报告整个环境中缺少和已经应用的软件更新。有关背景信息，请参阅模块修补程序管理阶段 2 ― 识别的“如何确定来源和通知的可靠性”部分。 软件更新管理功能包括以下组件：
| ? | 软件更新清查工具 |
| ? | 分发软件更新向导 |
| ? | 软件更新安装代理 |
| ? | 报告 |
在以上四个组件中，可以使用软件更新清查工具和 SMS 2003 报告来扫描和报告已安装的和缺少的软件更新。 软件更新清查工具包括：
| ? | Security Updates Inventory Tool，用于处理 Microsoft 操作系统、Internet Explorer、SQL Server 和 Exchange 的安全更新。 |
| ? | Microsoft Office Inventory Tool for Updates，用于处理 Microsoft Office 的软件更新。 |
这些工具是相互独立的。既可使用其中一个工具，也可同时使用两个工具。
注意：默认情况下，不会在 SMS 站点中安装软件更新清查工具。而必须从
http://www.microsoft.com/smserver/downloads（英文）下载这些工具。 由 Security Updates Inventory Tool 和 Microsoft Office Inventory Tool for Updates 提供的清单数据集中提供了有关 SMS 客户端的符合性级别的详细信息。这些信息包括：
| ? | 包含当前安装的更新和 Service Pack 列表。 |
| ? | 可用且适用的软件更新。 |
| ? | 更新的发布日期和时间。 |
| ? | 更新（如果适用）的安装日期和时间。 |
另外，软件更新清单数据还包括指向关于适用更新的 Microsoft 知识库文章的链接。这样即可访问相关信息，从而帮助评估组织内对这些更新的需求。 每个软件更新清查工具都包含一个用于安装此工具的安装程序。
注意：有关 SMS 2003 软件更新管理功能的详细技术信息，以及有关如何使用 SMS 2003 执行各种软件更新任务的分步指导，请参阅 SMS 2003 操作指南的第 6 章“管理软件更新”，和 SMS 2003 概念和计划指南的第 3 章“理解 SMS 的功能”，其网址同为
http://www.microsoft.com/smserver/default.asp（英文）。 运行软件更新清查工具将在 SMS 管理员控制台和许多 Web 报告中生成一些信息。基于控制台的扫描结果示例如图 5 所示。
图 5
使用 SMS 管理员控制台确定缺少的软件更新及其关联布告 ID 编号 Microsoft 以目录 (Mssecure.xml) 和 Web 下载的方式发布安全更新的相关信息。每当发布新的安全更新，Security Patch Bulletin Catalog 和 Microsoft Office Update Catalog 就会定期更新。 SMS 2003 的软件更新管理功能将这些目录用作评估客户端的参考。软件更新管理工具对企业内所有 SMS 客户端上已安装的适用更新进行详细清查。软件更新清查工具扫描客户端，确定使得客户端最新所需的更新，然后管理员使用“分发软件更新向导”部署必要的更新。 SMS 2003 包括数个与更新相关的预定义报告，这些报告与整个组织内的缺失软件更新相关。这些报告显示了适用软件更新和安装状态等信息。 例如，您可以使用 SMS 2003 中的“Software updates with count of applicable and installed computers（软件更新及其可应用的和已安装的计算机数）”报告显示包含所有已安装或适用软件更新的列表以及这些软件更新的相关信息。该报告还列出了缺少各个软件更新的计算机数量，以及已经安装此软件更新的目标计算机的数量，如图 6 所示。
图 6
SMS 2003 中的 Web 报告，显示了软件更新以及适用和已安装的计算机的数量 您还可以使用以下示例中的 SQL 查询来识别过去 7 天内该环境报告的新的软件更新： select QNumbers0 as Knowledgebase, ID0 as Bulletin, Product0 as 'Affected Product', Title0 as 'Vulnerability', MAX(DatePosted0) as 'Release Date', MAX(DateRevised0) as Revised, MIN(TimeDetected0) as 'First Detected on Clients' from v_gs_patchstate where (TimeDetected0 >= DATEADD(day,-7,getdate()) or DatePosted0 >= DATEADD(day,-7,getdate()) or DateRevised0 >= DATEADD(day,-7,getdate())) and Status0 != 'Installed' group by QNumbers0, ID0, Product0, Title0
识别阶段 ― 确定软件更新的相关性 对于收到的每个软件更新，应检查其与环境的相关性。有关背景信息，请参阅模块修补程序管理阶段 2 ― 识别的“确定软件更新的相关性”部分。 可以使用以下主要的筛选方法，以便确定对 IT 基础结构进行软件更新的适用性：
| ? | 参阅安全公告和知识库 (KB) 文章 |
| ? | 查看各个软件更新 |
| ? | 使用 SMS 管理员控制台 |
| ? | 使用 SMS 内置报告 |
参阅安全公告和知识库 (KB) 文章 要将环境中可能受漏洞影响的计算机隔离，应查看相关安全公告中列出的受影响的产品，并访问 SMS 中可用的清单数据。 例如，SMS 2003 提供了下列产品的默认集合：
| ? | Microsoft Windows 2000 Professional |
| ? | Windows 2000 Server |
| ? | Windows XP |
| ? | Windows 98 |
| ? | Windows NT? 4.0 |
| ? | Windows Server? 2003 |
查看每个软件更新 通知中的每个软件更新都需要详细和深入的查看，例如该更新可能是特定的方案或配置所特有的。您应检查生产环境中的方案和配置是否与知识库文章中的匹配。这可能需要创建 SMS 查询和 Web 报告以获得这些信息。 例如，如果知识库文章规定该软件更新仅是大于 3 GB 内存并运行 SQL Server 的计算机所必需的，则需要创建查询或 Web 报告，以确定环境中运行 SQL Server 的任何计算机是否有此配置。然而，安全更新可能需要以预防方式，在出现任何这样的征兆之前应用。 使用 SMS 软件更新管理功能 可以使用 SMS 2003 软件更新管理功能生成的扫描结果和报告，查看关于某个软件更新特定的、可应用的信息。图 7 显示了一个与 Exchange Server 2000 相关的重要安全修补程序。“Requested（请求的计算机数）”列下的数值显示了需要此更新的计算机数，而“Compliant（兼容的计算机数）”列下的数值显示了已经安装此更新并且兼容的计算机数。在图 7 中，仅有一台计算机需要 Exchange Server 2000 更新。
图 7
使用 SMS 管理员控制台确定软件更新与环境的相关性 使用 SMS 报告 SMS 2003 的“Compliance by Software ID（符合性 - 按照软件 ID）”报告总结了已经安装安全更新（以及还未安装）的计算机总数，以及与安全修补程序分发相关的状态。该报告（如图 8 所示）有助于识别特定安全更新当前的符合性级别（本例为 311967），它也是一个有用工具，可以确定特定安全更新对环境的适用性。
图 8
SMS 2003 的“Compliance by Software ID”（符合性 - 按照软件 ID）报告
注意： SMS 2003 提供的报告有一个有趣的功能，您不仅可以查看每个报告的 SQL 查询，还可以复制和修改此查询来创建自定义报告。该功能还允许从每隔 1 分钟到每隔 60 分钟自动刷新报告，尤其在紧急情况下十分有用。此时可以不断观察软件更新分发的更新状态和报告，以及特定软件更新的符合性级别。要使用此功能，只需突出显示特定的报告并查看其属性。
评估和计划阶段 ― 确定修补对象 要确定修补对象，需要准确了解环境的当前状况。有关背景信息，请参阅模块修补程序管理阶段 3 ― 评估和计划的“计划发布”部分。 可以使用由 Security Updates Inventory Tool、Microsoft Office Inventory Tool for Updates 以及 SMS 硬件和软件清查客户端代理检索的信息，来确定需要安装特定软件更新的机器。同样重要的是确定要修补的机器的类型和角色，以及它们的网络连接性。
评估和计划阶段 ― 部署紧急变更请求 对于重要更新，需要尽量准确确定处于危险的系统的数目和类型。有关背景信息，请参阅模块修补程序管理阶段 3 ― 评估和计划的“计划发布”部分。 要获得比常规计划的清查周期早的清单数据，SMS 管理员需要创建一个强制通告，运行 Security Updates Inventory Tool 或 Microsoft Office Inventory Tool for Updates，在认为有漏洞隐患的计算机上强制进行硬件和软件清查。
| ? | 如果需要修补 SMS 2003 站点服务器，应考虑手动修补这些计算机。这样在向生产环境中的其他计算机推广此软件更新过程中，这些服务器不会重新启动。 |
| ? | 对于网络连接性较差的站点，可能需要计划使用 SMS Courier Sender，将软件更新文件放置在可移动媒体上，并计划将此媒体尽可能快地运输到这些站点。 |
以下过程显示了使用“分发软件更新向导”来分发软件更新，并强制关键业务服务器进行安装所采取的步骤。对于应用于工作站的软件更新也可以遵循类似的过程。
注意： 该过程仅成功用于有足够的网络带宽的业务位置，以便允许客户端计算机使用软件更新文件和已更新的软件分发策略。
| ? | 使用“分发软件更新向导”分发软件更新，并强制关键业务服务器安装此软件更新 | 1. | 从控制面板中的“Run Available Programs（运行可用的程序）”或“Advertised Programs Manager（通告程序管理器）”工具运行 SyncXML.exe 程序。
此操作必须在执行同步任务的计算机上进行，该任务最初是由设置成 SMS 站点服务器的计算机的扫描工具创建。这样将确保可以在本地使用最新发布的目录。 | | 2. | 手动刷新此程序包的分发点，不断将新的目录传递给环境中的其他站点和其他分发点。确保所有分发点已完成其更新。
这些刷新的分发点是任何旧客户端和 SMS 2.0 客户端必需的。如果需要，高级客户端可以自动进入“等待内容”状态，因为新程序项将有一个策略，反映所需的新程序包版本。 | | 3. | 在现有的扫描工具程序包中新建一个程序项，观察该程序的“加急”形式（命令行包括 /s /cache /kick）。
该程序将用于确保预生产集合成员可以在下一个可用扫描周期中得到目录的最新版本 。 | | 4. | 为了便于使用，新程序的名称以新软件更新相应的特定公告 ID 或知识库 (KB) 号来命名，例如 Expedited MS03-039。 | | 5. | 将新的“加急”扫描工具程序通告给参考计算机集合。
由于这是新程序，预生产计算机将被迫下载包含新目录的相应程序包版本。 | | 6. | 在现有的扫描工具程序包中新建第二个程序项，观察该程序的“非加急”形式（命令行包括 /s /cache）。 | | 7. | 为了便于使用，新程序的名称以新软件更新相应的特定公告 ID 或知识库 (KB) 号来命名，例如 Non-expedited MS03039。 | | 8. | 使用“分发软件更新向导”专门为此软件更新新建一个程序包。如果客户端清查正在执行，如有必要可以使用“刷新”按钮，以确保所有可用的预生产计算机的清单一致。基于来自预生产集合的结果，授权此软件更新。（在生产系统进行扫描时，可以准备此程序包。） | ? | 如果打算在计划的硬件清查客户端代理的时间之前将清单数据发送到站点服务器，则选中“分发软件更新向导”的第一个客户端代理设置页中的“Collect client inventory immediately (may increase system activity)（立即收集客户端清单（可能增加系统活动））”复选框。 | | ? | 如果打算使用世界时特性，以强制软件更新全球一致，而不是逐个时区进行，可以对此进行验证。这是一个每软件更新设置。 | | ? | 请确保在向导的适当页面指定现有的扫描工具包和程序，而不是新程序。 | | ? | 此时，请不要在“分发软件更新向导”中通告。 | | ? | 使用新程序包将确保尽快进入下载和执行阶段，因为您将管理的其他软件更新的重要性定义为比当前活动的重要性低。 |
| | 9. | 关闭“分发软件更新向导”后，打开新的“分发软件更新向导”程序的属性页，添加对新建的“非加急”程序的程序依赖性。
程序依赖性将导致客户端在试图安装软件更新之前，运行带有新目录的扫描工具程序包版本。这样可以确保当代理首先试图在本地刷新清单时，将强制运行程序依赖性，反过来又可以确保将最近的目录缓存到客户端。对于依赖程序，可以自动得到“分发软件更新向导”程序通告的下载和执行配置，因为它没有自己的通告。 | | 10. | 为“分发软件更新向导”程序新建一个通告，并将其设置为下载和执行。 | ? | 如果打算让所有活动同时发生，而不是逐个时区进行，可以验证世界时的使用。通常，如果在软件更新的“Authorized on（授权）”设置上使用“Coordinated Universal Time（世界时）”选项，则可以将其包括在通告中。 | | ? | 通告的开始时间应确保早于第一次强制分配的时间。这将允许高级客户端先下载，并在服务窗口出现时已准备启动。（如果使用服务窗口，则这一点更重要。） | | ? | 如果需要，对每个变更窗口重复此操作（有限的安装时间）。 |
| | 11. | 使用“软件更新 ― 部署状态”下的可用报告监视新建的程序包，以获得状态和符合性信息。调查通常包括两个阶段，第一阶段的重点是软件分发成功（通告成功），第二阶段的重点是部署状态。 | ? | 软件更新分发状态（按照软件更新 ID）
此报告将给出“Install Verified（已验证安装）”、“无状态”或“失败”的计数，并提供每个类别的进一步信息。如果除了“Install Verified（已验证安装）”，其他类别的数目很高，则需要为每个类别运行此报告。 | | ? | 特定计算机在指定天数内的软件更新状态信息
此报告将为读者提供安装的实际状态信息。当此报告无法解释软件更新安装失败的原因时，必须检查实际的计算机详细信息，以获得通告状态。 |
| | 12. | 在紧急情况之后（达到足够的符合性以后），可以用正在进行的操作的最近软件更新对主要程序包进行修订，并废除最初的程序包。为此，需要将文件从一个程序包源文件夹复制到另一个文件夹，然后使用“分发软件更新向导”中的“高级”和“导入”按钮。由于此通告的大小，通常将其设置为从网络上运行。 | | 13. | 删除为预生产集合成员创建的加急程序项，以及为生产集合成员创建的非加急程序。
系统将自动删除这些通告，因为不再需要这些项。 |
|
评估和计划阶段 ― 构建发布 发布计划到位之后，下一步就是开发脚本、工具和程序，管理员要通过它们将软件更新部署到生产环境中。有关背景信息，请参阅修补程序管理阶段 3 ― 评估和计划模块的“构建发布”部分。 在此需要进行的任务和活动主要依赖于软件更新是否可以使用 SMS 2003 的“分发软件更新向导”来部署。 由于“分发软件更新向导”可以自动创建分发和安装软件更新所需的 SMS 包和程序，因此分担了许多工作，否则将需要使用 SMS 2003 来部署软件更新。可以将不是紧急变更请求中的一部分的安全更新添加到安全汇总包中，其中包括所有应用于特定产品和 Service Pack 组合的安全更新。例如，所有应用于 Windows 2000 SP3 的安全更新都可以包括在一个安全汇总包中，从而可以将适当的安全更新一次性应用于某台计算机，因而只需一台计算机。使用安全汇总包大大简化了管理过程，同时在很大程度上减少了为了使计算机符合标准所需的重新启动计算机的次数。 对于无法使用此功能部署的软件更新，管理员应使用 SMS 中的标准软件分发程序，创建程序包和通告，以便部署此软件更新。而且有必要指定批处理文件（MSI 文件）或可执行文件，以便在客户端计算机上运行。如果没有为软件更新提供可执行的安装文件，则管理员需要使用 MSI 授权工具创建一个可执行文件。 以下是对构建发布的进一步考虑：
| ? | 用于安装软件更新的任何程序应返回正确的退出代码，这样通过 SMS 状态系统就会返回正确的状态。成功安装时，退出代码应为 0，而任何非零值说明安装失败。SMS 状态系统使用返回代码来表示通告的成功或失败。 |
| ? | 可能还需要确保该程序向系统注册表中插入自定义的注册表项，这样管理员就可以确定某个计算机上存在的软件更新。在将这些信息存储在 SMS 数据库中以供 Web 报告和查询使用之前，需要将 SMS Hardware Inventory Client Agent 配置为从 SMS 客户端收集这些信息。 |
| ? | 该程序或批处理文件必须在安装完成以后才能退出。当与某个通告相关的程序退出时，SMS 2003 假定该通告已经完成运行。如果程序产生另一个过程，然后在新的过程完成安装软件更新之前退出，则此程序将无法返回表示安装成功的退出代码。 |
| ? | 安装失败时，应将批处理文件或程序配置成向事件日志写入事件。为了提醒管理员安装失败，需要在 Microsoft Operations Manager-Server (MOM) 中创建相应的规则，为该事件生成警报。 您可能还想进一步开发此脚本，编写一个事件来说明修补程序正在进行，从而可以在服务器重新启动时，避免在 MOM 控制台出现假警报。 |
对于“分发软件更新向导”支持的软件更新，管理员应使用此工具新建 SMS 包和通告，以便部署此软件更新。管理员还应将此软件更新添加到前面提到的安全汇总包中。一旦软件更新成功部署到生产环境中的所有客户端，此软件更新的单独的程序包和通告将不再有用，因为安全汇总包可以确保将此软件更新应用于任何新引入生产环境的计算机。 对于无法使用“分发软件更新向导”部署的软件更新，需要创建 SMS 包和通告来部署此软件更新。如果没有为软件更新提供可执行的安装文件，管理员需要创建一个，如上所述。
部署阶段 ― 部署准备 对于每个新发布，生产环境都需要做好准备。准备部署软件更新所需的步骤如下：
| ? | 通知推广计划 |
| ? | 从测试环境导入程序和通告 |
| ? | 分配分发点 |
| ? | 将更新临时放在分发点上 |
| ? | 选择部署组 |
有关背景信息，请参阅修补程序管理阶段 4 ― 部署模块的“部署准备”部分。 通知推广计划 要安全成功地部署更新，需要通知用户，因为需要他们执行特定操作以帮助进行更新安装过程。
| ? | 清楚地通知推广计划 | 1. | 向用户和管理员发送内容清晰并且易于辨认的电子邮件，通知他们更新的消息，并提供有关如何安装的信息。如果在核心工作时间以外的时间将更新部署到台式机上，则应在电子邮件中通知最终用户在指定日期让计算机一整夜保持开机状态。 | | 2. | 应该为此邮件做后续标记，提醒用户和管理员安装软件更新可能需要采取的任何操作。 |
|
从测试环境导入程序和通告 为了维持最大的可靠性和安全性，应总是导入在测试环境中开发的 SMS 2003 程序包。测试环境应该很好地反映生产环境。对于使用 SMS 2003 标准软件分发程序部署的软件更新，程序包的定义（包括与程序包相关的程序）应在测试环境中生成和测试。应将这些程序包导入到 SMS 2003 生产环境中。 要从测试环境导入现有的程序包，请依次使用“分发软件更新向导”中的“Identify the SMS Package（识别 SMS 程序包）”页上的“高级”和“导入”选项，如图 9 和图 10 所示。“高级”按钮允许从其他授权列表导入先前处理的软件更新，例如从测试环境导入到生产环境。
图 9
“分发软件更新向导”― “高级” 按钮
图 10
“分发软件更新向导”― “导入” 按钮 使用“分发软件更新向导”中的“导入”按钮，如图 11 所示，导入已经扫描病毒的软件更新文件。
图 11
此屏幕快照说明了如何导入已经扫描病毒的文件。 分配分发点 一旦将程序包导入 SMS 2003，应确定使用的分发点，以便客户端计算机可以使用此软件更新。请将软件更新二进制文件放在目标客户端所在的所有站点的分发点上。对于通过 Security Updates Inventory Tool 或 Microsoft Office Inventory Tool for Updates 识别的软件更新，可以在“分发软件更新向导”中分配分发点，尽管创建程序包以后可以手动修改这些分发点。 由于软件更新通常部署在同一组客户端上，因此每个软件更新都使用相同的分发点。例如，服务器和服务器应用程序的软件更新需要转向数据中心站点的所有分发点。会计应用程序的软件更新只需转到会计部门站点的分发点。 这允许在 SMS 2003 中设置分发点组，仅包含特定范围客户端的分发点。使用分发点组可以加快为部署的软件更新分配分发点的过程。SMS 数据库中的清单信息可以用来识别需要放置新分发点的位置。
注意： 即使使用了“Update Distribution Point（更新分发点）”选项，仅向分发点组添加分发点并不能导致向新分发点发送程序包。仅在将该组分配给程序包时，该组才会对此分发点进行评估。只能将新分发点逐个添加到程序包，然后更新分发点。 将更新临时放在分发点上 一旦分配了适当的分发点，应确保将所有单个文件的副本分发到这些服务器。使用 SMS 状态系统可以对软件更新文件的分发进行监视。如果分发点没有这些文件，该站点的客户端就不能安装软件更新。 向分发点发送软件更新二进制文件的过程包括在 SMS 站点之间发送文件以及从 SMS 站点向本地分发点发送文件。 在 SMS 站点之间发送更新 在大多数组织中，对于那些负责在站点之间发送指令、软件包和通告的站点间的发送人来说，通常将他们配置成只能有限使用网络带宽量，或者只能在一天中有限的次数内传递数据。这些限制主要用来确保在正常的工作时间之外进行软件分发，但在需要将重要软件更新尽快应用时，有时会出现问题。 表 1 显示的 SMS 消息可以用来帮助监视站点到站点的复制。 表 1：SMS 发送人消息
| 消息 ID | 详细信息 |
| 3531 | SMS 发送人当前正在向目标站点发送软件分发程序包。 |
| 3532 | SMS 发送人向目标站点发送软件分发程序包时，发生错误。 |
| 3533 | SMS 发送人成功地向目标站点发送了软件分发程序包。 |
SMS 允许将程序包的优先级定义为高、中或低。对于不被划分为业务关键型的软件更新，应该仅使用中优先级或低优先级。仅将高优先级保留给重要的软件更新。以下几点总结了程序包优先级对分发软件更新的影响：
| ? | Distribution Manager（分发管理器）是压缩和处理程序包的组件。它以优先级的顺序处理程序包。程序包优先级可以映射为 Sender/Scheduler/Replication Manager 的复制优先级。 |
| ? | 如果 Distribution Manager（分发管理器）已经开始压缩一个中优先级的程序包，就不会停止当前的操作而去压缩一个新建的高优先级的程序包。 |
| ? | 在发送人传输完当前程序包以后，才评估程序包的优先级。因此，如果正在传输一个中优先级的程序包，同时又定义了一个高优先级的程序包，则在重新评估优先级之前，先完成中优先级的程序包的传输。 |
| ? | 通告优先级仅影响站点间复制的优先级。然而，由于通告对象相当小，因此影响也很小，除非站点之间有大量挂起的通信。 |
| ? | 其他与程序包/通告有关的组件有 Distribution Manager（分发管理器）、Offer Manager（提供管理器）、Replication Manager（复制管理器）、计划程序、Despooler 和发送人。所有这些组件都按照优先级进行。 |
可以使用以下 SQL 查询生成一个报告，该报告是关于向所有站点分发时，已经完成传输内容的百分比。（在使用此查询之前，应将所有实例的 PackageID "BAR0001" 更改为实际环境的 PackageID。） declare @ver int select @ver=MAX(SourceVersion) from v_PackageStatusRootSummarizer where PackageID = 'BAR00001' create table #PkgProgress (RecordID int not null, Time datetime not null, SiteCode char(3) not null, PctComplete int not null, MessageID int not null, PRIMARY KEY(SiteCode,Time,RecordID)) insert into #PkgProgress(RecordID,Time,SiteCode,PctComplete,MessageID) select msg.RecordID, msg.Time, insSC.InsStrValue as SiteCode, IsNULL(insPC.InsStrValue,100) as PctComplete, msg.MessageID from v_StatusMessage msg join v_StatMsgAttributes att on msg.RecordID=att.RecordID and msg.Time=att.AttributeTime join v_StatMsgInsStrings insVER on msg.RecordID=insVER.RecordID and insVER.InsStrIndex=1 join v_StatMsgInsStrings insSC on msg.RecordID=insSC.RecordID and insSC.InsStrIndex=2 left join v_StatMsgInsStrings insPC on msg.RecordID=insPC.RecordID and insPC.InsStrIndex=3 where MessageID in (3531,3532,3533) and Component in ('SMS_ASYNC_RAS_SENDER','SMS_ISDN_RAS_SENDER','SMS_LAN_SENDER','SMS_SNA_RAS_SENDER ','SMS_X25_RAS_SENDER','SMS_WINSOCK_SENDER') and att.AttributeID=400 and att.AttributeValue= 'BAR00001' and insVER.InsStrValue=CONVERT(varchar(10),@ver) select Sites.SiteCode, prog.Time, prog.MessageID, prog.PctComplete as 'Sending % Complete', Sites.Targeted as 'DPs Targeted', 100*Sites.Installed/Sites.Targeted as '% DPs Complete' from v_PackageStatusDetailSumm Sites left join (#PkgProgress prog join (select SiteCode, MAX(Time) as MaxTime from #PkgProgress group by SiteCode) as LastProg on prog.Time=LastProg.MaxTime and prog.SiteCode=LastProg.SiteCode) on Sites.SiteCode=prog.SiteCode where Sites.PackageID = 'BAR00001' and Sites.Targeted>0 order by prog.SiteCode drop table #PkgProgress 紧急变更请求 在紧急变更请求的情况下，应解除所有站点间的限制，以使软件更新尽快发送到其他站点。如果站点间的网络链接很缓慢或已经很拥挤，解除对站点间发送人的限制将不会有任何作用。在这种情况下，可以考虑使用 SMS Courier Sender（SMS 快速发送人）将更新发送给每个站点。 将更新发送到分发点 更新到达 SMS 站点服务器时，将自动分发给站点内的所有分发点。应监视表 2 中所示针对每个分发点的 SMS 事件。 表 2：SMS 分发事件
| 消息 ID | 详细信息 |
| 2342 | 这表明 SMS 分发管理器开始向分发点分发程序包。 |
| 2330 | 这表明 SMS 分发管理器已经向分发点成功分发程序包。 |
注意：在客户端可以安装软件更新之前，本地管理点必须能够使用此策略。 选择部署组 使用“分发软件更新向导”分发新的软件更新时，无需精确定位计算机。这是因为该向导在客户端部署了智能代理，在需要安装新的软件更新时，就会调用此代理。此代理自动确定通过向导通知的软件更新是否适用于该计算机，以及是否已经安装。它还可以处理多个软件更新的链接，以及使这些软件更新成为当前更新所需的重新启动。 对于以这种方式安装的目标软件更新，应基于以下因素为其创建组：
| ? | 计算机检查和安装新的软件更新的频率。（创建在指定间隔内检查新软件更新的 SMS 通告。） |
| ? | 服务器、工作站和便携式计算机需要单独的查询，因为它们有不同的计划，而且可能运行不同的程序来安装软件更新。 |
| ? | 不同部门或不同地理位置的计算机需要单独的查询，因为它们可能有不同的时区。如果强制在所有时区同时部署更新，请选中“分发软件更新向导”中的“世界时”复选框。 |
如果不使用分发软件更新向导，而是通过自定义的程序包和集合来分发软件更新，则可能需要创建一个或多个 SMS 查询。例如：
| ? | 使用基于该查询的单个查询和单个集合，修改每个推广阶段的查询。开始时，先修改此查询，减小第一个推广阶段的目标客户端的范围，例如一个站点或工作组。推广到更多客户端时，应扩展此查询，其范围包括下一个推广阶段的客户端。 |
| ? | 应跟踪对查询的更改，并保留以前版本，因为这样可以使管理员随时回滚软件更新。 |
部署阶段 ―向客户端计算机通告软件更新 向产品部署软件更新所需的第一步是向客户端计算机通告软件更新。可以分阶段推广，或者所有客户端在相同的部署期间收到更新。有关背景知识，请参阅修补程序管理阶段 4 ― 部署模块的“向目标计算机部署软件更新”部分。 使用“分发软件更新向导”时，将自动创建重复的通告，在目标集合的计算机上运行软件更新安装代理。可以修改默认的重复间隔（7 天），以适合该集合。例如，包括服务器的集合可以每天运行代理一次，或更频繁。 需要考虑的其他事项：
| ? | 如果有控制组，应首先对这些计算机进行部署。 |
| ? | 如果不同类型的计算机需要不同的计划，使用相同的程序包和程序可以为多个集合创建多个通告。 |
| ? | 如果将运行软件更新安装代理的重复间隔设置为每日，并且需要尽快运行此代理以推广重要的软件更新，则应强制进行新的、一次性分配，以便尽快运行通告。 |
| ? | 如果推广是交错进行，第一阶段完成以后，应修改查询，将下一阶段的客户端包括进来，例如，要部署的下一批站点。将软件更新安装程序自动通知新的一组客户端之后，集合可以手动或按照定义的时间进行更新。 |
| ? | 用于目标集合的 SMS 查询是基于表明哪些计算机还未安装此软件更新的清单信息。随着计算机安装软件更新，随后重新进行清查，并更新集合，这些计算机也将从集合中删除，因为它们与查询定义不再匹配。将未安装此软件更新的新计算机添加到网络中，并由 SMS 清查以后，当集合进行下一次更新时，软件更新安装程序将自动通知给该计算机。 |
如果没有使用“分发软件更新向导”部署软件更新，则需要考虑以下内容：
| ? | 如果建立通告来安装软件更新，应将其计划配置为定期重复。这样，如果安装失败，就会自动重新尝试安装。如果通告没有重复，必须手动进行重新尝试，这需要为失败的客户端创建一个集合，并为该集合创建新的通告。这些步骤必须重复进行，直到将所有客户端修补完毕。 |
| ? | 需要谨慎选择通告的重复间隔，因为已经成功安装发布的客户端将保留在目标集合中，直到收集到新的清单（可能由安装程序自身来触发），或者直到在 SMS 数据库中更新此清单，以及集合被重新评估。因而该程序有可能在已经成功运行过一次的客户端上再次运行。因此，程序有必要先运行检查，查看是否已经安装了此软件更新，如果已经安装，则立即退出。 |
对于不重要的软件更新，SMS 2003 允许管理员给予用户决定安装更新时间的选择权，并且在特定的期限以后，自动安装该更新。通过在“分发软件更新向导”中选中“Allow users to postpone for（允许用户推迟安装）”复选框可以做到这一点，如图 12 所示。
图 12
该屏幕快照说明了如何选中 “Allow users to postpone for（允许用户推迟安装）” 复选框。 应通知用户和服务所有者有软件更新可以安装，并且在指定时间以后，将强制安装此软件更新。这样，远程便携式计算机的用户或通过慢速链接进行连接的计算机用户，就可以选择方便的时间来安装软件更新。然而，一旦指定的日期来临，将自动安装软件更新。 对于通过“分发软件更新向导”实现的软件更新，在更新可用时，将通过批注框文本通知用户，如图 13 所示。
图 13
可用更新的用户通知。 您应创建一个查询，返回最近登录到服务器的用户的名称，以及还未安装来自目标服务器的已授权更新的列表，这样就可以很容易通知计算机所有者他们的符合性级别和即将到来的期限。 紧急变更请求 如果变更请求表明该软件更新是紧急更新，则需要考虑以下内容：
| ? | 部署开始时，应向参考计算机集合发出通告。参考计算机集合包含生产环境中所有代表性的计算机，因此，这是任何阶段性部署或结构化部署的重要步骤。这样可以增强开始在生产环境的其他部分部署所需的信心。 |
| ? | 应尽快在客户端上安装软件更新，而不管它们连接到 SMS 站点或分发点的连接速度。每隔三个小时，运行高级客户端的计算机用户就会收到有关最终期限的提醒。 |
| ? | 创建通告时，应确保清除“Assignments are not mandatory over slow links（慢速链接时，不能强制分配）”复选框，如图 14 所示。
图 14
“Assignments are not mandatory over slow links（慢速链接时，不能强制分配）”复选框。 |
| ? | 最好请便携式计算机的用户到办公室安装重要软件更新，特别是当该软件更新比较大或者用户通过标准电话连接或慢速链接进行连接时。对于无法到办公室安装的用户，可能需要创建一个通告，将其配置成将软件更新下载到本地硬盘，并在本地硬盘执行软件更新，如图 15 所示。
图 15
如何创建通告，将其配置成将软件更新下载到本地硬盘，并在本地硬盘执行软件更新。 |
| ? | 另外，可以考虑使用受保护的分发点，将远程计算机或便携式计算机与分发点进行绑定。在理想情况下，受保护的分发点应是距离远程用户或便携式用户最近的分发点。使用受保护的分发点可以确保远程用户总是使用该分发点进行软件更新。然而，如果受保护的分发点不可用，则远程用户将自动恢复使用最近的未受保护的分发点。 |
部署阶段 ―监视和报告部署的进度 由于造成计算机安装更新失败的原因很多，因此能够对部署的进程进行监视很重要。有关背景知识，请参见修补程序管理阶段 4 ― 部署模块的“向目标计算机部署软件更新”部分。 通过向客户端集合进行通告的方式部署程序包以后，应确定客户端是否已经成功运行此通告。有许多种工具可以用来检查从 SMS 客户端返回的状态消息。 SMS 支持工具包括一个名为“Advertisement Status Viewer（通告状态查看器）”的工具，可以用来查看通告的部署状态（基于通告的状态消息）。但是在检查通告的部署状态时，了解以下内容通常非常有用：
| ? | 哪些客户端属于此集合，但还未收到通告。 |
| ? | 哪些客户端已经收到通告，但还未运行此通告。 |
| ? | 哪些客户端未能成功运行此程序。 |
状态消息只能指出重复的通告是否运行。实际上，“Patch Install（修补程序安装）”程序用于安装任何新的、已批准的软件更新。要检查此程序是否在客户端上成功运行，可以分析状态消息以确定此程序在每个客户端上最后一次成功运行的时间。如果自其运行以来的时间大于任何客户端的重复时间，则应调查一下原因。 状态消息还可以记录最终用户自愿修补与强制修补的对比程度，以及这些用户如何处理重新启动和安装计划。基于这些数据，可以调节强制和默认设置，以便更有效地使计算机符合标准。表 3 显示的消息可以用来查看这些信息。 表 3：通告的状态消息
| 消息 ID | 说明 |
| 11250 | 缺少计划安装窗口（最早开始时间）：等待重新尝试。 |
| 11251 | 缺少计划安装窗口（最晚开始时间）：等待重新尝试。 |
| 11256 | 缺少计划安装窗口（超过使用期限）：等待重新尝试。 |
| 11269 | 需要重新启动系统以便继续安装。 |
| 11257 | 用户重新计划安装更新所需的系统重新启动。 |
| 11258 | 用户推迟安装更新所需的系统重新启动。 |
| 11259 | 安装更新所需的系统重新启动被自动推迟。 |
| 11252 | 用户重新计划安装。 |
| 11253 | 用户推迟安装。 |
| 11254 | 自动推迟安装。 |
| 11270 | 需要重新启动计算机。 |
| 11266 | 安装完成并禁止工作站角色重新启动系统。 |
| 11267 | 安装完成并禁止服务器角色重新启动系统。 |
| 11268 | 安装完成，并且无需重新启动系统。 |
| 11261 | 安装完成，并由用户重新计划一次重新启动。 |
| 11262 | 安装完成，并由用户推迟重新启动。 |
| 11263 | 安装完成，并自动推迟重新启动。 |
| 11264 | 所需的重新启动开始进行。 |
| 11265 | 所需的强制重新启动开始进行。 |
对于通过 Security Updates Inventory Tool 或 Microsoft Office Inventory Tool for Updates 识别的软件更新，可以使用内置的报告来检查软件更新是否成功部署。可以使用“Compliance by Software ID（符合性 - 按照软件 ID）”报告来提供对已安装或未安装更新的系统总数的摘要，以及与软件更新分发相关的状态信息。该报告有助于识别特定软件更新当前的符合性级别。然而，由于该报告依赖于更新的清单，因此它不如查看状态消息得到的信息新。 分析结果 随着部署的进展，导致某些计算机安装软件更新失败的许多原因也随之出现，包括：
| ? | 由于各种原因，计算机处于脱机状态，如用户还未工作、用户需要拨号、用户是移动用户或计算机正在进行维护。 |
| ? | 计算机正在被重建或重新映像。 |
| ? | 自从上一次基准扫描以来，有 SMS 客户端的计算机没有与 SMS 站点服务器通信。 |
| ? | 计算机的代理服务停止（由用户停止或正在维护）。 |
| ? | 由于各种原因，计算机拒绝接受访问。 |
| ? | 计算机的 MSXML 3 最高只到 SP1（SMS 2003 需要 MSXML 3.0 SP4）。 |
| ? | 计算机的磁盘空间不足。 |
如果其中某个原因导致某些客户端计算机在给定的 SLA 下无法进行修补，则需要确定采取哪些缓解步骤可以使这些计算机符合标准。尽管可能无法修补所有机器，也应确保完全了解这些机器不能或不应该修补的原因。 以下指南有助于解决安装软件更新失败的问题，并有助于使更多计算机符合标准：
| ? | 在部署的第一阶段之后，请务必重新扫描环境，以识别在第一阶段遗漏的计算机。 |
| ? | 不断监视和报告部署的进展情况。 |
| ? | 重新扫描和监视，可让程序对报告出现例外的目标计算机进行重新部署。 |
| ? | 总是进行类选，以发现部署失败的根本原因。 |
| ? | 只要 SMS 代理服务处于良好状态，处于脱机状态或正在重建的计算机应得到通告。 |
| ? | 请参阅本部分的整个指南以增加部署的成功率。 |
部署阶段 ―处理失败的部署 如果确定部署已经失败，并且需要停止和回滚，则需要停止推广，卸载失败的更新，然后重新部署。有关背景知识，请参见修补程序管理阶段 4 ― 部署模块的“向目标计算机部署软件更新”部分。
| ? | 要处理例外，请执行下列步骤： | 1. | 停止活动程序包的部署。 | | 2. | 识别和解决问题。 | | 3. | 重新通告此程序包。 | | 4. | 卸载软件更新。 |
|
停止活动程序包的部署
| ? | 要停止活动程序包的部署，请执行下列操作： | 1. | 从 SMS 管理员控制台的程序包节点，选择要暂停的程序。 | | 2. | 在“Program Properties Advanced（高级程序属性）”选项卡上，选中“Disable this program on computers where it is advertised（在通告的计算机上禁用此程序）”复选框。这样即使将这些通告指定为强制运行，并设置成在指定时间或按计划开始运行，也将停止或暂停基于此程序的通告。 | | 3. | 打开“分发软件更新向导”，清除要禁用的软件更新的选中标记，并保存此更改。如果有其他软件更新在该程序包中正常运行，此操作将允许保持此通告为启用状态。 |
|
识别和解决问题 表 4 列出了报告查看器的 Software Update Infrastructure Health（软件更新基础结构状况）分类中的标准报告。您可以使用这些报告快速识别在试图安装软件更新的客户端上发生的任何问题，以及从 Internet 下载软件更新目录过程中发生的任何问题。重要的是尽早发现并解决问题，充分了解典型的软件更新返回代码和状态消息。 典型的问题包括：
| ? | 磁盘空间不足：客户端计算机必须有至少 10 MB 的可用磁盘空间。 |
| ? | XML 分析器版本已过期：如果在 System File Protection (SFP) 配置中检测，MSXML 3.0 SP2 是所需的最低版本。如果 SFP 不提供 XML 分析器文件，则 XML 3.0 SP4 是所需的版本，并将自动更新。（SFP 配置将不更新。） |
| ? | 安装通告在所需的扫描工具通告之前运行。这将导致安装代理失败，因为软件更新目录不可用。 |
表 4：软件更新报告
| 报告名称 | 报告分类 |
| Compliance by product（产品符合性） | 软件更新 ― 符合性 |
| Compliance by software ID（软件 ID 符合性） | 软件更新 ― 符合性 |
| 适用特定软件更新的计算机 | 软件更新 ― 符合性 |
| 特定计算机的软件更新 | 软件更新 ― 符合性 |
| 未授权的软件更新 | 软件更新 ― 符合性 |
| 软件更新以及可用且已经安装的计算机数 | 软件更新 ― 符合性 |
| 带有特定软件更新分发状态的所有计算机 | 软件更新 ― 分发状态 |
| 软件更新的分发状态摘要 | 软件更新 ― 分发状态 |
| 软件更新分发状态（按照软件更新 ID） | 软件更新 ― 分发状态 |
| 部署失败的软件更新摘要 | 软件更新 ― 分发状态 |
| 返回指定通告的软件更新错误消息的计算机 | 软件更新 ― 基础结构的状况 |
| 软件更新的状况 | 软件更新 ― 基础结构的状况 |
| 特定计算机在指定天数内的软件更新状态信息 | 软件更新 ― 基础结构的状况 |
重新通告此程序包 使用以下指导可以很容易地重新通告程序包：
| ? | 通过向现有的通告添加额外的计划，可以重新发送相同的程序包。该程序将强制客户端重新安装此程序包，即使客户端已经收到并且曾经运行此程序包。 |
| ? | 通过向通告添加其他计划，可以一直重新运行相同的通告。当在实验计算机上进行测试工作，并且需要快速重新发送此程序包时，这是一个有效的解决方案。该程序有助于在将软件更新部署到生产环境之前对其进行充分测试。对于确保加入到环境的新计算机已得到修补，这也是一个很好的解决方案。 |
| ? | 通过右键单击该通告，并选择“All Tasks-rerun advertisement（所有任务 - 重新运行通告）”，可以很容易地重新发送通告。 |
卸载软件更新 在 Microsoft 发布的软件更新中，一部分更新提供了卸载方式，另一部分则未提供。通过查看安全公告的技术细节，可以确定哪些可以卸载。这些操作可以在修补程序管理过程的“识别”阶段进行。 要使用 SMS 卸载软件更新，需要了解卸载命令。Microsoft 更新通常向注册表写入一条引用，包括卸载命令（如果可以卸载）。
| ? | 卸载软件更新 | 1. | 创建 SMS 程序包和脚本，使用新的通告从注册表检索相关信息。 | | 2. | 基于从注册表收到的信息，创建相应的集合规则。通常，可以使用软件更新清单数据作为集合规则，除非此软件更新不提供扫描工具检测。否则可能需要自定义的脚本或更改 SMS_def.mof，以获得必要的目标详细信息。 | | 3. | 创建包含运行卸载命令的脚本的 SMS 程序包。应了解执行无人参与的卸载所需的任何命令行选项。 | | 4. | 通过使用 SMS 通告程序分发此程序包，这与部署发布的方法相同。 |
|
注意：可以考虑使用综合的软件更新，这样不影响最终用户（无需重新启动），而且允许 IT 员工有机会实践部署，并对结果进行衡量。
