Sign in
 
Exchange Server TechCenter > Exchange Server Forums > High availability/Disaster Recovery > Standby Continuous Replication error
Ask a questionAsk a question
Search Forums:
 

AnswerStandby Continuous Replication error

  • Friday, February 01, 2008 4:28 PMBill P Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Am attempting to enable SCR on two standalone EX2k7 SP1 servers in same site. From the EMC I can enable LCR, and diid so. I then disabled it. When issuing the "enable-storagegroupcopy" command, i get the error:

     
    "Enable-StorageGroupCopy : Another standby continuous replication source is already configured at 'x:\Exchange Server\Mailbox\First Storage Group\Logs' for 'CopySystemFolderPath'.
    At line:1 char:24
    + enable-storagegroupcopy  <<<< -identity "first storage group" -standbymachine"

    I removed all of the files from the the copied location, and still get the error. If i run "disable-storagegroupcopy", reports there is no copy running. I found a simiilar thread in this forum, but the fix there did not help my issue.


    How can I fix or remove the setting indicated by the "log" copy error from above? Found nothing else searching Google, Technet, Forums or Experts-Exchange.

    thanks
    Bill

     

Answers

  • Saturday, February 02, 2008 1:33 AMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Sign In to Vote
    0
    Sign In to Vote

    Sorry when I typed "database" before I meant to say data path. My fingers have a mind of their own. CMS stands for Clustered Mailbox Server. While it might not have an application to your setup it is probably the reason why the same installation path was required for SCR. Have you tried using the GetScrSources script to see which storage groups report if it has a copy configured?

    I would suggest creating a new storage group for one of your server and then move all of the data to that storage group and remove "First Storage Group" for that server. I think that will unblock you.

     

     

All Replies

  • Friday, February 01, 2008 6:01 PMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    There could be multiple problems here. The first one is that SCR is in no way exposed through EMC. The next is that I'm pretty sure a storage group can't have an LCR copy and an SCR copy. The next is that a mailbox server can't have conficting names with the storage groups it has. So if Mailbox Server MBX1 has a storage group called "First Storage Group" and MBX2 has its own "First Storage Group" neither of these storage groups can be SCR targets on the other Mailbox Server. Doing so creates naming conflicts.

     
  • Friday, February 01, 2008 8:00 PMBill P Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Thanks for the insightful reply. Sadly, i know SCR is command line only. I did remove the LCR via EMC (same method as the install.) One of the prerequisites for SCR is that the source and target data and installation paths must match. I take that to mean down to the storage group folder, you don't think so? I can change the target name to check.Finding the instruction for how to do SCR isn't difficult, finding anything about trouble shooting, even the "help" on the PS1 apps, sucks.I guess it would be too much to hope that an MS Exchange person might be monitoring this thread and offer some wonderful solution. But I keep hoping, if we mere mortals can't fix it!

    thanks again

    Bill

     
  • Friday, February 01, 2008 9:18 PMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    You don't specify that database when enabling SCR. It will keep the same as the source. The installation path is annoying, but it's because if the CMS is moved to the SCR target and it looks up where the bits are supposed to be, and they're not there on the new machine you'll start pulling your hair out even more.

     
  • Friday, February 01, 2008 10:38 PMBill P Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    I don't understand. Don't specify WHAT database when enabling SCR? The only identities are the "first storage group" and target machine. Which acronym is this 'CMS' - sorry I can't find one that makes sense to me. The two machines are configured identically: install path is at d:\program files\microsoft\exchange server, the logs are both on x:\exchange server\mailbox\first storage group\logs, and the DBs are both on x:\exchange server\mailbox\ first storage group.

     For the life of me I can't figure out how to address " standby continuous replication source is already configured ", in ADSIEdit, I can't any applicable parameters with any informatio.

    Argh. Day and half wasted on this with no results! I'm getting frustrated.

     

    Here is the command I'm working with:

    [PS] H:\>enable-storagegroupcopy -identity "first storage group" -standbymachine target  -replaylagtime 0.0:05:0

    The output above is consistent. I've tried running several other commands to remove any links, sadly all fail:

    1) Interestingly, says no SCR is enabled on source

    [PS] H:\>disable-storagegroupcopy -identity "first storage group" -standbymachine source

    Disabling Storage Group Copy "first storage group".
    Yes Yes  Angel Yes to All  No No  [L] No to All  Sleep Suspend  [?] Help
    (default is "Y"):y
    Disable-StorageGroupCopy : Storage group 'first storage group' does not have standby continuous replication enabled.
    At line:1 char:25
    + disable-storagegroupcopy  <<<< -identity "first storage group" -standbymachine source

    2)  Plain vanilla test on the source only give an entirely different message

    [PS] H:\>enable-storagegroupcopy -identity "first storage group"
    Enable-StorageGroupCopy : The storage group is not enabled for local continuous replication. This command can only be used on storage groups whose databases have been enabled for local continuous replication with Enable-DatabaseCopy.
    At line:1 char:24
    + enable-storagegroupcopy  <<<< -identity "first storage group"

    3) The target machine responds identically with the source - no SCR enabled

    [PS] H:\>disable-storagegroupcopy -identity "first storage group" -standbymachine target

    Disabling Storage Group Copy "first storage group".
    Yes Yes  Angel Yes to All  No No  [L] No to All  Sleep Suspend  [?] Help
    (default is "Y"):y
    Disable-StorageGroupCopy : Storage group 'first storage group' does not have standby continuous replication enabled.
    At line:1 char:25
    + disable-storagegroupcopy  <<<< -identity "first storage group" -standbymachine target

    4) The consistent failure:

    [PS] H:\>enable-storagegroupcopy -identity "first storage group" -standbymachine target  -replaylagtime 0.0:05:0
    Enable-StorageGroupCopy : Another standby continuous replication source is already configured at 'X:\Exchange Server\Mailbox\First Storage Group\Log' for 'CopySystemFolderPath'.
    At line:1 char:24
    + enable-storagegroupcopy  <<<< -identity "tcpcs71-a\first storage group" -standbymachine target  -replaylagtime 0.0:05:0

     
  • Saturday, February 02, 2008 1:33 AMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     Answer
    Sign In to Vote
    0
    Sign In to Vote

    Sorry when I typed "database" before I meant to say data path. My fingers have a mind of their own. CMS stands for Clustered Mailbox Server. While it might not have an application to your setup it is probably the reason why the same installation path was required for SCR. Have you tried using the GetScrSources script to see which storage groups report if it has a copy configured?

    I would suggest creating a new storage group for one of your server and then move all of the data to that storage group and remove "First Storage Group" for that server. I think that will unblock you.

     

     
  • Saturday, February 02, 2008 6:12 AMBill P Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Thanks again for sticking with this. Creating a new SG and DB, moving the mailboxes to it eventually worked. There were a couple of glitches, but mostly went well. The basic SCR command completed without error. So thanks much. I will try to finish this tomorrow - i'm not convinced it's totally right just yet, but certainly a big step closer!

    Bill

     

     

     
  • Friday, February 08, 2008 3:15 PMmillercepbs Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    I've been getting these same errors on both of my storage groups. Any ideas?

    I've created similar storage groups on both servers with the same paths for the databases and log files.

    I've checked to make sure that I don't have LCR running on any of my storage groups.

    At one time, the storage gropus had spaces in their names, the script doesnt like names with spaces, so I removed the spaces.

     

    I'm stuck here....all the shell *** pisses me off. It's like MS took a step backwards with their interfaces with 07!!!

     
  • Friday, February 08, 2008 8:04 PMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    The problem here is that you created similar storage groups on your SCR targets. That's why SCR is blocking. It doesn't want to over write any data in the original with data from the copy. So remove the similar storage groups on the computers you want to be the targets, and let SCR create the directories and pass over all of the data.

     
  • Friday, February 08, 2008 10:55 PMBill P Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Absolutely correct. Thank you. I removed the SGs on the target machine, built new ones on the source and moved what little data I had to the new DB (new name as well.) Then the commands went just fine. However, I'm still awatiing replication to occur and build the mdb file on the target. I have about 200 log files, but no mdb file. I've tried suspend-,. update-, restore-, resume-storagegroup. I don't see any errors in logs I can find. Wish I had some errors to share, but there aren't any. I know there needs to be 50 log files before the mdb is copied - again, I have over 200. Any thoughts?

    thx

    -b 

     
  • Saturday, February 09, 2008 2:43 AMjader3rd Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    What's the replay lag time set to? I believe the default is 24 hours.

     
  • Saturday, February 09, 2008 3:03 AMBill P Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote

    Good thought, I set the lag time to 0.0:1:0 (one minute if I read the colons right Smile)

     
  • Wednesday, November 04, 2009 8:54 AMsdfsfdg Users MedalsUsers MedalsUsers MedalsUsers MedalsUsers Medals
     
    Sign In to Vote
    0
    Sign In to Vote
    Hello,

    Possible Causes 

    The SCR target server may be using the same log file path as the SCR source server.  This can happen when attempting to enable SCR on the First Storage Group.

    Resolution 

    Change the log file, system file paths on the Storage Group and database path on the Mailbox database to another location on the SCR target server.  Note: In order for the file path change to take effect the databases in the Storage Group will be temporarily dismounted and then remounted.

    See at http://msexchangeteam.com/archive/2008/05/28/448929.aspx  for more informations.
    Best regards