How to configure Office applications for automation from a COM+/MTS package (288368)


The information in this article applies to:

  • Microsoft Office Access 2003
  • Microsoft Access 2002
  • Microsoft Access 2000
  • Microsoft Access 97
  • Microsoft Office Excel 2003
  • Microsoft Excel 2002
  • Microsoft Excel 2000
  • Microsoft Excel 97 for Windows
  • Microsoft Office Word 2003
  • Microsoft Word 2002
  • Microsoft Word 2000
  • Microsoft Word 97 for Windows
This article was previously published under Q288368

SUMMARY

Microsoft does not recommend or support Automation to a Microsoft Office application from an unattended user account.

For more information about 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, use the steps in this article to configure a package that runs as a specific user, giving the Office 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 can 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 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 the interactive user account when it is started for Automation.

When you automate from within a COM+/MTS Package, you should be aware of the following problems:
  • The DCOM Identity setting for the Office application should be set to the launching user. This allows the Office application to run under the identity that is configured in the package. Other applications on the system that automate Office should be unaffected by this change. Those Office applications still run as the identity of the launching user.
  • This solution works only if you have a dynamic-link library (DLL) that is used to automate Office, or if you are automating from a Web page and have the application set to run in Isolated mode.
  • 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 CDs 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.
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 more information, click the following article number to view the article in the Microsoft Knowledge Base:

288366 How to configure Office applications to run under the interactive user account

288367 How to configure Office applications to run under a specific user account

Configuring Office as the launching user

To set up an Office Automation server as the launching 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 DCOMCNFG. Expand Component Services, expand Computers, expand My computer, expand DCOM Config, and then click the application that you want to automate. The application names are listed below:

    Microsoft Access 97 - Microsoft Access Database
    Microsoft Access 2000/2002/2003 - Microsoft 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.

  • Click the Security tab. Verify that Use Default Access Permissions and Use Default Launch Permissions are selected.
  • Click the Identity tab. Verify that The Launching User is selected.
  • Click OK to close the property dialog box and return to the main applications list dialog box.
  • In the DCOM Configuration dialog box, click the Default Security tab.
  • Click Edit Defaults for access permissions. Verify that the following users are listed in the access permissions, or add the users if they are not listed:

    SYSTEM
    INTERACTIVE
    Everyone
    Administrators
    OfficeAutomationUser
    IUSR_<machinename>*
    IWAM_<machinename>*

    * These accounts exist only if Internet Information Server (IIS) is installed on the computer.

  • Make sure that each user is allowed access and click OK.
  • Click Edit Defaults for launch permissions. Verify that the following users are listed in the launch permissions, or add the users if they are not listed:

    SYSTEM
    INTERACTIVE
    Everyone
    Administrators
    OfficeAutomationUser
    IUSR_<machinename>*
    IWAM_<machinename>*

    * These accounts exist only if IIS is installed on the computer.

  • Make sure that each user is allowed access, and then click OK.
  • Click OK to close DCOMCNFG.
  • Start REGEDIT and verify that the following keys and string values exist for the Office application that you want to automate:

    Microsoft Access 2000/2002/2003:
    Key: HKEY_CLASSES_ROOT\AppID\MSACCESS.EXE
    AppID: {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9}

    Microsoft Access 97:
    Key: HKEY_CLASSES_ROOT\AppID\MSACCESS.EXE
    AppID: {8CC49940-3146-11CF-97A1-00AA00424A9F}

    Microsoft Excel 97/2000/2002/2003:
    Key: HKEY_CLASSES_ROOT\AppID\EXCEL.EXE
    AppID: {00020812-0000-0000-C000-000000000046}

    Microsoft Word 97/2000/2002/2003:
    Key: HKEY_CLASSES_ROOT\AppID\WINWORD.EXE
    AppID: {00020906-0000-0000-C000-000000000046}

    If these keys do not exist, you can create them by running the following .reg file on your system: 
    REGEDIT4

[HKEY_CLASSES_ROOT\AppID\WINWORD.EXE]
"AppID"="{00020906-0000-0000-C000-000000000046}"

[HKEY_CLASSES_ROOT\AppID\EXCEL.EXE]
"AppID"="{00020812-0000-0000-C000-000000000046}"

[HKEY_CLASSES_ROOT\AppID\MSACCESS.EXE]
"AppID"="{73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9}"
    NOTE: The sample .reg file is for Access 2000 or Access 2002. If you are using Access 97, change the AppID key to the following: 
    "AppID"="{8CC49940-3146-11CF-97A1-00AA00424A9F}"
  • To avoid registry conflicts, install and run an NT service. Set the identity of the service to run as OfficeAutomationUser, and select Automatic as the startup type.
  • Restart the system. This is required.
NOTE: The steps that are given below use the term "package" to denote both a Windows NT 4.0 MTS Package and a Windows 2000 COM+ Application.

Creating a COM+/MTS package for a DLL

  1. On a Windows NT 4.0 computer, load the Transaction Server Explorer and browse to Microsoft Transaction Server\Computers\My Computer\Packages Installed. On a Windows 2000 computer, load the Component Services MMC Snap-in and browse to Component Services\Computers\My Computer\COM+ Applications.
  2. On Windows NT 4.0, right-click Packages Installed, click New, and then click Package. On Windows 2000, right-click COM+ Application, click New, and then click Application.
  3. Click Create an Empty Package and type the name of the package. For this example, use Office Automation Package, and then click Next.
  4. Select This user. Type OfficeAutomationUser and the password that you chose for this account, and then finish the wizard.
  5. Expand Office Automation Package and select Components. Right-click Components, click New, and then click Component.
  6. Select Install new component(s); a file dialog box appears. Select the DLL that automates Office and then click Open. The component information is displayed in the components dialog box. Finish the wizard.

Creating a COM+/MTS package for an ASP application

  1. Start the Internet Services Manager.
  2. Browse to the virtual folder that you would like to place into a package. Right-click this virtual folder and then click Properties.
  3. On the Directory tab, in Application Settings, click Create.
  4. On a Windows NT 4.0 computer, select Run in separate memory space (isolated process). On a Windows 2000 computer, set the Application Protection to High (Isolated).
  5. Click OK to accept the settings.
  6. On a Windows NT 4.0 computer, load the Transaction Server Explorer and browse to Microsoft Transaction Server\Computers\My Computer\Packages Installed. On a Windows 2000 computer, load the Component Services MMC Snap-in and browse to Component Services\Computers\My Computer\COM+ Applications.
  7. A new package named IIS-{Default Web Site\\Root\vdir} appears, where vdir is the virtual folder in which you created the application. Note that if the steps above were performed on a Web site other than the default Web site, the name of the package reflects that Web site.
  8. Right-click the package and click Properties.
  9. Click the Identity tab to view the identity information for the package.
  10. Select This user, type OfficeAutomationUser and the password that you chose for this account, and then click Finish.
  11. Click OK to accept the settings for the package.
  12. Right-click the package and then click Shut Down. This ensures that when the component is accessed, it will be created with the new identity.

REFERENCES

For more information, click the following article number to view the article in the Microsoft Knowledge Base:

169321 COM servers activation and NT Windows stations

184291 COM objects fail to print when called from ASP

Modification Type:MinorLast Reviewed:5/23/2006
Keywords:kbConfig kbAutomation kbDCOM kbhowto KB288368
©2004 Microsoft Corporation. All rights reserved.