☰

将邮箱从 Exchange 2013 CU23 迁移到 Exchange 2019 CU7 导致目标数据库崩溃

tag-icon • tag-icon exchange exchange-2013 exchange-migration exchange-2019
将邮箱从 Exchange 2013 CU23 迁移到 Exchange 2019 CU7 导致目标数据库崩溃

该文本是由机器翻译的。

我需要帮助解决从 Exchange Server 2013 CU23 迁移到 Exchange Server 2019 过程中的问题。

我遇到了与 ShiftTechGuy 在 7 月 31 日提出的问题相同的问题，但是他的帖子中没有发布任何解决方案：从 Exchange 2013 迁移到 2019 导致目标数据库崩溃

我目前正在将 Exchange Server 从 Ex2013Cu23 迁移到 Ex2019Cu7，目前面临的问题是，将邮箱移动到 Ex2013-DB 时，新的 Ex2019-DB 断开连接，短暂时间后再次可用，移动请求也已完成。如果移动邮箱，Outlook 可以连接到它。我已经排除故障 2 天了，但找不到解决方案。

Ex2019 的安装和配置也一直有效，直到邮箱被移动。我注意到的第一件事是，当我通过 WebGUI 创建迁移批处理时，它不会启动，并且在我打开它时不会显示任何信箱。您只能通过 Powershell 删除它。在这里我找到了信息，您应该先移动迁移邮箱，然后它应该可以工作。但我还没有移动迁移邮箱，因为我遇到了上面提到的 Ex2019 上数据库分离的问题。

这里首先简单概述一下环境：

  • Hyper-V Host Server 2016 标准版上的带有 OS Server 2019 标准版（最新补丁级别）的 VM，VM 版本 8

  • Exchange 服务器 2013 Cu23 + .NET4.8

  • 安装 Exchange Server 2019 CU7 + .NET 4.8

  • AD 级别（林和域）均为 2012R2

到目前为止，已经检查或研究了以下几点：

  • 不同邮箱、不同 VHD 上的不同数据库的错误模式相同

  • Ex2019 上的本地数据库之间的移动请求也会导致此错误

  • 将虚拟机移至新安装的 Hyper-V Host Server 2019：同样的错误

移动请求期间出现以下事件日志条目：ExchangeStoreDB，ID 225：

在‘12.10.2020 13:17:46’，此服务器上数据库‘MBX2019’的副本意外被卸载。故障转移返回的错误是“刚刚复制了邮政数据银行（MBX2019）。这不是自动重新处理。”。有关失败的更多具体信息，请查阅服务器上的事件日志中是否存在其他“ExchangeStoreDb”事件。

MSExchangeIS，ID 1013：

邮箱 GUID 为 2241df18-af16-46ac-9d60-17935fdb05ff 的邮箱导致数据库“MBX2019”(44f38f99-38cd-46d5-8a81-54fde40c5069) 崩溃或资源中断。

版本：15.02.0721.002 描述：InvalidOperationException：

MSEchangeIS，ID 1002：

未处理的异常（System.InvalidOperationException：该对象必须具有空值。（英文：可空对象必须具有值）在 System.ThrowHelper.ThrowInvalidOperationException（ExceptionResource 资源）在 Microsoft.Exchange.Protocols.MAPI.MapiMessage.IsStreamSizeInvalid（MapiContext context，Int64 size）在 Microsoft.Exchange.Protocols.MAPI.MapiStream.ValidateStreamSize（MapiContext context，Int64 size）在 Microsoft.Exchange.Protocols.MAPI.MapiStream.Write（MapiContext context，Byte[] bytesToWrite，Int32 offset，Int32 length）在 Microsoft.Exchange.Server.Storage.MapiDisp.RopHandler.WriteStreamExtended（MapiContext context，MapiStream stream，ArraySegment 1[] dataChunks, UInt32& outputByteCount, WriteStreamExtendedResultFactory resultFactory) bei Microsoft.Exchange.Server.Storage.MapiDisp.RopHandlerBase.WriteStreamExtended(IServerObject serverObject, ArraySegment1[] dataChunks，WriteStreamExtendedResultFactory resultFactory) 在 Microsoft.Exchange.RpcClientAccess.Parser.RopWriteStreamExtended.InternalExecute(IServerObject serverObject、IRopHandler ropHandler、ArraySegment 1 outputBuffer) bei Microsoft.Exchange.RpcClientAccess.Parser.InputRop.Execute(IConnectionInformation connection, IRopDriver ropDriver, ServerObjectHandleTable handleTable, ArraySegment1 outputBuffer) 在 Microsoft.Exchange.RpcClientAccess.Parser.RopDriver.ExecuteRops(List 1 inputArraySegmentList, ServerObjectHandleTable serverObjectHandleTable, ArraySegment1 outputBuffer、Int32 outputIndex、Int32 maxOutputSize、Boolean isOutputBufferMaxSize、Int32& outputSize、AuxiliaryDataauxiliaryData、Boolean isFake、Byte[]&fakeOut) 在 Microsoft.Exchange.RpcClientAccess.Parser.RopDriver.ExecuteOrBackoff(IList 1 inputBufferArray, ArraySegment1 outputBuffer、Int32& outputSize、AuxiliaryDataauxiliaryData、BooleanisFake、Byte[]&fakeOut) 在Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.<>c__DisplayClass29_1.b__0（MapiContext operationContext、MapiSession& session、Boolean& deregisterSession、AuxiliaryDataauxiliaryData）bei Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.Execute（IExecutionDiagnosticsexecutionDiagnostics、MapiContext outerContext、String functionName、Boolean isRpc、IntPtr&contextHandle、BooleantryLockSession、String userDn、IList 1 dataIn, Int32 sizeInMegabytes, ArraySegment1 auxIn、ArraySegment 1 auxOut, Int32& sizeAuxOut, ExecuteDelegate executeDelegate) bei Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.DoRpc(IExecutionDiagnostics executionDiagnostics, IntPtr& contextHandle, IList1 ropInArraySegments、ArraySegment 1 ropOut, Int32& sizeRopOut, Boolean internalAccessPrivileges, ArraySegment1 auxIn、ArraySegment 1 auxOut, Int32& sizeAuxOut, Boolean fakeRequest, Byte[]& fakeOut) bei Microsoft.Exchange.Server.Storage.MapiDisp.PoolRpcServer.EcDoRpc(MapiExecutionDiagnostics executionDiagnostics, IntPtr& sessionHandle, UInt32 flags, UInt32 maximumResponseSize, ArraySegment1 request、ArraySegment 1 auxiliaryIn, IPoolSessionDoRpcCompletion completion) bei Microsoft.Exchange.Server.Storage.MapiDisp.PoolRpcServer.EcPoolSessionDoRpc_Unwrapped(MapiExecutionDiagnostics executionDiagnostics, IntPtr contextHandle, UInt32 sessionHandle, UInt32 flags, UInt32 maximumResponseSize, ArraySegment1 request、ArraySegment`1auxIn、IPoolSessionDoRpcCompletion 完成）bei Microsoft.Exchange.Server.Storage.MapiDisp.PoolRpcServer.<>c__DisplayClass48_0.b__0() 在 Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch[T](Action tryDelegate、GenericFilterDelegate filterDelegate、GenericCatchDelegate catchDelegate、T state))。

你们中有谁知道这个问题并且可以提供帮助吗？

我现在已经没有其他解决方案了：我想彻底卸载新的 Ex2019，重新安装虚拟机并再次启动迁移过程。也许基本安装出了问题，但这更像是一种猜测。在第一个迁移批处理或移动请求之前，没有出现任何异常、崩溃等。

我可以通过这种方式从 AD 中干净地删除 Ex2019 并重新启动它吗？

非常感谢你的努力。

问候

答案1

目前看来我已经找到并修复了这个问题。至少服务器从大约 6 小时前开始运行，并且进行了几次双向邮箱迁移，没有出现任何数据库断开的情况。

错误发生在全局传输配置 (get-transportconfig) 中的 MaxReceiveSize 值处，该值被设置为 Unlimited。由于我已经将邮件服务器迁移了多个版本 (Ex2003 --> Ex2007 --> Ex2013)，因此我无法确定这是默认值还是在某个时候设置成那样。我现在设置了一个固定值，就像 MaxSendSize 一样，从那时起，我就再也没有断开过 Ex2019 上的数据库连接。

我注意到 Ex2019 数据库上的健康邮箱经常被隔离。这导致了数据库出现问题。在故障排除过程中，我偶然发现了这篇文章：https://dustindortch.com/2020/02/08/mailbox-quarantined-after-migrating-to-exchange-server-2019/

我现在正在观察该行为并将再次与您联系。

问候

答案2

我很高兴你找到了解决问题的方法。

此外，新数据库是否可以将 Exchange 2013 用户迁移到 Exchange 2019？

您可以关注Exchange 部署助理将 Exchange 2013 迁移到 Exchange 2019。

答案3

解决方案：

你好，

简短的返回信息。

Ex2019 运行正常，问题似乎已通过在传输配置中为 MaxReceiveSize 或 MaxSendSize 固定分配值来解决。我将此主题标记为已解决。

相关内容