Excel COM automation stops working when user logs off

I have developed a server app that uses Excel 2007 COM automation to convert some xls files. It is started as a service on a Windows Datacenter instance, running under its own user, and I had to change DCOM security settings ("launch as interactive user") to make it work.

The problem is, when I log off (via RDP), it stops working. I log on, it works again.

Has anyone had the same problem? I'm glad about any help at this point.

Ok, so I couldn't get Excel to operate without an interactive user, no amount of DCOMCNFG trickery would do. So I simply configured autologin for the user the service is running under (see http://support.microsoft.com/kb/315231 for instructions).

This has the effect that on server bootup, that user will login as an interactive console session. Unlike RDP sessions, this is permanent and makes Excel happy.

Other hints for the poors souls who have to do something similar:

* create the folder C:\Windows\System32[or SysWOW64]\config\systemprofile\Desktop
* make sure a default printer is configured for the user the service runs under
* change DCOMCNFG settings (mmc -32, add "component services") of Excel to run using the interactive account
* change global DCOM defaults to allow local access, local launch and local activation for the user the service runs under

Good luck!

I've had this issue, and I found that the answer is actually in the DCOM Configuration.

I did the following to resolve the issue:

* Open the Excel DCOM Properties
* Go to the Identity tab
* Select This User
* Enter the credentials of someone who has access to Excel

You may need to go to the Security tab and ensure the user you've specified above has appropriate Permissions.

After doing this, I was able to Log Off the Server while still using the Excel COM Automation libraries.

If the account which is running EXCEL is administrator then this will work:

For 64-bit (x64), create this folder:
For 32-bit (x86), create this folder:
Otherwise To resolve this issue follow these steps:

1. Login to your Server as a administrator
2. Go to "Start" -> "Run" and enter "MMC comexp.msc /32"
3. Go to the properties of Microsoft Excel Application, under Identity, change it to The Interactive User from The Launching User (which is set by default).
4. Go to the properties of Microsoft Office Excel 2007 Workbook, under Identity, change it to The Interactive User from The Launching User (which is set by default).
5. Go to Security tab for Microsoft Excel Application and select Customize for " Launch and Activation Permissions" and add ACCOUNT (under which EXCEL is running) to it and give it "Local launch" and "Local Activation" permission
6. Go to Security tab for Microsoft Office Excel 2007 Workbook and select Customize for " Access Permissions " and add ACCOUNT (under which EXCEL is running) to it and give it "Local Access" permission


Server side:

A) Switch "Interactive User" to "This User".

B) "This User" only works after creating these folders :

* C:\Windows\SysWOW64\config\systemprofile\Desktop
* C:\Windows\System32\config\systemprofile\Desktop

C) Wait for it... Step B) triggers Windows to auto create:

* C:\Users\Default\Desktop

Note the definition of "Interactive User" is to piggybacked on whatever is the active logged in user to the server. Thus failure to launch MS Office when no user is active on the server.

I.e., for me, the solution was a hybrid of the already proposed solutions. I used Office 2013 (x86) on Win 2012R2. My issue was instead with Word (to use WordToPDF).

Details for Step B:

* Login to Server > Start > run DCOMCNFG.EXE (to launch Component Services) > Console Root > Component Services > Computers > My Computer > DCOM Config...
* Scroll to "Microsoft Word 97 - 2003 Document" or "Microsoft Excel Application" (... i.e., whatever MS Office thing you need to launch)...
* Right click it and select "properties" > Identity tab > Choose "This User" > enter credentials for some user with access to MS Office on the server. (I used a user with administrator permissions.)

Details for Step C:

* The wait varies from 5 min to over-night. Optionally, create this folder manually (if the folder does not exist and you're in a rush to complete testing).


See Also:

[VeryDOC Release Notes] VeryDOC Releases an EXE COM of VeryPDFComRunCmd.exe today, VeryPDF EXE COM does allow you to call MS Office and Any EXE application from ASP, PHP, C#, .NET etc. program languages,

VeryPDFComRunCmd COM Component,

VN:F [1.9.20_1166]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.20_1166]
Rating: 0 (from 0 votes)

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *

Verify Code   If you cannot see the CheckCode image,please refresh the page again!