Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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

share|improve this question

migrated from serverfault.com Apr 8 '13 at 18:45

This question came from our site for system and network administrators.

    
What user account is used to run the scheduled task? –  Massimo Apr 8 '13 at 17:19
    
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 Apr 9 '13 at 13:19

2 Answers 2

up vote 3 down vote accepted

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.

  1. Open Component Services (Start -> Run, type in dcomcnfg)
  2. Drill down to Component Services -> Computers -> My Computer and click on DCOM Config
  3. Right-click on Microsoft Excel Application and choose Properties
  4. 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.

share|improve this answer
    
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 Apr 9 '13 at 13:16

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

share|improve this answer
    
THANK YOU SO MUCH. I have spent HOURS trying to get Excel to work on in a TaskScheduler script - driving me CRAZY. –  Guy Nov 7 '13 at 13:31
    
I 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 Dec 2 '14 at 8:52
    
I 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 Jun 5 at 10:22

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.