Terminal Server 4.0 中的 DCOM 功能是常规 Windows NT Server 4.0 DCOM 功能的一个子集。基于这一点，针对常规 Windows NT Server 4.0 环境编写并能在其上正常运行的一些应用程式，在终端伺服器上可能无法正常运行。本文的目的就是说明那些使用 DCOM 功能的应用程式会出现什幺样的行为。

以下 DCOM 功能可以在终端伺服器上获得全面支持：

客户端行为（作为终端伺服器的任一用户运行并通过 DCOM 调用其它机器的进程）没有变化。

如果没有直接或间接涉及 COM 激活过程（CoGetClassObject、CoCreateInstanceEx、由于远程调用而启动的进程等），则伺服器端的行为也没有变化。例如，如果指向终端伺服器机器上 COM 对象的接口指针被调整并传递给另一机器上的客户代码，则伺服器端行为就不涉及激活过程。这种行为的发生通常是作为 DCOM 方法调用的输出参数，但也可能存在其它方式。那种情况下，对终端伺服器（现在已作为 DCOM 伺服器）的回调将照常进行（包括通常的安全限制）。一个间接激活的例子是，对一个解析到终端伺服器机器并导致尝试在该机器上发生直接激活的档案标记的绑定。

在作为远程客户的伺服器运行时，终端伺服器系统在所支持的 DCOM 激活/进程启动模式方面会有所限制。对于任一给定的 ClassID 或 AppID，Windows NT 的 DCOM 通常支持四种激活/启动模式。

作为激活方运行（默认）：在终端伺服器中，本地进程由客户会话启动。

作为指定/命名用户运行：在终端伺服器中，本地进程始终由会话 0（控制台）启动。

作为 Win32 和 Windows NT 服务运行：在终端伺服器中，服务由会话 0（控制台）启动。

作为互动用户运行：不能用在终端伺服器中。

对于终端伺服器，只有模式 1（“作为激活方运行“）才受完全支持。模式 2 和 3（“作为指定/命名用户运行”和“作为 Win32 和 Windows NT 服务运行”）在终端伺服器系统上运行时会出现不同的行为，因此 Microsoft 不推荐或支持这样做。第四种模式（“作为互动用户运行”），在终端伺服器上根本不能运行。

DCOM 与 Windows 2000 终端服务

Microsoft 的目标是确保上述问题在 Windows 2000 中能够解决。以下内容是对 Microsoft Windows® 2000 终端服务下激活模式及其工作机制的简要描述：

作为激活方运行：

本地激活

伺服器在激活方所属的同一会话中被激活。这种行为在无论终端服务是否启用的情况下都完全相同。

远程激活：

启用终端服务后的激活规则与不启用时一样。然而，进程将在会话 ID 为 0 的视窗站中启动，而不是在用户对应的会话中启动。 这是为了保护远程调用的激活行为。为了说明这一行为方式的原因，不妨假设由对应于 Windows 2000 Server（已启用终端服务）上用户的会话启动激活过程的情况。如果用户注销，所有的视窗站及其进程就被杀死。如果用户是从伺服器上的多个客户登录的，而又决定从一台客户机上退出，则用户其它会话的客户进程将无法看到它们的激活过程。因此，其它会话将失败。基于这一原因，所有进程都将在会话 0 的视窗站中启动。因为会话 0 永远不会被删除，远程激活过程就能够继续正常进行。

作为命名/指定用户运行：

应用程式通过注册表中的 AppID 被配置为作为指定用户运行。本地和远程激活的行为相同。

当启用了终端服务时，进程将在会话 0 的一个新视窗站中启动。在有多个用户使用伺服器的情况下，后续请求将获得已有的同一个类对象。 呼叫方的 SID 或 LUID 对此没有影响。在单个用户使用伺服器的情况下，新的激活请求始终获得一个新的视窗站。即使同一用户登录到互动式桌面，激活过程也不会共享互动视窗站。

作为 Win32 和 Windows NT 服务运行：

应用程式通过 AppID 集被配置为作为服务运行进程。

当启用了终端服务后，服务从本质上讲仍是全局的，不会在某一特定会话中启动。根据服务配置不同，它们要幺在会话 0 的服务桌面上启动，要幺在会话 0 的互动桌面上启动。

作为互动用户运行：

应用程式被配置为在互动用户的安全环境下运行。

如前所述，Windows NT Server 4.0，Terminal Server Edition 不支持这类伺服器的远程激活，它只支持会话到会话的本地激活。在启用终端服务的状态下作为互动用户启动进程有两种方式，正处于研究之中。一种在当前会话之外的另一会话中激活进程的方式是使用会话“标誌”。另一种可能的方式是使用呼叫方的安全凭据启动进程。Windows 2000 正式推出时会提供更详细的信息