Hallo,
erst Mal vielen Dank an Frank für das Betreiben dieser Plattform, sie hilft mir seit vielen Jahren in meinem Alltag als Administrator.
Nun zu meinem Problem:
Ich benötige einmal Euer Schwarmwissen! Ich bin gerade in einer Exchange Server Migration von Ex2013Cu23 zu Ex2019Cu7 und stehe im Moment vor dem Problem, dass beim Verschieben eines Postfaches in die Ex2013-DB die neue Ex2019-DB getrennt wird und nach kurzer Zeit wieder zur Verfügung steht, der move-request wird auch abgeschlossen. Ist das Postfach verschoben kann sich Outlook auch damit verbinden. Ich bin schon seit 2 Tagen in der Fehlersuche und finde keine Lösung.
Die Installation und Konfiguration des Ex2019 hat bis zum Verschieben der Postfächer auch geklappt. Als erstes ist mir aufgefallen, dass wenn ich einen Migration Batch über die WebGUI erstelle, dieser nicht startet und beim Öffnen keine Postfächer anzeigt. Man kann diesen nur über die Powershell löschen. Hier habe ich die Info gefunden, dass man zuerst das Migrationspostfach veschieben soll, dann sollte es klappen. Das Migrationspostfach habe ich aber noch nicht verschoben da ich vorher auf mein oben genanntes Problem mit der Trennung der Datenbank auf dem Ex2019 getroffen bin.
Hier zuerst ein kurzer Überblick zur Umgebung:
- VM mit OS Server 2019 Standard (aktuellster Patchlevel) auf 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 und Domain) ist beides auf 2012R2
Folgende Punkte wurde bisher geprüft bzw. abgearbeitet:
- Gleiches Fehlerbild mit diversen Postfächern, diversen Datenbanken auf diversen VHDs
- auch ein move request zwischen lokalen Datenbanken auf dem Ex2019 führt zu diesem Fehler
- Umzug der VM auf einen frisch installierten Hyper-V Host Server 2019: gleicher Fehler
Die folgenden Eventlog Einträge erscheinen während dem 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.
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, ArraySegment`1[] dataChunks, UInt32& outputByteCount, WriteStreamExtendedResultFactory resultFactory)
bei Microsoft.Exchange.Server.Storage.MapiDisp.RopHandlerBase.WriteStreamExtended(IServerObject serverObject, ArraySegment`1[] dataChunks, WriteStreamExtendedResultFactory resultFactory)
bei 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, ArraySegment`1 outputBuffer)
bei Microsoft.Exchange.RpcClientAccess.Parser.RopDriver.ExecuteRops(List`1 inputArraySegmentList, ServerObjectHandleTable serverObjectHandleTable, ArraySegment`1 outputBuffer, Int32 outputIndex, Int32 maxOutputSize, Boolean isOutputBufferMaxSize, Int32& outputSize, AuxiliaryData auxiliaryData, Boolean isFake, Byte[]& fakeOut)
bei Microsoft.Exchange.RpcClientAccess.Parser.RopDriver.ExecuteOrBackoff(IList`1 inputBufferArray, ArraySegment`1 outputBuffer, Int32& outputSize, AuxiliaryData auxiliaryData, Boolean isFake, Byte[]& fakeOut)
bei Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.<>c__DisplayClass29_1.<DoRpc>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, IList`1 dataIn, Int32 sizeInMegabytes, ArraySegment`1 auxIn, ArraySegment`1 auxOut, Int32& sizeAuxOut, ExecuteDelegate executeDelegate)
bei Microsoft.Exchange.Server.Storage.MapiDisp.MapiRpc.DoRpc(IExecutionDiagnostics executionDiagnostics, IntPtr& contextHandle, IList`1 ropInArraySegments, ArraySegment`1 ropOut, Int32& sizeRopOut, Boolean internalAccessPrivileges, ArraySegment`1 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, ArraySegment`1 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, ArraySegment`1 request, ArraySegment`1 auxiliaryIn, IPoolSessionDoRpcCompletion completion)
bei Microsoft.Exchange.Server.Storage.MapiDisp.PoolRpcServer.<>c__DisplayClass48_0.<EcPoolSessionDoRpc>b__0()
bei Microsoft.Exchange.Common.IL.ILUtil.DoTryFilterCatch[T](Action tryDelegate, GenericFilterDelegate filterDelegate, GenericCatchDelegate catchDelegate, T state)).
Kennt jemand von Euch das Problem und kann helfen?
Ich bin im Moment an dem Punkt angekommen sollte es keine andere Lösung geben: Ich würde gerne den neuen Ex2019 sauber deinstallieren, die VM neu aufsetzen und den Vorgang der Migration nochmal starten. Evtl. ist bei der Grundinstallation etwas schief gelaufen, das ist aber eher eine Vermutung. Es gab keinerlei Auffälligkeiten, Abstürze etc. bis zum ersten Migrationbatch bzw. move-request.
Kann ich den Ex2019 auf diesem Weg sauber aus dem AD entfernen und nochmal neu starten?
Vielen Dank für Eure Bemühungen.
Gruß
hat niemand einen Tipp oder ähnliche Erfahrungen gemacht / machen dürfen? ?
Wie sieht es mit der sauberen Deinstallation des Ex2019 zum aktuellen Status aus? Ich mache nun seit knapp 20 Jahren Exchange Server und musste noch nie den Rückzug antreten
Es wurden noch keine Postfächer dauerhaft umgezogen und alle DNS Einträge zeigen auf den Ex2013.
Gruß
Hallo,
im Moment sieht es so aus, als wenn ich das Problem gefunden und behoben habe. Zumindest läuft der Server nun seit ca. 6h und div. Postfachmigrationen in beide Richtungen ohne irgendwelche Datenbanktrennungen.
Der Fehler lag in der globalen Transportconfig (get-transportconfig) am Wert MaxReceiveSize, dieser war auf Unlimited eingestellt. Da der Mailserver von mir bereits über mehrere Versionen (Ex2003 --> Ex2007 --> Ex2013) migriert wurde, kann ich nicht mehr sagen ob das ein Default-Wert war oder irgendwann so eingestellt wurde. Ich habe nun einen festen Wert eingestellt, genau wie bei MaxSendSize und seitdem hatte ich keinerlei Verbindungstrennungen der Datenbank auf dem Ex2019.
Aufmerksam darauf bin ich geworden, da mir aufgefallen ist, dass das Health-Postfach der Ex2019-Datenbank regelmäßig unter Quarantäne gestellt wurde. Dies führte dann zu den Problemen mit der Datenbank. Bei der Fehlersuche bin ich auf den Artikel hier gestoßen: https://dustindortch.com/2020/02/08/mailbox-quarantined-after-migrating-to-exchange-server-2019/
Ich beobachte das Verhalten nun und melde mich nochmal.
Gruß
Hallo,
kurze Rückinfo.
Der Ex2019 läuft wie er soll und das Problem scheint mit der festen Vergabe eines Wertes für MaxReceiveSize bzw. MaxSendSize in der Transportconfig behoben zu sein. Ich markiere das Thema als gelöst.
Anscheinend war nur der Wert MaxReceiveSize, der auf Unlimited gestanden hat, der Auslöser für da Problem. Dies führte zur Quarantäne der Health Mailbox der Datenbank und damit zum Absturz der Datenbank.
Again what learned! ?
Hallo Welt!
Ich möchte mich an dieser Stelle bei Hoffi bedanken. Der Foreneintrag hat mir das Wochenende gerettet.
Ähnliches Phänomen - Migration von Ex2013 zu Ex2019 - mit New-MoveRequest Befehl 36 von 43 Postfächer verschoben, dann immer wieder Fehler und keine Migration mehr möglich. Postfächer in der Quarantäne und immer wieder die Meldung:
Das Postfach /o=First Organization/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=Server2/cn=Microsoft System Attendant kann nicht geöffnet werden
Datenbank repariert, Systempostfach mehrfach neu angelegt, neue Datenbank, Datenbanken stürtzten immer wieder ab - nix half.
Nach der Anpassen der "maxsendsize" und "maxreceivesize" kam endlich Besserung. Ich vermute das Vorgänger auch von noch älteren Systemen migriert hatten und hier auch die Werte mitgenommen wurden.
Hier noch kurz verwendete Befehle für die Nachwelt:
Anzeigen lassen der maximal größen für Transport, Empfang und Nachrichtengrößen:
get-transportconfig | ft maxsendsize, maxreceivesize;get-receiveconnector | ft name, maxmessagesize;get-sendconnector | ft name, maxmessagesize;get-mailbox Administrator |ft Name, Maxsendsize, maxreceivesize
Ändern der maximalen Sende- und Empfangs-Größe in der Transportkonfig:
get-transportconfig | Set-TransportConfig -maxsendsize 100MB -maxreceivesize 100MB
@Hoffi - Nochmals Danke!