arcserve-KB : How to troubleshoot slow outlook connectivity

Last Update: 2014-10-31 11:32:56 UTC


Description: This article explains how to troubleshoot slow outlook connectivity issues during synchronization stage.


Outlook connectivity issues are likely caused by high I/O when RHA is reading data during sync. During the block sync comparison RHA compares root directories from different drives in parallel. Reading many files in parallel can impose a serious overhead on the server.  This  can be controled  by the following parameter in ws_rep.cfg file.

 EnableParallelFileSnapshot = True

Enables parallel processing.  By default, this option is enabled and root directories on different volumes are compared in parallel. Root directories on the same volume, by default, are processed sequentially - one file snapshot per volume at a time.


MaxParallelFileSnapshot = -1

Defines how many root directories on different volumes can be compared in parallel. The default value -1 sets parallel processing level to unlimited. Data on all synchronized volumes can be compared simultaneously.  By setting this parameter to a positive number you can limit the number of volumes to be processed at a time. This can help to reduce I/O overhead from processing all volumes simultaneously; however, overall synchronization time may increase.


If you set EnableParallelFileSnapshot = false then RHA will process one directory at a time. However, you can leave EnableParallelFileSnapshot = True and set MaxParallelFileSnapshot to define how many directories can be processed in parallel.


Note: Please restart CA ARCserve RHA Engine after editing this parameter.  This editing should be done both on the master  and replica servers.


First try to disable parallel processing completely and check if the overhead (client RPC latency) is sustainable or still not.


Sync always imposes some overhead on the server and this is quite typical that client RPC latency grows during sync making Outlook connections slower. You can schedule the initial synch after hours (during low activity of Exchange and when Exchange maintenance/backup is not running)


If you are replicating data over fast network (e.g. Gb LAN) you can delete all Exchange DB data from replica before they sync. If there is no data on replica, then we read/send one directory a time that imposes less overhead on the server.


Other reason of high RPC latency


  1. Spool is located on Exchange data or log drive on master


  1. Storage subsystem is not tuned well and disk read/write latencies are high (read/write cache is not enabled on disk controller). This can be monitored from performance logs.



It would be a good idea to run a perfmon logging on this server during sync and send S BLG file to Support 

Here is a list of perfmon counters that We recommend.


Add entire objects to the log:

Physical Disk

Logical Disk (if a customer is using mounted volumes)


Paging File

CAARCserveRHAEngine: CA ARCServeRHA Scenaris


Add individual counters for:


Process à ws_rep (IO Read Bytes/sec, IO Write Bytes/sec, Private Bytes, Virtual Bytes)

MSExchangeIS à RPC Averaged Latency

Database à I/O Log Writes/sec, I/O Database writes/sec


You can configure sample interval to 60 sec to minimize overhead on the server from perfmon log.

Here is a great MS doc showing the expected disk latencies and RPC latencies for Exchange


It is good to have perfmon data with and without RHA scenario running in order to compare.








Was this article helpful?
0 out of 0 found this helpful
Have more questions? Submit a request