Prerequisites for Exchange 2007 SP1's SCR

Both source and target servers must run Exchange 2007 SP1. SCR is available with the Standard Edition of Exchange 2007 SP1, but you need the Enterprise Edition if you want to use SCR with clusters. You can use different editions of Exchange on source and target servers. For example, the source can run the Enterprise Edition while the target runs the Standard edition or vice versa. Remember that the Standard Edition supports only up to five storage groups (SGs) whereas the Enterprise Edition supports up to fifty, so make sure you don't exceed the supported number of SGs on a server when you need to switch to a target server.

The servers must run the same version of Windows (including service pack level). For instance, if you run Windows Server 2008 on a source Mailbox server, you must run Server 2008 on the target server. This requirement is especially important for clustered servers because you manage clusters differently in Server 2008 and Windows Server 2003.

The data paths for the database and logs must be the same on both source and target server. Exchange stores the data path information in Active Directory (AD) but doesn't provide an option to update the data paths through Exchange Management Console. If you need to update paths—for example to move a target database to a more high-performing disk and put it into production using Exchange 2007's database portability feature—you can do this with the Move-StorageGroupPath and Move-DatabasePath PowerShell commands through Exchange Management Shell.

The SG that you want to replicate can contain only one database.

The target server must be configured for the Mailbox server role.

The target and source servers must be in the same AD domain but don’t have to be in the same site.

You must have sufficient network connectivity between source and target servers to transport the expected volume of transaction logs that SCR replicates. Sufficient bandwidth for this purpose means that the target server is able to pull logs as quickly as they accumulate on the source server so that a large queue of logs doesn't build up for the Microsoft Exchange Replication Service to process. The logic here is that any queued log represents a potential loss of data if you have to switch databases.