I developed a C# program that pulls data from a SQL Server database and then generates Word documents which include the data. 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.
Related
Hi I have created windows service c# to create an excel file. When I scheduled and running under my id in dev environment it is working fine. But when i run the same service with different interactive Id which is also an administrator account in the server, the service is failing at the line Excel.WORKBOOK.saveas(object) with the below error
"Microsoft Excel cannot open or save any more documents because there is not enough available memory or disk space." I have tried many solutions provided in net to provide permissions in comconfig and to create desktop folders in c:\windows\sys32 and syswow64.
But still unable to find it.. only with my id the service is running fine but any other interactive if it is failing. Please help
The Considerations for server-side Automation of Office article states the following:
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.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
I'd suggest using the Welcome to the Open XML SDK 2.5 for Office if you deal only with open XML documents, otherwise you may consider using third-party components designed for the server-side execution.
I am trying to use my asp.net application to open the outlook. It is working fine on my machine. now i am deploying the app to the server. i got this exception
Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED)).
I have been trying to solve this exception for three days. i googled a lot.
What I tried
they said that i have to go to DCOM CONFIG, i went there but I didn't find the microsoft office outlook entry.
then i opened a cmd and I typed mcc -32 and then i added the component server. after that i saw the outlook entry. i went to the property and then to the security tab, then i change the three of the options there to give access to the everyone user. but i kept having this problem
Note that I did that changes to these two entries
Microsoft Outlook Commadn Button
outlook message attachment
then i changed the user of the application bool to the Administrator account of the server, but i kept having the problem
please help me, i tried a lot really a lot to solve , but i couldn't
I am trying to use my asp.net application to open the outlook.
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.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
As a workaround you can use the low-level API - Extended MAPI. Or any other third-party wrappers around that API (for example, Redemption).
First off, forgive me if this question appears amateur or has been answered in the past - I'm pretty new to programming in general and have tried to search for an answer.
I'm trying to write an executable that will access an Outlook mailbox, pick up an unread email and insert its details into a database for our records.
I've written a proof of concept application that I can run fine but when I try and call it through a stored procedure in Sql server I hit the error message:
Unhandled Exception: System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80070005 Access is denied. (Exception from HRESULT: 0x80070005 (E_
I imagine I'm hitting a security issue along the way but maybe, due to my inexperience, this simply isn't possible with Microsoft security settings?
So far I've tried:
-Using regsvr32 to register the .dll
-Changing the permissions of the .dll
-Setting up a Sql server proxy account that is the same login as the one I use to access the VM where the server is hosted
-Trying to run it using both late and early bound methods
Any advice would be greatly appreciated as I'm pretty stumped!
Thanks in advance guys.
Just because something can be done, doesn't mean it should :) Going from SQL Server to Outlook via xp_cmdshell has so many possibilities for failure that I wouldn't even contemplate it. You might get it working on one machine then find that you just can't get it working on another.
The simple way to do this would be a small .Net app; query Outlook + write to database. If you want it to work on a continual basis either use a scheduler or create a Windows service to perform the task every n minutes.
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.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution.
I'd suggest choosing another model of calling/working with Outlook. For example, you can automate Outlook from a standalone application. See How to automate Outlook from another program for more information. Also you may consider developing an Outlook add-in which can synchronize emails on the fly (when they arrives).
I'm developing a windows service, generating a report. This report has a template. This template is prepared in an excel file. This file is copied to the output folder.
While developing I launched the service like a console application and had no problems accessing this file.
Then I prepared a service installer. The service is installed under Local System account. So this excel template file is marked as content and copied to the installation directory together with the executable as well.
But when the service is launched excel appears to have no access to this file. The service is installed to c:\Program Files (x86)\Our Company\Service Name\. The target OS is Windows Server 2008. While testing I use Windows 7 and run into the same issue.
I use the following code to access excel.
using Excel = Microsoft.Office.Interop.Excel;
//...
Excel.Application xlApp = new Microsoft.Office.Interop.Excel.Application();
//the following line throws an exception
Excel.Workbook xlWorkBook = xlApp.Workbooks.Open(#"path");
I also tried to copy the excel template file to some temporary directory (where the service has the right to write - this is tested) and tryed to open it from there, but to no success (while this variant works good in a console application as well).
The error message sais:
Microsoft Office Excel cannot access the file /path/.
There are several possible reasons:
1. The file name or path does not exist.
2. The file is being used by another program.
3. The workbook you are trying to save has the same name as a currently open workbook.
How can I make the windows service access this excel template file? Or is there another alternative?
To safety run Office applications (Excel and others) under user service with Local system account you must know two important things:
1) In Windows Server 2008/2008 R2 you must manually create two folders:
C:\Windows\system32\config\systemprofile\desktop
C:\Windows\SysWow64\config\systemprofile\desktop (for x64 version only)
Without this folders you cannot correct run office Applications from Local SystemAccount
2) If you service is configured without desktop interaction then in the first time launched office application (Excel for example) freeze on user credentials dialog - you cannot see this window in this mode - to resolve this enable desctop interacting, switch to office window after you service run it and manually enter credeentials.
Other information there(use google translater to read).
There is a detailed MS knowledge base article titled Considerations for server-side Automation of Office. Some key excerpts:
User Identity: Office applications assume a user identity when the applications are run, even when Automation starts the
applications. The applications try to initialize toolbars, menus,
options, printers, and some add-ins based on settings in the user
registry hive for the user who launches the application. Many services
run under accounts that have no user profiles (such as the SYSTEM
account or the IWAM_[servername] accounts). Therefore, Office may not
initialize correctly on startup. In this situation, Office returns an
error on the CreateObject function or the CoCreateInstance function.
Even if the Office application can be started, other functions may not
work correctly if no user profile exists.
Interactivity with the desktop: Office applications assume that they are being run under an interactive desktop. In some
circumstances, applications may need to be made visible for certain
Automation functions to work correctly. If an unexpected error occurs,
or if an unspecified parameter is needed to complete a function,
Office is designed to prompt the user with a modal dialog box that
asks the user what the user wants to do. A modal dialog box on a
non-interactive desktop cannot be dismissed. Therefore, that thread
stops responding (hangs) indefinitely. Although certain coding
practices can help reduce the likelihood of this issue, these
practices cannot prevent the issue entirely. This fact alone makes
running Office Applications from a server-side environment risky and
unsupported.
Obviously, as has been pointed out in the comments, using the SYSTEM account is a mistake. You would need to run the service under an account that has a user profile.
But even when you fix that, the other bullet point will kill you. Office applications do indeed assume they are running under an interactive desktop. My advice is to abandon attempting to automate Office from a service. Use a library like Aspose instead. Or run the process on an interactive desktop.
I just faced the same problem.
I have made a .bat file where I called the .exe file.
finally, I called the .bat file from the task scheduler actions.
It just works fine.
Does anyone know how to get the MS Office 2007 .NET C# Interop libraries to work with Vista?
I have a .NET C# application that I have setup to run as a Windows service. This program will open up a Word or Excel template depending on the situation and modify its contents and then save the document back out. All of this worked great when I was doing it on a Windows Server 2003 or XP machine using Office 2007. When I moved everything to a Server 2008 box, everything quit working. In Excel for example, I get a COM exception telling me that the Excel file cannot be opened when the file is clearly there and I can open it just fine when doing it manually. The windows service is running under the same user account that I log into the machine with and that account is an Administrator.
Does anyone have any idea what to do?
On Vista and Windows Server 2008, services run in something called Session0. Before Vista, regular programs would run in Session0 alongside services.
This means that Session0 has become a desktop-less wasteland where your services can't even access explorer.exe. I'm pretty sure the problem is that Office applications are expecting to be able to access a few components that are normally on the desktop.
Since Excel, Word, etc. are only supported on a desktop-ed session, you only have a few choices:
Set the Desktop checkbox in the LogOn tab of your Service's properties and pray that it appeases the Office gods. (It probably wont.)
After trying 1, go through your code and try and remove/work around anything that causes it to crash.
Use remoting/WCF to make a server that performs the interop work, and make your service communicate with it.
You'll need to have a logged in interactive user and the user needs to start the server application somehow. Perhaps best to use autostart.
You can try turning on Automatic login. http://support.microsoft.com/kb/324737
Try impersonating a Logged in user using CreateProcessAsUser and friends.
Note: I don't know how well this works unless a user is actually logged in, so it might not be any more useful than 2 above, and is much harder to pull off. (Needs P/Invoke)
Rewrite your program to use the OpenXML sdk or use something like SpreadsheetGear.
You should really avoiding running the Office clients as server side apps. Consider using xml as file format (xlsx for Office 2007, or using the Excel workbook xsd for (somewhat) older versions.) Then you would be freed from using the Excel API on the server.
I did find an interesting article from Microsoft basically saying don't do Office automation.
Get the installables from
http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&displaylang=en
install it on your system and refer excel dll in your solution and hopefully it should work.
Do you have the primary interop assemblies installed on the server? These are usually located in the GAC and not included in the bin directory when you build your program, so they would need to be installed locally on the server.
This is just a guess, but it might be UAC. I know that privileged (admin) applications and user applications cannot send messages to each other or communicate in any way. Your service is running as an administrator, but your desktop is running as a regular user under UAC even though they are the same user. I also expect that Office has started up (pre-loaded) parts of itself on startup and that would be running as a regular user.
Try turning off UAC and see if that helps. If so, at least you know what it is.
Do you leave an account logged on to the machine? Office is not a server-side app, and you will get random errors if you try to launch any of the executables without a desktop context.
Something to remember about Office. Its x86 only, so if your creating an application in x64, you will not be able to access the Office underlying COM objects. You will need to compile your application in x86, then it would work.
You can do that by going into the properties of your project, and selecting x86 under the build tab in visual studio.
This is all assuming that your app is being developed/run in a x64 enviroment that is.