注重 在混合模式组织中，每个站点都是一个治理组，不能使用本节讨论的治理模型。
使用分散式治理模型
在分散式治理模型中，对 Exchange 系统治理的整体控制分散在公司的各个地理区域或分部中。在这种类型的模型中，每个区域或分部控制它自己的资产，并负责对自己的系统进行治理。
这种类型的组织可能在每个分部或团体都至少有一个治理组。每个位置都有它自己的 Exchange 治理员组，这个组对其治理组中的对象具有完全治理控制权。
许多公司实行分散治理模型，目的前镏镜拿扛龇种Щ棺灾髟诵小＠纾珻ontoso 在美国、欧洲和亚洲的每个全球性分支机构都对自己分支机构的治理组、路由组、策略、服务器、公用文件夹树以及其他对象具有控制权（见图 2.12）。
图 2.12 分散式治理模型
使用集中式治理模型
在集中式治理模型中，一个或几个受控制的治理组保持对 Exchange 系统的完全控制权限。例如，图 2.13 表明 Contoso 在西雅图的治理组对公司的 Exchange 系统拥有完全控制权限。
图 2.13 集中式治理模型
这种治理模型类似于一个数据中心，其中的所有治理任务都由一个信息技术组执行。这种治理模型在中小型组织中是很常见的，但是也可以用在与所有区域办公室都具有高带宽连接的大型组织中。
使用混合治理模型
在混合模型中，治理组同时反映了功能和地理分布。您可以创建专门的治理组以便限定某些功能的治理由特定人群负责，并创建其他治理组以便沿着地理路线委派治理任务。为了说明这种类型的模型，下面列举了一些您可能需要创建的治理组示例：
· 要限定可以创建并维护策略的用户，可以专门为治理策略而创建一个治理组，这是一项功能性的任务。
· 为了治理特定区域中的公用文件夹，可以创建一个治理组来专门治理该区域的公用文件夹，这是出于地理位置上的考虑。
通常，对于在许多地理位置有多个分部或办公室的大型组织而言，应使用混合治理模型。在一家公司收购另一家公司的情况下，也可以使用混合模型。
图 2.14 显示 Contoso 如何在其组织中应用混合治理模型。为了集中治理公用文件夹和策略，Contoso 为治理公用文件夹而创建了一个中心治理组，为治理策略而创建了另一个治理组。余下的治理组是区域性的，并答应对其他功能（如路由组）进行区域性控制。
图 2.14 混合治理模型
显示治理组
在 Exchange 2003 或 Exchange 2000 组织中安装 Exchange 后，Exchange 系统治理器并不会自动显示治理组和路由组。必须配置 Exchange 组织显示治理组。在配置此设置后，可以查看"治理组"容器并为组织创建其他治理组。
注重 假如在 Exchange 5.5 站点中安装 Exchange 2000（或更高版本），默认情况下 Exchange 将启用治理组和路由组。这种情况下，每个 Exchange 5.5 站点都以治理组的形式出现。
显示治理组
1. 在 Exchange 系统治理器中，用鼠标右键单击您的 Exchange 组织，然后单击"属性"。
2. 在"常规"选项卡上（见图 2.15），选择"显示治理组"。
图 2.15 显示治理组
3. 重新启动 Exchange 系统治理器以应用更改。
创建治理组
在 Exchange 组织的默认配置中，只存在一个治理组。可以将所有服务器安装到这一个治理组中（这在集中式治理模型中很有用），也可以创建其他治理组并将服务器安装到相应的治理组中（基于治理模型）。
默认情况下，Exchange 将所有服务器安装到"第一个治理组"中的"服务器"容器中。可以重命名"第一个治理组"，并添加新的系统容器，但是不能从该组的"服务器"容器中删除服务器。
注重 在混合模式组织中，每个 Exchange 5.5 站点都成为它自己的治理组，并且治理组名称与站点名称匹配。
只能在安装服务器的过程中将其添加到治理组中。最好是在组织中的第一台 Exchange 服务器上创建必要的治理组，然后将其他服务器安装到相应的治理组中。永远不能在治理组之间移动服务器。
注重 SP1 中的新增功能：可以在混合模式下的治理组之间移动邮箱。最好是只在某些情况下（例如，站点合并期间）才以混合模式跨治理组移动邮箱。有关具体信息，请参阅"规划 Exchange Server 2003 邮件系统"(http://go.microsoft.com/fwlink/?LinkId=21766) 和"Exchange Server 2003 部署指南"(http://go.microsoft.com/fwlink/?LinkId=21768)。
创建新的治理组
· 在 Exchange 系统治理器中，用鼠标右键单击"治理组"，指向"新建"，然后单击"治理组"。
在治理组之间移动对象
可以将一个治理组中的一些对象移动到另一个组。但是，另外一些对象是不能移动的。
下面列举了可以在治理组之间移动的对象：
· 系统策略
· 公用文件夹
· 路由组成员服务器（仅限于纯模式）
· Exchange Server 2003 SP1 和更高版本中的邮箱。最好是只在某些情况下（例如，站点合并期间）才以混合模式跨治理组移动邮箱。有关具体信息，请参阅"规划 Exchange Server 2003 邮件系统"(http://go.microsoft.com/fwlink/?LinkId=21766) 和"Exchange Server 2003 部署指南"(http://go.microsoft.com/fwlink/?LinkId=21768)。
下面列举了不能在治理组之间移动的对象：
· 服务器
· 容器
只能在相同类型的容器之间移动对象。例如，可以将系统策略从一个系统策略容器移动到另一个治理组中的另一个系统策略容器，但是不能将系统策略移动到公用文件夹容器中。这种类型的操作默认情况下被禁止。
在治理组之间移动系统策略或公用文件夹
· 将系统策略或公用文件夹从源容器中剪切下来，⒄程侥勘耆萜髦小?br>
-或者-
· 将系统策略或公用文件夹从源容器拖动到目标容器中。
注重 在治理组之间移动或复制对象后，需单击"刷新"才能在新的容器中看到对象。
删除治理组
只能删除不包含对象的治理组。在删除某个治理组中的所有对象后，可以将该治理组删除。
删除治理组
· 在 Exchange 系统治理器中，展开"治理组"，用鼠标右键单击要删除的治理组，然后单击"删除"。
使用系统策略
系统策略是应用于一个或多个服务器、邮箱存储或公用文件夹存储的配置设置的集合。例如，要在多个服务器上启用邮件跟踪，可以只定义一个策略，而不必重复执行这一繁琐的任务 - 在每个服务器上逐个设置策略以便启用邮件跟踪。定义并实现策略后，可以通过编辑策略并应用更改来更改组织中所有服务器的配置。
为某个治理组创建的系统策略通常应用于该组中的对象。但是，系统策略也可以应用于它所在治理组之外的对象。例如，通过在一个中心治理组中创建服务器策略，并将它应用于组织中的所有服务器，可以对所有服务器实现一致的邮件跟踪选项。
策略出现在治理组下的"系统策略"容器中（见图 2.16）。
图 2.16 "系统策略"容器
有三种类型的系统策略：
· 公用文件夹存储策略：答应配置跨越公用文件夹存储的设置。
· 邮箱存储策略：答应配置跨越邮箱存储的设置。
· 服务器策略：答应在服务器上启用邮件跟踪选项。
对于这三种类型的系统策略，本节将只具体讨论服务器策略。有关配置公用文件夹存储策略或邮箱存储策略的信息，请参阅第 7 章"治理邮箱存储和公用文件夹存储"。
了解系统策略如何影响各个设置
系统策略使用 apply-time 实现来影响配置更改。可以创建策略、为该策略指定设置、将该策略与一个或多个服务器或公用文件夹存储关联，然后应用该策略。应用策略后，各个对象特有的相应设置将不可用，并呈现为灰色。这是因为这些设置现在由策略而不是各个对象控制。例如，假如创建启用邮件跟踪的策略，并将该策略应用于 Exchange 服务器，则该服务器的邮件跟踪选项将不可用（见图 2.17）。此配置使得治理员可以防止由策略控制的各个对象的设置被进一步更改。
图 2.17 服务器上的邮件跟踪选项被禁用
创建服务器策略
您对邮件跟踪使用服务器策略，并维护邮件跟踪日志文件的设置。当启用邮件跟踪以便跟踪邮件时，Exchange 将邮件存储在邮件跟踪日志文件中。通过启用主题日志记录和显示，可以在邮件跟踪中心存储邮件主题。可以使用邮件跟踪中心查看邮件。第 3 章"配置 Exchange 服务器设置"进一步具体说明了邮件跟踪和主题日志记录。
在治理组中创建服务器策略（或创建其他任何系统策略）之前，必须添加系统策略容器。创建系统策略容器后，即可创建服务器策略。
创建系统策略容器
· 在 Exchange 系统治理器中，展开"治理组"，用鼠标右键单击相应的治理组，指向"新建"，然后单击"系统策略容器"。
创建服务器策略
1. 在 Exchange 系统治理器中，展开"治理组"，再展开相应的治理组，用鼠标右键单击"系统策略"，指向"新建"，然后单击"服务器策略"。
2. 在"常规（策略）"选项卡上（见图 2.18），选择如下选项：
· 要记录邮件主题，并使该主题在邮件被跟踪后可见，请选择"启用主题日志记录和显示"。
· 要跟踪流进/流出服务器的所有邮件，请选择"启用邮件跟踪"。
图 2.18 服务器策略上的邮件跟踪选项
处理策略冲突
假如新建的策略与现有策略中的设置冲突，Exchange 将显示对话框通知您发生冲突。默认情况下，较新的策略将替换较旧的策略。例如，您用指定的配置创建服务器策略，并希望将该策略添加到特定的服务器中。但是，假如该服务器已处在另一个策略的控制下，将出现一个对话框，提示您确认是否要取消另一策略对该服务器的控制。可以选择取消前一个策略对该服务器的控制，或应用刚刚创建的新策略。假如不解决策略冲突，将出现下列消息：
The objectname (for example, Server1) could not be associated with policy policyname (ServerPolicy) because you refused to remove the object from the control of conflicting policies.
将服务器添加到服务器策略中
创建服务器策略后，必须将服务器添加到该策略中。
将服务器添加到服务器策略中
1. 在 Exchange 系统治理器中，展开"治理组"，再展开包含服务器要添加到的服务器策略的治理组，展开"系统策略"，用鼠标右键单击该服务器策略，然后单击"添加服务器"。
2. 在"选择将受此策略控制的项目"对话框中（见图 2.19），键入服务器名，然后单击"确定"。
图 2.19 选择将受服务器策略控制的项目
注重 图 2.19 显示了在 Microsoft Windows Server? 2003 上运行 Exchange 2003 时出现的对话框。假如在 Windows? 2000 Server 上运行 Exchange，此对话框提供相同的功能，但显示稍有不同。
查看受系统策略控制的对象
使用 Exchange 系统治理器，可以查看系统策略控制的对象，或 Exchange 应用于某个对象的策略：
· 要查看策略控制的对象，请单击"系统策略"容器中的策略。将在具体信息窗格中的"策略应用于"下列出对象。
· 要查看 Exchange 应用于特定对象的策略，请单击服务器"属性"对话框中的"策略"选项卡。
在治理组之间复制系统策略
在 Exchange 2003 中，可以在位于不同治理组中的策略容器之间复制或移动策略。复制策略有助于您在委派治理控制权的同时，在各个治理组的策略之间保持一致或类似的设置。例如，可以创建一次服务器策略，然后将它复制到需要的其他每个治理组中的系统策略容器中。然后，各个治理组的治理员可以基于此模板自定义策略，以便治理与自己的治理组关联的对象。
注重 请记住，只能在治理组之间复制各个策略，而不能将系统策略容器从一个治理组复制到另一个治理组。
在治理组之间复制策略对象
1. 在 Exchange 系统治理器中，用鼠标右键单击该策略，再单击"复制"，然后将该策略粘贴到目标容器中。
2. 用鼠标右键单击目标容器，然后单击"刷新"查看该容器中的策略。
复制策略后，必须将它应用于该策略复制到的治理组中的各个服务器、邮箱存储或公用文件夹存储。
修改或删除策略
可以修改应用于一个或多个对象的策略以更改所有对象的属性。
修改策略
1. 在 Exchange 系统治理器中，用鼠标右键单击要修改的策略，再单击"属性"，然后使用各个选项卡修改策略。
2. 在进行必要的修改后，用鼠标右键单击策略，然后单击"立即应用"以应用更改。
要分别更改各个对象的属性，还可以取消策略对某个对象的控制，或删除策略本身。
取消策略对某个对象的控制
1. 在 Exchange 系统治理器中，展开"系统策略"，然后单击相应的系统策略。
2. 在"策略应用于"列中，用鼠标右键单击对象，指向"所有任务"，再单击"从策略中删除"。
删除策略
· 在 Exchange 系统治理器中，用鼠标右键单击要删除的策略，然后单击"删除"。
应用策略后，关联的对象上与该策略关联的设置保持不变，即便已取消策略对某个对象的控制或已删除策略本身，也是如此。假如要更改策略应用的设置，必须在各个服务器、邮箱存储或公用文件夹存储上进行此项操作。
治理权限
治理 Exchange 组织时，一些最为重要的安全任务将涉及到权限。在 Exchange 2003 中正确地治理权限确保了用户和治理员能够成功地完成他们必须执行的那些任务，同时防止用户和治理员有意或无意地执行不适当的任务。
在 Exchange 2003 中，可以治理的权限有三组：
· Exchange 对象的权限。这些设置存储在 Active Directory 和 Microsoft Internet 信息服务 (IIS) 元数据库中。
· 存储权限。
· NTFS 文件系统卷上的文件权限。
这些权限共同提供了在 Exchange 2003 安装中的所有元素上实现安全性的方法。
本节集中讲述了使用 Exchange 系统治理器治理 Active Directory 和 IIS 元数据库中的 Exchange 对象的权限。有关治理存储权限的具体信息，请参阅第 7 章"治理邮箱存储和公用文件夹存储"。有关了解和治理 NTFS 权限的具体信息，请参阅 Windows 文档和资源工具包。
要点 应只使用 Exchange 系统治理器来设置 Exchange 对象的权限。
了解 Exchange 对象和 Exchange 系统治理器
安装的 Exchange 软件中的大多数元素都是通过对象来表示的。例如，服务器本身、SMTP 虚拟服务器以及邮箱存储都表示为对象。对其中每个对象的控制都是通过一组安全权限来实现的。Exchange 2003 中对象的权限是基于 Windows 操作系统通过 Active Directory 和 IIS 实现的权限构建的。Exchange 2003 使用 Active Directory 和 IIS 元数据库来存储有关 Exchange 对象的权限信息。
考虑到有关 Exchange 对象的信息存放在两个位置这一事实，应使用 Exchange 系统治理器来治理这些对象。这一工具统一表示存储在 Active Directory 和 IIS 元数据库中的对象。因此，可以通过一个界面治理存储在两个位置的对象。
Exchange 系统治理器暴露的权限模型是基于 Windows 安全模型构建的，后者是基于随机访问控制概念的面向对象安全模型。这意味着每个 Exchange 对象都有它自己的独立权限（以便控制对该对象的访问），并且这些权限可以由具有适当权限级别的任何人治理。此权限模型使得在安全策略要求进行委派的环境中实现委派的权限模型成为可能，即根据特定角色执行的功能性任务，为其分配不同的权限。
但是，使得 Exchange 满足复杂安全要求的大量对象和权限也使治理工作看上去很复杂。幸运的是，Exchange 系统治理器通过下列功能简化了权限治理：
· 支持继续
· 标准安全角色
· Exchange 治理委派向导
这些功能一起发挥作用，简化了权限的治理，以致于大多数 Exchange 实现都可以实现它们的安全要求，而不必对各个对象的各个属性设置权限。
支持继续的好处
在 Windows 中，"继续"描述的是这样一个过程：对象在创建时默认情况下继续其父对象的权限。
继续简化了在 Exchange 系统中治理权限的任务，这表现在下列方面：
· 它使得无需在创建子对象时手动对其应用权限。
· 它确保了附属于父对象的权限以一致的方式应用于所有子对象。
· 假如必须修改某个容器内所有对象的权限，只需更改一次该容器的权限。容器内的对象将自动继续更改。
对于某些 Exchange 对象，可以自定义此继续。这些对象包括公用文件夹树、地址列表和邮箱存储。对于这些对象，可以指定子对象不继续权限。或者，可以指定下列容器或子容器继续权限：
· 仅此容器
· 此容器及所有子容器
· 仅子容器
继续使得在对象的层次结构中以一致的方式应用权限成为可能。就继续本身而言，它是一个简化权限应用的重要工具。
Exchange 中标准安全角色的价值
为了帮助简化权限治理过程，Exchange 2003 提供了三个预定义的安全角色，可以在 Exchange 治理委派向导中使用这些角色。这些角色是标准权限的集合，可以应用在组织或治理组级别。
注重 有关治理组的信息，请参阅本章前面的"创建和治理治理组"。
帐户或组应用这些角色后，将立即被授予相应对象上的一组标准权限。角色十分依靠于权限继续，以确保权限的应用保持一致。应用角色后，与该角色关联的标准权限通过继续应用到层次结构中的下级对象。
由于设计角色是为了满足 Exchange 部署中常见的安全要求，因此应尽可能多地尝试使用这些角色。
Exchange 2003 提供的标准安全角色有：
· Exchange 治理员（完全控制）：该角色对 Exchange 系统信息具有完全治理权限并可以修改权限。此角色适用于必须能够修改权限以及查看和治理 Exchange 配置信息的人员。
· Exchange 治理员：该角色对 Exchange 系统信息具有完全治理权限。该角色不同于 Exchange 治理员（完全控制）。主要区别是该角色不能修改权限。该角色适用于必须能够查看和治理 Exchange 配置信息而不需要能够修改权限的人员。
· Exchange 治理员（仅查看）：该角色可以查看但不能治理 Exchange 配置信息。该角色适用于必须能够查看 Exchange 配置信息而不需要能够更改该配置信息的人员。与 Exchange 治理员角色一样，该角色也不能修改权限。
注重 不要将 Exchange 安全角色与 Active Directory 中的安全组弄混。角色是应用于 Active Directory 中的用户或组的一组标准权限。可以将角色想像成模板，而不要想像成安全组。
由于这些角色是一组标准权限，与安全组不同，角色具有相互取代的固有特性，因此，没有必要同时应用较高级和较低级的特权角色。应用较高级特权角色已足够。应用于组织的角色和应用于治理组的角色稍有不同。因此，应用角色后所导致的有效权限也可能稍有不同。
表 2.1 到 2.3 列出了有效权限（基于应用的角色以及应用的位置）。这些表帮助说明了角色是如何相互取代的，以及在组织级别和治理组级别产生的不同影响。
注重 没有表显示在治理组级别应用的角色在组织级别应用后的有效角色。这是因为在治理组级别应用的角色只适用于本地治理组。由于治理组位于层次结构中组织级别的下面，因此治理组可以继续组织的权限，但反过来则不成立。
表 2.1 在治理组级别应用的角色在治理组级别应用后的有效角色
表 2.2 在组织级别应用的角色在治理组级别应用后的有效角色
表 2.3 在组织级别应用的角色在组织级别应用后的有效角色
Exchange 治理委派向导的价值
Exchange 治理委派向导在 Exchange 系统治理器中的组织级别或治理组级别应用标准安全角色。
需记住的一点是，Exchange 治理委派向导以一致的方式对 Exchange 层次结构中的对象应用经过认真测试的权限。由于权限应用的这种一致性，因此该向导是在 Exchange 环境中治理权限的推荐和首选的方法。可以对各个对象应用自定义权限，但前提是安全策略要求这样做，并且是在完成测试之后。手动创建自定义权限增加了出现人为错误的可能性。还增加了由于误解权限的工作原理而创建不适当权限的可能性。此外，自定义的安全设置需要更多的维护，因为必须对它们进行存档，并且必须对自定义设置进行检验。虽然在某些情况下自定义安全设置是适宜的，但是必须认真地权衡风险和成本。
可以从组织级别或治理组级别启动 Exchange 治理委派向导。本章前面的"Exchange 中标准安全角色的价值"已指出，与角色关联的权限将在层次结构中从启动该向导时所在的对象向下应用。例如，假如在组织级别启动该向导，与角色关联的权限将应用于层次结构中组织以下的所有对象，包括所有的治理组。或者，假如在治理组启动该向导，与角色关联的权限将只应用于该治理组中的对象。
当启动 Exchange 治理委派向导时，它会提示您指定要将安全角色应用于哪些用户和组。通常，建议您将用户放入安全组内，然后使用向导对这些组应用角色。对各个用户应用权限很快就会使得治理工作变得很困难。
向导完成后，Exchange 系统治理器将权限应用于层次结构（向导启动时所处的位置）中选定的组或用户。权限将通过继续在层次结构中向下传播。通过使用该向导，只需若干次单击操作便可对 Active Directory 和 IIS 元数据库中的 Exchange 对象设置所有权限。
注重 有关治理存储权限的具体信息，请参阅第 7 章"治理邮箱存储和公用文件夹存储"。
