Part 1 Standalone Server to Standalone Server using Database Portability

Exchange 2007 SP1 has added some additional functionality to Exchange 2007. A new featured called Standby Continuous Replication (SCR) provides the ability that is similar to CCR and LCR but expands the limits of those two technologies.

Lets define LCR and CCR and see how SCR expands upon them:

LCR – Local Continuous Replication

CCR – Cluster Continuous Replication

Since the Beta 2 release of Exchange 2007 SP1 SCR functionality has been included in the product.

What can SCR do for me?
SCR allows an Exchange Admin to replicate a copy of a Storage Group to a number of remote servers. Microsoft recommends a max of 4 target machines.

An SCR Source can be an LCR,CCR,SCC, or Stand alone mailbox server but requires only 1 Database per Storage Group which is already a requirement for LCR and CCR.

The target can be on the same subnet or in a remote datacenter unlike CCR which currently requires both nodes be on the same subnet (this will change with Windows 2008)

SCR requires manual intervention to bring the remote server(s) online, this solution is not an instant on scenario.

Lets start to work with SCR……

Scenario 1 – Stand alone MBX server Source -> Stand alone MBX target
Lab Environment:
1 Windows 2003 SP2 DC
1 CAS/Hub Running Exchange 2007 SP1 Beta 2 build 177.3
2 MBX server Running Exchange 2007 SP1 Beta 2 build 177.3

There are only a few requirements for SCR:
1. the paths must be the same for both machines
— If source server is c:\Server1\Data and C:\Server1\Logs then these paths must be available on the target server.

2. There is a hard coded 50 log lag between the Source and Target
— by default there is a 24 hour replay time which is configurable.
3. There can be only 1 database per storage group
4. The target server must have Exchange mailbox role installed, if this is a cluster it will be install as a passive node.

5. The target server must be in the same Active Directory domain

On my source mailbox server I have created 2 storage groups with 1 database each

**Note the Path to the DB and logs are as follows

To enable SCR replication we need to open EMS and run the following command:
Enable-StorageGroupCopy -identity Storagegroup -standbymachine TargetServerName

** I also ran this command for SG2 and added some additional switches**

After a few moments the same path is created on the remote server seen below.

** There are some new switches to the Enable-StroageGroupCopy command in SP1 related to SCR replaylagtime and TruncationLagTime.

Replaylagtime- Time that the Microsoft Exchange Replication Service should wait before replaying logs. Default is 24 hours and max time is 7 days.

TruncationLagTime- Amount of time Microsoft Exchange Replication Service waits before truncating log files that have been copied to the target

We can validate this by running:
Get-storagegroupcopystatus -standbymachine TargetServerName
** note it take a few minutes to get the replication started **

now that replication has started and is healthy lets take a look at our target server logs folder:

I then used Loadgenerator ( which can be downloaded from MS to generate some logs file on my machine so I could get past the hard coded 50 log lag before the replay started.

You can see a copy of the database has been created on my target server

To bring an SCR replica online there are 3 options:
(Search the help file for “Activating Standby Continous Replication Clusters)

1. Database Portability
2. Recover CMS (for clusters only)
3. RecoverServer

Now that we have setup replication we are going to use database portability to bring these 2 databases back online on are target server.

Lets start by creating a new storage group and database on our target server
* Note this path will be different then the destination of replica *

As you can see below I chose to locate the logs D:\SCR\Recover\logs and systemfiles D:\SCR\Recover\Data

I have placed the database D:\SCR\Recover\Data

After the database has been created, mount it one time and then dismount the database.

Now we need to dismount our current source database
**Note if the source has crashed or is offline you can skip this command*

Dismount-Database vmmbx1\vmmbx1-sg2\vmmbx1-sg2-db1

Now we must make the scr target database mountable with the Restore-StorageGroupCopy cmdlet

Restore-StorageGroupCopy vmmbx1\vmmbx1-sg2 -StandbyMachine Scrtarget -force

If the SCR source is not available, the Force parameter must be added

Before we can bring the target database online we need to verify that the database is in a cleanshutdown state.

To do this we will use ESEUTIL (by deafult this is located in the (systemdrive)c:\program files\microsoft\Exchange Server\Bin directory)

Open a command prompt:
ESEUTIL /MH d:\scr\sg2\data\vmmbx1-sg2-db1.edb (path to edb file)

*Note we have a State of “Dirty Shutdown” and must repair our edb file*

If the db shows dirty we will need to do a recovery with ESEUTIL /R to get the state to Clean
ESEUTIL /R E01 (Zero Zero or whatever the logs file leads with) /l D:\SCR\SG2\Logs /S D:\SCR\SG2\Data

** Note you may receive an error about lossy failover and need to a the /a switch as seen in the screenshot above**

Now we need to modify our command with the /a switch
ESEUTIL /R E01 (Zero Zero or whatever the logs file leads with) /l D:\SCR\SG2\Logs /S D:\SCR\SG2\Data /a

Now lets check our state with ESEUTIL /MH again and you see we are now in a “Clean Shutdown”

Now we need to move the Storage Group info of our Temp SG to the location of the replicated logs

Move-StorageGroupPath Target\SG -SystemFolderPath D:\SCR\SG2\Data -LogFolderPath D:\SCR\SG2\logs -ConfigurationOnly

Now we need to move the Database info of our Temp DB to the location of the replicated database

Move-DatabasePath Target\TempSG\TempDB -EdbFilePath D:\SCR\SG1\DATA\vmmbx1-vmmbx1-db2.EDB -ConfigurationOnly

**Note the edb file is the name of the replicated edb file**

Now we have to set the DB to be overwritten this can be done in the gui or from EMS, since we are at the command line I will use EMS:

Set-Mailboxdatabase SCRTARGET\RECOVER\RECOVERDB -AllowFileRestore:$true

Lets attempt to bring the database onilne:


We can now see that our database has been brought online and we are only 1 step away from giving the client access again!

After the database is mounted, the user mailboxes homed on the SCR source database must be re-homed to theTarget Server

Get-Mailbox -Database vmmbx1\vmmbx1-SG2\vmmbx1-sg2-db1 ¦ where {$_.ObjectClass -NotMatch ‘(SystemAttendantMailboxExOleDbSystemMailbox)’} ¦ Move-Mailbox -ConfigurationOnly -TargetDatabase SCRTarget\Recover\recoverdb

You will see the user configuration being moved to the new location

Clients should now be able to access their mailbox depending on several factors:

Active Directory replication latency
CAS server has been updated with the correct information
OL 2007 will use autodiscover to find the mbx
However OL 2003 will not automatically configure the client unless the old server is still online and can be contacted.

Let look in the gui and see the db location of some of our users

We can see that our user now show that their mailboxes belong to our Recover Database

Let logon to OWA to validate the users can access their email

The screen shot below showthe users logon information from OWA– Selection Options-About

We can see our mbx is on the new server SCRTarget and OWA logon was successful

Lets logon with Outlook 2007 and see if it connect and finds the correct mailbox

We have now successfully recovered our users using Exchange 2007s newest feature Standby Continuous Replication.

I want to note that many of the tasks above can be added to a script so that only 1 command has to be run which will rapidly improve recovery time.

august movie crew stone cold college movie tracey fragments the movie release shutter horror movie mr hobbs takes a vacation movie site chop shop movie title zoolander bolt the movie star wars the clone wars tinkerbell movie teacher the movie credits fugitive pieces closer movie