Migration of mailboxes from Exchange 2013 CU23 to Exchange 2019 CU7 causes the target database to crash

Question

the text was translated by machine.

I need help with a problem in the process of migration from Exchange Server 2013 CU23 to Exchange Server 2019.

I have the same problem as already asked by ShiftTechGuy on July 31 However, no solution was published in his post: Migrating from Exchange 2013 to 2019 causes target database to crash

I am currently in the process of an Exchange Server migration from Ex2013Cu23 to Ex2019Cu7 and am currently facing the problem that when moving a mailbox to Ex2013-DB the new Ex2019-DB is disconnected and after a short time is available again, the move-request is also completed. If the mailbox is moved Outlook can connect to it. I have been troubleshooting for 2 days now and cannot find a solution.

The installation and configuration of the Ex2019 has also worked until the mailboxes were moved. The first thing I noticed is that when I create a migration batch via the WebGUI, it doesn't start and doesn't show any letterboxes when I open it. You can only delete it via the Powershell. Here I found the info that you should move the migration mailbox first, then it should work. But I did not move the migration mailbox yet, because I encountered my above mentioned problem with the separation of the database on the Ex2019.

Here first a short overview of the environment:

• VM with OS Server 2019 standard (latest patch level) on Hyper-V Host Server 2016 standard, VM version 8

• Exchange Server 2013 Cu23 + .NET4.8

• Installation Exchange Server 2019 CU7 + .NET 4.8

• AD Level (Forest and Domain) is both at 2012R2

The following points have been examined or worked through so far:

• Same error pattern with various mailboxes, various databases on various VHDs

• also a move request between local databases on the Ex2019 leads to this error

• Moving the VM to a newly installed Hyper-V Host Server 2019: same error

The following eventlog entries appear during the move-request: ExchangeStoreDB, ID 225:

At '12.10.2020 13:17:46' the copy of database 'MBX2019' on this server was unexpectedly dismounted. The error returned by failover was "Es ist nur eine Kopie der Postfachdatenbank (MBX2019) vorhanden. Es ist keine automatische Wiederherstellung verfügbar.". For more specific information about the failures, consult the event log on the server for other "ExchangeStoreDb" events.

MSExchangeIS, ID 1013:

The mailbox with mailbox guid 2241df18-af16-46ac-9d60-17935fdb05ff caused a crash or resource outage on database "MBX2019" (44f38f99-38cd-46d5-8a81-54fde40c5069).

Version: 15.02.0721.002 Description: InvalidOperationException:

MSEchangeIS, ID 1002:

Unhandled exception (System.InvalidOperationException: Das Objekt mit Nullwert muss einen Wert haben.(in english: Nullable object must have a value) bei System.ThrowHelper.ThrowInvalidOperationException(ExceptionResource resource) bei Microsoft.Exchange.Protocols.MAPI.MapiMessage.IsStreamSizeInvalid(MapiContext context, Int64 size) bei Microsoft.Exchange.Protocols.MAPI.MapiStream.ValidateStreamSize(MapiContext context, Int64 size) bei Microsoft.Exchange.Protocols.MAPI.MapiStream.Write(MapiContext context, Byte[] bytesToWrite, Int32 offset, Int32 length) bei Microsoft.Exchange.Server.Storage.MapiDisp.RopHandler.WriteStreamExtended(MapiContext context, MapiStream stream, ArraySegment1[] dataChunks, UInt32& outputByteCount, WriteStreamExtendedResultFactory resultFactory) bei Microsoft.Exchange.Server.Storage.MapiDisp.RopHandlerBase.WriteStreamExtended(IServerObject serverObject, ArraySegment1[] dataChunks, WriteStreamExtendedResultFactory resultFactory) bei Microsoft.Exchange.RpcClientAccess.Parser.RopWriteStreamExtended.InternalExecute(IServerObject serverObject, IRopHandler ropHandler, ArraySegment1 outputBuffer) bei Microsoft.Exchange.RpcClientAccess.Parser.InputRop.Execute(IConnectionInformation connection, IRopDriver ropDriver, ServerObjectHandleTable handleTable, ArraySegment1 outputBuffer) bei Microsoft.Exchange.RpcClientAccess.Parser.RopDriver.ExecuteRops(List1 inputArraySegmentList, ServerObjectHandleTable serverObjectHandleTable, ArraySegment1 outputBuffer, Int32 outputIndex, Int32 maxOutputSize, Boolean isOutputBufferMaxSize, Int32& outputSize, AuxiliaryData auxiliaryData, Boolean isFake, Byte[]& fakeOut) bei Microsoft.Exchange.RpcClientAccess.Parser.RopDriver.ExecuteOrBackoff(IList1 inputBufferArray, ArraySegment1 outputBuffer, Int32& outputSize, AuxiliaryData auxiliaryData, Boolean isFake, Byte[]& fakeOut) bei Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.<>c__DisplayClass29_1.b__0(MapiContext operationContext, MapiSession& session, Boolean& deregisterSession, AuxiliaryData auxiliaryData) bei Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.Execute(IExecutionDiagnostics executionDiagnostics, MapiContext outerContext, String functionName, Boolean isRpc, IntPtr& contextHandle, Boolean tryLockSession, String userDn, IList1 dataIn, Int32 sizeInMegabytes, ArraySegment1 auxIn, ArraySegment1 auxOut, Int32& sizeAuxOut, ExecuteDelegate executeDelegate) bei Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.DoRpc(IExecutionDiagnostics executionDiagnostics, IntPtr& contextHandle, IList1 ropInArraySegments, ArraySegment1 ropOut, Int32& sizeRopOut, Boolean internalAccessPrivileges, ArraySegment1 auxIn, ArraySegment1 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, ArraySegment1 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`1 auxiliaryIn, IPoolSessionDoRpcCompletion completion) bei Microsoft.Exchange.Server.Storage.MapiDisp.PoolRpcServer.<>c__DisplayClass48_0.b__0() bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch[T](Action tryDelegate, GenericFilterDelegate filterDelegate, GenericCatchDelegate catchDelegate, T state)).

Does any of you know the problem and can help?

I am at the point where there should be no other solution: I would like to uninstall the new Ex2019 cleanly, reinstall the VM and start the migration process again. Maybe something went wrong with the basic installation, but that is more of a guess. There were no abnormalities, crashes etc. until the first migration batch or move-request.

Can I cleanly remove the Ex2019 from the AD this way and restart it again?

Thank you very much for your efforts.

Greeting

Answer 1

at the moment it looks like I have found and fixed the problem. At least the server is running now since about 6h and several mailbox migrations in both directions without any database disconnections.

The error was in the global transport config (get-transportconfig) at the value MaxReceiveSize, this was set to Unlimited. Because the mail server was already migrated by me over several versions (Ex2003 --> Ex2007 --> Ex2013), I can't say if this was a default value or if it was set like that at some point. I have now set a fixed value, just like with MaxSendSize and since then I had no disconnections of the database on Ex2019.

I noticed that the health mailbox on the Ex2019 database was regularly quarantined. This then led to the problems with the database. During troubleshooting I came across the article here: https://dustindortch.com/2020/02/08/mailbox-quarantined-after-migrating-to-exchange-server-2019/

I am now observing the behaviour and will contact you again.

Greetings

Answer 2

I'm glad you have found a solution to resolve your issue.

In addition, Could a new DB to migrate exchange 2013 users to exchange 2019?

You could follow Exchange Deployment Assistant to migrate exchange 2013 to exchange 2019.

Answer 3

Solution:

Hello,

short return info.

The Ex2019 runs as it should and the problem seems to be solved with the fixed assignment of a value for MaxReceiveSize or MaxSendSize in the transport config. I mark the topic as solved.