A. While it's quite easy to run the Enable-StorageGroupCopy cmdlet to enable a SCR replica of a database, actually activating a replica copy is a very different story.
When you activate an SCR replica of a standalone source (not in a cluster), you use database portability to mount the replicated database on the target server then update Active Directory (AD) with the new database location and update the mailboxes to point to the new server.
When you activate an SCR replica of a clustered source, you want to use the RecoverCMS capabilities of the Exchange Server setup.com on the target. Because you specify the same CMS name as the source, you must delete the existing DNS record, because the security on the record would stop your new cluster from replacing it. This type of activation is simple and you don't need to reconfigure AD user objects.
If your replica is part of a cluster your task is simple, but you have a challenge ahead if you have a source that's clustered. The preferred activation is via RecoverCMS, but that's only possible if you're running on a server that's installed as a passive mailbox server role in a failover cluster. This means you need the SCR target to actually be part of a cluster. To meet this requirement, it's very common to configure this target box as a single node cluster to get the options you need to install as a passive mailbox server through Exchange and then use the RecoverCMS method of activation.
If the target of a clustered source isn't a passive mailbox server, activation requires a lot of manual steps. Basically, you uninstall and reinstall Exchange. So when you're planning out your SCR deployment, make sure your SCR target is architected correctly based on the source.
Microsoft offers step-by-step instructions on replica activation. The company also has a page with more information on RecoveryCMS.
Related Reading:
Videos:
Check out hundreds more useful Q&As like this in John Savill's FAQ for Windows. Also, watch instructional videos made by John at ITTV.net.
Register
