Now that we have used database portability to recover a database that has been replicated by Standby Continuous Replication (SCR) I want to move onto one of the 2 remaining methods utilizing the /recoverServer switch.

There are many different scenarios we can come up with related to recovering Exchange 2007 but I will keep this basic for the blog.

TEST:
Configure 2 standalone mailbox servers which use Standby Continuous Replication (SCR) and the source server has a catastrophic problem that renders it useless. I will then run setup /recoverserver on the scr target machine to bring our Exchange server online.

Environment:
1 Windows 2003 SP2 DC/GC
1 Exchange 2007 CAS/HUB
2 Exchange 2007 MAILBOX SERVERS

Lets start by identifying information about using the /recoverserver switch
http://technet.microsoft.com/en-us/library/bb123496.aspx

When do we want to use this?
When a server has been completely lost and we want to bring the SCR target online with the same name to midigate client configuration.

Lets begin:

I currnetly have 2 mailbox server VMmbx1 and SCRTarget

I hope this is not confusing but SCRTarget will be the source and VMmbx1 will be our target.

Our first step is to Enable SCR replication
Enable-StorageGroupCopy -StandbyMachine vmmbx1 -ReplayLagTime 0.0:5:0 -TruncationLagTime 0.0:10:0

The above command enabled replication from our source SCRTarget to the replica VMmbx1

Now that the logs have been replicated and the database seeded I will turn off my Exchange server called ScrTarget and perform a recovery on VMmbx1

Start the Recovery Process

we start by using the restore-storagegroupcopy command
Restore-StorageGroupCopy -Identity scrtarget\recover -StandbyMachine vmbx1 -Force

**Note we had to use the -force switch since the source system has been powered off **

Next we need to uninstall exchange from our target server this can be done from the gui or command line, I will use the command line here to uninstall Exchange

I have my Exchange binaries located D:\177.3

From the target server VMmbx1 I need to remove Exchange so that I can run setup /recoverserver

D:\177.3>Setup /M:Uninstall

3. Reset ad account

Most documentation I found states you only need to reset the computer account before we change the name, when I did my testing I had to remove the computer account before it would allow me to change the name of my server.

**Note if you have to remove the computer account you will need to add it to the Exchange Server and Exchange Install Servers group after the reboot and a new computer account is created **

4. Rename server

5. After changing the server name we need to reboot the server

6. Next we need to run setup /recoverserver

D\177.3> setup /recoverserver

This will start the Exchange recovery install and bring our original source server back online.

**Note The logical drive structure should be the same **

If the database does not mount (most likely will not) we need to use eseutil to recover the database.

lets check to see if we have a clean shut down.

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

notice we have Dirty Shutdown and will need to recover the database

We now need to run Eseutil /R to recover the database

ESEUTIL /R E00(Zero Zero or whatever the logs file leads with) /l D:\SCR\SG2\Logs /S D:\SCR\SG2\Data

Notice we recieve an error which requires us to add the /a switch to recover the database

After the repair has run lets check our database status.

ESEUTIL /MH d:\scr\sg2\data\vmmbx1-sg2-db1.ed

We now have a clean shutdown of our database

Lets attempt to mount the database

We can see that our database mounted and we have the same server danme so no client configuration would need to change.

If we look at our recipient configuration we can see that our mailboxes confirm they still remain on SCRTarget.

We see our user Jodie Bartos mailbox belongs to Scrtarget

Lets attempt to logon to her mailbox via OWA and Outlook 2007 to see if we have any problems.

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
http://technet.microsoft.com/en-us/library/bb125195.aspx

CCR – Cluster Continuous Replication
http://technet.microsoft.com/en-us/library/bb124521.aspx

Since the Beta 2 release of Exchange 2007 SP1 SCR functionality has been included in the product. http://technet.microsoft.com/en-us/library/bb676502.aspx.

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
D:\SCR\SG1\Data
D:\SCR\SG1\logs
D:\SCR\SG2\Data
D:\SCR\SGs\logs

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 ( http://technet.microsoft.com/en-us/exchange/bb330849.aspx.) 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)
http://technet.microsoft.com/en-us/library/bb691321.aspx.

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

Important:
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*

http://exchangeis.com/blogs/exchangeis/archive/2007/04/30/eseutil-r-soft-recovery-a-quick-and-simple-tutorial.aspx

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:

Mount-Database SCRTarget\RECOVER\RECOVERDB

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.