Considerations for server-side Automation of Office

All current versions of Microsoft Office were designed, tested, and configured to run as end-user products on a client workstation. They assume an interactive desktop and user profile. They do not provide the level of reentrancy or security that is necessary to meet the needs of server-side components that are designed to run unattended.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.

Problems using server-side Automation of Office

Developers who try to use Office in a server-side solution need to be aware of five major areas in which Office behaves differently than anticipated because of the environment. If your code is to run successfully, you must address these issues and minimize their effects as much as possible. Consider these issues carefully when you build your application. One solution cannot address all the issues. Different designs require you to prioritize the elements differently.

• User Identity: Office applications assume a user identity when the applications are run, even when Automation starts the applications. The applications try to initialize toolbars, menus, options, printers, and some add-ins based on settings in the user registry hive for the user who launches the application. Many services run under accounts that have no user profiles (such as the SYSTEM account or the IWAM_[servername] accounts). Therefore, Office may not initialize correctly on startup. In this situation, Office returns an error on the CreateObject function or the CoCreateInstance function. Even if the Office application can be started, other functions may not work correctly if no user profile exists.
• Interactivity with the desktop: Office applications assume that they are being run under an interactive desktop. In some circumstances, applications may need to be made visible for certain Automation functions to work correctly. If an unexpected error occurs, or if an unspecified parameter is needed to complete a function, Office is designed to prompt the user with a modal dialog box that asks the user what the user wants to do. A modal dialog box on a non-interactive desktop cannot be dismissed. Therefore, that thread stops responding (hangs) indefinitely. Although certain coding practices can help reduce the likelihood of this issue, these practices cannot prevent the issue entirely. This fact alone makes running Office Applications from a server-side environment risky and unsupported.
• Reentrancy and scalability: Server-side components need to be highly reentrant, multi-threaded COM components that have minimum overhead and high throughput for multiple clients. Office applications are in almost all respects the exact opposite. Office applications are non-reentrant, STA-based Automation servers that are designed to provide diverse but resource-intensive functionality for a single client. The applications offer little scalability as a server-side solution. Additionally, the applications have fixed limits to important elements, such as memory. These cannot be changed through configuration. More importantly, the applications use global resources such as memory mapped files, global add-ins or templates, and shared Automation servers. This can limit the number of instances that can run concurrently and can lead to race conditions if the applications are configured in a multi-client environment. Developers who plan to run more than one instance of any Office application at the same time need to consider "pooling" or serializing access to the Office application to avoid potential deadlocks or data corruption.
• Resiliency and stability: Office 2000, Office XP, Office 2003, and Office 2007 use Microsoft Windows Installer (MSI) technology to make installation and self-repair easier for an end user. MSI introduces the concept of "install on first use." This allows features to be dynamically installed or configured at run time for the system, or more often for a particular user. In a server-side environment, this both slows down performance and increases the likelihood that a dialog box may appear that asks the user to approve the installation or to provide an installation disk. Although this is designed to increase the resiliency of Office as an end-user product, Office's implementation of MSI capabilities is counterproductive in a server-side environment. Furthermore, the stability of Office in general cannot be assured when Office is run server-side because it has not been designed or tested for this type of use. Using Office as a service component on a network server may reduce the stability of that computer, and therefore may reduce the stability of your whole network.
• Server-side security: Office applications were never intended for server-side use. Therefore, Office applications do not take into consideration the security problems that distributed components face. Office does not authenticate incoming requests. Office also does not protect you from unintentionally running macros, or from starting another server that might run macros, from your server-side code. Do not open files that are uploaded to the server from an anonymous Web site. Based on the security settings that were last set, the server can run macros under an Administrator or System context with full privileges and can therefore compromise your network. Additionally, Office uses many client-side components (such as Simple MAPI, WinInet, and MSDAIPP) that can cache client authentication information to speed processing. If Office is being automated server-side, one instance may service more than one client. If authentication information has been cached for that session, one client can use the cached credentials of another client. Therefore, the client may gain non-granted access permissions by impersonating other users.

Besides the technical problems, you must also consider licensing issues. Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office. Using server-side Automation to provide Office functionality to unlicensed workstations is not covered by the End User License Agreement (EULA).

In addition to these issues, one of the following common errors may occur when you try to automate Office server-side:

• The CreateObject function and the CoCreateInstance function return one of the following run-time error messages and cannot be started for Automation.
   
  Message 1
  Run-time error '429': ActiveX component cannot create object
  Message 2
  Run-time error '70': Permission denied
  Message 3
  CO_E_SERVER_EXEC_FAILURE (0x80080005): Server execution failed
  Message 4
  E_ACCESSDENIED (0x80070005): Access denied
• When you open an Office document, you receive one of the following error messages.
   
  Message 1
  Run-time error '5981' (0x800A175D): Could not open macro storage
  Message 2
  Run-time error '1004': Method '~' of object '~' failed
• The CreateObject function and the CoCreateInstance function stop responding and never finish, or take a long time to return. On some servers, the creation is fast, but 1004 errors appear in the Windows event log that indicate that the application was stopped.
• Certain functions fail unexpectedly or stop responding indefinitely because of a user alert or other dialog box that requires user attention.
• Running multiple requests or stress testing causes the code to fail, stop responding, or crash on creation or termination of an Office application. When this occurs, either the process is left running in memory and cannot be terminated, or all instances of the application that is being automated fail from that point on.

Other problems or messages may appear in addition to those listed here, but these problems typically occur as a result of the five main issues that are listed earlier in this article. 

Alternatives to server-side Automation

Microsoft strongly recommends that developers find alternatives to Automation of Office if they need to develop server-side solutions. Because of the limitations to Office's design, changes to Office configuration are not enough to resolve all issues. Microsoft strongly recommends a number of alternatives that do not require Office to be installed server-side, and that can perform most common tasks more efficiently and more quickly than Automation. Before you involve Office as a server-side component in your project, consider alternatives.

Most server-side Automation tasks involve document creation or editing. Office 2007 supports new Open XML file formats that let developers create, edit, read, and transform file content on the server side. These file formats use the System.IO.Package.IO namespace in the Microsoft .NET 3.x Framework to edit Office files without using the Office client applications themselves. This is the recommended and supported method for handling changes to Office files from a service.

The Open XML file formats are a public standard. 

Microsoft provides an SDK for manipulating Open XML file formats from the .NET 3.x Framework. For more information about the SDK and about how to use the SDK to create or edit Open XML files, visit the following Microsoft Developer Network (MSDN) Web sites:

When you stream Open XML files from ASP or from ASP.NET, you must provide the correct Multipurpose Internet Mail Extension (MIME) type for the content that you stream. For a listing of the MIME types for Office 2007 files, visit the following Web site:

If you are targeting pre-Office 2007 clients only, and you do not want to require the use of Open XML in the solution, you can use other non-binary Office file formats, such as HTML, XML, and RTF. You can then stream these files to a client by using a MIME type so that the resulting text appears in Office. The document can be edited, saved, and even returned to the server by using ASP on the server.

For more information about any of these topics, and for examples that show how to implement them, click the following article numbers to view the articles in the Microsoft Knowledge Base:

If your business requires the server-side creation of the Office 97, Office 2000, Office XP, and Office 2003 binary file formats, third-party vendors offer components that can help you. Microsoft does not provide any such components, so you will need to either build a solution yourself or purchase one from a third-party vendor. Many different third-party products are available. You should investigate each solution to best match the vendor to your business needs.