VERITAS Storage Replicator (VSR) 2.1 SP3 readme

Article:TECH24863  |  Created: 2009-01-05  |  Updated: 2009-01-05  |  Article URL
Article Type
Technical Solution



VERITAS Storage Replicator (VSR) 2.1 SP3 readme


VERITAS Storage Replicator for Windows
Version 2.1 Service Pack 3


Copyright (c) 2003 by VERITAS Software Corporation

This Readme document contains important information about
Storage Replicator.  Please read this document before you
install Storage Replicator on your production systems.

You can find more information about installing and running
Storage Replicator in the product documentation set.

  1) Introduction

  2) Service Pack Installer

  3) Bug fixes since last release

  4) Product Enhancements

  5) Known Issues

  6) Product Support Information

1)  Introduction
  Welcome to VERITAS Storage Replicator.  On behalf of
the entire development team, we'd like to thank you for
purchasing our product.
  If you have any comments, questions, or problems, please do
not hesitate to contact our world-class technical support team
via e-mail at

2)  VSR Service Pack 3 Installation
  There are two installers included in this release: the 'normal' product
installer and a Service Pack installer.  Each installer serves a specific
purpose and the correct installer must be used in each situation.

  Installing on a machine with no previous version installed:
       - Use the 'normal' product installer.  This can run from the CD
         Browser or by double clicking on the setup executable
         <cd root>\VSR\Install\Setup.exe.

  Upgrading over a VSR 2.0x version:
       - Use the 'normal' product installer.  This can run from the CD
         Browser or by double clicking on the setup executable
         <cd root>\VSR\Install\Setup.exe.  Every machine in the
        Replication Neighborhood needs to be upgraded to the new version
        as there is no backwards compatibility between VSR 2.1x and
        VSR 2.0x versions.

  Upgrading over a VSR 2.1x version:
       - Use the Service Pack installer.  Running the 'normal' installer
         will prompt to uninstall the product.  The Service Pack installer
         can be found on the CD in <cd root>\VSR\Service Pack.  This
         Service Pack installer will not upgrade a VSR 2.0x version.  You
         must upgrade the RMS machine before upgrading any machines that
         are used to run the Administrative Console or SRToolUR.

  See the 'Known Issues' section below for more installation

3)  Bug Fixes
The following defects were fixed in this Service Pack 3
  1. "Event 54" system hangs.  The file system filter drivers have been
       updated in SP3 to fix this problem.  

  2. PHP Script Errors.  The VSR File System Filter Drivers would cause PHP
       scripts to fail.  The SP3 filter drivers fix this problem.

  3. "Rename into Policy" replication failures.  Under some circumstances, a
       file renamed from one directory not under replication to a directory
       that is currently being replicated by a VSR Job in Dynamic mode would
       fail to replicate to the Target.  The folders would have to be on the
       same volume for this to occur.  This is fixed in SP3.

  4. VSR could interfere with SMTP e-mail generation by IIS web servers.  
       Fixed in SP3.

  5. Some applications that create temporary files in a particular way could
       cause Synchronization to fail if the Source Server was experiencing
       extremely heavy I/O loads.  Fixed in SP3.

The following defects were fixed in the Service Pack 2

  1. Bug: RMS hangs under heavy load when there are a very
          large number of Servers in a Job or a very large
          number of Jobs starting and stopping at the same time.
     Status: The RMS can now start and stop hundreds of Jobs
          and control Jobs with 120 Replication Pairs.  (See the
          Known Issues section for details.)

  2. Bug: Occasional failure of SrToolUR and/or the Console to
          Connect to the RMS under Terminal Services.  
     Status: The cause was identified and fixed.

  3. Bug: Access Denied during replication.  These problems
          would happen in both Synchronization and Continuous
     Status: The Access Denied problems have been addressed in
          the SP2 version.  

  4. Bug: VSR does not install correctly on servers that have
          Services for UNIX installed.
     Status: VSR 2.1 SP2 installs correctly on machines that have
          Services for UNIX installed.  Installing Services for
          UNIX after Installing VSR will break VSR, but there is
          a workaround.  See the Known Issues section for details.

  5. Bug: Services fail to shutdown.  Under some circumstances it
          was possible to get the Storage Replicator RSA and RMS
          services into a state where they could not be stopped
          from the Service Control Manager.  
     Status: The services are now fully controllable from the SCM.

  6. Bug: Jobs sometimes appear to be 'stuck' in canceling or
          expiring state.  
     Status: Notification of state changes has been streamlined
          so these states are not 'sticky' anymore.

  7. Bug: The Console and SrToolUR were slow to respond in
          environments with large numbers of servers.
     Status: The Console and SrToolUR are completely functional in  

          Replication Neighborhoods that contain several hundreds of
          servers.  See the Product Enhancements section for

  8. Bug: The MSCS Job Agent could hang the MSCS cluster.
     Status: This would happen in a rare, but possible, condition.
          The bug was identified and corrected.

  9. Bug: Pattern Matching Discrepancy.  In some instances, the Job
          Properties window, Rules Tab, Source Tree view will
          display a file as though it would be replicated (shown
          in normal density) when it actually will not be
          replicated and should have been displayed grayed out.
             Entering a rule to include "wordp*" displays
             "wordpad.exe" as being replicated, but the software
             does not actually replicate it.  However, including
             "wordp*.*" does replicate wordpad.exe.
     Status: Fixed in SP2.

4)  Product Enhancements
The following product enhancements were included in this Service Pack 3

  1. Windows XP Support.  VSR 2.1 SP3 contains full support for Windows XP

  2. Disable Dynamic Journaling Option added to Jobs.  Disabling Dynamic
       Journaling allows Publication Jobs to contain more than 63 Target

  Use this new feature with extreme care!  Disabling Dynamic Journaling
will also inhibit VSR's ability to track changes to the Source data set
while Synchronization is taking place.  If this data set changes on the
Source Server during synchronization and Dynamic Journaling is disabled then
the data set on the Target will not have write order fidelity.  This will
result in a logically inconsistent replica on the target that will not be
fixed until the next synchronization (Job Start).  This option can only be
used for Synchronization Only jobs and should be used only when access to
the source data can be limited by the administrator.  

  Creating Publication Jobs with more than 63 Target Servers can only be
done in the command line tool SRToolUR.  The Administrative Console will
stop adding Replication Pairs at 63 regardless of the state of the Disable
Dynamic Journaling option.  

  Use the following commands to add a Replication Pair to a Job in

     Add pair to job <Job Name> with SourceServer=<Source Server Name>,
         TargetServer=<Target Server Name>

  Note that the Job Name and the Server Names should all be enclosed in
double quotes.

  Once the pairs are added to a Job they can be edited and manipulated
(custom target paths, bandwidth settings, etc.) in the Administrative
Console or SRToolUR.  

  To turn the Disable Dynamic Journaling Option on and off in SRToolUR, use
the following:

               Set NoDynamicJournal of job <Job Name> to <1 or 0>

  The NoDynamicJournal property can be set in the Administrative Console as

  3. New Monitor Jobs View Columns.  There are three new columns in the
Monitor Jobs View.  These columns are "Current Operation", "Next Pending
Operation", and "Last Requested Operation."  These columns show actions the
RMS is taking within the jobs, what RMS actions are pending, and the last
operation requested.

  4. Changing NIC cards in a server no longer changes that server's unique
identifier in the Replication Neighborhood.  RSAs in previous versions of VSR
would appear in the console twice when a NIC was changed and any Replication
Jobs that reference the server would need to be edited to run correctly.

  5. Viewing Job Statistics is now possible in SRToolUR.  Job Statistics

       RunStage - Will be one of the following: NotRunning, Prescan,
                  Synchronization, Dynamic, Resynch, NoConnection.

       WhenStageStarted - The date and time the current Run Stage started.

       TotalBytesSent - The total number of bytes sent over the wire to the
                  Target Server for the pair being monitored.

       CurrentFileSize - The size (in bytes) of the current file being
                  replicated to the target. This is only valid during

       ScannedObjectTally - The count of the number of objects (files and
                  directories) scanned during prescan.  Valid only during

       CurrentFileName - The name of the file currently being replicated to
                  the target during Synchronization.  Not valid during
                  Dynamic replication or PreScan.

       TransferRate - The aggregate data transfer rate for the pair.  Valid
                  only during Synchronization and Dynamic replication, not

       ResynchPctComplete - Shows how far synchronization has progressed
                  expressed as an integral number from zero to 100.  Valid
                  only during Synchronization and Resynchronization, and only
                  if PreScan is turned on for the Job.

       Resyncs - The total number of resyncs since the scheduled Job start for
                  this pair.

       TimeTilSyncDone - The time needed to complete the Synchronization of
                  the pair.

  Example 1:
       Keep showing some pair statistic as long as the pair is Synchronizing:

       loop while RunStage of pair "SRC:TRG" of job "MyJob" EQ Synchronization
               get Name, CurrentFileSize, CurrentFileName of pair "SRC:TRG" of job "MyJob"
               wait 1 sec

  Example 2:
       Pause a batch file until a pair goes into Dynamic replication:

       rem do something here before
       srtoolur -cmd wait until pair "SERVER1:SERVER2" of job "Bar" EQ Dynamic
       rem do something else here after

  6. The debugging logs (Picilog) is no longer truncated at server start
time.  An existing Picilog is renamed and a new log is started when the
services start.  The old picilog is renamed picilog.txt.prev and is left in the
same directory as the new picilog file.

The following product enhancements were included in the Service Pack 2

  1. Server logs have been cleaned of much redundant information
     and extra entries have been added.

  2. Server pair restarts are more reliable in SP2.  The
     protocol has been simplified for the restarting of replication
     between servers after a network outage.  This fix addressed a
     rare but seen condition where servers would not re-start
     correctly after an outage.

  3. Scaling Enhancements.  SP2 includes many critical
     enhancements to VSR's ability to run correctly in very large-
     scale installations (many hundreds of servers).  Specifically:

     1. Server information is now stored in the database on the
        RMS enabling the Consoles and SrToolUR to startup much
        faster.  Job creation in the Console is now faster as well.

     2. RMS Job Starts are now parallelized.  If one Job takes
        a long time to start it will not hold up any other jobs
        that are scheduled to start at the same time.

     3. The Console and SrToolUR start much faster due to a cache
        loading enhancement.  This can cut many seconds off the
        client startup time which is particularly important when
        using SrToolUR in complex Perl scripts where it might be
        started many times in a loop.

     4. The Console no longer shows No Credentials.  The Servers
        are still secure and credentials will be prompted for if
        they are needed when a Server Property Sheet is opened or
        a Server is added to a Job.

     In general, SP2 will run comfortably in an environment with
     many hundreds of machines and can handle Replication jobs of
     up to 120-to-one and one-to-63.  (See the 'Known Issues'
     section below for more information.)

  4. Diagnostic logging is now dynamically configurable.  Previous
     versions required a stop and start of the Storage Replicator
     RSA service to turn on and off diagnostic logging.  This can
     now be done without a restart.

  5. Better performance during very heavy I/O loads.  Previous
     versions would occasionally exhibit problems with very high
     I/O loads, particularly on the source machine.  Under some
     conditions this could lead to unbounded Journal growth and a
     severe slow down of the source computer.  This general
     issue has been addressed and is much improved in SP2.

  6. The User Interface now offers the option of stopping a
     job at the end of a scheduled window even if the
     synchronization is not complete.  Previous versions would
     ignore the end of the scheduled window and complete the
     synchronization before stopping.

  7. VSR 2.1 SP2 now supports Windows Server Appliance Kit (SAK)
     installed on NAS appliances.

  8. Synchronization is much more efficient for very large files.
     Dirty file regions are transmitted earlier in the
     region analysis and the region size has been tuned.

5)  Known Issues

5.0 Scaling (Job Size) Issues

  1. An RSA can be the Source for only 63 Replication Pairs at
     any one time.  It can be the Source Server for more than
     63 Replication Pairs in multiple Jobs but only 63 of those
     Replication Pairs will run at any one time.  For example,
     The RSA can:
       - be a Source in one 1-to-63 job

       - be a Source in a 1-to-31 Job and
         be a Source in 32 1-to-1 Jobs if these jobs are
            scheduled to run at the same time

       - be a Source in an unlimited number of 1-to-63 Jobs
            if these Jobs are not run at the same time

     If an RSA is scheduled to run in more than 63 Replication
     Pairs at any one time then the first 63 of those pairs will
     start and the rest will not.  The pairs will start as others
     stop, cancel or expire.

  2. An RSA can be the target for only 120 Replication Pairs at
     any one time.  It can be the Target Server for more than
     120 Replication Pairs in multiple Jobs but only 120 of those
     Replication Pairs will run at any one time.  For example,
     The RSA can:
       - be a Target in one 1-to-120 job

       - be a Target in one 1-to-60 job and
         be a Target in another 60-to-one job

       - be a Target in 120 1-to-1 Jobs

       - be a Target in multiple 120-to-1 Jobs
            if these Jobs are not run at the same time

     But the RSA cannot:
       - be a Target in one 1-to-140 job

       - be a Target in one 1-to-80 job and
         be a Target in another 80-to-one job
            if both these Jobs are run at the same time

  3. The limits described in 5.0.2 are reduced to 63 if Target
     Protection is enabled for all Pairs.  The same rules
     apply for Jobs that are not run concurrently.

  4. Remember, these limitations apply to jobs that are all
     running at the same time.  For instance, a single RSA can
     appear in thousands or Replication Pairs as a Target as long
     as no more than 120 of them run at any one time.  And a
     single RSA can appear in thousands or Replication Pairs as
     a Source as long as no more than 63 of them run at any
     one time.

     If this limit is exceeded then the server over the limit
     will refuse the new connection and the Replication Pair
     will fail to start when the job starts.  

5.1 General issues

  1. As a general guide, it is recommended that there is
     at least 10% more disk space on the target volume than
     the volume that is being replicated.

  2. When choosing a custom target path, be very careful
     not to select any path with data that needs to be saved.
     Replication will overwrite/delete all data in the
     selected directory!

  3. When deploying to a remote machine, the logged in user
     must have Administrator access on both machines. The server
     being deployed to and the machine on which the Console is running.

  4. To create or edit a replication job, the logged in user
     must have Backup rights for all source and target
     servers paired in the job.

  5. Disabling Storage Replicator SNMP support.
     If the Windows SNMP service is installed on the
     computer when Storage Replicator was installed,
     Storage Replicator's SNMP support will be automatically
     installed.  To disable Storage Replicator's
     SNMP support, look for the following value in the registry key:


     that contains this string:
        "SOFTWARE\VERITAS\Storage Replicator\2.11".

     To disable SNMP support, simply delete this value.

  6. Storage Replicator uses the NobleNet WinRPC product.
     This product uses a Sun RPC portmapper program which
     acts as a location broker for WinRPC applications.
     The portmapper uses the Sun RPC well-known port.

     The NobleNet Portmapper is redistributed and installed
     with the Storage Replicator product.

     If you are using another portmapper, The following link
     explains how to configure Storage Replicator to use that

  7. When creating or editing job file selection rules, pay careful
     attention to the order of the include/exclude rules.  Rules
     are evaluated in-order, and so rule ordering will directly
     affect which files get replicated (and which files don't!).  
     Please note that it is possible to create conflicting sets of
     rules.  To avoid such conflicts, it is recommended that all
     rules and their ordering are double-check prior to running a
     replication job. The following is a link to a TechNote that
     addresses rules in a replication job:

  8. Selection of Journal directory

     The user is strongly discouraged from placing the Storage
     Replicator journal files on a file system that is also a source
     for replication or a system drive.  Under a heavy I/O load, such a
     configuration could cause the source server's performance to degrade
     rapidly until the server becomes totally unresponsive and appears to  
     have hung.

     To avoid this scenario, it is strongly recommend to configure  
     VSR to host its databases and journal files on volume that will
     never be a replication source.  

     Unfortunately, nothing in the Storage Replicator installer
     prevents configuring VSR in this undesirable manner.
     However, after installation the location of the VSR databases
     and journals can be changed through the registry if necessary.  
     To change where these VSR database and journal files are located,
     do the following:

        1. Stop the RSA service
        2. Copy the VSR/Databases and VSR/Journals directories to a
           new volume.
        3. Change the following registry keys to reflect where the
           the Databases and Journals directories were copied:

HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\JournalRoot
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\ProtectedDatasetDirectory
HKEY_LOCAL_MACHINE\SOFTWARE\VERITAS\Storage Replicator\2.11\UnprotectedDatasetDirectory

        4. Restart the RSA service.

See the following TechNote for details:

  9. Running SrToolUR from a Job post-script requires some changes to
     the way the Storage Replicator RSA service is configured in  
     the Service Control Manager.  The Storage Replicator RSA
     service runs under the Local System account by default and
     this account doesn't have permissions to connect to the RMS.
     The following TechNote is a workaround:

  10. IP Address changes while VSR is running can cause Servers
     to disconnect and fail to replicate.  The workaround is to
     assign fixed IP addresses to the VSR RSA's or to stop and
     restart the ENL and RSA (and RMS) services on the machine
     after the IP address change occurs.

  11. Renaming a machine can cause it to show as "Unavailable"
     in the Console forever.  

  12. Deleting Replication Pairs from a Job can leave old selection
     rules in the database.  These rules have no effect on
     replication but can appear in the Console.

  13. Running Consoles will fail to update under some conditions
     when Replication Pairs are created in a Job on another
     Console.  Closing and re-opening the Console will clear up
     the inconsistency.

5.2 Installation issues

  1. While not required, it is strongly recommended that the
     Replication Management System (RMS) component is installed
     before installing other Replication Service Agents (RSAs).

     If the RSA is installed prior to installing the RMS, and the
     RSA exists on a different subnet from the RMS, it might be
     necessary to add/change a registry key on the RSA in order
     for the RSA to successfully attach to the correct Replication

     To do this, first stop the ENL and Storage Replicator RSA
     services then change the registry key (described below), and
     restart both services.

     From the Services screen, stop ENL service.  This will display a
     warning that it will also stop the Storage Replicator RSA.
     Click OK.

     Using REGEDIT.EXE, locate or add this registry key:
     Set this key's value to the name or IP address of the RMS

     When finished, start the ENL service first, and then start
     the Storage Replicator RSA service.
     This is explained further in the TechNote link below:

  2. It is possible to push-install an RSA across subnets using
     the New Server Wizard.  If you push an RSA to a subnet other
     than the one where the RMS is installed then you will need to
     follow the instructions in (5.2.1) or in the TechNote link

  3. When installing VSR, never select a storage device that is
     shared among nodes of a cluster to store the database or
     journal files.  The VSR installer will not select these
     devices by default if the shared storage devices are
     configured to be used by either Microsoft Cluster Server
     or VERITAS Cluster Server.  If the storage devices are not
     configured to be used by a cluster, the installer may
     incorrectly select these devices.

     Please see the TechNote
     for more information.

5.3 Upgrading to SP3
     VSR 2.1 SP3 is RSA-Compatible with all VSR 2.1x versions.  The
     SP3 RSAs, however, will not function with an older RMS.  
     There are other compatibility and behavior issues with running
     the older Consoles and SrTools with the new SP3 RMS.  The
     SP3 compatibility guidelines are:

     1. The RMS must be upgraded first.
     2. Every RSA that runs the VCS or MSCS Job or RMS Cluster
        Agent must be upgraded to SP3.
     3. Every machine that you use the SrToolUR or Console from must
        be upgraded.  Don't forget any RSA's that may be running
        SrToolUR from a pre- or post-Job script - these need to be
        upgraded too.

     Any remaining old RSA's will continue to run in the new SP3
     Replication Neighborhood but will not benefit from some of the
     enhancements and bug fixes.  Users are encouraged to upgrade
     all RSA machines as quickly as possible.

5.4 Replication issues

  1. When deleting a replicated long named file by its short
     name, it may not be deleted on the target when the source
     is an NT 4 machine and the target is a Windows 2000 machine.

  2. Pair pre and post script commands run with the same
     security context as the RxRSA service on the machine
     executing the command.  By default, services run without
     any network rights.  If the application requires any network
     authentication to run in a pair script, it will fail.  
     SrToolUR is an example of just such an application.  
     Because it requires authentication with the RMS, it
     cannot be run from within a pre/post job script.
     The following is a link to a workaround for this issue.

5.5 Firewall Support
    To replicate through a firewall, open the following TCP and
    UDP ports in your firewall software.

111/TCP SUN RPC portmapper
1804/UDP RxService port 0
20481/TCP RxService port 1
20482/TCP RxService port 2
20484/TCP RxService port 3

    Check the following link for the TechNote on this:

5.6 Compatibility issues

  1. Storage Replicator 2.1 SP3 is not compatible with Storage
     Replicator 2.0x or Seagate Software's Replication Exec
     product.  See section 5.3 in this document for more details.

  2. Other software that utilize file system filter drivers, such as
     disk defragmenter utilities, certain open file agents and
     some virus protection software, should not be used with this
     product as there could be conflicts.  If an incompatible
     product is found to be installed on a Storage Replicator

     1. Starting both Storage Replicator and the incompatible
     product may cause the system to become unstable or crash.

     2. Enabling both products at system boot time will prevent the
     system from booting.

     It is strongly recommended that the system is protected by
     ensuring the Windows emergency repair information is current
     and available.  Before making any major change on a
     system (for example, installing a major application), use
     the Windows Repair Disk Utility to update the system's
     repair information.  Storage Replicator Setup prompts you
     to update this information.

     Storage Replicator Setup installs a file system filter
     driver on the system.  In the unlikely event that a product
     on the system would conflict with this driver, the repair
     information would allow the return of the system to its
     previous configuration.

     If an incompatible product is installed on the system
     that is to run Storage Replicator, it will be necessary
     to either disable or remove the incompatible product before
     installing Storage Replicator on this system.

     If Storage Replicator is already installed on the system,
     do not enable or start the other product while Storage
     Replicator is installed and running.

  3. This product is not compatible with Computer Associates
     InoculateIT Virus protection software. Storage Replicator
     will not replicate files in continuous mode if the InoculateIT
     software's "Enable real-time file monitor" option is turned
     on.  Please disable this option in InoculateIT if a job is
     continuously replicating data from this server.

  4. This product is not compatible with Network Associates
     ViruScan for Windows versions that use a file system filter driver.

  5. This product is not compatible with ArcServe for Windows

  6. This product is not compatible with VERITAS Storage Migrator.

6)  Product Support Information
  Support for problems, questions, and solutions can be
obtained by using our world-class support system.  Please
don't hesitate to contact one of our friendly support
specialists via e-mail to

When contacting technical support, please be sure to include
the following information:
 1) Your name
 2) Your company name
 3) Your phone number or e-mail address
 4) A brief description of the problem

Legacy ID


Article URL

Terms of use for this information are found in Legal Notices