了解 Microsoft Exchange Server 2003 操作

 

上一次修改主题: 2004-10-19

信息技术 (IT) 操作是指 IT 基础结构的日常管理。IT 操作包含了保持系统平稳运行所需的所有工作。此过程通常包括引入和控制对系统的小型更改(如邮箱移动和硬件升级),但这些小型更改不会影响总体系统设计。在 Microsoft® Exchange Server 2003 组织内,需要将操作中涉及的步骤、角色和职责正式化。

根据 Microsoft Operations Framework (MOF) 来实现 Exchange Server 2003 操作步骤,需要:

  • 了解 MOF   MOF 是最佳实践、原则和模型的集合,它为您提供有关 IT 项目管理(如日常 Exchange Server 2003 操作)的技术指南。遵循 MOF 指南将帮助您实现 Microsoft 产品的关键生产系统可靠性、可用性、可支持性和可管理性。
  • 熟悉用于 Exchange 组织的最佳实践   建议您实现已证实的实用步骤来管理 Exchange Server 2003 组织。在您的组织中使用经过试验和测试的已记录操作管理方法,可能比开发自己的方法更有效。
  • 将操作分割为每日、每周和每月过程   记录在公司内定期执行的操作任务。记录如何以及何时执行任务可确保当操作人员变换工作或离开公司时信息仍会保留下来。新员工也可受益于此文档,因为它可以帮助他们快速了解 IT 部门是如何执行其 Exchange 操作的。
  • 部署操作 Exchange Server 2003 组织所需的工具   有多种工具可用于帮助解决问题和自动完成任务。您可以定义一个标准工具集,以便由操作团队执行的任务可以以有效、一致且受控的方式完成。还应实现用以跟踪事件和主要配置更改的过程。

本主题介绍维护 Exchange Server 2003 环境所需的知识、工具和最佳实践。它说明 Exchange Server 2003 的管理如何符合总体 MOF 模型。它将帮助您设计操作管理环境,并提供用以实现可保持环境平稳运行的步骤的方法。

Microsoft Operations Framework (MOF) 是一个模板,您可以在其上设计有效操作 IT 基础结构所需的步骤、控制和角色。

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 的详细信息,请访问 http://go.microsoft.com/fwlink/?LinkId=21640(英文)。

有关 ITIL 和 ISO 的详细信息,请分别访问 http://www.ogc.gov.uk/index.asp?id=2261(英文)和 http://www.iso.org(英文)。

MOF 可与 Microsoft Solutions Framework (MSF) 集成,它是后者的补充。MSF 是用以管理技术项目的规范化方法,它基于 Microsoft 内部实践、在与客户和伙伴合作中积累的 Microsoft 产品技术支持服务经验以及软件开发和项目管理中的行业最佳实践。MSF 是用于设计和实现 IT 系统的部署方法(例如,要从 Lotus Notes 移至 Exchange Server 2003 的迁移项目),而 MOF 用于处理系统或环境(如 Exchange Server 2003 组织)的日常管理。

MOF 过程模型由象限、操作管理检查和服务管理检查组成。图 1.1 显示 MOF 循环是如何进行的。

Microsoft Operations Framework 循环

从图中可以看到 MOF 过程模型如何按顺时针方向移动并如何分为四个互相协调的的象限,如下所示:

  • 更改
  • 操作
  • 支持
  • 优化

这些象限构成螺旋式生命周期,此生命周期适用于从特定应用程序到具有多个数据中心的完整操作环境的各种 IT 操作。此过程模型受 Service Management Functions (SMF) 和集成的团队模型与风险模型支持。每个象限是由相应的操作管理检查(也称为检查里程碑)支持的,在进行该检查期间会对该象限的 SMF 的有效性进行评估。您应该了解,虽然模型按顺序描述 MOF 象限,但是所有象限中的活动都可以同时发生。

简要地说,象限包括下列活动:

  • 更改   更改是在更改阶段中规划和测试的。进行发行就绪状态检查之后,会将更改转出到生产环境并进入操作阶段。发行就绪状态检查不应是第一次进行的发行评估;它应是实际部署前的最终检查里程碑。使用 SMF 可提供过程和任务途径,并可保证成功进行部署和转出管理的版本。
  • 操作   操作检查的目的在于提供使对系统的支持变得尽可能简单高效的过程、步骤和工具。可将此象限中的 SMF 视作典型的数据中心活动,如系统管理、监视和批处理。这些活动可保证发行的平稳和可预测的操作。
  • 支持   支持阶段是使用这些工具和步骤维护系统的过程。此象限包含对 IT 服务解决方案的用户提供持续支持的主要 SMF。与任何过程、系统、应用程序或服务一样,操作开始时就可能出现问题。支持和操作人员必须快速确定、分配并解决问题,以满足服务级别协议 (SLA) 中提出的需求。SLA 检查是对系统执行的有效性进行的测量。由 SLA 检查发现的问题可能会突出显示需要改进的区域。
  • 优化   此象限的服务任务是在保持或提高服务级别的同时降低成本。改进系统可能需要对硬件、软件或步骤进行更改。发行批准状态检查会对更改建议进行评估,说明成本、风险和益处等项目。经过批准的更改会送入更改象限,然后此过程将重新开始。当各个团队逐渐引入对系统的更改以实现改进时,此迭代过程通常会自然发生。

MOF 框架形式化地描述了此改进循环中涉及的步骤,为每个步骤分配职责并使整个过程能够受到管理。在每个阶段末尾都有一个检查点。对于大型 IT 部门,这很可能是所涉及的人员或团队之间的检查会议,如发行管理、操作和安全。在小型公司,检查点可能只是一个表明您可继续进行操作的检查点。图 1.2 显示 MOF 和 MSF 之间的关系。

MOF 和 MSF 之间的关系

MSF 过程有助于开发解决方案以响应业务需要,如整合服务器资源的需要。在这种情况下,解决方案可能概述如何部署运行 Exchange Server 2003 的强大的邮箱服务器。部署此解决方案之后,设计和部署团队会将环境传递给 MOF 模型中描述的团队。这些团队会管理日常操作,并为设计团队提供有关对更改的需求或建议的反馈。同样,这是一个迭代过程,该过程可用于改善和不断改进解决方案。

Service Management Functions (SMF) 是组织中的人员或团队的角色,如支持专业人员或系统管理。SMF 代表 MOF 过程模型的基础。虽然 SMF 是跨功能和跨象限的,但是 SMF 的主角色适用于象限中的特定阶段。例如,系统管理属于操作象限,而发行管理属于更改象限。本节将详细讨论 SMF 和每个 SMF 适用的 MOF 循环象限。您公司的 IT 部门可能符合这些角色和象限。图 1.3 显示 MOF 循环中的这些服务管理功能。

MOF 中的服务管理功能
  • 更改    此象限中的过程用于在环境中引入新的方案、技术、系统、应用程序、硬件和过程。这包括:
    • 更改管理   涉及管理开发、测试和将更改转出到生产环境。更改管理过程的一个重要目标是标识将受到即将发生的更改影响的所有人并向其提供详细信息。
    • 配置管理   涉及确定、记录和跟踪环境组件及它们之间的关系。配置管理还负责维护最终软件库 (DSL),该软件库容纳了 IT 环境中部署的所有软件的主副本。
    • 发行管理   涉及将新的软件、硬件和过程版本发行到生产和管理的预生产环境。发行管理会考虑发行的所有方面,无论是技术方面还是非技术方面。可确保针对每项 IT 服务良好地定义、维护和排定了发行。
  • 操作    此象限中的过程围绕有效和高效执行日常任务。
    • 系统管理   涉及维护邮件系统和协调 IT 团队。
    • 安全管理   涉及维护安全可靠的计算环境。
    • 目录服务管理   涉及管理用户帐户、组织单位和其他 Active Directory® 目录服务对象。目录服务管理重点关注组织的日常操作、维护和支持。
    • 网络管理   涉及维护物理网络基础结构(如服务器、路由器和防火墙)以确保邮件系统之间可互相通信。
    • 服务监视和控制   涉及监视系统性能以确保日常操作符合 SLA。
    • 存储管理   涉及维护邮件组织中的数据储存库以确保数据的可用性。这包括备份和容量规划。
    • 作业安排   涉及在非高峰期安排维护作业(例如,备份和批处理),同时会考虑可用容量。
  • 支持   此象限中的过程围绕事件、问题和查询的解决。
    • 服务中心   提供有关设置和运行作为用户和 IT 服务提供商之间唯一联系点的组织单位或部门的指导。服务中心组织有关事件、问题的活动和客户通信以及与生产系统相关的查询。

    • 事件管理   涉及管理解决生产系统的任何错误或中断的过程,包括上报到其他 SMF 和与其他 SMF 进行通信。
    • 问题管理   重点关注构建问题的调查、诊断、解决和关闭的上报过程。
    • 优化   重点关注 IT 服务传递中优化性能或容量、提高可用性或降低成本的更改。
    • 服务级别管理   涉及监视 IT 部门的性能和定期检查其与 SLA 的遵从性。
    • 财务管理   涉及确定所需的更改和其他支出就成本与优点而言是否合理。例如,聘用其他用户帮助中心人员的成本与减少支持呼叫等待时间的优点。
    • 容量管理   涉及监视邮件系统的容量以确保符合 SLA 中定义的性能标准。
    • 可用性管理   涉及管理、监视和报告邮件系统的可用性、可靠性和可维护性。
    • 人员管理   涉及提供最佳实践、评估人员需求、培养技能和积极的团队态度和传授知识。
    • 安全管理   定义和传达组织的安全规划、策略、准则和由关联的外部行业或政府机构定义的相关规章。
    • 基础结构管理   确保基础结构开发工作的协调,将战略技术倡议转化为实用的 IT 环境元素,管理针对 IT 工程、硬件和企业体系结构项目的技术规划,并确保提供了高质量的工具和技术。

MOF 过程模型和 MOF 团队模型是定义 Microsoft Operations Framework 的核心模型。MOF 团队模型为组织团队和每个角色群集的功能和能力提供准则。团队模型中的角色群集可与过程模型的 SMF 配合使用。团队模型角色群集使 SMF 过程得以遵循。MOF 团队模型还建议将那些应该保持独立的功能组合起来。例如,在将更改发行到生产环境之前对其进行测试的团队应与开发更改的团队分开。图 1.4 显示在 MOF 内这些角色群集的组合方式。

MOF 中的角色群集

MOF 团队模型定义七个角色群集。这些角色通常反映中型到大型环境中团队的组织方式。本节中将讨论这些角色群集:

  • 发行   发行团队管理将更改实施到生产环境中这一过程,负责配置管理,维护授权信息,并在开发组和操作组之间建立联系。
  • 服务   服务团队负责特定服务(如在整个组织内提供邮件解决方案服务)的端对端管理。解决方案的设计、部署和操作阶段都涉及服务团队。
  • 基础结构   基础结构团队规划并管理 IT 基础结构,包括容量预测、管理标准版本和系统映像以及监视系统可用性和连接性。
  • 支持   支持团队是用户与帮助中心支持之间的联系点。该团队对 SLA 的遵从性进行管理,提供事件和问题解决方案,并维护常用解决方案的知识库。该团队还负责为设计团队提供客户反馈。
  • 操作   操作团队管理用户帐户和邮箱,监视系统性能和可用性,管理与外部系统的连接,监视队列和日志,并维护防火墙。
  • 合作伙伴   合作伙伴团队充当供应商和伙伴(如 Internet 服务提供商 (ISP))之间的联络点。该团队管理与第三方订立的合同性 SLA,评估备选供应商,管理采购,并制定购买决策。
  • 安全   安全团队检测病毒攻击、入侵尝试、拒绝服务及其他攻击。该团队必须监视 IT 资源的使用情况和与标准的遵从性,并审核跟踪和报告。该团队经常管理邮件签名和加密所必需的公钥基础结构 (PKI) 技术以及外部测试(包括邮件中继测试和渗透测试)。

此详细的 MOF 模型构成了用于组织资源和职责(用于操作、支持、优化和更改 IT 基础结构)的基础。

最佳实践是根据 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 Pack   Exchange 管理员团队在规划的维护周期期间执行安装。

建议您实现用于安排更改的过程以避免在工作的重叠部分发生混乱。例如,两个团队可能都在规划对系统进行次要更改。一个团队可能要应用 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® Services   Windows 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 管理指南”(http://go.microsoft.com/fwlink/?LinkId=21769)。由于每个组织都是唯一的,因此您必须自定义和修改这些资源以适应您的需求。

标准步骤将更改,有时还需要修订文档。当进行更改时,更改管理过程应确定每个更改可能如何影响管理任务的执行方式。使用更改管理功能更新和控制文档。

经常,更改管理从系统管理完成的位置接管。如果某任务包括在标准步骤中,则它是系统管理功能的一部分。如果没有针对某任务的标准步骤,则应使用更改管理功能处理该任务。

用于执行系统管理任务的角色和职责取决于组织是遵循集中式模式还是分散式模型,还是组合模型。

集中式模型   在集中式模型中,一个或几个受控制的管理组保持对 Exchange 系统的完全控制。这种管理模型类似于一个数据中心,其中的所有管理任务都由一个信息技术组执行。应根据经验和专业技能定义此团队中的角色和职责。

分散式模型   分散式组织位于多个地理位置并且在不同位置具有 Exchange 服务器和管理员团队。例如,每个国家/地区的每个办公室都可能有本地管理人员和一个或多个 Exchange 服务器。或者,北美和欧洲可能各有一个 Exchange 服务器群集和一个管理团队。有时,您将需要确保管理员只负责他们自己的地理区域,并且他们没有管理其他区域的权限。在 Exchange Server 2003 中,可用通过使用委派控制向导将管理员分配到特定管理组来实现此目的。

组织必须准备好处理意外问题,并应有一个从报告问题直到解决问题过程中管理问题的步骤。应将有关支持人员如何诊断问题的信息记录下来供将来使用,以避免不必要地重复已经完成的工作。

图 1.5 显示系统疑难解答过程以及与其他操作角色的交互。

系统故障排除流程图
  • 分类和设置优先级   此任务通常由服务中心执行。例如,可以将问题分组为邮件问题或硬件问题。然后将问题发送到适当的支持团队以供调查。用于确定问题优先级的规则连同响应时间和解决时间,通常在 SLA 中定义。
  • 调查和诊断   适当的支持团队诊断问题并提议更改以解决问题。如果解决方案很简单,并且不需要更改控制,则可立即应用解决方案。如果解决方案不简单,则应提出更改请求,并且通常应在“快速跟踪”步骤中,由更改管理过程管理提议的工作。应使用配置管理过程记录所做的任何更改。
  • 关闭和记录   测试解决方案后,会关闭问题。如果从问题中获得经验教训,则应在知识库中创建一个条目。
  • 检查和趋势分析   应执行最新问题的定期检查以确定问题趋势。例如,如果用户经常遇到登录他们的邮箱速度很慢的问题,则原因可能是网络带宽问题。应检查问题解决时间和任何中断对系统可用性的影响,并将其与 SLA 进行比较。应将任何重大问题通知给与客户就服务问题进行联系的人员,如客户经理。

服务中心工具使工作人员可以记录、分类并设置新问题的优先级。然后它们将提供工作流过程,以通过调查和诊断(通常有多个支持团队参与)来管理问题“票证”。它们会经常提供有关解决时间和历史趋势的报告。它们还可能包括知识库数据库,可用于搜索过去的问题。Microsoft 知识库是 Microsoft 已遇到的支持问题的有用记录。有关详细信息,请访问 Microsoft 帮助和支持网站 http://go.microsoft.com/fwlink/?linkid=14898

有的第三方软件通常需要自定义才能满足组织需要,如团队组织、报告需求和 SLA 所需的测量。

服务级别协议 (SLA) 是一个文档,该文档定义您的客户期望从您这里得到的服务。此文档的复杂程度和内容主要取决于客户是内部客户(在贵公司内)还是外部客户。

如果客户是外部客户,则 SLA 可能是带有针对性能(在定义的服务级别之内或之外)的经济奖惩措施的法律合同的一部分。定义这些服务级别应该是总体合同协商的一部分。

与所有合同一样,双方都知道对自己有什么期望和自己期望什么是非常重要的。SLA 定义这些期望。文档内容不应经常更改,而且只应在与客户协商的情况下更改。

如果客户是内部客户,则您可能仍然希望定义操作团队和 IT 系统期望的服务。SLA 可以由操作人员创建,旨在作为组织中 IT 服务可用性的一组目标。或者,性能级别可以由管理层设置,并用作评估员工绩效时的基准。

服务级别协议包括定义最低可用性、支持和容量级别标准的组件。

  • 可用性   定义小时数和电子邮件与其他 Exchange 服务在其上可用的操作系统(这可能包括手持式 PDA 和移动电话)。应定义任何影响服务可用性的日常维护。定义影响服务的外部因素,例如 Internet 连接断开。
  • 支持   定义对系统的支持可用的小时数。指定客户与支持人员联系的方法、如何分组事件以及用于响应和解决事件的目标时间。定义反馈给客户的频率和内容。
  • 容量   定义最大允许的用户邮箱大小以及超过限制时要采取的步骤。定义最大允许的执行标准任务的时间,如从公用文件夹检索文档的时间。定义最大用户数,并同意如果添加更多用户,则遵循某个过程来增加容量。

Microsoft Operations Framework (MOF) 模型由许多服务管理功能组成。可以与同一团队的成员或与其他团队分享有关如何以及何时执行任务的文档。存储和共享文档的方法可能根据功能的类型而不同。例如,可以将用于系统管理的步骤存储为 Word 文档,因为它们可能经常要被打印和引用。配置管理信息可以自动生成并存储在数据库中,以便轻松搜索和索引。有些文档可能是机密文档,应对其进行限制。一个描述用以防止电子邮件欺骗、垃圾邮件、病毒和来自恶意用户攻击的安全措施的文档,便是机密文档的一个示例。只有适当的人员可以使用这些文档。必须具备一个用于版本控制的机制,以便在文档更改时可以替换循环中的旧副本。

文档管理系统充当中央文档库,可确保仅最新的文档版本可用。还可考虑存档较旧的文档版本以供参考。Microsoft SharePoint® Portal Server 是许多用于管理文档的适当应用程序中的一个。为防止意外使用过时的步骤,不建议 IT 人员使用文档的本地副本。只有具有相应权限的人员才能限制、查看或编辑文档。草稿文档可保持等待审批状态,例如当等待批准关联的更改请求时。

已讨论了几种适用于使用数据库的工具和管理功能。配置管理过程可能使用自动过程来存储大量需要索引和搜索的数据。支持人员在解决新问题时可以搜索过去问题和解决方案的数据库。

不同的目的很可能会使用不同的数据库。确定是否应该链接或合并这些数据库。例如,如果服务中心确定常见主题(如引起特定网络卡问题的新软件)的几个问题,他们可以可查询配置数据库以预测可能会有多少台计算机受到影响。

有许多 IT 服务应自动和实时监视。此外,可能有必须立即警告操作人员的关键时刻,例如邮件队列发生累积。如果只有在工作日结束时的手动检查过程中才会发现它,则邮件到达的延迟可能对业务产生严重影响。

有许多更加复杂的监视任务通常不是自动执行的,应该通过定期手动检查来完成这些任务。有关定期记录的检查和维护任务需要的详细信息,请参阅本主题前面的“系统管理”。下面是与 Exchange Server 2003 相关的部分标准任务的列表。这些列表可用作生成组织标准步骤的基础。本主题后面将更加详细地讨论这些列表。

建议每日执行下列任务和步骤:

  • 检查 Windows 事件日志中的 Exchange 警告和错误   应检查 Exchange 服务器事件日志是否存在意外的警告和错误。您可以在每个 Exchange 服务器上手动执行此操作,也可以通过使用 Microsoft Operations Manager (MOM)(它可以合并日志并筛选掉某些条目)之类的工具执行此操作。
  • 检查备份作业   确保以前一天晚上的备份作业已运行并调查任何错误或警告。应该有一个根据正在使用的备份策略进行媒体轮换、标记和存储的步骤。如果适用(基于运行的备份类型),请确定是否已作为备份过程的一部分从磁盘刷新事务日志。
  • 检查性能监视器   您可能正在使用 Windows 性能监视器或更高级的工具(如 MOM)检查关键性能指标,如可用磁盘空间和邮件队列长度,以获得服务器或系统状态的整体视图。使用这些工具的警报功能为任何突然更改或问题设置警告,并设置可以随着组织的增长而修改的基线。
  • 检查入侵检测日志   如果有专用入侵检测软件,或者如果防火墙生成了入侵尝试的日志,请检查前一天的日志,研究重复的身份验证尝试和其他可疑活动。
  • 检查防病毒更新   检查每个 Exchange 服务器和/或网关上是否一直都在运行自动防病毒签名更新,并且所有签名是否都是最新的。如果手动更新防病毒签名,请每日执行这些操作。

建议每周执行下列任务和步骤:

  • 存档事件日志   如果未将事件日志配置为根据需要覆盖事件,则必须定期存档和清除这些日志。这对于安全日志尤其如此,调查尝试的安全缺口时可能需要这些安全日志。
  • 检查安全更新   确定任何新的 Service Pack、修补程序或更新。如果适用,请在测试实验室中测试它们并使用更改控制步骤来安排部署到生产服务器。
  • 检查 SLA 性能图   检查前一周的关键性能数据。根据 SLA 的需求检查性能。识别趋势和尚未达到其目标的项目。
  • 检查公用文件夹复制   检查公用文件夹复制是否是最新的。如果复制失败,用户可能无法访问数据,或者他们可能从远程站点访问数据,从而导致 WAN 通信逐渐增加。
  • 存档数据   将数据存档到 CD、DVD、磁带或类似媒体。用户离开后,根据贵组织的策略,您可能需要在一段时间内保留邮箱,然后将其存档以维护合理的 Exchange 存储大小。
  • 测试环境   应定期检查和维护空调、温度和湿度监视器以及物理安全措施。

建议每月执行下列任务和步骤:

  • 安全检查   根据要求的安全级别,可能适于执行定期的安全审核,包括防火墙规则、用户权限、组成员身份和委托权限等。
  • 容量规划   检查上一月的容量图并生成下一月可能需要的任何升级规划,以保持系统在 SLA 指定的限制之内运行。
  • 灾难恢复测试   对单个服务器执行系统恢复来测试硬件。这将模拟一个服务器的完整硬件故障并确保资源、规划和数据都可用于恢复。尝试每月进行轮转,以便每次测试不同服务器或其他设备的故障。例如,邮件中继服务器、前端 Exchange 服务器、后端 Exchange 服务器、防火墙等。

下列任务按需要执行,但经常也包括在标准步骤中:

  • 新用户和离开者   新用户通常需要用户帐户、邮箱、某些权限和组成员身份,还可能需要组织的 IT 和安全步骤的电子邮件副本等。要快速实现此任务,应记录确切的步骤。离开组织的人员必须有权访问他们的邮箱和其他已吊销的系统(通常非常紧急)。您可能需要一个策略来定义应如何处理发往用户的电子邮件(应该重新路由还是拒绝该邮件)。您还将需要一个步骤来说明用户离开后如何处理他们的 Exchange 数据。
  • 公用文件夹创建   您可授予用户创建某些公用文件夹的权限,但其他文件夹(尤其是顶级文件夹)只应由管理员创建。步骤中应定义谁可以提出请求以及应该应用哪些权限。
  • 邮箱恢复   通过使用邮箱恢复中心可以进行整个邮箱的恢复。如果在步骤中标准化该任务,则可以快速和安全地执行该任务。
  • 完全安全审核   该任务可以定期执行,也可以作为邮件系统升级或重新设计的响应而执行,或者作为尝试的(或成功的)安全缺口的响应而执行。此过程可能涉及服务器和防火墙上的端口扫描、安全修复程序审核和第三方渗透测试。
  • 更新性能基线   升级或配置更改后应更新性能基线。基线将用于测量性能更改和检测影响系统性能的问题。
  • 数据库维护   使用磁盘碎片整理来执行数据库维护。对硬盘进行碎片整理有助于提高磁盘性能,并确保 Exchange 服务器平稳有效地运行。
  • 其他数据库维护   其它数据库维护可以根据系统疑难解答进行分类。有一个关于如何使用 Isinteg.exe、Eseutil.exe 和其他标准工具以响应特定问题的步骤是非常有用的。

用于管理 Exchange 服务器和用户的基本工具集包括 Windows Server 2003 管理工具包和 Exchange Server 2003 系统管理工具。本节概述用于管理 Exchange Server 2003 组织操作的部分工具。这些管理任务和工具分为六组:

  • 活动目录和权限管理   Exchange Server 2003 与 Active Directory 紧密集成并依赖于 Active Directory。与 Exchange 服务器有关的用户属性(电子邮件地址、使用 POP 3 连接的能力和邮箱服务器等)作为用户属性存储在 Active Directory 中。因此,用于管理 Exchange 用户的重要工具是 Active Directory 用户和计算机 MMC 管理单元。
  • 安全更新和软件更新   因为大多数邮件系统连接到 Internet 并且必须能够接受来自未知系统的未经请求的连接,因此邮件系统特别容易受到恶意攻击。一旦有安全更新可用,便立即将它们全部应用到暴露给公共网络的服务器,这一点非常重要。确保在生产环境中部署安全更新之前,先在测试环境中对其进行测试。若要验证服务器是最新的并报告回操作系统和应用程序缺少的 Service Pack 和修补程序,可以使用 Microsoft Baseline Security Analyzer (MBSA)。应使用 MSBA(它可从 Microsoft 免费下载)对系统执行审核。有关详细信息,请访问 Microsoft 高信度计算:安全网站 (http://go.microsoft.com/fwlink/?LinkId=26388)(英文)。
    note注意:
    MBSA 寻找 Exchange Server 5.5 及更高版本上的安全更新。它不会检查 Exchange 是如何配置的。
    • 相反,软件更新服务 (SUS) 是用于自动部署安全更新和其他必要更新的工具。它对于更新工作站特别有用,但也可用于更新服务器。当 Microsoft 发行更新后,SUS 便会从 Internet 上自动下载每个更新。它允许您在自动部署新更新之前测试它。使用 Active Directory 策略,您可以控制哪些计算机接收更新以及如何应用更新。可以将工作站配置为下载并安装更新并根据需要重新启动,而无需手动干预。服务器通常配置为仅下载更新。管理员必须在方便的时候手动安装更新并重新启动服务器。有关 SUS 的详细信息,请访问 http://go.microsoft.com/fwlink/?LinkId=35215(英文)。
  • 安全管理   使用 IIS 锁定工具来保护 Internet Information Server 4.0、5.0 和 6.0。IIS 锁定 (IISlockd.exe) 工具只有在 Windows® 2000 Server 上才需要。在 Windows Server™ 2003 中,IIS 锁定是 Internet Information Services (IIS) 的核心部分。有关如何对在 Windows 2000 上运行 Exchange Server 2003 的服务器使用 IIS 锁定工具的详细信息,请参阅 Security Operations Guide for Exchange 2000 Server(英文)(http://go.microsoft.com/fwlink/?linkid=11906)。IIS 锁定工具由两个部分组成。第一个部分更改 IIS 内的配置设置以防止对 Web 服务器的常见攻击。它还提供删除或禁用未使用服务和网页的选项。第二个部分称为 URLScan,可防止来自 Web 浏览器的恶意和不正确请求。IIS 锁定内提供用于各种服务器角色的模板,可以只禁用特定服务器角色不需要的服务。在 Exchange 服务器上运行 IIS 锁定时,请确保使用用于适当 Exchange 版本的模板。有关 IIS 锁定向导的详细信息,请参阅 Microsoft 知识库文章 325864“如何安装和使用 IIS 锁定向导”(http://go.microsoft.com/fwlink/?LinkId=3052&kbid=325864)。
  • Microsoft Operations Manager   在中型和大型企业中,或在高可用性非常重要的组织中,应考虑使用自动工具来跟踪服务器的性能和可用性和进行容量管理。可以将这些工具配置为报告长期趋势,如在客户端数量增加时对 MAPI 客户端的响应逐渐下降。它们还可用于在发生故障时或服务快速下降时警告支持人员。Microsoft Operations Manager 是用于监视和警告、管理事件日志、报告和趋势分析的应用程序。它用于监视服务器和自动记录及分析来自许多计算机的事件和统计信息。有关 Microsoft Operations Manager 的详细信息,请访问 Microsoft Operations Framework 网站 ( http://go.microsoft.com/fwlink/?linkid=21640 )(英文)。
  • Systems Management Server   Systems Management Server 是一个工具,它使您能够通过收集硬件和软件资产的相关信息、将此数据存储在 SQL Server 数据库中、并允许生成自定义查询和报表来自动化配置管理任务。除了执行配置管理的报告任务外,Systems Management Server 还可部署软件、Service Pack 和修补程序。可以将 Systems Management Server 配置为自动检测网络上的设备并将代理部署到每个服务器或工作站中。
    每个代理从设备收集配置数据并将信息传递回到中央数据库。因此,它可用于自动化更改管理一节中讨论的许多定期更改。Windows Server 2003 软件部署服务可用于将软件部署到整个组织或特定组织单位 (OU) 中的计算机或用户。由于 Systems Management Server 的灵活性,您可以,例如,只将软件部署到特定 OU 内、运行 Windows XP、至少具有 2 GB 可用磁盘空间和 256 MB RAM 的客户端上。有关 System Management Server 的详细信息,请访问 http://go.microsoft.com/fwlink/?LinkId=34976 (英文)。
  • Exchange Server 2003 工具   用来管理 Exchange Server 2003 组织的标准工具,包括 Exchange 系统管理器和 Exchange 迁移向导。有关使用 Exchange 系统管理器执行标准任务的详细信息,请参阅主题“每日操作任务”。Exchange 迁移向导用于从其他邮件系统(如 Exchange Server 5.5、Exchange 2000 Server、Microsoft Mail for PC Networks 或 Lotus cc:Mail)将用户邮箱迁移到 Exchange Server 2003。
  • 自动化工具和脚本   通过使用脚本可以使许多管理任务自动化。Microsoft Windows Scripting Host (WSH) 是支持脚本运行的宿主应用程序,在 Windows Server 2003 和 Windows XP Professional 上默认安装该程序。在众多脚本语言中,VBScript(Visual Basic® 的派生语言)最常用于管理任务,在这些任务中,代码编写速度比代码的细致和效率更重要。Web 上有许多有用脚本的示例,可以将它们自定义以适合您的需要。有关有用脚本的示例,请访问 Microsoft TechNet 网站 (http://go.microsoft.com/fwlink/?linkid=33284) 上的“Script Center”(英文)。
 
显示: