thanks..

Thanks Scott for the time to do these videos, I'm a little confused though, have you written a technicle guide, or even a dummy guide for people like me :) explaining all the steps on why and how what needs to be done when the source database is corrupt and you want to start using the target database as the production database, as well as then getting the other database fixed and having SCR enabled again? Thanks very very much Musto

Here are some observations: (1) As explained in video 2 of this series, when you set up SCR, your disaster recovery (DR) machine may NOT define (confirm in Exchange Management Console) the same Storage Group *name* (e.g. First Storage Group) OR database *name* (e.g. Mailbox Database) as the production machine. If you defined them with the same names anyway on the DR machine, remove them from that DR machine. Don't expect to use those names EVER again ANYWHERE, even on the SCR target after recovery (see below). (2) When you set up SCR with something like: update-storageGroupCopy –Identity “EX01\First Storage Group” –StandbyMachine EXDR01, the servers are basically just running a file-level sync (MS calls this "replication") of the source SCR directory (e.g. c:\program files\microsoft\exchange server\mailbox\first storage group\") to the target SCR directory (also at c:\program files\microsoft\exchange server\mailbox\first storage group\"). BUT, notice that the target Exchange software knows NOTHING about that directory or its files (no defined storage group for it, no defined database name for it), whereas the *SCR software* knows ALL ABOUT IT, since it copied the files. (3) Scott is using "database portability" (basically telling Exchange to mount any .edb file) by pre-creating a differently-named storage recovery group (see video 2) called sg1port and its database mbx1port.edb, then immediately deleting their resulting (and intentionally blank) .edb and other files IN ORDER TO LATER, during recovery, tell Active Directory, "Hey, remember sg1port and mbx1port.edb? Well, oops! So, sg1port is the right storage group name, but its database folder is actually located at the SCR target location and its database file is there too, called mbx1.edb." (4) This means that on the DR machine, you NEVER, not even during recovery, use the original storage group's name! Instead, you use an alternate storage group name (sg1port not sg1) whose folder and files (principally mbx1port.edb) are located at the SCR target location. If you activate an SCR target, it will STILL be called sg1port, NOT sg1! In short, Exchange and Windows seem unforgiving about hardware and naming, so plan accordingly!

Quick clarification on my previous post: "Instead, you use an alternate storage group name (sg1port not sg1) whose folder and files (principally mbx1port.edb) are located at the SCR target location." SHOULD READ "Instead, you use an alternate storage group name (sg1port not sg1) whose folder and files (principally the mbx1port "database" located in file mbx1.edb) are located at the SCR target location."