• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 864
  • Last Modified:

Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80070005.

I have an application that should run on a remote server as a scheduled task.  The application fails with the above error message.  However, if I execute the application manually, it runs smoothly.  No problems.  

All the resolutions I have found relate to ASP.net applications.  Including those I have found in Experts Exhange.  My application has no UI.  It just needs to run at a specified time.  

The application builds word documents then saves them to a location on another server.  I've determined the program fails when I identify the path and folder to where the letters need to be stored.
0
bgernon
Asked:
bgernon
  • 6
  • 5
1 Solution
 
pasoloCommented:
This appears to be a permissions issue related to the account under which the scheduled task is running.
But have a look at the Scheduled Tasks log file
0
 
bgernonAuthor Commented:
Where is the log?  I'm new to this scheduler.  I've been poking around trying to find it.
0
 
pasoloCommented:

On XP look for Schedlgu.txt in the Windows folder.
On Windows 7 Task Scheduler can be viewed by opening the task properties and clicking on the History tab
0
Cloud Class® Course: CompTIA Healthcare IT Tech

This course will help prep you to earn the CompTIA Healthcare IT Technician certification showing that you have the knowledge and skills needed to succeed in installing, managing, and troubleshooting IT systems in medical and clinical settings.

 
bgernonAuthor Commented:
No, nothing there.  The scheduler thinks it completed the task successfully.  I have the program email errors to me.  I catch the error, then have it emailed to me.  So as far as the scheduler goes, it thinks it did it's job.
0
 
pasoloCommented:
As I said it appears like a permission issue.
When the task runs under you account, that is when it runs manually, there are no problems as you say.
If the task run under another user account it has no access to your CURRENT_USER Registry where you might have saved configuration settings. Or the task may be trying to save to a folder where it has no wrtting permissions..It may also be a problem related to relative paths, test with absolute paths and see if it works.
0
 
bgernonAuthor Commented:
The path is absolute.  

Are you saying that when the task runs, it is using a different user account than my own?  When I set up the task, it is using my user account.
0
 
bgernonAuthor Commented:
The fix is to open up Component Services\Computers\My Computer\DCOM Config. Right click Microsoft Office Word and select properties.  Select the Identity tab.  Select This User button, then put either your user ID or Administrator, then password.
0
 
pasoloCommented:
You have not found the solution, you have been leaad to the solution
0
 
bgernonAuthor Commented:
0
 
pasoloCommented:
When you came here you had no clue, even to search google about the issue.
I gave you all the information you needed.
You showed surprise in these terms?
"Are you saying that when the task runs, it is using a different user account than my own? "
Then you searched google with my input and you got the specific answer you were looking for.
The answer was:
"Select the Identity tab.  Select This User button, then put either your user ID or Administrator, then password"
But you thought you have found the solution and decided to close the question even without a thank you.
Pity
0
 
pasoloCommented:
All my comments state it is a permission issue, and I clearly said:
"When the task runs under you account, that is when it runs manually, there are no problems as you say. If the task run under another user account it has no access to your CURRENT_USER Registry where you might have saved configuration settings"

I don't find what bgernon considers the solution a good solution (according to programming good practices) for the simple reason that according to Microsoft
http://support.microsoft.com/kb/257757/
"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"

Even if the solution satisfies bgernon, he has arrived at it after the discussion here and all hints I provided are actually part of the solution that satisfies him, namely that the problem is caused by the task not running always under the same account and then can not access the Registry settings where the path is stored when running under a different account.




0
 
South ModModeratorCommented:
All,
 
Following an 'Objection' by bgernon (at http://www.experts-exchange.com/Q_26856643.html) to the intended closure of this question, it has been reviewed by at least one Moderator and is being closed as recommended by the Expert.
 
At this point I am going to re-start the auto-close procedure.
 
Thank you,
 
SouthMod
Community Support Moderator
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

  • 6
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now