none
Postfach von "reparierter" DB (eseutil /p) kann nicht verschoben werden RRS feed

  • Frage

  • Hallo zusammen,

    folgendes Szenario:

    Exchange 2013 DAG mit 2 Exchange Servern

    SP1 CU10

    Durch verschiedene Ursachen wurde eine DB inkonsistent und zeigte auch einen Dirty Shutdown.
    Ein "Softrepair" schlug fehl und es wurde mit ESEUTIL /p weitergearbeitet.

    DB war dann mit Clean Shutdown da und konnte auch gemountet werden.

    Ein new-mailboxrepairrequest über die DB ist auch erfolgt.

    Alle Postfächer sind da und funktionieren Problemlos.

    Ich möchte nun die Postfächer von der DB entfernen um eine neue nicht wiederhergestellte zu verwenden.

    Da komme ich aber bei den Moverequest auf folgenden Fehler:

    Fehler: Postfachänderungen konnten nicht repliziert werden. Die Einschränkung SecondCopy wird von der Datenbank 1bb782e8-637e-4958-a95d-26b2d5960620 nicht erfüllt, da die Commitzeit 05.11.2015 08:21:13 durch die Replikationszeit 01.01.0001 00:00:00 nicht sichergestellt werden kann."

    Das geschieht bei allen Postfächern. Auch mit BadItemlimit von 200.

    Was habe ich noch für Möglichkeiten?

    Grüße
    Mike

    Donnerstag, 5. November 2015 09:00

Antworten

  • Ok, jetzt geht es wieder....

    Habe folgendes getan:

    set-mailboxdatabase ZielDB -DataMoveReplicationConstraint:none

    (dies darf aber nur temporär sein. Für DAG DB ist SecondCopy der defaultwert

    New-MoveRequest -Identity  'Mailadresse' -TargetDatabase "ZielDB" -BadItemLimit 1000 -AcceptLargeDataLoss

    Vorher war DataMoveReplicationConstraint bei den Datenbanken auf SecondCopy gestellt. Ist aber auch normal bei DAG-DB's soweit ich es recherchieren konnte.

    Es lag aber nicht an LargeItems oder BadItems! Ein neue angelegtes Postfach auf der DB konnte auch nicht verschoben werden.

    Hauptfehlermeldung siehe im ersten Eintrag und dazu noch diese Meldung

    MailboxDataReplicationFailedPermanentException

    Danke für Unterstützung!

    Grüße
    Mike

    • Als Antwort markiert M. Volkmann Donnerstag, 5. November 2015 15:19
    Donnerstag, 5. November 2015 15:19

Alle Antworten

  • Hast du eine passive Kopie von der reparierten DB und hast die wohlmöglich nicht neu erstellt?

    Grüße

    Jörg

    Donnerstag, 5. November 2015 10:28
  • Schon, aber ich entferne diese jetzt noch mal und versuche den moverequest mal ohne passive Kopie.
    Donnerstag, 5. November 2015 10:30
  • Weiterhin erfolglos.

    In der Shell steht der Request sehr lange auf 95% und Finalization.
    Dann wird mit oben beschriebener Fehlermeldung beendet.

    In der Shell FailedOther und 95%

    Donnerstag, 5. November 2015 11:40
  • Hmm, das riecht ja eigentlich dann nach einem Support Ticket. Ich habe da jetzt so adhoc keine Idee zu.
    Donnerstag, 5. November 2015 11:59
  • Habe gerade mitgeteilt bekommen dass es auch bei Postfächern von anderen DB's den gleichen Fehler gibt.

    Habe nun den Loadbalancer in verdacht.

    Im Einsatz ist hier KEMP.

    Ich denke dass hier der Fehler liegt....

    Donnerstag, 5. November 2015 12:19
  • Erfolgt der moverequest über http/s oder über das File-/Datenbanksystem?
    Es ist eine DAG aber die Datenbanken sind jetzt gerade alle auf einem Server aktiv.


    • Bearbeitet M. Volkmann Donnerstag, 5. November 2015 13:38 Schreibfehler
    Donnerstag, 5. November 2015 13:38
  • Ok, jetzt geht es wieder....

    Habe folgendes getan:

    set-mailboxdatabase ZielDB -DataMoveReplicationConstraint:none

    (dies darf aber nur temporär sein. Für DAG DB ist SecondCopy der defaultwert

    New-MoveRequest -Identity  'Mailadresse' -TargetDatabase "ZielDB" -BadItemLimit 1000 -AcceptLargeDataLoss

    Vorher war DataMoveReplicationConstraint bei den Datenbanken auf SecondCopy gestellt. Ist aber auch normal bei DAG-DB's soweit ich es recherchieren konnte.

    Es lag aber nicht an LargeItems oder BadItems! Ein neue angelegtes Postfach auf der DB konnte auch nicht verschoben werden.

    Hauptfehlermeldung siehe im ersten Eintrag und dazu noch diese Meldung

    MailboxDataReplicationFailedPermanentException

    Danke für Unterstützung!

    Grüße
    Mike

    • Als Antwort markiert M. Volkmann Donnerstag, 5. November 2015 15:19
    Donnerstag, 5. November 2015 15:19