File Access from Excel COM object fails when run from NT Service on Vista
We use COM objects to access excel spreadsheets in an NT service (via the Windows Scripting Host). Prior to Vista, this worked beautifully, but starting with Vista, we receive this error:
Microsoft Office Excel cannot access the file 'c:\myfiles\test.xls'. There are several possible reasons:
- The file name or path does not exist.
- The file is being used by another program.
- The workbook you are trying to save has the same name as a currently open workbook.
I have tried changing the NT service logon settings to use my own account, an admin account and local system. I've looked through the Local Security Policy and have not found anything. I've spent days searching through the Microsoft KB to no avail.
If the script is executed from a console application, it works fine. The file opens and is processed with no problem. The error only occurs when executed from within the context of a service.
If the service is running on Windows XP or Server 2003 SP1, it also works fine. Only on Vista does it fail (and we've now gotten reports of it failing in Server 2003 SP2)!
The code, for what it is worth is exceptionally simple:
dim xl_app Set xl_app = CreateObject("Excel.Application") xl_app.Workbooks.Open mypath,0,1
I suspect that this person might be experiencing the same issue: http://bytes.com/forum/thread819740.html
just some further questions:
- Which version of Excel are you using?
- Have you tried running the service with elevated privileges?
I have "kind of" solved this problem. If you use "dcomcnfg" to change the account to launch the excel application to a user account or "interactive user" the excel launched from the service starts in that account and it now can access the file system.
The problem is this is a global setting. If you use: * "this User": then excel ALWAYS opens with that user AND always opens up with no UI in session 0, even for interactive use of excel. IE its always invisible. * "Interactive User": Now excel always launches in the interactive user accout which I don't think will work for a service which will launch on bootup with NO interactive user.
There must be some security setting on this. I hope others have other ideas.