我有一台 Exchange 2016 服务器，大约 14 天后出现蓝屏。该服务器是虚拟的，存在于通过 iSCSI 存储的群集 vmware 环境中。我们运行的其他 Windows 服务器（包括 Exchange 的被动副本）均未出现蓝屏。被动 Exchange 正在备份，并按应有的方式清除被动节点和主动节点上的事务日志。
- 我已尝试安装最新的关键补丁（尚无可选补丁）
- 我已尝试将有问题的虚拟机迁移到新主机。
以下是 BSoD 查看器提供的信息：
052716-21921-01.dmp 27.05.2016 10:22:16 CRITICAL_PROCESS_DIED 0x000000ef ffffe000`de10d080 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e3a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e3a0 C:\Windows\Minidump\052716-21921-01.dmp 8 15 9600 138 150 27.05.2016 10:22:47
051516-25765-01.dmp 15.05.2016 10:11:06 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`0ad80900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e3a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e3a0 C:\Windows\Minidump\051516-25765-01.dmp 8 15 9600 138 150 15.05.2016 10:11:41
042816-19328-01.dmp 28.04.2016 22:36:50 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`3da4f900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e8a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e8a0 C:\Windows\Minidump\042816-19328-01.dmp 8 15 9600 294 472 28.04.2016 22:39:45
041916-23859-01.dmp 19.04.2016 08:43:53 CRITICAL_PROCESS_DIED 0x000000ef ffffe001`23101900 00000000`00000000 00000000`00000000 00000000`00000000 ntoskrnl.exe ntoskrnl.exe+14e8a0 NT Kernel & System Microsoft® Windows® Operating System Microsoft Corporation 6.3.9600.18289 (winblue_ltsb.160328-1315) x64 ntoskrnl.exe+14e8a0 C:\Windows\Minidump\041916-23859-01.dmp 8 15 9600 294 472 19.04.2016 08:47:04
我在另一个网站上看到了有关同样问题的帖子，但是没有人真正回答该问题，而且该帖子已经过期。
有人能指点如何解决这个问题吗？我是否必须安装另一个 Exchange 服务器并迁移进去？这会非常不幸。
答案1
您的存储系统出现故障或速度太慢，无法跟上。如果 IO 停滞时间过长，Exchange 会认为存储已死，并终止 Wininit 以强制硬重置。
看https://technet.microsoft.com/en-us/library/ff625233.aspx并滚动到末尾。2013 年和 2016 年也是如此。
在某些情况下，整个存储堆栈可能会受到挂起的影响，从而无法将失败事件写入 Crimson 通道或 Windows 事件日志的任何其他区域。ESE 还通过验证是否可以写入事件日志来监视 Crimson 通道。如果写入事件日志长时间失败，MSExchangeRepl 会通过终止 wininit.exe 故意导致 Windows 的错误检查。当操作系统 I/O 挂起时，系统显然无法将任何 ESE 事件写入事件日志。
我使用 Windows Server Backup 备份 Exchange 时亲身经历过这种情况。备份开始时，它会并行对所有数据库进行一致性检查。当存储丢失时，这会导致 Exchange 在几分钟后进入 BSoD。
第一个解决方案是禁用 ATS 心跳到存储阵列 https://kb.vmware.com/kb/2113956
文本太长，无法复制，但 TL;DR：当 ATS 8 秒心跳超时时，您的存储阵列连接可能会在重度 IO 下断开，这将导致 VM 中的 IO 超时，从而导致 Exchange BSoD。
第二种解决方案是向 VM 添加存储控制器并在控制器之间分配数据库磁盘。就我而言，单个 pvscsi 控制器在 6 个数据库下会严重阻塞，但当磁盘（包括操作系统磁盘等）分布在 4 个 pvscsi 控制器上时，问题就消失了。我没有这方面的参考，只是在 vSphere 5.5 U3 上的个人经验。
答案2
您可以发出命令来禁用 ESE 强制重启，Don 的回答很好地解释了原因。
我最近为一个拥有一台 ESXi 服务器的客户做了这件事，因为 IO 过度消耗了 Exchange。（它仍然在消耗它，因为例如仅仅打开一个管理控制台就需要很长时间，但至少它不会重新启动..）
Add-GlobalMonitoringOverride -Identity Exchange\ActiveDirectoryConnectivityConfigDCServerReboot -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion '15.0.712.24'
在那里您需要使用正确的 Exchange 版本。
有关 Exchange 版本请参阅此处；https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx
更多详细信息请参阅此处；http://www.tecfused.com/2014/11/exchange-2013-dag-bsod/