Exchange 自动发现基础架构- 简介| Exchange第 01 部分#36

自动发现是 Microsoft Exchange 服务器架构中最重要和最重要的组件之一，但同时也是最“未知”和“被误解”的术语之一。

我的主要目标是“打开一扇门”，进入迷人且令人兴奋的 Exchange 自动发现架构。

当我决定要写一篇有关 Exchange 自动发现机制的文章时，我天真地认为我可以在 3-5 篇文章系列中涵盖这个主题。

结果是关于 Exchange 自动发现服务主题的 36 篇文章系列。
虽然这个数字听起来令人印象深刻，但我可以向您保证，此自动发现文章系列中包含自动发现基础结构的许多方面和部分。

自动发现是一个神奇的“一个词”，它的内部包含了许多不同的组件和部分。

Exchange 自动发现以这种或那种方式与几乎所有 Exchange 体系结构部分有联系。

在下面的“自动发现矩阵”图中，我尝试说明自动发现这一术语的复杂性。
矩阵中出现的所有术语、名称和基础结构都与 Exchange 自动发现服务相关，反之亦然。

文章内容

本文是对 Exchange 自动发现基础架构的“初步了解”。在本文中，我们将了解到，我们无法真正为“自动发现”这个术语提供“几句话”的解释。 ”

我们将回顾 Exchange 现代环境的主要特征，并了解 Exchange 自动发现服务如何“满足”Exchange 现代环境的需求。

如何解释自动发现——先有鸡还是先有蛋综合症

当我坐下来撰写自动发现系列文章时，我遇到的最大挑战是——先有鸡还是先有蛋综合症。

如果不深入了解 Exchange 自动发现基础架构，就无法深刻理解 Exchange 架构；如果不深入了解 Exchange 架构，就无法彻底了解 Exchange 自动发现基础架构。

在阅读自动发现文章系列时，您可能会感到轻微的困惑，因为很多时候我会从一个主题跳到与 Exchange 自动发现相关的其他主题，然后又跳回来。

我的观点是——耐心，有时信息看起来有点混乱，而且并不总是你可以轻松地将这些点连接成连贯的图片。

最终，画面会变得更加清晰！

什么是 Exchange 自动发现？

这个问题就像问一个禅宗问题，例如：一只手拍手的声音是什么？

答案永远不会是一个小问题，因为“自动发现”一词是一个包含多种含义的词。

大多数与 Exchange 自动发现主题相关的技术文章都建立在以下基本假设之上：读者熟悉自动发现的所有方面、不同的方案、自动发现体系结构等。

简单的事实是，虽然自动发现是重要的 Exchange 基础设施之一，涉及几乎所有 Exchange 基本服务，但对于我们大多数人来说，Exchange 自动发现在很多时候都是一个“黑匣子”。

我们不会转述了解或部分了解 - 什么是 Exchange 自动发现服务、自动发现的作用以及如何进行自动发现工作。

如果我们要定义 Exchange 自动发现服务的本质，我们可以说自动发现机制的主要目的是 - 提供一种简单直接的方法来获取以下信息：

1. 通信参数 - Exchange 客户端和 Exchange 服务器之间的通信通道基于预定义的参数，例如特定类型的身份验证协议、特定类型的数据加密协议、通信协议和其他参数。
2. 有关特定 Exchange 服务和提供此服务的 Exchange 主机的信息 - Exchange 基础架构是一个非常丰富的环境，为 Exchange 客户端提供多种类型的不同服务。
   Exchange 客户端的任务是 - 查找可用的 Exchange 服务以及提供此服务的 Exchange 主机是谁。

理论上，我们可以创建某种配置文件，其中包含所有必需的信息并将传递给每个 Exchange 客户端，但由于三个主要原因，实际情况要复杂得多。

1. Exchange客户端不同

不同的 Exchange 客户端需要使用不同的配置参数。各种 Exchange 客户端的差异要求和需求的示例可能有很多。例如，ActiveSync Exchange 客户端将使用与 Outlook 等 Exchange 客户端不同的通信协议和参数。

另一个示例是 Exchange 服务器版本 - 邮箱托管在 Exchange 2007 邮箱服务器上的 Outlook Exchange 用户将使用与邮箱托管在 Exchange 2013 邮箱服务器上的 Outlook Exchange 用户不同的通信参数。

2. Exchange 客户端的物理位置

Exchange 客户端（例如 Outlook）位于内部组织网络中的通信协议和参数与 Outlook 客户端位于公共网络中的情况不同。

3. 动态环境

有关现有 Exchange 基础架构的信息是一种“动态信息”，受到许多不同因素的影响，例如 Exchange Server 的可用性：可以提供特定服务的新 Exchange 服务器、已删除的不存在的 Exchange 服务器、新的 Exchange 服务等。

Exchange 自动发现体系结构的目的是：

• 客户端 - 自动执行“识别”特定 Exchange 服务器的过程
• 服务器端——基于这种Exchange客户端类型，Exchange服务器以自动的方式提供他需要的信息。 Exchange 客户端不需要有关 Exchange 基础结构的“预定义知识”，也不需要使用手动配置设置。

自动发现——信息来源

在整个系列文章中，我们将详细回顾 Exchange CAS 服务器作为信息源、信息的组成等概念。

到目前为止，我们只要提及这样一个事实就足够了：所有这些“自动化”的源头都是充当 CAS 服务器角色的 Exchange 服务器。

自动发现体系结构基于客户端“检测”或“定位”机制，其中 Exchange 客户端使用特定方法来确定将提供自动发现信息的 Exchange CAS 服务器。

自动发现不同的视角

Exchange 客户端和 Exchange 服务器端对术语“自动发现”的“解释”不同。

自动发现 - Exchange 客户端

从 Exchange 客户端的角度来看，术语“自动发现”的含义是：

1. Exchange 客户端用于定位和连接“信息源”（Exchange CAS 服务器）的方法。
2. Exchange 客户端从“信息提供者”（Exchange CAS 服务器）获取信息的过程。
3. 将信息（自动发现信息）用于不同目的，例如：创建 Outlook 邮件配置文件、定位 Exchange Web 服务等。

Exchange服务器端

从 Exchange 服务器端的角度来看，术语“自动发现”的含义是：

1. 收集和生成特定信息（自动发现信息）的能力。
2. 能够向其 Exchange 客户提供所需信息。

自动发现客户端

术语“自动发现客户端”可以翻译为多种类型的 Exchange 客户端。

例如，自动发现客户端可以是“标准 Exchange 邮件客户端”，例如 Outlook 或 Mobile (ActiveSync) 客户端。
术语的另一个“翻译 - “Exchange 客户端”也可以是另一个需要获取信息的 Exchange 服务器来自特定 Exchange 组织。

此类场景的一个示例是在 Office 365 环境中实施的混合配置，其中 Exchange Online 可以视为“自动发现客户端”，需要查找 Exchange 本地服务器资源并查询此“Exchange 本地”信息资源。

对于最“引人注目的”Exchange 邮件客户端来说，完全依赖于 Exchange 自动发现服务的是“Outlook 邮件客户端”。
还有另一种自动发现邮件客户端，例如 Mobile (ActiveSync) 客户端，但大多数信息和示例都与所描述的客户端协议连接流程将主要涉及Outlook、邮件客户端。

自动发现客户端\服务器概念

Exchange 基础结构基于客户端\服务器模块。客户端向“服务器”发出请求，请求服务器为他提供服务，例如访问他的邮箱、信息服务、Exchange Web 服务等。

在Exchange架构中，“服务器端”由Exchange CAS服务器代表。

Exchange 客户端完全依赖于担任 Exchange CAS 服务器角色的 Exchange 服务器。

自动发现基础结构内置于 Exchange 邮件客户端（例如 Outlook）中。每个 Outlook 客户端学会说的第一个词是 - 自动发现！

• Outlook Exchange 客户端使用自动发现机制来定位所需的 Exchange CAS 服务器（自动发现端点）。
• Exchange 客户端设法找到并连接其 Exchange CAS 服务器后，Exchange 客户端 (Outlook) 会发送“自动发现查询”，以获取所需的自动发现信息（有关配置设置和 Exchange Web 服务的信息）。

Exchange CAS 服务器想要做的就是 - 通过向客户提供自动发现信息来“滋养”他们。

自动发现作为 Exchange 环境中的基础结构的重要性

我们可以将 Exchange 自动发现视为托管或充当所有“其他 Exchange 部件”的基础架构的“主板”。

换句话说，如果不深刻理解Exchange自动发现基础设施，我们就无法真正理解Exchange基础设施。

问：为什么我应该如此关心 Exchange 自动发现服务？

A：这个问题有几个答案。

1：Exchange 基础设施：设计、规划和部署

我所描述的“设计、规划和部署 Exchange 基础架构”部分涉及许多可能的场景，例如：

• 从头开始构建新的 Exchange 基础设施。
• Exchange 共存环境 - 升级现有 Exchange 基础架构。我们将“新的 Exchange 服务器版本”添加到现有 Exchange 基础架构中的场景。
• 实施一个迁移项目，其中，我们需要将现有的 Exchange 本地服务器邮件基础架构迁移到“云”（Exchange Online）并将用户连接到他们的“云邮箱”。
• 实施和构建将 Exchange 本地基础设施 + 云（Exchange Online）基础设施结合在一起的 Exchange 混合环境。

所有这些不同“Exchange 场景”的共同点是，为了能够在 Exchange 环境中成功完成“设计、规划和部署”不同场景的任务，我们需要彻底了解每个场景交换组件。特别是，涉及并“触及”每个不同 Exchange 基础架构部分的 Exchange 自动发现基础架构。

2：Exchange 基础架构 - 故障排除场景

相当于一个好医生，应该了解人体，“治愈”交易所基础设施问题的方法是——了解并了解交易所不同的部分是什么，这些“交换部分”的用途是什么，如何运作“部件”是相互关联的，这些交换部件之间有什么关系等等。

自动发现基础架构的错误配置和问题可能会导致许多常见的“Exchange 故障排除场景”，例如：

2.1 经典的故障排除场景：无法创建新的 Outlook 配置文件。

最传统的故障排除场景之一是用户描述的场景：“无法连接到 Exchange”，或者换句话说 - 无法创建新的 Outlook 邮件配置文件。

“阻止用户创建所需的新 Outlook 邮件配置文件的原因是什么”的答案可能与许多因素有关，其中主要或突出的因素之一是错过配置或缺少自动发现设置。

即使我们确定问题的情况是 - 未配置自动发现配置，在我们提供问题的答案或解决方案之前，我们必须知道确切的 Exchange 基础结构是什么。每个不同的 Exchange 基础设施都有不同的章程和不同的“部分”，我们需要检查和验证。

例如，在内部网络上创建新的 Outlook 邮件配置文件的过程的实现方式与用户尝试从公共网络创建新的 Outlook 邮件配置文件的场景不同。

在混合环境中，连接到 Exchange 本地服务器邮箱的用户与邮箱托管在 Exchange Online 上的 Exchange 用户之间存在显着差异。

2.2 Exchange混合环境

在本节中，我们可以提到与 Exchange 本地基础架构和“云邮件基础架构”(Exchange Online) 之间存在的“关系”相关的多个故障排除场景。

例如，在混合环境中，Exchange 本地服务器和 Exchange Online 之间“共享”的许多服务都依赖于自动发现基础架构。
自动发现基础架构的错误配置可能会导致许多可能的问题，首先是可用性服务（看不到忙/闲时间）、移动邮箱（无法将邮箱迁移到 Exchange Online）等等。

在下图中，我们可以看到可能与自动发现基础架构相关的“Exchange 故障排除场景”的简单分类。

3：纯粹的好奇心 |自动发现为黑匣子

我们生活在快餐时代。
每个人都希望现在就快点！

这是我整天“讲授”的好处。
我认识许多 Exchange 管理员和 Exchange 工具，他们做他们所做的事情，但并没有真正理解他们在做什么。

大多数时候，普遍的观点是 - “当我们到达那里时，我们会跨过那座桥。”
例如，在出现问题或错误的情况下，我会“谷歌它”并可能找到解决方案。

我的世界观表明，如果不深入了解 Exchange 架构的内部和大门，就不可能成为“Exchange 专业人士”。

是的，“好奇心”这个词并不是一个肮脏的词！

大多数时候，我们生活在非常平坦的信息水平上。
公式如下：我有一个问题==>我需要一个解决方案==>我寻找一个解决方案==>我找到了解决方案==>我实现了解决方案==>问题解决了=大家高兴！

然而，99% 的时候，我们不愿意花时间去了解特定基础设施（例如在我们的例子中的 Exchange 和自动发现基础设施）的“内部”和“幕后”。