4

Here is some strange behavior, I've got a PowerShell script that converts an XLSX file into a CSV file. This script runs in the console without issue.

Trying to schedule the task/script results in a CSV file with no data (0 Bytes).

In my searching, I found this TechNet forum post that proved helpful.

Essentially the scheduled task containing the Powershell script that uses the Excel ComObject fails because You have to create a folder (or two on a 64bit-windows). Once this was done, the task when run manually works as expected. It also works when a trigger is set and the user is logged off.

Is this type of behavior concerning the Excel ComObject documented anywhere at all? I spent 3 hours trying to get this to work.

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

(64Bit)

C:\Windows\SysWOW64\config\systemprofile\Desktop
Improve this question

2 Answers 2

Reset to default
2

AFAIK There are no official documentation from MS about this issue/limitation. It should be reported as a bug (contact Microsoft Support).

The requirement of a desktop folder (which SYSTEM doesn't have by default) shouldn't be necessary for excel to run and at least it should have created the folder if missing.

Improve this answer
Sign up to request clarification or add additional context in comments.

5 Comments

What's worse, that TechNet thread is from 2010. Would this be a bug from Windows, Excel or PowerShell?
The problem is with the Excel.Application ComObject (or Excel application itself). The problem is documented with vbscript sample too.
I can't log a bug at connect.microsoft.com/directory so I'm not sure what next step to take.
I think you have to call Microsoft support when it comes to Office bugs. If they can reproduce it they'll make a bug report.
I'll look into that option, for now I have posted the problem here
1

I don't believe Microsoft supports what you are attempting to do. According to this documentation, Microsoft states:

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

The documentation appears to be for Office 2003, but I'm not sure if they have changed there stance since then as I haven't found other documentation stating support. As recently as 2009, this MVP reiterates that it isn't supported. The recommendations appear to be to use OpenXML SDK for non-interactive automation, or another third party library for working with the file format directly.

Improve this answer

2 Comments

Now things are starting to make sense, this is what I term current behavior governed by past problems. In the Technology world, these problems might have been identified and resolved with updated code/technology or understanding. The suggested route, as pointed out, is to use OpenXML and System.IO.Package.IO namespace in the Microsoft .NET 3.x Framework to edit Office files. Trouble is, I've got to learn that!
Yep, I ran into a similar issue. There is a PSExcel Module that leverages EPPlus. You could use either of those to lessen the learning burden.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.