Can't create a COM object in a powershell script running as a scheduled task

1

I have a powershell script I'm trying to run as a scheduled task. Its purpose is to perform a nightly export from an Access database, then upload the exported flat files to an SFTP destination. The script works fine when I run it manually, but when I try to run it as a scheduled task, it fails. I've narrowed down the problem to a failure to create a COM object.

What I'm Seeing

I've done some logging on this, and I think I know what's going on; I just don't know how to fix it.

The offending line in my powershell script is $Access = New-Object -ComObject Access.Application. When I run the script manually, my Access COM object is created successfully. $Access is of type Microsoft.Office.Interop.Access.ApplicationClass, as I'd expect.

If I run it as a scheduled task, running under my own permissions, the COM object isn't created; $Access is returned as $null, which causes any method calls against that object to fail.

I can get the COM object created successfully by checking "Run with highest privileges" in the Task Scheduler, but this creates another problem. My Access database uses linked tables on a network share, and by running as the local admin, I lose access to those tables because I'm no longer a domain user.

My question

Does anybody know why I can't seem to create a COM object when running this as a scheduled task under my own credentials? Is there any fix for it?

Failing that, any suggestions for fixing my permissions problem? It seems like I'm in a Catch-22 here; the only way to successfully create my COM object is to use credentials that cause the rest of my script to fail.

Jeff Rosenberg

Posted 2014-03-18T13:49:37.523

Reputation: 111

2

This answer is for excel, but it may help your situation with Access as well http://stackoverflow.com/a/13369587/291709 Also, be sure to check out the KB article on Server side considerations for office automation http://support.microsoft.com/kb/257757 Office applications assume a desktop environment, so running as a scheduled task while logged off can cause problems.

– Rynant – 2014-03-18T17:29:53.573

Thanks for the warning. After reading the KB article, I may consider an alternative way of doing this. – Jeff Rosenberg – 2014-03-18T17:48:36.643

can you not map a drive to the network share in your script (including user credentials) so that local system can impersonate you while you are not logged in. Maybe just need an if test-path = false statement followed by a net use \\myshare command to map it. – Knuckle-Dragger – 2014-03-21T08:03:23.820

No answers