Windows Server 2012 BSoD上的Exchange 2016

我有一个Exchange中的服务器，在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

我在一个不同的网站上看到了同样的问题，但是没有人真正回答这个问题，并且这个post老化了。

有没有人有任何关于如何解决这个问题的指针？我需要安装ANOTHTER Exchange服务器并迁移到？这将是非常不幸的..

您的存储系统失败或速度太慢，无法跟上。如果IO已经停顿太久，Exchange认为存储已经死了，杀死了Wininit来强制重置硬盘。

看到https://technet.microsoft.com/en-us/library/ff625233.aspx并滚动到结尾。 2013年和2016年也是如此。

在某些情况下，整个存储堆栈可能会受到挂起的影响，从而无法将故障事件写入到Windows事件日志的深红通道或任何其他区域。 ESE还通过validation可以写入事件日志来监视深红通道。如果写入事件日志失败很长一段时间，MSExchangeRepl通过终止wininit.exe故意导致Windows错误检查。当操作系统I / O挂起时，系统显然无法将任何ESE事件写入事件日志。

使用Windows Server Backup备份Exchange时，我已经体会到了这一点。备份开始时，将对所有数据库并行进行一致性检查。这导致交换到BSoD几分钟后，存储退出。

第一个解决scheme是禁用ATS心跳存储arrayshttps://kb.vmware.com/kb/2113956

文本太长而无法复制，但是TL; DR：您的存储arrays连接可能会在沉重的IO下丢失，当ATS的心跳超过8秒时，这将导致VM在IO超时，导致Exchange到BSoD。

次要解决scheme是将存储控制器添加到VM，并在控制器之间分发数据库磁盘在我的情况下，单个pvscsi控制器会在6个数据库下严重窒息，但是当磁盘（包括OS磁盘等）分布在4个pvscsi控制器上时，问题就消失了。我没有这方面的参考，只是在vSphere 5.5 U3上的个人经验。

你可以发出一个命令来禁用ESE强制重启，原因很好解释唐的答案。

我最近做了一个esx单服务器的客户，因为IO太过分了。（它仍然在杀死它，因为它只需要打开一个pipe理控制台的例子，但至less它不会重新启动..）

Add-GlobalMonitoringOverride -Identity ExchangeActiveDirectoryConnectivityConfigDCServerReboot -ItemType Responder -PropertyName Enabled -PropertyValue 0 -ApplyVersion“15.0.712.24

在那里你需要使用正确的Exchange版本。

看到那里的交换版本; https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx