Component Services Administration Help

The Component Services administrative tool enables you to configure and administer COM components and COM+ applications. This Component Services Administration Help documentation provides the conceptual information and procedures you can use for the most common system administration tasks. This generally includes installing and configuring COM+ applications, setting security at the application level, and creating and maintaining COM+ partitions.

The Component Services administrative tool is designed both for system administrators and for application developers. For example, developers can configure routine component and application behavior, such as participation in transactions and object pooling. For conceptual information and procedures on tasks mainly reserved for developers using the Component Services administrative tool, in addition to reference information about the COM+ administrative objects and programming interfaces, please see the topics under "COM+ (Component Services)" in the Microsoft Platform SDK. If you don't have the Platform SDK installed, see the MSDN Web site to view or install it.

For information about the latest improvements to the Component Services administrative tool, see What's New in Component Services.

For an overview of the topics and tasks covered in this guide, see Roadmap for Using Component Services Administrative Help.

For important security information, see Administering Trustworthy Computing.


What's New in Component Services

With this release, the Component Services administrative tool offers new features, as well as changes to existing features, that are designed to increase the overall scalability, availability, security, and manageability of COM+ applications for both developers and system administrators. To make it easier to configure and deploy these new features, Help topics have been updated in the Component Services administrative tool and enhanced documentation and new reference topics have been added to the Platform SDK documentation.

New (D)COM Security System

Windows XP SP2 includes a new security system for (D)COM applications. The new security system makes it easy to reduce the accessibility of COM applications to unauthorized users.

In addition to the previous access and launch permissions for COM applications, the new system includes a separate activation permission. Users that have activation permission, but not launch permission, for a COM application can create a client proxy for the application only if the application is already running on the server. Access permission is still required to make use of the proxy, so all users with activation permission should also be given access permission.

Access, launch, and activation permissions are now divided into separate local and remote permissions. Users with a local permission for a COM application can perform the allowed action only on the local computer (the computer on which the application runs). To perform the action from a different computer across a network, the user must have remote permission.

The new security system also includes a new machine-wide restriction policy. This policy limits the permissions that can be granted in any way (including the use of the CoInitializeSecurity API). You can, for example, disallow remote access to any COM application by denying remote access, launch, and activation permissions to all users in the machine-wide restriction policy.

The following table summarizes the default machine-wide restriction policy.

Permission | Administrators | Everyone | Anonymous
Access | Local, Remote | Local, Remote | Local
Activation | Local, Remote | Local | No permissions
Launch | Local, Remote | Local | No permissions

Note that the anonymous user has no remote permissions, and the users that are not administrators have no remote launch or activation permissions. These default settings may cause existing scenarios to break. For additional information, see DCOM on MSDN.

For more information about the new COM security system, including specific instructions on how to set permissions, see Access Permissions and Launch and Activation Permissions.

Feature Changes from Previous Releases

The following sections briefly describe feature enhancements to the Component Services administrative tool that were introduced in previous releases.

Application Pooling

The new COM+ application pooling service adds scalability for single-threaded processes and integrates with the new COM+ application recycling service. See COM+ Application Pooling for detailed information.

Application Recycling

Application performance can degrade over time because of application problems such as memory leaks, nonscalable resource usage, and process failures. The COM+ application recycling service enables you to shut down an application automatically and restart it, thus reinitializing a failing process and reallocating memory it uses. See Administering Application Recycling for a detailed explanation of the concepts and a step-by-step procedure for configuring the recycling of COM+ applications.

COM+ Partitions

In this release, COM+ introduces support for partitions, a feature that allows multiple configurations of COM+ applications to be run simultaneously on the same machine. This feature can save you the cost and time-consuming effort of using multiple servers to manage different configurations of an application. For example, you can create a "test" and a "development" configuration of a COM+ application. See Administering COM+ Partitions for a detailed explanation of the concepts and step-by-step procedures for creating and managing COM+ partitions.

COM+ SOAP Service

The new COM+ SOAP service allows clients to access configured COM components on a network server by using XML and SOAP (Simple Object Access Protocol). The COM+ SOAP service enables you to easily deploy your COM+ applications across a network as XML Web services while maintaining centralized control. See Administering the COM+ SOAP Service for more information.

Low-Memory Activation Gates

With this release, Component Services automatically checks memory before creating a COM+ server or object. If the percentage of virtual memory available to the application falls below a fixed threshold, the activation fails before the object is created. By failing these activations that would normally run, the low-memory activation gates feature greatly enhances system reliability. See Low-Memory Activation Gates for more information about this feature.

Pausing and Disabling Applications

COM+ applications are now more manageable. An administrator can pause and resume COM+ server applications or disable and enable COM+ library or server applications, or even individual configured components. Both the pausing and disabling features prevent future activations without affecting existing component instances. See Administering the Operation of COM+ Applications for more information.

Process Dumping

It's not easy troubleshooting applications in a production environment. How do you gather information on a problem without disturbing the running processes? COM+ now provides a solution through its new process dump feature. This feature allows the system administrator to dump the entire state of a process without terminating it. See Administering the Process Dump Tool for more information.


Roadmap for Using Component Services Administration Help

The sections described in the following table explain the administrative concepts and tasks provided in this guide.

Topic | Description
Guide to Administering Component Services | Provides an introduction to basic administrative concepts, a general overview of suggested categories for grouping administrative tasks, and an explanation of the items in the Component Services console tree.
Configuring the System for Component Services | Describes tasks you must perform after you install Component Services and before you can use the Component Services administrative tool over your network.
Installing COM+ Applications | Introduces client-side and server-side COM+ application deployment.
Administering the Operation of COM+ Applications | Provides concepts and procedures related to shutting down and starting, disabling and enabling, and pausing and resuming COM+ applications.
Administering Application Pooling | Provides concepts and procedures related to the pooling of COM+ applications, a COM+ feature that allows single-threaded processes to scale and helps single-process-failure recovery by providing other running processes to handle activations.
Administering Application Recycling | Provides concepts and procedures related to the recycling of COM+ applications, a COM+ feature that automatically shuts down and restarts applications to improve system stability and performance.
Administering Application Security | Provides an overview of Component Services security administration, along with links to more information on setting attributes to enforce security.
Administering COM+ Partitions | Provides an overview of COM+ partitions, as well as the concepts and procedures related to creating and managing partitions in either a local or a domain environment.
Administering the COM+ SOAP Service | Provides concepts and procedures relating to the COM+ SOAP service, which allows remote access to component functionality via the SOAP protocol.
Administering Distributed Transactions | Introduces distributed transaction administration, providing links to concepts and tasks on configuring your system to use the Microsoft Distributed Transaction Coordinator (DTC), view transaction statistics, and resolve transaction states.
Administering the Process Dump Tool | Provides concepts and procedures relating to the process dump tool, which can be used for the debugging of COM+ applications.
Administering Queued Components | Provides concepts and procedures related to the COM+ Queued Components service, which enables a client application to request services from a COM+ server application, even when the server application is unavailable or offline.
COM+ Glossary | Provides definitions of important COM+ terms and features.


Administering Trustworthy Computing

As developers, administrators, and consumers rely increasingly on global connectedness, an ever greater need for security has inspired the Microsoft Trustworthy Computing initiative. The Microsoft product teams have embraced this initiative and its challenges and are committed to providing you with the most secure computing environment possible. In keeping with that commitment, this version of the Component Services administrative tool enables you to set the software restriction policy for your COM+ applications, as well as allowing you to easily configure role-based security for your COM+ partitions and applications.

However, trustworthy computing cannot be achieved by software alone. It also requires a commitment on the part of developers and administrators to understand and anticipate the potential vulnerabilities of their systems and applications. While the demands of your computing environment may require its own particular, proprietary safeguards, the following list offers useful guidelines for security best practices:

  • Restrict physical access to computers, especially domain controllers, to trusted personnel.

  • Enforce the Principle of Least Privilege by granting only the permissions necessary for a given task.

  • Define groups and their membership and set default access levels in accordance with their defined roles.

  • Use strong Access Control Lists to secure data on your computers.

  • Use strong passwords throughout your organization.

  • Never download or run programs that come from untrusted sources.

  • Keep your virus-detecting programs up-to-date.

  • Keep all security patches up-to-date.

For detailed information about applying these practices in the Microsoft® Windows® Server 2003 environment, as well as an overview of security and new security features, click Start, click Help and Support, and then click Security.

For more information about using the COM+ Security services, see Administering Application Security.


Guide to Administering Component Services

You can deploy and administer COM+ applications in two ways. You can use the Component Services administrative tool, or you can write scripts to automate these processes. This guide explains how you can use the Component Services administrative tool to administer computers and configure and administer COM components and COM+ applications.

Note As an alternative to using the Component Services administrative tool to perform administrative tasks, you can automate any of these tasks by writing code that uses administration objects provided through the COMAdmin Library DLL. For a description of how to use these objects, see "Automating COM+ Administration" under the "COM+ General Tasks" node in the "Component Services" section of the Microsoft Platform SDK.

The topics in this section, described in the following table, provide an overview of the concepts and tasks essential to using the Component Services administrative tool.

Topic | Description
Component Services Application Types | Introduces concepts key to understanding the roles and types of COM+ applications.
Component Services Administrative Tasks Overview | Provides a general overview of suggested categories for grouping the Component Services administrative tasks.
Component Services Console Tree | Describes the categories of items you will see in the Component Services console tree.


Component Services Application Types

Most Component Services administrative tasks involve deploying completed development efforts on the network and ensuring high performance and security for the deployed applications and components. The tasks you perform depend on the type of application you're working with and the services that the application uses. This topic provides an overview of application types and the services they use.

Note The topics in this Component Services administration guide cover only a portion of the settings you can make with the Component Services administrative tool. Settings not covered by this guide should be made only by someone with thorough knowledge of the component's or application's implementation. Typically, these settings, which are discussed under "COM+ (Component Services)" in the Microsoft Platform SDK, are made by the developer before the application is delivered for installation and deployment.

You can think of applications you administer with the Component Services administrative tool as falling into one of two categories: COM applications and COM+ applications. These terms are used in this guide where settings may vary depending on the application type.

COM Applications

The idea of COM applications is not at all new—it's simply the term used to refer to groups of COM components developed to work together. A COM application example is Microsoft® Excel, which consists of a primary executable and accompanying application extension DLLs for the spelling checker, Microsoft Visual Basic® functionality, and so on.

COM+ Applications

COM+ applications are groups of COM components developed and configured together to make use of COM+ services such as queuing, role-based security, and so on. As a result, these are discussed much more frequently in this guide than COM applications. Some of what differentiates a COM+ application is written into the component code, and some is defined through the Component Services administrative tool.

COM+ applications can be divided into two types, each with distinct administrative needs. These are COM+ server applications and COM+ library applications. Server applications run in their own process space; for example, a server application might consist of a group of DLLs that encapsulate payroll processing. Library applications consist of components developed to run in a hosting application's process; for example, in a library application, you might group DLLs that provide services to other application components and that can share security characteristics of those components.


Component Services Administrative Tasks Overview

Administrative tasks performed with the Component Services administrative tool fall into four broad categories, as follows:

  • Configuring your system for Component Services

  • Making initial services settings

  • Installing and configuring COM+ applications

  • Monitoring and tuning component services

    Note While this topic examines tasks that are necessary or common, there are others you might perform as the need arises. For a more complete view, see the documentation for the areas that you are administering.

Configuring Your System for Component Services

When you are getting started with COM+, there are a few customization tasks you must perform before you can use the services with your network. For example, you must start by setting access to the underlying application that responds to settings and tasks you perform in the Component Services administrative tool. For more information about these tasks for getting started, see Configuring the System for Component Services.

Making Initial Services Settings

When you have done basic Component Services configuration for the characteristics of your network, your next task might be to adjust settings specific to the kinds of applications and services you want to use on the network.

Following are examples of the types of settings you might make to computers on your network:

  • To ensure security for components that aren't configured into COM+ applications—that is, COM applications or COM components deployed independently—you may need to make specific COM security settings for those computers. (COM+ applications, on the other hand, can be designed to take advantage of role-based security.) For more information, see COM Security Settings.

  • If your applications use distributed transactions, you should specify whether the Microsoft Distributed Transaction Coordinator (DTC) starts manually or automatically on each computer that runs it. Also, if transactions are used with Windows Clustering, you must configure the network appropriately. For more information, see Administering Distributed Transactions.

Installing and Configuring COM+ Applications

A COM+ application must be configured with settings specific to the services it needs to use, and then you can install its client-side and server-side portions to computers on the network. Prior to installing COM+ applications, you can optionally create COM+ partitions.

Following are examples of the types of tasks you might perform to install and configure COM+ applications:

  • Before you can make settings that govern how the COM+ application behaves on the network, you should install the application to a staging machine where you can configure it. For more information, see Staging and Production Computers.

  • To ensure that the application participates appropriately in your network's security scheme (that is, access both to the application and to other resources are appropriate to your needs), you may need to add users to the application's roles and set the application's security identity. For more information, see Administering Application Security.

  • When you have configured the COM+ application with respect to security and the services it needs to use, you must deploy its client-side and server-side portions to production computers across your network. Prior to installing COM+ applications, you can optionally create COM+ partitions. For more information, see Installing COM+ Applications.

Monitoring and Tuning Component Services

When you have deployed components that use Component Services, you can track those services to watch for performance enhancement opportunities and to handle failures. In some cases, changes you make to these settings—particularly to achieve more thorough monitoring—may actually decrease performance. Be sure to read the documentation for the area you are configuring.

Following are examples of the types of tasks you might perform to monitor your components and applications:

  • When a new version of a COM+ application is available, upgrading to the new version is a matter of removing the older version and installing the new one. For more information, see Installing COM+ Applications.

  • To enhance your control of security—for example, to keep objects from being accidentally or maliciously released too early—you can use reference tracking to make additional security checks and keep track of additional information. For more information, see Reference Tracking.

  • If applications participate in distributed transactions, you can monitor performance by viewing transaction status, messages, and statistics. Also, you may be able to increase system performance by changing the size or location of the log file that stores transaction statistics. For more information, see Monitoring DTC Performance and Configuring the DTC Log File.


Component Services Console Tree

You can use the console tree of the Component Services administrative tool to view the applications, components, and security roles that you can administer. This topic describes the main directories and subdirectories, as well as the icons, which are displayed in the console tree.

Directories and Subdirectories

Listed and described below are the various directories and subdirectories that appear in the console tree of the Component Services administrative tool.

Computers

This folder contains the My Computer icon and icons for other computers that have been added by an administrator.

My Computer

By default, the My Computer icon corresponds to the local computer on which the Component Services administration tool is installed.

COM+ Partitions

This folder contains the COM+ partitions into which COM+ applications are installed.

Note The COM+ Partitions folder appears on the console tree only when Enable partitions is selected on the Options tab of the properties page of My Computer.

Base Application Partition

This folder is a subdirectory of the COM+ Partitions folder. It contains systemwide COM+ application components that need to be accessible to all users in the domain. It is always present when COM+ partitions are enabled.

COM+ Applications

This folder contains the COM+ applications installed on this computer. You can change properties of an application by right-clicking the application and then clicking Properties. For more information on installing applications, see Installing COM+ Applications.

Components

This folder contains the configured components installed in a COM+ application. You can change properties of a component by right-clicking the component and then clicking Properties.

Legacy Components

This folder contains the unconfigured components installed in a COM+ application. You can change properties of a legacy component by right-clicking the component and then clicking Properties. You can promote a legacy component to a configured component by right-clicking the component and then clicking Promote.

Interfaces

This folder contains the interfaces available in a component. You can change properties of an interface by right-clicking the interface and then clicking Properties.

Subscriptions

This folder contains the subscriptions available in a component. You can change properties of an subscription by right-clicking the subscription and then clicking Properties.

Methods

This folder contains the methods available from a component's interfaces. You can change properties for a method by right-clicking the method and then clicking Properties.

Roles

This folder contains the roles available for a COM+ application. You can change properties of a role by right-clicking the role and then clicking Properties.

Users

This folder contains the list of users who are members of a role.

COM+ Partition Users

This folder contains the list of COM+ partition users. You can change the default partition assigned to those users by right-clicking the user and then clicking Properties.

Note The COM+ Partition Users folder appears on the console tree only when Enable partitions is selected on the Options tab of the properties page of My Computer.

DCOM Config

This folder allows you to view and modify the settings of individual COM applications. For example, if you need to increase the security settings of a COM application so that it runs properly when called by a COM+ application, you can change the security settings of the COM application in the DCOM Config folder rather than changing the machine-wide security settings.

Distributed Transaction Coordinator

In this folder, Transaction List displays current transactions in which the computer is participating and Transaction Statistics displays information about the transactions. For more information about the Microsoft Distributed Transaction Coordinator (DTC), see Administering Distributed Transactions.

Transaction List

This utility displays the current transactions in which this computer is participating. This includes transactions for which status is in doubt or which have remained in the same state for the transaction time-out period specified on the Options tab of the computer property sheet.

Transaction Statistics

This utility displays transaction information, such as performance, types, speed, and maximum and minimum response time for the transactions in which a computer participates.

Running Processes

This folder displays all COM+ application processes that are currently running.

Icons

Listed and described below are the various icons that appear in the console tree of the Component Services administration tool.

COM+ Icon | Description
Administrative Tools |
 | The Component Services administrative tool
Applications |
 | A COM+ library application
 | A disabled COM+ library application
 | A COM+ server application
 | A disabled COM+ server application
 | A COM+ service application
 | A disabled COM+ service application
 | A COM+ proxy application
Components |
 | A COM+ component
 | A disabled COM+ component
 | A 64-bit COM+ component
 | A disabled 64-bit COM+ component
Processes |
 | A running process
 | A process that is undergoing recycling
 | A paused process
Transactions |
 | A list of current transactions
 | A set of data about current and aggregate transactions
Other |
 | A COM+ partition
 | A COM+ interface
 | A COM+ method
 | A COM+ user
 | A COM+ security role that has been assigned to a user
 | A COM+ subscription


Configuring the System for Component Services

After you install Microsoft Windows, you must configure the system for Component Services. Configuration involves enabling administrator control for the System Application. It also includes configuring Component Services to recognize your network by making computers visible to Component Services and enabling component communication across machine boundaries by configuring distributed COM (DCOM). These configuration requirements are crucial to proper administration of Component Services.

Before You Continue

Depending on your system's needs, it might be necessary to perform configuration tasks beyond those described in the topics of this section. Although you may be able to configure the following properties at a later date, it is important to be aware of them early.

  • The Component Services administrative tool requires the Microsoft Distributed Transaction Coordinator (DTC) service to be running, so you need to configure the DTC. For more information, see Administering Distributed Transactions.

  • If enhancing system scalability is a goal for you, you can configure Component Services to shut down application processes that are not being used. For more information, see Setting the Server Process Shutdown.
Topic | Description
System Configuration Concepts | Provides a list of tasks for system configuration, along with links to step-by-step descriptions.
System Configuration Tasks | Provides links to step-by-step descriptions.


System Configuration Concepts

This section provides a general overview of the initial system configuration tasks you must perform for the Component Services administrative tool after you have installed Windows. For detailed information about performing each task, see System Configuration Tasks.

Note The Component Services administrative tool requires the Microsoft Distributed Transaction Coordinator (DTC) service to be running. If the DTC is stopped and you attempt to change any settings using the Component Services administrative tool, the DTC service is restarted. If you get errors when attempting to use the Component Services administrative tool, verify that the DTC is started and if not, restart it. For more information about starting and stopping the DTC, see Starting and Stopping the DTC.

Setting Control on the System Application

The System Application, located in the COM+ Applications folder of the Component Services administration tool, manages configuration and deployment within Component Services. To guard access to this important application, you must define who can administer the environment. This step is necessary for making any changes to your Component Services configuration, including installing an application or adding a computer.

The System Application uses role-based security with roles such as Administrator, Reader, Server Application, Any Application, and QC Trusted User. Members of the Administrator role have read and write access to the System Application. They can add, change, or delete any of the settings in the Component Services administrative tool. Only members of the Administrator role can install COM+ applications on the system. By default, the local Administrators group is the only member of this role. Only users who belong to the local Administrators group can be added to the Administrator role.

Warning You must assign at least one user or group to the Administrator role; otherwise, no one can administer Component Services.

Members of the Reader role have read-only access to the System Application. They can view settings in the Component Services administrative tool, but they cannot change, add, or delete anything. By default, Everyone belongs to this role, meaning that anyone who has access to the computer can view the Component Services settings.

Note For security reasons you might not want Everyone to be able to view the Component Services settings. If so, you should delete Everyone from the Reader role and add only those users who should be allowed read access to the Component Services settings. You must restart the computer for the changes to take effect.

Members of the Server Application role are allowed to run COM+ server applications, while members of the Any Application role are allowed to run both COM+ server and COM+ library applications. By default, Everyone belongs to each role.

Members of the QC Trusted User role are trusted to transmit messages for queued components on behalf of other users. By default, this role has no members.

Note Members of the QC Trusted User role are allowed to specify an arbitrary identity, which means that a malicious member could execute a queued component call with elevated privileges. It is therefore recommended that the number of such users be kept to an absolute minimum. For more information about security considerations when using COM+ Queued Components, see Administering Queued Components.

For instructions on setting administrative security on the System Application, see Setting Administrative Security. For additional information about security, see Administering Application Security and Administering Trustworthy Computing.

Making Computers Visible to Component Services

Any computer you want to administer for Component Services should be added to the console tree of the Component Services administrative tool. Unless a computer is visible to the Component Services administrative tool, you cannot set security or install applications for it. For instructions on adding computers to Component Services, see Making Computers Visible to Component Services.

Configuring Distributed COM

The distributed COM (DCOM) wire protocol handles all network communication between COM components running on separate computers. You must enable DCOM for each computer with COM components that communicate with others across the network. Although disabling DCOM has no effect on communication between components on the same computer, all communication is disabled between components on separate computers. For instructions on enabling component communication across machine boundaries, see Enabling or Disabling Distributed COM.


System Configuration Tasks

The following topics in this section provide detailed information about performing the required tasks for initial system configuration:

  • Setting Administrative Security

  • Making Computers Visible to Component Services

  • Enabling or Disabling Distributed COM

For overview information about these tasks, see System Configuration Concepts.


Setting Administrative Security

The System Application, located in the COM+ Applications folder in the console tree of the Component Services administrative tool, manages configuration and deployment within Component Services. The default Authentication Level that the System Application uses for calls is Packet Privacy, which provides the highest level of security.

Note For security reasons it is strongly recommended that the Authentication Level of the System Application remain at its default value of Packet Privacy.

To enable any changes to the system, such as installing a COM+ application or adding a computer, security must be set to define who can administer the environment. The following procedure describes how to enable security on the System Application by defining who belongs to the Administrator role. Only members of the Administrators group on your computer can belong to the Administrator role of the System Application.

Warning To enable administrative security on the System Application, you must assign at least one user or group to the Administrator role. If you do not, no one can administer Component Services.

Note Users in the Administrator role for the System Application must be members of the local administrators group.

To assign a user to the Administrator role of the System Application

  1. In the console tree of the Component Services administrative tool, expand the COM+ Applications icon.

  2. Expand the System Application icon.

  3. Expand the Roles icon.

  4. Expand the Administrator icon.

  5. Right-click the Users folder in the role, point to New, and then click User.

  6. In the Select Users or Groups window, in the bottom pane, type the fully qualified name of the user or group you want to add. If you do not know the name, do the following:
    1. Click the Locations button in the Select Users or Groups window.

    2. When the Locations window appears, select the appropriate domain and click OK to close the Locations window.

    3. In the Select Users, Computers, or Groups window, click the Advanced button.

    4. In the expanded Select Users, Computers, or Groups window, click Find Now to view a list of users and groups in the selected domain.

    5. Select a user or group from the Name (RDN) list, and click OK.
  7. To add more user accounts or groups, repeat steps 5 and 6.

  8. Restart the computer for the changes to take effect.

If you need to remove a user or group from the Administrator role of the System Application, see Removing a User Account or Group from a Role.


Making Computers Visible to Component Services

If you have sufficient privileges on a remote computer, you can manage its COM+ applications and monitor its transactions from the Component Services administrative tool on your own computer.

To add a remote computer to the Component Services administrative tool hierarchy

  1. In the console tree of the Component Services administrative tool, right-click the Computers icon, point to New, and then click Computer.

  2. In the Add Computer dialog box, type the name of the computer to add. If you do not know the name, do the following:
    1. Click the Browse button, and then click the Advanced button in the Select Computer window.

    2. Narrow the search for the computer by filling as many fields as possible under the Common Queries tab, and click Find Now to view a list of computers that meet the criteria you specified.

    3. Select a computer from the Name (RDN) list, and click OK to return to the Add Computer dialog box.
  3. Click OK.

After you have added the computer to the console tree, an icon representing it appears in the details pane. Using the Component Services administrative tool, you can now manage objects on the remote computer in the same way you manage objects on the local computer.

You can also remove a remote computer from the Component Services administrative tool hierarchy.

To remove a remote computer from the Component Services administrative tool hierarchy

  1. In the console tree of the Component Services administrative tool, click the Computers icon.

  2. In the details pane, select the computer or computers you want to remove.

  3. Press the Delete key, or alternatively, right-click the computer you want to remove and click Delete.


Enabling or Disabling Distributed COM

If the computer using Component Services is part of a network, Component Services needs the DCOM wire protocol to communicate with COM components on other computers. In a Windows-based system, by default, network computers are initially configured to enable DCOM. You can disable DCOM, but doing so disables communication with components on other computers.

Warning If you disable DCOM on a remote computer, you cannot remotely access that computer afterwards to enable DCOM again. To enable DCOM again, you need physical access to that computer.

To enable or disable DCOM

  1. In the Computers folder of the console tree of the Component Services administrative tool, right-click the computer for which you want to disable or enable DCOM and then click Properties.

  2. Click the Default Properties tab.

  3. To enable DCOM, select the Enable Distributed COM on this computer check box; to disable DCOM, clear this check box.

  4. Click OK.


Administering COM+ Applications

COM+ extends the component programming model by allowing you to easily add useful functionality to a configured component. The added functionality includes role-based security, queuing, process recycling, and accessibility via SOAP.


Installing COM+ Applications

Many of the tasks performed by system administrators relate to installing server applications on staging and production computers, installing application proxies on client computers, and removing or updating applications. Much of this work can be performed through the Component Services administrative tool. All of these tasks can also be automated through the Microsoft® Windows® Scripting Host.

Before You Continue

Installing a COM+ application typically involves working with components and prebuilt COM+ applications on a staging computer that is used to develop and test the application. For more information about staging computers, see Staging and Production Computers.

Before you begin the installation process, you need to use the Component Services administrative tool (running on the staging computer) to configure security, such as setting identities and assigning users to roles. For more information, see Administering Application Security.

You should also set the server process shutdown so that there is a time frame in which the server process is terminated after remaining idle.

Finally, you might want to create COM+ partitions into which to install your COM+ applications. COM+ partitions allow you to install multiple configurations of a COM+ application on the same machine. For more information, see Administering COM+ Partitions.

The topics described in the following table provide background and task information related to installing COM+ applications. For a general description of COM+ applications, see Guide to Administering Component Services.

Topic | Description
Installation Concepts | Provides an introduction to COM+ application installation.
Installation Tasks | Describes the tasks associated with installing COM+ applications.


Installation Concepts

Using the Component Services administrative tool to install COM+ applications requires certain system security permissions. For information about security implications when installing these applications, see Setting Administrative Security.

In addition to security, other configuration tasks must be completed before installing COM+ applications by using the Component Services administrative tool. For more information about configuring the Component Services environment, see Component Services Administrative Tasks Overview.

The topics described in the following table provide general information about installation considerations for COM+ applications.

Topic | Description
Staging and Production Computers | Introduces the concept of using a different set of computers for development and testing versus the computers used for final application deployment.
COM+ Application Installation Overview | Provides an overview of installation scenarios, along with links to step-by-step details.
Server-Side Installation for COM+ Applications | Provides a brief overview related to installing server-side components that might require the installation of other resources, such as database connections.
Client-Side Installation for COM+ Applications | Provides an overview related to installing client-side components.


Staging and Production Computers

It is useful to install and test applications on a staging environment that allows you to simulate scenarios that are likely to occur after applications are deployed on production computers used by others on the network.

Staging environments can be used to manage versioning and to update components. Rather than changing configurations or updating individual components on a production computer, you can modify the application, test it on a staging environment, and then export it as a unit to be installed on the production computer.

Using COM+ partitions, you can configure staging and production environments on the same computer. For more information, see Administering COM+ Partitions.

In some cases, the configuration is identical between the staging and production environments and the only difference is that the staging environment is not publicly accessible. In these cases, you can replicate the applications, moving a validated set of applications and their configuration from a staging to a production environment. For more information about replication, see Replicating COM+ Applications.


COM+ Application Installation Overview

COM+ applications can be developed in-house, where the developer has full knowledge of the target environment (user accounts, user groups, server names, and so on). The developer configures and exports the application, and the administrator needs only to install the application on the target system.

COM+ applications can also be purchased from a third-party application vendor. If the application vendor does not provide a regular installation program that guides you through the required steps, you must install and configure the COM+ application yourself.

Configuring the COM+ application is often performed on a staging computer rather than on the production computer. If a staging computer is used, you must export the configured COM+ application and a COM+ application proxy from the staging computer and install them on the production computers. For more information, see Staging and Production Computers.

Manually installing a COM+ application includes the following steps. Depending on how the application vendor or developer chooses to provide the application, not all of these steps may be required. For more information, refer to the documentation provided with the application.

  1. On the staging computer, configure the COM+ application for a specific target environment.

  2. Export environment-specific client-side and server-side installation files from the staging computer.

  3. Install the COM+ application or COM+ application proxy on the production computers.

For step-by-step details about installing applications, see Installation Tasks.

For an overview of configuration for COM+ applications, see Component Services Administrative Tasks Overview.

Updating COM+ Application Versions

As COM+ applications become dated or are no longer used, you need to update or remove them. If you want to upgrade a COM+ application, you must first delete the previously installed version and then install the updated application.

For step-by-step details, see Removing COM+ Applications and Installing COM+ Applications.


Server-Side Installation for COM+ Applications

All of the necessary information for a COM+ server application is contained in a server application file (.msi). The Component Services administrative tool or the Windows Installer can be used to install the COM+ application from the .msi file.

To prevent unauthorized modifications of your exported applications, you should store server application files only in directories with restricted write permissions. For additional security, sign your server application files using Microsoft® Authenticode®.

If a component in a COM+ application requires the installation or configuration of other resources—database connections, data or text files, Internet Information Services (IIS) virtual root configuration, and so on—these must be installed using tools or utilities other than the Component Services administrative tool.

For step-by-step details about application installation, see Installing COM+ Server Applications.


Client-Side Installation for COM+ Applications

After a COM+ server application is installed on a computer, it may be necessary to access the application remotely by using DCOM or Message Queuing.

If an application is to be accessed remotely, you can use the Component Services administrative tool to export a COM+ application proxy. The application proxy file (.msi) contains the information needed to remotely access classes in a COM+ server application from a client computer through DCOM. Using this file with the Component Services administrative tool, you can install the COM+ application proxy on the site's client computers.

It is possible to create an application proxy that accesses a different server than the computer from which it was exported. This is useful when the application proxy for a production computer needs to be exported from a staging computer. To change the server name, click the Options tab of the computer properties page in the Component Services administrative tool and enter the correct application proxy remote server name (RSN).

For step-by-step details about exporting and installing application proxies, see Exporting COM+ Application Proxies and Installing COM+ Application Proxies.


Installation Tasks

The following topics describe COM+ application installation tasks you may need to perform. These tasks are typically done in the order listed here.

  • Creating a New COM+ Application

  • Exporting COM+ Server Applications

  • Installing COM+ Server Applications

  • Exporting COM+ Application Proxies

  • Installing COM+ Application Proxies

  • Removing COM+ Applications

  • Replicating COM+ Applications


Creating a New COM+ Application

You can use the Component Services administrative tool to create new, empty COM+ applications. To perform this procedure, you must be a member of the Administrator role on the target computer's system application. In the default configuration, only local computer administrators are assigned to this role. For more information, see Setting Administrative Security.

Important You can install a COM+ server application only on computers running Microsoft® Windows® 2000 or later. A server application requires a platform that supports Component Services.

The minimum configuration for an application is one in which security is not required. If security is required for the application, use the Component Services administrative tool to set process-level security or add users to predefined roles after the application has been created. See Administering Application Security for more information about how to configure security for your application.

Note To allow unauthenticated network users to run a COM+ application, the application roles must include the Anonymous user. In Windows Server 2003, by default, the Anonymous user is not included in the Everyone group.

To create a new COM+ application using the Component Services administrative tool

  1. In the console tree of the Component Services administrative tool, under Component Services, locate the COM+ Applications folder associated with the computer on which you want to install the application.

    Note If you have the COM+ partitions feature enabled, you can locate the COM+ Applications folder in the COM+ Partitions folder for the computer on which you want to install the application. For more information about the COM+ partitions service and instructions for enabling it on your system, see Administering COM+ Partitions.

  2. Right-click the COM+ Applications folder, point to New, and click Application.

  3. On the COM+ Application Install Wizard, click Next.

  4. In the Install or Create a New Application dialog box, click Create an empty application.

  5. In the Create an empty application dialog box, enter a name for the new application and choose whether the applications components, when called, must be activated in the caller's process (Library application) or in a separate, dedicated server process (Server application). Click Next.

  6. In the Set Application Identity dialog box, specify the application identity and click Next.

    Note The default selection is Interactive User. The interactive user is the user who is logged on to the Windows account for the computer that runs the application. You can choose a different user by selecting This user and entering details for a specific Windows user or group.

  7. In the Add Application Roles dialog box, specify any roles you want to create for the application. By default, a single role named CreatorOwner is created. Click Next.

  8. In the Add Users to Roles dialog box, add the desired users to the roles you have created. By default, your user account is added to the CreatorOwner role. Click Next.

  9. Click Finish.

The hierarchy in the console tree now shows the new application in the detail pane.


Exporting COM+ Server Applications

You can use the Component Services administrative tool to export a COM+ server application for installation on one or more other server computers. For example, you can use the Component Services administrative tool to export a COM+ application from a staging computer, on which the application was developed and tested, to a production computer at an individual site.

Note Application locks against changes or deleting are exported with the application.

Important You can install a COM+ server application only on computers running Microsoft® Windows® 2000 or later. A server application requires a platform that supports Component Services. Therefore, if you want to install a COM+ application on a computer running Microsoft Windows NT®, Microsoft Windows 98, or Microsoft Windows 95, you must export the application as an application proxy rather than as a server application. See Exporting COM+ Application Proxies for more information.

To export a COM+ server application

  1. In the console tree of the Component Services administrative tool, click the COM+ application you want to export.

  2. Right-click the application, and then click Export.

  3. In the initial dialog box for the COM+ Application Export Wizard, click Next.

  4. In the Application Export Information dialog box, enter the full path of the application file to be created. If you do not know the full path, click Browse to locate an existing directory.

    Note A server application file (.msi) with the name you specify is created when you finish with the wizard. This file contains all the necessary information for the COM+ application.

    Security Note To prevent unauthorized modifications of your exported applications, export applications only to directories with restricted write permissions. For additional security, sign your application file (.msi) using Microsoft® Authenticode®.

  5. Under Export as in the Application Export Information dialog box, click Server application - Install this application onto other machines.

  6. If you want to include any users that you have assigned to roles for the application, select the Export user identities with roles check box.

    Note Use this option only if you plan to install the application on a computer that is running in the same Microsoft® Windows® security domain as the computer from which you are exporting the application. If not, the user IDs assigned to roles may be invalid, causing errors when you attempt to install the application. Additionally, be careful when installing the application on a computer running a different language version of Windows from that on the computer from which you are exporting the application. Some user and group names, such as Administrators, will be localized on the target computer. These users must be re-added to the role before they can access the application on the target computer.

  7. Click Next.

  8. In the closing dialog box, click Finish.

    Important If a component's class ID (CLSID), type library identifier (TypeLibId), or interface identifier (IID) changes after you have exported an application, you must export the application again and reinstall it. Other application characteristics (and the binary executable) can also require a reinstallation after re-exporting the application.


Installing COM+ Server Applications

You can use the Component Services administrative tool to install COM+ server applications. To perform this procedure, you must be a member of the Administrator role on the target computer's system application. In the default configuration, only local computer administrators are assigned to this role. For more information, see Setting Administrative Security.

Important You can install a COM+ server application only on computers running Microsoft® Windows® 2000 or later. A server application requires a platform that supports Component Services.

The minimum configuration for an application is one in which security is not required. If security is required for the application, use the Component Services administrative tool to set process-level security or add users to predefined roles after the application has been installed. See Administering Application Security for more information about how to configure security for your application.

Note To allow unauthenticated network users to run a COM+ application, the application roles must include the Anonymous user. In Windows Server 2003, by default, the Anonymous user is not included in the Everyone group.

To install a COM+ server application using the Component Services administrative tool

  1. In the console tree of the Component Services administrative tool, under Component Services, locate the COM+ Applications folder associated with the computer on which you want to install the application.

    Note If you have the COM+ partitions feature enabled, you can locate the COM+ Applications folder in the COM+ Partitions folder for the computer on which you want to install the application. For more information about the COM+ Partitions service and instructions for enabling it on your system, see Administering COM+ Partitions.

  2. Right-click the COM+ Applications folder, point to New, and then click Application.

  3. In the initial dialog box for the COM+ Application Install Wizard, click Next.

  4. In the Install or Create a New Application dialog box, click Install pre-built application(s).

  5. In the Install from application file dialog box, browse to select the .msi file for the application you are installing and then click Open.

  6. In the Select Application Files dialog box, click Add to browse for any additional applications you want to install and then click Next.

  7. In the Set Application Identity dialog box, specify the application identity and then click Next.

    Note The default selection is Interactive User. The interactive user is the user who is logged on to the Windows account for the computer that runs the application. You can select a different user by clicking This user and entering details for a specific Windows user or group.

  8. In the Application Installation Options dialog box, specify the directory in which to install the COM+ application and then click Next.

    The application's component files are copied from the .msi file to the installation directory. The default installation directory is:

    %Program Files%\COMPlus Applications\<appid>

    You can either accept the default directory or click Specific directory and Browse to search for another location.

    Note To perform this procedure, the application identity specified in step 8 must have at least read access to the installation directory, and the person running the Component Services administrative tool during this process must have write access to the installation directory.

  9. Click Finish.

The hierarchy in the console tree now shows the new application in the detail pane. If you install multiple applications, the options you choose in steps 8 and 9 apply to all the applications.

To install a COM+ server application using Windows Explorer

  1. On the computer on which you want to install the COM+ application, locate the server application file (.msi) using Windows Explorer. The file can reside locally or on a network share.

  2. Double-click the server application file. You can also right-click the filename and then click Install. The Windows installer automatically installs the server application on the target computer.

To install a COM+ server application using the command prompt

At the command prompt, type the following:

msiexec -i [<property overrides>] <application_name>.msi

In addition to the standard Windows Installer property overrides, you can specify the following option to change the installation directory for the COM+ application from the default to the specified directory:

TARGETDIR = <target installation directory>

Alternatives to These Procedures

You can install a COM+ application by dragging an application file from Windows Explorer to the details pane of the Component Services administrative tool while the COM+ Applications folder of a computer is open.


Exporting COM+ Application Proxies

You can use the Component Services administrative tool to export a COM+ application proxy. When the proxy is installed on client computers, client applications can use the proxy information to find and access, via DCOM, a COM+ server application running on a production computer.

Important If a component's class ID (CLSID), type library identifier (TypeLibId), or interface identifier (IID) changes after you have exported an application, you must export the application proxy again and reinstall it on the client computers.

To export a COM+ application proxy

  1. In the Component Services administrative tool console tree, right-click the application and then click Export.

  2. In the initial dialog box for the COM+ Application Export Wizard, click Next.

  3. In the Application Export Information dialog box, enter the full path of the application proxy file to be created or click Browse to locate an existing file or directory.

  4. Under Export as, click Application proxy - Install on other machines to enable access to this machine and then click Next.

  5. In the closing dialog box, click Finish.

By default, the application proxy file includes remote server information that points to the server computer from which the application proxy was exported. If you export an application proxy from a virtual server, by default the application proxy uses the physical node the virtual server was on when exporting as the remote server name. You can use the Component Services administrative tool to change the default remote server name.

The default remote server name in an application proxy file can also be overridden at installation time. See Installing COM+ Application Proxies for more information.

To specify an alternate remote server used by application proxies

  1. In the Component Services administrative tool console tree, right-click the computer from which you are exporting applications and click Properties.

  2. In the computer properties dialog box, click the Options tab.

  3. Under Export, in the Application Proxy RSN box, enter the name of the remote server computer to be used by application proxies.

  4. Click OK.


Installing COM+ Application Proxies

After the application proxy is created as a Windows Installer (.msi) file, it is easy to install it on a client computer. Installing the application proxy provides the registration information needed for client applications to access the COM+ application remotely from the client computer.

Important You can install a COM+ application proxy on any computer that's running the Windows Installer. The Windows Installer is automatically installed on all computers running Microsoft® Windows® 2000 or later and is available for computers running Microsoft Windows 95, Microsoft Windows 98, and Microsoft Windows NT® 4.0. However, if an application proxy requires the COM+ Queued Components service, this proxy can be installed only on a computer running Windows 2000 or later. The Queued Components service is available only on platforms that support Component Services.

To install a COM+ application proxy using the Component Services administrative tool

  1. In the console tree of the Component Services administrative tool, under Component Services, locate the COM+ Applications folder associated with the computer on which you want to install the application.

    Note If you have the COM+ Partitions service enabled, you can locate the COM+ Applications folder in the COM+ Partitions folder for the computer on which you want to install the application proxy. For more information about the COM+ Partitions service and instructions for enabling it on your system, see Administering COM+ Partitions.

  2. Right-click the COM+ Applications folder, point to New, and then click Application.

  3. In the initial dialog box for the COM+ Application Install Wizard, click Next.

  4. In the Install or Create a New Application dialog box, click Install pre-built application(s).

  5. In the Install from application file dialog box, browse to select the .msi file for the application proxy you are installing and then click Open.

  6. In the Select Application Files dialog box, click Add to browse for any additional application proxies you want to install and then click Next.

  7. In the Application Installation Options dialog box, specify the directory in which to install the COM+ application proxy and then click Next.

    The application's component files are copied from the .msi file to the installation directory. The default installation directory is:

    %Program Files%\COMPlus Applications\<appid>

    You can either accept the default directory or click Specific directory and Browse to search for another location.

    Note To perform this procedure, you must have write access to the installation directory.

  8. Click Finish.

The hierarchy in the console tree now shows the new application in the detail pane. If you install multiple applications, the directory you choose in step 8 is used for all the applications.

To install a COM+ application proxy using Windows Explorer

  1. On the client computer, locate the application proxy file (.msi) by using Windows Explorer. This file can reside locally or on a network share.

  2. Double-click the application proxy file. You can also right-click the filename and then click Install. The Windows Installer automatically installs the application proxy on the client computer.

To install a COM+ application proxy using the command prompt

At the command prompt, type the following:

msiexec -i [<property overrides>] <application_name>.msi

In addition to the standard Windows Installer property overrides, you can specify the installer options described in the following table.

Installer option | Description
REMOTESERVERNAME = <new target server> | Changes the server to which the client computer connects, from the exported default to the specified new target server.
ALLUSERS = 0 | Installs the application proxy only for the current user. By default, the application proxy is installed machine-wide.
TARGETDIR = <target installation directory> | Changes the installation directory for the COM+ application from the default to the specified directory.


Removing COM+ Applications

As existing applications become outdated or are no longer being used, you may need to remove them. Deleting the application also deletes any components contained in the application. If these components depend on additional resources (database connections, data or text files, IIS virtual root configuration, and so on), these resources must be removed by using tools or utilities other than the Component Services administrative tool.

Note If you delete a COM+ server application while it is running, the application shuts down without warning prior to being deleted.

To delete a COM+ application using the Component Services administrative tool

  1. In the console tree of the Component Services administrative tool, double-click the computer for which you want to delete an application.

  2. Double-click the COM+ Applications folder for the specified computer to display all the applications.

  3. Click the application you want to remove.

  4. If you selected a server application, shut down the application. To do this, right-click the application and then click Shut down. If you selected a library application, make sure that all processes currently using this library application are shut down.

  5. Right-click the application. If Delete is not visible as an option when you right-click the application, you must enable deletion of the application by doing the following:
    1. Right-click the application and then click Properties.

    2. In the application properties page, select the Advanced tab.

    3. Under Protection, uncheck the Disable deletion check box.

    4. Click OK.
  6. Right-click the application and then click Delete.

  7. Click Yes in the Confirm Item Delete dialog box to remove the application.

The following procedures are especially useful for deleting COM+ applications on client computers that are not running the Component Services administrative tool.

To delete a COM+ application using Windows Explorer

  1. On the computer on which you want to delete the COM+ application, use Windows Explorer to locate the server application file (.msi) or application proxy file (.msi).

  2. Right-click the .msi file, and then click Uninstall. The Windows installer automatically deletes the application.

To delete a COM+ application using the command prompt

At the command prompt, type the following:

msiexec -x <application_name>.msi

Alternatives to These Procedures

You can delete a COM+ application by using the Add or Remove Programs utility from the Control Panel.


Replicating COM+ Applications

You may need to replicate all COM+ applications and their configurations from one computer (master) to another computer (replication target). Replication is useful for the following scenarios:

  • Web farm

  • Failover cluster

  • Staging to production

You could replicate applications manually by repeatedly exporting and then installing each of the applications on the master computer. However, you might find that it is simpler to perform this rather tedious and error-prone task with a replication utility (comrepl.exe) for COM+ applications provided by Microsoft® Windows® 2000 and later. This replication utility copies all the COM+ applications from a master computer to a target computer. It also replicates all computerwide COM+ configurations.

To use the comrepl utility, type the following at the command prompt:

comrepl <sourceComputer> <targetComputerList> [/n [/v]]

The command-line parameters are described in the following table.

Parameter | Description
<sourceComputer> | Computer name of the source.
<targetComputerList> | Computer names of the targets separated by spaces.
/n | Suppress confirmation prompt before starting replication.
/v | Echo log file output to the console.

Notes

  • All target computers must already have Component Services installed because only configuration data and applications are replicated, not Component Services.

  • The user must pass role checks for the system application on both the source and the target computers.

  • No local machine accounts that may be used by roles are replicated.

  • The target computer(s) must be online.

  • The user is responsible for replicating all data that is not related to Component Services (for example, database tables, data files, and so on) to the target computers.

  • The target computer is identified by its name only.


Administering the Operation of COM+ Applications

The Component Services administrative tool provides useful features for administering the operation of COM+ applications. These features provide flexibility for debugging and troubleshooting applications and can be useful during application deployment as well.

The topics described in the following table provide background concepts related to running COM+ applications and explain how to use the Component Services administrative tool to configure the operation of COM+ applications.

Topics | Descriptions
Application Operation Concepts | Provides a conceptual description of running COM+ applications.
Application Operation Tasks | Provides a step-by-step procedure for configuring the operation of COM+ applications.


Application Operation Concepts

The Component Services administrative tool helps you improve the operation of COM+ applications by providing more flexibility for debugging and troubleshooting those applications. COM+ also provides an automatic low-memory activation gates feature for ensuring that there is sufficient memory before activating objects and processes. This memory-protection service is automatic, and no administrative tasks are associated with it.

The topics described in the following table provide general information about running and administering the operation of COM+ applications.

Topic | Description
Controlling COM+ Application Operation | Provides an overview related to improving the operation of COM+ applications, especially when debugging and troubleshooting.
Low-Memory Activation Gates | Describes an automatic COM+ feature for ensuring that there is sufficient memory before activating objects and processes.


Controlling COM+ Application Operation

A system administrator can use the Component Services administrative tool to quickly shut down or start COM+ server applications. The administrator also can use this tool to easily disable and enable COM+ library or server applications or to easily pause and resume COM+ server applications.

Note The pause-and-resume capability applies only to a particular COM+ server process. The disable-and-enable capability applies to both COM+ library and COM+ server applications.

Shutting Down and Starting COM+ Server Applications

An administrator should shut down a COM+ server application only if the entire process needs to be shut down. Otherwise, using the shutdown feature is not an efficient way to handle applications. If any cross-process or cross-machine references to objects exist when the process shuts down, any calling programs are likely to get unexpected errors. Furthermore, after an application is shut down, the next activation simply starts it up again.

To avoid these shutdown errors, an administrator can disable a COM+ application, pause a COM+ server application, or use application recycling, which shuts down the application while continuing to service existing objects.

For step-by-step instructions, see Shutting Down and Starting COM+ Server Applications.

Setting the Server Process Shutdown

An administrator can configure a server process to shut down after remaining idle for a certain amount of time. This is a useful way to automatically free up resources that are no longer needed.

For step-by-step instructions, see Setting the Server Process Shutdown.

Disabling and Enabling COM+ Applications

The disable-and-enable feature in COM+ offers an administrator the ability to stop a library or server application until further notice. Disabling a COM+ application prevents errors that would occur by using the shutdown method when you need to install new applications or software, upgrade applications, or install new hardware.

When an application is disabled, activations of components within the application are rejected. Even if the computer is rebooted, activations continue to be rejected because the system remembers the disabled state of the application, which is stored in the COM+ configuration database. Activations are serviced only after an administrator enables the application.

An administrator can install new applications in disabled mode instead of using shutdown. Installing applications in disabled mode prevents applications from accepting activations and running during the installation process. When all of the applications have been installed, you can enable the applications.

When upgrading COM+ library applications, disabling them is more advantageous than just shutting them down. For example, if a brokerage wants to release a new version of its trading application, the application can be disabled without disrupting trades in process. Component Services generates a message saying that the application is disabled, and the application can then notify customers that trading is temporarily disabled. After the existing trading activities are completed, the system administrator can shut down the application, replace the DLL, and then enable the application. Also, if necessary, the administrator can add new hardware and then configure the application, all without the threat of incoming activations. Finally, the administrator can reboot the database server that the application depends on while the application is disabled.

For step-by-step instructions, see Disabling and Enabling COM+ Applications.

Pausing and Resuming COM+ Server Application Processes

By temporarily stopping COM+ server applications from accepting activations, the server application pause-and-resume feature allows for easy debugging of the application. For example, if an administrator notices that something is wrong with an object service on a particular client, the administrator can disable the application that is broken. If an administrator realizes that one of the server processes servicing that application seems to be broken, the administrator can pause the server process and re-enable the application. Activations are then routed to the other servers, and the administrator can keep the broken process for debugging.

The server application pause-and-resume feature can also be used to recycle the Queued Components listener. If a COM+ queued application is started but its listener is not started, you can activate the Queued Components listener, pause and resume the application, and the Queued Components listener then starts. Similarly, you can deactivate the Queued Components listener, pause and resume the application, and the Queued Components listener stops after completing the processing of those messages whose processing had already started. For more information on the COM+ Queued Components service, see Administering Queued Components.

When you pause a server application process, it rejects any further activation and it continues to service method calls on objects that have already been created. However, the activity that was interrupted is not stored in the configuration database; therefore, if you reboot the computer before saving the changes, any changes made to the database during the pause state are erased.

Note The server application pause-and-resume capability is process-specific. That is, if a computer is rebooted or if another server is created that implements the application, any activations sent to the server are serviced—which can result in more errors. COM classes added to a COM+ application and COM+ library applications do not support the server application pause-and-resume feature.

For step-by-step instructions, see Pausing and Resuming COM+ Server Application Processes.


Low-Memory Activation Gates

Reliability problems often occur when a server's resources cannot react efficiently to peak loads. When a server doesn't have enough physical resources to meet peak demand, it can exhaust virtual memory. This becomes a problem if the user code or system code does not properly handle memory allocation failures. The server begins to slow down, and as memory is exhausted, memory allocations fail. The server executes error paths to handle the allocation failures. If an error path contains a bug in the system or user code running on the server, it's extremely difficult to trap and handle safely.

COM+ attempts to prevent situations in which these error paths have to be executed on a server. Through the low-memory activation gates feature, COM+ proactively monitors memory load in the system and ensures that a reasonable amount of memory is available before executing user code. If the percentage of virtual memory available to the application falls below a fixed threshold, the activation fails before a COM+ server application or object is created (as shown in the illustration below). By failing these activations that would normally run, the low-memory activation gates feature minimizes the problems associated with memory allocations in user code, which significantly enhances system reliability.

The low-memory activation gates feature applies only to configured COM components that are installed in a COM+ application.

How the Low-Memory Activation Gates Feature Works

The low-memory activation gates feature uses a different fixed threshold level depending on the type of activation. When creating a COM+ server application, COM+ allows the activation if more than 10 percent of virtual memory is available. If less than 10 percent is available, COM+ makes a test allocation to find out if the paging file can expand to accommodate the new memory load. If the paging file expands, the server application is created. If the paging file cannot be expanded, the activation fails and memory is not allocated.

The process is similar when creating an object. In this case, COM+ allows the activation if more than 5 percent of virtual memory is available. If less than 5 percent is available, COM+ proceeds with a test allocation. Again, if the test allocation expands the paging file, the object is created. If not, the activation fails.

The fixed threshold levels for low-memory activation gates are currently not configurable. For this reason, there are no procedures associated with this feature under Application Operation Tasks.


Application Operation Tasks

The following topics describe COM+ application operation tasks you may need to perform:

  • Shutting Down and Starting COM+ Server Applications

  • Setting the Server Process Shutdown

  • Disabling and Enabling COM+ Applications

  • Pausing and Resuming COM+ Server Application Processes


Shutting Down and Starting COM+ Server Applications

An administrator should shut down a COM+ server application only if the entire process needs to be shut down. Otherwise, using the shutdown feature is not an efficient way to handle applications. To avoid shutdown errors, you can disable a COM+ application, pause a COM+ server application process, or use application recycling, which shuts down the application while continuing to service existing objects.

For more information about shutting down and starting COM+ server applications, about the advantages of disabling and enabling applications, or about the advantages of pausing and resuming server application processes, see Application Operation Concepts.

The following procedures describe how to shut down and start a COM+ server application.

To shut down a COM+ server application

  1. In the console tree of the Component Services administrative tool, click the COM+ server application you want to shut down.

  2. Right-click the COM+ application, and then click Shut down.

To start a COM+ server application

  1. In the console tree of the Component Services administrative tool, click the COM+ server application you want to start.

  2. Right-click the COM+ application, and then click Start.


Setting the Server Process Shutdown

An administrator can configure a server process to shut down after remaining idle for a certain amount of time. This is a useful way to automatically free up resources that are no longer needed.

The following procedure describes how to set the server process shutdown.

To set the process shutdown of a COM+ server application

  1. In the console tree of the Component Services administrative tool, locate the COM+ server application whose process shutdown you want to set.

  2. Right-click the application, and then click Properties.

  3. In the application properties dialog box, click the Advanced tab.

  4. Under Server Process Shutdown, select one of the following:
    • Leave running when idle This setting indicates that the server processes do not time out and automatically shut down. Instead, the processes must be manually shut down.

    • Minutes until idle shutdown In the textbox to the right of this selection, enter the number of minutes that the server processes must be idle before timing out and automatically shutting down. The valid range is 1 through 1440 minutes (24 hours), and the default is 3 minutes. Paused processes do not time out while they are paused, but they can reach a state where they time out as soon as they are resumed.
  5. Click OK.

The server process shutdown settings take effect the next time the application is started.


Disabling and Enabling COM+ Applications

The disable-and-enable feature in COM+ provides an administrator the ability to stop a library or server application until further notice. Disabling a COM+ application prevents errors that would occur by using the shutdown method when you need to install new applications or software, upgrade applications, or install new hardware.

For more information about the advantages of disabling and enabling COM+ applications, see Application Operation Concepts.

The following procedures describe how to disable and enable COM+ applications.

To disable a COM+ application

  1. In the console tree of the Component Services administrative tool, click the COM+ application you want to disable.

  2. Right-click the COM+ application, and then click Disable.

To enable a COM+ application

  1. In the console tree of the Component Services administrative tool, click the COM+ application you want to enable.

  2. Right-click the COM+ application, and then click Enable.


Pausing and Resuming COM+ Server Application Processes

By temporarily stopping COM+ server applications from accepting activations, the server application pause-and-resume feature allows for easy debugging of the application. When you pause a server application process, it rejects any further activation and continues to service method calls on objects that have already been created. However, the activity that was interrupted is not stored in the configuration database.

For more information about the advantages of pausing and resuming COM+ server application processes, see Application Operation Concepts.

The following procedures describe how to pause and resume COM+ server application processes.

To pause a COM+ server process

  1. In the Component Services administrative tool, double-click the Running Processes folder of the computer running the server application you want to pause.

  2. Right-click the process that you want to pause, and then click Pause.

To resume a COM+ server process

  1. In the Component Services administrative tool, double-click the Running Processes folder of the computer running the server application you want to resume.

  2. Right-click the paused process that you want to resume, and then click Resume.


Administering Application Pooling

The COM+ Application Pooling service enhances system reliability by allowing single-threaded processes to scale, similar to the way that thread pooling allows single-threaded objects to scale. Application pooling can also help recover from failures in single processes by providing other running processes able to handle activations.

The topics described in the following table provide background and task information about using COM+ Application Pooling.

Topics | Descriptions
Application Pooling Administration Concepts | Provides a conceptual description of pooling COM+ applications.
Application Pooling Administration Tasks | Provides a step-by-step procedure for configuring the pooling of COM+ applications.


Application Pooling Administration Concepts

The COM+ Application Pooling service enhances system reliability by allowing single-threaded processes to scale, similar to the way that thread pooling allows single-threaded objects to scale. This is especially helpful in situations when legacy code (where no threading model is defined) must run in the main single-threaded apartment.

Application pooling can also help recover from failures in single processes by providing other running processes able to handle activations. For example, if there are three running processes for a single application and one process fails, the other processes are unaffected and the possible loss of work is minimized. If the COM+ Application Recycling service is also enabled, application pooling further ensures reliability and stability because only one of the specified number of running processes is recycled at any one time.

Note Library applications have the recycling and pooling properties of their host process.

With the COM+ Application Pooling service, you can use the Component Services administrative tool to specify multiple server processes, which then effectively act as a single application. When the application starts, COM+ creates a specified number of Dllhost processes, and these processes simultaneously service activations for the application. Any instance of the Dllhost process can service any call to the server application.

To configure application pooling with the Component Services administrative tool, you simply enter an integer value in the Pool Size field on the Pooling & Recycling property page. This value specifies the maximum number of simultaneous Dllhost processes that should be started to service activations for an application. If the Pool Size field is set to 1, which is the default value, the COM+ Application Pooling service is disabled.

For step-by-step instructions on configuring application pooling with the Component Services administrative tool, see Configuring Application Pooling. You can also configure application pooling programmatically by using the COM+ Administrative SDK.


Application Pooling Administration Tasks

The following topic in this section provides a step-by-step procedure for configuring application pooling by using the Component Services administrative tool:

Configuring Application Pooling


Configuring Application Pooling

You can use the Component Services administrative tool to configure application pooling for COM+ applications. For more information about the background concepts related to application recycling, see Application Pooling Administration Concepts.

To configure application pooling for a COM+ application

Note Library applications have the recycling and pooling properties of their host process.

  1. In the console tree of the Component Services administrative tool, right-click the COM+ application you want to pool and then click Properties.

  2. On the Pooling & Recycling tab, under Application Pooling, enter a value for Pool Size, depending on the number of instances of your application that you want to have running. If Pool Size is set to 1, which is the default value, the COM+ Application Pooling service is disabled.

  3. Click OK.


Administering Application Recycling

Application recycling is an efficient way of improving application stability by configuring COM+ to automatically shut down and restart applications.

The topics described in the following table provide background concepts related to application recycling and explain how to use the Component Services administrative tool to configure the recycling of COM+ applications.

Topics | Descriptions
Application Recycling Administration Concepts | Provides a conceptual description of recycling COM+ applications.
Application Recycling Administration Tasks | Provides a step-by-step procedure for configuring the recycling of COM+ applications.


Application Recycling Administration Concepts

Application recycling can significantly increase the overall stability of your applications by offering a quick fix for known problems and a safeguard against unexpected ones. Application performance can degrade over time because of application problems such as memory leaks, nonscalable resource usage, and process failures. COM+ provides application recycling as a solution to shut down a process automatically and restart it, thus reinitializing a failing process and reallocating memory it uses.

Application recycling works by creating a duplicate of the Dllhost process associated with an application. This duplicate Dllhost process services all future object requests, which leaves the old Dllhost to finish servicing the remaining object requests. The old Dllhost process is shut down when it detects the release of all external references to objects in the process or when the expiration time-out value is reached. Through this behavior, application recycling ensures that a client application never experiences a service interruption.

You can configure application recycling administratively, by using the Component Services administrative tool, or programmatically, through the COM+ administrative SDK. You can recycle processes based on several criteria, including the following:

  • A specified number of minutes that a Dllhost process runs before recycling

  • A specified amount of memory usage that a Dllhost process cannot exceed

  • The number of calls to configured objects in the Dllhost process

  • A specified number of Dllhost process activations

You can select more than one criterion for recycling a process. COM+ recycles the process after the first of the set of criteria is satisfied. You can set the expiration time-out value to determine how long an old Dllhost process can spend completing remaining service requests before being forcibly shut down.

Note You cannot recycle a COM+ application that has been configured to run as a Windows service.

For specific information about configuring application recycling, see Configuring Application Recycling.


Application Recycling Administration Tasks

The following topic in this section provides a step-by-step procedure for configuring application recycling by using the Component Services administrative tool:

Configuring Application Recycling


Configuring Application Recycling

You can use the Component Services administrative tool to configure application recycling for COM+ applications. For more information about the background concepts related to application recycling, see Application Recycling Administration Concepts.

To configure application recycling for a COM+ application

Note You cannot recycle a COM+ application that has been configured to run as a Windows service.

  1. In the console tree of the Component Services administrative tool, right-click the COM+ application you want to be recycled and then click Properties.

  2. On the Pooling & Recycling tab, enter values for Lifetime Limit (minutes), Memory Limit (KB), Expiration Timeout (minutes), Call Limit, and Activation Limit, depending on the criteria you want to use.

    Note When the Lifetime Limit, Memory Limit, Call Limit, or Activation Limit value is set to 0 (the default value), application recycling for that criterion is disabled. When all four of these criteria are set to 0, application recycling is disabled for the selected application.

    • Lifetime Limit indicates the maximum number of minutes a process can run before it's recycled. The valid range is 0 through 30,240 minutes (21 days). The default number of minutes is 0.

    • Memory Limit indicates the maximum amount of process memory usage (in kilobytes) before recycling the process. If the process's memory usage exceeds the specified number for longer than one minute, the process is recycled. The valid range is 0 through 1,048,576 KB, and the default amount of memory usage is 0 KB.

    • Expiration Timeout indicates the number of minutes to wait, before being forcibly shut down, for the release of all external references to objects in the process. The valid range is 1 through 1440 minutes (24 hours), and the default expiration time-out is 15 minutes. This value is used only when it is already determined that a process will be recycled based on the other criteria.

    • Call Limit indicates the maximum number of calls that application objects can accept before recycling the process. The valid range is 0 through 1,048,576 calls, and the default number of calls is 0.

    • Activation Limit indicates the maximum number of application object activations to accept before recycling the process. The valid range is 0 through 1,048,576 activations, and the default number of activations is 0.
  3. Click OK.


Administering Application Security

Component Services provides a simple, robust security model that you can use to protect COM+ applications, data, and resources from accidental or malicious corruption.

The central mechanism is that of roles, which are user categories that have been defined for an application by its developer. Roles are initially assigned to the application and its components by the developer and then populated with actual users by the system administrator. When in place, roles serve to enforce an access control policy for the application.

For administrative purposes, role-based security clarifies and simplifies security maintenance for a COM+ application. Tasks for administration of role-based security are typically as simple as populating an application's predefined roles with Microsoft® Windows® groups or user accounts and setting an identity for the application (a user account under which the application runs).

Before You Continue

Security should be an intrinsic part of an application's design. Developers assess security requirements and balance them against performance and functional requirements. The developer decides what level of role-based security is appropriate and incorporates roles that represent the categories of users for whom the application is intended. These choices can affect every functional aspect of an application, so they should be made in the context of its overall design.

Note For a broad discussion of COM+ security, see the "COM+ Security" section under "Component Services" in the Microsoft Platform SDK. For a discussion of COM security, see the "COM Security" section under "Component Services" in the Microsoft Platform SDK. If you don't have the Platform SDK installed, see the MSDN Web site to view or install it.

The topics described in the following table provide detailed background and task information about security.

Topic | Description
Security Administration Concepts | Provides an overview and links to more information about administering application security.
Security Administration Tasks | Provides links to step-by-step procedures for security-related tasks.


Security Administration Concepts

The role-based security model used by COM+ applications is built on top of the security mechanisms of Microsoft® Windows® and COM, including user identification, authentication services, and impersonation and delegation; these security mechanisms continue to function transparently in underlying layers. Windows provides basic protection with user identification through logons, controlled access to system resources, audited security events through Local Users and Groups, and file protection through the NTFS file system.

You should be familiar with Windows security features when administering Component Services security. For more information, consult the Windows documentation and the Microsoft Windows Resource Kit for background information.

Administration of COM+ Application Security

Where security for COM+ applications is concerned, administrative tasks include the following:

  • Assigning Windows user groups to predefined roles for the application or for a specific COM+ partition and then managing those roles on an ongoing basis.

  • Setting the application identity during installation, generally to a user account that the application runs under and uses when it makes calls out to other applications and resources. (This applies only to server applications; it is not required for library applications.)

Administering role-based security effectively requires knowledge of the application's security needs and how they are enforced through roles. It is crucial that users are assigned to the roles appropriate to them according to the application's security policy.

Caution It is strongly recommended that you do not use the Component Services administrative tool to modify an application's security settings. An application that uses role-based security might contain code that relies on checking role membership. If you modify its security settings, an application might not run at all, it might not run as intended, or it might run unsecured.

Administration of COM Application Security

COM applications use a number of security configuration properties. These properties have machine-wide settings that an application can use by default. Alternatively, COM security configuration can be customized for any particular application. If an application does not have custom security settings, it uses the settings set for the machine on which it resides.

You can use the Component Services administrative tool to change the COM machine-wide security properties and to set customized security properties for a particular COM application. In general, it is not necessary that you change anything, although for particular applications or particular systems, security requirements may dictate that you do so.

For a full discussion of COM security, see the "COM Security" section under "Component Services" in the Microsoft Platform SDK.

For further background information about Component Services security administration, see the topics described in the following table.

Topic | Description
Role-Based Security | Provides an overview of how role-based security works.
Security Levels for Access Checks | Describes where security access checks are performed.
Software Restriction Policy | Provides an overview of the software restriction policy and why you should use it.
Authentication in COM+ | Describes the importance of authentication in a security policy.
Impersonation and Delegation in COM+ | Describes the usefulness of impersonation and restrictions associated with delegation.
Application Identity | Provides an overview of how the application identity is used.
Library Application Security | Describes the special security concerns of COM+ library applications.


Role-Based Security

Security roles model and enforce an access control policy for a COM+ application or a COM+ partition. Roles are categories of users that have been defined for the application or the COM+ partition for the purpose of determining access permissions to the application's resources. The developer assigns the roles (as symbolic user categories) to the application and potentially to finer structures within it—including components, interfaces, methods, or private application resources. These role assignments are then used to determine which user categories have permission to access which elements within the application.

When an application uses role-based security, a caller's role membership is checked on every call into the application. If a caller does not belong to a role having permission to access the item being called, the call fails. Callers are granted access to the application or its resources strictly according to the constraints defined within the roles to which they belong.

The system administrator's job is to populate the roles defined for the application or the COM+ partition with Microsoft® Windows® user accounts and groups. This is a crucial stage in carrying out the application's security policy. Users must be assigned to the roles that correctly represent their relationship to the data and resources they might access through the application.

Assigning Groups of Users to Roles

The preferred way to populate roles with users is to use Windows groups. First you assign a user account to the appropriate groups, and then you ensure that the groups are assigned to the appropriate roles. Using Windows groups to populate roles makes it easier for you to manage large numbers of users. In enterprise computing environments, it is often difficult to effectively track each user's place within the organization and determine how that maps into the role-based security policy particular to each application. As the number of users, administrators, and applications rises, this task becomes increasingly complicated. The most scalable solution is to assign user groups to COM+ application roles.

Before you assign any groups to roles, you need to be sure that you understand the application's security policy. Ideally, roles should carry names, such as "Managers" and "Tellers," that suggest who should belong to them. In addition, you can use the Component Services administrative tool to access each role description, and each role description may indicate what kinds of users should belong to the role. However, if you are not sure which user groups belong in which roles, consult the documentation that accompanies the application or ask the developer for clarification.

You can use the Component Services administrative tool both to make the initial assignments to roles during application installation and to make any necessary changes in role membership during the application's lifetime.

See the following topics for step-by-step instructions on tasks that are part of managing role membership:

  • Enabling Role-Based Authorization Checking

  • Assigning a User Account or Group to a Role

  • Removing a User Account or Group from a Role

  • Moving a User Account or Group to a Different Role


Security Levels for Access Checks

Security is checked only at application boundaries. That is, for two components in the same application, when one component calls the other, no security check occurs. However, if two applications share the same process and a component in one calls a component in the other, a security check is done because an application boundary is crossed. Likewise, if two applications reside in different server processes and a component in the first application calls a component in the second application, a security check is done. Therefore, if you have two components and you want security checks to be done when one calls the other, you need to put the components in separate COM+ applications.

Because COM+ library applications are hosted by other processes, there is a security boundary between the library application and the hosting process. Additionally, the library application doesn't control process-level security, which affects how you need to configure security for it. For more information, see Library Application Security.

Component-Level Access Checks

For a COM+ server application, you have the choice of enforcing access checks either at the component level or at the process level. When you select component-level access checking, you enable fine-grained role assignments. You can assign roles to components, interfaces, and methods and achieve an articulated authorization policy. This is the standard configuration for applications using role-based security. For COM+ library applications, you must select component-level security if you want to use roles.

You should select component-level access checking if you are using programmatic role-based security. Security call context information is available only when component-level security is enabled. Additionally, when you select component-level access checking, the security property is included on the object context. This means that security configuration can play a role in how the object is activated.

Process-Level Access Checks

Process-level checks apply only to the application boundary. That is, the roles that you have defined for the whole COM+ application determine who is granted access to any resource within the application. No finer-grained role assignments apply. Essentially, the roles are used to create a security descriptor against which any call into the application's components is validated. In this case, you would not want to construct a detailed authorization policy with multiple roles. The application uses a single security descriptor.

For COM+ library applications, you would not select process-level access checks. The library application runs hosted in the client's process and hence does not control process-level security. For more information, see Library Application Security.

With process-level access checks enabled, security call context information is not available. This means that you cannot do programmatic security when using only process-level security. Additionally, the security property is not included on the object context. This means that when using only process-level access checks, security configuration never plays a role in how the object is activated.

For step-by-step instructions on setting the security level for access checks, see Setting a Security Level for Access Checks.


Software Restriction Policy

Properly using the software restriction policy can make your business more agile because it provides a proactive framework for preventing problems, rather than a reactive framework that relies on the costly alternative of restoring a system after a problem has occurred. The software restriction policy was created to protect systems from unknown and possibly dangerous code and provides a mechanism where only trusted code is given unrestricted access to a user's privileges.

By using the software restriction policy, you allow unknown code, which might contain viruses or code that conflicts with currently installed programs, to run only in a constrained environment (often called a sandbox) where it is disallowed from accessing any security-sensitive user privileges. For example, an e-mail attachment that contains a worm would be prohibited from automatically accessing your address book and therefore could not propagate itself. If the e-mail attachment contained a virus, the software restriction policy would restrict its ability to damage your system because it would be allowed to run only in a constrained environment.

The software restriction policy depends on assigning trust levels to the code that can run on a system. Currently, two trust levels exist: Unrestricted and Disallowed. Code that has an Unrestricted trust level is given unrestricted access to the user's privileges, so this trust level should be applied only to fully trusted code. Code with a Disallowed trust level is disallowed from accessing any security-sensitive user privileges and can run only in a sandbox so that Unrestricted code cannot load the Disallowed code into its address space.

Configuring the software restriction policy for a system is done through the Local Security Policy administrative tool, while the restriction policy configuration of individual COM+ applications is done either programmatically or through the Component Services administrative tool. If the restriction policy trust level is not specified for a COM+ application, the systemwide settings are used to determine the application's trust level.

The COM+ software restriction policy settings must be carefully coordinated with the systemwide settings because a COM+ application that has an Unrestricted trust level can load only components with an Unrestricted trust level, while a Disallowed COM+ application can load components with any trust level but cannot access any security-sensitive user privileges.

For step-by-step instructions on configuring the software restriction policy in COM+ applications, see Configuring the Software Restriction Policy.


Authentication in COM+

Authentication is the process of determining that callers are actually who they say they are—verifying the authenticity of a claim of identity. In general, this can be done by both server and client, each authenticating the other. But it is especially important for a server application that is authorizing clients, as with role-based security, to do authentication as well. Authenticating clients is a prerequisite for a meaningful authorization policy because if you don't know for certain that the client identity you are checking is authentic, your application is basically relying on the honor system.

For COM+ applications, you can turn on and configure authentication administratively, after which it works transparently. You specify an authentication level administratively by using the Component Services administrative tool or the Administrative SDK functions.

For a COM+ server application, you can choose from several authentication levels that provide varying degrees of security, ranging from no authentication to encryption of every packet and all method call parameters. Higher security comes with some performance cost, however, which you should take into consideration when configuring your application. COM+ negotiates between the authentication level specified by client and server and uses the more secure of the two. This enables you to administratively control the minimum authentication level from the server side alone.

Note You should never specify an authentication level programmatically by using CoInitializeSecurity within a COM+ application. COM+ calls CoInitializeSecurity for you, and this can be called only once per process.

For a COM+ library application, authentication is largely controlled by the hosting process. However, you can configure the library application so that it does not participate in authentication. That is, calls into the application can be authenticated or unauthenticated, and in the latter case, authentication of clients always succeeds. For information about this, see Library Application Security.

For a description of authentication levels, see Authentication Level.

For step-by-step instructions for setting the authentication of COM+ server and library applications, see Setting Authentication in COM+.


Impersonation and Delegation in COM+

Impersonation is the process by which a server makes a call on behalf of a client and presents the client's identity and credentials in place of its own when making the call. In some circumstances, a server needs to present a client's identity to resources it accesses on the client's behalf, usually to cause access checks or authentication to be performed against the client's identity.

Using impersonation ensures that the server can do precisely what the client can do. Access to resources may be either restricted or expanded, depending on what the client has permission to do.

You might choose to have a server impersonate a client when connecting to a database so that the database can authenticate and authorize the client for itself. Or, if your application accesses files that are protected with a security descriptor and to ensure that the client can obtain authorized access only to information in these files, the application can impersonate the client before accessing the files.

When a COM+ application makes a call to another application or resource, it expresses an impersonation level. For COM+ server applications, you can set an impersonation level administratively. COM+ library applications cannot set their own impersonation level; they use that of the host process instead.

Administrative Requirements for Delegate-Level Impersonation

Delegation is server impersonation of a client over the network; that is, the application, as a server, is making calls to other applications on remote machines and using the client's identity with the client's permission. Because this is a very powerful level of authority to grant an application, with potential security risks, the behavior of delegation is controlled administratively through the Active Directory service. When a client application is granting a server permission to do delegate-level impersonation, the following two requirements must be met for it to work:

  • The server application must be running under an identity that is marked as "Trusted for delegation" in Active Directory.

  • The client application must be running under an identity that is not marked as "Account is sensitive and cannot be delegated" in Active Directory.

For a description of impersonation levels, see Impersonation Level.

For step-by-step instructions on setting the impersonation level of COM+ server applications, see Setting an Impersonation Level in COM+.

For step-by-step instructions on configuring delegation in Active Directory, see Configuring an Account for Delegation Using Active Directory.


Application Identity

The application identity is the user account under which the application runs. When you install a COM+ server application—that is, a COM+ application running in its own process space—you need to set an identity under which it runs. The identity can be set to interactive user (meaning whichever user is logged on to the computer running the application), to the local service user (an account with the minimal permissions to run a locally accessible service), to the network service user (an account with the permissions of the local service user and network access), or to a specific user account (which requires a valid password for that account). You do not need to set the identity for COM+ library applications, which run in the host's process space under the host's identity.

The identity determines the security context for calls that the application makes when it runs. When the application makes calls to other applications, it uses its identity (provided it is not impersonating a client when making calls on the client's behalf). An application receiving the call uses the calling application's identity to do its own security checking to validate the call.

Which Identity to Specify

Specifying a particular user is usually preferable to using the interactive user identity. When a particular user identity is used, the server can run even when no one is logged on to the machine on which the application is running.

Assigning a particular user identity is more secure than assigning an interactive user because the particular user identity can be assigned to the application only by someone who has the specific user's password. Additionally, choosing interactive user identity carries other security risks because the application runs under the identity of the logged on user without that user's knowledge or consent. For example, if the application is running on a computer while an administrator is logged on, the application runs under the administrator's identity, potentially making calls as such on behalf of clients.

If the application does not require access to a particular user's private files, running under the local or network service account is generally the most secure option, because these accounts have even more limited access permissions than user accounts.

If the identity is set to interactive user, the application runs only when a user is logged on. Interactive user is the only identity that allows the client to see a graphical user interface (GUI) provided by the application.

Requirements for Delegation to Work

When setting the identity for a COM+ application that you want to be able to perform delegation on behalf of clients, if you set it for a particular user identity, that user must be a domain user account that is trusted for delegation. If Interactive User Identity is used, whatever user is logged on must be trusted for delegation.

If the application identity is not trusted for delegation, the call fails when the application attempts to impersonate a client over the network.

For an overview of impersonation and delegation in COM+, see Impersonation and Delegation in COM+.

For step-by-step instructions on setting identity, see Setting Application Identity.


Library Application Security

Because a COM+ library application is hosted by another process, which may have its own security settings, security for library applications requires special consideration. The following constraints apply to library application security:

  • Library applications run under the host process security token rather than under their own user identity. They have only as much privilege as the host has.

  • Library applications do not control process-level security. No users in roles are added to the security descriptor for the process. The only way for a library application to perform its own access checks is to use component-level security.

  • Library applications can be configured to either participate or not participate in host process authentication, by enabling or disabling authentication.

  • Library applications cannot set an impersonation level; they use that of the host process.

Using Library Applications to Limit Application Privilege

In some cases, you may want to configure an application specifically as a library application so that it runs under the identity of the hosting process. Doing so fundamentally limits the application so that it can access only those resources that its client, the host process, can access. The threads that the library application components run on use the process token by default, and therefore when they make calls outside of the application or gain access to resources such as files guarded with a security descriptor, they appear to be the client. For applications that perform sensitive work, this may be an easy way to control the scope of their actions.

Enforcing Role Checks

A security factor to consider is whether or not the library application should use role-based security. If role-based security is used, you must be using component-level security for any access checks to be carried out. The roles assigned to the library application are not reflected in the process security descriptor. The only authorization that the library application can control is at the component level.

For more information about component-level security, see Security Levels for Access Checks.

For step-by-step instructions on setting component-level security, see Setting a Security Level for Access Checks.

Enabling or Disabling Authentication

Another decision to make is whether callers of the library application should be subject to the process-level security checks of the hosting process—that is, whether to enable or disable authentication.

For example, if the library application is to be hosted by a browser, it might need to receive unauthenticated callbacks. To address this need, you can disable authentication so that the hosting process does not perform security checks for callers of the library application. When you disable authentication, the library application effectively goes unauthenticated and all calls to it succeed. Callers of the library application are not subject to the security checks of the hosting process. Basically, the library application is tagged as unauthenticated, and security checks are omitted for calls to the library application.

For an overview of authentication in COM+, see Authentication in COM+.

For step-by-step instructions about how to enable or disable authentication in a COM+ library application, see Enabling Authentication for a Library Application.


Security Administration Tasks

The following topics in this section describe the security administration tasks that you can perform with the Component Services administrative tool:

  • Managing Users in Roles

  • Setting a Security Level for Access Checks

  • Configuring the Software Restriciton Policy

  • Setting Authentication in COM+

  • Setting an Impersonation Level in COM+

  • Setting Application Identity

For overview information about these tasks, see Security Administration Concepts.


Managing Users in Roles

Most administration tasks for configuring COM+ application security involve populating predefined roles with users, both when installing applications and on an ongoing basis. For introductory information about how these security features work, see Role-Based Security.

In this section, step-by-step instructions are provided for the following tasks:

  • Enabling Role-Based Authorization Checking

  • Assigning a User Account or Group to a Role

  • Removing a User Account or Group from a Role

  • Moving a User Account or Group to a Different Role


Enabling Role-Based Authorization Checking

To use role-based security in your COM+ application, you must first enable role-based authorization checking for the application. This ensures that users who are accessing the application are checked for the role they belong to before they are authorized to do anything in the application. If role-based authorization checking is not enabled, role-based security for the application is not used.

To enable role-based authorization checking

  1. Right-click the COM+ application for which you are enabling role-based authorization checking, and then click Properties.

  2. In the application properties dialog box, click the Security tab.

  3. Under Authorization, select the Enforce access checks for this application check box; clearing the check box means that role-based security is not used for the application.

  4. Click OK.

The selected authorization setting takes effect the next time the application is started.


Assigning a User Account or Group to a Role

You can use the Component Services administrative tool to populate a role with user accounts or groups. The preferred way to assign a user account to a role is to assign the user account to a Microsoft® Windows® group and then assign the group to the role. Using Windows groups to populate roles makes it easier for you to manage large numbers of users. In the online help for the Computer Management administrative tool, see the topic "Local Users and Groups" for more information about creating a Windows group or assigning a user account to a Windows group.

Note To allow unauthenticated network users to run a COM+ application, the application roles must include the Anonymous user. In Windows Server 2003, by default, the Anonymous user is not included in the Everyone group.

After you have assigned the user account to the appropriate Windows group, follow the steps below to assign the Windows group to the role.

To assign a Windows group to a security role

  1. In the console tree of the Component Services administrative tool, locate the COM+ application that contains the role to which you want to add the user account or group. Expand the view in the console tree until the application's roles are visible.

  2. Locate the role to which you want to add the user account or group.

    Note If the role you are looking for is not in the Roles folder, the role has not been added to the application. It must be added to the application by the developer before you can assign user accounts to the role.

  3. Right-click the Users folder in the role, point to New, and then click User.

  4. In the Select Users or Groups window, in the bottom pane, type the fully qualified name of the user or group you want to add. If you do not know the name, click the Advanced button and then click Find Now to view a list of users and groups in the selected domain. Select a user or group from the Name (RDN) list, and click OK.

  5. To add more user accounts or groups, repeat step 4.

  6. When you have finished adding user accounts and groups to the role, click OK.

For each user account or group you have assigned to the role, an icon appears in the Users folder. The new role membership takes effect the next time the application is started.


Removing a User Account or Group from a Role

You can remove user accounts or groups from a role when the users or members of the groups should no longer be given access to the application resources to which the role is assigned.

To remove a user account or group from a role

  1. In the console tree of the Component Services administrative tool, locate the COM+ application that contains the role you are interested in. Expand the view in the console tree until the users for the role are visible.

  2. Right-click the user account or group you want to remove, and then click Delete.

  3. When prompted by the Confirm Item Delete dialog box, click Yes to delete the user account or group.

The user account or group that you have removed from the role no longer appears in the Users folder. The new role membership takes effect the next time the application is started. If you have made changes to the System Application, you must restart the computer for the changes to take effect.


Moving a User Account or Group to a Different Role

If a user's privileges change or if roles are added to an application, you can move an account from one role to another role. To move a user account or group of users from one role to another, you must remove the user account or group from its current role and then assign it to the new role.

To move a user account or group from one role to another

  1. Remove the user account or group from the role that it should no longer belong to, as follows:
    1. In the console tree of the Component Services administrative tool, locate the COM+ application that contains the role you are interested in. Expand the view in the console tree until the users for the role are visible.

    2. Right-click the user account or group you want to remove, and then click Delete.

    3. When prompted by the Confirm Item Delete dialog box, click Yes to delete the user account or group.

    The user account or group that you have removed from the role no longer appears in the Users folder.

  2. Assign the user account or group you have removed to the roles that the user or group should be assigned to, as follows:
    1. In the console tree of the Component Services administrative tool, locate the COM+ application that contains the role to which you want to add the user account or group. Expand the view in the console tree until the application's roles are visible.

    2. Locate the role to which you want to add the user account or group.

      Note If the role you are looking for is not in the Roles folder, the role has not been added to the application. It must be added to the application by the developer before you can assign user accounts to the role.

    3. Right-click the Users folder in the role, point to New, and then click User.

    4. In the Select Users or Groups window, in the bottom pane, type the fully qualified name of the user or group you want to add. If you do not know the name, click the Advanced button and then click Find Now to view a list of users and groups in the selected domain. Select a user or group from the Name (RDN) list and click OK.

    5. When you have finished adding the user account or group to the role, click OK.

    For each user account or group you have assigned to the role, an icon appears in the Users folder.

The changed role membership for the user account or group takes effect the next time the application is started.


Setting a Security Level for Access Checks

After you have enabled role-based authorization checking for your COM+ application, you must select the level at which you want to have access checks performed. For an overview of the security levels, see Security Levels for Access Checks.

To select a security level

  1. In the console tree of the Component Services administrative tool, right-click the COM+ application for which you want to select its security level and then click Properties.

  2. In the application properties dialog box, click the Security tab.

  3. Under Security Level, select one of the following:
    • Perform access checks only at the process level This setting indicates that users in roles that are assigned to the application are added to the process security descriptor. This has the following effects and implications:

      Fine-grained role checking is turned off at the component, method, and interface levels. Security checks are performed only at the application level.

      The security property is not included on the context for any objects running within the application. This ensures that security never influences how objects are activated.

      The security call context is not available. Programmatic security that relies on security call context information does not function.

    • Perform access checks at the process and component level This setting indicates that process-level security descriptor checks and full role-based security checks are performed. This has the following effects and implications:

      To enable role checking for particular components, you must enable access checks at the component level.

      The security property is included on the context for any objects running within the application. If an object has a configuration incompatible with the context of its creator, it is activated in its own context.

      The security call context is available. Programmatic role-based security is enabled.

      Note For any meaningful access checking to work for COM+ library applications, you must choose to perform access checks at the process and component level. Library applications rely on the host process for process-level security.

  4. Click OK.

The next time the application is started, security is automatically checked at the specified level and only users assigned to roles assigned to the application are given access to the application.


Configuring the Software Restriction Policy

When you explicitly set the software restriction trust levels of a COM+ application, you are overriding the default systemwide settings for the software restriction policy. This is often necessary for COM+ server applications because the systemwide restriction policy is set the same for all server applications (because they all run in the same file, dllhost.exe).

Note When you set the trust level of a COM+ library application, you are affecting the systemwide software restriction policy for that application. For an overview of how to use the software restriction policy in COM+, see Software Restriction Policy.

To set the software restriction policy

  1. Right-click the COM+ application for which you are setting the restriction policy, and then click Properties.

  2. In the application properties dialog box, click the Security tab.

  3. Under Software Restriction Policy, select the Apply software restriction policy check box to enable setting the trust level; clearing the check box causes COM+ to use the systemwide software restriction policy for the application.

  4. In the Restriction Level box, select the appropriate level. The levels are as follows, ordered from least to most trusted:
    • Disallowed The application is disallowed from using the full privileges of the user. Components with any restriction policy trust level can be loaded into it.

    • Unrestricted The application has unrestricted access to the user's privileges. Only components with an Unrestricted trust level can be loaded into it.
  5. Click OK.

The trust level you select takes effect the next time the application is started.


Setting Authentication in COM+

In COM+, authentication settings and effects depend on whether you are working with a server application or a library application.

For COM+ server applications, you set an authentication level that determines how authentication is performed when clients call into components within the application. For more information, see Setting an Authentication Level for a Server Application.

For COM+ library applications, you enable or disable authentication to determine whether or not the application is subject to the authentication performed by the hosting process. For more information, see Enabling Authentication for a Library Application.

For an overview of authentication in COM+, see Authentication in COM+.


Setting an Authentication Level for a Server Application

When you set an authentication level for an application, you determine what degree of authentication is performed when clients call into the application. Higher authentication levels provide greater security and data integrity, although usually with some performance degradation. For an overview of authentication in COM+, see Authentication in COM+.

To select an authentication level for a server application

  1. Right-click the COM+ server application for which you are setting authentication, and then click Properties.

  2. In the application properties dialog box, click the Security tab.

  3. In the Authentication Level for Calls box, select the appropriate level. The levels are as follows, ordered from lowest to highest security:
    • None No authentication occurs.

    • Connect Authenticates credentials only when the connection is made.

    • Call Authenticates credentials at the beginning of every call.

    • Packet Authenticates credentials and verifies that all call data is received. This is the default setting for COM+ server applications.

    • Packet Integrity Authenticates credentials and verifies that no call data has been modified in transit.

    • Packet Privacy Authenticates credentials and encrypts the packet, including the data and the sender's identity and signature.
  4. Click OK.

The authentication level you select takes effect the next time the application is started.


Enabling Authentication for a Library Application

Because COM+ library applications are hosted by other processes, their security requirements may be different from those of server applications. If the library application is hosted by a browser, it might need to receive unauthenticated callbacks.

To address this need, you can disable authentication so that the hosting process does not perform security checks for callers of the library application. When you disable authentication, calls to the library application effectively go unauthenticated and all calls to it succeed. For more detail, see Library Application Security. For an overview of authentication in COM+, see Authentication in COM+.

To enable (or disable) authentication for a library application

  1. Right-click the COM+ library application for which you are enabling or disabling authentication, and then click Properties.

  2. In the application properties dialog box, click the Security tab.

  3. Under Authentication, select the Enable Authentication check box to enable authentication; clearing the check box disables authentication.

  4. Click OK.

The selected authentication setting takes effect the next time the application is started.


Setting an Impersonation Level in COM+

When you set an impersonation level for an application, you determine what degree of authority the application grants other applications to use its identity when it calls them. You can set this only for COM+ server applications; library applications run under the identity of the hosting process and use the impersonation level that it specifies. For an overview of impersonation in COM+, see Impersonation and Delegation in COM+.

To select an impersonation level for a server application

  1. Right-click the COM+ server application for which you are setting impersonation, and then click Properties.

  2. In the application properties dialog box, click the Security tab.

  3. In the Impersonation Level box, select the appropriate level. The levels are as follows, ordered from granting least to greatest authority:
    • Anonymous The client is anonymous to the server. The server can impersonate the client, but the impersonation token (a local credential) does not contain any information about the client.

    • Identify The server can obtain the client's identity and can impersonate the client to determine access-checking levels.

    • Impersonate This is the default setting for COM+ server applications. The server can impersonate the client while acting on its behalf, although with restrictions. The server can access resources on the same computer as the client. If the server is on the same computer as the client, it can access network resources as the client. If the server is on a computer different from the client, it can access only resources that are on the same computer as the server.

    • Delegate The server can impersonate the client while acting on its behalf, whether or not on the same computer as the client. During impersonation, the client's credentials (both those with local and those with network validity) can be passed to any number of machines.
  4. Click OK.

The selected impersonation level takes effect the next time the application is started.

For instructions on how to configure an account to use delegate-level impersonation, see Configuring an Account for Delegation Using Active Directory.


Configuring an Account for Delegation Using Active Directory

Because delegate-level impersonation is such a powerful feature, with potential security risks, the behavior of delegation is controlled administratively through the Active Directory service. When a client application is granting a server permission to do delegate-level impersonation, the following two requirements must be met for it to work:

  • The server application must be running under an identity that is marked as "Trusted for delegation" in Active Directory.

  • The client application must be running under an identity that is not marked as "Account is sensitive and cannot be delegated" in Active Directory.

To set a user account to use delegation

  1. On the server that you have designated as your domain controller, click the Active Directory Users and Computers administrative tool.

  2. Under your domain, click the Users folder.

  3. Right-click the user account that you are allowing to use delegation, and then click Properties.

  4. Click the Account tab.

  5. If you want to allow the account to run as the identity of a server that can use delegate-level impersonation, under Account options, select the Account is trusted for delegation check box.

  6. If you want to allow the account to run as the identity of a client that can use delegate-level impersonation, under Account options, clear the Account is sensitive and cannot be delegated check box.

  7. Click OK.

The new user account settings take effect when the Active Directory schema is next updated (usually within 5 minutes if there are no network problems).

If the server process is running under a system account, the principal account is the computer account in the Active Directory. In this case, the computer account must be set to use delegation.

To set a computer account to use delegation

  1. On the server that you have designated as your domain controller, click the Active Directory Users and Computers administrative tool.

  2. Under your domain, click the Computers folder.

  3. Right-click the computer account that you are allowing to use delegation, and then click Properties.

  4. On the General tab, select the Trust computer for delegation check box.

  5. Click OK.

The new computer account settings take effect when the Active Directory schema is next updated (usually within 5 minutes if there are no network problems).

For more information about enabling delegation in Active Directory, see the help associated with the Active Directory Users and Computers administrative tool.

For step-by-step instructions on setting the impersonation level of COM+ server applications, see Setting an Impersonation Level in COM+.


Setting Application Identity

Using the Component Services administrative tool, you can set the identity for a COM+ server application. (For a COM+ library application, the identity is always the identity of the hosting process.) The identity can be set either to a particular user account, along with a valid password, or to interactive user. The application runs under this user account and uses it when it makes calls to other applications or resources. For an overview of application identities, see Application Identity.

To set the identity for a COM+ server application

  1. In the console tree of the Component Services administrative tool, right-click the COM+ application whose identity you want to set and then click Properties.

  2. In the properties dialog box, click the Identity tab.

  3. Under Account, select from the following options:
    • To specify that the server must run under the identity of the logged on user, click Interactive user – The current logged on user.

    • To specify that the server must run with the identity of a local service, click Local Service - Built-in service account.

    • To specify that the server must run with the identity of a network service, click Network Service - Built-in service account with network access.

    • To specify that the server must run under a particular user's identity, click This user and then enter the user name, password, and confirmed password. If you don't know the fully qualified user name, click Browse to locate it. In the Select User window, click the Advanced button and then click Find Now to view a list of users and groups in the selected domain. Select a user or group from the Name (RDN) list, and click OK.
  4. Click OK.

The selected identity takes effect the next time the application is started.


Administering COM+ Partitions

COM+ partitions enable you to install and use multiple configurations of an application on a computer simultaneously. Using the Component Services administrative tool, you can create and configure partitions on the local computer and then install specific configurations of COM+ applications into them.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

The sections described in the following table provide background concepts related to COM+ partitions and describe how to use the Component Services tool to create and manage COM+ partitions and partition sets.

Topics | Descriptions
COM+ Partition Administration Concepts | Provides a conceptual description of COM+ partitions as well as concepts related to creating and managing COM+ partitions and partition sets.
COM+ Partition Administration Tasks | Provides step-by-step procedures for creating and managing COM+ partitions and partition sets.


COM+ Partition Administration Concepts

Many computing environments require using different configurations of applications simultaneously. For example, a company might want to run a training configuration of an application alongside testing and development configurations. The training configuration could allow users to become familiar with the application while testing and development of the application continued.

If you have to run each configuration of the application on a separate computer, it is both costly and inefficient because it increases hardware costs and administrative overhead. COM+ solves this problem by providing the partitions feature. COM+ partitions enable you to install and use multiple configurations of COM+ applications on a computer simultaneously.

Administrators should understand COM+ partitions because of the enormous benefit for users in a domain. Also, application programmers can use COM+ partitions to ensure that their distributed applications work seamlessly within a partitioned environment.

The following topics in this section provide detailed information about COM+ partitions and how to use them:

  • What Are COM+ Partitions?

  • Primary Usage Scenario for COM+ Partitions

  • Administration Overview for COM+ Partitions


What Are COM+ Partitions?

A COM+ partition is a logical container that allows an application to run independently of other configurations of that application. Each configuration is installed into a separate partition and can be separately configured and managed according to the specific needs of its users. For example, an application service provider could install and manage a separate configuration of an application for each customer that it supports.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

The use of COM+ partitions offers several advantages, including the following:

  • Organizations can lower their total cost of ownership by using fewer physical application servers to support users who need multiple application configurations.

  • Administrative overhead is reduced. Instead of having to configure and manage multiple computers, administrators need only configure and manage multiple partitions on the same computer. Furthermore, partitions can be managed programmatically through the addition of a new COM+ programming interface.

  • Security can be implemented and managed on a partition-by-partition basis for local users, domain users, and organizational units (OUs).

  • Programmers and administrators can use Microsoft development and administrative tools, such as the Platform SDK, Active Directory Users and Computers, and Component Services administrative tool, to manage partitions.


Primary Usage Scenario for COM+ Partitions

A primary reason for customers to deploy the COM+ partitions feature is to host Web-based applications. A Web page accessed by a user can, in turn, access an application service provider that activates COM+ components. Each of the component activations can then be mapped to a partition.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

For example, suppose a small software company develops a COM+ application for use by hospital personnel. The application, which is a distributed, Web-based application, provides a way for hospitals to store and retrieve patient medical records using a SQL Server database.

Suppose the software company has three customers: Hospital A, Hospital B, and Hospital C. While each customer runs the client side of the COM+ application locally on its desktop computers, the server side of the COM+ application resides on the software company's in-house Web server and is accessed by its customers via the Web.

Because each hospital has its own set of storage and retrieval requirements and its own set of customized patient data, the software company must provide a way for multiple configurations of the server part of the application to be executed simultaneously on the Web server. COM+ partitions provide a solution to this problem, as shown in the following illustration.


Administration Overview for COM+ Partitions

The primary way to deploy and administer COM+ partitions is at the domain level. That is, you should create domainwide COM+ partitions within Active Directory and make them available to multiple users throughout the domain. By using the Active Directory Users and Computers administrative tool, you can create domainwide COM+ partitions, group those partitions into partition sets, and map users and organizational units (OUs) in the domain to those partition sets. Then, using the Component Services administrative tool, you can map COM+ partitions on the application server to the domainwide COM+ partitions created within Active Directory.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

All COM+ partition administration tasks can be done either programmatically or through the Component Services and Active Directory Users and Computers administrative tools. Following are some typical tasks for administering COM+ partitions:

  • Creating domainwide COM+ partitions and partition sets within Active Directory.

  • Mapping users and OUs in a domain to partition sets within Active Directory.

  • Creating COM+ partitions on an application server for local or domain users.

  • Assigning default COM+ partitions to users.

  • Assigning COM+ partition security roles to users.

  • Grouping applications into COM+ partitions.

The following topics in this section explain the key concepts you need to understand to administer COM+ partitions:

  • The Base Application Partition

  • COM+ Partitions and Active Directory

  • Default COM+ Partitions

  • Local COM+ Partitions

  • Partition Properties

  • Partition Security


The Base Application Partition

In addition to any partitions that administrators create, there is a special partition on each computer called the Base Application Partition. The Base Application Partition contains systemwide COM+ application components that need to be accessible to all users in the domain. Installing an application component into the Base Application Partition removes the need to install a copy of the component into each COM+ partition where that component is used.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

If a user's default or current COM+ partition does not include a specific application component that the user is attempting to access, but that component is installed in the Base Application Partition, the component is activated from the Base Application Partition.


COM+ Partitions and Active Directory

Created in Active Directory, partition sets allow users in a domain to access COM+ partitions throughout the domain. Individual users and organizational units (OUs) are assigned to a particular partition set. Domainwide COM+ partitions that the user or OU needs to access can then be placed within their partition set.

A single user or OU can access multiple COM+ partitions and their applications because there is a one-to-one correlation between a user or OU and a partition set. Without a partition set, a user or OU would need multiple user identities to access applications that are contained in different COM+ partitions.

To make a COM+ application available to domain users, an administrator must perform tasks both on the domain controller where Active Directory resides and on the server where the COM+ application is installed.

On the Domain Controller

The administrator first creates a COM+ partition within Active Directory. After the COM+ partition has been created within Active Directory, the administrator can then create a partition set in Active Directory. In creating a partition set, the administrator defines the COM+ partitions that are included in that set. Finally, the administrator can map domain users or organizational units (OUs) to the newly created partition sets. These steps are performed either by using the Active Directory Users and Computers administrative tool or programmatically by using the Active Directory Services Interface (ADSI).

On the COM+ Application Server

To create a domainwide COM+ partition, the administrator must link a COM+ partition in Active Directory to a COM+ partition on the application server. To do this, the administrator must create a new COM+ partition on the application server, specifying the same partition name and partition ID (GUID) as that of the domainwide COM+ partition that was created within Active Directory on the domain controller. To simplify this task, the Component Services tool allows the administrator to browse Active Directory to select the desired partition and its GUID.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

When the domainwide COM+ partition has been created, a user's default partition becomes the default partition of the partition set in Active Directory. For more information about default partitions, see Default COM+ Partitions.

Finally, the administrator can install COM+ applications into the newly created COM+ partition on the application server. These applications are then available to any other users or OUs in the domain that are mapped to the same partition set that the COM+ partition is a part of.

For more information about administering COM+ partitions for access by domain users, see Creating a Domainwide COM+ Partition, or the help associated with the Active Directory Users and Computers administrative tool.


Default COM+ Partitions

When a default COM+ partition is assigned to a user, COM+ attempts to activate components in that partition first. If the activation fails, COM+ searches the Base Application Partition for the component to activate. The exception to this process occurs when the COM+ component includes a partition moniker, which explicitly specifies the partition in which the component is located. In this case, the partition moniker takes precedence over any default COM+ partition configuration.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

When using local COM+ partitions on an application server, the default COM+ partition is assigned to users via the COM+ Partition Users folder in the Component Services administrative tool on the application server. When using partition sets in the Active Directory, the user's default partition is determined by the user's partition set.

For step-by-step instructions, see Assigning a Default COM+ Partition to a New COM+ Partition.


Local COM+ Partitions

COM+ partitions can be used locally on an application server. In this scenario, an administrator creates a COM+ partition on the application server using the Component Services administrative tool but does not associate the newly created COM+ partition with a domainwide COM+ partition that exists in Active Directory. COM+ partitions that are implemented locally and not within Active Directory are accessible to local users only, and not to users on other computers in the domain. After a local COM+ partition is created and a COM+ application is installed into it, the administrator can assign that partition as a default COM+ partition for one or more users on that application server.

Note Because the COM+ partitions feature is most useful in an enterprise environment, it is recommended that local partitions be used strictly for development and testing purposes and not for production use.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.


Partition Properties

COM+ partitions have five properties available. These properties and their descriptions are as follows:

  • Name—A text string associated with the partition.

  • Description — A textual description of the partition.

  • Partition ID—A GUID that the system uses to correlate users to a partition.

  • Disable deletion—A protection option that prevents a user from deleting a partition.

  • Disable changes—A protection option that prevents a user from making changes to a partition.

These properties are viewable by right-clicking a partition name within the Component Services administrative tool and choosing Properties.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.


Partition Security

For each COM+ partition (excluding the Base Application Partition), the Component Services administrative tool shows a Roles folder. The Activator role is the primary role that can be assigned to users for a specific COM+ partition. Assigning a user identity to the Activator role authorizes the user to activate a set of COM+ components registered in that partition. A COM+ component in the Base Application Partition can be activated by anyone who has the authority to activate that component.

Note To view and manage COM+ partitions with the Component Services administrative tool, select the Enable partitions check box on the Options tab of the computer's Properties page.

The Activator role does not apply when using partition sets in Active Directory. Membership in an Active Directory partition set automatically grants the right to activate components in a COM+ partition.

Only members of the Administrator role of the COM+ System Application can create and modify COM+ partitions, add users to the Activator role of different COM+ partitions, and populate the COM+ Partition Users folder with local users and groups.


COM+ Partition Administration Tasks

You can use the Component Services and Active Directory Users and Computers administration tools to perform all the tasks required to set up and maintain COM+ partitions.

This section provides step-by-step procedures for administering partitions on an application server through the use of the Component Services administrative tool. For information about administering partitions within Active Directory, see the Active Directory Users and Computers Administrative Help.

The tasks related to COM+ partitions are as follows:

  • Enabling COM+ Partitions

  • Creating a Domainwide COM+ Partition

  • Assigning a Default COM+ Partition to a New COM+ Partition User

  • Creating a Local COM+ Partition

  • Changing a COM+ Partition Name

  • Disabling Deletion of a COM+ Partition

  • Disabling Changes to a COM+ Partition

  • Adding a Description to a COM+ Partition

  • Assigning a User to the Activator Role

  • Assigning Administration of COM+ Partitions

  • Exporting a COM+ Partition


Enabling COM+ Partitions

The Component Services administrative tool allows you to enable COM+ partitions on your system. COM+ partitions cannot be viewed or managed until they have been enabled.

To enable partitions using the Component Services administrative tool

  1. In the Component Services console tree, open the Computers folder and select a computer.

  2. Right-click the computer name, and choose the Properties menu item.

  3. On the Options tab, select the Enable partitions check box.


Creating a Domainwide COM+ Partition

To create a domainwide COM+ partition, you must create the partition (and a partition set for the partition) within Active Directory using the Active Directory Users and Computers administrative tool. Then you must create those same partitions on the COM+ application server, using the Component Services administrative tool. By creating a COM+ partition on the application server that has the same GUID as a COM+ partition in Active Directory, the partitions become linked and become a single domainwide COM+ partition.

Note To perform the following procedures in Active Directory, you must be a member of the Domain Admins group or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. For more information, see the help associated with the Active Directory Users and Computers administrative tool.

To create a domainwide COM+ partition

  1. Create a COM+ partition in Active Directory:
    1. Using the Active Directory Users and Computers administrative tool, select Advanced Features from the View menu.

    2. In the System folder of the domain, right-click the ComPartitions folder, and select New Partition.

    3. On the General Properties for New Partition page, type a name and description for the new partition and click OK.
  2. Create a partition set in Active Directory:
    1. Using the Active Directory Users and Computers administrative tool, select Advanced Features from the View menu.

    2. In the System folder of the domain, right-click the ComPartitionSets folder and select New Partition Set.

    3. On the General Properties on New Set page, type the name and description of the new partition set and click Next.

    4. On the Configure Partition for New Set page, click the partitions that you want to include in the partition set, click Add, and click Next.

    5. On the Configure Users for New Set page, click Add User and Add Org Unit to add the users and organizational units that are to be mapped to the partition set, and click Finish.
  3. Map domain users or organizational units to the newly created partition set:
    1. Using the Active Directory Users and Computers administrative tool, right-click the user name or organizational unit that you want to map to a partition set and click Properties.

    2. On the COM+ tab, from the Partition Set list box, select the partition set to which you want to map the user or organizational unit.
  4. Create a COM+ partition on the application server and link it to a COM+ partition in Active Directory:
    1. Verify that COM+ partitions are enabled for the application server.

    2. In the Component Services console tree, locate the name of the computer on which you want to create the partition. Expand the view in the console tree until the computer's folders are visible.

    3. Right-click the COM+ Partitions folder, select New, and click Partition from the submenu.

    4. In the COM+ Partition Install Wizard, click Next.

    5. Click Create an empty partition.

    6. Press the Browse Directory button. This displays the Add Directory Service Application Partition dialog box.

    7. Select the COM+ partition from Active Directory that you want to link to.

    8. Click Next; then click Finish.


Assigning a Default COM+ Partition to a New COM+ Partition User

Using the Component Services administrative tool, you can assign a default COM+ partition to a new COM+ partition user. When the new user attempts to access a COM+ application, COM+ searches that user's default partition for the application.

To assign a default COM+ partition to a new COM+ partition user

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the console tree of the Component Services administrative tool, locate the name of the computer on which the user resides. Expand the view in the console tree until the computer's folders are visible.

  3. Right-click the COM+ Partition Users folder, choose New, and choose User. This displays the Assign Default Partition dialog box.

  4. Click Add; this displays the Select Users dialog box.

  5. Enter one or more user names in the Enter the object names to select field.

  6. Click OK.

  7. In the Default partition list box, choose a default partition for the new user.

  8. Click OK.


Creating a Local COM+ Partition

You can use the Component Services administrative tool to create COM+ partitions in which to install local COM+ applications that you want to be unavailable to other users of the domain.

To create a local COM+ partition

  1. Verify that COM+ partitions are enabled for the local computer.

  2. In the Component Services console tree, locate the name of the computer on which you want to create the partition. Expand the view in the console tree until the computer's folders are visible.

  3. Right-click the COM+ Partitions folder, select New, and click Partition from the submenu.

  4. In the COM+ Partition Install Wizard, click Next.

  5. Click Create an empty partition.

  6. Enter a name for the new partition.

  7. If you want to specify a particular GUID for the new partition, delete the existing partition ID in the Partition ID field and enter a new partition ID.

  8. Click Next; then click Finish.


Changing a COM+ Partition Name

Using the Component Services administrative tool, you can change the name of a COM+ partition that you create.

Note You cannot change the name of the Base Application Partition.

To change the name of a partition

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the Component Services administrative tool, select a COM+ partition name.

  3. Right-click the name, and choose Properties.

  4. On the General tab, delete the current name, enter a new name, and click OK.


Disabling Deletion of a COM+ Partition

Using the Component Services administrative tool, you can disable deletion of a COM+ partition.

Note You cannot perform this task on the Base Application Partition. The Base Application Partition cannot be deleted.

To disable deletion of a COM+ partition

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the Component Services administrative tool, select a COM+ partition name.

  3. Right-click the selected partition name, and choose Properties.

  4. On the Advanced tab, select the Disable deletion check box and click OK.


Disabling Changes to a COM+ Partition

Using the Component Services administrative tool, you can disable changes to a COM+ partition.

To disable changes to a COM+ partition

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the Component Services administrative tool, select a COM+ partition name.

  3. Right-click the selected partition name, and choose Properties.

  4. On the Advanced tab, select the Disable changes check box and click OK.


Adding a Description to a COM+ Partition

Using the Component Services administrative tool, you can add a description to a COM+ partition.

To add a description to a COM+ partition

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the Component Services administrative tool, select a COM+ partition name.

  3. Right-click the selected partition, and choose Properties.

  4. On the General tab, enter a description for the partition and click OK.


Assigning a User to the Activator Role

To authorize a user to activate a COM+ component within a specific COM+ partition, you must assign the user to the Activator role for that partition.

To assign a user identity to the Activator role for a partition

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the console tree of the Component Services administrative tool, locate the name of the computer on which the COM+ partition is installed.

  3. Expand the view in the console tree until the COM+ Partitions folder is visible.

  4. Expand the COM+ Partitions folder.

  5. Expand the partition to which you want to add the new Activator.

  6. Expand the Roles folder.

  7. Expand the Activator folder.

  8. Right-click the Users folder, choose New, and choose User. This displays the Select Users or Groups dialog box.

  9. Enter the identity of the user you want to add to the Activator role.

  10. Click OK.


Assigning Administration of COM+ Partitions

To delegate the administration of all COM+ partitions to a user, you must assign the user to the Administrator role within the COM+ System Application.

To authorize a user to become a COM+ System administrator

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the console tree of the Component Services administrative tool, locate the name of the computer on which the COM+ application is installed.

  3. Expand the view in the console tree until the COM+ Partitions folder is visible.

  4. Expand the COM+ Partitions folder.

  5. Expand the Base Application Partition icon.

  6. Expand the COM+ Applications folder.

  7. Expand the System Application folder.

  8. Expand the Roles folder.

  9. Expand the Administrator icon.

  10. Right-click the Users folder, choose New, and choose User. This displays the Select Users or Groups dialog box.

  11. Enter the identity of the user you want to add to the Administrator role with the System Application.

  12. Click OK.


Exporting a COM+ Partition

The COM+ Partition Export Wizard guides you through extracting and packaging the configuration and contents of an existing partition so that it can be moved to another computer.

To access the COM+ Partition Export Wizard

  1. Verify that COM+ partitions are enabled for the computer.

  2. In the console tree of the Component Services administrative tool, locate the name of the computer that contains the COM+ partition that you want to export. Expand the view in the console tree until the computer's folders are visible.

  3. Expand the COM+ Partitions folder.

  4. Right-click the COM+ partition that you want to export, and choose Export. This displays the COM+ Partition Export Wizard. Click Next.

    Note To export user identities with roles, check the Export user identities with roles check box on the Partition Export Information page.

  5. Click Next.

The COM+ Partition Export Wizard creates a Windows Installer Package and a cabinet file. To install the partition on a target computer, move the two files to the target computer and double-click the Windows Installer Package.


Administering the COM+ SOAP Service

Simply by selecting the Uses SOAP check box in the Component Services administrative tool, you can expose a COM+ application as an XML Web service. You can also transparently use an XML Web service, whether deployed using COM+ or not, as a COM component. This means that you can easily create new XML Web services out of existing COM+ applications and easily incorporate XML Web services into new COM+ applications.

The topics described in the following table provide background and task information about using COM+ to expose your configured COM components as XML Web services.

Topic | Description
COM+ SOAP Service Concepts | Provides an overview of XML Web services and SOAP.
COM+ SOAP Service Tasks | Provides instructions for using COM+ to create and deploy XML Web services.


COM+ SOAP Service Concepts

The following topics in this section provide background information necessary to use and administer the COM+ SOAP service.

  • COM+ SOAP Service Overview

  • COM+ SOAP Service Security Considerations


COM+ SOAP Service Overview

HTTP revolutionized computer use by allowing people to use a Web browser for easy access to information on a remote server over a network. XML Web services have now revolutionized application development by allowing client applications to easily call remote methods over a network.

It is often useful for a client application to be able to call a method implemented on a remote server. Sometimes the method makes use of volatile information stored on the remote server (for example, a method that returns the current price of the stock corresponding to a given ticker symbol). At other times, the developer wants the ability to upgrade the method's implementation without having to redeploy all the applications that use it.

Like Web pages, XML Web services are accessed via a Web server, such as IIS, using HTTP. However, instead of Web pages encoded in HTML, these HTTP packets contain the input and output parameters of calls to a method implemented on the server, encoded in SOAP.

You can expose the methods in the default interfaces of the configured COM components in any COM+ application as an XML Web service. No special programming considerations are necessary when writing the components, except that the methods you want to expose must be in your component's default interface and the component must be configured (in your server's COM+ catalog). For detailed instructions about using the COM+ SOAP service to create an XML Web service, see Creating XML Web Services.

You can control access to components exposed as XML Web services by using the access control methods of both IIS and the COM+ application. For details about how to accomplish this, see Securing XML Web Services.

When you use COM+ to create an XML Web service, that service can be used by any authorized client, including those not using COM+ or even Microsoft® Windows®. However, COM+ makes XML Web services especially easy by allowing you to use existing COM+ applications as XML Web services in a completely transparent fashion. If you export a COM+ application that has been exposed as an XML Web service from your server, any client that imports the application can transparently use the server's XML Web service whenever the imported application is used. This facility makes the conversion of existing COM+ applications to XML Web services and the deployment of those services over a network very easy.


COM+ SOAP Service Security Considerations

If you use the .NET Framework version 1.1, the XML Web service you have created by using the COM+ SOAP service enforces any corresponding COM+ application's role-based security settings. These settings allow you to encrypt communications between client and server and to require certificate-based authentication of client identities. For information on COM+ role-based security settings, see Administering Application Security.

By disabling packet authentication and role-based security for your COM+ application, you can allow anonymous access to the corresponding XML Web service from all clients with network access to your machine.

If you enable packet authentication and role-based security for your COM+ application, the corresponding XML Web service is accessible only to authorized COM+ clients. In secure mode, anonymous access is disabled and WSDL file is not published. When created in secure mode, an XML Web service cannot revert to insecure mode.

By default, unencrypted SOAP communications are received at the HTTP port (80) and encrypted SOAP communications are received at the HTTPS port (443). For a client to successfully access an XML Web service, any firewalls between the client and the server must be configured to allow TCP SYN packets to reach the appropriate server port. Conversely, a firewall administrator can close these ports to limit access to XML Web services.

For detailed instructions about how to configure specific XML Web service security settings, see Securing XML Web Services.


COM+ SOAP Service Tasks

The following topics in this section provide step-by-step instructions for using COM+ to expose and manage your applications as XML Web services:

  • Creating XML Web Services

  • Securing XML Web Services

  • Exporting a SOAP-Enabled Application

  • Importing a SOAP-Enabled Application


Creating XML Web Services

Any COM+ application can be exposed as an XML Web service. The methods in the default interfaces of the application's configured components (components in the server's COM+ catalog) can then be called remotely. You can use the Component Services administrative tool to create an IIS virtual root directory from which the component methods can be called by using SOAP.

To expose a COM+ application as an XML Web service

  1. In the console tree of the Component Services administrative tool, under Component Services, open the COM+ Applications folder associated with the computer you want to manage.

  2. Right-click the application you want to expose as an XML Web service, and click Properties.

  3. Click the Activation tab in the properties dialog.

  4. Select the Uses SOAP check box.

  5. In the SOAP VRoot text box, specify the name of the IIS virtual root directory from which the methods of the application's configured components can be accessed remotely.

If you specify the IIS virtual root directory as vroot and if your server's fully qualified domain name is servername, the URL where your component is exposed as an XML Web service is http://servername/vroot/. The corresponding directory in your file system is \windows\system32\com\SoapVRoots\vroot\.


Securing XML Web Services

If you use the .NET Framework version 1.1, the XML Web service you have created by using the COM+ SOAP service enforces any corresponding COM+ application's role-based security settings. If you want to allow anonymous clients to access your XML Web service, you must disable packet authentication and role-based security for the corresponding COM+ application. For more information, see COM+ SOAP Service Security Considerations.

To check whether your SOAP-enabled COM+ application implements role-based security

  1. In the console tree of the Component Services administrative tool, under Component Services, open the COM+ Applications folder associated with the computer you want to manage.

  2. Right-click the SOAP-enabled application you want to check, and click Properties.

  3. Click the Activation tab in the properties dialog.

  4. If the SOAP Security setting is Implement full COM+ security, your SOAP-enabled COM+ application uses role-based security. If the SOAP Security setting is Expose component methods to any caller, your SOAP-enabled application relies on IIS security settings to control access.

  5. Click OK.

If you are using the .NET Framework version 1.1, your SOAP Security setting is Implement full COM+ security, unless you have set the Authentication Level for Calls to None (on the Security tab of your COM+ application's property page) and disabled access checks for your application. In that case, your SOAP Security setting is Expose component methods to any caller. See Setting an Authentication Level for a Server Application forstep-by-step instructions about setting authentication levels.

Note To change role-based security settings for a SOAP-enabled application, disable SOAP access before making the changes and enable SOAP access again afterward. COM+ does not support changes to an application's security settings while SOAP is enabled.

For additional information on COM+ role-based security settings, see Administering Application Security.


Exporting a SOAP-Enabled Application

When you use the COM+ SOAP service to expose an application as an XML Web service, that service can be used by any authorized client, including those not using COM+ or even Microsoft® Windows®. However, using a SOAP-enabled COM+ server application from a COM+ client application is especially easy. Just export the SOAP-enabled application in proxy mode, and then import it into the client from which you want to access the corresponding XML Web service.

To export a SOAP-enabled application from a server

  1. In the console tree of the Component Services administrative tool, under Component Services, open the COM+ Applications folder associated with the computer you want to manage.

  2. Right-click the SOAP-enabled application you want to export, and choose Export. The COM+ Application Export Wizard appears.

  3. In the text box labeled Enter the full path and filename for the application file to be created, enter the full path and filename for the MSI file that is to contain the exported application, or click Browse to select the full path and filename by using a dialog box.

  4. Under Export As, select the Application Proxy – Install on other machines to enable access to this machine radio button.


Importing a SOAP-Enabled Application

When a SOAP-enabled application has been exported from a server in proxy mode, clients that import it have access to the methods of the components it contains. When the components of an application imported in this way are used on the client, they do not run on the client but instead are accessed remotely as an XML Web service provided by the server from which the application was exported. This allows you to very easily exploit the functionality of a SOAP-enabled COM+ application across a network.

To import a SOAP-enabled application into a client

  1. In the console tree of the Component Services administrative tool, under Component Services, open the folder associated with the client computer on which you want to install the SOAP-enabled application.

  2. Right-click the client's COM+ Applications folder, choose New, and then choose Application. The COM+ Application Install Wizard appears.

  3. In the COM+ Application Install Wizard, click Next, and then click Install pre-built application(s).

  4. Browse the network to locate or specify the network path of the MSI file on the server from which you want to install the SOAP-enabled application.


Administering the Process Dump Tool

The process dump tool simplifies the debugging of a COM+ application by dumping the state of the application at the time of failure.

The topics described in the following table provide background concepts related to the process dump tool and explain how to use the Component Services administrative tool to configure the process dump of COM+ applications.

Topics | Descriptions
Process Dump Tool Concepts | Provides a conceptual description of what the process dump tool does and the advantages it delivers.
Process Dump Tool Tasks | Provides a step-by-step procedure for configuring the process dumps of COM+ applications.


Process Dump Tool Concepts

By dumping the state of a COM+ application to a designated directory at the time of failure, the process dump tool allows the administrator to simplify the developer's task of debugging of the application. The following are examples of failure scenarios:

  • An application hangs and becomes unresponsive to the client.

  • An application causes an exception and is terminated by the COM+ runtime.

  • An application fails.

In all of these scenarios, the process dump feature allows you to dump the entire process state at the time of the failure, enabling a more efficient debugging of application failures.

You can dump the files to any computer—not necessarily the one running the application. In addition, the COM+ catalog on the application's computer can be configured to write the dump file to any computer that is accessible over the network. The application can then be debugged offline.

For step-by-step instructions on enabling process dump, see Enabling Process Dump.

For step-by-step instructions on disabling process dump, see Disabing Process Dump.


Process Dump Tool Tasks

The following topics in this section provide step-by-step procedures for performing process dump tasks:

  • Enabling Process Dump

  • Disabing Process Dump


Enabling Process Dump

The process dump feature can be used to obtain information on the state of an application when an exception occurs, the application fails, or the application is hung. For a description of scenarios when you would use the process dump tool in COM+, see Process Dump Tool Concepts.

Note Component Services does not perform any dump file management. Dump files are usually large, so it is recommended that users periodically delete or archive these files.

To dump an application on exception or failure

  1. In the Component Services administrative tool, locate and right-click the COM+ application for which you want to enable process dumping, and then click Properties.

  2. In the application properties dialog box, click the Dump tab.

  3. In the Image Dump Directory text box, enter the complete path to the dump file. Do not include the filename. The default path is %SystemRoot%\system32\com\dmp.

  4. In the Maximum Number of Dump Images list box, enter the maximum number of dump files to be generated before overwriting occurs. The valid range is 1 through 200 files; the default is 5.

  5. Under Enable Process Image Dump, check the Enable Image Dump on Application Fault check box.

  6. Click OK.

To dump an application when it hangs

  1. In the Running Processes folder of the console tree of the Component Services administrative tool, right-click the COM+ application that is hanging and then click Dump.

  2. A dump file is generated in the folder specified in the Image Dump Directory text box on the Dump tab of the application's property pages.

For information about how to disable process dump, see Disabling Process Dump.


Disabling Process Dump

After you have finished debugging your application, you can disable the process dump feature (to prevent dumping because of exceptions and failures) with the following procedure. For a description of scenarios when you would use the process dump tool in COM+, see Process Dump Tool Concepts.

To disable process dump

  1. In the Component Services administrative tool, locate and right-click the COM+ application for which you want process dump disabled, and then click Properties.

  2. In the application properties dialog box, click the Dump tab.

  3. Under Enable Process Image Dump, uncheck the Enable Image Dump on Application Fault check box.

  4. Click OK.

For information on how to enable process dump, see Enabling Process Dump.


Administering Queued Components

The COM+ Queued Components feature enables a client to request a service from a COM+ server application, even when the server application is temporarily unavailable. The client request is stored in a queue and processed when the server becomes available.

Note To use the COM+ Queued Components service, you must have Message Queuing installed on your computer. For information about installing Message Queuing, see Using Message Queuing, under Application and Development Support on the Help and Support Center page, accessible from the Microsoft® Windows® Start menu.

The topics described in the following table provide background and task information about using Component Services to administer Queued Components.

Topic | Description
Queued Components Administration Concepts | Provides an overview of COM+ Queued Components concepts.
Queued Components Administration Tasks | Lists tasks for administering the COM+ Queued Components service.


Queued Components Administration Concepts

Using the COM+ Queued Components feature, a client application can request a service from a COM+ server application. The client's request is recorded to an outbound queue, which Message Queuing transmits to the server application's queue. The request is stored on the server application's queue until it can be processed by the server application. The progression of a Queued Components request is shown in the following illustration.

Note The Queued Components service allows client-server communication that is asynchronous, transactional, and authenticated. For information about developing queued components, see the "Queued Components" topic in the "Component Services" section of the Microsoft Platform SDK.

When you want to use the COM+ Queued Components service, your first administrative task is to determine for which COM+ server applications you want to create queues. For instructions on creating an application queue, see Specifying a COM+ Application as Queued.

If you want a queued application to process queued requests continuously, you must also activate its listener. Alternatively, you can queue requests over time and activate the listener only when you want to begin processing them. To activate a queued application's listener, see Activating the Queued Components Listener.

The Queued Components listener is multithreaded, meaning that many instances of it may run concurrently, to facilitate the rapid processing of queued requests. You may find that the resulting instances of the server application consume all the resources of a computer on which you intended the service to have only a minor impact. Alternatively, you may intend the processing of these queued requests to be the primary function of the computer. To control resource consumption caused by a particular queued application, you can specify the maximum number of concurrent listener threads that can process queued requests. For instructions, see Specifying the Maximum Number of Listener Threads for a Queued Application.

To avoid processing requests from unauthorized clients, you can require each client to present a certificate proving its identity with each request. For instructions on implementing this security precaution, see Specifying the Authentication Protocol. For instructions on how to renew a client's certificate, see Renewing a Message Queuing Certificate.

Occasionally, a request cannot be processed, perhaps because of a problem with the server or with the request itself. When such a problem occurs, the Queued Components service attempts to execute the request several times before moving it to a final resting queue, where it remains until it is requeued manually. For instructions on requeuing requests, see Using the Message Mover.


Queued Components Administration Tasks

The following topics in this section provide step-by-step instructions for administering the COM+ Queued Components service.

Note To use Queued Components, you must have Message Queuing installed on your computer. For information about installing Message Queuing, see Using Message Queuing, under Application and Development Support on the Help and Support Center page, accessible from the Microsoft® Windows® Start menu.

  • Specifying a COM+ Application as Queued

  • Activating the Queued Components Listener

  • Specifying the Maximum Number of Listener Threads for a Queued Application

  • Specifying the Authentication Protocol

  • Renewing a Message Queuing Certificate

  • Using the Message Mover


Specifying a COM+ Application as Queued

When you specify a COM+ application as queued, Component Services creates an associated Message Queuing queue in which requests for the application's services are stored.

To specify a COM+ application as queued

  1. In the console tree of the Component Services administrative tool, under Component Services, open the COM+ Applications folder associated with the computer you want to manage.

  2. Right-click the application for which you want to create a queue, and then click Properties.

  3. Select the Queuing tab in the properties dialog.

  4. Activate the check box labeled Queued – This application can be reached by MSMQ queues.

  5. Click OK.


Activating the Queued Components Listener

To pass requests from a queue to a COM+ server application, after you have specified the server application as queued, the associated listener must be active.

Note Before you can activate its listener, an application must first have been marked as queued. See Specifying a COM+ Application as Queued for step-by-step instructions on marking an application as queued.

To activate the Queued Components listener

  1. In the console tree of the Component Services administrative tool, under Component Services, open the COM+ Applications folder associated with the computer you want to manage.

  2. Right-click the queued application for which you want to activate the listener, and then click Properties.

  3. Select the Queuing tab in the properties dialog.

  4. Activate the check box labeled Listen – This application, when activated, will process messages that arrive on its MSMQ queue.

  5. Click OK.


Specifying the Maximum Number of Listener Threads for a Queued Application

The default value for the maximum number of listener threads is 16 times the number of processors in the computer. Use the default value if you do not yet know whether resource consumption caused by a particular Queued Components service could be a problem. If the service consumes too many resources, use a smaller value. If you want to dedicate more resources to the service, increase the value.

To specify the number of listener threads for a queued application

  1. In the console tree of the Component Services administrative tool, under Component Services, open the COM+ Applications folder associated with the computer you want to manage.

  2. Right-click the queued application for which you want to set the maximum number of threads, and then click Properties.

  3. Select the Queuing tab in the properties dialog.

  4. In the field labeled Maximum concurrent players (0-1000), enter 0 for default, enter the maximum number of threads that can process queued requests for this application.

  5. Click OK.


Specifying the Authentication Protocol

Depending on the security requirements at your site, you can require the Queued Components service always to verify a client's identity, never to verify a client's identify, or to verify a client's identity only if other integrity checks are also being performed.

To specify the authentication protocol

  1. In the console tree of the Component Services administrative tool, under Component Services, open the COM+ Applications folder associated with the computer you want to manage.

  2. Right-click the queued application for which you want to specify the authentication protocol, and then click Properties.

  3. Select the Queuing tab in the properties dialog.

  4. Under MSMQ Message Authentication, select the radio button associated with the authentication protocol you want to implement.

  5. Click OK.


Renewing a Message Queuing Certificate

Under normal circumstances, Message Queuing certificates are generated automatically. Use this procedure only if you need to renew a certificate manually.

Note To perform this task, you must have Message Queuing installed on your computer. For information about installing Message Queuing, see Using Message Queuing, under Application and Development Support on the Help and Support Center page, accessible from the Microsoft® Windows® Start menu.

To renew a Message Queuing certificate

  1. Right-click the My Computer icon on your desktop, and select Manage from the pop-up menu.

  2. Double-click the Message Queuing icon in the Services and Applications folder of the Computer Management tree.

  3. Select the User Certificate tab in the dialog.

  4. Under Internal Certificate, click the Renew button.

  5. Click OK.


Using the Message Mover

You can use the message mover to move requests between queues. The message mover is an Automation object that can be invoked with a simple script. Only users who are assigned the role of QC Trusted User are allowed to use the message mover. For information on how to assign the role of QC Trusted User, see Assigning a User Account or Group to a Role.

Note To use Queued Components, you must have Message Queuing installed on your computer. For information about installing Message Queuing, see Using Message Queuing, under Application and Development Support on the Help and Support Center page, accessible from the Microsoft® Windows® Start menu.

The following VBScript function illustrates the use of the message mover to move a Queued Components request between queues, where strSource is the path to the source queue and strDest is the path to the destination queue on your computer.

Function MyMessageMover ( _
  strSource, _
  strDest _
)  ' Return False if any errors occur.

    MyMessageMover = False  ' Initialize the function.
    On Error Resume Next    ' Initialize error handling.
    Err.Clear               ' Clear the error object.

    Dim objMessageMover   ' The message mover
    Dim lngMovedMessages  ' Number of messages moved

    Set objMessageMover = Wscript.CreateObject("QC.MessageMover")
    If Err.Number <> 0 Then
        MsgBox "Error # " & Hex(Err.Number) & vbNewLine & Err.Description
        Exit Function  ' Replace with specific error handling.
    End If

    objMessageMover.SourcePath = strSource
    objMessageMover.DestPath = strDest
    lngMovedMessages = objMessageMover.MoveMessages
    If Err.Number <> 0 Then
        MsgBox "Error # " & Hex(Err.Number) & vbNewLine & Err.Description
        Exit Function  ' Replace with specific error handling.
    End If

    Wscript.Echo lngMovedMessages, "messages moved from", _
      strSource, "to", strDest

    MyMessageMover = True  ' Successful end to procedure
    Set objMessageMover = Nothing
    Set lngMovedMessages = Nothing
End Function

The following VBScript code demonstrates how to call the MyMessageMover function.

' Replace AppName with a COM+ application that has Queuing enabled.
If Not MyMessageMover(".\private$\AppName_deadqueue", ".\AppName") Then
    Wscript.Echo "MyMessageMover failed."
End If


COM+ Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

A

return to top

access token

An object that describes the security context of a process or thread. The information in a token includes the identity and privileges of the user account associated with the process or thread. When a user logs on, the system verifies the user's password by comparing it with information stored in a security database. If the password is authenticated, the system produces an access token. Every process executed on behalf of this user has a copy of this access token. See also context, primary access token.

ACID properties

Acronym coined by transaction processing pioneers for atomic, consistent, isolated, and durable. These properties ensure predictable behavior, reinforcing the role of transactions as all-or-none propositions designed to provide consistent and predictable results in a distributed environment when independent failures can occur.

activation

The chain of events that results in the creation of a COM object and the return of a valid pointer to an interface on that object. In COM+, an object gets activated either in its own context or in that of its creator (an object that has requested the object being activated). COM+ services rely on appropriate activation of an object based on the object's configuration. In the course of activation, the system determines the context in which the object runs, initializes the context properties, checks access permissions, and establishes a security identity. See also activation security, activation type, context, Just-in-Time (JIT) Activation.

activation security

A form of security protection that determines who can launch a server. Activation security is automatically applied by the Service Control Manager (SCM) of a particular machine. Upon receipt of a request from a client to activate an object, the SCM checks the request against activation-security information stored within its registry. Activation security is also checked for same-machine activations. Also called launch security. See also activation, activation type, call security, Service Control Manager (SCM).

activation type

Activation category for a COM+ application that indicates whether the application runs in or out of its client's process space (depending on whether it's a library or server application, respectively) as well as whether the application runs as an NT service. See also COM+ library application, COM+ server application.

activity

In COM+, a logical thread comprising one or more transactions and containing a collection of components that are grouped into a COM+ application. Every COM object belongs to one activity. The association between an object and an activity cannot be changed.

apartment model process

A process that has two or more single-threaded apartments and no multithreaded apartments. See also free-threaded process, mixed model process, multithreaded apartment model, neutral apartment model, single-threaded process.

application pooling See COM+ Application Pooling .

application recycling See COM+ Application Recycling .

application proxy

A set of files containing registration information that allows a client to remotely access a COM+ server application. When installed on a client computer, an application proxy file writes information about the server application to the client computer; the client can then remotely access the server application.

authentication

The security process of determining that a caller of an application is actually who it says it is—verifying the authenticity of an identity claim. For COM+ applications, authentication can be turned on and configured administratively, after which it works transparently to the application.

authorization

The security process of determining whether a caller of an application is authorized to do what it is asking to do.

C

return to top

caching resource manager

A resource manager that acts as a front-end to another resource manager and that caches information locally, reducing the cost of accessing the underlying resource. Unlike a conventional resource manager, a caching resource manager does not participate in recovery because it never permanently stores the underlying data. See also resource manager.

call security

A form of security protection that helps control access to a server object's methods after a server has been launched. See also activation security.

class (COM)

A named, concrete implementation of one or more interfaces. A COM class is identified by a CLSID and, sometimes, a ProgID. See also interface, method.

cloaking

A server's ability to mask its own identity when making calls on a client's behalf. When cloaking is enabled, calls made by the server impersonating the client can be made under the client's identity. When cloaking is disabled, calls by the server will be made under the server's identity. See also dynamic cloaking, impersonation, static cloaking.

COM+ application

The primary unit of administration and security for Component Services. A COM+ application is a group of COM components that, generally, perform related functions. These components further consist of COM interfaces and methods. See also interface, method.

COM+ Application Pooling

A Component Services feature that allows single-threaded processes to scale and can also help you recover from failures in single processes by providing other running processes able to handle activations. See also COM+ Application Recycling .

COM+ Application Recycling

A Component Services feature that significantly increases the overall stability of your applications by allowing you to gracefully shut down a process associated with an application and restart it. See also COM+ Application Pooling.

COM+ catalog

The data store that holds COM+ configuration data. Performance of COM+ administration tasks requires reading and writing data stored in the catalog. The catalog can be accessed only through the Component Services administrative tool or through the COMAdmin library.

COM+ Events

COM+ Events matches and connects publishers and subscribers via a loosely coupled events sytem. A publisher makes the method call to initiate an event, and a subscriber receives these calls via the event system rather than directly from the publisher. The COM+ Events service maintains the list of interested subscribers who receive the calls and directs those calls without requiring the knowledge of the publisher. See also loosely coupled event, publisher, subscriber, tightly coupled event.

COM+ library application

A COM+ application that runs in the process of the client that creates it. Library applications can use role-based security but do not support remote access or queued components. See also COM+ server application, role-based security.

COM+ Object Pooling

An automatic service provided by COM+ that enables you to configure a component to have instances of itself kept active in a pool, ready to be used by any client that requests the component.

COM+ Partitions

A COM+ service that enables, on a single machine, the creation of separate execution spaces for applications.

COM+ partition sets

A group of COM+ partitions that is mapped to a particular user ID in Active Directory.

COM+ Queued Components

A COM+ service, based on Microsoft® Message Queuing, that provides an easy way to invoke and execute components asynchronously. Message processing can occur without regard to the availability or accessibility of either the sender or the receiver.

COM+ server application

A COM+ application that runs in its own process. Server applications can support all COM+ services. See also COM+ library application.

COM+ SOAP

A Component Services feature that allows you to expose a COM+ application as an XML Web service. COM+ SOAP also enables you to use an XML Web service as a COM component. See also SOAP, XML Web services.

COM component

A binary unit of code that includes packaging and registration code and that creates COM objects. All COM+ applications consist of one or more COM components.

commit tree

In a distributed transaction system, the conceptual representation of a transaction as based on the hierarchical relationships between individual transaction managers participating in a distributed transaction. Included in that hierarchy are the enlisted resource managers associated with the transaction managers. See also distributed transaction, Distributed Transaction Coordinator (DTC), global commit coordinator, resource manager, transaction, transaction manager.

COM object

In the COM programming model, a programming structure encapsulating both data and functionality, which are defined and allocated as a single unit and for which the only public access is through the programming structure's interfaces. A COM object must support, at a minimum, the IUnknown interface, which maintains the object's existence while it is being used and provides access to the object's other interfaces. See also interface, method, pseudo-object.

Compensating Resource Manager (CRM)

A COM+ feature that enables non-transactional resources to participate in a two-phase commit transaction with the Microsoft® Distributed Transaction Coordinator (DTC). Typically, CRMs do not provide the isolation capabilities of full resource managers, but they do provide transactional atomicity and durability by writing to a log. See also Distributed Transaction Coordinator (DTC), resource manager, two-phase commit protocol.

Component Services administrative tool

Introduced in the release of the Microsoft Windows® 2000 operating system, a user-interface snap-in through which administrators and developers can create, configure, and maintain COM+ applications, as well as administer distributed transactions and memory-resident databases. The Component Services administrative tool can also be used to view system events and manage system services local to the computer on which the tool is installed.

conceptual model

The first step in the COM+ application design phase, where the developer defines the business problems to be solved and decides what components and services are required. See also logical model, physical model, three-tier architectural model.

concurrency

The ability of more than one transaction or process to access the same data at the same time. COM+ generally manages concurrency through synchronization. See also synchronization.

configured component

A COM component that has been installed into a COM+ application. After it is installed, the component is configured within the COM+ catalog to make use of the available COM+ services. See also COM component, unconfigured component.

context

A set of run-time properties associated with one or more COM objects that are used to provide services for those objects. Every COM object runs in a single context from activation to deactivation (always within the same apartment). Initialized when an object is activated, context properties, such as security context properties, represent the run-time needs of an object. See also activation.

D

return to top

data tier

In the three-tier architecture model for business applications, the DBMS access layer, which can be accessed through the middle tier, or business services layer, and on occasion through the presentation tier, or user services layer. The data tier consists of data access components (rather than raw DBMS connections) to aid in resource sharing and to allow clients to be configured without installing the DBMS libraries and ODBC drivers on each client. Also called data services layer. See also middle tier, presentation tier, three-tier architectural model.

deadlock

In multithreaded applications, a threading problem that occurs when each member of a set of threads is waiting for another member of the set.

delegation

A form of impersonation that authorizes a server to act on a client's behalf, giving the server the ability to impersonate clients over the network. See also impersonation.

distributed transaction

A transaction that involves multiple resource managers, which can be on the same or different machines. See also transaction.

Distributed Transaction Coordinator (DTC)

A system service that manages transactions and transaction-related communications that are distributed across two or more resource managers on one or more systems to ensure correct ACID transactions. See also ACID properties, distributed transaction, transaction, transaction manager.

dynamic cloaking

A form of cloaking where the original client identity is discovered as the server thread access token on each method call to the downstream server. Although the identity that is presented can be determined dynamically, the overhead required to do this can be considerably more expensive. For COM+ applications, the default configuration is for dynamic cloaking capability because it provides the flexibility that is usually required by circumstances that necessitate using impersonation in the first place. See also cloaking, impersonation, static cloaking.

E

return to top

enumerator object

Enables enumeration of items in a collection. See also COM object.

event

An action recognized by an object, such as clicking the mouse or pressing a key, and for which you can write code to respond. See also COM+ Events.

event class object

A configured component that provides a persistent record in the COM+ event system to describe the publishers and the firing interfaces associated with those publishers. See also COM+ Events.

event method

A method in a COM+ interface that identifies a COM+ event. Event methods must be uniquely named and can contain only input parameters. The return value must be an HRESULT. See also interface, method.

event object

A COM object that can signal one or more threads that an event has occurred, essentially acting as a traffic cop. Any thread within a process can create an event object. See also COM object.

exception

An abnormal condition or error that occurs during the execution of a program and that requires the execution of software outside the normal flow of control.

F

return to top

failover

In a cluster network system, the process of relocating an overloaded or failed resource—such as a server, a disk drive, or a network—to its backup component.

free-threaded process

A process that has a multithreaded apartment and no single-threaded apartments. See also apartment model process, mixed model process, multithreaded apartment model, neutral apartment model, single-threaded process.

G

return to top

global commit coordinator

On a Microsoft Windows–based distributed transaction system, the root transaction manager of the commit tree. This coordinator makes the decision to either commit or abort a given transaction and is never in doubt. See also commit tree, distributed transaction, Distributed Transaction Coordinator (DTC), transaction, transaction manager.

I

return to top

impersonation

The ability of a thread to execute in a security context different from that of the process owning the thread. The server thread uses an access token representing the client's credentials, and with this, it can access resources that the client can access. See also access token, context, impersonation level.

impersonation level

The setting used by the client to grant the server a particular level of authority to carry out actions on the client's behalf. In COM+, this can be set only for COM+ server applications.

interception

For an object activated in a given context, the process of handling calls to that object from across the context boundary. Calls across context are handled with lightweight interface proxies that will handle whatever mediation is required to adjust the run-time environment from one that accommodates the caller to one that accommodates the callee. See also activation, context, interface proxy.

interface

In COM-based programming, a collection of related public functions that provide access to a COM object. The set of interfaces on a COM object composes a contract that specifies how programs and other objects can interact with the COM object. See also class (COM), COM object, method.

interface proxy

An interface-specific object that packages (marshals) parameters for that interface in preparation for a remote method call and unpackages (unmarshals) the return values from the interface stub. A proxy runs in the address space of the sender and communicates with a corresponding stub in the receiver's address space. See also interface stub.

interface stub

An interface-specific object that unpackages marshaled parameters, calls the required method, and packages (marshals) return values from the called method. The stub runs in the receiver's address space and communicates with a corresponding interface proxy in the sender's address space. See also interface proxy.

interior object

In a transactional hierarchy, any object under the root object. See also COM object, root object.

J

return to top

Just-in-Time (JIT) Activation

An automatic service provided by COM+ that allows idle server resources to be used more productively. When a component is configured as JIT activated, COM+ can deactivate an instance of it while a client still holds an active reference to the object. The next time the client calls a method on the object, COM+ will reactivate the object transparently to the client, just in time. See also activation.

L

return to top

launch security See activation security.

legacy component

An unconfigured component that has been installed into a COM+ application. See also COM component, configured component, unconfigured component.

listener

An architectural element of the COM+ Queued Components service. The listener is a COM object that opens the message queue associated with its host application and waits for messages to arrive. As messages arrive, the listener dispatches threads that process messages. See also COM+ Queued Components, message mover, player, recorder.

logical model

The second step in a COM+ application design process, where the conceptual model is broken out into the logical tiers of the three-tier architecture, as follows: the presentation tier, or user services; the middle tier, or business services; and the data tier, or data services. See also conceptual model, data tier, middle tier, physical model, presentation tier, three-tier architectural model.

loosely coupled event

An event whose sender (publisher) and receiver (subscriber) are not closely bound. In a loosely coupled event system, such as COM+ Events, event information from different publishers is persisted in an event store. Subscribers query this store and select the events that they want to receive. Selecting event information from the event store creates a subscription. When an event occurs, the event system looks in this database and finds the interested subscribers, creates a new object of each interested class, and calls a method on that object. See also COM+ Events, tightly coupled event.

M

return to top

marshaling

The process of packaging and unpackaging interface method parameters across thread or process boundaries so that a remote procedure call can take place.

message mover

The architectural element of the COM+ Queued Components service that moves failed messages back to their input queue so that they can be retried. See also COM+ Queued Components, listener, player, recorder.

meta-event

A type of event used by the COM+ Events system to notify interested subscribers whenever event class objects or subscriptions are created, modified, or removed. See also COM+ Events, event, event class object.

method

In COM-based programming, a process performed by a COM object when it receives a message. See also COM object, interface.

middle tier

In the three-tier architecture model for business applications, the layer comprising the business logic and data rules. The components that make up the middle tier can be used to enforce business rules, such as business algorithms, legal or governmental regulations, and data rules, which are designed to keep the data structures consistent within either specific or multiple databases. Because these middle-tier components are not tied to a specific client, they can be used by all applications and can be moved to different locations as response time and other rules require. Also called business services layer or business logic tier. See also data tier, presentation tier, three-tier architectural model.

mixed model process

A process that has a multithreaded apartment and one or more single-threaded apartments. See also apartment model process, free-threaded process, multithreaded apartment model, neutral apartment model, single-threaded process.

moniker

A name that uniquely identifies a COM object. In the same way that a path identifies a file in the file system, a moniker identifies a COM object in the directory namespace. See also COM object.

.msi file

A file created by the Component Services administrative tool when you export a COM+ application or application proxy for installation on another computer. The .msi file can be installed on any Windows-based client using Windows Installer. See also application proxy, COM+ application, Component Services administrative tool.

multithreaded apartment model

An apartment model in which all the threads in the process that have been initialized as free-threaded reside in a single apartment. Therefore, there is no need to marshal between threads. The threads need not retrieve and dispatch messages because COM does not use window messages in this model. See also apartment model process, free-threaded process, mixed model process, neutral apartment model, single-threaded process.

N

return to top

nested transaction

A secondary transaction initiated from within an existing primary or parent transaction boundary. The primary transaction does not commit until all of its subordinate, or nested, transactions commit. COM+ does not support nested transactions. See also transaction.

neutral apartment model

A threading model in which objects follow the guidelines for multithreaded apartments but can execute on any kind of thread. The neutral apartment model is the recommended threading model for COM components and COM+ applications. See also apartment model process, free-threaded process, mixed model process, multithreaded apartment model, single-threaded process.

O

return to top

object See COM object.

object pooling See COM+ Object Pooling.

P

return to top

partitions See COM+ Partitions.

partition sets See COM+ partition sets.

persistent object

A COM object that can save its internal state when asked to do so by a client and that conforms to COM-defined standards through which clients can request objects to be initialized, loaded, and saved to and from a data store (for example, flat file, structured storage, or memory). It is the client's responsibility to manage the location where the object's persistent data is stored but not the format of the data. See also COM object, persistent object interface.

persistent object interface

A COM interface implemented by a persistent object. Clients use persistent object interfaces to tell those persistent objects when and where to store their state. See also interface, persistent object.

Phase Zero notification interface

COM+ interface that allows applications to detect when a transaction is ready to proceed with a two-phase commit protocol so that it can perform the necessary notification operations and communicate to the transaction manager when the operations have been completed. See also interface, two-phase commit protocol.

physical model

The third and final step in the COM+ application design process, where the developer determines where the components reside physically and how they are to be coded. See also conceptual model, logical model, presentation tier, three-tier architectural model.

player

The architectural element of the COM+ Queued Components service that retrieves the message from a queue and then loads the server object and the standard interface stubs to unmarshal data and invoke server methods. The player unmarshals the client's security context at the server side and then invokes the server component and makes the same method calls. The method calls are not played back by the player until the client component completes and the transaction that recorded the method calls commits. See also COM+ Queued Components, listener, message mover, recorder.

presentation tier

In the three-tier architecture model for business applications, the layer that presents data to the user and optionally permits data manipulation and data entry. The two main types of user interface for the presentation tier are the traditional application and the Web-based application. Also called user services layer. See also data tier, middle tier, three-tier architectural model.

primary access token

Describes the security context of the user account associated with a process. See also access token, context.

proxy manager

In standard marshaling, a component that manages all the interface proxies for a single object. See also interface proxy, marshaling.

pseudo-object

A type of contained object, such as a user selection in a document, a range of cells in a spreadsheet, or a range of characters in a text document. This type of object is called a pseudo-object because it isn't treated as a distinct object until a user marks the selection. See also COM object.

publisher

The sender of an event. In the COM+ Events architecture, the publisher makes the method call to initiate an event. See also COM+ Events, subscriber.

Q

return to top

queued components See COM+ Queued Components.

queue moniker

The moniker used to activate a queued component. See also COM+ Queued Components, moniker.

R

return to top

race condition

In a multithreaded application, a condition that occurs when multiple threads access a data item without coordination, possibly causing inconsistent results, depending on which thread reaches the data item first. COM supplies some functions specifically designed to help avoid race conditions in out-of-process servers. See also multithreaded apartment model.

recorder

The architectural element of the COM+ Queued Components service that marshals the client's security context into a message and records all of the method calls for an object. The recorder is a system-provided proxy manager that selects interfaces from the queuable interfaces in the COM+ catalog. See also COM+ Queued Components, COM+ catalog, listener, message mover, player.

resource dispenser

In the COM+ programming model, a component that manages nondurable shared state on behalf of the application components within a process. Resource dispensers are similar to resource managers but without the guarantee of durability. See also Shared Property Manager (SPM).

resource manager

A service that manages persistent or durable data in databases, durable message queues, or transactional file systems. It is the resource manager that knows how to store data and perform disaster recovery. COM+ server applications use resource managers to maintain the durable state of an application, such as the record of inventory on hand, pending orders, and accounts receivable. Resource managers work in cooperation with the Microsoft Distributed Transaction Coordinator (DTC) to guarantee atomicity and isolation to an application. See also caching resource manager, Distributed Transaction Coordinator (DTC).

role-based security

A COM+ security service provided for COM+ applications. A role represents a category of users defined for a COM+ application for the purpose of determining access permissions to the application's resources. Roles are assigned by a developer to components, interfaces, and methods. Users are assigned by an administrator to appropriate roles, enabling a user within a given role to access any resources to which that role is assigned.

root object

The first object of a transaction, called the root of the transaction, and always placed in a new transactional boundary. There can be only one root object in a transaction. All other objects in the transactional hierarchy under the root object are called interior objects. See also COM object, interior object.

root transaction manager

The transaction manager on the system that initiates a transaction. The transaction is not finalized until the root transaction manager determines the transaction's status (either committed or aborted). See also Distributed Transaction Coordinator (DTC), transaction manager.

S

return to top

semaphore

A kernel object used to arbitrate access to a shared resource.

Service Control Manager (SCM)

A Microsoft Windows server process that manages all the services in the Windows registry.

Shared Property Manager (SPM)

In Com+, a resource dispenser that you can use to share nonpersistent state among multiple objects within a server process. See also resource dispenser.

single-threaded process

A process that consists of just one single-threaded apartment, which in turn consists of exactly one thread. All COM objects that live in a single-threaded apartment can receive method calls from only the one thread that belongs to that apartment. See also apartment model process, free-threaded process, mixed model process, multithreaded apartment model, neutral apartment model.

SOAP

A simple, XML-based protocol for exchanging structured and type information on the Web. The protocol contains no application or transport semantics, which makes it highly modular and extensible. See also COM+ SOAP, XML Web Services.

split registration

For components that are already existing COM components and are used in the COM+ services environment, the registration arrangement in which the basic COM aspect of the registration is stored in the Windows registry and new COM+ services and attributes (for example, Queued Components) are stored in the COM+ Registration Database. Each component attribute is stored in either the Windows registry or the COM+ Registration Database. New COM components are registered exclusively in the COM+ Registration Database, with some duplication in the Windows registry so that existing tools can use them.

stateful

Of or pertaining to a system or process that monitors all details of the state of an activity in which it participates. See also stateless.

stateless

Of or pertaining to a system or process that participates in activity without monitoring all details of its state. See also stateful.

static cloaking

A form of cloaking where the original client identity can be presented once to a downstream server, setting the original client identity once on the proxy. This client identity is presented as a server thread token that will be used on subsequent method calls. See also cloaking, dynamic cloaking, impersonation.

subscriber

The receiver of an event. In the COM+ Events architecture, the subscriber receives the calls made by the publisher. See also COM+ Events, publisher.

subscription object

In the COM+ Events system, an object created by a subscriber to request and manage the delivery of events. See also COM+ Events, subscriber.

synchronization

In COM+, a service that flows from component to component and prohibits more than one caller from entering the component at any given time. Synchronization determines when threads can dispatch calls to an object.

T

return to top

three-tier architectural model

The fundamental framework for the logical design model, segments an application's components into three tiers of services as follows: the presentation tier, or user services; the middle tier, or business services; and the data tier, or data services. These tiers do not necessarily correspond to physical locations on various computers on a network, but rather to logical layers of the application. See also conceptual model, data tier, logical model, middle tier, physical model, presentation tier.

tightly coupled event

An event whose sender (publisher) and receiver (subscriber) are closely bound. In a tightly coupled event system, the publisher is provided with an interface on which to call a method when a change occurs. The subscriber knows which publisher to request notification from and the interfaces that are exposed. A tightly coupled event system requires that both the publisher and the subscriber are running at all times. See also COM+ Events, loosely coupled event.

trace log

A log file automatically generated by the Microsoft Distributed Transaction Coordinator that shows data related to one or more distributed transactions. Examples of data in a trace log are transaction ID, transaction time, and messages indicating the transaction outcome.

transaction

A unit of work in which a series of related operations occur during an application process. A transaction executes exactly once and is atomic—either all of the work is done or none of it is. See also distributed transaction.

transaction commit tree See commit tree.

Transaction Internet Protocol (TIP)

Transaction Internet Protocol is a standard two-phase commit protocol that enables heterogeneous transaction managers to coordinate distributed transactions, especially over the Internet. The TIP two-phase commit protocol is simple to implement and is independent of the application-to-application communications protocol, such that it may be used with any application protocol but especially HTTP. See also two-phase commit protocol.

transaction manager

The part of the Microsoft Distributed Transaction Coordinator (DTC) that executes on each machine participating in a distributed transaction and manages the activities related to committing or aborting that part of the transaction. See also Distributed Transaction Coordinator (DTC), root transaction manager.

transaction processing application

A collection of transaction operations that automate a given business task. See also distributed transaction, transaction, transaction processing system.

transaction processing system

A complete system, comprising both computer hardware and software, that hosts a transaction processing application to perform routine transactions necessary to conduct business. See also distributed transaction, transaction, transaction processing application.

two-phase commit protocol

A protocol used only in distributed transactions, ensures that the outcome of a transaction is consistent across all transaction managers participating in the transaction. The protocol operates in two distinct phases to ultimately commit or abort a transaction: Phase one evaluates the condition of each resource manager, and phase two completes the transaction. See also distributed transaction, resource manager, transaction, Transaction Internet Protocol (TIP), transaction manager.

U

return to top

unconfigured component

A COM component that has not been configured within the COM+ catalog. Unconfigured components cannot make use of COM+ services. See also COM component, configured component.

W

return to top

whereabouts

For DTC transactions, an opaque data structure that represents the address of the resource manager's transaction manager.

X

return to top

XA interfaces

A standard set of programming interfaces that allow COM+ application developers to access XA-compliant databases and create resource managers that operate with relational databases, message queuing, transactional files, and object-oriented databases. Although Microsoft does not directly support the XA protocol, Microsoft does support translation facilities between OLE transactions and XA.

XML Web services

Units of application logic providing data and services to other applications. Applications access XML Web services via standard Web protocols, such as SOAP. See also COM+ SOAP, SOAP.


Administering (D)COM Applications

The Component Object Model (COM) allows functionality to be encapsulated in a COM application that can be re-used by many different applications. Distributed COM (DCOM) technology even allows a COM application to be accessed from different computers over a network.

The topics described in the following table provide detailed background and task information about administering COM applications.

Topic | Description
COM Administration Concepts | Provides an overview and links to more information about administering COM applications.
COM Administration Tasks | Provides links to step-by-step procedures for administering COM applications.


COM Administration Concepts

The following topics in this section provide detailed information about administering COM applications:

  • COM Security Settings


COM Security Settings

COM applications—for example, Microsoft® Word—use a number of security configuration properties: authentication level, impersonation level, access permissions, launch permissions, and configuration permissions. These properties have machine-wide settings that an application can use by default. Alternatively, COM security properties can be configured specifically for any particular application. If an application does not have specific security settings, it uses the machine-wide security settings. A machine-wide restriction policy specifies a minimum level of security that cannot be overridden by either application-specific or machine-wide security settings.

While it is generally unnecessary to change any settings, security requirements for particular applications or particular systems may dictate that you do so. You can change the security settings for a specific COM application, the machine-wide security settings, and the machine-wide restriction policy using the Component Services administrative tool.

Machine-Wide Security Settings

For each COM security property, a COM application can either use the machine-wide setting or use a custom setting. Whenever an application has custom security settings, the machine-wide settings are disregarded, but an application that does not have its own settings uses the machine-wide settings.

If the default values do not meet the security requirements of the applications on your system, you can use the Component Services administrative tool to modify the machine-wide security settings. However, you should remember that changing the machine-wide settings affects every COM application that does not have a custom configuration.

If you want to use the default machine-wide settings, you do not have to do anything. COM uses the following default values automatically for the machine-wide security settings:

  • An authentication level of Connect.

  • An impersonation level of Identify.

  • Access permissions granting permissions to the server identity and the local system.

  • A principal name based on the user name and password.

  • A security service provider determined by COM to be the best for the environment. In Microsoft Windows® 2000, Windows XP, and Windows Server 2003, this is Kerberos or NTLMSSP.

See the topics described in the following table for background and task information about setting security levels in COM.

Topic | Description
Authentication Level | Provides an overview of levels at which client and server use credentials to verify each another's identity, and by which they verify and encrypt data that passes between them.
Impersonation Level | Introduces levels through which a server makes a call on behalf of a client and presents the client's identity and credentials in place of its own when making the call.
Access Permissions | Introduces permissions specifying a list of users who are granted or denied access to COM applications.
Launch and Activation Permissions | Provides an overview of permissions that specify a list of users who are granted or denied permission to start or use COM applications.
Reference Tracking | Introduces a technology through which COM does additional security checks to authenticate reference count calls and tracks additional information to prevent objects from being accidentally or maliciously released too early.


Authentication Level

Authentication is the process by which client and server use credentials to verify each another's identity and by which they verify and encrypt data that passes between them.

The authentication level setting indicates what degree of authentication is required for communication with an application (when it makes or receives calls). Higher authentication levels provide greater security and data integrity, although usually with some performance degradation.

Using the Component Services administrative tool, you can change the machine-wide setting for the authentication level. This machine-wide setting is used when a COM application doesn't specify an authentication level programmatically. The default setting for machine-wide authentication level is Connect.

For step-by-step instructions on setting levels, see Setting the Machine-Wide Authentication Level.

The levels, from lowest to highest security, are described in the following table.

Level | Description
None | No authentication occurs.
Connect | Authenticates credentials only when the connection is made.
Call | Authenticates credentials at the beginning of every call.
Packet | Authenticates credentials and verifies that all call data is received.
Packet Integrity | Authenticates credentials and verifies that no call data has been modified in transit.
Packet Privacy | Authenticates credentials and encrypts the packet, including the data and the sender's identity and signature.


Impersonation Level

Impersonation is the process by which a server makes a call on behalf of a client and presents the client's identity and credentials in place of its own when making the call. This can take place only when the client explicitly grants the server permission to use its identity.

The impersonation level setting is used by the client to grant the server a particular level of authority to carry out actions on its behalf. The highest level of trust is required for the server to impersonate the client over the network. Local impersonation is impersonate-level impersonation; impersonation over the network is delegate-level impersonation, or delegation. To perform delegation, the server must be running under an identity marked as "Trusted for delegation" in Active Directory. To grant delegate-level authority, the client must not be marked as "Account is sensitive and cannot be delegated" in Active Directory. (See Application Identity for more information about identities and delegation.)

Using the Component Services administrative tool, you can change the machine-wide setting for the impersonation level. This machine-wide setting is used when a COM client on the machine doesn't specify an impersonation level programmatically. The default setting for machine-wide impersonation level is Identify.

For step-by-step instructions, see Setting the Machine-Wide Impersonation Level.

The levels, from granting least to greatest authority, are described in the following table.

Level | Description
Anonymous | The client is anonymous to the server. The server can impersonate the client, but the impersonation token (a local credential) does not contain any information about the client.
Identify | The server can obtain the client's identity and can impersonate the client to do access-control list checks.
Impersonate | The server can impersonate the client while acting on its behalf, but with restrictions. The server can access resources on the same computer as the client. If the server is on the same computer as the client, it can access network resources as the client. If the server is a computer different from the client, it can access only resources that are on the same computer as the server.
Delegate | The server can impersonate the client while acting on its behalf, whether or not on the same computer as the client. During impersonation, the client's credentials (both those with local and those with network validity) can be passed to any number of machines.


Access Permissions

Access permissions specify a list of users who are granted or denied access to COM applications. The machine-wide access permissions apply to all COM applications that do not specify their own access permissions.

Access permissions can be specified separately for each COM application. The machine-wide default access permissions apply to all COM applications that do not specify their own access permissions. The machine-wide restriction policy limits access permissions that can be granted using either scenario.

Access permissions are divided into local access permission and remote access permission. Users with local access permission may access a COM application running on the same machine as the calling client. Users with remote access permission may access a COM application from other computers across a network connection.

Using the Component Services administrative tool, you can add or remove user accounts or groups from the list of user access permissions. This does not affect COM+ applications.

A machine-wide restriction policy limits the access permissions that can be granted to COM applications. The Administrator can use the machine-wide restriction policy limits to override less restrictive application-level or machine-wide default permissions. By default, the machine-wide restriction policy allows local and remote access permission to be granted to members of the Everyone group, and local access permission to be granted to members of the Everyone group and the Anonymous User. If the system policy excludes the "Anonymous User" from the Everyone group, then anonymous clients are not allowed to access COM applications remotely.

For step-by-step instructions on changing these settings, see Setting Machine-Wide Access Permissions or Setting Application-Specific Access Permissions.


Launch and Activation Permissions

Launch and activation permissions specify a list of users who are granted or denied permission to launch or activate COM applications. Launch permission is required to start a new COM application. Activation permission is required for a new client to use a COM application, even if the application has already been launched.

You can specify separate lauch and activation permissions for each COM application. The machine-wide default launch and activation permissions apply to all COM applications that do not specify their own launch permissions. The machine-wide restriction policy limits the launch and activate permissions that can be granted using either scenario.

Launch and activation permissions are divided into local and remote launch and activation permissions. Users with local launch or activation permission can start or use a COM application running on the same machine as the calling client. Users with remote launch or activation permission can start or use a COM application from other computers across a network connection.

Using the Component Services administrative tool, you can add or remove user accounts or groups from the list of users that have machine-wide launch and activation permissions. This does not affect COM+ applications.

A machine-wide restriction policy limits the launch and activation permissions that can be granted to COM applications. The Administrator can use the machine-wide restriction policy limits to override less restrictive application-level or machine-wide launch and activation permissions. By default, the machine-wide restriction policy allows local and remote launch and activation permissions to be granted to members of the Administrators group, and local launch and activation permissions to be granted to the Everyone group. If the system policy excludes the "Anonymous User" from the Everyone group, then anonymous clients are not allowed to launch or activate COM applications.

For step-by-step instructions on changing these settings, see Setting Machine-Wide Launch and Activate Permissions or Setting Application-Specific Launch and Activate Permissions.


Reference Tracking

When you enable reference tracking, also known as secure reference counting, COM does additional security checks to authenticate reference count calls and tracks additional information to prevent objects from being accidentally or maliciously released too early. Enabling reference tracking increases system security but can decrease performance. Reference tracking is not supported for a Default Authentication Level of None nor for a Default Impersonation Level of Anonymous.

For step-by-step instructions, see Setting Machine-Wide Reference Tracking.


COM Administration Tasks

The following topics in this section provide step-by-step instructions for administering COM applications:

  • Setting the Location of a COM Application

  • Setting the Identity of a COM Application

  • Setting Machine-Wide COM Security Configuration

  • Setting Application-Specific COM Security Configuration


Setting the Location of a COM Application

The location tells COM on which computer a COM application should run.

To set the location of a COM application

  1. In the console tree of the Component Services administrative tool, right-click the DCOM application you want to modify and then click Properties.

  2. Select the Location tab.

  3. Select the checkbox that specifies where you want the application to run. To run the application on a computer other than the current computer or the computer where the data is located, select Run application on the following computer and enter the NetBIOS name of the computer on which to run the application.


Setting the Identity of a COM Application

The identity tells COM under which user identity a COM application should run.

To set the identity of a COM application

  1. In the console tree of the Component Services administrative tool, right-click the DCOM application you want to modify and then click Properties.

  2. Select the Identity tab.

  3. Select the button that specifies the identity under which you want the application to run.


Setting Machine-Wide COM Security Configuration

Using the Component Services administrative tool, you can set the machine-wide COM security properties that are used by COM applications. For more information about how these security features work, see COM Security Settings.

Step-by-step instructions are provided in this section for the following tasks:

  • Setting the Machine-Wide Authentication Level

  • Setting the Machine-Wide Impersonation Level

  • Setting Machine-Wide Access Permissions

  • Setting Machine-Wide Launch and Activate Permissions

  • Setting Machine-Wide Reference Tracking


Setting the Machine-Wide Authentication Level

The authentication level tells COM the extent to which clients and servers should verify each other's identity during calls between applications. If you want to enable security for a computer, you must choose a machine-wide authentication level other than None. For overview information, see Authentication Level.

To set the machine-wide authentication level

  4. In the console tree of the Component Services administrative tool, right-click the computer whose machine-wide authentication level you want to modify and then click Properties.

  5. Select the Default Properties tab.

  6. Ensure that Enable Distributed COM on this computer is checked.

  7. In the Default Authentication Level box, select a value other than None.

  8. Click OK.

The new machine-wide authentication level is available the next time an application on the computer is started. Applications that are currently running are not affected until they are restarted.


Setting the Machine-Wide Impersonation Level

The impersonation level, set by the client, determines the amount of authority given to the server to act on the client's behalf. Setting the machine-wide impersonation level for the whole computer determines the impersonation level to be used when a particular client doesn't specify an impersonation level programmatically. For overview information, see Impersonation Level.

To set the machine-wide impersonation level

  1. In the console tree of the Component Services administrative tool, right-click the computer whose machine-wide impersonation level you want to modify and then click Properties.

  2. Select the Default Properties tab.

  3. Ensure that Enable Distributed COM on this computer is checked.

  4. In the Default Impersonation Level box, select the impersonation level you want.

  5. Click OK.

The new machine-wide impersonation level is available the next time an application on the computer is started. Applications that are currently running are not affected until they are restarted.


Setting Machine-Wide Access Permissions

Machine-wide access permissions specify users who are granted or denied access to COM applications. Using the Component Services administrative tool, you can change either the machine-wide default access permissions or the machine-wide restriction policy. For overview information, see Access Permissions.

To set machine-wide access permissions

  1. In the console tree of the Component Services administrative tool, right-click the computer whose machine-wide access permissions you want to modify and then click Properties.

  2. Select the COM Security tab.

  3. Under Access Permissions, click either the Edit Limits… button or the Edit Default… button, depending on whether you want to modify the machine-wide restriction policy or the machine-wide default settings. An Access Permission dialog box appears.

  4. To remove a user account or group, select the group or user in the Group or user names list and then click Remove. The selected user account or group no longer appears in the list.

  5. To add a user account or group, click Add. Then, in the Select Users, Computers, or Groups window, in the bottom pane, type the fully qualified name of the user or group you want to add. If you do not know the name, click the Advanced button and then click Find Now to view a list of users and groups in the selected domain. Select a user or group from the Name (RDN) list, and click OK. The added user account or group appears in the Group or user names list.

  6. In the Group or user names list, select the group or user whose macine-wide access permission you want to change.

  7. In the Permissions list, select whether to Allow or Deny local access permission and remote access permission for the selected group or user name.

  8. Click OK to return to the Default COM Security page.

  9. Click OK.

The new machine-wide access permissions are applied the next time an application on the computer is started. Applications that are currently running are not affected until they are restarted.


Setting Machine-Wide Launch and Activation Permissions

The machine-wide launch and activation permissions determine which users are explicitly granted or denied permission to launch and activate COM applications. Using the Component Services administrative tool, you can change either the machine-wide default launch and activation permissions or the machine-wide restriction policy. For overview information, see Launch and Activation Permissions.

Important When setting permissions, you must ensure that SYSTEM is included in the Group or user names list in the Launch and Activation Permission dialog and that SYSTEM is allowed launch permission. SYSTEM is included implicitly in the group Everyone. However, for security reasons, it is recommended that you not enable launch permissions for the group Everyone.

To set machine-wide launch and activation permissions

  1. In the console tree of the Component Services administrative tool, right-click the computer whose machine-wide launch permissions you want to modify and then click Properties.

  2. Select the COM Security tab.

  3. Under Launch and Activation Permissions, click either the Edit Limits… button or the Edit Default… button, depending on whether you want to modify the machine-wide restriction policy or the machine-wide default settings. A Launch Permission dialog box appears.

  4. To remove a user account or group, select the group or user in the Group or user names list and then click Remove. The selected user account or group no longer appears in the list.

  5. To add a user account or group, click Add and, in the bottom pane of the Select Users, Computers, or Groups window, type the fully qualified name of the user or group you want to add. If you do not know the name, click the Advanced button and then click Find Now to view a list of users and groups in the selected domain. Select a user or group from the Name (RDN) list, and click OK. The added user account or group appears in the Group or user names list.

  6. In the Group or user names list, select the group or user whose machine-wide launch and activation permissions you want to change.

  7. In the Permissions list, select whether to Allow or Deny local launch permission, local activation permission, remote launch permission, and remote activation permission for the selected group or user name.

  8. Click OK to return to the Default COM Security page.

  9. Click OK.

The new machine-wide launch and activation settings are applied the next time an application on the computer is started. Applications that are currently running are not affected until they are restarted.


Setting Machine-Wide Reference Tracking

When you enable reference tracking, you are asking COM to do additional security checks and keep track of additional information to keep objects from being accidentally or maliciously released too early. Enabling reference tracking, also known as secure reference counting, can decrease performance. For an overview of reference tracking, see Reference Tracking.

Note You cannot enable reference tracking if either the Default Authentication Level is set to None or the Default Impersonation Level is set to Anonymous.

To enable (or disable) reference tracking for a computer

  1. In the console tree of the Component Services administrative tool, right-click the computer for which you want to set reference tracking and then click Properties.

  2. Select the Default Properties tab.

  3. Ensure that Enable Distributed COM on this computer is checked.

  4. Under Default Distributed COM Communication Properties, select from the following options:
    • To enable reference tracking, select the Provide additional security for reference tracking check box.

    • To disable reference tracking, clear the Provide additional security for reference tracking check box.
  5. Click OK.

The new reference-tracking settings are available the next time an application on the computer is started. Applications that are currently running are not affected until they are restarted.


Setting Application-Specific COM Security Configuration

Using the Component Services administrative tool, you can set COM security properties for a specific COM application. For more information about how these security features work, see COM Security Settings.

Step-by-step instructions are provided in this section for the following tasks:

  • Setting Application-Specific Access Permissions

  • Setting Application-Specific Launch and Activation Permissions


Setting Application-Specific Access Permissions

Application-specific access permissions specify users who are granted or denied access to a COM application. For overview information, see Access Permissions.

To set application-specific access permissions

  1. In the console tree of the Component Services administrative tool, right-click the DCOM application whose access permissions you want to modify and then click Properties.

  2. Select the Security tab.

  3. Under Access Permissions, click the Customize button, then click the Edit… button.

  4. To remove a user account or group, select the group or user in the Group or user names list and then click Remove. The selected user account or group no longer appears in the list.

  5. To add a user account or group, click Add. Then, in the Select Users, Computers, or Groups window, in the bottom pane, type the fully qualified name of the user or group you want to add. If you do not know the name, click the Advanced button and then click Find Now to view a list of users and groups in the selected domain. Select a user or group from the Name (RDN) list, and click OK. The added user account or group appears in the Group or user names list.

  6. In the Group or user names list, select the group or user whose default access permission you want to change.

  7. In the Permissions list, select whether to Allow or Deny local access permission and remote access permission for the selected group or user name.

  8. Click OK to return to the Default COM Security page.

  9. Click OK.

The new application-specific access permissions apply the next time the application is started on the computer.


Setting Application-Specific Launch and Activation Permissions

Application-specific launch and activation permissions specify users who are granted or denied permission to launch or activate to a COM application. For overview information, see Launch and Activation Permissions.

To set application-specific launch and activation permissions

  10. In the console tree of the Component Services administrative tool, right-click the DCOM application whose access permissions you want to modify and then click Properties.

  11. Select the Security tab.

  12. Under Launch and Activation Permissions, click the Customize button, then click the Edit… button.

  13. To remove a user account or group, select the group or user in the Group or user names list and then click Remove. The selected user account or group no longer appears in the list.

  14. To add a user account or group, click Add. Then, in the Select Users, Computers, or Groups window, in the bottom pane, type the fully qualified name of the user or group you want to add. If you do not know the name, click the Advanced button and then click Find Now to view a list of users and groups in the selected domain. Select a user or group from the Name (RDN) list, and click OK. The added user account or group appears in the Group or user names list.

  15. In the Group or user names list, select the group or user whose default access permission you want to change.

  16. In the Permissions list, select whether to Allow or Deny local launch permission, local activation permission, remote launch permission, and remote activation permission for the selected group or user name.

  17. Click OK to return to the Default COM Security page.

  18. Click OK.

The new application-specific launch and activation permissions apply the next time the application is started on the computer.


Administering Distributed Transactions

The COM+ Distributed Transaction Coordinator (DTC) service coordinates transactions that update two or more transaction-protected resources, such as databases, message queues, file systems, and so on. These transaction-protected resources may be contained on a single system or distributed across a network of systems.

Using the Component Services administrative tool, which includes the Microsoft® Distributed Transaction Coordinator (DTC), you can configure your computers and network to support distributed transactions as well as monitor and manage distributed transactions.

Before You Continue

Decisions about transaction attributes, such as when a transactional component requires or supports a transaction, are typically made as the component or application is developed. Administrative decisions, on the other hand, are generally focused on configuring, starting and stopping the DTC, monitoring and managing the flow of transactions, and monitoring transaction performance.

See the topics described in the following table for in-depth background and task information about distributed transaction administration.

Topic | Description
Distributed Transaction Administration Concepts | Provides an introduction to the DTC, along with links to more information.
Distributed Transaction Administration Tasks | Provides links to specific distributed transaction administration tasks.


Distributed Transaction Administration Concepts

In applications developed to use distributed transactions, concurrent work done by multiple clients, components, and databases can be managed to help protect the applications against failures. Within a distributed transaction, either all the work done by participating components happens or none of it does, simplifying tracking and error recovery because no loose ends are left by failures.

The Component Services administrative tool provides several features that allow administrators to perform basic administration of the COM+ Distributed Transaction Coordinator (DTC). These features can be found in three distinct locations within the Component Services user interface:

  • The computer properties dialog box—By accessing the Properties page for a computer listed in the console tree, you can perform several DTC administration tasks. Examples of tasks include starting and stopping the DTC service, changing the location of the DTC log file, and configuring DTC security settings.

  • The menu for a computer—By right-clicking a computer icon listed in the console tree, you can display a menu that allows you to start or stop the DTC service.

  • The Transaction List and Transaction Statistics utilities—These utilities, accessed by expanding the Distributed Transaction Coordinator folder in the console tree, allow you to view and change the status of individual distributed transactions.

For step-by-step procedures for DTC administration using the Component Services administrative tool, see Distributed Transaction Administration Tasks.

For information about additional DTC administration concepts associated with tasks performed with tools other than the Component Services administrative tool, see the Microsoft Platform SDK documentation.


Distributed Transaction Administration Tasks

Administrative tasks for distributed transactions include configuring your system to support distributed transactions, monitoring transactions and managing performance, and resolving problems associated with system failures. For an overview of administering distributed transactions, see Distributed Transaction Administration Concepts.

Note Non-administrative users must have the appropriate access rights to view and modify DTC configuration settings. If a user does not have the appropriate access rights, any attempt to view or modify DTC configuration settings causes a permission denied message to appear. If the user has Read access only, the DTC administrative user interface appears but all administrative functions are grayed out.

See the following topics for step-by-step instructions on performing specific tasks related to the COM+ Distributed Transaction Coordinator (DTC):

  • Configuring the DTC

  • Managing the DTC

  • Troubleshooting DTC Problems


Configuring the DTC

You can use the Component Services administrative tool to configure your system to support distributed transactions. The following topics provide step-by-step instructions for configuring the DTC:

  • Configuring the Default Transaction Coordinator

  • Configuring the Client Network Protocol

  • Configuring the DTC Log File

  • Configuring DTC Security

  • Configuring the DTC Logon Account


Configuring the Default Transaction Coordinator

By default, each system uses its local DTC transaction manager when initiating and coordinating transactions. However, you can configure your computer to use the DTC transaction manager of another system as the default transaction coordinator. The DTC transaction manager on the specified system is used as the transaction coordinator whenever a client on the local system begins a DTC transaction and that client does not explicitly specify a transaction coordinator. The default transaction coordinator coordinates all transactions initiated by COM+. The default transaction coordinator also serves as the transaction coordinator for all resource managers on the local system that enlist in any DTC transaction.

The system you select as the default coordinator should be reliable. The network connection to the default coordinator system should also be reliable. Otherwise, specifying a default coordinator could reduce the availability of the DTC on your local system. A Windows Server 2003 cluster running Cluster service is a good choice to serve as the default coordinator. When you configure a Windows Server 2003 cluster running Cluster service as the default coordinator, you can specify the name of any virtual server running on the cluster.

If you choose a remote default coordinator, both your computer and the remote coordinator must both configured to allow network DTC access. See Configuring DTC Security for instructions.

To configure the default transaction coordinator, you must have administrator privileges on both the local system and the system you are designating as the default transaction coordinator. This makes it possible for the local DTC system to retrieve the appropriate information from the system registry on the default transaction coordinator system.

To designate a remote system as the default transaction coordinator

  1. In the console tree of the Component Services administrative tool, right-click the computer whose transaction coordinator settings you want to change and then click Properties.

  2. In the computer properties dialog box, click the MSDTC tab.

  3. Clear the Use local coordinator check box.

  4. In the Remote Host text box, enter the remote system name. If you are unsure of the exact name, click Select to display a list of all computers on the network and select the computer you want from the list.

  5. Click OK.

To designate the local system as the default transaction coordinator

  1. In the console tree of the Component Services administrative tool, right-click the computer you want to designate as the default transaction coordinator and then click Properties.

  2. In the computer properties dialog box, click the MSDTC tab.

  3. Select the Use local coordinator check box.

  4. Click OK.


Configuring the Client Network Protocol

When you configure the DTC to rely on a remote DTC transaction coordinator, you can specify which RPC transport the DTC proxy uses to communicate with the transaction coordinator on the remote system. Because it is more widely supported, TCP/IP is the default and recommended protocol for the DTC.

Note If Windows Server 2003 was installed as an upgrade from Windows 2000 Server, the network protocols that were available before the upgrade will continue to be available in Windows Server 2003. If Windows Server 2003 was not installed as an upgrade, TCP/IP is the only available network protocol.

To configure the client network protocol

  1. In the console tree of the Component Services administrative tool, right-click the computer whose network protocol type you want set and then click Properties.

  2. In the computer properties dialog box, click the MSDTC tab.

  3. In the Client Network Protocol Configuration box, select TCP/IP or any other network protocol that might be listed.

  4. Click OK.


Configuring the DTC Log File

You can configure the location and size of the DTC log file.

Caution If you change the size of the log file, the current log file is destroyed and a new log file is created. Before altering the DTC log file, verify that the existing log file can safely be deleted by ensuring that there are no transactions in the In Doubt, Cannot Notify Abort, or Cannot Notify Commit state. See Manually Resolving Transactions for more information.

To change the size or location of the log file

  1. In the console tree of the Component Services administrative tool, right-click the computer containing the DTC log file and then click Properties.

  2. In the computer properties dialog box, click the MSDTC tab.

  3. Under Service Control Status for MSDTC, click the Stop button to stop the DTC.

    Note If you do not stop the DTC, your attempt to reset the log file generates a DTC console message indicating that the DTC service needs to be stopped and restarted to perform the requested action.

  4. To change the log file location, under Log Information, in the Location text box, enter the new drive and path for the log file. If you do not know the full path, click the Browse button to select a log file location.

  5. To change the log file size, under Log Information, in the Capacity text box, enter the new log file size in megabytes.

  6. Click the Reset log button to alter the DTC log location and size.

  7. Under Service Control Status for MSDTC, click the Start button to start the DTC.

  8. Click OK.


Configuring DTC Security

  • The DTC allows you to configure the security requirements for distributed transactions in which your computer participates. The default security settings do not allow your computer to participate in remote distributed transactions.

To allow only local transactions:

  1. In the console tree of the Component Services administrative tool, in the Computers folder, right-click the local computer and click Properties.

  2. Click the MSDTC tab.

  3. Click the Security Configuration button.

  4. Under Security Settings on the Security Configuration page, uncheck the Network DTC Access box.

  5. Click OK to return to the computer properties dialog box.

  6. Click OK.

To use a remote transaction coordinator:

  1. In the console tree of the Component Services administrative tool, in the Computers folder, right-click the local computer and click Properties.

  2. Click the MSDTC tab.

  3. Click the Security Configuration button.

  4. Under Security Settings on the Security Configuration page, check the Network DTC Access box.

  5. Under Transaction Manager Communication, check the Allow Inbound and Allow Outbound boxes.

  6. Select an authentication level for DTC communications. Mutual Authentication Required is the most secure level.

  7. Click OK to return to the computer properties dialog box.

  8. Click OK.

To coordinate remote transactions:

  1. In the console tree of the Component Services administrative tool, in the Computers folder, right-click the local computer and click Properties.

  2. Click the MSDTC tab.

  3. Click the Security Configuration button.

  4. Under Security Settings on the Security Configuration page, check the Network DTC Access box.

  5. Under Client and Administration, check the Allow Remote Clients box.

  6. Under Transaction Manager Communication, check the Allow Inbound and Allow Outbound boxes.

  7. Select an authentication level for DTC communications. Mutual Authentication Required is the most secure level.

  8. Click OK to return to the computer properties dialog box.

  9. Click OK.


Managing the DTC

The DTC provides tools you can use to monitor and manage transactions, troubleshoot problems, and optimize performance.

See the following topics for step-by-step details on managing the DTC:

  • Starting and Stopping the DTC

  • Monitoring DTC Performance

  • Viewing Transaction Information

  • Manually Resolving Transactions

  • Resetting the DTC Log File

  • Controlling Background Tracing


Starting and Stopping the DTC

The Component Services administrative tool allows you to start or stop the DTC service.

Note To commit any configuration changes, the Component Services administrative tool requires the DTC to be running. If you attempt to change any settings using the Component Services administrative tool when the DTC is stopped, the DTC is restarted. If you get errors when attempting to use the Component Services administrative tool, verify that the DTC is started and, if not, restart it.

To start or stop the DTC using the Component Services administrative tool

  1. In the console tree of the Component Services administrative tool, click the computer for which you are managing transactions.

  2. Right-click the computer, and then click Start MS DTC or Stop MS DTC.

If the DTC fails to start, examine the Event Viewer administrative tool to see whether any DTC-related events are displayed near the time of the failure. The DTC typically logs an event when it is unable to start successfully.


Monitoring DTC Performance

You can monitor the performance of DTC transactions using the Component Services administrative tool. You would typically perform this task after you have set up transaction parameters.

The Component Services administrative tool includes a Transaction Statistics utility that displays statistical information about the transactions in which a server participated. You can use transaction statistics to get an overview of DTC performance.

To view transaction statistics

  1. In the console tree of the Component Services administrative tool, double-click the computer for which you want to view transaction statistics.

  2. Double-click the Distributed Transaction Coordinator folder, and then click Transaction Statistics.

You can view the states of your transactions under Current, Aggregate, and Response Times groups.


Viewing Transaction Information

Occasionally, if a communication line fails or a faulty distributed transaction application leaves unresolved transactions, you might need to view transaction lists and properties, control which transactions are displayed, set transaction time-out periods, and control how often transactions are updated.

To view the DTC Transaction List

  1. In the console tree of the Component Services administrative tool, double-click the computer for which you want to view the transaction list.

  2. Double-click the Distributed Transaction Coordinator folder, and then double-click Transaction List.

You can use this view to see all transactions, their status, and their identifiers. To resolve transactions, see Manually Resolving Transactions.

To view transaction properties in the DTC Transaction List

  1. In the console tree of the Component Services administrative tool, double-click the computer for which you want to view the transaction list.

  2. Double-click the Distributed Transaction Coordinator folder, and then double-click Transaction List.

  3. In the details pane, right-click the transaction whose properties you want to view and then click View.

  4. Click Properties to list the parent transaction and its children.


Manually Resolving Transactions

Occasionally, you might need to force a transaction to commit or abort to release locks and make database resources available to other network users and applications.

To manually resolve transactions

  1. In the console tree of the Component Services administrative tool, double-click the computer for which you want to view the transaction list.

  2. Double-click the Distributed Transaction Coordinator folder, and then double-click Transaction List.

  3. Right-click the transaction you want to resolve, point to Resolve, and then click Commit, Abort, or Forget.

Whether to commit, abort, or forget a transaction can be determined by reviewing the following procedures.

Resolving the In Doubt State

The In Doubt state indicates that the transaction is on a subordinate DTC and that the superior DTC is inaccessible.

To resolve a transaction in the In Doubt state

  1. Use the Transaction List to locate the in-doubt transaction's immediate parent. For information about how to view transaction properties, see Viewing Transaction Information.

  2. Locate the superior DTC system, and use the Transaction List on that system to determine the outcome of the in-doubt transaction, as follows:
    • If the transaction does not appear in the Transactions page, the transaction has been aborted and you can abort the transaction on the subordinate system manually.

    • If the transaction appears on the superior system as Cannot Notify Commit, the transaction has committed and you can commit the transaction on the subordinate system manually.

    • If the transaction appears on the superior system as Cannot Notify Abort, the transaction has aborted and you can abort the transaction on the subordinate system manually.

    • If the transaction is shown as In Doubt on the superior system, use the Transactions page on that system to locate the transaction's next immediate superior. Continue to follow the transaction up the commit tree until you locate the superior system on which the transaction is not shown (indicating that it aborted), is in the Cannot Notify Abort state (indicating that it aborted), or is in the Cannot Notify Commit state (indicating that it committed). If the transaction is aborted on the superior system, manually force the transaction to abort on that computer's immediate subordinate. If the transaction is committed on the superior system, manually force the transaction to commit on the subordinate system.
  3. When you have either manually committed or manually aborted the transaction on the subordinate system, manually force the immediate superior to forget the transaction.

Resolving the Cannot Notify Abort State

The Cannot Notify Abort state indicates that the transaction has aborted but that a subordinate transaction manager has not been notified of the transaction's outcome. You can manually resolve the transaction as follows.

Caution Do not manually forget a transaction until all subordinate DTCs have been notified of the transaction outcome.

To display a transaction in the Cannot Notify Abort state

  1. Right-click the transaction that is in the Cannot Notify Abort state. This displays the superior DTC and subordinate transaction managers for the transaction.

  2. Having located the subordinate transaction managers, force the transaction to abort on each of the subordinate systems.

  3. When you have manually aborted the transaction on all subordinate systems, return to the DTC that shows the transaction in the Cannot Notify Abort state and force that DTC to forget the transaction.

Resolving the Cannot Notify Commit State

The Cannot Notify Commit state indicates that the transaction has committed but that some subordinate DTC transaction managers or resource managers have not been notified of the transaction's outcome. You can manually resolve the transaction.

Caution Do not manually forget a transaction until all subordinate DTCs have been notified of the transaction outcome.

To resolve a transaction in the Cannot Notify Commit state

  1. Right-click the transaction that is in the Cannot Notify Commit state. This displays the superior and subordinate DTC transaction managers for the transaction.

  2. Having located the subordinate DTC transaction managers, force the transaction to commit on each subordinate system.

  3. When you have manually committed the transaction on all subordinate systems, return to the DTC that shows the transaction in the Cannot Notify Commit state and force that DTC to forget the transaction.


Resetting the DTC Log File

You must reset the DTC log file whenever you want to relocate it to another device or to change its size. Before resetting the DTC log file, ensure that there are no transactions in the In Doubt, Cannot Notify Abort, or Cannot Notify Commit state.

Note You cannot reset the DTC log file on a remote system. Because the Component Services administrative tool updates the DTC log file directly, it must run on the computer where the log file resides.

To reset the DTC log file

  1. In the console tree of the Component Services administrative tool, right-click My Computer and then click Properties.

  2. In the My Computer Properties dialog box, click the MSDTC tab.

  3. Under Service Control Status for MSDTC, click the Stop button to stop the DTC.

  4. Under Log Information, click Reset log to reinitialize the log file.

    Note If a log file already exists in the location specified by the drive and directory, clicking Reset log deletes the current log file. Before deleting an existing log file, you must ensure that there are no transactions in the In Doubt, Cannot Notify Abort, or Cannot Notify Commit states. You can confirm the current transaction state by using the Transaction List in the Component Services administrative tool. See Viewing Transaction Information for more information.

  5. Under Service Control Status for MSDTC, click the Start button to restart the DTC.

  6. Click OK.


Controlling Background Tracing

The DTC provides a dialog box in which you can control background tracing. This dialog box is for background tracing only; you cannot use it to control the tracing of individual transactions or to control trace settings remotely.

To control background trace settings

  1. In the console tree of the Component Services administrative tool, right-click My Computer and then click Properties.

  2. Click the MSDTC tab.

  3. Click the Tracing Options button. This displays the Tracing Options dialog box.

The Tracing Options dialog box allows you to set the output and logging options. For more information, see the following sections on setting output options and setting logging options.

Setting Output Options

By default, the Trace Aborted Transactions and Trace Long-Lived Transactions options are enabled.

Note If either the higher-level Trace Transactions check box or the highest-level Trace Output check box is unchecked, the default tracing options become disabled.

To set the type of tracing you want to enable or disable

  1. Display the Tracing Options dialog box as described in the preceding procedure.

  2. In the Output Options panel, check or uncheck the appropriate check box. The choices are as follows:
    • Trace All Transactions

    • Trace Aborted Transactions

    • Trace Long-Lived Transactions
  3. Click OK.

Setting Logging Options

Logging options allow you to control the log file for the trace data.

To set the logging options

  1. Display the Tracing Options dialog box as described at the beginning of this page.

  2. In the Logging Options panel, select from the following:
    • New Session Click this button to start a new tracing session. When a new session starts up, the DTC backs up the existing log file, if one exists.

    • Stop Session Click this button to stop a tracing session that is in progress. Stopping a trace session causes the trace log file to become unlocked so that you can delete the file if necessary.

    • Flush Data Click this button to move all of the data from its memory buffers to the log file on disk. You should click this button prior to viewing trace data to ensure that all trace data in memory is sent to disk; otherwise, some trace data might not appear in the log file when you view it. Clicking this button might affect system performance. When the tracing session is stopped, this button is disabled.

    • Max. Num. Of Memory Buffers (size PageSize) Change this value if you want to change the maximum number of memory buffers allowed. The default maximum value is 25. If increasing this limit is recommended, the DTC writes a message to the event viewer. This memory is taken out of the non-pageable buffer. Therefore, if the amount of memory available in the non-pageable buffer is insufficient, you might not be able to set a high number for this value. In this case, the DTC displays a message to that effect. If this happens, click OK.
  3. Click OK.


Troubleshooting DTC Problems

One of the most frequently reported errors for the DTC is the "Failed to enlist" error. If this error occurs when your transactional component is accessing a Microsoft® SQL Server™ database, please see the following topics to determine the possible cause:

  • Verify That the DTC Has Started

  • Check Transaction Time-Out


Verify That the DTC Has Started

Make certain that the DTC is started on the system on which your components running in Component Services are deployed.

If your application is accessing a Microsoft SQL Server database on a remote system, ensure that the DTC is started on that system also. This is frequently the cause of the "Failed to enlist" error.

For more information on starting and stopping the DTC, see Starting and Stopping the DTC.


Check Transaction Time-Out

If you see a "Failed to enlist" error, the component's transaction might have aborted due to transaction time-out before the database enlistment completed. You can increase the transaction time-out value through the Component Services administrative tool.

To check the transaction time-out period

  1. In the console tree of the Component Services administrative tool, right-click the computer where the transaction was initiated and then click Properties.

  2. In the computer properties dialog box, click the Options tab.

  3. Under Transaction Timeout, in the Transaction timeout (seconds) text box, enter the value for the time-out period in seconds.

    Note You can specify any value between 0 and 3600 seconds (1 hour). A value of 0 seconds prevents transactions from ever timing out. You might need to experiment with different values to obtain the right time-out value for your system.

  4. Click Apply.

  5. Click the MSDTC tab, and under Service Control Status for DTC, click the Stop button to stop the DTC.

  6. Click the Start button to apply the new transaction time-out setting.

  7. Click OK.


Configuring the DTC Logon Account

  25. You can configure the default using account under which the DTC will run.

Caution Do not change the default user account by using the Distributed Transaction Coordinator Properties page within the Local Services administrative tool. Changing the default user account through the Distributed Transaction Coordinator Properties page can cause the DTC to fail to start because necessary changes have not been made to the COM+ catalog. It also poses a security risk because it can allow the DTC to run under an invalid account.

To change the default user account

  1. In the console tree of the Component Services administrative tool, in the Computers folder, right-click the local computer and then click Properties.

  2. Click the MSDTC tab.

  3. Click the Security Configuration button.

  4. Under DTC Logon Account on the Security Configuration page, enter the user name, password, and confirmed password. If you don't know the fully qualified user name, click Browse to locate it.

  5. Click OK to return to the computer properties window.

  6. Click OK.