Microsoft Office 所有当前版本的设计、测试和配置都是为在客户端工作站上作为最终用户产品运行而完成的。它们假定存在一个交互式桌面和用户配置文件，而且不提供满足为以无人参与方式运行而设计的服务器端组件的需要所必需的重入或安全性级别。

Microsoft 目前建议不要从任何无人参与的、非交互式客户端应用程序或组件（包括 ASP、DCOM 和 NT Service）中进行 Microsoft Office 应用程序的“自动化”，也不为此提供支持，因为 Office 在这种环境中运行时可能会出现不稳定的现象并且/或者会死锁。

如果您要构建在服务器端上下文中运行的解决方案，应尽可能尝试使用对于以无人参与方式执行很安全的组件，或找到至少允许一部分代码在客户端运行的备选方案。如果您选择从服务器端解决方案中运行 Office 应用程序，将发现这样会缺少成功运行所必需的许多功能，而且整体解决方案的稳定性会有风险。

使用服务器端 Office 自动化时出现的问题

尝试在服务器端解决方案中使用 Office 的开发人员需要了解 Office 的表现因环境而与预期不同的五个主要问题。要成功运行您的代码，就需要解决这些问题，而且需要尽可能减少它们的影响。您在构建应用程序时，要仔细考虑这些问题，因为没有任何一种解决方案能解决所有这些问题，不同的设计要求您优先考虑不同的元素。

用户身份：Office 应用程序在运行时会假定存在一个用户身份，即使在它们由“自动化”启动时也是如此。它们尝试根据用户注册表配置单元中的设置为启动应用程序的用户初始化工具栏、菜单、选项、打印机和一些加载项。许多服务会在没有用户配置文件的帐户（例如，SYSTEM 或 IWAM_[servername] 帐户）下运行，因此，Office 可能无法在启动时进行正确的初始化，进而返回一个有关“CreateObject”或“CoCreateInstance”的错误。即使能够在没有用户配置文件的情况下启动 Office 应用程序，其他功能也可能无法正常工作。如果您计划从某个服务进行“Office 自动化”，需要配置您的代码或 Office，以便它使用某个已加载的用户配置文件来运行。

与桌面的交互性：Office 应用程序假定它们在某个交互式桌面下运行，在有些情况下，可能需要让用户看到它们以便某些“自动化”功能正常运行。如果发生意外错误，或者需要一个未指定的参数才能完成某项功能，根据设计，Office 会用一个模式对话框提示用户，询问用户要进行什么操作。非交互式桌面上的模式对话框是无法取消的，这就导致该线程无限期地停止响应（挂起）。虽然有些代码编写的经验做法有助于减少发生这种情况的可能性，但还是无法做到完全防止。正是这种情况使得从服务器端环境运行 Office 应用程序带有风险，而且不受支持。

重入和可伸缩性：服务器端组件需要是具有较高可重入性的多线程 COM 组件，这些组件在有多个客户端时开销最少而吞吐量较高。Office 应用程序在几乎所有方面都正好相反。它们是非重入的、基于 STA 的“自动化”服务器，是为给一个客户端提供多种多样但占用资源较多的功能而设计的。它们作为服务器端解决方案提供不了多少可伸缩性，而且对于重要元素有固定的限制，例如，对于内存，无法通过配置进行更改。更重要的是，它们要使用全局性资源（例如，映射到内存的文件、全局加载项或模板，以及共享的“自动化”服务器），这样可能会限制能够并发运行的实例的数量，而且，如果它们是在多客户端环境中配置的，还可能导致争用的情况。开发人员如果计划同时运行多个任意“Office 应用程序”的实例，就需要考虑“后台处理”或序列化对“Office 应用程序”的访问，以避免可能出现的死锁或数据损坏。

复原性和稳定性：Office 2000、Office XP 和 Office 2003 使用 Microsoft Windows 安装程序 (MSI) 技术，以使最终用户在进行安装和自行修复时更加容易。MSI 推出了“首次使用时安装”的概念，允许在运行时动态安装或配置功能（针对系统，或者更多地针对特定用户）。在服务器端环境中，这会既降低性能，又增加出现要求用户同意安装或提供相应安装盘的对话框的可能性。虽然此设计旨在增强 Office 作为最终用户产品的复原性，但 Office 实现 MSI 功能在服务器端环境中还是会对生产力带来不利影响。此外，在服务器端运行时，Office 的稳定性通常无法得到保障，因为它尚未为这样使用而进行设计或测试。在网络服务器上使用 Office 作为服务组件可能会降低这台计算机的稳定性，进而降低您的网络作为一个整体的稳定性。如果您计划在服务器端自动运行 Office，请尝试将该程序隔离到一台专用计算机上，该计算机不能影响重要功能，而且在需要时可以重新启动。

服务器端安全性：Office 应用程序从来都不是为在服务器端使用而准备的，因此，请不要考虑分布式组件所面临的安全性问题。Office 不对传入的请求进行身份验证，而且不会保护您免受无意中从服务器端代码中运行宏或启动另一台可能会运行宏的服务器的损害。不要打开从匿名网站上载到服务器上的文件！基于上一次设置的安全性设置，服务器可能会在具有全部特权的 Administrator 或 System 上下文下运行宏，并危及您的网络的安全！另外，Office 使用很多客户端组件（例如，Simple MAPI、WinInet、MSDAIPP），它们会缓存客户端身份验证信息以加快处理速度。如果在服务器端进行 Office 自动化，则一个实例可能为多个客户端提供服务，而且由于已经为该会话缓存了身份验证信息，就有可能出现这样的情况：一个客户端可以使用另一个客户端的缓存凭据，从而通过模拟其他用户获得未经授予的访问权限。

除了要考虑技术问题以外，您还必须考虑这样一种设计在许可方面的可行性。目前的许可原则禁止在服务器上使用“Office 应用程序”为客户端请求提供服务，除非那些客户端自己具有 Office 的许可副本。《最终用户许可协议》(EULA) 没有涉及使用服务器端“自动化”向未经许可的工作站提供 Office 功能的情况。