ExchangeServer2003操作指南.doc

c5541abf-15ce-464f-b5d2-758395fcdf3eMicrosoft Exchange Server 2003 操作指南Microsoft Corporation发布日期：2006 年 12 月 12 日作者：Exchange Server 文档组摘要Exchange Server 2003 操作指南为灾难恢复任务以及每天、每周和每月的维护任务提供了操作准则。有意见或建议吗?请将您的反馈意见（英文）发送至 。ContentsExchange Server 2003 操作指南5有关详细信息5了解 Microsoft Exchange Server 2003 操作5Microsoft Operations Framework6用于 Exchange 组织的最佳实践13Exchange Server 2003 每日操作26执行物理环境检查27监视事件查看器27执行备份33检查磁盘使用34检查服务器和连接器状态36监视服务器性能39检查邮件路径40执行日常数据库维护44监视网络性能44监视 Exchange 和 Windows 服务45监视群集资源48强制执行安全措施51Exchange Server 2003 中的预定维护任务55生成报告和确定趋势55检查协议日志57监视 Outlook Web Access 服务器58管理邮箱59管理 BadMail 文件夹62管理邮局主管邮箱63召开状态会议和建立状态报告64Exchange Server 2003 中的按需任务64Exchange 2000 Server 和 Exchange Server 2003 数据库的联机和脱机碎片整理65验证邮箱和公用文件夹存储完整性67检查队列查看器69用于配置性能控制台的指南70Exchange Server 2003 操作一览表71Exchange Server 2003 灾难恢复准备一览表72一览表：灾难恢复准备72Exchange Server 2003 摘要一览表75一览表：摘要75Exchange Server 2003 每月操作一览表77一览表：容量规划77一览表：修补程序、Service Pack、更新汇总和安全更新77Exchange Server 2003 每周操作一览表78一览表：创建报表78一览表：事件报告79一览表：防病毒保护79一览表：状态会议80Exchange Server 2003 每日操作一览表80一览表：执行物理环境检查80一览表：检查备份81一览表：检查 CPU 和内存使用情况81一览表：检查磁盘使用情况82一览表：事件日志83一览表：检查 IIS 日志和性能84一览表：Exchange 数据库运行状况85一览表：MAPI 客户端性能85一览表：检查队列查看器86一览表：邮件路径和邮件流86一览表：连接到非 Exchange 邮件平台的 Exchange 连接器87一览表：安全日志88Copyright8889Exchange Server 2003 操作指南“Exchange Server2003 操作指南”由四个主题组成，这四个主题说明了 Microsoft Exchange Server2003 组织每天、每周、每月需要执行哪些维护任务才能保持信息技术 (IT) 组织顺利且无间断地运行。主题范围如下：对 IT 基础结构进行有效日常管理的过程概述。本主题提供维护 Exchange Server2003 环境所需的知识、工具以及最佳实践。为了确保 Exchange Server2003 组织的可用性和可靠性，需要有关日常维护任务的信息。某些日常维护任务范围如下：性能备份、检查磁盘使用情况、监视服务器和网络性能以及强制安全措施。 有关用于收集数据以便进行趋势分析以及容量规划的排定维护任务的信息。维护任务包括生成报告和识别趋势、检查协议日志、监视 Microsoft Office Outlook Web Access、管理邮箱、BadMail 文件夹、邮局主管邮箱以及执行每周状态会议有关按需任务（如对邮箱和公用文件夹存储进行碎片整理、验证邮件和公用文件夹存储完整性、使用队列查看器检查队列以及配置系统监视器以监视 Exchange 服务器性能）的信息。注意： 请下载 Microsoft Exchange Server 2003 Operations Guide（英文），以便脱机后打印或阅读。有关详细信息有关影响性能的因素的详细信息和有关如何优化 Exchange Server 2003 环境的建议，请参阅 Exchange Server 2003 性能和可伸缩性指南。 有关用于 Exchange Server 2003 组织的备份策略和灾难恢复操作的详细信息，请参阅 Exchange Server 2003 灾难恢复操作指南。了解 Microsoft Exchange Server 2003 操作信息技术 (IT) 操作是指 IT 基础结构的日常管理。IT 操作包含了保持系统平稳运行所需的所有工作。此过程通常包括引入和控制对系统的小型更改（如邮箱移动和硬件升级），但这些小型更改不会影响总体系统设计。在 Microsoft Exchange Server 2003 组织内，需要将操作中涉及的步骤、角色和职责正式化。根据 Microsoft Operations Framework (MOF) 来实现 Exchange Server 2003 操作步骤，需要：了解 MOFMOF 是最佳实践、原则和模型的集合，它为您提供有关 IT 项目管理（如日常 Exchange Server 2003 操作）的技术指南。遵循 MOF 指南将帮助您实现 Microsoft 产品的关键生产系统可靠性、可用性、可支持性和可管理性。 熟悉用于 Exchange 组织的最佳实践建议您实现已证实的实用步骤来管理 Exchange Server2003 组织。在您的组织中使用经过试验和测试的已记录操作管理方法，可能比开发自己的方法更有效。 将操作分割为每日、每周和每月过程记录在公司内定期执行的操作任务。记录如何以及何时执行任务可确保当操作人员变换工作或离开公司时信息仍会保留下来。新员工也可受益于此文档，因为它可以帮助他们快速了解 IT 部门是如何执行其 Exchange 操作的。部署操作 Exchange Server 2003 组织所需的工具有多种工具可用于帮助解决问题和自动完成任务。您可以定义一个标准工具集，以便由操作团队执行的任务可以以有效、一致且受控的方式完成。还应实现用以跟踪事件和主要配置更改的过程。本主题介绍维护 Exchange Server 2003 环境所需的知识、工具和最佳实践。它说明 Exchange Server 2003 的管理如何符合总体 MOF 模型。它将帮助您设计操作管理环境，并提供用以实现可保持环境平稳运行的步骤的方法。Microsoft Operations FrameworkMicrosoft Operations Framework (MOF) 是一个模板，您可以在其上设计有效操作 IT 基础结构所需的步骤、控制和角色。 MOF 过程模型MOF 提供有关如何规划、部署和维护 IT 操作过程以支持关键服务解决方案的指南。MOF 是通用模型，因此您必须修改许多建议，以将其用于您的公司。当您在 MOF 模型中看到对“角色”的引用时，您应知道可以给一个人分配许多角色，特别是在小型公司中。但即使您代表整个 IT 部门，此模型中的步骤和建议通常也都适用。 MOF 是基于下列各项的结构化的灵活模型：Microsoft 咨询和支持团队及其与企业客户和伙伴合作的经验以及 Microsoft 内部 IT 操作组。IT 基础结构库 (ITIL)，它描述了传递关键服务解决方案所需的过程和最佳实践。 来自国际标准化组织 (ISO) 的 ISO/IEC 15504，它提供了用以评估软件过程成熟度的规范化方法。MOF 提供有关部署各种 Microsoft 产品（如 Microsoft Windows Server 2003 和 Microsoft Exchange Server 2003）的建议。有关 Microsoft Operations Framework 的详细信息，请访问 /fwlink/?LinkId=21640（英文）。 有关 ITIL 和 ISO 的详细信息，请分别访问 .uk/index.asp?id=2261（英文）和 （英文）。MOF 可与 Microsoft Solutions Framework (MSF) 集成，它是后者的补充。MSF 是用以管理技术项目的规范化方法，它基于 Microsoft 内部实践、在与客户和伙伴合作中积累的 Microsoft 产品技术支持服务经验以及软件开发和项目管理中的行业最佳实践。MSF 是用于设计和实现 IT 系统的部署方法（例如，要从 Lotus Notes 移至 Exchange Server 2003 的迁移项目），而 MOF 用于处理系统或环境（如 Exchange Server 2003 组织）的日常管理。 MOF 过程模型的组件MOF 过程模型由象限、操作管理检查和服务管理检查组成。图 1.1 显示 MOF 循环是如何进行的。图 1.1 Microsoft Operations Framework 循环从图中可以看到 MOF 过程模型如何按顺时针方向移动并如何分为四个互相协调的的象限，如下所示：更改 操作支持优化这些象限构成螺旋式生命周期，此生命周期适用于从特定应用程序到具有多个数据中心的完整操作环境的各种 IT 操作。此过程模型受 Service Management Functions (SMF) 和集成的团队模型与风险模型支持。每个象限是由相应的操作管理检查（也称为检查里程碑）支持的，在进行该检查期间会对该象限的 SMF 的有效性进行评估。您应该了解，虽然模型按顺序描述 MOF 象限，但是所有象限中的活动都可以同时发生。 简要地说，象限包括下列活动： 更改更改是在更改阶段中规划和测试的。进行发行就绪状态检查之后，会将更改转出到生产环境并进入操作阶段。发行就绪状态检查不应是第一次进行的发行评估；它应是实际部署前的最终检查里程碑。使用 SMF 可提供过程和任务途径，并可保证成功进行部署和转出管理的版本。操作操作检查的目的在于提供使对系统的支持变得尽可能简单高效的过程、步骤和工具。可将此象限中的 SMF 视作典型的数据中心活动，如系统管理、监视和批处理。这些活动可保证发行的平稳和可预测的操作。 支持支持阶段是使用这些工具和步骤维护系统的过程。此象限包含对 IT 服务解决方案的用户提供持续支持的主要 SMF。与任何过程、系统、应用程序或服务一样，操作开始时就可能出现问题。支持和操作人员必须快速确定、分配并解决问题，以满足服务级别协议 (SLA) 中提出的需求。SLA 检查是对系统执行的有效性进行的测量。由 SLA 检查发现的问题可能会突出显示需要改进的区域。优化此象限的服务任务是在保持或提高服务级别的同时降低成本。改进系统可能需要对硬件、软件或步骤进行更改。发行批准状态检查会对更改建议进行评估，说明成本、风险和益处等项目。经过批准的更改会送入更改象限，然后此过程将重新开始。当各个团队逐渐引入对系统的更改以实现改进时，此迭代过程通常会自然发生。 MOF 框架形式化地描述了此改进循环中涉及的步骤，为每个步骤分配职责并使整个过程能够受到管理。在每个阶段末尾都有一个检查点。对于大型 IT 部门，这很可能是所涉及的人员或团队之间的检查会议，如发行管理、操作和安全。在小型公司，检查点可能只是一个表明您可继续进行操作的检查点。图 1.2 显示 MOF 和 MSF 之间的关系。 图 1.2 MOF 和 MSF 之间的关系MSF 过程有助于开发解决方案以响应业务需要，如整合服务器资源的需要。在这种情况下，解决方案可能概述如何部署运行 Exchange Server 2003 的强大的邮箱服务器。部署此解决方案之后，设计和部署团队会将环境传递给 MOF 模型中描述的团队。这些团队会管理日常操作，并为设计团队提供有关对更改的需求或建议的反馈。同样，这是一个迭代过程，该过程可用于改善和不断改进解决方案。Service Management FunctionsService Management Functions (SMF) 是组织中的人员或团队的角色，如支持专业人员或系统管理。SMF 代表 MOF 过程模型的基础。虽然 SMF 是跨功能和跨象限的，但是 SMF 的主角色适用于象限中的特定阶段。例如，系统管理属于操作象限，而发行管理属于更改象限。本节将详细讨论 SMF 和每个 SMF 适用的 MOF 循环象限。您公司的 IT 部门可能符合这些角色和象限。图 1.3 显示 MOF 循环中的这些服务管理功能。图 1.3 MOF 中的服务管理功能更改此象限中的过程用于在环境中引入新的方案、技术、系统、应用程序、硬件和过程。这包括：更改管理涉及管理开发、测试和将更改转出到生产环境。更改管理过程的一个重要目标是标识将受到即将发生的更改影响的所有人并向其提供详细信息。 配置管理涉及确定、记录和跟踪环境组件及它们之间的关系。配置管理还负责维护最终软件库 (DSL)，该软件库容纳了 IT 环境中部署的所有软件的主副本。 发行管理涉及将新的软件、硬件和过程版本发行到生产和管理的预生产环境。发行管理会考虑发行的所有方面，无论是技术方面还是非技术方面。可确保针对每项 IT 服务良好地定义、维护和排定了发行。 操作此象限中的过程围绕有效和高效执行日常任务。系统管理涉及维护邮件系统和协调 IT 团队。安全管理涉及维护安全可靠的计算环境。目录服务管理涉及管理用户帐户、组织单位和其他 Active Directory 目录服务对象。目录服务管理重点关注组织的日常操作、维护和支持。 网络管理涉及维护物理网络基础结构（如服务器、路由器和防火墙）以确保邮件系统之间可互相通信。服务监视和控制涉及监视系统性能以确保日常操作符合 SLA。存储管理涉及维护邮件组织中的数据储存库以确保数据的可用性。这包括备份和容量规划。作业安排涉及在非高峰期安排维护作业（例如，备份和批处理），同时会考虑可用容量。支持此象限中的过程围绕事件、问题和查询的解决。服务中心提供有关设置和运行作为用户和 IT 服务提供商之间唯一联系点的组织单位或部门的指导。服务中心组织有关事件、问题的活动和客户通信以及与生产系统相关的查询。事件管理涉及管理解决生产系统的任何错误或中断的过程，包括上报到其他 SMF 和与其他 SMF 进行通信。问题管理重点关注构建问题的调查、诊断、解决和关闭的上报过程。优化重点关注 IT 服务传递中优化性能或容量、提高可用性或降低成本的更改。服务级别管理涉及监视 IT 部门的性能和定期检查其与 SLA 的遵从性。财务管理涉及确定所需的更改和其他支出就成本与优点而言是否合理。例如，聘用其他用户帮助中心人员的成本与减少支持呼叫等待时间的优点。容量管理涉及监视邮件系统的容量以确保符合 SLA 中定义的性能标准。可用性管理涉及管理、监视和报告邮件系统的可用性、可靠性和可维护性。人员管理涉及提供最佳实践、评估人员需求、培养技能和积极的团队态度和传授知识。安全管理定义和传达组织的安全规划、策略、准则和由关联的外部行业或政府机构定义的相关规章。基础结构管理确保基础结构开发工作的协调，将战略技术倡议转化为实用的 IT 环境元素，管理针对 IT 工程、硬件和企业体系结构项目的技术规划，并确保提供了高质量的工具和技术。 MOF 团队模型角色MOF 过程模型和 MOF 团队模型是定义 Microsoft Operations Framework 的核心模型。MOF 团队模型为组织团队和每个角色群集的功能和能力提供准则。团队模型中的角色群集可与过程模型的 SMF 配合使用。团队模型角色群集使 SMF 过程得以遵循。MOF 团队模型还建议将那些应该保持独立的功能组合起来。例如，在将更改发行到生产环境之前对其进行测试的团队应与开发更改的团队分开。图 1.4 显示在 MOF 内这些角色群集的组合方式。 图 1.4 MOF 内的角色群集MOF 团队模型定义七个角色群集。这些角色通常反映中型到大型环境中团队的组织方式。本节中将讨论这些角色群集：发行发行团队管理将更改实施到生产环境中这一过程，负责配置管理，维护授权信息，并在开发组和操作组之间建立联系。服务服务团队负责特定服务（如在整个组织内提供邮件解决方案服务）的端对端管理。解决方案的设计、部署和操作阶段都涉及服务团队。 基础结构基础结构团队规划并管理 IT 基础结构，包括容量预测、管理标准版本和系统映像以及监视系统可用性和连接性。支持支持团队是用户与帮助中心支持之间的联系点。该团队对 SLA 的遵从性进行管理，提供事件和问题解决方案，并维护常用解决方案的知识库。该团队还负责为设计团队提供客户反馈。操作操作团队管理用户帐户和邮箱，监视系统性能和可用性，管理与外部系统的连接，监视队列和日志，并维护防火墙。合作伙伴合作伙伴团队充当供应商和伙伴（如 Internet 服务提供商 (ISP)）之间的联络点。该团队管理与第三方订立的合同性 SLA，评估备选供应商，管理采购，并制定购买决策。安全安全团队检测病毒攻击、入侵尝试、拒绝服务及其他攻击。该团队必须监视 IT 资源的使用情况和与标准的遵从性，并审核跟踪和报告。该团队经常管理邮件签名和加密所必需的公钥基础结构 (PKI) 技术以及外部测试（包括邮件中继测试和渗透测试）。此详细的 MOF 模型构成了用于组织资源和职责（用于操作、支持、优化和更改 IT 基础结构）的基础。用于 Exchange 组织的最佳实践最佳实践是根据 IT 专业人员从许多环境中获得的知识和经验建议的。它们提供邮件管理员每日必须完成的典型任务的标准步骤，并列出他们应该用来管理 Exchange 2003 服务器组织的工具。 用于 Exchange 管理的典型任务包括：容量和可用性管理定义用以预测将来容量需求的测量方法和测量对象。此外，还用于报告系统的容量、可靠性和可用性。必须确保正在运行 Exchange 的服务器的大小足以处理系统上的负载，并确保将计划外的停机时间保持在 SLA 中定义的级别之下。此外，您将需要升级硬件以不断满足定义的需求。 更改管理和配置管理控制如何对 IT 系统进行更改。这应包括测试、应用、反馈和应急计划、记录所有更改以及出现问题时检验管理。记录软件和硬件资产及其配置。系统管理概述用于执行管理任务（如数据库管理和邮件管理）的标准方法。 安全管理制定详细策略和规划以保护 IT 基础结构的数据保密性、数据完整性和数据可用性。这包括与维护和调整 IT 安全基础结构相关的日常活动和任务。 系统疑难解答概述用于处理意外问题的方法，包括用以防止将来出现类似问题的步骤。服务级别协议维护 IT 系统的一组性能目标并根据这些目标定期测量性能。文档记录标准步骤，如配置信息和经验教训，并使它们可供需要它们的人员使用。当对配置进行更改时，也相应地更新文档。容量和可用性管理容量管理和可用性管理的目的在于测量和控制系统性能。建议您实现容量管理和可用性管理步骤，以便可以测量和控制系统性能。您必须通过设置基线并监视系统以寻找趋势来了解系统是否可用以及它是否能够处理当前和预计需求。能力管理能力管理包括规划和控制服务能力以及调整其规模，以确保超过 SLA 中规定的最低性能级别。好的能力管理可确保您能以合理的成本提供 IT 服务，并且仍能满足与客户签订的 SLA 中定义的性能级别。这些标准可包括：系统响应时间这是测得的系统用来执行典型操作的时间。示例包括，客户端登录到域并进行身份验证的时间、允许进行 Exchange 存储完整备份的时间以及从邮箱或公用文件夹检索项目所花的时间。存储容量不管存储系统是网络共享、备份磁带驱动器还是 Exchange 存储，它都是指存储系统的容量。示例包括要提供的按用户最低存储空间和备份磁带被覆盖之前必须保留的时间。调整容量通常是确保有足够可用物理资源（如磁盘空间和网络带宽）的方案。表 1 列出容量相关问题的典型解决方案。表 1 容量相关问题的典型解决方案问题可能的解决方案登录邮箱速度很慢将另一个域控制器引入该站点或增加网络带宽从公用文件夹检索文档速度很慢确保本地有公用文件夹副本通过 Microsoft Office Outlook Web Access 访问速度太慢增加 Internet 连接的可用带宽网络共享上的可用空间不足向服务器或存储阵列添加更多磁盘容量受系统配置的影响并取决于网络带宽等物理资源。例如，如果运行 Exchange Server 2003 的服务器已配置为将故障排除信息记录到磁盘，则随着时间的推移，日志文件可能会用尽磁盘空间。这可减少可用于 Exchange 存储的磁盘容量。容量管理是将系统容量保持在可接受级别之内的过程，并解决下列问题：对需求的更改做出反应需要对容量需求进行调整以适应系统或组织中的更改。例如，如果增加发往 Internet 的最大允许邮件大小，您可能注意到通过 Internet 连接的通信也相应增加。然后，您可能需要增加该连接的容量以避免邮件传输中不可接受的延迟。预测将来的需求某些容量需求随时间变化的更改是可以预测的，因而可以提前规划。例如，Exchange 存储中邮件的总量通常以相当稳定的速率增长。通过查看 Exchange 存储大小在过去六个月中是如何更改的，您也许能够预测大约何时它将达到限制。标准版 Exchange 2003 服务器上 Exchange 存储的最大大小为 16 GB。因此您将需要规划升级到企业版，引入邮箱大小配额，或添加 Exchange 服务器并将部分邮箱移至这些新服务器。可用性管理可用性管理是确保任何 IT 服务一贯地和经济高效地提供客户所需的可用性级别的过程。可用性管理不仅涉及尽量减少服务损失，而且涉及确保在服务损失时采取相应的操作。在 Exchange Server 2003 环境中，您可能会关心 Exchange 存储服务是否可用、SMTP 连接器是否正常工作，等等。SLA 定义可接受的中断频率和中断时间，允许系统在特定期间内由于预定维护和意外故障而不可用。如果您需要提供有关系统可用性管理的报表，或如果存在与达不到可用性目标有关的经济处罚或其他处罚，则必须记录可用性数据。即使没有这样的正式需求，也建议至少知道系统在特定时间段内失败的频率，例如系统在过去 12 个月内的可用性及其每次故障恢复所花的时间。此信息将有助于测量和提高团队响应系统故障的效率。如果有争议，它也可为您提供有用信息。与可用性相关的测量如下所示：可用性这通常表示为相较于停机时间，系统或服务可访问的时间。它通常以百分比形式表示。（您可能会看到对“三个九”或“五个九”的引用。这些是指 99.9% 或 99.999% 的可用性。）可靠性这是系统故障之间的时间测量，有时表示为平均无故障时间 (MTBF)。修复时间这是发生故障后恢复服务所花的时间，有时表示为平均修复时间 (MTTR)。可用性、可靠性和修复时间之间的关系如下所示：Availability = (MTBF MTTR) / MTBF例如，如果服务器在六个月的时间内发生两次故障，并且平均 20 分钟不可用，则 MTBF 是三个月或 90 天，而 MTTR 是 20 分钟。因此， Availability = (90 days 20 minutes) / 90 days = 99.985%可用性管理是确保将可用性最大化并保持在 SLA 中定义的参数内的过程。可用性管理包括下列过程：监视检查服务何时不可用以及不可用的时间有多长。报告应定期向管理、用户和操作团队提供可用性图表。这些报表应突出显示趋势并确定进展情况良好的区域和需要注意的区域。报告应总结对 SLA 中设置目标的遵从性。改进如果可用性低于 SLA 中定义的目标，或其中的趋势是可用性降低，则可用性管理过程应定义规划的步骤。这应该包括与其他负责团队合作，以重点关注中断原因并规划补救操作以防止再次出现中断。 容量和可用性测量是重复性任务，最适合于自动工具和脚本，如 Microsoft Operations Manager，本主题稍后将对其进行讨论。 更改管理有时您必须对 IT 环境引入更改，如新的技术、系统、应用程序、硬件、工具和过程以及对角色和职责的更改。有效的更改管理系统使您可以快速对 IT 环境引入更改，同时尽可能减少服务中断。更改管理系统使多个团队共同参与修改系统。引入 Microsoft Office Outlook Web Access 便是一个示例。Outlook Web Access 是 Exchange Server 2003 的一个集成组件，它使用 Web 浏览器和 Internet 或 Intranet 连接，使您能够读取 Exchange 服务器上存储的公司电子邮件、计划和其他信息。在组织中部署 Outlook Web Access 要求若干团队共同参与，如：测试团队该团队必须在测试服务器上对 Outlook Web Access 进行负载测试，并提供在生产服务器上实现 Outlook Web Access 的指导。测试团队必须通过使用指定类型和版本的常用 Web 浏览器（如 Internet Explorer 6.0）来评估 Outlook Web Access。Exchange 管理员此团队在更改被部署到生产环境中后管理系统。在将更改投入生产之前，他们必须了解更改的效果并将更改结合到其步骤中。网络团队此团队负责更改防火墙规则以允许从 Internet 访问 Outlook Web Access 服务器。安全团队此团队评估安全性并尽可能降低风险。安全团队必须检查已知漏洞并确保将安全风险降至最低。用户验收团队此团队由愿意测试系统并提供改进反馈的用户组成。更改管理过程定义每个团队的职责并安排要执行的工作，根据需要并入检查和测试。更改控制会因更改的复杂程度和预期效果而异。从次要更改的自动批准，到更改检查会议，到完整的项目级检查各不相同。为了对此进行更好的说明，本节中将讨论更改组。主要更改主要更改对系统具有全局影响，可能需要不同团队的投入。从 Exchange Server 5.5 升级到 Exchange Server 2003 是它的一个示例。主要更改影响许多不同的团队并可能影响不同的系统。更改管理过程可能遵循前面讨论的有关在组织中部署 Outlook Web Access 的示例的类似步骤，但将可能包括一个或多个更改检查会议以通知将要参与更改或受更改影响的团队。重大更改要规划、构建和实现重大更改，需要大量的资源。应该引入适当的更改控制以确保已了解更改的效果、已测试部署步骤并且回滚和应急计划已就绪。重大更改的一个示例是部署新的 Service Pack。 次要更改次要更改不会显著影响 IT 环境，例如，修改某些 Exchange 系统策略设置。 标准更改标准更改定期执行，并且对其已有足够的了解和记录。示例包括创建新邮箱或更改备份范围。定期更改应在标准操作步骤 (SOP) 中记录，但它们不需要更改控制。例如，用于创建新邮箱的步骤可能规定所有新邮箱都将具有 100 MB 的存储限制，都将启用 IMAP 和 Outlook Web Access，并且都将禁用所有其他客户端协议。更改管理过程应检查对步骤的任何更改，但不应（例如）参与创建每个邮箱。以下更改管理示例检查部署新 Service Pack 时不同团队之间如何交互以及所执行的操作。这些操作是由更改管理过程组织和管理的。提出更改请求安全团队已评估了最新的 Service Pack，并确认它可解决生产系统中的一个可能的漏洞。该团队提出更改请求以将新的 Service Pack 应用到所有 Exchange 服务器。Service Pack 发行说明检查Exchange 管理员团队检查 Service Pack 发行说明以确定对系统的影响。完成一系列实验室测试Exchange 管理员团队必须在非生产环境中的一台服务器上执行测试更新，以确定是否可以在不影响任何已安装应用程序和服务器系统的情况下，成功应用此 Service Pack。如果生产环境中有第三方或内部创建的应用程序与 Exchange 相互作用，则还应测试这些应用程序。这些测试也可用于估计执行升级所需的时间。 通知用户发生中断Exchange 管理员团队或用户帮助中心通知所有受到影响的用户有关规划的维护周期以及服务器将不可用的时间长度。升级前执行 Exchange 存储的完整备份Exchange 管理员团队必须确保存在有效备份，以便能够在 Service Pack 安装失败的情况下恢复到原始系统状态。建议将备份还原到备用服务器以便可以在出现问题时随时使用此系统。 部署 Service PackExchange 管理员团队在规划的维护周期期间执行安装。管理更改的时间建议您实现用于安排更改的过程以避免在工作的重叠部分发生混乱。例如，两个团队可能都在规划对系统进行次要更改。一个团队可能要应用 Service Pack，而另一个团队要安装运行于 Exchange Server 2003 之下的费用报销应用程序的自定义表单。两个团队都不会受到其他团队正在规划的更改的影响，而且它们可能不必了解其他团队正在规划何种更改。如果两个更改同时发生，则在实现更改时可能出现问题。此外，如果应用更改后出现问题，例如如果费用报销应用程序失败，则可能很难确定应回滚哪个更改。应在 IT 和管理之间设置定期维护时间段，以测试并接受这些更改。配置管理配置管理是记录和跟踪硬件和软件资产以及系统配置信息的过程。它通常用于跟踪软件许可证、维护客户端计算机和服务器的标准硬件和软件版本，并定义新计算机的命名标准。配置管理通常包括下列类别：硬件此类别跟踪 IT 组织拥有哪些设备、设备的位置以及设备的使用者。此信息使组织能够规划和预算升级、维护标准硬件版本、报告用于记帐目的 IT 资产价值，并有助于防止被窃。软件此类别跟踪每台计算机上安装了哪些软件、软件版本号以及许可证的保存位置。此信息有助于规划升级、确保软件已获得许可证，并检测是否存在未经授权（和未获得许可证）的软件。标准版本此类别跟踪客户端计算机和服务器的当前标准版本以及客户端计算机和服务器是否满足此标准。存在和实施标准版本可以帮助支持人员，因为他们只需要维护每份软件的有限数量的版本。Service Pack 和修补程序此类别跟踪哪些 Service Pack 已测试和批准进行使用以及哪些计算机是最新的。此信息对于尽量减少计算机受到危害的风险以及检测已安装未经批准更新的用户非常重要。系统配置信息此类别跟踪系统功能、系统元素之间的交互以及哪些过程依赖于平稳运行的系统。例如，可能会在单个服务器上配置到第三方电子邮件系统的连接器。应了解此电子邮件系统对于此服务器的依赖关系，如果出现故障，可能需要应急计划。如果第二个连接器安装在其他服务器上，则依赖关系和应急计划可能会更改。实现配置管理确定配置管理练习的目的并确定需要管理哪些项目后，需要通过收集数据和报告数据来实现配置管理。对于小型组织来说，最简单的方法是手动收集数据（客户端计算机的数量和型号、操作系统、已安装的软件）并将其存储在 Microsoft Office Word 或 Microsoft Office Excel 文档中。对于大型、比较复杂和不断更改的系统，必须将资产的发现和详细信息的收集自动化。确定哪些信息与组织相关，并将其记录在数据库中。配置管理数据库在以下方面，对于支持人员和管理来说是一个有用的工具：安全审核此数据库使您能够确定需要应用修补程序或尚未安装 Service Pack 或最新防病毒更新的 Exchange 服务器和客户端计算机系统。软件安装如果确定客户端计算机已安装 Microsoft Office Outlook 2003，则这可为手动部署 Outlook 2003 节省时间。 配置信息如果维护所有到邮件系统和传真服务器等的 Exchange 2003 连接器的最新列表，您将能够更加快速和有效地解决连接问题。规划升级如果容量检查显示 Exchange 2003 服务器上需要附加存储空间。如果每台服务器都有一个内部 RAID 控制器，但每台服务器都安装了不同型号和不同数量的磁盘，则配置管理数据库将表明在每种情况下可以安装的磁盘类型和数量以及将使用的升级路径。用于配置管理的工具有许多工具可用来发现、审核和报告资产。本节中讨论其中的一些工具。 自动脚本您可以编写简单脚本报告项目，如一组特定计算机上的操作系统、Service Pack 级别和存在的软件。您可以根据组织的确切需求指定这些脚本；不过，所需脚本的数量及其复杂程度可能会使脚本的创建和维护成本非常高。自动工具根据业务大小和组织的需要，可能需要考虑使用自动工具。Microsoft Systems Management Server (SMS) 等工具合并了标准报表模板（如 Service Pack 级别），同时使您能够创建自定义报表（例如，为自定义应用程序创建自定义报表）。Microsoft Operations Manager (MOM) 也可用于报告硬件和软件配置。有关 SMS 和 MOM 的详细信息，请参阅在本主题后面“用于操作 Exchange 2003 服务器组织的工具和技术”中的“Systems Management Server”和“Microsoft Operations Manager”子主题。另外还有一些工具可用于记录配置数据并使其可由适当的 IT 人员访问：公用文件夹这些对于存储配置数据将非常有用，因为可以在整个组织中访问它们，并可轻松地控制它们，这样只有适当的人员才能查看或更改项目。Microsoft Windows SharePoint ServicesWindows SharePoint Services 是 Windows Server 2003 的组件，它通过使个人或团队能够创建用于信息共享和文档协作的网站，可帮助组织提高个人或团队生产力。用户可协作处理文档、任务和事件，并共享联系人和其他信息。此外，Windows SharePoint Services 使团队和站点管理者能够管理站点内容和用户活动。SharePoint 环境是为灵活的部署、管理和应用程序开发而设计的。自定义数据库对于大型组织，将配置信息存储在 Microsoft Office Access 或 Microsoft SQL Server 数据库中可能会非常有用，因为这样可以对信息执行更高级的查询。例如，列出所有未安装 Service Pack 2 的 Windows XP 客户端计算机。自动工具SMS 等工具不仅自动收集数据，而且将数据存储在中央数据库中。在中央数据库中，此数据可用于执行标准和自定义查询以及生成数据报表。与更改管理的关系配置管理与更改管理紧密相关。配置管理确定更改需要，并确定和记录已发生更改。例如，配置管理数据库可用来确定需要修补程序的服务器。更改管理然后定义应用修补程序的过程。相反，如果转出新软件包，更改管理过程会将此信息提供给配置管理系统。配置管理工具可能需要配置为可识别新软件，以便它们可以发现并跟踪部署此软件的位置和时间。系统管理系统管理包括日常管理任务，包括保持 IT 系统平稳运行所需的规划任务和按需任务。通常，写成的步骤中会包括系统管理任务。这些步骤可确保所有支持人员都使用相同的标准工具和方法。在 Exchange Server 2003 环境中，典型的系统管理任务包括创建邮箱、备份和存档邮箱和公用文件夹数据、监视日志、维护和恢复邮箱以及更新防病毒扫描程序。标准步骤有几种资源可帮助您定义组织中需要的标准步骤以及如何执行这些步骤。有关如何管理 Exchange 组织的详细信息，请参阅“ExchangeServer 2003 管理指南”(/fwlink/?LinkId=21769)。由于每个组织都是唯一的，因此您必须自定义和修改这些资源以适应您的需求。标准步骤将更改，有时还需要修订文档。当进行更改时，更改管理过程应确定每个更改可能如何影响管理任务的执行方式。使用更改管理功能更新和控制文档。经常，更改管理从系统管理完成的位置接管。如果某任务包括在标准步骤中，则它是系统管理功能的一部分。如果没有针对某任务的标准步骤，则应使用更改管理功能处理该任务。集中式与分散式管理用于执行系统管理任务的角色和职责取决于组织是遵循集中式模式还是分散式模型，还是组合模型。集中式模型在集中式模型中，一个或几个受控制的管理组保持对 Exchange 系统的完全控制。这种管理模型类似于一个数据中心，其中的所有管理任务都由一个信息技术组执行。应根据经验和专业技能定义此团队中的角色和职责。分散式模型分散式组织位于多个地理位置并且在不同位置具有 Exchange 服务器和管理员团队。例如，每个国家/地区的每个办公室都可能有本地管理人员和一个或多个 Exchange 服务器。或者，北美和欧洲可能各有一个 Exchange 服务器群集和一个管理团队。有时，您将需要确保管理员只负责他们自己的地理区域，并且他们没有管理其他区域的权限。在 Exchange Server 2003 中，可用通过使用委派控制向导将管理员分配到特定管理组来实现此目的。系统疑难解答组织必须准备好处理意外问题，并应有一个从报告问题直到解决问题过程中管理问题的步骤。应将有关支持人员如何诊断问题的信息记录下来供将来使用，以避免不必要地重复已经完成的工作。系统疑难解答过程图 1.5 显示系统疑难解答过程以及与其他操作角色的交互。 图 1.5 系统疑难解答流程图分类和设置优先级此任务通常由服务中心执行。例如，可以将问题分组为邮件问题或硬件问题。然后将问题发送到适当的支持团队以供调查。用于确定问题优先级的规则连同响应时间和解决时间，通常在 SLA 中定义。调查和诊断适当的支持团队诊断问题并提议更改以解决问题。如果解决方案很简单，并且不需要更改控制，则可立即应用解决方案。如果解决方案不简单，则应提出更改请求，并且通常应在“快速跟踪”步骤中，由更改管理过程管理提议的工作。应使用配置管理过程记录所做的任何更改。关闭和记录测试解决方案后，会关闭问题。如果从问题中获得经验教训，则应在知识库中创建一个条目。检查和趋势分析应执行最新问题的定期检查以确定问题趋势。例如，如果用户经常遇到登录他们的邮箱速度很慢的问题，则原因可能是网络带宽问题。应检查问题解决时间和任何中断对系统可用性的影响，并将其与 SLA 进行比较。应将任何重大问题通知给与客户就服务问题进行联系的人员，如客户经理。问题管理工具服务中心工具使工作人员可以记录、分类并设置新问题的优先级。然后它们将提供工作流过程，以通过调查和诊断（通常有多个支持团队参与）来管理问题“票证”。它们会经常提供有关解决时间和历史趋势的报告。它们还可能包括知识库数据库，可用于搜索过去的问题。Microsoft 知识库是 Microsoft 已遇到的支持问题的有用记录。有关详细信息，请访问 Microsoft 帮助和支持网站 /fwlink/?linkid=14898。有的第三方软件通常需要自定义才能满足组织需要，如团队组织、报告需求和 SLA 所需的测量。 服务级别协议服务级别协议 (SLA) 是一个文档，该文档定义您的客户期望从您这里得到的服务。此文档的复杂程度和内容主要取决于客户是内部客户（在贵公司内）还是外部客户。外部客户如果客户是外部客户，则 SLA 可能是带有针对性能（在定义的服务级别之内或之外）的经济奖惩措施的法律合同的一部分。定义这些服务级别应该是总体合同协商的一部分。与所有合同一样，双方都知道对自己有什么期望和自己期望什么是非常重要的。SLA 定义这些期望。文档内容不应经常更改，而且只应在与客户协商的情况下更改。内部客户如果客户是内部客户，则您可能仍然希望定义操作团队和 IT 系统期望的服务。SLA 可以由操作人员创建，旨在作为组织中 IT 服务