Exchange 2013共存|自动发现基础设施|第 2/2 部分 | 12#23

当前文章的重点是内部/私有环境中的 Exchange 自动发现基础结构。

在本文中，我们将回顾以下主题：

1. Exchange 自动发现环境的总体审查
2. Exchange 2013 共存环境中 Exchange 自动发现基础结构的具体特征
3. 实施“自动发现中心化模式”的原因
4. Active Directory SCP（服务连接点）和 Exchange 自动发现名称注册概念以及使用 PowerShell 的管理。

本篇文章是上一篇文章的延续：Exchange 2013共存环境|自动发现基础设施|第 1/2 部分

内部网络环境中自动发现基础设施的一般概念

在我们开始描述 Exchange 2013 共存环境中的 Exchange 内部自动发现之前，有必要回顾一下内部 Exchange 环境中的自动发现逻辑的一些基本概念，然后才“继续”到自动发现的描述在 Exchange 2013 共存环境中。

场景 1：Exchange 站点上的内部自动发现流程

单个 Exchange 站点环境中的“标准内部自动发现流程”通过以下方式实现：

交换CAS服务器在Active Directory SCP（服务连接点）中注册自己。

当Exchange客户端（自动发现客户端）需要定位自动发现端点（Exchange CAS服务器）时，他会查询Active Directory，获取现有Exchange CAS服务器的列表，并向Exchange CAS服务器寻址以获取所需的自动发现信息。

场景 2：多个 Exchange 站点环境中的内部自动发现流程

多 Exchange 站点环境中的“内部自动发现过程”通过以下方式实现：

每个 Exchange CAS 服务器都在 Active Directory SCP（服务连接点）中注册自己。

当Exchange客户端需要定位自动发现端点（Exchange CAS服务器）时，他会查询Active Directory，获取现有Exchange CAS服务器的列表，并根据“Active Directory站点”从列表中选择最“合适”的Exchange CAS服务器财产。

Exchange 客户端始终更愿意连接与他位于同一 Active Directory 中的“本地 Exchange CAS 服务器”。
在我们的场景中，“红色 Exchange 客户端”将更愿意连接站点 1 中的 Exchange CAS 服务器获取所需的自动发现信息。
在我们的场景中，“黄色 Exchange 客户端”将更愿意连接站点 2 中的 Exchange CAS 服务器以接收所需的自动发现信息。

Exchange 2013 共存环境中的内部自动发现基础结构

Exchange 2013 共存环境的场景需要对内部自动发现基础结构实施调整。

共存环境中内部自动发现基础结构的最佳实践基于 Exchange 2013 CAS 充当“自动发现焦点”的概念

该术语的含义是，在 Exchange 2013 共存环境中，Exchange CAS 不是在多个 Exchange 站点中实现的默认自动发现基础结构（其中每个 Exchange 站点都有自己的“自动发现端点”），而是 Exchange CAS 2013 年将“替换”“其他自动发现信息源”（旧版 Exchange CAS 服务器），并将该模型转变为“集中式模型”，其中只有一个自动发现信息源：Exchange CAS 2013。

场景一：Exchange 2013共存环境|单一Exchange站点环境

此方案的章程是单个 Exchange 站点，其中包括多个版本的 Exchange 服务器。从技术上讲，每台 Exchange CAS 服务器都可以提供自动发现服务，但如前所述，“旧版 Exchange CAS 服务器”向更多“高级 Exchange 客户端”提供自动发现服务的能力是有限的。

例如，Exchange 2007 CAS 将无法为 Exchange 2013 客户端提供所需的自动发现服务。

因此，解决方案是将 Exchange CAS 2013 服务器“加冕”为所有不同类型 Exchange 客户端的“焦点自动发现点”。

在下图中，我们可以看到一个概念示例，其中 Exchange CAS 2013 服务器成为特定 Exchange 站点中内部 Exchange 客户端的自动发现服务的焦点。

每个不同的 Exchange 客户端（例如：Exchange 2007、2010 和 2013）将向 Exchange CAS 2013 服务器查找自动发现服务。 Exchange CAS 2013 服务器“足够智能”，能够根据 Exchange 客户端的版本了解或提供所需的“自动发现答案”。

场景2：Exchange 2013共存环境|多交换站点环境|集中式自动发现模型

在当前方案中，组织 Exchange 基础结构基于多个 Exchange 站点基础结构。

在 Exchange 2013 共存环境中，Exchange 2013 共存环境成为“自动发现信息的主要来源”，即使对于物理上位于另一个 Exchange 站点的 Exchange 客户端也是如此。

在此方案中，每个自动发现 Exchange 客户端必需项（所有站点的 Exchange 客户端）将始终寻址到站点 1 中的 Exchange CAS 2013 服务器。

当站点 1 上的 Exchange CAS 2013 服务器收到自动发现请求时，他将识别 Exchange 客户端，查询有关特定用户的 Active Directory 并找到确切的“Exchange 客户端版本”。

例如，如果 Exchange 客户端的邮箱托管在 Exchange 2010 邮箱服务器上，则 Exchange CAS 2013 服务器“了解”他需要向该特定 Exchange 2010 客户端提供特定的自动发现信息。

在这种情况下，Exchange CAS 2013 服务器会将请求代理到 Exchange 2010 CAS 服务器（与 Exchange 客户端位于同一 Active Directory 中的 Exchange 2010 CAS 服务器），从 Exchange 2010 CAS 服务器获取所需的自动发现信息并提供此信息到 Exchange 2010 客户端。

Exchange 2013共存环境分布式自动发现模型|被禁止的模型

在上一节中，我们必须回顾一下 Exchange 2013 共存环境中自动发现基础结构的最佳实践配置。

从技术上讲，“最佳实践”不是强制性的，此外，我不熟悉 Microsoft 的正式文章，该文章描述了 Exchange 2013 共存环境中自动发现基础结构的最佳实践建议。

假设，由于某种原因，您不愿意采用最佳实践的建议，而您更愿意使用“标准自动发现基础设施”。

一个小线索：在下一节中，我们将演示在 Exchange 2013 共存环境中不使用最佳实践自动发现模型的后果。

在“非 Exchange 2013 共存环境”或同类 Exchange 环境中，在多个 Exchange 站点的情况下，每个 Exchange 站点都有一个“本地 Exchange CAS 服务器”，充当本地 Exchange 客户端的自动发现端点。

为了能够演示这个概念，让我们使用以下场景。

组织拥有三个 Active Directory 站点和两个 Exchange 站点（其中一个公司站点不包括 Exchange 基础结构）。

• 站点 1 基于 Exchange 2013 基础结构。
• 站点 2 基于 Exchange 2007 基础结构

有关两个 Exchange CAS 服务器的信息在 SCP（服务连接点）的 Active Directory 中注册。

在下图中，我们可以看到，在我们的场景中，Active Directory SCP 包含有关两个不同 Exchange CAS 服务器的信息。
站点 1 的 Exchange CAS 服务器和站点 2 的 Exchange CAS 服务器。

当站点 1 的内部 Exchange 2013 客户端查找自动发现端点时，他将获得一个包含 Exchange 2007 CAS 和 Exchange 2013 CAS 名称的列表。由于“站点 1 Exchange 客户端”和 Exchange 2013 CAS 位于同一站点，因此站点 1 的 Exchange 客户端将选择寻址 Exchange 2013 CAS。

同样的逻辑将在站点 2 的内部 Exchange 2007 客户端中实现。当“站点 2 Exchange 客户端”查询 Active Directory 时，他会获取可用 Exchange CAS 服务器的列表，他会更喜欢寻址本地 Exchange CAS 服务器，这意味着： Exchange 2007 CAS。

我们审查的“分布式”自动发现基础设施可能会导致 Exchange 客户端访问“错误的 Exchange CAS 服务器”的问题。

如前所述，更现代版本的 Exchange CAS 服务器可以为“本机 Exchange 客户端”（与 Exchange CAS 服务器具有相同版本的 Exchange 客户端）提供服务，此外还可以为旧版 Exchange 客户端提供服务。

例如 - Exchange 2013 CAS 可以满足 Exchange 2013 客户端 + Exchange 2007 客户端的自动发现请求。

此规则不适用于以前版本的 Exchange CAS 服务器。 Exchange 2007 CAS 可以处理 Exchange 2007 客户端的自动发现请求，但无法处理 Exchange 2013 客户端的自动发现请求。

问题 1：没有本地 Exchange CAS 服务器的 Exchange 站点

在以下场景中，Exchange 2013 客户端位于 Active Directory 站点 3 中。当 Exchange 2013 客户端在 Active Directory 中查询可用 Exchange CAS 服务器列表时，他将获得 Exchange 2013 CAS + Exchange 2007 CAS 的名称。

Q1：Exchange 客户端会从列表中选择哪一台 Exchange CAS 服务器？
A1：答案是，在这种情况下，Exchange 2013 客户端会随机选择一个Exchange CAS 服务器的名称。

• 如果 Exchange 2013 客户端选择 Exchange 2013 CAS 的名称，自动发现过程将成功完成。
• 如果 Exchange 2013 客户端选择 Exchange 2007 CAS 的名称，则自动发现过程将无法成功完成。

问题 2：Exchange 客户端位于其他 Active Directory 站点。

当前的场景章程是：“属于”站点 1 的 Exchange 2013 客户端正在访问其他公司站点：站点 2。
当自动发现 Exchange 2013 客户端时，创建一个查询，查找可用的 Exchange CAS 服务器的名称，“答案”将包括两个名称：站点 1 中的 Exchange 2013 CAS 和站点 2 中的 Exchange 2007 CAS。

在这种情况下，Exchange 2013 客户端将选择 Exchange 2007 CAS 的地址，因为从他的角度来看，这是“最近的 Exchange CAS 服务器”。

在这种情况下，自动发现过程将无法成功完成，因为 Exchange 2007 CAS 无法向 Exchange 2013 客户端提供“正确的自动发现信息”。

Exchange 2013共存环境| Active Directory SCP 所需的更新

正如前面几节提到的，在 Exchange 2013 共存环境中，我们需要实施“集中式自动发现模型”，其中 Exchange CAS 2013 将充当自动发现信息的“主要来源”。

这种“集中式自动发现模型”的实现是通过更新 Active Directory SCP 中存在的现有自动发现信息来实现的。在实施所需的更新之前，Active Directory SCP 将包含指向旧版 Exchange CAS 服务器的“指针”。

默认情况下，每个 Exchange CAS 服务器都知道如何在 Active Directory 中的一个名为 SCP（服务连接点）的特殊系统文件夹中自动注册自己。

在 Exchange 共存环境中，此“默认行为”将导致出现问题，因为当 Exchange 客户端在 Active Directory 中查询可用 Exchange CAS 服务器列表时，Exchange CAS 服务器列表将包含有关 Exchange CAS 服务器的信息。具有不同的服务器版本。

例如，Exchange 2013 客户端需要获取自动发现基础结构。
位于具有三个不同 Exchange CAS 服务器的 Exchange 站点上的 Exchange 2013 客户端。

在下图中，我们可以看到包含三“代”Exchange CAS 版本的 Exchange 基础架构场景。

Exchange 客户端查询 Active Directory 并获取三个自动发现 URL 地址的列表。
Exchange 2013 客户端现在面临的主要问题是 - 如何决定选择哪个 Exchange CAS 服务器名称？

计算成功自动发现事件与不成功自动发现事件的数学概率的公式可能非常复杂。
我们需要实现一个配置，其中自动发现过程将在 100% 的情况下成功完成！

为了能够消除“较新的 Exchange 客户端”将寻址“较旧的 Exchange CAS 服务器”的情况，我们需要从 Active Directory SCP 中删除所有将 Exchange 客户端指向旧版 Exchange 基础架构的指针，并维护自动发现指针仅指向 Exchange 2013 基础结构（指向 Exchange 2013 CAS 服务器的指针）。

在我们的场景中，我们需要从 Active Directory SCP 中“删除”指向以下各项的指针： Exchange 2010 CAS 服务器：cas2010-01.o365info.com 和 Exchange 2007 CAS服务器：cas2007-01.o365info.com

当邮件客户端（2007、2010 或 2013）查询 Active Directory 时，Active Directory“答案”将仅包含 Exchange 2013 CAS 服务器的名称。

Exchange CAS 2013 服务器自动发现服务的变色龙

我们可以使用一个有趣的比喻来描述 Exchange CAS 2013 与不同版本的自动发现客户端相关的“行为”方式，可以是：将 Exchange CAS 2013 作为变色龙。

就像变色龙根据所处的特定环境改变肤色并“适应”新的基础设施一样，Exchange CAS 2013 的操作方式也类似。

当Exchange 2013 CAS“接受”自动发现请求时，他不会应答自动发现客户端，直到他验证了Exchange 客户端版本。根据 Exchange 客户端版本，Exchange 2013 CAS 将实施“自定义流程”，该流程将以自动发现响应结束，其中包括针对特定 Exchange 客户端自定义的自动发现信息。

Exchange CAS 2013 使用的自动发现信息的来源

如前所述，Exchange CAS 2013 知道如何向每个不同的 Exchange 客户端自动发现客户端提供它们所需的特定自动发现信息。

可能出现的问题是：Exchange CAS 2013 如何知道什么是“正确的自动发现信息？”

或者换句话说，Exchange CAS 2013 用于获取不同类型（版本）的 Exchange 客户端所需的自动发现信息的信息来源是什么？

答案是 Exchange CAS 2013 知道如何处理其他“来源”以获取所需的自动发现信息。

在下图中，我们可以看到 Exchange 2013 CAS 服务器为不同版本的 Exchange 客户端提供服务而实现的不同“自动发现流程”的示例。

例如：当 Exchange 2010 客户端（其邮箱托管在 Exchange 2010 邮箱服务器上的 Exchange 客户端）连接 Exchange 2013 CAS 服务器时，Exchange 2013 CAS 服务器会将 Exchange 客户端识别为“Exchange 2010 客户端”。
为此，他将请求代理到Exchange 2010 CAS服务器，获取所需的自动发现信息并将信息“传递”到Exchange 2010客户端。

注意：与 Exchange 2013 CAS 服务器充当内部 Exchange 自动发现请求的焦点相同的概念，也用于为外部/公共 Exchange 邮件客户端提供服务。

管理 Active Directory SCP 中的自动发现信息

尽管正式声明：“本文实际上不是一篇‘如何做’的文章，而是：‘一般概念和架构的文章’，但对实现Exchange 2013 共存环境中所需的自动发现基础结构更新。

更新 Active Directory SCP

我们用于更新存储在 Active Directory SCP 中的“内部自动发现信息”的方法是使用 PowerShell 命令。

我们使用的 PowerShell 命令是：

• Get-ClientAccessServer - 用于查看存储在 Active Directory SCP 中的信息。
• Set-ClientAccessServer - 用于更新存储在 Active Directory SCP 中的信息。

为了能够在 Exchange 2013 共存环境中演示所需的自动发现配置，让我们使用以下场景：

该组织在 Exchange 2013 共存环境中拥有三个 Exchange 版本。

为了能够在 Exchange 2013 共存环境中实施自动发现基础架构的最佳实践，我们需要实施“集中式自动发现模型”。

“集中式自动发现模型”将通过以下方式执行：删除任何指向旧版 Exchange 2007/2010 CAS 的自动发现指针，并配置内部自动发现基础结构以指向“新的 Exchange 2013 CAS”。

内部自动发现基础架构的命名空间

选择“内部自动发现基础设施的命名空间”时，我们可以选择内部 Active Directory 命名空间与外部自动发现命名空间（不相交模块）相同的模型，或者相同的外部和内部自动发现命名空间的其他模型。

当前场景基于一个模块，其中内部自动发现命名空间与公共自动发现命名空间不同。

在我们的场景中，我们将使用 Exchange CAS 2013 的 FQDN（内部名称）将 Exchange CAS 2013“发布”为中央自动发现点。我们将注册的自动发现 URL 基于 Exchange CAS 2013 主机名：sts.o365info.com

在下图中，我们可以看到我们需要实现的任务的表示。我们将更新旧版 Exchange CAS 服务器的现有自动发现 URL 地址，该地址已在 Active Directory SCP 上注册以“指向”Exchange 2013 CAS。

1.查看内部自动发现信息

为了能够查看 Active Directory SCP 中显示的有关自动发现端点的当前信息，我们将使用 PowerShell 命令：

Get-ClientAccessServer | FL auto*

在下面的屏幕截图中，我们可以看到有关三个 Exchange CAS 服务器（EX01、EX02 和 STS）的信息。

在查看属性： AutoDiscoverServiceInternalUri时，我们可以看到每个 Exchange CAS 服务器都在 Active Directory SCP 上“注册了自己”。
每个 Exchange CAS 服务器“将自己声明为“自动发现端点”。

注意：从技术上讲，我们可以运行 PowerShell 命令 Get-ClientAccessServer | FL 自动*

从每个 Exchange CAS 服务器 PowerShell CLI，但根据我的经验，最佳实践是从“较新的 Exchange 版本”的 PowerShell 控制台执行此命令。
在我们的场景中：Exchange CAS 2013 服务器 PowerShell 控制台。

2.更新内部自动发现信息

“删除有关旧版 Exchange CAS 服务器基础结构的信息”的任务不是通过从 Active Directory SCP 中删除信息来实现的，而是通过运行 PowerShell Set-ClientAccessServer 来更新 Active Directory SCP 中的信息，以便自动发现 URL 地址将指向 Exchange CAS 2013 服务器 (sts.o365info.com)。

PowerShell 命令语法包含 Exchange CAS 服务器名称，因此理论上，我们可以从任何 Exchange CAS 服务器 PowerShell 控制台运行所需的 Set-ClientAccessServer PowerShell 命令。

根据我的经验，最佳实践是执行 PowerShell，这将从 Exchange CAS 服务器的 PowerShell 控制台更新特定 Exchange CAS 服务器的自动发现端点 URL。

例如：如果我们使用 Exchange CAS 2013 Server PowerShell 控制台运行 Set-ClientAccessServer 命令，该命令需要更新 Exchange 2010 CAS 服务器的自动发现 URL 地址 (EXO1)，则会出现以下错误出现：

您无法进行此更改，因为“CN=EX01、CN=服务器、CN=Exchange 管理组”。
(FYDIBOHF23SPDLT)、CN=管理组、CN=第一个组织、CN=Microsoft
Exchange、CN= Services,CN=Configuration,DC=o365info,DC=local' 对于当前版本的 Exchange 是只读的。

CategoryInfo：InvalidOperation：(:) [Set-ClientAccessServer]，CannotModifyCrossVersionObjectException

FullQualifiedErrorId：[服务器=STS，RequestId=b041d5d1-c2a3-4117-9dd3-061253859afc，时间戳=11/21/2014 2:11:03
PM] [FailureCategory=Cmdlet-CannotModifyCrossVersionObjectException] 96B3710A，Microsoft.Exchange.Management .System
ConfigurationTasks.SetClientAccessServer

PS计算机名称：sts.o365info.local

如果现有 Exchange CAS 服务器更新每个自动发现 URL 地址的“正确方法”是执行以下过程：

在 Exchange 2010 CAS 服务器 (EX01) 的 PowerShell 控制台中，我们将运行以下 PowerShell 命令：

Set-ClientAccessServer -Identity EX01 -AutoDiscoverServiceInternalUri: "https://STS.o365info.local/Autodiscover/Autodiscover.xml"

在 Exchange 2007 CAS 服务器 (EX02) 的 PowerShell 控制台中，我们将运行以下 PowerShell 命令：

Set-ClientAccessServer -Identity EX02 -AutoDiscoverServiceInternalUri:"https://STS.o365info.local/Autodiscover/Autodiscover.xml"

在下面的屏幕截图中，我们可以看到结果：有关三个 Exchange CAS 服务器的信息仍然出现在 Active Directory SCP（STS、EX01 和 EX02）中，但是当我们查看 AutoDiscoverServiceInternalUri 值时，我们可以看到 FQDN 名称已更新为 Exchange CAS 2013 服务器 FQDN：sts.o365info.com