DCOM Failure of Office Automation

I developed a C# program that pulls data from a SQL Server database and then generates Word documents which include the da开发者_开发知识库ta. I've set the program up to run as part of an SSIS job on a Windows Server 2003 box. The program runs as user SQLSVC which doesn't have administrative privileges. When I log in as SQLSVC and run the program it executes correctly. However, when the program is run automatically as an SSIS job it freezes at the following line of code

Microsoft.Office.Interop.Word.Application word =
    new Microsoft.Office.Interop.Word.Application();

When I kill the process forcibly, the following error message is generated.

Error Message: System.Runtime.InteropServices.COMException (0x80080005):
Retrieving the COM class factory for component
with CLSID {000209FF-0000-0000-C000-000000000046}
failed due to the following error: 80080005.
   at IepGlance.Program.CreateNewIepFiles(Dictionary`2
       iepDictionary, EasyIepDataContext dbContext)
   at IepGlance.Program.Main(String[] args)

As far as I can figure out the problem is with DCOM permissions. I've used dcomcnfg to add all possible DCOM permissions to user SQLSVC, but this hasn't helped. Are there any other possible solutions?

Run program "dcomcnfg -32". ( You cant find the word and excel components if it runs under 64bit) Go to "Console Root/Component Services/Computer/My Computer/DCOM Config/" Look up Microsoft Word and Excel and choose properties. Go to Security and select "Customize" under "Configuration Permissions. (If needed you might want to change the other permissions as well, but I didn't need to) Add "IIS_IUSRS" and give it "Full Control". Now go to "Identity" and select "The interactive user".

Couple of things here.

First, this thread on SO may help.

Second, Microsoft warns that 'complications' may arise when you automate Office through an unattended process. Here's the punchline (bolded in the original):

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 linked article discusses workarounds.

It depends whether you are on a 64-bit machine and if you are 32-bit Office or 64-bit office, but in either scenario you need to go into the Admin Tools > Component Services and under DCOM config you need to find 'Microsoft Word 97 - 2003 Document', and then set the 'identity' to the user that is running your app pool. or simply disable the security on it.

If you are running a 64-bit server with 32-bit Office, you may have trouble finding this DCOM setting. You will need to run "MMC -32" from the command prompt to launch 32-bit MMC and then add 'Component Services' from the 'File > Add / Remove Snap-ins' menu.

Hope this helped

One point from my side, I was scheduling the batch job in one of our server and it was throwing the same error whereas it was running in my local.

I tried all of the above steps but in my case actual scenario was different.

Whenever schedule the batchjob, do not select the option [Run whether user is logged on or not] because this requires the admin access and if you are not, you are in problem.