Why can't Excel open a file when run from task scheduler?

I wrote a powershell script that opens an excel workbook and runs a macro. When I run that script from PS console, or even from command line using powershell.exe script.ps1, it jus works. When I set up a task from the windows task scheduler, it raises an exception about that excel file, saying that it either does not exist or is already in use.

The file exists for sure, as the script run from command line, and i'm positive it is not in use.

I tried to move the excel file to a local and non-privileged area, to avoid network trust/ admin privilege issues. The task still runs with highest privileges. The path has no spaces, or special characters.

When I try to access to the file using a File system object, there is no errors even when run from the scheduler, so I guess it is specific to Excel.Application.Workbooks.Open("..") method.

What should I consider now ?

Thanks in advance

zrz

Posted 2013-04-08T17:03:39.910

Reputation: 153

tl;dr: The workaround in eric's answer is effective, but it is unsupported - see this Microsoft support article. Better to look for alternatives such as the DocumentFormat.OpenXml nuget package.

– mklement0 – 2020-02-03T15:37:39.247

1What user account is used to run the scheduled task? – Massimo – 2013-04-08T17:19:29.800

I used the domain administrator account, and it seemed to be the problem. Using the domain administrators group worked. But I now had to find why the DCOM Access authorization has an issue with the domain administrator account. – zrz – 2013-04-09T13:19:10.153

Answers

It's likely a DCOM permissions issue. Automating Excel is sometimes fraught with peril...

The only way I've found around issues such as this is to set Excel to run as a specific user through DCOM permissions.

Open Component Services (Start -> Run, type in dcomcnfg)
Drill down to Component Services -> Computers -> My Computer and click on DCOM Config
Right-click on Microsoft Excel Application and choose Properties
In the Identity tab select This User and enter the ID and password of an interactive user account (domain or local) and click Ok

Keeping it as the interactive user or the launching doesn't work with the task scheduler unfortunately, even when setting the task up to run under an account that has admin access to the machine.

squillman

Posted 2013-04-08T17:03:39.910

Reputation: 5 676

Microsoft doesn't support running Office COM components in non-interactive sessions - see https://support.microsoft.com/en-us/help/257757/considerations-for-server-side-automation-of-office. eric's answer is a currently effective workaround, but it is unsupported.

– mklement0 – 2020-02-03T15:30:18.393

Thanks for pointing out dcomcnfg. I had to manually add the Excel Application into the Registry to be able to see it into dcomcnfg, then I tried to change identity settings but it didn't work either. From dcomcnfg, I looked into Access Authorization: the Domain Administrator was on the list and had local and remote access, but there was a little red sign (white cross within a red disk) over its icon. I have no idea why but somehow there is a problem with the Domain Administrator account. Adding the Domain Administrators group account and running the task from that group is a workaround. – zrz – 2013-04-09T13:16:05.750

Create these two folders:

32Bit:

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

64Bit:

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

Excel needs these folders if it's not run interactively. Create both folders even if you are on a 64-bit OS.

eric

Posted 2013-04-08T17:03:39.910

Reputation: 401

2I just want to add in that Microsoft does not endorse running any Office component non-interactively, but it is possible to get around it in many cases. – flindeberg – 2014-12-02T08:52:56.780

1I don't normally post 'thank you' spam, but for this I just have to. Its unbelievable that Excel simply doesn't work when an empty folder doesn't exist when running in non-interactive mode, while being completely fine in normal mode. It really does beggar belief. – BJury – 2015-06-05T10:22:48.087

@eric . . . Thank you, thank you. This worked for me. – Gordon Linoff – 2015-09-03T19:53:11.860

6This is some seriously black magic. I don't know what's scarier - that Excel needed this folder in this scenario or that someone knew that Excel needed this folder in this scenario. – Rich C – 2015-10-27T19:27:05.307

I spent like 2 days trying to get php exec a vbs script to convert xlsx. This finally fixed the issue. Bless windows for its stupidity. Thanks so much for this solution!!! – Bluestar – 2018-03-13T19:25:17.300

I have no words do describe how grateful I am right now. Thank you so much. But I was wondering...how do you find out about this trick – Theotonio – 2018-05-18T20:27:35.157

2How can I ever repay you? Cash, creditcard, pokemon cards, firstborns? – steenbergh – 2018-06-08T19:00:03.977

I have been searching high and low for this answer. I've been plagues my various com issues. This has solved it. – Tom Kelly – 2019-11-15T14:52:43.317

This is unbelievable - I spent an entire day trying to resolve why I could run a Python script to access Excel, but could not run the same script if I SSH'ed into the server first. Thank you. I would love to know where this information exists or how you discovered this. – Jason Roman – 2020-01-11T01:33:07.007

To emphasize @flindeberg's point: This workaround is effective, but it is unsupported - see this Microsoft support article.

– mklement0 – 2020-02-03T15:31:34.007

THANK YOU SO MUCH. I have spent HOURS trying to get Excel to work on in a TaskScheduler script - driving me CRAZY. – Guy – 2013-11-07T13:31:40.160

When setting DCOM permissions, if Microsoft Excel doesn't appear in dcomcnfg try mmc comexp.msc /32

reference

cmo

Posted 2013-04-08T17:03:39.910

Reputation: 41

This was the missing piece for me - thank you! – John M – 2017-07-06T08:23:22.863