Maintaining MTS Packages

Archived content. No warranty is made as to technical accuracy. Content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

After a package has been successfully built, distributed, and deployed, administrators can use the MTS Explorer to maintain MTS packages. Maintaining MTS packages entails monitoring the status and properties of packages and their components, and reconfiguring package and component properties if required.

On This Page

Monitoring Status and Properties in the MTS Explorer
Using Property Sheets in the MTS Explorer
Managing Users for MTS Roles
Using MTS Replication

Monitoring Status and Properties in the MTS Explorer

You can use the MTS Explorer Status View and Property View settings to monitor the status and properties of active packages and their components. You can view the status or properties of items in the Explorer by selecting the item and then clicking the Status View or Property View button in the MTS Explorer toolbar.

The Status View lets you see the status of computers, packages, and components in the Explorer. For example, Status View for the Computers folder indicates if Microsoft Distributed Transaction Coordinator (MS DTC) has been started, while Status View for the Packages Installed folder indicates which package is running. Status View for components in a package allows you to see the component's programmatic identifier (progID), objects activated, and the objects in call. You can use the Status View to quickly see the status of computers and application processes that you are managing.

To use the Status View in the MTS Explorer

  1. Select the Packages Installed folder or Components folder.

  2. Choose the Status View icon on the MTS toolbar in the right pane of the MTS Explorer.

Note Status View does not display the status of the Utilities and System packages.

Use the Property View to quickly gather information about the properties of packages and components. For example, the property view for components displays the component's ProgID, transaction setting, dynamic-link library (DLL) location, class ID (CLSID), threading model, and security authorization settings. For example, you can use the Property View to quickly view the transaction properties for all components in a package.

To use Property View in the MTS Explorer

  1. In the right pane of the MTS Explorer, select the folder whose status you would like to view, such as the Packages Installed or Components folder

  2. Click the Property View button on the MTS Explorer toolbar. The properties for items in that folder will be displayed in columns in the right pane of the MTS Explorer.

Using Property Sheets in the MTS Explorer

Package and component property sheets allow you to change the configuration of MTS packages. For example, if you would like to change the transaction property for a component, you can modify the component property sheet for transaction settings. Before you re-configure a specific property setting, review the Creating MTS Packages and Installing MTS Packages topics for descriptions and procedures on setting different properties in the MTS Explorer.

Packages can be locked against modification or deletion of the package and its components. If a package has been locked during installation or deployment, you will have to unlock the package before modifying component properties. For more information about locking, see Locking Your MTS Package .

To configure package and application properties using property pages

  1. Right-click the item whose properties you want to set. You can also select the item in the left pane of the MTS Explorer and choose Properties from the Action menu.

  2. Modify the appropriate property sheet and click either OK or Apply.

  3. Refresh all components of My Computer by selecting the My Computer icon and choosing Refresh all components from the Action menu. You can also refresh individual packages by selecting the Packages Installed folder and clicking the Refresh icon on the MTS toolbar in the right pane of the MTS Explorer.

    Note: If you change the activation level of your package, you have to shut down that package process before the change will take effect. You can shut down the package process by right-clicking the package and choosing the Shut down option. Note that packages administered remotely on an MTS 1.x computer cannot be shut down individually.

Managing Users for MTS Roles

As an administrator, you will have manage a role's Windows NT users and groups of users by:

  • Adding a new user or group to a role

  • Removing a user or group from a role

  • Moving a user or group from one role to another

As clients of your server packages increase, use the MTS Explorer to map the new users to roles for the package. For more information about mapping new users to a role, refer to the Mapping MTS Roles to Users and Groups topic.

You may have to remove users from a role, or move users or groups of users from an existing role to a newly created role. For example, if an employee leaves the company, you would remove that user from the roles with which the former employee was associated.

When you create new roles for an existing package, you may have to move a user or a group of users from one role to another. For example, if you create a Clerk role for an Accounting package, you may have to move some users or a group of users from the existing Manager role (with read and write privileges for Accounting data) to the Clerk role (with read-only privileges). In order to move users or groups of users, you must remove the user or group of users from the role and then map them to the new role.

To remove a user from a role

  1. Locate the package that contains the role from which you want to remove a group or a user. In the left pane of the MTS Explorer, select that package.

  2. Open the Roles folder.

  3. Double-click the role that has been defined for the user you want to remove.

  4. Open the Users folder.

  5. Select the user you want to remove.

  6. On the Action menu, click Delete. You can also right-click and select Delete from the right-click menu.

  7. Click Yes in the dialog box that appears. You can also remove a user by selecting the icon for that user and pressing Delete.

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

  1. Install MTS on both computers. For more information, see Configuring MTS with Microsoft Cluster Server.

  2. Designate a master computer and install your packages on that computer.

  3. Register any imported components on both computers.

  4. Ensure dependencies such as runtime libraries are installed on both computers. (See the Limitations section in this topic.)

  5. 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).

  6. 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\Mts, then the default package install directory is c:\Program Files\Mts\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\Mts\Packages

c:\Program Files\Mts\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\Mts\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

  1. 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.

  2. Use the MSCS Cluster Administrator to create virtual server names for both computers.

  3. 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.

  4. 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.