Sign in
 
HomeOnline201020072003LibraryForumsPartnersEHLO Blog
Exchange Server TechCenter > Exchange Server Forums > High availability/Disaster Recovery > Manual Seed of SCR Target

Unanswered Manual Seed of SCR Target

    •  
      Monday, September 21, 2009 10:52 PM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      I’m in the process to setup SCR in my Exchange organization and have a few questions regarding manual seeding process.

       

      CURRENT ENVIRONMENT

       

      SCR Source: CCR running in Production Site – Win Server 2003 Enterprise – Exch 2007 SP1

      Additional Server running HUB and CAS roles

       

      SCR Target: DR Site – Win Server 2003 Enterprise – Standalone Exch 2007 SP1 running the Mailbox Server Role

      Additional Server running HUB and CAS roles

       

       

      PLAN

       

      Here is my Plan for seeding: Since my DBs are large (around 160GB each), it won't be convenient to seed over the WAN so I'm planning to copy the DBs to external hard drive, then I’ll transport the external hard drive to DR Site so we can copy over the DBs to SCR target server.

       

      The Details:

       

      1.              Copy over DBs to External Hard Drive: To avoid down time, instead of dismounting the DBs, we will use the Update-StorageGroupCopy to perform the seed, and we will include the -TargetPath parameter, to specify an alternate path for the seed. In this case the alternate path will the external hard drive. Scott Schnoll suggested this procedure in this blog: http://www.mombu.com/microsoft/exchange-server-clustering/t-scr-seeding-3045693.html

       

      2.              Once DBs are copied to external Hard Drive, we will send out the drive to DR Site in order to copy DBs to SCR Target machine

       

      3.              Suspend or put on hold Exchange Backups to avoid logs being truncated

       

      NOTE: Since it will take a couple of days to get the copy of DBs to DR Site and copy them over to SCR Target machine, we will put on hold the Exchange backup to avoid the logs being truncated. Once we enable the replication from Production site, then the logs will get replicated to the SCR Target.

       

      4.              Copy the DBs to the Target SCR to the corresponding path (same as source server paths).

       

      NOTE: Since the requirement is that the SCR Target must have the same disk layout as the SCR Source for a given storage group, I have manually setup on the SCR Target all the appropriate folder paths to match those on the SCR Source.

       

      5.              Once DBs are copied to SCR Target machine, we will enable SCR replication using Enable-StorageGroupCopy -identity Storagegroup -standbymachine TargetServerName

       

      6.              Once we verify everything is working OK, we will resume the Exchange Backups

      Am I missing anything important in the steps above?

       

      QUESTIONS

       

      1.     As indicated in my plan above, I’m starting with the manual copy of the DBs to external Drive and then to SCR Target. At this point I have not enable SCR

       

      Is this OK or do I necessarily need to enable SCR before the manual seeding?

       

      2.     I created the same folder structure on the SCR Target to match the same folder paths as those on the SCR Source. I will manually place/copy the DBs in the appropriate folder in the SCR Target

       

      What happens when I enable SCR after the DBs are manually copy on the SCR Target?

       

      The theory says that when you enable SCR on a particular storage group, Exchange starts replicating the logs to the target SCR server, then the database will be created in the SCR target after 50 logs are created in the SCR source and after the replaylagtime parameter is reached.

       

      Is Exchange going to attempt to seed the DBs once I enable SCR?

       

      Is Exchange going to try to over-write the DBs I manually copied to the SCR Target?

       

      Is Exchange intelligent enough to realized that the DBs have been manually copied (seeded) to the SCR Target and will not try to over-write them or create the DBs again?

       

       

      Unfortunately I don’t have the available resources to setup this in a Lab environment to test myself so I would appreciate your comments if you have already done this. Thanks in advance for your feedback!

       

       FT

       

       

       

       

       

       

        

       

    All Replies

    • Wednesday, September 23, 2009 6:39 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote
      Hi ,


      http://social.technet.microsoft.com/Forums/en-US/exchangesvravailabilityandisasterrecovery/thread/7ea45ba2-eb33-44b8-b59c-edea7d5cc39b


      This definatly helps you.

      Regards
      Syed Arsalan.

      syed.arsalan
       
    • Wednesday, September 23, 2009 8:08 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Added to the above comments..

      SCR has some difficulties with Exchange 2007 Roll-Up 5, make sure you have atleast Roll-Up 7 for Exchange 2007 on target and Source.

      http://msexchangeteam.com/archive/2009/03/18/450863.aspx

      Thanks
      Hari

       
    • Wednesday, September 23, 2009 11:22 PM
       
        Has Code
      Sign In to Vote
      0
      Sign In to Vote

      Hi,

       

      Thanks to Syed and Hari for their feedback!

       

      Syed, thanks for sending the link

       

      Hari, Thanks for the recommendation. I have already applied Rollup 9 to both: source and target so they are up to date

       

      One more question, if you don’t mind.

      Today I run a quick test as I wanted to make sure that the Update-StorageGroupCopy using the -TargetPath parameter is going to help me to seed the Databases to an external storage device (NAS) so that I can send our the external device later to DR Site

       

       

      1.      Created a test Storage Group called: DRPTEST

      2.      Created a test DB called: DRPTEST_Store.edb

      3.      Created a test account on new test DB

      4.      Suspended Replication

      5.      Issued the following cmdlet:

       

      Update-StorageGroupCopy –Identity DRPTEST -TargetPath \\192.168.1.101\share\DRPTEST

       

            I also tried:

       

      Update-StorageGroupCopy –Identity ServerName\DRPTEST -TargetPath \\192.168.1.101\share\DRPTEST

       

       

      But I got the following error message:

       

      Update-StorageGroupCopy : Cannot bind parameter 'TargetPath'. Cannot convert value "\\192.168.1.101\share\DRPTEST" to type "Microsoft.Exchange.Data.L

      ocalLongFullPath". Error: ""\\192.168.1.101\share\DRPTEST" is not an acceptable path. An acceptable path is either an absolute, local, or long file path and does not contain '~'.

      Parameter name: path"

      At line:1 char:67

      + Update-StorageGroupCopy -Identity AC-EXCHANGE1\DRPTEST -TargetPath  <<<< \\192.168.1.101\share\DRPTEST

       

      I’m trying to copy the DB to an external NAS storage device that was assigned the private IP: 192.168.1.101 so I guess my issue is that Exchange does not see the NAS box as a <LocalLongFullPath>]

       

      Do you think this is my issue? Does the error message mean that UNC path is not acceptable in this case? Any work around? Please advice!

       

       

      According to this KB: http://technet.microsoft.com/en-us/library/aa998853.aspx

       

      This is the syntax:

      Update-StorageGroupCopy -Identity <StorageGroupIdParameter> [-Confirm [<SwitchParameter>]] [-DataHostNames <String[]>] [-DeleteExistingFiles <SwitchParameter>] [-DomainController <Fqdn>] [-Force <SwitchParameter>] [-ManualResume <SwitchParameter>] [-StandbyMachine <String>] [-TargetPath <LocalLongFullPath>] [-WhatIf [<SwitchParameter>]]

       

       

      The TargetPath parameter specifies the location for the database file on the local computer. This is the directory that will contain the database. The last part of the path is determined by the source's base name.

      The TargetPath parameter is used to seed a database to a path that is different from the configured location for the passive copy of the database. For example, when you have an SCR target in a remote physical location, you can use the TargetPath parameter to perform the update locally on the SCR source, and then use a copy utility that provides data compression to move the copy over the network to the SCR target computer.

       

       
    • Thursday, September 24, 2009 4:53 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote


      please  try to access from run prompt from the scr source ( i think you have to share the folder and give accurates rights that is mentioned below)

       \\192.168.1.101\share\DRPTEST and
      • Share Name: <Storage Group GUID>$
      • Folder Path: <drive>:\<Storage Group Log Folder Path>
      • Share Permissions: <root domain>\Exchange Servers – Read
      • Folder Permissions: <root domain>\Exchange Servers – Read, <computer>\Administrators – Full Control, SYSTEM – Full Control
        Cc535020.note(en-us,EXCHG.80).gifNote:
        Although files can be listed and copied, when you view the share via Windows Explorer, you will see that the Exchange Servers security group does not have the 'Read' permissions checkbox checked. This is due to an access flag not being set.

      Depending on the environment, the SCR target's service will connect using a particular namespace.

      • The Replication service on the CCR passive node always connects to \\nodenameActive to pull logs to the passive copy.
      • The Replication service on the SCR target, when connecting to a CCR source environment, connects to \\nodenameActive to pull logs to the SCR target.
      • The Replication service on the SCR target, when connecting to a SCC source environment, connects to \\CMSName to pull logs to the SCR target.
      • The Replication service on the SCR target, when connecting to a standalone mailbox server, connects to \\ServerName to pull logs to the SCR target.

      Regards
      Syed Arsalan.

      syed.arsalan
       
    • Friday, September 25, 2009 5:47 AM
       
       
      Sign In to Vote
      0
      Sign In to Vote

      Syed,

      Thanks for your reply! No matter what I do it does not work. At this point I'm not quite sure if I'm not typing in correctly the syntax of the absolute, local, or long file path  

      In the mean time I can go with plan B...dismounting the DBs to copy over the DBs to external NAS Storage Unit

      On another note, I was also considering the -SeedingPostponed parameter with the Enable-StorageGroupCopy. Actually I run a test today with it:

      1. Created a Storage Group called: DRPTEST and a DB called DRPTEST_Store
      2. Created the same file structure in SCR Target to mach that in SCR Source
      3. Enable SCR on the DRPTEST Storage Group using the following parameters:

      Enable-StorageGroupCopy –Identity DRPTEST -StandbyMachine AC-EXCHANGEDRP –ReplayLagTime 0.0:15:0 –TruncationLagTime 0.0:15:0 -SeedingPostponed

      4. On the SCR Target I checked the Event Viewer Application Logs and looked for event ID 2114. It indicated that the replication instance for storage group DRPTEST started copying the transaction logs
      5. Issued Get-storagegroupcopystatus as shown below, the DRPTEST Copy Status shows as Initializing
      6. Issued Test-ReplicationHealth to verified the Replication Health…all Passed
      7. After a few minutes, the logs started showing up in the appropriate path on the SCR Target
      8. After checking the Database location, I was surprised to see that the database had been created!!!! EVEN THOUGH I specified the –SeedingPostponed parameter!!!

      So for some reason, the –SeedingPostponed did not do its job! Now, that was part of my concern and that’s why I was planning to seed the SCR target before enabling SCR on my production storage groups. I don’t want the databases to be seeded over the WAN as they are too large (160GB)

      I guess at this point I will run another test but this time I will manually seed the DB on the SCR Target and then enable SCR. This makes me go back to my original questions as I don’t have answers yet:

      a. After I manually seed the SCR, Is Exchange going to attempt to seed the DBs once I enable SCR?

      b. Is Exchange going to try to over-write the DBs I manually copied to the SCR Target?

      c. Is Exchange intelligent enough to realize that the DBs have been manually copied (seeded) to the SCR Target and will not try to over-write them or create the DBs again?

       

      Thanks!