Using DCOM with Windows NT Server 4.0, Terminal Server Edition and Terminal Services in Windows 2000

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

Updated : August 2, 2001

On This Page

Abstract
DCOM Applications and Windows NT Server 4.0, Terminal Server Edition
DCOM Activation Modes and Terminal Server
DCOM and Terminal Services for Windows 2000
For more Information

Abstract

The following is a discussion of the Distributed Component Object Model (DCOM) and its support and use on Microsoft® Windows NT® Server 4.0, Terminal Server Edition and Windows® 2000. To have a complete understanding of the interaction between Terminal Server and DCOM, you should first read the white papers on Terminal Server Architecture, Optimizing Applications for Terminal Server, and DCOM.

For more information on DCOM: Microsoft TechNet or https://www.microsoft.com/com/tech/dcom.asp

For more Information on Terminal Server Architecture: Microsoft TechNet or https://www.microsoft.com/ntserver/ProductInfo/terminal/Dcom.asp

For more information on Optimizing Applications for Terminal Server: Microsoft TechNet or

https://www.microsoft.com/windows2000/techinfo/planning/terminal/tsappdev.asp

DCOM Applications and Windows NT Server 4.0, Terminal Server Edition

The following is a discussion of the Distributed Component Object Model (DCOM) and its support and use on Windows NT Server 4.0, Terminal Server Edition (Terminal Server). To have a complete understanding of the interaction between Terminal Server and DCOM, you should first read the white papers on Terminal Server Architecture, Optimizing Applications for Terminal Server, and DCOM.

Distributed Component Object Model (DCOM)

DCOM is a protocol that enables software components to communicate directly over a network in a reliable, secure, and efficient manner. Previously called "Network OLE," DCOM is designed for use across multiple network transports, including Internet protocols such as HTTP. DCOM is based on the Open Software Foundation's DCE-RPC spec and will work with both Java language applets and ActiveX® components through its use of the Component Object Model (COM).

DCOM functionality in Terminal Server 4.0 is a subset of DCOM functionality on a regular Windows NT Server 4.0. For this reason, some applications which are written for and function properly in a regular Windows NT Server 4.0 environment may not function properly when running on a Terminal Server. The purpose of this paper is to explain what behavior can be expected from applications that use DCOM functionality.

The following DCOM functionality is fully supported on Terminal Server:

  • Client-side behavior (any process running as any user on a Terminal Server and calling other machines over DCOM) is unchanged.

  • Server-side behavior is also unchanged when COM activation (CoGetClassObject, CoCreateInstanceEx, process launching due to remote calls, etc.) is not directly or indirectly involved. For example, server-side behavior with no activation occurs when the interface pointer to a COM object on the Terminal Server-based machine is marshaled and handed to client code on another machine. This typically occurs as an out parameter of a DCOM method call, but other means are possible. In that situation, callbacks to the Terminal Server, now acting as a DCOM server, work as usual (including the usual security restrictions). An example of indirect activation would be binding a file moniker that resolves to a Terminal Server-based machine and results in an attempted direct activation on that machine.

DCOM Activation Modes and Terminal Server

A Terminal Server-based system is limited, however, in the DCOM activation/process launching modes that it supports when functioning as a server for remote clients. DCOM on Windows NT normally supports four activation/launching modes for any given ClassID or AppID:

The following modes exist in DCOM:

  1. Run as activator (default): In Terminal Server, the local process is started in the client's session.

  2. Run as specified/named user: In Terminal Server, the local process is always started in the session 0 (Console).

  3. Run as Win32 and Windows NT -based service: In Terminal Server, the service is started in the session 0 (Console).

  4. Run as Interactive user: Does not work in Terminal Server.

For Terminal Server, only mode 1, "Run as activator" is fully supported. Modes 2 and 3, "Run as specified/named user" and "Run as Win32 and Windows NT-based service" will result in different behavior on a Terminal Server system, and are therefore not recommended or supported by Microsoft. The fourth mode, "Run as Interactive user," will not function at all on Terminal Server.

DCOM and Terminal Services for Windows 2000

Microsoft's goal is to ensure that these issues are addressed in Windows® 2000. Under Terminal Services for Microsoft Windows 2000, the following is a brief interpretation of the activation modes and how they will work:

Run as activator:

Local Activation:

The server is activated on the same session as the activator. This behavior will be the same whether Terminal Services are enabled or not.

Remote Activation:

When Terminal Services are enabled, the activation rules will be the same as when they are not. However, the process is launched in a Window Station of Session ID 0, and not on a session corresponding to the user. This is to preserve the activation behavior for remote calls. To understand why this is so, consider if activation were started on a session corresponding to the user running on a Windows 2000 Server with Terminal Services enabled. If the user logged off, all the Window Stations and hence processes on that Window Station would be killed. If the user were logged on from multiple clients on server , and the user decided to log off from one of the client machines, the client processes from the user's other sessions would be unable to see their activations. As a result, the other sessions would fail. For this reason, all processes are launched in a Windows Station of Session 0. Since Session 0 can never be deleted, remote activations will continue to behave properly.

Run as Named/specified user:

The application is configured with its AppID in the registry configured to run as a specified user. Local and remote activation behave the same.

When Terminal Services are enabled, the process is started on a new Window Station on Session 0. In the case of multiple use servers, the subsequent requests get the same existing class object. It does not matter what the SID or LUID of the caller is. In the case of single-use servers, a new activation request always gets a new Window Station. Activation is never shared with the interactive Window station, even if the same user is logged on to the interactive desktop.

Run as Win32 and Windows NT –based service:

The application is configured with the AppID set to run the process as a service

When Terminal Services are enabled, services are still global in nature, and services are not started on a particular session. They are always started on either the service desktop on Session 0 or on the interactive desktop on Session 0, depending on the service configuration.

Run as interactive user:

The application is configured to run in the security context of the interactive user.

As mentioned before, remote activation of such a server is not supported on Windows NT Server 4.0, Terminal Server Edition. Only local activation from session to session is supported. There are two means being investigated for starting a process as interactive user when running with Terminal Services enabled. One means of activating a process in a session other than the current session is by using a session moniker. Another possible means is to launch the process using the security credentials of the caller. More information will be made available when Windows 2000 ships.

For more Information

The information provided here is not final and is subject to change. More information will be forthcoming prior to the release of Windows 2000 Server.

Check out Microsoft TechNet or the following Web sites for the latest information on Windows 2000, Terminal Server and DCOM:

https://www.microsoft.com/windowsserver2003/default.mspx

https://www,microsoft.com/ntserver/terminalserver

https://www.microsoft.com/com/tech/dcom.asp