Using MTS Replication

MTS provides replication for use with Microsoft Cluster Server (MSCS). If an MTS server in a cluster fails or is taken offline, the other server takes over the failed server's operations.

How to Replicate an MTS Server

To replicate an MTS server

Install MTS on both computers. For more information, see Configuring MTS with Microsoft Cluster Server.
Designate a master computer and install your packages on that computer.
Register any imported components on both computers.
Ensure dependencies such as runtime libraries are installed on both computers. (See the Limitations section in this topic.)
Specify a Replication Share name for the master on the Options tab on the My Computer property sheet (see the Package Contents Replication section in this topic).
Run the MTXREPL.EXE command-line utility.

You use the MTXREPL.EXE command-line utility to replicate an MTS server. Both the master and destination computers must be running. MTXREPL.EXE takes the following arguments:

MTXREPL.EXE master destination

MTS replication uses a single-master approach, copying MTS catalog information from a master computer to a destination computer. To replicate to another destination computer, run the MTXREPL.EXE utility again. The single-master approach is not strictly enforced, however, so you can in turn use the destination computer as the master for another MTS server replication.

During replication, MTS completely replaces the catalog on the destination with the catalog on the source, except where noted below in the What MTS Replication Does Not Do section in this topic. You cannot do partial replication. If MTS replication fails, run the MTXREPL.EXE utility again.

Administrators are responsible for initiating MTS replication and must ensure that package changes to the master server are replicated to all computers within the cluster.

It is recommended that replication be performed when the destination is not currently running MTS components. There is a window of failure on MTS startup while reading catalog information. If the replication were to occur at this time, package startup will fail, requiring the client to retry.

Replicating IIS Packages

Use the Microsoft Internet Information Server (IIS) version 4.0 replication utility to replicate IIS packages. IIS replication copies all MTS catalog information automatically. Because of this, running the MTS replication utility is not necessary; in fact, it will not run if IIS 4.0 is installed.

Package Contents Replication

MTS replication copies all necessary component dynamic-link libraries (DLL)s, type type libraries, and proxy-stub DLLs. To allow destination computers to access these files, you must specify a Replication Share name for the master on the Options tab on the My Computer property sheet. You must create this share on the master and grant read-only privileges to destination computers. The Replication Share name is the share name, not the directory that the share name maps to. For example, if you have d:\mtx\repl shared as MyReplPoint, then Replication Share should be MyReplPoint, not d:\mtx\repl.

The Replication Share must grant read-only permission to the identity of the destination computer's System package. If the destination's System package performs role checking, then the identity of the System package on the master must belong to the Administrator role in the destination's System package.

The location of the first component DLL in a package determines where files are installed on the destination computer. If this component is located in a subdirectory beneath the default package directory, the subdirectory is mirrored on the destination computer. The default package directory is determined during MTS setup; for example, if you install MTS into c:\program files\mtx, then the default package install directory is c:\program files\mtx\packages.

If your packages are installed beneath this directory, they will be installed in the same location relative to the default package install directory on the destination computer. For example:

Computer	Default Package Directory	Package Install Directory

Master	c:\program files\mtx\packages	c:\program files\mtx\packages\MyPak
Destination	d:\mts\packages	d:\mts\packages\MyPak

Packages installed outside the default package install directory are installed in the "external" subdirectory on the destination computer. For the above example:

Computer	Package Install Directory

Master	Package A in c:\program files\mtx\packages\MyPak Package B in d:\misc
Destination	Package A and B in d:\mts\packages\MyPak

It is recommended you install packages beneath the default package directory. It is also recommended that all files of the same package reside in the same directory.

Administering MTS Server Clusters

Administrators must always use physical computer names for administration in an MSCS cluster. If you are on the master computer in an MSCS cluster and you want to view the copy, use its physical computer name. To replicate between the master and copy, use the physical computer names.

You must specify the virtual server name in the Remote Server Name on the Options tab on the My Computer property sheet for deploying MTS applications on an MSCS cluster. When you export a package using the application executable utility, clients which then install the application will be directed to the virtual server. If you do not set the Remote Server Name, clients will be directed to the physical computer, which is not the proper configuration for failover protection.

You can also perform static load balancing with failover protection by specifying different virtual server names. By having two virtual server names, one for each physical computer, you can create a client installation executable for a package installed on both computers. By dividing their distribution among clients, static load balancing is achieved.

To load balance an MTS application using virtual servers

Decide on how you want to balance load.

For example, you can run all packages on only one computer at a time, run all packages on both computers, or run some packages on one computer and some on the other.

Use the MSCS Cluster Administrator to create virtual server names for both computers.
Export packages using the virtual server names that you created in Step 2.

If you want to run all packages on only a single computer at a time, export all packages under a single virtual server name. If you want to run all packages on both computers at the same time, export all packages twice, one for each virtual server name You must then distribute the two different sets of client installation executables to among your clients. If you want to run half the packages on one computer and half the packages on the other, export each half using a different virtual server name.

Run the client executables on the client machines. Depending on how you chose to load balance in Step 1, you may have several executables to run on each client.

What MTS Replication Does Not Do

MTS replication does not do the following:

Install MTS. You must setup MTS on each destination computer before running MTS replication.
Replace MTS system and utilities packages and the IIS utilities packages. You must configure these packages identically on the master and destination (although file paths can differ). MTS does not enforce this; it is the responsibility of the administrator to synchronize both sets of packages as needed.
Replicate computer-specific information such as the Replication Share and Remote Server Name properties.
Replicate MTS component dependencies that cannot be detected by MTS such as run-time libraries. You must copy these files on each destination computer in order for applications to execute properly.
Replicate local computer security accounts. Such accounts are not recommended for use within clusters for roles or package identities.
Replicate persisted data that your application relies on. For example, SQL Server provides automatic failover for its databases; you must ensure that the database is configured to failover for your application.

Limitations

MTS replication to or from Windows 95 computers is not supported.
MTS replication will fail if there are any remote components on the master which are set to run on the destination computer.
Imported components can only be replicated if they are already registered on the destination computers. Installed components are automatically registered and configured on the copy by the replication utility. When replicating components that were imported on the master, the replication utility expects to find the components already registered on the copy. It is your responsibly to manually register imported components on each destination computer prior to running the replication utility.
Replication to or from versions of MTS prior to MTS 2.0 is not supported.