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.
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.573Thanks 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 anet use \\myshare
command to map it. – Knuckle-Dragger – 2014-03-21T08:03:23.820