This article discusses the complications that developers may face. The article also offers alternatives to Automation that can speed performance. Developers should be aware, however, that the suggestions that this article provides are for informational purposes only. Microsoft does not recommend or support server-side Automation of Office.
Note In this context, the Microsoft 2007 Office System Driver and the 2010 Access Database Engine are considered Microsoft Office components. The term "server-side" also applies to code that is running on a Windows workstation, if the code is running from a Windows workstation other than the interactive station of the user who is logged on. For example, code that is started by Task Scheduler under the SYSTEM account runs in the same environment as "server-side" ASP code or as DCOM code. Therefore, many of the issues that this article describes may occur. For more information about Windows workstations and about COM, see the "More Information" section and the "References" section.
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 OfficeDevelopers 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.
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 1Run-time error '429': ActiveX component cannot create objectMessage 2Run-time error '70': Permission deniedMessage 3CO_E_SERVER_EXEC_FAILURE (0x80080005): Server execution failedMessage 4E_ACCESSDENIED (0x80070005): Access denied
- When you open an Office document, you receive one of the following error messages.
Message 1Run-time error '5981' (0x800A175D): Could not open macro storageMessage 2Run-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.
Alternatives to server-side AutomationMicrosoft 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. To obtain a copy of the specification, visit the following Web site:
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:
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: