We help IT Professionals succeed at work.

Check out our new AWS podcast with Certified Expert, Phil Phillips! Listen to "How to Execute a Seamless AWS Migration" on EE or on your favorite podcast platform. Listen Now


Exchange 2007 SCR question

Medium Priority
Last Modified: 2012-05-07
I just had a question about Exchange 2007 Standby Continuous replication....I want to enable SCR but when i give the command

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

Now, the above command requires the source Exchange Server to be dismounted (or disconnected from network) to work; will not work otherwise  ... I was under the impression that in case of failure I only need to give the following command

Get-Mailbox -Database vmmbx1 ... | where ... | move-mailbox

But now I think I need to give all the commands starting from

1. Restore-StorageGroupCopystatus
2. Use Eseutil utility
3. Move storagegroup path and movedatabase path
4. Setmailboxdatabase and mount and finally the get-mailbox-cmdlet ...

So Am I doing all these steps 1-4 in case of failure (because I certainly cant give restore-storagegroupcopystatus command) as long as the primary exchange doesnt go down ... So thats the confusion ... Do I give all 4 commands or just the last command of get-mailbox-cmdlet ...

Sorry if i cant make it clear, let me know in case anything is unclear !
Watch Question

you shouldn't need to dismount the database, especially since it should be down for SCR to be enabled...

Here is a real life example:

Are you clustered? or do you have single standby unit?


single standby unit ...

exactly right, i wont need to dismount the database since the server will be down ... But what I wanted to know was only when my Primary Exchange server dies, then I need to give all those commands (mentioned in steps 1 - 4) in my post above .... I thought that I only needed to give the last command i.e. get-mailbox-cmdlet ...  but it turns out that I have to give all those commands, right ?
err, no..

in a cluster, the database is replicated, so not needed, however a standby unit is not, so recover database or database portability is required.

Essentially, what your doing is just updating the Schema and DNS to point the service to the new server...

So, if you use Mailbox recovery, the eseutil shouldnt be needed as the service replays the log files from the SCR commands redirect.



and whats the recommendation on which method of SCR to use

Database Portability or RecoverServer method ???

I used the database portability method in my testing ...

thanks for ur help !
both are ok, just depends on your requirements.

If you using Database portability, you should move, then, and only if dirty, use eseutil to recover.


hmmm....ok..i read the link above...typical example of database portability method...

but in my case, am suspecting the primary exchange server itself to go down ... i mean database portability would still work in that scenario, right ?
since the database is not stored on that machine itself, the idea is that you could enable a standby server to take over that service and use that database..

However, you are right with the recovery option on eseutil as if the outage caused a corruption, you would need to repair before starting the service..


sorry, i just got confused with ur answer ...
my query was simply whether database portability would be a good enough option to use even if the server (primary exchange) would be dead ? or should I use recover server option instead ?
Unlock this solution and get a sample of our free trial.
(No credit card required)


The reason being that I never got a straightforward answer to my straigh forward question ..... rather
Unlock the solution to this question.
Thanks for using Experts Exchange.

Please provide your email to receive a sample view!

*This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.


Please enter a first name

Please enter a last name

8+ characters (letters, numbers, and a symbol)

By clicking, you agree to the Terms of Use and Privacy Policy.