Developers can use Automation in Microsoft Office to build custom solutions that use the capabilities and the features that are built into the Office product. Although such programmatic development can be implemented on a client system with relative ease, a number of complications can occur if Automation takes place from server-side code such as Microsoft Active Server Pages (ASP), ASP.NET, DCOM, or a Windows NT service.
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.
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
- 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
- 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
- The CreateObject function and the CoCreateInstance function
return one of the following run-time error messages and cannot be started for
Run-time error '429': ActiveX component
cannot create object
Run-time error '70': Permission denied
Server execution failed
E_ACCESSDENIED (0x80070005): Access denied
- When you open an Office document, you receive one of the
following error messages.
Run-time error '5981' (0x800A175D): Could
not open macro storage
Run-time error '1004': Method '~' of object
- 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
- 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. To obtain a copy of the specification,
visit the following Web site:
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:
information about using Open XML from the .NET 3.0 Framework and for an
example, click the following article numbers to view the articles in the
Microsoft Knowledge Base:
How to use components of the .NET Framework 3.0 to create and then to stream an Office Word 2007 document and an Office Excel 2007 workbook to a client computer
How to use the Office XML file format and the packaging components from the .NET Framework 3.0 to create a simple Excel 2007 workbook or a simple Word 2007 document
Users who are running earlier versions of Office
(such as Office 2000, Office XP, and Office 2003) can view and edit Open XML
files if the users install the free compatibility pack download from the
Microsoft Web site. To download and install the compatibility pack, visit the
following Microsoft Web site:
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:
How to use ASP to generate a Rich Text Format (RTF) document to stream to Microsoft Word
How to automate Excel from a client-side VBScript
How to display ASP results using Excel in IE with MIME types
How to format cell data when you are creating an Excel file with an Active Server Pages page
ExcelADO demonstrates how to use ADO to read and write data in Excel workbooks
How to use a VB ActiveX component for Word automation from Internet Explorer
How to use ASP to build spreadsheet XML for client-side display
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. For more information, visit the following Web site:
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
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:
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.
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.