Exchange Sample Configurations & Best Practices

Peer DRS Help > Replication Modules > MS Exchange Server > Exchange Sample Configurations & Best Practices

Peer DRS can be configured in numerous ways based on your needs and your environment. Below are some best practices and the most common configurations along with sample job configuration data and requirements:

Exchange Replication Best Practices

Most small to medium sized businesses will have a single Exchange server and will more then likely only need one standby target. In order to make job configuration and permission setup easier to deploy and more secure, we recommend that you install Peer DRS on the Target Exchange server. This configuration will eliminate the need to use administrative shares to the target, and you won't need to run Peer DRS under an account with Domain Administrative permission.

2.	Whenever possible, try to avoid running Peer DRS on the primary Exchange server. Running the application on another machine, or the target Exchange server will off load processing and will have negligible impact on the primary Exchange server.

If your Exchange databases are extremely large or space is a concern, then we recommend that you limit the number of duplicate copies of full database backups and transaction logs files. In addition, it will speed up the target recovery process by eliminating an extra potentially large network file copy to a Target File Copy Destination Folder. If the machine that Peer DRS is running on has direct access to the shared backup directory and you don't require a second backup copy of the primary database files, then you should set the Target File Copy Destination Folder to the same folder as the Backup Folder. In addition you should set the backup file retention time to a value that suits your needs.

Peer DRS Exchange data sources are configured on a per storage group basis and all Exchange databases belonging to that storage group will be backed up as a single job. Therefore, a storage group's transaction logs will contain transactions for all databases in the storage group. Whenever possible, we recommend having no more than one database per storage group. This will result in smoother backup and restore(s) and will isolate each job to a single database and it's transactions. There is nothing wrong with replicating storage groups containing multiple database, but less can go wrong during the restore process and errors with one database will not effect another.

5.	We recommend you configure all target Exchange server data file paths identical to the primary Exchange servers. These include the storage group transaction log paths, database file paths and Exchange system paths.

We recommend setting you incremental backup schedule to a "Continuous" which continuously copies transaction log files in near real-time as they are committed to disk. Exchange transaction log files are 5MB in size for Exchange 2000 & 2003 and 1MB for Exchange 2007 which means that you will be no more then 5MB or 1MB, respectively, out of synch with the primary database. If you have a low volume sight and 5MB changes do not occur very often, we recommend combining continuous incremental backups with email alerts. If you set the "Send email alert if no backup occurs within" value to a small increment, let's say 1 hour, and have enabled continuous replication, then an incremental backup will be automatically performed if no backup has occurred within a 1 hour time period. This gives you the best of both worlds, i.e. continuous verse scheduled. See requirement #10 for restrictions and requirements for running continuous replication.

Since performing full backups have minimal impact on the primary Exchange server, we recommend you perform full backups as frequently as possible based on the size and time it takes a full backup to run in your environment. Ideally, you should perform full backups on a recurring basis throughout the day.

We strongly recommend performing Log Replay testing at least once after configuring a new replication job to make sure your target is correctly configured for recovery, and will subsequently lead to less problems if you should need perform recovery/failover of the target. You can perform this operation at any time via the Target Database Operations menu item.

Peer DRS Installation on Target Exchange Server (Best Practice #1)

Peer DRS is installed on the same server as the Target Exchange server and the target server has two configured local drives, C: and D: This example has the shared backup folder located on a local drive on the target, but you could also use a network share located on a different machine or on the Primary Exchange server, or some other NAS device. In any case the domain user account that Peer DRS is run under must have read-write access to the shared backup folder.

Below is a diagram depicting a typical environment where the Peer DRS is installed on the target Exchange servers along with a sample job configuration and requirements:

exchange_config_target

Primary Exchange Server	ExchangeA
Primary Exchange Storage Group	SG1
Primary Exchange Database	Mailbox Store 1
Primary Database Path for Mailbox Store 1	C:\Program Files\Exchangesrv\mdbdata

Target Exchange Server	ExchangeB
Target Exchange Storage Group	SG1
Target Exchange Database	Mailbox Store 1
Target Database Paths for Mailbox Store 1	C:\Program Files\Exchangesrv\mdbdata
Target Log Replay Folder	C:\DRS\LogReplay
Shared Backup Folder (on target)	D:\PeerDRS\Backup\ExchangeA

Peer DRS Server	ExchangeB
User Peer DRS service is running under	PeerDRS

Peer DRS Replication Job Configuration
Network Path to Backup Folder	D:\PeerDRS\Backup\ExchangeA
Primary database local path to Backup Folder	n/a
Target destination folder for copied files	D:\PeerDRS\Backup\ExchangeA
Target server local path to copied files	n/a
Target Log Replay Folder	C:\DRS\LogReplay
Target server local path to log replay folder	n/a
Target Exchange Database file path used: (this is not configurable and based on actual Exchange data file locations)	C:\Program Files\Exchangesrv\mdbdata

Requirements

A.	Domain user account PeerDRS must have domain Backup Operator and Full Exchange Administrator privileges

B.	Domain user account PeerDRS must have read-write access to local paths, C:\Program Files\Exchangesrv\mdbdata, D:\PeerDRS\Backup\ExchangeA, C:\DRS\LogReplay

C.	ExchangeB must have TCP/IP access to ExchangeA and be on the same domain.

D.	MS Exchange Server must be installed on ExchangeB with storage group SG1 and database Mailbox Store 1 configured and dismounted.

E.	The account that the target Exchange information store process is running under (default is local system account) must have access to C:\DRS\LogReplay.

F.	If you want to utilize continuous, real-time replication then the PeerDRS user account must have read-write access to administrative network share: \\ExchangeA\C$\Program Files\Exchangesrv\mdbdata. This usually required granting domain level Administrator rights to this user.

Remote Centralized Installation

Peer DRS is installed on a separate server from the primary and the target Exchange server's name is BackupSrv. This shared backup folder is located on the BackupSrv host on local drive D:\PeerDRS\Backup\ExchangeA. The target File Copy Destination folder is the same and the Backup Folder and therefore no extra file copies will occur. The main difference in this configuration is that administrative shares on the target must be configured and accessible by the domain account that Peer DRS is running under.

Below is a diagram depicting a typical environment where the Peer DRS installation is centralized on a separate server from the primary and target Exchange servers along with a sample job configuration and requirements:

exchange_config_remote

Primary Exchange Server	ExchangeA
Primary Exchange Storage Group	SG1
Primary Exchange Database	Mailbox Store 1
Primary Database Path for Mailbox Store 1	C:\Program Files\Exchangesrv\mdbdata

Target Exchange Server	ExchangeB
Target Exchange Storage Group	SG1
Target Exchange Database	Mailbox Store 1
Target Database Paths for Mailbox Store 1	C:\Program Files\Exchangesrv\mdbdata
Target Log Replay Folder	C:\DRS\LogReplay

Peer DRS Server	BackupSrv
User Peer DRS service is running under	PeerDRS
Shared Backup Folder (on BackupSrv)	D:\PeerDRS\Backup\ExchangeA

Peer DRS Replication Job Configuration
Network Path to Backup Folder	D:\PeerDRS\Backup\ExchangeA
Primary database local path to Backup Folder	n/a
Target destination folder for copied files	D:\PeerDRS\Backup\ExchangeA
Target server local path to copied files	n/a
Target Log Replay Folder	\\ExchangeB\C$\DRS\LogReplay
Target server local path to log replay folder	C:\DRS\LogReplay
Target Exchange Database file path used (this is not configurable and based on actual Exchange data file locations)	\\ExchangeB\C$\Program Files\Exchangesrv\mdbdata

Requirements

A.	Domain user account PeerDRS must have domain Backup Operator and Full Exchange Administrator privileges.

B.	Domain user account PeerDRS must have read-write access to local path D:\PeerDRS\Backup\ExchangeA

C.	Domain user account PeerDRS must have read-write access to administrative network shares: \\ExchangeB\C$\Program Files\Exchangesrv\mdbdata, and \\ExchangeB\C$\DRS\LogReplay. This usually required granting domain level Administrator writes to this user.

D.	BackupSrv must have TCP/IP access to ExchangeA & ExchangeB and be on the same domain.

E.	MS Exchange Server must be installed on ExchangeB with storage group SG1 and database Mailbox Store 1 configured and dismounted.

F.	The account that the target Exchange information store process is running under (default is local system account) must have access to C:\DRS\LogReplay.

G.	If you want to utilize continuous, real-time replication then the PeerDRS user account must have read-write access to administrative network share: \\ExchangeA\C$\Program Files\Exchangesrv\mdbdata. This usually required granting domain level Administrator writes to this user.