Considerations for server-side Automation of Office

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:

Open XML SDK Documentation

How to: Manipulate Office Open XML Formats Documents

Manipulating Word 2007 Files with the Open XML Object Model (Part 1 of 3)

Manipulating Word 2007 Files with the Open XML Object Model (Part 2 of 3)

Manipulating Word 2007 Files with the Open XML Object Model (Part 3 of 3)

Manipulating Excel 2007 and PowerPoint 2007 Files with the Open XML Object Model (Part 1 of 2)

Manipulating Excel 2007 and PowerPoint 2007 Files with the Open XML Object Model (Part 2 of 2)

Building Server-Side Document Generation Solutions Using the Open XML Object Model (Part 1 of 2)

Building Server-Side Document Generation Solutions Using the Open XML Object Model (Part 2 of 2)

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:

Office 2007 File Format MIME Types for HTTP Content Streaming

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:

198703 How to automate Excel from a client-side VBScript

How To Query and Update Excel Data Using ADO From ASP

286023 How to use a VB ActiveX component for Word automation from Internet Explorer
 

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.

If you want to build your own solution that edits the Office 97, Office 2000, Office XP, and Office 2003 binary file formats directly, you can obtain the file format specifications for free under the terms of the Microsoft Open Specification Promise (OSP). No technical support is available for the documentation or for the products that you create, but documentation is available. 

Server-side solutions also may want to allow users to upload files, and then have the server render the files for viewing on the Web or on other mediums. Microsoft is currently working to offer such features, and provides an early version of this capability in Microsoft Excel Services.

Excel Services is a new server technology that is included in Microsoft Office SharePoint Server 2007 and that enables you to load, calculate, and display Excel workbooks on Office SharePoint Server 2007. For more information about Excel Services, visit the following Microsoft Developer Network (MSDN) Web sites:

Excel Services Overview

Walkthrough: Developing a Custom Application Using Excel Web Services

Creating Business Applications by Using Excel Services and Office Open XML Formats Word Automation Services is a new service application in SharePoint Server 2010. Word Automation Services provides unattended, server-side conversion of documents into formats that are supported by the Microsoft Word client application.

Word Automation Services Overview

Introducing Word Automation Services You need to evaluate which of the options that this article describes suits your needs, and how best to deploy your solution. The information that this article provides is not guaranteed to resolve all issues for all clients. You are encouraged to test your solution thoroughly before you deploy the solution.