初始化配置
安装后的检查
在安装Exchange服务器并重新启动后，如何知道安装是否成功？首先，如果在控制台上没有收到任何错误消息，则安装本身运行良好。接下来，检查所有Exchange服务是否成功启动，检查 Exchange 组件的状态，检查管理控制台是否能成功打开。
Virtual Directories
Exchange服务器的安装已经成功完成，可以开始配置Exchange服务器了。要使Exchange服务器完全投入使用，必须配置以下项目。
• Virtual directories(虚拟目录)
• SSL certificate(SSL 证书)
• Send connector(发送连接器)
• Accepted domains(接受域)
• Email address policies(电子邮件地址策略)
• Mailbox database location(邮箱数据库位置)
• SMTP Queue database location(SMTP 队列数据库位置)
• IIS log file location (IIS 日志文件位置)
• Exchange server 2019 product key(Exchange server 2019 产品密钥)
在部署 Exchange 2019 时，服务器上的所有内部虚拟目录都配置了它们的本地FQDN，后跟虚拟目录的短名称，即 https://sh-ex01.contoso.local/owa，服务器上的外部虚拟目录始终为空。
如果只有一个 Exchange 服务器，则可以配置外部虚拟目录使用相同的 FQDN。如果有多台 Exchange 服务器，则使用每个服务器的单个 FQDN 具有挑战性，可以使用更通用的 FQDN，例如 webmail.proexchangeadmin.com
Microsoft 建议为所有虚拟目录使用相同的外部URL 和内部 URL，这意味着 webmail.proexchangeadmin.com 指向在Internet上的公共IP地址，同时webmail.proexchangeadmin.com 指向内部网络上的私有IP地址。这被称为“分裂DNS(split DNS)”配置。
在 Exchange 2019 中，需要配置以下目录
• OWA virtual directory
• ECP virtual directory
• EWS (web services) virtual directory
• ActiveSync virtual directory
• OAB (offline address book) virtual directory
• PowerShell virtual directory
• MapiHttp virtual directory
下图列出了 Exchange 2019 中的所有虚拟目录的 InternalURL 和 ExternalURL 属性的值，对于我们proexchangeadmin的安装，内部 URL 和外部 URL 属性使用相同的 URL
上图中没有提及 Autodiscover 虚拟目录。这是正确的，因为不需要设置此虚拟目录的内部 URL 和外部 URL 属性。自动发现功能将在后面进行更详细的讨论，我们使用 PowerShell 命令来更改这些虚拟目录设置。
要配置 Exchange 2019 服务器的所有虚拟目录，您可以使用以下命令
MapiHttp 是 Exchange 2013 SP 1 中引入的 Outlook 客户端协议。对于 Outlook，您需要使用完全修补的 Outlook 2010 或更高版本的客户端。在组织级别上启用MapiHttp，因此它对整个环境启用或禁用。要为 Exchange server 2019 启用MapiHttp，请执行以下 PowerShell 命令：
如果您仍在运行像 Outlook 2007 这样的过时且不受支持的客户端，则必须通过在EMS 中输入以下命令来启用 Outlook Anywhere：
虽然不是真正的虚拟目录，但 Autodiscover 的服务连接点(SCP)也必须在此时进行配置。SCP 只能使用 PowerShell 进行配置；没有可用的 GUI。要配置 SCP，请在 EMS 中执行以下命令：
Configure an SSL Certificate
默认情况下，在安装过程中，每个 Exchange 服务器都会安装一个自签名证书，无论其版本如何。该自签名证书的通用名称为服务器的 NetBIOS 名称，而服务器的全限定域名(FQDN)则配置在证书的“使用者可选名称”字段中。
自签名证书在测试 OWA 和 EAC 时工作正常，但决不能用于生产目的。请求有效的SSL 证书是唯一的选择。
使用 EMS 申请 SSL 证书
在这个例子中，只使用了两个域名：Webmail.proexchangeadmin.com， Autodiscover.proexchangeadmin.com
使用 SSLCertRequest.req 文件的内容从证书颁发机构 (CA) 请求 SSL 证书
在从证书颁发机构订购证书后，您将新证书存储在同目录中，并继续执行以下命令：导入交换证书，将从 CA 返回的 SSL 证书导入 Exchange 2019 服务器的本地证书存储区并为证书分配服务。
导出现有 SSL 证书
导入现有 SSL 证书
最终3台服务器都成功安装了证书。
Create a Send Connector
默认情况下，Exchange服务器可以在其接收连接器上接收消息，但不能向外部世界发送消息，因为没有创建默认的发送连接器。在创建新的发送连接器时，它需要一个名称、一个地址空间和一个源传输服务器，即哪个服务器可以使用此连接器向外部世界发送电子邮件。
Receive Connectors
除了发送连接器，Exchange服务器2019还有接收连接器。有来自其他SMTP主机的消息的默认接收连接器，还有客户端接收连接器，以便已验证的客户机可以发送SMTP消息。
Client Frontend SH-EX01
在端口 587 上监听，此连接器用于 Mozilla Thunderbird 等客户端，这些客户端希望使用经过身份验证的 SMTP 发送电子邮件。此端口需要用户进行身份验证才能使用服务。
Client Proxy SH-EX01
在端口 465 上监听，此连接器从 Exchange 服务器 2019服务器或同一 Active Directory 站点中的任何其他 Exchange 服务器 201 9 服务器上的客户端访问服务接收客户端消息。
Default SH-EX01
在端口 2525 上监听，这是 SMTP 服务，从预设前端接收连接器在Exchange server 2019 服务器或同一 Active Directory 站点中的任何其他 Exchange server 2019 服务器上接收讯息。此连接器不适用于常规客户端使用。
Default Frontend SH-EX01
在端口 25 上监听，这是用于接收常规入站 SMTP 消息的连接器。连接到此端口的服务器可以是其他 SMTP 服务器、Exchange 2010 Hub Transport 服务、组织中的其他 Exchange 2013/ 2016/20 19 服务器，或者需要向邮箱提交消息的应用程序或设备。
Outbound Proxy Frontend SH-EX01
此连接器接受来自Exchange服务器上的传输服务的消息，并将消息中继到外部主机。只有启用前端代理选项的发送连接器才会发生这种情况。
在安装 Exchange server 2019 时，无需在接收连接器上配置任何内容就 可以正常工作了。您只需配置防火墙将 SMTP 转发到 Exchange server 2019 服务器的TCP/25，就可以准备就绪了。
Accepted Domains
Exchange服务器中接受的域是用于电子邮件服务的域，此特定Exchange环境将为此接受消息，有三种类型的接受域。
Authoritative domain
权威域-这是 Exchange 环境最终负责的域，在链接电子邮件环境时，这将是最终目的地。没有其他邮件环境负责此域。如果此环境中不存在收件人，则生成非送达报告(NDR)并返回给原始发送方
Internal relay
内部中继器-这是Exchange环境可能部分负责的领域，但它不是唯一接收此域邮件的环境。如果此环境中不存在收件人，则电子邮件将使用包含此域作为地址空间的发送连接器转发到此环境。
External relay
外部中继器-这是Exchange环境将接受邮件的领域，但它没有此领域的任何收件人。它也不会尝试查找收件人。所有邮件都将通过专用发送连接器转发到另一个邮件环境。
要在 Exchange 中创建具有地址空间@ProExchangeAdmin.com的新权威域，请在 PowerShell 中执行以下命令
Create an Email Address Policy
当创建已接受域时，您可以手动将电子邮件地址添加到收件人。自动分配电子邮件地址要高效得多。这就是电子邮件地址策略的作用。基于某些标准，如收件人类型、Active Directory中的收件人容器或收件人的某些属性，电子邮件地址会自动应用于收件人。
电子邮件地址策略具有：一个名称(A name)，一个电子邮件地址格式(An email address format)，一种类型的收件人(A type of recipient)，定义如何或在哪里在Active Directory中查找收件人的规则(A rule that defines how or where to find the recipients in Active Directory)。
在 Exchange 中，始终存在一个默认的电子邮件地址策略，该策略应用于 Exchange 组织中的所有收件人；此电子邮件地址策略使用默认接受的域。电子邮件地址策略只能与 Exchange 组织中接受的域一起创建。可以创建多个电子邮件地址策略。
要在Active Directory 中 OU=Accounts，OU=Users 中存在的所有收件人上分配<alias>@proExchangeadmin.com 的电子邮件地址，请执行以下 PowerShell 命令:
Relocate the Initial Mailbox Database
除了邮箱数据库的名称外，在 EAC 中无法更改其他属性，包括邮箱数据库的位置。要更改邮箱数据库文件的位置并更改实际邮箱数据库文件的名称(.edb 文件)，必须使用PowerShell 中的 Move-DatabasePath 命令。要重命名邮箱数据库文件并将其移动到不同的位置，请执行以下 PowerShell 命令：
当 Mailbox 数据库重命名或移动到另一个位置时，它将自动卸载。卸载时，用户将断开连接。
Relocate the SMTP Queue Database
由Exchange服务器发送和接收的SMTP消息总是被排队并保存在队列数据库中。默认情况下，该队列数据库保存在与Exchange服务器软件安装在相同的磁盘上。通常，这是C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\data\Queue目录。该队列数据库用于临时存储存储或接收的每个消息，并且它可以快速增长。
传输服务的配置保存在一个称为EdgeTransport.exe的配置文件中。配置文件位于Exchange服务器的C:\Program Files\Microsoft\Exchange Server\V15\Bin目录中。可以手动更改文件位置的设置，但也可以在Exchange服务器上使用PowerShell脚本来处理。Exchange服务器的脚本目录有一个别名$ExScripts
脚本将停止 MSExchangeTransport 服务，将队列数据库和随附文件复制到新位置，并再次启动 MSExchangeTransport 服务。由于复制了队列数据库，因此在移动过程中不会丢失消息。
此配置不会存储在活动目录中。当安装新的累积更新并需要新的配置文件时，以前的配置文件将被覆盖。所有更改都会丢失，需要重新应用。
Relocate IIS Logfiles
Exchange服务器上另一个占用大量磁盘空间的组件是Internet信息服务器(IIS)，它是托管Exchange客户端访问前端组件的Web服务器。
客户端访问前端组件日志文件
C:\inetpub\logs\LogFiles\W3SVC1—Here are the client access front-end component logfiles located.
客户端访问后端组件日志文件
C:\inetpub\logs\LogFiles\W3SVC2—Here are the client access back-end component logfiles located.
所有客户端的所有 HTTPS 客户端请求，无论是直接请求还是代理请求，都会被记录下来。日志文件是纯文本，占用大量的磁盘空间，每个日志文件 10 GB，对于高负载的Exchange 服务器，每天有多个日志文件。仅 SMTP 队列数据库的 IIS 日志就可以填满默认磁盘，Exchange 服务器将停止运行。建议将 IIS 日志文件移动到另一个磁盘。为此，请使用以下 PowerShell 命令将 IIS 日志文件定位到其他盘符。
重新启动IIS以使这些更改生效。
Enter a Product Key
如果没有产品密钥，Exchange 服务器将作为未授权服务器运行，并且仅限于装载五个 Mailbox 数据库。可以配置更多，但不能装载，在注册产品密钥后，需要重新启动信息存储( Information Store)。
Exchange Server 2019 Patch Management
对于 Exchange 服务器，更新会定期发布，称为累积更新 (CU)。CU 不会通过 Windows 更新发布，但仅作为单独的下载提供。有时，会为 Exchange 发布带有安全修复的临时更新，但仅在出现严重漏洞的情况下。这些更新称为安全更新 (SU)，并作为特别发布发布。与 CU 相反，SU 通过 Windows 更新发布，但也可以作为手动下载提供。
累积更新(Cumulative Updates)，包含当前更新，还包括所有以前发布的更新。因此，每个累积更新都是 Exchange server 的完整版本，并且可以用于 Exchange server 的新安装或恢复安装
安全更新(Security Updates)，按需发布，但只有在发现并修复了关键漏洞时才会发布。SUs通过Windows更新发布，但它们也可以作为单独的下载提供。一个SU是针对一个CU的，因此会发布多个版本的SU。
Exchange Client Access Services
Client Access Services
从 Exchange 服务器 2016 开始，客户端访问服务器角色和邮箱服务器角色不再是单独的服务器角色，而是合并为一个角色，即 Exchange 2019 邮箱服务器。 Exchange 2019 邮箱服务器角色由客户端访问服务和邮箱服务组成。请注意命名中“服务器”和“服务”之间的区别，它也可以被视为“前端”和“后端”服务。
Exchange Server 2019 服务器上的客户端访问服务包括以下角色或服务:
Client Access Front End (CAFE) - 客户端访问前端，用于验证客户端请求并代理连接到正确的邮箱服务。
Front-End Transport Service (FETS) - 前端传输服务，用于从其他SMTP主机接收传入的SMTP消息。FETS还可以用于将出站消息路由到其他SMTP主机，但这是可选的。
客户端通过负载平衡器连接到一组负载平衡的Exchange服务器阵列。客户端从负载均衡器连接到客户端访问前端服务，并在身份验证后，将客户端请求代理到托管用户邮箱的邮箱服务。这可以是同一台服务器，也可以是托管用户邮箱的另一台邮箱服务器，如图所示，客户端连接到服务器EXCH01上的CAFE，但邮箱在服务器EXCH02上
客户端连接到CAFE，后者使用Internet信息服务器。经过身份验证后，请求被代理到用户邮箱所在的后端客户端访问服务，该服务也运行在Internet信息服务器上。这可以是相同的Exchange服务器，但它也可以是另一个Exchange服务器。POP3和IMAP4在CAFE和邮箱服务器上都运行着自己的服务。同样，经过身份验证后，POP3或IMAP4服务确定用户邮箱所在的位置，并将请求代理到该邮箱服务器。SMTP的工作方式类似。当邮件被发送到Exchange服务器时，前端传输服务(FETS)接受连接。它确定哪个服务器托管邮箱，并将SMTP连接代理到运行在该服务器的传输服务上，以将邮件发送到邮箱。协议流程如图
为了防止在Exchange服务器上发生冲突，CAFE和客户端访问服务在Internet信息服务器上都有自己的应用程序，每个应用程序都使用自己的端口。CAFE使用默认端口443，但客户端访问服务使用端口444。POP3客户端使用端口110(未加密)或端口995(加密)连接到CAFE。在身份验证后，请求将被代理到托管邮箱的邮箱服务器。这里的POP3服务使用端口1995。对于IMAP4，CAFE使用端口143(未加密)和995(加密)；邮箱服务器使用端口1995进行IMAP4。对于SMTP，使用多个端口。作为FETS默认前端连接器的端口25正在监听。这是所有SMTP主机连接的端口，这是匿名访问。这是来自互联网或需要将SMTP消息传递到邮箱的内部SMTP主机的常规SMTP流量，FETS 确定托管用户邮箱的邮箱服务器，并将消息转发到在邮箱服务器上运行的传输服务。此传输服务使用端口 2525 与 FETS 或 Exchange 传输服务器进行连接。已验证的 SMTP 使用端口 587；Mozilla Thunderbird 等邮件客户端或无法提交 SMTP 消息的应用程序使用该端口匿名。经过身份验证后，提交的 SMTP 消息将按照常规路径发送到收件箱或Internet。SMTP 使用的“奇怪”端口是 FETS 的端口 717。此端口用于从配置为使用FETS 提供的出站前端代理的发送连接器的出站 SMTP 流量。下表列出了客户端访问前端服务和邮箱服务使用的所有端口
Virtual Directories
因此，Exchange服务器上的所有服务都有前端和后端组件。对于IIS，当在Exchange服务器上打开IIS管理器时，这是显而易见的，如图
Exchange服务器可以使用多种身份验证方法。在安装Exchange时使用的默认设置对于正常使用来说已经足够了。对于大型和复杂的组织，或者在与Exchange 2010/2016等先前的Exchange版本共存的情况下，身份验证方法变得更加重要。此外，在通过CAFE 进行身份验证并代理到另一台服务器后，会将凭据传递到代理连接的服务器。
Form-based authentication (FBA) —— 基于表单的身份验证，这是登录 Outlook on the Web 或 Exchange Admin Center 时使用的身份验证方法。用户输入加密的凭据，并将其发送到 Exchange 服务器。
Basic Authentication —— 基本身份验证，通常通过一个请求凭据的小窗口来识别。凭据通过未加密的线路发送，因此基本身份验证必须始终与 SSL 结合使用基本身份验证，通常通过一个请求凭据的小窗口来识别。凭据通过未加密的线路发送，因此基本身份验证必须始终与 SSL 结合使用
Kerberos authentication —— Kerberos身份验证，这是本机的Windows客户端-服务器身份验证方法。最初由麻省理工学院(MIT)开发，后来被集成到Windows 2000中的Active Directory中。Kerberos允许安全的网络身份验证，但连接到运行在域控制器上的密钥分发中心(KDC)需要始终可用。这在内部网络上工作良好，但对于Internet上的客户端、未加入域的客户端或非Windows客户端(如MacBook或Linux客户端)不起作用。一旦客户端具有有效的Kerberos令牌，它就可以使用此令牌访问内部网络上的其他资源。
NTLM —— New Technology LAN Manager，它是微软的一项旧技术。它使用挑战/响应序列，并通过网络发送加密的凭据。然而，使用现代蛮力技术很容易就会受到攻击
Integrated Windows Authentication (IWA) —— Windows集成身份验证，这是IIS使用的本机客户端-服务器身份验证方法，启用时可以使用NTLM和Kerberos两种身份验证。
所有客户端协议都由Exchange服务器独立处理，并通过虚拟目录实现。Exchange服务器上可用的虚拟目录如下：
OWA virtual directory — 用于Outlook on the Web。
ECP virtual directory — 用于Exchange管理中心。
ActiveSync virtual directory — 用于移动客户端。
OAB virtual directory — 用于Outlook客户端下载脱机地址簿。
EWS virtual directory — EWS是Exchange Web Services虚拟目录，由客户端用于请求空闲/忙碌服务、邮件提示或外出回复，也由邮箱复制服务(MRS)用于在Exchange服务器之间移动邮箱。
PowerShell virtual directory — 用于 PowerShell 和 Exchange 的远程访问。
MAPI virtual directory — 用于Outlook 客户端连接到 Exchange 服务 器。
RPC virtual directory — Outlook Anywhere客户端连接到 Exchange 服务器时使用。
Autodiscover virtual directory — 用于Outlook客户端请求邮箱所在的Exchange配置。
每个虚拟目录都有两个 URL，一个供内部使用(-InternalURL 属性)，另一个供外部使用(-ExternalURL 属性)。客户端使用这些属性来确定如何连接到虚拟目录。因此，两个 URL 都必须可解析，并且客户端可以连接到其中一个 URL。例如，Outlook 将使用自动发现机制来确定如何连接到 Exchange 服务器。它接收-InternalURL 和-ExternalURL 属性，并将尝试连接。Outlook 将根据网络设置来确定使用哪个 URL 进行连接。首先，它将尝试使用-InternalURL 进行连接，如果失败，它将尝试使用-ExternalURL 属性进行连接。如果也失败了，Outlook 决定无法连接到 Exchange 服务器，并将保持断开状态。当安装 Exchange 服务器时，所有虚拟目录的 -InternalURL 属性都设置为服务器的 FQDN，而 -ExternalURL 属性为空。当请求MAPI 虚拟目录的属性时，它返回以下输出:
当请求 Outlook Anywhere 的属性时，它会返回以下输出：
如上命令输出所示，每个虚拟目录还具有自己的身份验证方法，该方法独立于其他虚拟目录进行配置。因此，可以配置 OWA 使用基本身份验证，并配置 Outlook Anywhere 使用 NTLM 身份验证。内部客户端和外部客户端之间的身份验证也存在差异。除非您处于共存环境，例如 Exchange 2010/Exchange 2016，并且迁移指南明确告诉您更改设置，否则最好将这些设置保留为默认设置。
每个虚拟目录都有一个 -internalURL 和 -externalURL 属性，客户端使用这些属性连接到Exchange 服务器。对于 OWA 和 EAC，这不是什么大问题。只要名称解析到Exchange 服务器的 IP 地址，您就可以使用任何 URL 访问 OWA。当请求中的名称与证书上的名称不匹配时，您会看到一个证书警告，但除此之外，您可以访问该服务。
对于 Outlook 客户端和移动客户端，情况有所不同，因为这些客户端通过Autodiscover 获取其 Exchange 配置。如果配置不正确，错误的数据将返回给客户端，客户端将无法连接到各种服务。对于单个服务器，如果可以公开解析，则可以使用相同的 FQDN 作为外部 URL。当使用多个 Exchange 服务器时，当在 Exchange 服务器前面使用负载平衡器时，通常，会使用 webmail 这样的通用服务器名称，FQDN 将类似于webmail.proexchangeadmin.com，这个 FQDN 应指向负载均衡器上的虚拟服务，请求将从负载均衡器转发到 Exchange 服务器之一，微软建议使用DNS分离解析(split DNS)，因此webmail.proexchangeadmin. com 将在互联网上解析为外部地址，在内部网络上解析为内部地址。这样，内部URL和外部URL都配置为与 webmail.proexchangeadmin.com 相同的值。要在 Exchange server 上将所有虚拟目录更改为webmail.proexchangeadmin.com 。对于内部URL和外部URL，在EMS中执行以下命令：
RPC 虚拟目录不是这样配置的。没有*-RpcVirtualDirectory命令可用。RPC 虚拟目录是 Outlook Anywhere 的组成部分,在 EMS 中使用 Set-OutlookAnywhere 命令进行配置。注意：Autodiscover 虚拟目录也具有 internalURL 和 externalURL 属性，但它们没有使用。
由于所有通信都通过虚拟目录(在IIS中)在Exchange服务器上进行，因此大量日志记录发生在IIS级别。IIS日志文件的默认位置是C:\inetpub\logs\LogFiles\W3SVC1，对于典型的Exchange服务器，每天存储数百兆字节的数据并不罕见。这么多数据可能会很快填满客户端访问服务器的系统和启动磁盘，因此需要相应地采取行动。前Exchange Server MVP保罗·坎宁安(Paul Cunningham)编写了一个脚本，将日志文件压缩为月度存档，并将存档文件存储在中央存档位置。您可以在他的网站上找到有关此脚本的更多信息和下载选项，网址为https://practical365/powershell-script-iis-logs cleanup/。另一个选择是将IIS日志文件移动到另一个磁盘，如前relocate the IIS logfiles中所示。
Namespaces
命名空间在Exchange服务器中扮演着越来越重要的角色，这始于Exchange服务器2007时代Autodiscover及其命名空间的引入。命名空间是客户端用来访问Exchange环境的域名。例如，webmail.proexchangeadmin.com，Exchange服务器环境中使用的另一个命名空间是autodiscover.proexchangeadmin.com。Outlook客户端使用它向Exchange服务器发送Autodiscover请求，以检索有关在哪里可以找到和如何访问邮箱的信息。在Exchange 环境中，最小数量的命名空间为两个：协议命名空间和 Autodiscover 命名空间。
在 Exchange 2010 中，rpc 客户端访问服务使用另一个命名空间，类似于outlook.proexchangeadmin.com。该命名空间用于 rpc 客户端访问阵列(也称为Cas 阵列)，并作为内部 Outlook 客户端的 rpCc端点。由于不再在 Exchange 中使用Rpc/Tcp，因此不再使用 rpc Cas 阵列。
更多的命名空间意味着 SSL 证书上的更多域名。在典型环境中，webmail.proexchangeadmin.com 和 autodiscover.proexchangeadmin.com 命名空间被使用，因此这些是需要在 SSL 证书上配置的唯一名称。从负载平衡的角度来看，命名空间也是一个重要的考虑因素。第四层负载平衡器无法执行任何内容检查，因此无法确定特定命名空间中使用的协议。例如，第四层负载平衡器无法确定请求是Exchange Web Services、MAPI 虚拟目录还是 ActiveSync；它只知道 Exchange 服务器的 IP 地址。因此，负载平衡器无法检查单个服务的健康状况。通过在负载平衡器处终止 SSL 连接(terminating the SSL connection)，对传入流量进行内容检查并对流量进行重新加密，可以解决这个问题。重新加密流量是可选的。一些客户有这方面的要求，但 Exchange 完全支持 SSL 卸载(SSL offloading)，因此从负载平衡器到 Exchange 服务器的未加密流量也是可行的，但是，我不建议这样做。SSL 卸载和负载平衡将在本章后面进行讨论。
Split DNS
如果内部网络和外部网络(即webmail.proexchangeadmin. com)使用相同的命名空间，那么使用起来会更容易。使用一个名称空间不仅更清晰，而且也不需要在SSL证书上使用其他名称，当从Internet使用webmail.proexchangeadmin.com时，会解析Exchange服务器负载平衡阵列的外部IP地址。当在内部网络上使用webmail.proexchangeadmin.com时，会解析客户端访问服务器的内部负载平衡数组的IP地址。这种配置称为DNS分离式配置，是命名空间规划的推荐方法。
Single Common Namespace
Exchange服务器松散耦合架构的一个优点是它的统一命名空间。现在可以为整个Exchange组织只使用一个或两个命名空间。甚至可以为所有Exchange服务器只使用一个命名空间，例如webmail.proexchangeadmin.com ，例如，一个名为John的用户在阿姆斯特丹登录webmail.proexchangeadmin.com。这是他的邮箱所在的位置。他由本地Exchange服务器进行身份验证，他的请求被代理到另一个Mailbox服务器，也在阿姆斯特丹。当John去纽约旅行时，他仍然可以访问webmail.proexchangeadmin。Exchange服务器检测到John的邮箱在阿姆斯特丹，并通过内部网络代理请求到阿姆斯特丹的邮箱服务器。
SSL Certificates
由于 Exchange 服务器在客户端和 Exchange 客户端访问前端服务之间广泛使用HTTP 进行通信，因此 SSL 证书非常重要。 当安装 Exchange 服务器时，会创建一个自签名 SSL 证书。该自签名证书仅包含服务器的 NetBIOS 名称作为其通用名称，以及服务器在“subject alternative name”字段中的 FQDN。这种证书可用于加密，但不能用于服务器身份验证，因为其发行者(Exchange 服务器本身)不受任何其他机器信任。Edge 订阅中的“默认 SMTP 证书”是一个例外。创建 Edge 订阅时，证书的指纹从Edge 传输复制到 Exchange 2019 服务器。这反过来又用于服务器身份验证。
对于 Exchange 服务器，此自签名证书可用于测试目的，以查看 OWA 和 EAC 是否正确工作，并配置服务器，但它不是用于生产目的。通常的 SSL 证书只有一个名称；这是证书的通用名称(CN)，当使用与通用名称相同的 URL 访问具有此证书配置的服务器时，它将完美工作。例如，可以使用 https://sh-ex01.proexchangeadmin.com/owa 这样的 URL 访问 Exchange 服务器，其证书的通用名称为CN=sh-ex01.proexchangeadmin.com
Exchange服务器及其客户端的“问题”在于，可以使用像 webmail.proexchangeadmin.com 这样的常规 URL 访问该服务器，但是外部 Outlook 客户端(无法访问 Active Directory)会自动尝试使用 FQDN autodiscover.proexchangeadmin.com访问 Exchange 服务器。如果您有常规 SSL 证书，则该尝试将失败，因为 autodiscover.proexchangeadmin.com 服务器名称不匹配 CN=webmail.proexchangeadmin.com 名称。要解决此问题，可以使用多域名证书。此多域名证书可以在其常规名称旁边保存多个服务器名称。这些额外的服务器名称存储在名为“subject alternative name”的属性中。典型多域名证书将具有CN=webmail.proexchangeadmin.com和autodiscover.proexchangeadmin.com的条目。如果在您的环境中使用split DNS配置，这些服务器名称就足够了，这也是根据微软的最佳实践。
Request a New SSL Certificate
要请求新的 SSL 证书，请作为 Exchange 管理员登录到 Exchange 服务器，并在 EMS 中输入以下命令：
在 EMS 中，使用以下命令来完成 SSL 证书创建：
在本例中，该证书仅与 IIS 绑定，用于所有基于 HTTPS 的通信。如果您想将此证书也用于 POP3 和 IMAP4，则可以使用 -Services IIS，IMAP，POP。您还可以将此证书用于 SMTP。
Export an SSL Certificate
当正确安装和配置 SSL 证书时，可以使用 Export-ExchangeCertificate 命令创建Exchange 证书的备份文件。 此备份文件可以保存在安全位置，但也可以用于在额外的 Exchange 2019 客户端访问服务器上导入。 要创建 SSL 证书的导出文件，首先必须找到 SSL 证书的指纹。此指纹是 SSL 证书在 Exchange 环境中的唯一标识符。在EMS 中执行 Get-ExchangeCertificate 命令时，将显示 SSL 证书的指纹：
要将证书导出为 .PFX 文件，您首先必须创建一个包含 SSL 证书导出文件的变量，然后将变量的内容写入磁盘。为此，请在 EMS 中执行以下命令：
前一个示例中的 get-Credential 命令显示了一个可以输入凭据的对话框。对于Export-ExchangeCertificate 命令，只使用密码。与使用“Get-Credential”命令不同，还可以使用字符串作为密码，并使用“ConvertTo-SecureString”命令。然后，之前的命令将是:
Import an SSL Certificate
当您拥有 SSL 证书的导出文件时，可以使用 PowerShell 将此 SSL 证书导入到其他Exchange 服务器。为此，您可以在 EMS 中使用以下命令：
如果您有一个负载平衡的 Exchange 服务器阵列，那么这些服务器上使用的 SSL 证书必须是相同的。
Client
使用 Exchange 服务器时，有多种电子邮件客户端可供选择。
• Outlook
• Web-based clients
• Autodiscover
• Mobile clients
• Exchange Web Services
Outlook
在 Exchange Server 2013 及以上版本中，最重要的变化之一是 Outlook 不再使用直接 MAPI(RPC over TCP)；只能使用 Outlook Anywhere(RPC/HTTPS)或MapiHttp 访问 Exchange 服务器。
Outlook 客户端严重依赖 HTTP(以及 IIS)，不仅用于 MapiHttp，还用于Exchange Web Services(EWS)、Offline 地址簿和 Autodiscover。使用 EWS，Outlook 客户端可以请求可用性信息(空闲/忙碌)或设置离线办公室消息。在缓存模式下运行的 Outlook 客户端会下载 Offline 地址簿。Outlook for Mac 也完全使用HTTPS 通信；此 Outlook 客户端在所有通信中充分利用 Exchange Web Services。最后，Outlook 客户端在配置其 Outlook 配置文件时使用 Autodiscover 查找其初始配置。但这还不是全部；Outlook 每小时都会使用 Autodiscover 检查任何配置更改。
由于所有这些 HTTP 依赖项，不难想象命名空间和 SSL 证书在每个 Exchange 和Outlook 部署中都起着重要作用。一个小小的配置错误就会导致连接错误、身份验证弹出框或 SSL 证书警告。
Outlook客户端可以在缓存模式下运行，也可以在联机模式下运行，其中缓存模式是默认(和首选)模式。在缓存模式下运行时，Outlook将与本地机器上的邮箱副本一起工作，并对这个“缓存”副本进行所有更改。Outlook会自动在后台将这个副本与Exchange Server上的邮箱同步。所有处理都在Outlook客户端的工作站上进行，而不是在Exchange Server上进行，从而减少了Exchange Server上的处理器周期和(昂贵的)磁盘输入/输出。在联机模式下运行时，Outlook直接与Exchange Server协同工作，并且本地工作站上没有邮箱的副本。很明显，这将增加Exchange Server的负载，而且Outlook客户端始终需要在线。在这种情况下，离线工作是不可能的，当在终端服务器环境中使用时，可以在线模式运行 Outlook，但当使用 FSLogix 等工具时，也可以在终端服务器环境中以缓存模式运行 Outlook。
MAPI/HTTP
MAPI/HTTP在Exchange服务器2013 SP1中引入，作为RPC/HTTPS的继任者，也称为Outlook Anywhere。RPC是一个古老的协议，在20世纪60年代开发，用于在正常和稳定的网络(如您的办公室)上运行的服务器，而不是在像WiFi或互联网这样的不可靠的网络上运行。即使Outlook Anywhere本身是稳定的，当您的网络连接时有时无时，您的HTTPS连接可以处理，但HTTPS数据包中的RPC无法处理。Microsoft Exchange可以与HTTPS连接完美地工作。例如，看看ActiveSync或OWA；它们可以在像互联网这样的不可靠的网络上正常工作。如果您因为连接到另一个无线网络而暂时失去互联网连接，OWA将继续工作。ActiveSync也是如此。您可以在全国各地旅行，而不会注意到您的移动设备一直在切换网络。Outlook Anywhere的另一个问题是，它依赖于Windows服务器上的RPC代理服务。因此，RPC代理服务不是微软Exchange产品组的责任，而是微软Windows产品组的责任。当Outlook Anywhere中发现一个错误，结果发现是一个RPC代理服务的问题时，Exchange产品组需要向Windows产品组提交一个事件，并希望后者能够解决问题。这不是一个令人满意的情况。为了克服这个问题，微软开发了MapiHttp，它基本上是本机的HTTPS流量。Outlook客户端不再使用RPC进行MAPI通信，而是直接使用HTTPS。区别如图所示：
MapiHttp 在全局级别启用；您可以在同一时刻为整个组织启用它。要启用MapiHttp，请打开 Exchange 管理 shell 并输入以下命令：
请注意，这一变化可能需要一些时间才能生效。
当从 Exchange 服务器 2010 迁移到 Exchange 服务器 2016 时，您会注意到客户端连接到 Exchange 服务器的差异。较旧的 Outlook 客户端使用 Rcp/Tcp(传统的Mapi)连接到邮箱数据库。作为 Rpc 端点，使用 Rpc Cas 阵列。微软已不再使用Rpc/Tcp；仅存的两种协议是 Outlook anywhere(但已被弃用)和 Mapi/hTtp。这是 Exchange 服务器 2019 的默认协议，但也在 Exchange Online 中。因此，当从Exchange 服务器 2007 迁移到 Exchange 服务器 2016 时，您会看到客户端在迁移邮箱时使用不同的协议重新连接。此外，当从 Exchange 2013 或 Exchange 2016 迁移到Exchange 2019 时，Mapi/Http 不会自动启用。这是需要注意的事情。
Autodiscover
Autodiscover 在 Exchange 2007 中引入，以支持 Outlook 2007，它已被开发成为任何 Exchange 环境中最重要的部分之一。它被广泛地用于 Exchange 本地部署、Exchange Online 和 Exchange 混合场景。如果您没有适当的 Autodiscover 实现，您将遇到各种讨厌的问题，从无法在安排会议时检查空闲/忙碌信息，到无法下载离线通讯簿，无法使用 Outlook 客户端设置离开办公室消息，以及根本无法连接。
当配置 Outlook 时，用户只需输入他们的姓名、电子邮件地址和 Active Directory 密码，Outlook 客户端将自动进行配置。它发现与Exchange服务器实现有关的所有信息，并使用这些信息来配置Outlook配置文件。但是，它不仅在初始设置时这样做，而且还定期执行此操作，以检查Exchange环境中的任何更改。
Autodiscover通过向Exchange服务器发送XML请求来工作。Exchange服务器检查Active Directory以查找用户邮箱的位置，并在需要时将请求代理到托管邮箱的Exchange服务器。此Exchange服务器上的自动发现进程处理请求，收集所有请求信息，并将其返回给客户端。客户端依次配置Outlook profile 。如图所示：
Outlook客户端如何发现要向哪个Exchange服务器发送请求？答案有两个：
登录到活动目录域的域连接 Outlook 客户端直接从活动目录检索此信息。
非域连接的 Outlook 客户端或无法访问 Active Directory 的域连接 Outlook 客户端(例如在家工作时)，基于用户的SMTP构建自动发现URL地址
接下来将介绍这两种情况
Domain-Joined Clients
当安装Exchange服务器时，会在Active Directory的配置分区中创建一个计算机对象。除了这个计算机对象外，还会在Active Directory中创建一个服务连接点(SCP)。对于每个安装的Exchange服务器，都会创建一个相应的SCP。因此，如果您有6个Exchange服务器，那么您也有6个SCP。SCP具有一个已知的GUID(全局唯一标识符)，该GUID对于使用SCP的应用程序类型是唯一的。就Exchange服务器而言，此应用程序是Outlook。通过安装Exchange服务器创建的所有服务连接点具有相同的已知的GUID，Outlook客户端查询Active Directory以获取此GUID。此GUID存储在关键字属性中，与Exchange服务器安装的Active Directory站点名称在一起，如图:
一旦找到，服务绑定信息属性将被检索，并且，默认情况下，此值包含Exchange服务器的FQDN，例如，SH-EX01.proexchangeadmin.com。如果Exchange环境中的Active Directory站点中有多个Exchange服务器，则应在负载平衡器上创建虚拟IP(VIP)。此VIP应为负载平衡的FQDN的IP地址(例如，autodiscover.proexchangeadmin.com)，并且应包含所有Exchange服务器。客户端连接到此VIP，而不是连接到单个Exchange服务器，并且所有客户端请求将分布在所有Exchange服务器上。Outlook客户端从Active Directory检索Autodiscover FQDN，并向此URL发送HTTP POST命令。然后，Exchange服务器接受请求并将其代理到托管用户邮箱的Exchange服务器。该邮箱服务器收集所有所需信息，并将其作为XML 包返回给 Outlook 客户端。然后，Outlook 客户端可以使用 XML 包来配置其配置文件(当它是新设置时)或重新配置其配置文件(当检测到 Exchange 环境中的更改时)。
这个过程总是在发生，不仅是在 Outlook 客户端的初始设置期间；该请求每小时发送一次，以确定 Exchange 配置是否有任何更改。由于这是一个必须进行安全保护的HTTP 请求，因此 SSL 证书发挥作用。autodiscover.proexchangeadmin.com FQDN 也需要在证书中，在 webmail.proexchangeadmin.com 名称旁边。Autodiscover URL 只能通过使用 Exchange 管理 Shell 来配置。为此，打开 EMS 并执行以下命令：
如果所有客户端访问服务器都需要配置此 URL，可以使用以下命令：
注意，在安装完Exchange服务器后直接使用Set-ClientAccessService命令修改SCP记录，以防止Outlook客户端意外从新安装的Exchange服务器检索错误的信息。
Autodiscover将从Exchange环境中检索所有信息，包括有关虚拟目录、离线通讯簿下载和Exchange Web Services的信息。这些Exchange Web Services用于检索空闲/忙碌信息或设置不在办公室信息。因此，如果在Outlook中遇到与空闲/忙碌信息或设置“不在办公室”消息有关的问题，总是建议首先检查OWA中的相同功能，然后检查Autodiscover配置。在99%的情况下，任何与Autodiscover有关的复杂问题都是由SSL证书错误引起的。当使用浏览器连接到Exchange服务器时出现证书错误时，尽管出现错误消息，但仍然可以继续。这是OWA的一个很大的优势，但Outlook要敏感得多。
从 Outlook 中可以验证自动发现功能。当 Outlook 运行时，请检查系统托盘中是否有Outlook 图标。右键单击 Outlook 图标，然后按 Ctrl，然后选择“测试电子邮件自动配置”。如图：
然后输入电子邮件地址和密码，清除“使用Guess smart”和“保护Guessmart身份验证”复选框，然后单击“测试”按钮。Outlook客户端将执行与Exchange Server的Autodiscover检查，Outlook客户端将执行与Exchange Server的Autodiscover检查，并显示如图所示的信息
有三个可见的选项卡:
结果——返回的信息以可读格式显示。
日志——显示 Outlook 客户端尝试检索信息的各种选项。
XML——从Exchange服务器返回的原始XML数据。
Non-domain-Joined Client
非加入域客户端或无法访问 Active Directory 的客户端使用不同的方法获取Autodiscover 信息。首先，Outlook 将基于电子邮件地址的右侧构建 FQDN。因此，如果用户的电子邮件地址为 john@proexchangeadmin.com，Outlook 将开始查看https://proexchangeadmin.com/autodiscover/autodiscover.xml，试图找到Exchange 服务器。通常，这会导致问题，因为根域“proexchangeadmin.com”用于公司网站，而不是 Autodiscover 目的。在这种情况下，拒绝公司防火墙上的 /Autodiscover 请求将有助于加快 Autodiscover 过程。一旦构建了 URL，Outlook 将自动向 Autodiscover URL 发送 HTTP XML POST 请求，并获取所有必要的信息，就像对内部 Outlook 客户端一样。如果这不起作用，Outlook将退回到相同的URL，但带有Autodiscover前缀，例如https://autodiscover.proexchangeadmin.com/autodiscover/autodiscovery.xml。在大多数情况下，这将起作用。
对于外部客户端，在 SSL 证书中正确设置 FQDN webmail.proexchange admin.com 和 autodiscover.proexchange admin.com 域名非常重要。对于非域连接的客户端，除非您在公共 DNS 中实现基于 SRV 记录的解决方案，否则没有简单的方法可以解决这个问题。任何无法访问 Active Directory 的 Outlook 客户端都将自动尝试使用自构建的 URL autodiscover.proexchangeadmin.com 连接到 Exchange 服务器。这是 Outlook 应用程序中的硬编码 。
除了内置的 Outlook 测试实用程序，Microsoft 提供了另一个远程测试工具，称为远程连接性分析器(RCA)，可以通过 https://aka.ms/exrca 或www.testexchangeconnectivity.com/ 访问。此工具将通过 Internet 使用常规的自发现选项自动检查Exchange 配置。
要使用此工具，请选择“Outlook连接”，然后输入用户帐户的电子邮件地址、用户名(可以是UPN或域\用户名)和密码。勾选“我知道必须使用我的Exchange域中的工作帐户凭据……”复选框，然后在验证框中输入字符。您可以单击“验证”按钮，或者直接单击“执行测试”按钮，因为这将自动开始验证。有多种方法可以检索自动发现信息，这些方法显示为一个红色圆圈，里面有一个白色十字，一个绿色圆圈，里面有一个白色复选框，或者一个橙色三角形，里面有一个感叹号。当一种方法失败时，Outlook(and RCA)将自动继续使用下一个可用选项。当您看到红色圆圈时，不需要惊慌；只有当您只看到红色圆圈而没有绿色圆圈时，才需要开始担心。
远程连接性分析器是一个可公开获取的工具，用于测试您的 Exchange 环境。由于它必须从互联网访问您的 Exchange 环境，因此您的 Exchange 服务器必须能够从互联网访问。如果Exchange 服务器位于 VPN 解决方案或MFA 解决方案之后。在这两种情况下，RCA 都无法工作。
它还需要 Exchange 服务器上具有有效和受信任的第三方 SSL 证书。重要提示：它不能与默认的自签名证书一起使用。如果您检查 IIS 日志文件(默认位于%SystemDrive%\inetpub\logs\LogFiles\ W3SVC1)，您将看到许多类似这样的条目:
使用IIS日志文件，可以对自动发现过程进行故障排除。此处显示的是远程连接分析器测试生成的条目在本节前面。它显示了日期和时间、Exchange服务器的IP地址、以及源IP地址。在这个例子中，它显示了负载均衡器的IP地址。它还显示用户名和用户代理字符串。
在IIS日志文件中还会发现很多其他条目，如下所示：
这些服务是由Managed Availability创建的，它是每个Exchange服务器(版本2013及更高版本)中的一种服务，可执行所有服务的端到端可用性。
Autodiscover Redirect
Outlook会自动根据用户的主要SMTP地址构建一个Autodiscover FQDN，在 Exchange 2013 客户端访问服务器的 SSL 证书上。如果您在 Exchange 组织中只有一个或两个主要 SMTP 域，那么这没问题，当您有很多 SMTP 域时，拥有这么多域的 SSL 证书很难使用。大多数第三方 SSL 证书供应商在 SSL 证书上最多支持 20 或 25 个域名。这是这些供应商设定的实际限制。当您的 SSL 证书中有大量域名时，验证所有这些域名需要大量时间，此外，这种 SSL 证书的成本飙升。
假设在 proexchangeadmin.com Exchange 环境中，另一个 SMTP 主机名 inframan.nl。但是，Exchange服务器的SSL证书上只有webmail.proexchangeadmin.com和Autodiscover.proexchangeadmin.com这两个域名。
针对这种情况，微软开发了Autodiscover Redirect选项。这样，Exchange服务器上就多了一个网站(监听端口80)，该网站的FQDN为autodiscoverredirect.proexchangeadmin.com。在IIS内部，对该网站的请求会自动重定向到autodiscover.proexchangeadmin.com。inframan.nl的额外域名在公共DNS中有一个Autodiscover记录，但它不是A记录，而是一个CNAME记录。这个指向Autodiscover.inframan.nl的CNAME记录指向的是autodiscoverredirect.proexchangeadmin.com，该网站位于Exchange服务器上。
当一个外部用户使用主要SMTP地址M.Jones@inframan.nl打开他的Outlook时，Outlook会自动连接到autodiscover.inframan.nl。这个尝试将会失败，因为 Exchange 服务器会用 SSL 警告消息进行回应。Outlook 的下一个尝试是检查 HTTP 重定向选项。Outlook 将访问 Exchange 服务器并检查 HTTP/302 重定向。如果检测到，Outlook 将继续使用重定向字符串中找到的网站进行 Autodiscover 过程。从这里开始，过程相同；Outlook 将向 Exchange 服务器发送 HTTP POST 命令，并在 Exchange 服务器上运行的Autodiscover 服务将收集所有信息并将其作为 XML 文件返回到 Outlook 客户端，Outlook 将从 Exchange 服务器收到 HTTP/302 重定向并继续 Autodiscover 过程。
要在Exchange服务器上实现自动发现重定向方法，您必须
- 向Exchange服务器添加一个附加的IP地址。
2. 在Exchange服务器上创建另一个网站。
3. 正确设置绑定和IP地址。
4. 将附加网站的重定向设置为原始网站(Autodiscover)网站。
在 Exchange 管理 shell 中，可以使用以下命令配置自动发现重定向：
一个服务器上的多个网站需要唯一的IP地址和端口号组合。因此，您会在端口443上看到Default Web Site列表，在端口443上看到Exchange Back End网站。这样，两个网站都可以使用相同的IP地址。相反如果在Exchange服务器上使用其他IP地址，也可以使用不同的端口号。
例如使用Autodiscoverredirect网站进行测试，该网站使用相同的IP地址，但位于端口81上。然后，在负载平衡器上为Autodiscoverredirect网站创建虚拟服务，并连接到端口82上的Exchange服务器。这将为您省去使用额外IP地址的麻烦和潜在挑战。
您可以使用实现自动发现重定向方法的步骤如下：
1.在Exchange服务器上配置附加的IP地址。
2.在IIS管理器中，将默认网站绑定到端口443的Exchange服务器的原始IP地址， 在继续之前，请确保Exchange服务器仍然可以工作 正确地使用了这个新的绑定。
3.在Exchange服务器上，创建两个附加目录：C:\Inetpub\AutodiscoverRedirect and C:\Inetpub\AutodiscoverRedirect\Autodiscover
4.在IIS管理器中，创建一个新的网站，命名它AutodiscoverRedirect，并使用 C:\Inetpub\Autodiscover作为其物理路径，确保此网站的绑定设置为我们之前配置的附加IP地址。
5.在AutodiscoverRedirect网站的IIS管理器，查看Autodiscover虚拟目录，选择这个Autodiscover虚拟目录，并在详细信息窗格中，双击“HTTP重定向”。
6.在HTTP重定向窗口中，检查对此的“重定向”请求目的地，并输入正常的自动发现URL，如https://autodiscover.proexchangeadmin.com/autodiscover
当 Autodiscoverredirect 网站启动并运行时，在负载平衡器上配置一个虚拟 IP 地址，使其对外可访问。最后一步是为 autodiscoverredirect.proexchangeadmin.com 创建一个公共 DNS 记录，该记录应指向附加的 IP 地址。autodiscover.inframan.nl 域名记录应为 CNAME 记录，并指向autodiscoverredirect.proexchangeadmin.com，最后，使用RCA测试此配置。微软在 Exchange Online 中广泛使用 http 重定向选项进行自动发现。
Autodiscover SRV Records
如果您不想在 Exchange 服务器上配置其他网站(例如，因为您没有足够的公共 IP 地址)，Autodiscover 还有另一种方法可以访问您的 Exchange 服务器，那就是在公共DNS 中使用服务记录(SRV)。请注意，并非所有客户端都支持 Autodiscover 的SRV 记录。例如，移动客户端通常不支持此功能。
假设我们在 proexchangeadmin.com 环境中有一个名为 exchange16.com 的另一个SMTP 域，同样，该域名未在任何 SSL 证书中使用。对于此域，我们可以为Autodiscover 配置 SRV 记录。此服务记录类似于 _autodiscover._tcp.exchange16.com，它将指向端口 443 的 Autodiscover.proexchangeadmin.com，如图所示。
当使用 MXToolbox.com(或其他任何工具)来检查 SRV 条目时，您将看到类似于下图所示的内容。
现在，当检查 RCA 时，您将看到 Autodiscover 重定向选项失败，但 SRV 选项成功 。
注意：在使用SRV记录进行自动发现时，您可以使用您喜欢的任何FQDN。通过这种方式，您可以只使用webmail.proexchange.com配置Exchange服务器，并使用SRV记录进行自动发现，并将其指向webmail.proexchange.com，在Exchange的早期，这有时被用来在SSL证书上节省一些钱，但如今，这已不再是一个有效的商业理由，SSL证书价格低廉。但这仍然是可能的。
Web-Based Clients
理论上，所有 Exchange 2019 客户端都是基于 Web 的客户端，但在本部分中，我们将重点介绍 Outlook on the Web(以前称为 OWA，现在仍称为 OWA)及其配套解决方案。
Outlook on the Web
Outlook on the Web是Exchange服务器的主要的和原生的基于Web的邮件客户端，以前称为Outlook Web App(OWA)。OWA是一个基于HTML5的客户端，使用OWA检查邮件，你可以快速排除任何服务器端问题。OWA还有离线使用的选项，这是几年前在Exchange服务器2013中引入的。OWA还支持基于服务器的应用程序，以丰富用户界面并提供其他功能。
OWA Offline
大多数浏览器都支持 OWA 的脱机使用，而且很容易启用。单击“设置”图标，选择“脱机设置”，检查“打开离线访问”复选框，然后按照向导启用离线使用。
邮件数据存储在本地计算机上，这可能会构成一种安全性 当其他人使用电脑时也有风险。数据被存储在位于用户配置文件中的web数据库中 (C:\Users\<username>\AppData\Local\Microsoft\Edge\User Data\Default\databases)
OWA在计算机上使用预定的存储量。如果需要更多的存储空间，则会出现一个弹出窗口，要求提供更多的存储空间。
当离线时，书签是离线访问 OWA 的最佳方式。
默认情况下，只有收件箱和草稿文件夹用于离线同步。最近使用的另外五个文件夹也会同步，但也可以选择其他文件夹。
在组织层面上，可以禁用 OWA 的脱机使用。为此，请使用以下命令在 EMS 中创建OWA 邮箱策略：
还可以在虚拟目录上禁用 OWA 的脱机使用。为此，在 EMS 中执行以下命令：( 注意这些设置必须应用到每个Exchange服务器上。如果您有多台Exchange服务器，可以使用OWa邮箱策略来完成此操作)
Outlook Apps
Outlook 应用程序在 Exchange 服务器 2013 中引入，并在 Exchange 2019 中仍然存在。使用 Outlook 应用程序，您可以自定义 OWA 和 Outlook 的功能。在Exchange 中，一个默认可用的好例子是“必应地图”。当电子邮件中有街道地址时，Exchange 会自动检测到它，联系必应地图。
默认情况下，在 Exchange 中有五个应用程序可用：
• Action Items • Bing Maps • My Templates • Suggested Meetings • Unsubscribe
要添加其他 Outlook 应用程序，请打开 EAC，然后转到“组织”➤“加载项”。在这里，您将看到五个默认的 Outlook 应用程序，但当您单击“+”图标并从 Office 商店中选择“添加”时，您将被重定向到 Microsoft 商店。在“Exchange”上过滤，您将看到所有可用于 OWA (显示为 Web 应用程序)和 Outlook 的 Exchange 可用应用程序。
Office Online Server
当您使用 OWA 并收到带有附件的电子邮件时，除了下载附件并使用当前使用的计算机上安装的应用程序打开它之外，没有其他方法。当它是受信任的设备时，这没有问题，但当它是公共计算机时，情况就不同了。您不希望在公共计算机上下载和存储任何(业务)信息。为了解决这个问题，微软推出了 Office Online Server。Office Online Server 是一种与 Microsoft Exchange、SharePoint 和 Skype for Business 内部部署一起工作的应用程序，它允许您在 Web 浏览器中查看附件，而不是将其下载到计算机上。Office Online Server 的工作原理如下：
- 在 OWA 中，用户单击附件或选择下拉菜单中的预览选项。
- Exchange服务器直接从Office Online服务器检索文件类型的发现信息。
- Office Online服务器将发现信息直接返回给Exchange服务器，并带有唯一的URL。
- Exchange 为附件创建一个 <iFrame>，并使用在前一步中检索到的唯一 URL。此信息将发送到 OWA 客户端。
- OWA客户端使用带有令牌的唯一URL直接在<iFrame>中访问Office Online服务器。
- Exchange将附件传输到Office Online服务器。
- Office Online服务器从附件中渲染内容，并将其直接返回到OWA客户端。
如图所示：
当用户读取附件中的信息并关闭<iFrame>时，所有数据都会被删除，(公共)计算机上不会留下任何东西。
注意：Office Online Server不是Exchange服务器的一部分；它是批量许可协议的一部分，也是单独的下载。此外，Office Online Server仅在Windows 2016上运行，而不在Windows 2019上运行。
安装Office Online服务器很简单。安装Windows 2016服务器，并添加以下先决条件服务器角色和功能：
Office Online Server具有以下必备软件：
Microsoft .NET Framework 4.5.2 — www.microsoft.com/download/details.aspx?id=42643
Visual C++ Redistributable for Visual Studio 2015 — www.microsoft.com/download/details.aspx?id=48145
Visual C++ Redistributable Packages for Visual Studio 2013 — www.microsoft.com/download/details.aspx?id=40784
Microsoft.IdentityModel.Extension.dll — https://download.microsoft.com/download/0/1/D/01D06854-CA0C-46F1-ADBA-EBF86010DCC6/MicrosoftIdentityExtensions-64.msi
Windows Server 2016附带了。NET Framework 4.6.2，所以第一个必备软件不必下载和安装。
Office Online Server上还需要有效的第三方SSL证书。在proexchangeadmin环境中，Office Online Server的FQDN为Office.proexchangeadmin.com，并为该FQDN创建SSL请求。与Exchange服务器不同，证书上不使用其他名称。此外，此FQDN用于外部和内部，下图显示了创建证书请求时的Internet信息服务器管理器。
为证书使用易于识别的友好名称。稍后，在创建 Office Online 服务器场时将使用此名称。
在安装介质上打开Office Online Server安装应用程序，然后跟随向导。安装过程中唯一可以进行的配置更改是软件的位置。
安装完成后，若要创建新的Office Online Server场，请在具有提升权限的PowerShell窗口中执行以下命令：
-certificatename选项是早些时候创建的ssl证书的友好名称。
在安装了 Office Online Server 后，在 OWA 中下载选项旁边会新增一个“预览”选项。但在公共计算机上，您希望完全禁用下载选项，只保留附件的预览选项。这可以通过 OWA 策略中的文件访问选项来实现。要禁用 OWA 中的文件访问，请在EMS 中执行以下命令：
注意，Office Online 服务器很难打补丁。如果必须为该服务器打补丁，则必须删除该服务器上的Office Online Server场，为该服务器打补丁，然后重新创建该服务器上的Office Online Server场。
Exchange Admin Center
Exchange 管理员可以管理 EAC 中大多数功能。那是大多数，但不是全部，因为有些功能无法使用默认设置，甚至对于 Exchange 管理员也是如此，例如 Enterprise Search 功能或导出到 PST 功能。权限通过基于角色的访问控制(RBAC)进行控制。可以禁用对EAC的访问；要完成此操作，请在EMS中执行以下命令：
此更改大约需要 5 分钟才能生效。为了加速此更改，您始终可以使用 IISRESET 命令重置 Internet 信息服务器。注意：只有 EAC 的管理组件将被禁用；用户组件仍然可用。对于外部和内部访问都是如此，对于更精细的方法，建议使用客户端访问规则来限制访问。
Exchange Web Services
Exchange Web Services 不是一个客户端，而是一个应用程序编程接口(API)，可以通过网络或通过 Web 使用 Exchange Online。
EWS客户端可以通过发送基于SOAP 的XML消息来访问Exchange服务器上的邮箱项目。常见的EWS客户端有Microsoft Outlook和Outlook for Mac，但是也有很多PowerShell脚本使用EWS来访问邮箱。此外，第三方应用程序也可以使用EWS来与邮箱进行交互。Outlook的使用案例包括可用性信息(空闲/忙碌)、邮件提示和离线设置。Exchange Web Services架构如图：
Exchange Web Services 体系结构包括以下内容：
- EWS application — 可以是任何客户端，如微软Outlook或Mac版Outlook、自定义应用程序、PowerShell脚本或第三方应用程序。对于自定义应用程序或PowerShell脚本，您必须安装Microsoft Exchange Web Services管理API，可以从http://bit.ly/EWSAPIDownload下载，更多信息，包括代码样本可以在http://bit.ly/ExploreEWS查看。
- SOAP/XML message — XML消息是发送到Exchange服务器的SOAP信封。强烈建议在客户端和服务器之间使用HTTPS进行通信。
- Authentication method — EWS包括基本身份验证、Windows集成身份验证(NTLM)和OAuth。后者用于Microsoft Teams访问Exchange服务器上的邮箱进行身份验证。
- Load balancer — 负载平衡器将客户端请求分配到多个Exchange服务器。
- Array of Exchange servers — Exchange服务器阵列，但对于小型环境来说，可能只有一个Exchange服务器，或者更详细地说，客户端访问前端服务，执行自动发现查询以查找托管用户邮箱的Exchange服务器，并将请求代理到该Exchange服务器。
- Autodiscover service — 自动发现服务通过使用 Active Directory 查找托管用户邮箱的Exchange 服务器来执行服务发现。
- Exchange Web Service — Exchange Web Service 由三个文件描述，Services.wsdl：描述客户端和服务器之间的合同，Messages.xsd：定义请求和响应SOAP消息，Types.xsd：定义 SOAP 消息中使用的元素。
- Database Availability Group — 数据库高可用组，用于托管邮箱数据库。
当 EWS 应用程序从 Exchange 存储区请求信息时，会创建一个符合 SOAP 标准的XML 请求消息，并将其发送到 Exchange 服务器。当 Exchange 服务器收到请求时，它会验证客户端提供的凭据，并自动解析 XML 以获取请求的数据。然后，服务器会构建一个 SOAP 响应，其中包含表示所请求信息的 XML 数据。这些 XML 数据以 HTTP 响应的形式发送回应用程序，由应用程序处理。
Client Access Rules
在 Exchange server 2019 中，新增了客户端访问规则，可以帮助您限制对 EAC 和远程 PowerShell 的访问。客户端访问规则与 Exchange 中的传输规则非常相似。基于某些标准，您可以限制对 EAC 的访问。这些标准是客户端(IPv4 和 IPv6)的 IP 地址、身份验证类型和用户属性值。客户端访问规则由以下组件组成：
Condition — 条件，确定客户端连接以及何时连接符合条件并应用操作。当客户端连接符合条件并应用操作时，规则评估停止。
Exception — 异常，确定该操作不应应用的客户端连接。
Action — 操作，可以应用的有效操作是允许访问(AllowAccess)，拒绝访问(DenyAccess)。
Priority— 优先级，优先级较高的规则(编号较低)在优先级较低的规则之前处理。一条规则的最高优先级为“1”。
注意，客户端访问规则适用于内部和外部客户端连接，因此您必须考虑客户端访问规则对内部客户端的影响。作为最佳实践，您可以创建具有最高优先级的客户端访问规则，允许来自内部网络的连接。
在 EMS 中执行以下命令，以创建一个新客户端访问规则，该规则将限制对 EAC 的访问，但仅允许来自内部子网 10.38. 96.0/4 的客户端访问：
当客户端访问规则处于活动状态且您导航到 Exchange Admin Center 时，您可以登录，但会显示警告：您无法访问 EAC，但如果您愿意，可以重定向到OWA，也可以选择注销。
除了控制对 EAC 的访问外，还可以控制对远程 PowerShell 的访问。要允许对远程PowerShell 的内部访问，即来自 10.38. 96.0/24 子网的客户端，请在 EMS 中执行以下命令：
由于性能原因，客户端访问规则被缓存。这自动意味着更改不会立即生效。对于第一个创建的规则，它可能需要长达 24 小时才能生效。其他客户端访问规则在大约 1 小时内生效。另一个陷阱是 Exchange 服务器前面的负载平衡器。客户端访问规则的结果取决于在负载平衡器上配置透明模式(Transparency)。当负载平衡器上的虚拟服务配置为禁用透明模式时，Exchange 服务器上的所有请求都来自负载平衡器的内部 IP 地址。因此，客户端访问规则将永远不会显示所需的行为。
Mobile Clients
Exchange ActiveSync(EAS)是移动客户端连接到互联网上的Exchange环境所使用的协议。移动客户端主要是运行iOS或Android系统的智能手机和平板电脑。Windows 10默认的邮件客户端也使用EAS从Exchange服务器检索电子邮件。移动客户端在 SSL 证书方面通常非常敏感，并非所有的 SSL 证书都受到移动客户端的认可。要使 EAS 正常运行，必须使用受支持的第三方 SSL 证书。大多数移动客户端依赖于 Exchange 服务器的自动发现功能，因此，拥有一个完全正常工作的自动发现环境是成功运行 EAS 的先决条件。
POP3 and IMAP4
虽然 POP3 和 IMAP4 仍然被广泛使用，并且仍在积极开发中，但它们在微软环境中并不常用。POP3 和 IMAP4 主要用于(低成本的)运行某些类 Unix 环境的托管环境，但它们也可以配置为在 Exchange Server 上使用。还有一些商业应用程序可以使用POP3 或 IMAP4 协议访问特定的邮箱以检索邮件。POP3 和 IMAP 4 默认安装在Exchange 服务器上，但相关服务被设置为“手动启动”，因此如果需要，必须将POP3 或 IMAP4 服务重置为“自动启动”。此外，需要设置身份验证(加密登录或纯文本登录)。Exchange Server 支持基本的 POP3 和 IMAP4，但也支持加密版本，即POP3S(POP3 over SSL)和 IMAPS(IMAP4 over SSL)。POP3和IMAP4协议仅用于检索邮件。邮件客户端应配置为通过SMTP邮件主机发送出站邮件，当然，这可以是运行客户端前端连接器(Client Front-End connector)的 Exchange 服务器。
如果您想使用 POP3 或 IMAP4 的第三方证书，则必须配置相应的服务以使用它，这与IIS 的配置过程非常相似。要为 POP3 和 IMAP4 启用 SSL 证书，请在 EMS 中执行以下命令：
重新启动 POP3 和 IMAP4 服务，就可以正常使用了。
Client Access High Availability
如果您运行多个Exchange服务器，则很可能出于冗余和性能原因而使用负载平衡器。为此，您可以使用负载平衡器解决方案。使用负载平衡器，您可以将来自客户端的负载分布在多个Exchange服务器之间。这将跨Exchange服务器分配负载，如果一个服务器失败，客户端连接将分布在剩余的Exchange服务器之间。负载平衡解决方案可以是硬件负载平衡器、软件负载平衡器(通常类似于硬件负载平衡器，但运行在您自己的硬件上的虚拟机中)和微软网络负载平衡(NLB)。在Exchange Server的早期，几乎没有负载平衡，微软的负载平衡解决方案是使用NLB。虽然NLB工作良好，但它有一些缺点：NLB 是 Windows Server 中的一个服务，因此依赖于服务器。NLB 是 Windows Server 中的一个服务，因此依赖于服务器。亲和力(affinity)唯一的选择是源 IP。当您向 NLB 群集添加或移除节点时，所有客户端都会自动断开连接，必须重新连接。在单播模式(unicast mode)下使用NLB时，可能会发生端口或交换机洪泛(flooding occurs)。没有服务意识(service awareness)，因此可能造成“黑洞”(“black hole“)。NLB 无法与多角色服务器上的数据库可用性组(DAG)结合使用，DAG 使用故障转移群集软件，无法与 NLB 软件结合使用，在 Exchange 2013 之前，可以分离服务器角色，并且可以安装专用客户端访问服务器，因此 DAG 冲突不是问题。从Exchange 2013起，已经不再使用NLB了。
Layer 4 and Layer 7 Load Balancing
在 Exchange 中，可以使用两种负载平衡方式：第四层(L4)负载平衡，一个相对“笨拙”的负载平衡解决方案，将传入客户端连接一对一地转发到Exchange服务器。第 7 层(L7)负载平衡，其中入站 SSL 客户端连接在负载平衡器处终止(terminated)，然后转发(forwarded)到 Exchange 服务器。
让我们将负载平衡层与 OSI 模型进行比较。第 7 层负载平衡器是一种解决方案，其中在应用层进行负载平衡。SSL 会话在负载平衡器处终止，负载平衡器可以对连接执行智能操作，例如修改 HTTP 标头或使用 HTTP 流中的 cookie 信息。然后使用这些信息来标识会话，并确保会话始终连接到相同的 Exchange 服务器。
使用第 4 层负载平衡器，负载平衡发生在网络层。传入连接被“原样”接受并分发到多个 Exchange 服务器，没有任何处理。然后 Exchange 服务器接受连接，并在身份验证后将连接转发到适当的 Mailbox 服务器。由于与 Exchange 服务器的连接是无状态的，因此无需担心亲和性。如果 Exchange 服务器连接失败，则将其重定向到另一台 Exchange 服务器。由于自动重新验证，性能会略有下降，但邮箱服务器的连接得以保留。默认情况下，第 4 层是透明的。
负载均衡器配置了虚拟服务，该虚拟服务具有 FQDN(如 webmail.proexchangeadmin. com)和 IP 地址。IP 地址称为“虚拟 IP”或 VIP。客户端连接到此 VIP，从而连接到负载均衡器。负载均衡器跟踪连接请求的源 IP 并将请求转发到一台 Exchange 服务器。
请记住，在第 4 层负载均衡器中，SSL 连接在 Exchange 服务器上终止，而不是在负载均衡器上终止。因此，负载均衡器无法检查客户端和 Exchange 服务器之间的任何流量。为了克服这个问题，有两种可能的解决方案：
1、为各种服务使用多个 VIP，以便可以检查每个 VIP 的健康状况。
上图中，Exchange服务器的负载平衡器上有多个VIP，可以看到有 8 个单独的 VIP(每个服务一个 VIP)，它们相互独立。当Exchange 服务器的 OWA AppPool 失败时，只有 OWA 流量被重定向到另一台Exchange 服务器，而其他流量继续由这台 Exchange 服务器提供服务。
2、使用第 7 层负载平衡器，以便负载平衡器可以检查单个服务的流量。这可以与 SSL 卸载结合使用。
使用第 7 层负载平衡器，客户端连接在负载平衡器处终止。终止后，负载平衡器可以执行内容检查。它可以检测传入连接是用于 OWA、EWS 还是 MAPI，并将连接重定向到Exchange 服务器的相应虚拟目录。因此，您可以使用一个 VIP 用于 Webmail 和Autodiscover，包括所有虚拟目录。当连接在负载平衡器处终止时，负载平衡器确定将请求发送到哪个虚拟目录。当一个服务失败时，负载平衡器可以仅针对特定虚拟目录在另一个Exchange服务器上启动故障转移。
上图中，在负载平衡器上有一个 VIP，在 Exchange 服务器上有多个虚拟目录，OWA 虚拟目录失败。在这种情况下，负载平衡器将重定向到另一台Exchange 服务器，但此特定服务器的所有其他虚拟目录都将保持活动并支持客户端。
注意，当使用第 7 层负载平衡时，连接在负载平衡器处终止。因此，负载平衡器上的 VIP 是客户端的端点，并且必须配置适当的 SSL 证书。
SSL Offloading
当使用 SSL 卸载时，SSL 流量在负载平衡器处终止；在负载平衡器之外，流量可以继续进行未加密传输。使用 SSL 卸载，可以执行内容检查，从而评估单个客户端请求，然后将这些单独的客户端请求代理到客户端访问服务器上的单独虚拟目录。为了提高透明度，还需要SSL卸载。
默认情况下，不会为单个 Web 服务启用 SSL 卸载，因此必须在 Exchange 服务器的每个虚拟目录上启用 SSL 卸载。为此，请在 EMS 中执行以下命令：
对于 Exchange 服务器上的 Outlook Anywhere，SSL 卸载是默认启用的。如果由于某些原因，Outlook Anywhere 的 SSL 卸载未启用，则可以在 EMS 中使用以下命令启用 SSL 卸载：
客户通常不允许在负载平衡器和Exchange服务器之间进行未加密的流量。为了克服这一点，您可以在负载平衡器上启用重新加密选项。这样，SSL连接在负载平衡器上终止，负载平衡器可以执行其任务，而到Exchange服务器的流量仍然使用加密连接。Exchange服务器的默认自签名证书可用于此情况。自签名证书仅用于加密连接，而不是用于服务器验证；因此，不需要第三方SSL证书。
Load Balancer Transparency
在第 7 层配置中有效工作需要做两件事：入站流量需要通过负载均衡器，响应流量需要通过出口负载均衡器。
为了实现这一点，可以将负载平衡器配置为 L7 透明模式或 L7 非透明模式。
当流量到达负载平衡器时，其源 IP 地址是访问 Exchange 服务器的客户端的 IP 地址，而目标IP 地址是负载平衡器上的虚拟服务的 IP 地址。
默认情况下，第 7 层是不透明的。这意味着客户端源 IP 地址丢失，并被替换为负载均衡器的IP地址。所有 Exchange 审核日志都将显示负载均衡器的 IP 地址，而不是客户端的 IP 地址。
当配置为 L7 透明模式时，客户端的源 IP 地址保持不变，但目标 IP 更改为 Exchange 服务器的 IP 地址。返回流量发送到原始源地址，但返回流量必须通过负载平衡器。Exchange 服务器的默认网关设置必须是平衡器；否则，Exchange 服务器将通过常规网络默认网关路由流量，导致负载平衡器功能中断。如下图，常规流量通过默认网关，但客户端流量需要通过负载平衡器。
使用L7 透明模式，在有些设备中又叫第7层SNAT模式(带SSL卸载)，其中 X-Forwarded-For 标头用于在Exchange 服务器上的 IIS 日志中记录客户端 IP 地址。
当配置为 L7 非透明模式时，负载均衡器会将客户端流量的源 IP 地址更改为负载均衡器的内部 IP 地址，并将目标 IP 地址更改为 Exchange 服务器的 IP 地址。Exchange 服务器将只能看到来自负载均衡器内部 IP 地址的流量，响应流量将始终通过此内部 IP 地址路由。在这种情况下，不需要对 Exchange 服务器的网络设置进行任何更改。
为了实现透明性，需要首先对 Exchange 服务器进行配置，使其支持 SSL 卸载。您可以使用 healthcheck.htm 页面检查 SSL 卸载是否起作用，该页面是Managed Availability 的组成部分，也是负载平衡器检查服务器可用性的工具。打开浏览器，导航到 http://hostname/owa/healthcheck.htm，您应该看到类似下图 的内容，OWA使用未加密的80端口连接。
下一步是禁用负载平衡器和Exchange服务器之间的重新加密流量。这取决于供应商，但使用Kemp LoadMaster时，只需取消勾下图所示的重新加密复选框即可。
虚拟服务应保持“开启”状态，真实服务器(Exchange服务器)也应保持健康状态。当禁用从负载平衡器到Exchange服务器的重新加密流量时，透明性应自动切换到启用状态，如下图所示，禁用重新加密时，透明度会自动启用。
提示：在测试 SSL 卸载时，请注意 OWA 默认使用基于表单的身份验证(FBA)，而 FBA 会自动重定向到端口 443。您可以通过将外部身份验证从 FBA 更改为基本身份验证来绕过此操作。
Customize OWA Login Page
在配置和测试 Exchange 的负载平衡时，不清楚客户端连接到哪个服务器。为了解决这个问题，您可以自定义 OWA 登录页面。当测试 Exchange 时，可以在 OWA 登录页面上添加服务器名称和版本，要做到这一点，请打开C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth 目录中的logon.aspx文件，滚动到 div class=“logonContainer” 部分，并在 UserNameLabel 变量之前添加服务器名称文本。
Up-Level and Down-Level Proxy
Exchange 2013、2016 和 2019 的一个优点是，从客户端访问前端的角度来看，服务器之间是兼容的，并且它们可以执行上层代理和下层代理。什么是上层代理和下层代理？
下级代理意味着邮箱在 Exchange 2016 上，客户端连接到 Exchange 2019 服务器；客户端连接从 Exchange 2019 代理到 Exchange 2016。
上级代理意味着邮箱在 Exchange 2016 上，客户端连接到 Exchange 2013 服务器；客户端连接从 Exchange 2013 代理到 Exchange 2016。
这意味着您可以创建负载平衡的Exchange 2013、2016和2019服务器阵列，而不会出现任何问题。
上层代理仅适用于 Exchange 2013 及更高版本。如果与 Exchange 2010 和Exchange 2016 处于共存模式，则只能使用下层代理。上层代理在此场景下无法使用。仅客户端访问前端服务具有兼容性，邮箱数据库彼此不兼容，因此，数据库可用性组中不能混合 Exchange 版本。
7828
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
