Exchange CAS服务器作为信息+Web服务提供商|第 07 部分#36

当前文章重点介绍了 Exchange CAS 服务器的两个主要职责：
作为信息提供者（自动发现信息）的 Exchange CAS 服务器。
作为 Exchange Web 服务提供者的 Exchange CAS 服务器。

当前文章是上一篇文章的延续。在上一篇文章中，我们回顾了 Exchange CAS 服务器的职责，其描述为“提供 Exchange 客户端对其邮箱的访问”。

Exchange CAS 服务器作为信息（自动发现信息）提供者

在下面的部分中，我们将重点关注 Exchange CAS 服务器作为“信息提供者”的方面。

自动发现信息的两个主要类别

我们可以将 Exchange CAS 服务器向 Exchange 客户端提供的类型信息分为两大类：

1. Exchange邮件客户端的配置设置

Exchange CAS 服务器为三种类型的邮件客户端（Outlook、移动邮件客户端和 Web 邮件客户端）提供所需的配置设置。

Outlook 和 Mobile 邮件客户端使用该配置参数自动创建邮件配置文件。
关于 Web 邮件客户端（例如 - OWA）的主题，该 Exchange 客户端并未使用邮件配置文件进行配置，而且老实说；我不知道 OWA Web 客户端何时何地会使用自动发现信息。

2. 有关 Exchange Web 服务的信息

Exchange CAS 服务器向其自动发现客户端提供的第二种信息是可用的 Exchange Web 基础服务的列表。

该“列表”包括所提供的特定 Exchange Web 服务的描述以及特定 Web 服务的 URL 地址（该 URL 地址包括提供特定 Web 服务的 Exchange CAS 服务器的主机名）。

Exchange CAS服务器通过使用“不同格式”提供有关现有Web服务的信息。

外部邮件客户端的一种“格式”，包括提供特定 Web 服务的 Exchange CAS 服务器的公共名称。另一种类型的“URL 格式”，其中包括提供 Web 服务的 Exchange CAS 服务器的内部\私有名称（外部邮件客户端无法访问或发布内部\私有名称）。

1. Exchange 客户端创建新邮件配置文件所需的信息。

Exchange 客户端（例如 Outlook 和移动设备）需要创建邮件配置文件来连接其 Exchange 邮箱。

我们可以将“邮件配置文件”视为创建与 Exchange CAS 服务器的通信通道所需的“配置设置和用户详细信息的集合”。

理论上，所需的配置设置可以手动配置，但实际上，手动配置邮件配置文件的任务并不那么简单，因为它需要事先了解邮件配置文件所需的参数和设置，并且此任务不适合“标准用户。”

此外，如果目标服务器是 Exchange 2013，则几乎不可能创建手动邮件配置文件，因为 Outlook 邮件配置文件不是使用 Exchange CAS 服务器名称配置的，而是使用会话 ID 或 GUID ID由 Exchange CAS 服务器提供。

鉴于 Exchange 客户端提供了其电子邮件地址和用户凭据，所有其余所需的技术详细信息将提供给邮件客户端（例如 Outlook），并将用于自动创建新的邮件配置文件。

2.有关可用 Exchange Web 服务的信息。

Exchange CAS 服务器，充当 Exchange 客户端的“焦点”或“信息中心”。可以说，Outlook 等邮件客户端将 Exchange CAS 服务器称为“公告板”。

Exchange CAS 服务器拥有有关“谁在做什么”以及如何到达那里的所有信息。

如果我们想了解更多技术信息，Exchange 客户端（自动发现客户端）通过询问名为 autodiscover.xml 或 autodiscover.csv 文件的文件来提交信息请求。

Exchange CAS 服务器“应答”是指 Exchange CAS 服务器向 Exchange 客户端（例如 Outlook）提供的信息被“打包”并作为自动发现响应传递给客户端。

Autodiscover.xml 包含有关现有 Exchange 基础结构中所有可用 Exchange Web 服务的宝贵信息。

Exchange CAS 服务器提供的信息包括以下详细说明：

• 可用 Exchange Web 服务的名称。
• 每个 Web 服务的 URL 地址 - URL 地址包括提供特定 Web 服务的 Exchange CAS 服务器的名称。
• 外部和内部邮件客户端的 URL 地址类型不同 - Exchange CAS 服务器有两个“身份” - 仅向内部邮件客户端“公开”的内部身份和向外部邮件客户端公开的外部身份。
  Exchange CAS 服务器提供的信息是根据“Exchange 客户端的类型”提供的。如果 Exchange CAS 服务器识别出邮件客户端是“内部邮件客户端”，则该信息将包括带有 Exchange CAS 服务器“私有名称”的 URL 地址。

Exchange CAS服务器，负责生成所需的信息。
我们使用术语“生成”，因为信息不是静态的，而是“动态的”。这意味着 Exchange CAS 服务器需要为每个自动发现客户端请求“重新创建”信息。

Exchange CAS 服务器将信息“打包”为 XML 格式，并将数据发送到 Exchange 邮件客户端。

“Exchange Web 服务”可以由单个 Exchange CAS 服务器提供，也可以分布在许多 Exchange CAS 服务器之间。

Outlook 客户端在需要获取特定 Exchange Web 服务时，使用从 Exchange CAS 服务器获取的信息（自动发现响应）。例如 - 通过寻址提供特定 Web 服务的 Exchange 服务器来提供可用性服务（空闲\忙碌时间）、自动回复（不在办公室）、邮件提示等。

在下图中，我们可以看到 Exchange 客户端请求信息和 Exchange CAS 服务器响应“答案”的过程。

提供 Exchange Web 服务\对 Exchange Web 服务的访问。

Exchange CAS 服务器充当提供有关可用 Exchange Web 服务的自动发现信息的元素，同时通过提供 Exchange Web 服务扮演“服务提供商”的角色。

这种服务“混合”仅与 Exchange Server 2007 和 2010 版本相关。

在 Exchange 2013 体系结构中，提供 Exchange Web 服务的责任被分配给 Exchange 邮箱服务器。

Exchange 2013 CAS服务器会将Exchange客户端对Exchange Web服务的请求转发到Exchange邮箱服务器，但他本身并不是提供Exchange Web服务的“元素”。

Exchange CAS 服务器向其 Exchange 客户端提供的自动发现信息可以包含指向“自己”的 URL 地址或提供特定 Web 服务的其他或附加 Exchange CAS 服务器的 URL 地址。

Exchange Web 服务示例 | Exchange 可用性服务（空闲\忙碌时间）服务。

Exchange 可用性服务（闲\忙时间）服务是一项非常受欢迎的服务，许多 Exchange 客户端每天都会使用它。

每个标准 Outlook 用户都熟悉创建新会议、使用日程安排助手邀请其他参与者以及查看有关这些 Exchange 收件人的忙/闲时间的信息的简单任务。

乍一看，这个任务似乎很平常，也很简单。实际上，用户 A 可以看到用户 B 的忙/闲时间的“最终结果”可以被视为一项复合任务，需要 Exchange CAS 服务器执行许多步骤才能提供必要的结果。

启用这些 Exchange 服务的“机制”是 Exchange 可用性服务（闲\忙时间）服务。

为了能够演示 Exchange 可用性服务（空闲\忙碌时间）服务的“工作方式”，让我们使用以下场景。

组织有两个物理 Active Directory 和 Exchange 站点 - 纽约站点和洛杉矶站点。

Alice 是来自纽约站点的收件人，Bob 是来自洛杉矶站点的收件人。

在我们的场景中，Alice 需要邀请 Bob 参加特定日期的会议，并且 Alice 需要获取有关 Bob 在该特定日期的可用性状态的信息。

Alice 导航到她的 Outlook 日历，并使用日程安排助手将 Bob 的名字添加到会议中。

在下面的屏幕截图中，我们可以看到邀请特定组织用户参加会议时显示的忙/闲时间信息的示例。

假设一切正常，几秒钟后； Alice 可以看到 Bob 在特定日期有空。

现在让我们再看一下 Exchange 基础设施的“幕后”发生了什么。

1. Alice，向她的 Exchange CAS 服务器（位于纽约站点的 Alice Exchange CAS 服务器）发送有关“Bob 闲/忙时间”信息的请求。
2. New York Exchange CAS 服务器访问本地 Active Directory 以获取有关托管 Bob 邮箱的 Exchange 邮箱服务器的信息。
3. 当纽约交易所 CAS 服务器从 Active Directory 获取信息时，他“了解到”Bob 的邮箱位于另一个站点——洛杉矶的站点。
4. 纽约 Exchange CAS 服务器访问本地 Active Directory 以获取有关谁（以及是否）有代表洛杉矶站点的 Exchange CAS 服务器的信息。
5. 当纽约Exchange CAS服务器从Active Directory获取信息时，他尝试连接洛杉矶站点的Exchange CAS服务器。
6. 洛杉矶 Exchange CAS 服务器访问本地 Active Directory 以获取有关托管 Bob 邮箱的 Exchange 邮箱服务器的信息。
7. 洛杉矶 Exchange CAS 服务器是 Exchange 邮箱服务器，它托管 Bob 的邮箱并向他询问有关 Bob 的可用性（闲\忙时间）的信息。
8. 当洛杉矶交易所的CAS服务器获得所需信息后，他将信息“转发”到纽约交易所的CAS服务器。
9. 当纽约站点的Exchange CAS服务器获得所需信息时，他将信息“转发”到用户（Alice）邮箱。
10. Alice 在她的日历中看到有关 Bob 空闲\忙碌时间的信息。