How to configure Office applications to run under a specific user account
How to configure Office applications to run under a specific user account This article was previously published under Q288367 SUMMARY We do not recommend or support automation to a Microsoft Office application from an unattended user account. For additional information on why Microsoft does not recommend automation under this context, click the following article number to view the article in the Microsoft Knowledge Base:257757 Considerations for server-side automation of Office If there is no choice but to automate Office from an unattended user account, the following steps can be used to configure the computer to run the Office application as a specific user, giving the application a fixed identity when it is started for Automation. MORE INFORMATION Caution Automation of any Office application from an unattended, non-interactive user account is risky and unstable. A single error in code or configuration can result in a dialog box that can cause the client process to stop responding (hang), that can corrupt data, or that can even crash the calling process (which could bring down your Web server if the client is ASP). Warning Office was not designed, and is not safe, for unattended execution on a server. Developers who use Office in this manner do so at their own risk. Regardless, it may be absolutely required to use Office in this manner. In these cases, special configuration must be done to avoid errors on Office startup. The steps in this article demonstrate how to configure Office to run as a specific user account when it is started for Automation. When you automate under a specific user account, you should be aware of the following problems: Any process that creates an Automation instance of the configured Office application creates the instance under the specific user account, allowing it to run with that user's security credentials. Setting the Distributed Componenet Object Model (DCOM) settings to run as a specific user is global to the system. This setting affects all users and programs that automate the Office application on the system. Terminal Server clients may not be able to use Office appropriately. You should not use this setting and the steps in this article on an application Terminal Server. Component Object Model (COM) creates a unique WinStation for the new instance of the Office application. Any dialog boxes or warnings that may display do not appear on the interactive desktop. If you set the Visible flag for an application, the interactive user will not see that application. For more information about COM and WinStations, see the "References" section. When COM loads a server to run as a specific user account, the registry hive for that user is not loaded. Because the hive is not loaded for that user, the system .DEFAULT hive is used. Because Office has not been run under an account with this hive, you may receive dialog boxes that prompt you for input or the Office CD-ROMs to complete installation. The dialog boxes are not visible on the interactive desktop, so the application appears to stop responding (hang). The dialog boxes may time out and allow the process to continue, but after a noticeable delay in running the program. To work around this situation, install an NT service that runs under the same user account that is set for the DCOM setting. The NT Service Control Manager (SCM) loads the hive for that user when the service starts. Because the changes in DCOM are global, configuring Office in this manner can have negative side effects for other clients on the system that use Office. It is possible that another client application, or Terminal Server clients, will not be able to use the Office application after the settings are made. Consider carefully what impact this has to your server before you make any changes to the DCOM configuration settings. If the problems listed here are too great for your design, or cause other unidentified problems, it is possible to configure Office differently and still allow it to start from an unattended process or service. For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:288366 How To Configure Office Applications to Run Under the Interactive User Account 288368 How To Configure Office Applications for Automation from a COM+/MTS Package Configuring Office as a Specific User To set up an Office Automation server under a specific user account, follow these steps: Log on to the computer as the Administrator and create a new user account that will automate Office. In our example, this account is named OfficeAutomationUser. Create a password for this user account, and select Never expire so that the password does not have to be changed. Add the OfficeAutomationUser account to the Administrators group. Log in to the computer as OfficeAutomationUser and install (or reinstall) Office using a complete install. For system robustness, it is recommended that you copy the contents of the Office CD-ROM to a local drive and install Office from this location. Start the Office application that you intend to automate. This forces the application to register itself. After the application is running, press ALT+F11 to load the Microsoft Visual Basic for Applications (VBA) editor. This forces VBA to initialize itself. Close the applications, including VBA. Click Start, click Run, and then type `<kbd>``DCOMCNFG</kbd>`. Select the application that you want to automate. The application names are listed below:Microsoft Access 97/2002 - Microsoft Access Database Microsoft Access 2003 - Microsoft Office Access Application Microsoft Excel 97/2000/2002/2003 - Microsoft Excel Application Microsoft Word 97 - Microsoft Word Basic Microsoft Word 2000/2002/2003 - Microsoft Word Document Click Properties to open the property dialog box for this application. ...