简介：《Mastering Microsoft Exchange Server 2016》是一本面向Exchange管理员与IT运维人员的英文原版专业书籍，系统讲解Exchange Server 2016从基础部署到高级运维的完整知识体系。资源本身为一个PDF文件，体积约28.23MB，便于按章节阅读、检索和标注，适合初学者建立整体认知，也适合有经验管理员作为案头参考。全书重点覆盖邮箱数据库管理、消息传输代理（MTA）配置、客户端访问服务器安装、Outlook Anywhere与Exchange Online整合，并针对灾难恢复和高可用性场景给出详细配置方法。书中配有大量实际操作案例和示例，覆盖典型企业环境中的部署与运维需求，可帮助读者理解底层原理、复现排错流程，并根据自身场景完成定制化配置。截至目前已有167人浏览学习，对于希望通过系统学习提升Exchange Server 2016管理能力、或备战相关认证的IT人员而言，是一份高价值的参考资料。
1. 先想清楚 Exchange Server 2016 到底改了什么
很多 IT 同行拿到这本 “Mastering Microsoft Exchange Server 2016.pdf” 时，第一反应是翻目录找“部署步骤”，但真正读懂 2016 的人会告诉你：这一版最大的门槛不是安装向导，而是架构认知的切换。Exchange Server 2016 把 CAS 和 Mailbox 角色合并成单一的邮箱角色，从根上改变了高可用的设计方式。也就是说，过去“多装几台 CAS 分散压力”的思路失效了，一切可用性都得靠数据库可用性组（DAG）和托管可用性（Managed Availability）这套健康模型来撑。这篇文章要解决的就是三件事：部署前要满足什么条件、DAG 怎么建才稳、出了问题从哪里查起。适合正在做 2013 到 2016 升级、或者打算在 2016 上重建邮件系统的工程师往下读。
2. Exchange Server 2016 架构变化与部署前置条件
2.1 为什么 2016 把 CAS 角色并进了邮箱角色
从 Exchange 2013 开始，微软就在推动“瘦 CAS”的概念，到了 2016 索性不再允许单独部署 CAS 角色。OWA、ECP 管理界面、Outlook 的 RPC 访问、MAPI over HTTP，全部运行在邮箱角色内部。这样做的好处很直接：服务器数量减少，许可成本下降，运维只需要盯住一种服务器角色；代价也明显——邮箱角色一旦不可用，用户连登录页都打不开。
这个变化直接影响高可用策略。过去两台 CAS 加两台 Mailbox 是标配，现在常见做法是两台邮箱服务器组成 DAG，把数据库副本分布在两台机器上，再配合负载均衡器把客户端流量指向两台服务器。客户端访问层不再需要单独规划一组角色，网络架构上少了一层，排错路径也随之变短。理解了这一点，再去看 2016 的管理命令，会发现所有操作都围绕“邮箱数据库”展开：建库、加副本、切换激活、查看复制状态。
2.2 部署前的硬性条件：系统、内存与存储
部署 Exchange Server 2016 之前，我一般会先按下面的表格过一遍环境，缺哪项补哪项，避免装到一半报前置检查错误：
| 检查项 | 要求 | 实际运维注意点 |
|---|---|---|
| Active Directory 架构 | 林架构版本不低于 Windows Server 2008 R2 | 先扩展架构再装 Exchange，否则安装程序直接拒绝 |
| 操作系统 | Windows Server 2012 R2 或 2016 | 装完所有补丁再装 Exchange，Windows 更新没跑完容易出怪问题 |
| .NET Framework | 4.6.2 或更高版本 | 必须先于 Exchange 安装，且不能用精简版系统镜像 |
| 内存 | 至少 8 GB，建议 16 GB 起 | 2016 的数据库缓存会自动占用物理内存的一半左右 |
| 磁盘 | 数据库、日志、系统盘分开 | 日志盘的写入延迟比数据库盘的容量更影响体验 |
内存和磁盘是最容易埋雷的地方。如果一台服务器既跑域控又跑 Exchange，性能瓶颈几乎必然出现在缓存争用上；磁盘方面，数据库盘吃的是 IOPS 和随机读性能，日志盘吃的是顺序写的延迟，把两者放在同一块盘上，压力大时日志写入会拖累整个存储栈。生产环境我通常建议数据库和日志至少分两个卷，有条件的直接用 SSD 承载日志。
2.3 用 Setup.exe 做最小化静默安装的命令
对于只需要邮箱角色的场景，我会用静默安装来减少手工点击的错误率。在已加入域的服务器上，以管理员身份打开 PowerShell，先安装必备系统组件，再执行：
Setup.exe /IAcceptExchangeServerLicenseTerms /Mode:Install /Role:Mailbox /InstallWindowsComponents /TargetDir:D:\Exchange/Mode:Install指定为全新安装；/Role:Mailbox仅安装邮箱角色，这是 2016 最常见的部署方式；/InstallWindowsComponents让安装程序自动启用 IIS、.NET、Windows 身份验证等依赖组件，省去手工逐项添加的环节；/TargetDir指定 Exchange 程序文件的安装位置，建议放到非系统盘。
安装时间一般在 40 到 60 分钟，取决于服务器性能和域控响应速度。安装完成后，访问http://服务器名/owa能看到 Outlook 网页版登录页，就说明基础服务已经起来了。这里容易踩的坑是 DNS 解析：如果 Exchange 服务器无法解析域内其他服务器的记录，安装会卡在“准备就绪检查”阶段，日志路径是C:\ExchangeSetupLogs，报错关键词通常是 Mailbox Role 或 Client Access。
3. Exchange Server 2016 高可用：DAG 建组、见证与 AutoReseed
3.1 DAG 的投票模型：奇偶节点与文件见证
DAG 的高可用核心是“投票”机制。每个 DAG 成员和见证服务器各有一票，总票数决定 DAG 是否具备仲裁。常见做法是让 DAG 成员数加上见证服务器的票数等于奇数，这样网络分区时系统能自动判断哪一侧拥有多数派，避免两边同时挂载数据库造成脑裂。
具体选择规则如下：两节点 DAG 必须配一台文件见证服务器，三节点及以上奇数节点 DAG 可以不配见证，但为了在网络割裂时更稳定，我仍然建议保留见证。见证服务器不能是 Exchange 邮箱服务器，一般放在一台普通的文件服务器或域控上，并保证它和 DAG 成员之间的网络稳定。
2016 在 DAG 层面还有个值得注意的设计：数据库切换时，系统优先选择副本状态为“已挂载”且复制队列长度最短的服务器。这个选择过程不需要人工干预，但前提是健康状况探测正常，所以后面第 5 章的Get-ServerHealth就成了日常巡检的标准动作。
3.2 用 PowerShell 创建 DAG 并添加成员的完整命令
创建一个两节点 DAG 并加入成员的典型命令如下：
New-DatabaseAvailabilityGroup -Name DAG01 ` -DatabaseAvailabilityGroupIPAddresses 192.168.10.5 ` -WitnessServer FS01 ` -AutoDagDatabasesRootFolderPath C:\ExchangeDatabases ` -AutoDagVolumesRootFolderPath C:\ExchangeVolumes Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer MBX01 Add-DatabaseAvailabilityGroupServer -Identity DAG01 -MailboxServer MBX02DatabaseAvailabilityGroupIPAddresses指定 DAG 使用的静态 IP 地址；如果网络支持 DHCP，可以省略这一项，但生产环境建议显式指定，避免地址漂移。WitnessServer是见证服务器，这里用的是 FS01。AutoDagDatabasesRootFolderPath和AutoDagVolumesRootFolderPath是 AutoReseed 功能的路径基础，后面细说。
添加成员时，Add-DatabaseAvailabilityGroupServer会自动配置故障转移群集组件，并把这台服务器纳入 DAG 的管理范围。执行完建议用Get-DatabaseAvailabilityGroup -Identity DAG01 | Format-List Servers, WitnessServer确认成员列表，再用Get-MailboxDatabaseCopyStatus检查数据库副本状态是否进入健康的“Healthy”或“Mounted”状态。
提示：DAG 建好后，不要手动去故障转移群集管理器里乱改设置，Exchange 会通过自己的健康模型管理群集组，手工改动可能让系统进入不支持状态。
3.3 AutoReseed 与磁盘布局：2016 的存储救星
AutoReseed 是 Exchange Server 2016 里最具实用价值的功能之一。当数据库副本因为磁盘损坏或数据不一致被系统自动移除后，AutoReseed 会在预先配置好的空白卷上自动重建该副本，不需要管理员手工执行Update-MailboxDatabaseCopy。
这套机制依赖固定的磁盘布局。常见做法是准备多个卷，每个卷放置一个数据库及其日志目录，然后在创建 DAG 时指定数据库根路径和卷根路径。系统会按照“一个卷一个数据库”的规则自动分配。这样做的好处是：某个卷出现物理故障时，只有那一个数据库受影响，其余的仍在正常服务；移除副本后，系统会在备用卷上自动重新播种，大幅减少故障恢复的人工操作。
生产环境中我建议把 AutoReseed 和数据库副本数配合使用：至少 2 个副本，主副本所在卷故障时，系统会自动把活跃副本切换到另一台服务器，然后在新卷上重建坏掉的副本。整个过程里用户只会感受到短暂的重连，数据丢失风险几乎为零。
4. 数据库配额、数据库缓存与邮件流检查点
4.1 数据库缓存：默认够用，但要知道怎么看
Exchange Server 2016 的数据库缓存由存储引擎自动管理，默认最多使用服务器物理内存的 50%。注意这不是固定值，系统会根据页面访问频率动态调整。大部分场景下不需要手工干预，真正该做的是通过性能监视器观察缓存命中率。
在性能监视器里添加MSExchange Database -> Instances -> Cache Size和Database Page Fault Stalls/sec两个计数器，如果页面错误停顿持续偏高，说明内存不足或磁盘太慢。这里有个常见的误解：有人以为增加数据库缓存参数就能提升性能，但 2016 的缓存调优更依赖物理内存容量和数据库工作集的合理性，参数本身已经被封装成自动化逻辑，乱调反而会干扰系统的自适应机制。
4.2 用 Set-MailboxDatabase 设置数据库配额
数据库配额是邮箱系统最常被问到的设置项。给某个数据库统一设置配额限制，使用如下命令：
Set-MailboxDatabase -Identity DB01 ` -ProhibitSendReceiveQuota 5GB ` -ProhibitSendQuota 4.5GB ` -IssueWarningQuota 4GBProhibitSendReceiveQuota是硬上限，用户达到这个值后无法发送和接收新邮件；ProhibitSendQuota只禁止发送，仍可接收，适合给需要持续接收告警邮件的业务邮箱用；IssueWarningQuota是警告阈值，用户邮箱接近上限时会收到系统提示。这里的单位可以用 GB 或 MB，PowerShell 会自动换算。
需要提醒的是，数据库配额是粗粒度策略，适合按部门或项目组统一管理。对于高管等特殊群体，更好的做法是单独建一个数据库并设置更宽松的配额，而不是在同一个库上做例外。邮件归档需求多时，可以把RetentionPolicy和配额配合使用，让旧邮件自动归档或删除，避免数据库无限膨胀。
4.3 邮件流的三个检查点：传输服务、队列与重试
邮件投递出问题时，我一般按固定顺序排查：先看传输服务是否运行，再看队列长度，最后看重试状态。Exchange Server 2016 的邮件流路径从前端传输组件进入，经过分类器，再交给邮箱传输提交服务写入数据库；出站则通过发送连接器路由出去。
查看传输服务和队列的关键命令如下：
Get-Service MSExchangeFrontendTransport, MSExchangeTransport, MSExchangeMailboxTransportSubmission Get-Queue -Server MBX01 | Format-Table Identity, DeliveryType, Status, MessageCount第一条命令检查三个核心服务是否都在运行状态，任何一个处于停止状态都会导致邮件卡住。第二条命令查看 MBX01 上的队列，重点看Status列，如果出现Retry，说明 DNS 或目标服务器暂时不可达；MessageCount持续增长则说明发送连接器配置有问题。
队列需要手动恢复时，使用Resume-Queue -Identity "MBX01\5"，其中5是队列的 Identity 编号，可以替换为具体的队列名称。重新投递后观察 5 到 10 分钟，如果进入Active状态并开始消耗消息数，说明问题已解除；如果立刻退回Retry，就要检查连接器配置和网络路由。
| 检查点 | 关键服务或对象 | 判断标准 |
|---|---|---|
| 入站接收 | MSExchangeFrontendTransport | 服务运行中，端口 25 正常监听 |
| 分类提交 | MSExchangeMailboxTransportSubmission | 服务运行中，无持续增长的提交失败 |
| 出站发送 | Send Connector 与传输队列 | 队列长度稳定，Status 为 Active 或 None |
注意：处理队列问题时不要随意删除队列里的邮件，优先使用
Resume-Queue恢复投递。删除操作是不可逆的，会造成邮件丢失。
5. 用可复现命令做健康巡检与故障恢复
5.1 用 Get-ServerHealth 快速定位不健康组件
日常巡检中最实用的命令是Get-ServerHealth，它会直接返回 Exchange 2016 内置健康探测的结果：
Get-ServerHealth -Identity MBX01 | Where-Object AlertValue -ne 'Healthy' | Format-Table Name, AlertValue, HealthSetName正常输出应该为空，说明所有组件健康。如果某个HealthSetName列出Outlook.Protocol或Owa.Protocol的健康值异常，就立即对应到客户端访问功能的问题面。这个命令的价值在于：把分散在事件日志里的问题汇总成结构化结果，省去逐条翻日志的功夫。
5.2 数据库切换与激活：两条必须背下来的命令
故障切换时，将某个数据库的活跃副本迁移到另一台服务器：
Move-ActiveMailboxDatabase DB01 -ActivateOnServer MBX02 -MountDialOverride:BestAvailabilityActivateOnServer指向要激活的目标服务器；MountDialOverride:BestAvailability表示即使日志缺失也尽量快速挂载，适合故障恢复场景。反向操作，把数据库切回首选服务器时，先调整副本激活优先级再切换，避免切换后立刻再跳回：
Set-MailboxDatabaseCopy -Identity DB01\MBX01 -ActivationPreference 15.3 数据库副本完整性验证的最终手段
如果副本状态一直显示Failed，且Get-MailboxDatabaseCopyStatus的输出里复制队列长度持续增长，常见做法是用Update-MailboxDatabaseCopy手动重新播种一个全新副本：
Update-MailboxDatabaseCopy -Identity DB01\MBX02 -SourceServer MBX01SourceServer参数是可选的，默认选取当前活跃副本作为源。重播种期间会占用大量磁盘 IO 和网络带宽，生产环境建议放在业务低峰执行，并监控源服务器磁盘队列长度。这一步做完后，再执行Get-MailboxDatabaseCopyStatus -Server MBX02 | Format-Table Name, Status, ContentIndexState，确认Status变为Healthy且ContentIndexState为AutoSuspended或Healthy，整个恢复流程才算闭环。
本文还有配套的精品资源，点击获取
