none
Can´t move back 2013 mailbox to 2007 RRS feed

  • Question

  • Hello people

    I am working doing mailbox migration from 2007 to 2013, but I want to have a rollback plan in case anything fails. I know that is not the best to come back the mailbox to 2007 but if I need it in an emergency, I need to have a procedure.
    This is the scenario (changed the names)

    DCD1.domain1.local

    EX2007.domain1.local
    DCD2.domain2.local

    EX2013.domain2.local

    I already had the mail enable user in 2007 because was left there after migrating the mailbox from 2007 to 2013. Also, the move request created for that migration was already removed. I created a move request in the following way in 2013

    New-MoveRequest -Identity MAILBOXNAME -RemoteLegacy -BadItemLimit unlimited -RemoteTargetDatabase "EX2007\NAMESTORAGEGROUP\TARGETDB" -RemoteGlobalCatalog "DCD1.domain1.local
    " -RemoteCredential $Credentials -TargetDeliveryDomain domain.com

    Then I ran the following command


    Get-MoveRequest MAILBOXNAME | Get-MoveRequestStatistics -IncludeReport | fl displayname,status,statusdetail,percentcomplete,report,message


    And got this in the report part


    24/01/2019 05:36:16 p.m. [EX2013] The Microsoft Exchange Mailbox Replication service 'EX2013.domain.com' (15.0.1210.2 caps:1FFF) is examining the request.

    24/01/2019 05:36:16 p.m. [EX2013] Connected to target Mailbox 'GUID (Primary)', database 'EX2007\STORAGEGROUP\TARGETDATABASE', Mailbox server 'ex2007.domain1.com' Version 8.3 (Build 83.0).

    24/01/2019 05:36:16 p.m. [EX2013] Connected to source mailbox 'GUID (Primary)', database 'SOURCEDATABASE', Mailbox server 
    'EX2013.domain2.com' Version 15.0 (Build 1210.0).

    Seems that connects OK to 2007. Then...

    24/01/2019 05:41:21 p.m. [EX2013] Move for mailbox 'X500ADDRESS' is stalled because DataMoveReplicationConstraint is not satisfied for the database 'EX2007\STORAGEGROUP\TARGETDATABASE' (agent None). Failure Reason: Information for database GUID hasn't been collected. Will wait until 24/01/2019 05:51:16 p.m..

    24/01/2019 05:42:22 p.m. [
    EX2013] Request is still stalled...
    24/01/2019 05:43:23 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:44:24 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:45:25 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:46:26 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:47:28 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:48:29 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:49:30 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:50:31 p.m. [EX2013] Request is still stalled...
    24/01/2019 05:51:22 p.m. [EX2013] Relinquishing job.


    It will retry every 10 minutes forever.
    Good news, there´s a KB

    Move request that uses RemoteLegacy from Exchange Server 2013 to Exchange Server 2007 never completes

    https://support.microsoft.com/kb/3037077

    Bad news, it´s not available and I don´t know why. The property DataMoveReplicationConstraint is a property for 2010/2013 databases (I think also 2016/2019) but not for 2007. In fact, there is no parameter with that name in the Set-MailboxDatabase cmdlet in 2007 and didn´t find any similar.
    So, I am in a dead end. I also seek on google cache and/or Internet Archive Database, but there is no record about that KB. Don´t know why MS deleted it, but there is no single trace about it.
    Did someone had this problem?

    Thanks

    Friday, January 25, 2019 6:24 PM

All replies

  • What happens if you set DataMoveReplicationConstrain  to none on the 2013 side even though it seems illogical?
    Saturday, January 26, 2019 12:25 PM
    Moderator
  • Don´t worry, nothing is illogical, but I already thought that and the source database (2013) is already in "none".
    What I also tried, even if it´s sound illogical, was having a database (2007) inside a storage group with local continuous replication in case if that change something in the database, but no luck. Same message.
    Monday, January 28, 2019 5:38 PM
  • Don´t worry, nothing is illogical, but I already thought that and the source database (2013) is already in "none".
    What I also tried, even if it´s sound illogical, was having a database (2007) inside a storage group with local continuous replication in case if that change something in the database, but no luck. Same message.

    What if you set the priority to emergency with new-moverequest ?

    Monday, January 28, 2019 6:20 PM
    Moderator
  • Hey Andy, thanks for the help. Tried that and didn´t work.
    Monday, January 28, 2019 10:39 PM