交换基础设施|实现单域命名空间方案 |第 2 部分#2 |第 18 部分#36

当前的文章是我们回顾 Exchange 基础结构的概念和单个命名空间的使用的第二篇文章。

在上一篇文章中，我们回顾了建议使用 Exchange 单一命名空间的概念和原因。本文重点讨论我们希望将现有 Exchange 基础结构转换为 Exchange 单一命名空间的场景。

术语的含义——统一域名空间

在本文中，我们将多次提到术语——统一域命名空间。从技术上讲，没有这样的正式术语。

我用这个术语来描述一种环境或场景，其中 Exchange 服务器的内部标识和 Exchange 服务器的公共标识基于相同的命名空间（即公共命名空间）。

在上一篇文章（我应该为 Exchange 基础结构使用单个命名空间吗？ | 第 1#2 部分 | 第 17#36 部分）中，我们回顾了在 Active Directory 域名私有的情况下实施的默认 Exchange 基础结构。

无效的完全合格域名 - 主要原因

我还提到了我对“为 Active Directory 使用私有域名”这一概念持保留态度，但该基础设施在许多组织中都很流行或常见。

无论我对 Exchange 内部基础结构使用 Active Directory 私有域名的看法如何，这里都有一个更改此类配置的坚定论据 - 无效的完全限定域名。

术语“无效的完全限定域名”涉及新的证书标准，其中公共 SAN 证书将不支持使用“单一主机名”和使用私有域名后缀（例如 - local）的主机名 (FQDN)

自 2015 年 11 月 1 日起，将不再支持此类配置。

注意 - 您可以在文章 - 自动发现过程和 Exchange 安全基础结构 | 中阅读有关无效完全限定域名主题的其他信息。第 20 部分#36

使用“Exchange 基础设施的统一域名空间”选项还有其他原因，例如更直观、更方便的故障排除过程、简化的管理等等。

在现代 Exchange 环境中，我们可以说不可避免地需要为 Exchange 基础结构使用单个域命名空间。

假设您确信，并且您希望将基于两个不同域名空间概念的现有 Exchange 基础架构转变为 Exchange 基础架构的统一域名方案的基础架构。

主要问题是：

问：可以吗？是否有选项可以将我现有的 Exchange 域名基础结构“转换”为统一的域命名空间？

A：答案是：“是”

其他重要问题是：

第一季度。整个过程涉及哪些步骤？

第二季度。此“更改”是否会影响 Exchange 服务的可用性？

第三季度。如果我会仔细阅读这篇文章，我是否能够在不需要外部帮助的情况下完成它？

这个问题的答案是：

A1。在下面的文章中，我们将回顾将现有 Exchange 基础架构转换为“统一域命名空间”过程中涉及的每个“步骤”、基础架构和组件。 ”

A2。现在，假设您制定了所需的“规划流程”并实施了所有必需的必要配置，那么您的 Exchange 客户端将不会出现“停机时间”。

A3。答案是“是”。如果能够从有经验、有“实践经验”的人那里得到帮助或建议总是好的。然而，如果您是一位经验丰富的 Active Directory 和 Exchange 管理员，那么“迁移”就相当简单了。

将现有的 Exchange 基础设施转换为 - “统一的域命名空间” |任务清单

在迁移过程中，“基于统一域命名空间的Exchange基础架构”最关键的阶段是规划过程，在这个过程中我们需要考虑将涉及的所有组件和任务。

我们可以定义三个主要元素，它们涉及将现有 Exchange 基础设施转换为“统一域命名空间”的整个迁移过程。

1.内部DNS服务器

在 Active Directory 基于私有域名的场景中，我们需要将附加域名（公共域名）添加到将“托管”公共域名的本地 DNS 服务器。

请注意，与本地\内部 Active Directory、DNS 服务器并行，公共域名也将托管在公共 DNS 服务器上。

在这种情况下，同一域名空间由两个不同且独立的 DNS 服务器管理，名为 - 拆分 DNS。

（我们将在下一节中回顾拆分 DNS 的主题）。

2. Active Directory SCP

我们需要更新在 Active Directory SCP 中注册的信息并“替换”现有的 Exchange CAS 服务器名称。

默认情况下，当前的每个 Exchange CAS 服务器将使用其私有含义（FQDN）自动在 Active Directory SCP 上注册自己，其中包括 Active Directory 私有域名后缀。

3. Exchange CAS服务器

Exchange CAS 服务器的一部分包括 Exchange CAS 服务器 Web 服务的 URL 地址。此 URL 地址包括 Exchange CAS 服务器的私有主机名。

当我们实现“内部+外部Exchange基础设施统一域名空间”的方法时，我们还需要更新所有Exchange CAS服务器URL地址，以便“新URL地址”将包括Exchange的“新公共名称” CAS 服务器。

在下图中，我们可以看到一个摘要，其中指出了元素以及我们需要使用“新 Exchange 服务器主机名”和 Exchange Web 服务 URL 地址进行更新的基础结构。

实施“统一域名空间”交换基础设施|任务列表

在下一节中，我们将描述“在 Exchange 基础架构中实施“统一域命名空间”过程中涉及的每个“主要步骤”。

整个过程涉及的主要组件是：

1.拆分 DNS

当我们对内部和外部 Exchange FQDN 名称使用统一的域命名空间时，在 Active Directory 域名是私有域名的情况下，我们需要向本地 DNS 添加额外区域来“托管”公共域名。

内部 DNS 服务器将被配置为公共域名的“权威”。

在这种情况下，我们需要手动添加与 Exchange 基础结构相关的所有 DNS 记录，例如：

Exchange 服务器主机名的 A 记录、自动发现记录、MX 记录等。

2.活动目录 SCP

我们需要从 Active Directory SCP 中删除包含使用 Active Directory 私有域名的 Exchange FQDN 的主机名，并添加使用公共域名后缀存在的 Exchange CAS 服务器的信息。

3. Exchange CAS 服务器配置

我们需要将所有包含使用私有域名的 Exchange 主机名的 Exchange Web 服务 URL 地址更新为使用公共域名后缀的“新 Exchange FQDN”。

第 1 步：实施拆分 DNS 基础设施

拆分 DNS 的实施使我们能够绕过 Exchange 服务器主机名 (FQDN) 默认基于 Active Directory 域命名方案的障碍。

如果 Active Directory 是私有域名空间，我们希望将 Exchange 基础架构命名空间与 Active Directory 私有域名“断开”或“分离”，并将 Exchange 域名空间与公共域名“关联”。域名。

问：这个魔法是如何发生的？
答：使用拆分 DNS 选项

下一个问题可能是：

问：Split DNS 的含义是什么？如果 Split DNS 对我有好处，我应该实施此配置吗？

DNS 作为分布式数据库和单一权威来源的基本概念

DNS世界是一个非常有趣和复杂的世界，它可以在无限数量的DNS服务器之间共享数据。

尽管事实上，许多 DNS 服务器可以在逻辑上共享任何信息，例如有关特定域名的信息（区域传输等），但只有“一个权威来源”。

其含义是，只有一台 DNS 服务器可以认为其所掌握的信息是“权威的”。

这个“权威来源”（主 DNS）可以将信息复制到其他 DNS 服务器，但基本作用是所有保存区域文件（域名）副本的 DNS 服务器上的信息应该相同。从主 DNS（权威来源）接受。

在下图中，我们可以看到主 DNS 服务器正在将特定域名（被视为“在其权限下”的域名）的信息复制到附加 DNS 服务器。

DNS 客户端可以访问或查询每个 DNS 服务器，并且 DNS 客户端在每个 DNS 服务器中得到的“答案”应该是相同的。

- 分割 DNS 是什么意思？

“拆分 DNS”这个术语的简单解释是——一种配置，其中两个不同且独立的 DNS 服务器同时充当同一命名空间（域名）的“权威来源”。

注意：此配置的其他流行术语包括 - 水平分割 DNS 和裂脑 DNS

当使用分割 DNS 的配置时，我们“违反”了 DNS 基础设施的最基本概念之一，因为我们创建了一个场景，其中两个不同的 DNS 服务器“认为”它们是特定域名的唯一所有者，同时，实际上，有两个 DNS 基础设施 - 内部 Active Directory DNS 基础设施和外部公共 DNS 基础设施，它们定义为同一域名的权威。

每个 DNS 基础设施都“确信”自己是“唯一的”，并且每个 DNS 基础设施都不知道其他 DNS 基础设施的存在。

问：为什么我们需要使用分割DNS选项？

A：答案是 - 当我们使用拆分 DNS 配置时，我们能够根据不同的客户端的物理位置提供不同的答案。

面向公众的 Exchange CAS 服务器 - 一个名称和两个不同的 IP 地址

在我们将现有的 Exchange 域方案从“双域名基础设施”转换为“单一统一域名”的场景中，主要目标是使内部 + 外部 Exchange 客户端能够使用相同的 FQDN（相同的 FQDN）。使用公共域名后缀的主机名）。

然而，与此同时，我们不应忘记，尽管“单一统一域名”的概念与域名相关，而不是与 Exchange CAS 服务器的 IP 地址相关。

在下图中，我们可以看到一个场景示例，其中 Exchange 本地服务器有两组 IP 地址。

在我们的场景中，Exchange 服务器将由主机名表示 - mail.o365info.com

该主机名将使用不同的 IP 地址在内部和外部 DNS 服务器中“发布”。

• 内部 Exchange 客户端将尝试访问主机名 - o365info.com，并将尝试使用私有 IP 地址 - 192.168 与 Exchange CAS 服务器进行通信。 1.5
• 外部 Exchange 客户端将尝试访问主机名 - o365info.com，将尝试使用私有 IP 地址 - 212.25 与 Exchange CAS 服务器进行通信。 80.239

注意：实际上，我们并未将公共 IP 地址物理分配给 Exchange 本地服务器，而是使用具有特定公共 IP 地址范围的防火墙。

需要访问面向公众的 Exchange CAS 服务器的外部邮件客户端的每次连接尝试都将使用专用 IP 地址自动“转发”到 Exchange CAS 服务器（这是 NAT 配置的实现）。

使用两台DNS服务器实现拆分DNS配置

在我们的示例中，“绿色 DNS 服务器”（图中的服务器 A）是 Active Directory 内部 DNS 服务器，仅可供位于公司专用网络上的主机访问或使用，并且“紫色 DNS 服务器”将仅对外部客户端可用。

这些 DNS 服务器中的每一个都拥有或被视为域名的“SOA - 权威来源” - o365info.com

每个 DNS 服务器都会发布有关特定主机 IP 地址的“不同信息”。

在下图中，我们可以看到拆分 DNS 概念的示例。

我们可以看到有两个 DNS 服务器，它们“声称是信息源”。 ”

另外，我们可以看到每个DNS数据库（区域文件）中的信息都是不同的。

DNS 服务器“声称”名为 mail.o365info.com 的主机的 IP 地址是 - 192.198.1.5

DNS 服务器 B “声称”名为 mail.o365info.com 的主机的 IP 地址是 - 212.25.80.239

在下图中，我们可以看到拆分 DNS 的概念，但这一次是从 DNS 客户端的角度来看的。

当内部 DNS 客户端向 DNS 服务器查询名为 mail.o365info.com 的主机时，DNS 服务器回复将包含私有 IP 地址主机的。

当外部 DNS 客户端向 DNS 服务器查询名为 mail.o365info.com 的主机时，DNS 服务器回复将包含该主机的公共 IP 地址主人。

面向公众的 Exchange CAS 服务器公共 IP 地址和防火墙基础设施

如前所述，大多数时候，外部邮件客户端和面向公众的 Exchange CAS 服务器之间没有“直接”通信。

相反，面向公众的 Exchange CAS 服务器通过使用防火墙服务器“发布”或“呈现”给外部客户端。

防火墙“冒充”自己并显示为“面向公众的 Exchange CAS 服务器”。
当外部客户端尝试使用 IP 地址 - 212.25.80.239 与面向公众的 Exchange CAS 服务器进行通信时，通信请求将被被防火墙“拦截”，并使用 Exchange 服务器的私有 IP 自动转发到 Exchange CAS 服务器。

所有这些“过程”对于外部邮件客户端来说都是“透明的”。

管理拆分 DNS 配置

通过使用至少两个独立的 DNS 服务器来实现分割 DNS 基础设施。内部 Active Directory、DNS 基础设施和公共 DNS 基础设施。

如果 Active Directory 使用私有域名，我们需要向内部 DNS 服务器添加具有公共域名的附加域（技术术语为“区域”）。
在我们的场景中，Active Directory私有域名为 - o365info.local ，公司公共域名为 - o365info.com

在图中，我们可以看到以下信息：

1. 该组织使用两个不同的 DNS 服务器 - 供内部“Active Directory 用户”使用的内部 DNS 服务器和将由外部客户端使用的附加“公共 DNS 服务器”。
2. 内部 DNS 服务器对两个不同的域具有权威性 - o365info.local + o365info.com
3. 为 Exchange CAS 服务器选择的“公共主机名”是 - 邮件。
   该主机名将被配置两次 - 在内部 DNS 服务器中 +在外部 DNS 服务器中。

请注意，Exchange CAS 服务器的“真实主机名”（NetBIOS 名称）是 - ex01

从技术上讲，此名称将自动在私有 Active Directory 域名 (o365info.local) 中注册，但在我们的场景中，我们不希望启用“默认”基于 Active Directory 专用名称后缀的 Exchange 服务器名称。

内部和外部邮件客户端将使用的主机名是 - mail

Exchange CAS 服务器的 FQDN 将为 - mail.o365info.com

管理内部 Active Directory DNS 服务器

在下面的屏幕截图中，我们可以看到包含两个不同域名的内部 DNS 示例。

1. o365info.local DNS区域

Active Directory 域名是 - o365info.local 我们会自动管理。

默认情况下，DNS 区域配置为支持未来的 DDNS（动态 DNS）。域中的每个内部主机都“知道”如何在 Active Directory 域名下的 DNS 中注册自己。

2.o365info.com DNS区域

代表公共域名的附加域名（在我们的场景中 o365info.com）将被手动管理，因为 Active Directory 主机（加入域的主机）不“属于”或与该域名相关联。

我们需要手动添加需要在公共域名下“发布”的每个主机名，并另外添加其私有 IP 地址。

在下面的屏幕截图中，我们可以看到在公共域名下，我们添加了主机名 - mail，它代表 Exchange CAS 服务器及其私有 IP 地址。

关于自动发现记录，从技术上讲，我们不需要添加此记录，因为配置为加入域的内部主机不会使用 DNS 服务来定位 Exchange CAS 服务器的名称。相反，将访问 Active Directory 以获取 Exchange CAS 服务器的名称（在我们的场景中，Active Directory 将提供的名称是 mail.o365info.com）

仅对于未加入域的内部主机，才需要添加自动发现记录。

如果我们不使用分割 DNS 配置会发生什么？

我们怀疑的头脑中可能会出现一个有趣的问题：“如果我们不使用拆分 DNS 配置，会发生什么？ ”

答案是，在某些情况下，一切都会正常工作，而无需实施拆分 DNS 配置（需要向内部 DNS 服务器添加其他区域、向公共名称 DNS 区域添加 A 记录等）的所有“头痛”。

实现拆分 DNS 配置的原因是为了防止内部客户端使用“内部主机”（我们场景中的 Exchange CAS 服务器）的公共 IP 地址。
相反，我们希望内部客户端使用“内部主机”的公共 IP 地址。 Exchange 客户端将通过使用其私有 IP 地址来连接 Exchange CAS 服务器。

如果内部 Exchange 客户端将使用其公共 IP 地址来寻址 Exchange CAS 服务器，则通信通道可以配置为“扭曲”。

内部主机和外部主机之间的通信通道

内部主机和外部主机之间的“正常”通信通道通过以下方式实现：
当内部客户端需要访问“外部主机”（具有公共IP地址的主机）时，内部主机将需要借助防火墙或代理服务器等“网关”，它将“将其请求转发”到目标外部主机，反之亦然。

当外部主机回复时，网关会将响应转发给内部主机。

当我们确实需要访问外部主机时，所描述的通信通道是“可接受的”，但在我们的场景中，Exchange CAS 服务器不是外部主机。

内部主机和外部主机之间没有推荐的通信通道

如果我们不使用拆分 DNS 的配置，则每个 DNS 都会查询“属于”公有域名的主机（例如 DNS 查询主机名 - mail.o365info .com），将被“重定向”到权威机构的公有域名。

默认情况下，权威机构是托管域名的外部 DNS 服务器 - o365info.com

在这种情况下，我们使用公共 DNS 作为公共域名的权威机构，将导致“事件”，其中内部 Exchange 客户端将尝试使用公共 IP 地址而不是使用他的 Exchange CAS 服务器来寻址它们“标准”私有IP地址。

这种情况的结果是通信通道将以非最佳方式实现，这可能导致性能下降甚至逻辑错误和其他问题，从而阻止内部邮件客户端与其内部 Exchange CAS 服务器之间的通信。

为了演示在我们不使用拆分 DNS 配置的情况下会发生什么，让我们使用以下示例：

内部邮件客户端需要访问其 Exchange CAS 服务器。
邮件客户端使用 Exchange CAS 服务器的名称连接本地 Active Directory 和 Active Directory 重播 - mail.o365info.com

1. 内部客户端连接本地 DNS 查找主机的 IP 地址 - mail.o365info.com
2. 本地 DNS 服务器将连接外部根 DNS 服务器，以获取该域的“托管”（权威）DNS 服务器的名称和 IP 地址 - o365info.com
3. 内部 DNS 向内部客户端提供主机的公共 IP 地址 - 212.25.80.239
4. 内部客户端“理解”该IP不是本地的，因此连接hos网关。
5. 网关将请求“反弹”到他的“外部分支”，因为他负责这个公共 IP（在我们的场景中 - 212.25.80.239）。
6. 网关使用主机的私有 IP 地址（在我们的场景中为192.168.1.5）来寻址内部主机。

1. 内部主机（Exchange CAS 服务器）“应答”进行连接尝试的“主机”。请注意，从内部 Exchange CAS 服务器的角度来看，尝试联系他的主机是防火墙服务器的“内腿”。
2. 防火墙接受“Exchange CAS 服务器响应”并将“答案”转发到内部邮件客户端。

听起来很奇怪而且有点扭曲？

是的，这就是重点。如果我们不使用拆分 DNS 选项并为我们的 Exchange 基础设施使用公共域名方案，这就是通信工作流程的实现方式。

这种“工作流程”的后果可能是：防火墙服务器上不必要的负载、由于通信路径相当复杂而降低网络性能、防火墙服务器不可用时出现单点故障等等。

步骤 2：交换公共域命名方案和 Active Directory

- Exchange 公共域命名方案方案中的另一个元素是 Active Directory 的组件以及在 Active Directory SCP（服务连接点）中注册的 Exchange CAS 服务器信息。

在 Active Directory 使用私有域名的情况下，每个 Exchange CAS 服务器都会使用包含 Active Directory 私有域名的主机名自动在 Active Directory SCP（服务连接点）上注册自己。

在“Exchange 基础设施单一命名方案”的场景中，我们需要“删除”在 Active Directory SCP 上注册的现有信息，并更新信息，使其“指向”“新的 Exchange CAS”基于公共域名后缀的服务器名称。

为了演示这个概念，让我们使用以下示例：

• Active Directory 使用名为 - o365info.lcoal 的私有域
• 公司的公众名称是 - o365info.com
• 本地 Exchange CAS 服务器的主机名是 - exo1，并且 Exchange CAS 服务器的“全名”（FQDN）是 - mail.o365info.local
• 我们要使用公共域名分配给本地 Exchange CAS 服务器的名称是 - mail.o365info.com
• 请注意，默认情况下，Exchange CAS 服务器已使用主机名在 Active Directory SCP 上注册 - ex01.o365info.local

在我们的场景中，我们希望每次邮件客户端（自动发现客户端）向 Active Directory 查询可用自动发现端点（Exchange CAS 服务器）的名称时，Active Directory 将提供的答案是Exchange CAS 服务器的“公共名称”。

为了能够满足此要求，我们需要将在 Active Directory SCP 上自动注册的现有值更新为 Exchange CAS 服务器的“新名称”。

在我们的示例中，我们需要使用 PowerShell 命令将在 Active Directory SCP 中注册的 Exchange CAS 服务器名称更新为“新名称”，例如：
Set-ClientAccessServer -Identity “EX01” -AutodiscoverServiceInternalURI “ https://mail.o365info.com/Autodiscover/Autodiscover.xml”

步骤 3：更新 Exchange CAS 服务器 Web 服务 URL 地址。

Exchange CAS 服务器通过使用 URL 地址“告诉”客户端可用的 Web 服务。

我们可以将 Exchange CAS 服务器提供的 URL 地址作为指向所需 Exchange Web 服务的“指针”。

如前所述，Exchange CAS 服务器对内部 Exchange 客户端和外部 Exchange 客户端使用两个单独的接口。

每个 Exchange CAS 服务器 Web 服务都是使用内部 URL 地址和外部 URL 地址发布的。

内部 URL 地址应由内部 Exchange 客户端使用，外部 URL 地址应由外部 Exchange 客户端使用。

在我们的场景中，仅使用一个域名（公共域名），我们需要更新每个 Exchange Web 服务的 URL 地址，以便默认使用私有域名配置的内部 URL 地址将被更新。将被更新并将设置为与基于公共域名后缀的外部 URL 地址相同。

我们需要更新其 URL 地址的 Exchange Web 服务是：

• 交换网络服务 (EWS)
• 动态同步
• 奥瓦
• ECP
• OAB

使用 Exchange 图形管理界面更新 Exchange CAS 服务器 URL 地址。

大多数 Exchange Web 服务都可以使用 Exchange 图形管理界面进行更新。

在Exchange 2010服务器版本中，我们可以使用图形管理界面来更新除Exchange Web服务（EWS）之外的所有Exchange Web服务URL。

如果您使用 Exchange 2013，我们可以使用 Web 管理界面来更新所有 Exchange Web 服务，包括 Exchange Web 服务 (EWS)。

在下面的屏幕截图中，我们可以看到使用 Exchange 2010 图形管理界面时可用的选项示例。

在服务器配置、客户端访问下，我们可以看到每个 Exchange Web 服务的“选项卡” 。

例如，让我们看一下 Exchange OWA Web 服务的设置。

在下面的屏幕截图中，我们可以看到 OWA 内部 URL 默认情况下使用 Exchange CAS 服务器内部名称进行配置。

在我们的场景中，Exchange 内部主机名是 - o365info.local

在“单一统一域名方案”的场景中，我们希望实现一种配置，其中Exchange CAS服务器域名基于公共域名后缀，并且内部和外部URL相同。

在下面的截图中，我们可以看到“更新后的URL地址”。内部 URL 地址已更新为以下 URL 地址 - mail.o365info.com

使用 Exchange PowerShell 界面更新 Exchange CAS 服务器 Web 服务 URL 地址

更新 Exchange CAS 服务器 Web 服务 URL 地址的另一个选项是使用 PowerShell 界面。

在下一节中，您可以看到可用于更新 Exchange 内部 URL 地址的 PowerShell 命令示例。

如果您想了解有关可用于通过 Exchange PowerShell 界面管理 CAS 服务器 Web 服务 URL 地址的可用 PowerShell 命令的更多详细信息，您可以阅读文章- Exchange Web 服务 | CAS 服务器 Web 服务 URL 地址。管理内部和外部 URL 地址 |第 10 部分#36

设置\更新 - Exchange Web 服务 (EWS) 的 URL 地址

在以下示例中，我们将使用“新”Exchange CAS 服务器主机名 - mail.o365info.com 更新 Exchange EWS 服务的内部和外部 URL 地址

PowerShell 命令：

Set-WebServicesVirtualDirectory -Identity "CAS01\EWS (Default Web Site)"
-InternalUrl "https://mail.o365info.com/ews/exchange.asmx"
-ExternalUrl "https://mail.o365info.com/ews/exchange.asmx"

设置\更新 - ActiveSync Exchange Web 服务的 URL 地址

在以下示例中，我们将使用“新”Exchange CAS 服务器主机名 -mail.o365info.com 更新 Exchange ActiveSync 服务的内部和外部 URL 地址

Set-ActiveSyncVirtualDirectory -Identity "EX01\Microsoft-Server-ActiveSync"
-InternalUrl "mail.o365info.com/Microsoft-Server-ActiveSync"
-ExternalUrl "mail.o365info.com/Microsoft-Server-ActiveSync"

设置\更新 - OWA Exchange Web 服务的 URL 地址

在以下示例中，我们将使用“新”Exchange CAS 服务器主机名 - mail.o365info.com 更新 Exchange OWA（网络邮件服务）的内部和外部 URL 地址

Set-OwaVirtualDirectory -Identity "ex01\owa (default Web site)"
-InternalUrl "https:// mail.o365info.com/owa"
-ExternalUrl "https://mail.o365info.com/owa"

设置\更新 - Exchange ECP 的 URL 地址

在以下示例中，我们将使用“新”Exchange CAS 服务器主机名 - mail.o365info.com更新 Exchange ECP（Exchange 控制面板）的内部和外部 URL 地址>

Set-EcpVirtualDirectory -Identity "ex01\ECP (Default Web Site)"
-InternalUrl "https://mail.o365info.com/ecp"
-ExternalUrl "https://mail.o365info.com/ecp"

交换OAB（离线通讯录）

在以下示例中，我们将使用“新”Exchange CAS 服务器主机名 - mail.o365info.com更新 Exchange OAB（脱机通讯簿）的内部和外部 URL 地址>

Set-OABVirtualDirectory -identity "ex01\OAB (Default Web Site)"
-InternalUrl "https://ex01.o365info.local/oab"
-ExternalUrl "https://mail.o365info.com/oab"

Exchange 私有域名与公共域名的优缺点

正如您已经理解的那样，我的观点是，首选方法或最有效或更可取的方法是 - 使用单个命名空间，这意味着分配给 Exchange 基础设施的公共域名方案，而不是维护两个单独的名称方案（私有和民众）。

如果到目前为止您还不太确信，这里是对每个选项的优缺点的快速回顾。

在我们研究这些优点和缺点之前，我想总结一下我的口头禅。当我们“投资”所需的资源来规划和创建必要的拆分 DNS 基础设施后，我们的生活应该非常轻松和直接。尽管如此，我还是花了很多“言语”来解释拆分 DNS 基础设施，我们需要分配的“资源”非常简单明了。

使用 Exchange 基础结构的公共域命名方案

优点

1. 简化用户与邮件服务的交互

当对 Exchange 基础结构使用公共域名方案时，Exchange 客户端将不再需要记住两个单独的主机名来从内部网络寻址 Exchange 服务器与从外部\公共网络寻址 Exchange。

2. 简化证书主机名管理。

如果我们仅使用一种命名方案（公共名称方案），我们将不再需要使用外部 + 内部主机名“填充”Exchange 公共证书。

3. 简化自动发现和其他 Exchange 相关问题的故障排除过程。

如果我们需要处理与自动发现和其他 Exchange Web 服务相关的故障排除方案，则仅使用一种命名方案（公共域名方案）时解决问题会容易得多。

4. 预防 - 当新标准“无效的完全合格域名”将被强制执行\实施时，Exchange 基础设施未来会出现困难

我们已经审查了公共证书中无效的完全合格域名的主题，看起来，除了接受仅使用公共命名方案并“摆脱”分配的方案之外，别无选择Exchange 基础结构的专用 Active Directory 命名方案。

缺点

1. 构建拆分 DNS 基础设施所需的资源

理论上，我们需要分配资源来构建“拆分 DNS 基础设施”，该基础设施将作为仅向 Exchange 基础设施分配公共名称方案的基础。

事实上，我们需要分配的唯一真正资源是我们需要花在阅读“如何构建拆分 DNS 基础设施”上的时间。 ”

分割 DNS 基础设施的实施不需要任何专用服务器或硬件资源。
我们需要做的只是将额外的区域（域名）添加到来自每个 DC 的一部分的 DNS 服务器上的构建中（活动目录服务器）。

2.需要在Active Directory SCP中重新注册Exchange CAS服务器名称

在 Active Directory SCP 中重新注册 Exchange CAS 服务器名称的需求可以通过使用 PowerShell 命令非常轻松地实现，并且基本假设是这是“一次性操作”，因为我们需要运行“重新注册过程”仅当新的 Exchange CAS 服务器添加时才会进行。