none
Excel 2007 automation on top of a Windows Server 2008 x64

    Question

  • I’m well aware of the Microsoft support base article stating that it’s not supported to automate office products UI less. It seems that Windows Server 2008 and Excel 2007 enforce the given statement.

    I’m running the following code in a NT Service (Local System account) OnStart method. All it does is Excel automation the way it’s working when you run the same code in a Console Application.

    The provided code has two parts. The first part launches Excel, creates a new work book and saves it to the given filename. The second part launches a new instance of Excel and opens the given file. The open operation ends in this exception:

    Service cannot be started. System.Runtime.InteropServices.COMException (0x800A03EC): Microsoft Office Excel cannot access the file 'c:\temp\test.xls'. There are several possible reasons:

    • The file name or path does not exist.
    • The file is being used by another program.
    • The workbook you are trying to save has the same name as a currently open workbook.

    Why was the automated excel able to launch and write files to disk but fails when it’s asked “just “ to open an existing file?

    System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-US");

                // launch excel and create/save a new work book

                Microsoft.Office.Interop.Excel.ApplicationClass excel = new Microsoft.Office.Interop.Excel.ApplicationClass();

    excel.UserLibraryPath, excel.Interactive));

                //           

                string filename = "c:\\temp\\test.xls";

                if(System.IO.File.Exists(filename)) System.IO.File.Delete(filename);

                //

                excel.Workbooks.Add(System.Reflection.Missing.Value);

                excel.Save(filename);

                excel.Quit();

                excel = null;

                // lauch new instance of excel and open saved file

                excel = new Microsoft.Office.Interop.Excel.ApplicationClass();

                try

                {

                    Microsoft.Office.Interop.Excel.Workbook book = excel.Workbooks.Open(filename,

                        System.Reflection.Missing.Value,

                        System.Reflection.Missing.Value,

                        System.Reflection.Missing.Value,

                        System.Reflection.Missing.Value,

                        System.Reflection.Missing.Value,

                        true,

                        System.Reflection.Missing.Value,

                        System.Reflection.Missing.Value,

                        false,

                        false,

                        System.Reflection.Missing.Value,

                        false,

                        System.Reflection.Missing.Value,

                        System.Reflection.Missing.Value);

                    book.Close(false, System.Reflection.Missing.Value, System.Reflection.Missing.Value);

                    book = null;

                }

                finally

                {

                    excel.Quit();

                    excel = null;

                }

                //

                GC.Collect();

     


    Chris Richner http://www.raccoom.net
    Thursday, May 14, 2009 2:30 PM

Answers

All replies

  • Hi,


    Thank you for contacting Microsoft Innovate on Office Advisory Services.

    We have started our research on this request and will get back to you ASAP.

    Thanks,
    Sunando.

    Note:
    Create an alert when someone has either replied to the post or added a post to the thread you subscribed to. The alert will send you a message (via e-mail, Instant Message or a mobile device).

    http://forums.microsoft.com/msdn/languages/en-US/docs/faq.aspx?SiteID=1#19

    Sunday, May 17, 2009 7:28 PM
  • Hi,

    We have looked at all options around the usage of a service for achieving something like this. The services running in windows run in a specific security context of one of the three generally -

    1. SYSTEM
    2. LocalService
    3. NetworkService

    There is one more special context of the User that is the somewhat similar to the one of the current logged in user ------------- domain\user.

    Now, once a service is attached to a process that is in common terminology, when a service runs, there is a station created for that service and any process runs within that station. Now if you were to write the same code in an executable and run it by clicking on the exe file, you will find the code working and if you check the owner of the file it will be the current logged in user. But, when this file is created using a service the owner is always the administrator and the not the current user. Therefore through this service the file is created and probably opened in an invisble excel as well, but altogether in a different station. Hence the excel is never visible to the current user. The notion though can be revalidated using the processes running on the machine for other users, you will find an excel process running due to creation and opening of the file.

    If you are looking at running an excel file upon user login, then it would be appropriate to create an executable based on the above code and copy the same in startup folder.

    Please follow the links for more info on service creation and stations.

    http://msdn.microsoft.com/en-us/library/ms687096(VS.85).aspx

    Window Station and Desktop Creation
    Process Connection to a Window Station
    Window Station Security and Access Rights

    Thanks & Regards,

    Sunando

    Monday, May 18, 2009 1:37 AM
  • Hi,

    Thanks for your effort to investigate this issue. So far I understand the following things, also verified on my own test systems.

    • The owner of the file is always the administrator (and the not the current user)
    • According to Mark's Process Explorer Excel’s parent process is the same svchost.exe instance where dcomlaunch service is also running -> station 0, my desktop is running on station 1
    • This behavior seems to be unique to Windows Server 2008 & Excel 2007, I’ve installed a Windows Server 2003 R2 x64 & Excel 2007. The same code ran within a NT Service without any issues.

    By the way, I don’t want to do anything with a logged in user, it must be a NT service running on the server ready to do calc in an open workbook. The input and output flows trough WCF service in production.

    Are you aware of what exactly changed between the two major OS Versions? Is there any possibility that a configuration tweek can bring back the ability to automate Excel 2007 on a Windows Server 2008 x64?


    Chris Richner http://www.raccoom.net
    Monday, May 18, 2009 2:51 PM
  • Hi,

    Thanks for your comments. I will investigate the issue further. The only fact I wanted to bring to notice is - the owner of the file for all programmatical purposes is the administrator but only when the file is created through a service.

    I have tried a Windows Server 2008 x86 machine so far and the code works. I will soon try the same in a x64 machine with Windows Server 2008 and get back to you with the findings.

    Thanks
    Sunando
    Monday, May 18, 2009 4:26 PM
  • Do you mean by

    I have tried a Windows Server 2008 x86 machine so far and the code works. I will soon try the same in a x64 machine with Windows Server 2008 and get back to you with the findings.

    that the NT Service was able to open the excel file and you didn't faced the named exception I've seen?
    It is working with a X86 Version of the OS?

    BTW: I just need to open files with that automated excel, the creation of new files was just for sample purpose


    Chris Richner http://www.raccoom.net
    Tuesday, May 19, 2009 7:56 AM
  • Wednesday, May 27, 2009 9:13 AM
  • Hi,

    Apologies for the delay. Yes, I was able to open the excel file with an x86 machine. But, haven't had any luck with x64 version yet. I am still finding the reason for this unexpected behavior.

    Thanks,
    Sunando

    Thursday, May 28, 2009 3:22 AM
  • Thanks for your effort...

    I've checked out the registry hack ( http://social.technet.microsoft.com/Forums/en-US/office2007deploymentcompatibility/thread/334c9f30-4e27-4904-9e71-abfc65975e23?prof=required)and it's working.
    But why is it working? Because all the folders are already there or because Excel is able to create those folders?
     
    Maybe one could create the needed excel eco system ( folders etc ) by hand and then excel works fine with the regular ProfileImagePath,
     
    what do you think? Can you shed some light into this?

    Thanks

    Chris


    Chris Richner http://www.raccoom.net
    Thursday, May 28, 2009 11:25 AM
  • Hi Chris,

    Looking at the other thread you linked to it would seem that the issue exists for Office 2003 as well. I am working with PowerPoint 2007 and have the exact same issue.

    My understanding/experience is as follows:

    X86 - You can get it to work if you specify a specific user to run the Office application. If you use the user running the service it fails.

    X64 - There is no way to get it to work, unless you use the suggested registry hack from the other thread. However, using that may result in a number of unexpected behaviors so that feels a bit risky for a production server.

    Given that Windows Server 2008 x86 versus x64 function in different ways tends to suggest it is a bug. I'm just hoping Microsoft can help us get it to work the same way it does on previous Windows versions.

    Regards,
    Christer


    Christer Ogenstad @ http://www.slideexecutive.com

    Monday, June 01, 2009 8:45 PM
  • Hi Christer,

    AFAIK the issue is only related to Windows Server 2008 (R2 too) x64 & Office 2007. Every other scenario is working without any issues. 

    Microsoft never intended and supported this scenario and therefore maybe did changes on purpose to stop people doing it.
    Maybe they changed some important things behind da scene for the current x64 OS breed to be ready to host Office 2010 which will be the first Office version running with x64 executables.

    Just guessing, of course. Yes, let's hope for a "workaround" without any side effects or an alternative method.

    Maybe the OpenXML file formats can solve your problem? Did you check out the OpenXML pptx format support in .net?

    Chris
    Chris Richner http://www.raccoom.net
    Wednesday, June 03, 2009 11:13 AM
  • Hi,

    I have the exact same issue but I am not trying to run the .exe on Windows Server. I have set it up as a scheduled task using the Vista scheduler.

    The task runs successfully sometimes and gives the above error message some times. I have no clue why this is happening. When i run the code manually, i never have this problem.

    Can someone help me out with this?

    -Sandeep
    Thursday, June 04, 2009 1:09 AM
  • Hi Chris,

    Yes I have had a look at OpenXML and it looks promising. Unfortunately I have to generate thumbnails, furthermore (as far as I know) OpenXML is not backword compatible with older versions of Office (PowerPoint, Excel etc).

    Regarding the issue, I have the issue on x86 as well aulthough I can fix it by specifying the exact user that should be running Office in dcomcnfg.exe. However, on X64 I'm dead in the water, nothing is working.

    I still think/hope this is some sort of bug since x84 and x64 are behaving differently. Would be great if we could get a small sign from Microsoft that they are looking in to this.

    /Christer
    Christer Ogenstad @ http://www.slideexecutive.com
    Thursday, June 04, 2009 8:48 AM
  • Hi Sunando,

    Do you have any news for us?

    Thanks,
    Chris
    Chris Richner http://www.raccoom.net
    Wednesday, June 24, 2009 7:21 AM
  • Hi,

    I was running into the same issue and
    I have investigated infomation about "registry hack".

    After all, I found another solution that changes no registry values
     and everything works on properly.

    This solution is ...

    ・Windows 2008 Server x64

      Please make this folder.

      C:\Windows\SysWOW64\config\systemprofile\Desktop

    ・Windows 2008 Server x86

      Please make this folder.

      C:\Windows\System32\config\systemprofile\Desktop

      ...instead of dcomcnfg.exe.

    This operation took away office automation problems in my system.

    A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.

    It disappears from Windows2008, Windows2003 had the folder,
    and I think it cause this error.

    I think it is safer than "registry hack".

    If you try this solution, please let me know results.

    Ogawa

    • Edited by H Ogawa Wednesday, June 24, 2009 11:38 PM
    • Proposed as answer by angerico Monday, June 29, 2009 7:37 AM
    • Marked as answer by Chris Richner Monday, June 29, 2009 12:12 PM
    Wednesday, June 24, 2009 8:39 AM
  • Things that makes you go hmmmmm, i will check that and let you know.
    Chris Richner http://www.raccoom.net
    Wednesday, June 24, 2009 5:29 PM
  • Since you are aware of the article 257757 you probably might consider changing the application architecture.

    Excel 2007 workbooks and subsequent versions are Open Office XML. You need to consider using that to advantage. Here are links to content that may explain how to design and build the product:

    *. Office 2007 implements Open XML file format; you can utilize this to generate Office files on the server side. 

    *. You can use content controls along with custom xml parts to create a document or template. Content Controls are bound to elements in the custom xml.

    An Office Client can fill out a Server-side generated XML document and upload it to a server. An Office 2007 document is a zip file, If you rename any .docx/.xlsx to .zip, when you extract its contents you can easily see the contents of it as XML. Office XML files are converted to documents using .Net 3.5 Packaging class. On the server, we can access the custom XML data and fetch the information.

    Here are links that can help you out.

    This is an 'Index' to content sorted by Microsoft Product
    How Do I ... in 2007 Office System Programs
    http://msdn2.microsoft.com/en-us/office/bb410137.aspx

    The next three are links to 3 webcasts:
    Office Open XML Content Controls and Repeating Data (Part 1 of 3)
    http://www.microsoft.com/uk/msdn/screencasts/screencast/261/Office-Open-XML-Content-Controls-and-Repeating-Data-Part-1-of-3.aspx

    Office Open XML Content Controls and Repeating Data (Part 2 of 3)
    http://www.microsoft.com/uk/msdn/screencasts/screencast/259/Office-Open-XML-Content-Controls-and-Repeating-Data-Part-2-of-3.aspx

    Office Open XML Content Controls and Repeating Data (Part 3 of 3)
    http://www.microsoft.com/uk/msdn/screencasts/screencast/260/Office-Open-XML-Content-Controls-and-Repeating-Data-Part-3-of-3.aspx


    The following are links to readable media:
    ================================================
    How to use components of the .NET Framework 3.0 to create and then to stream an Office Word 2007 document and an Office Excel 2007
    workbook to a client computer 
    http://support.microsoft.com/kb/932921
     
    How to use the Office XML file format and the packaging components from the .NET Framework 3.0 to create a simple Excel 2007
    workbook or a simple Word 2007 document
    http://support.microsoft.com/kb/931866

    Introducing the Office (2007) Open XML File Formats
    http://msdn2.microsoft.com/en-us/library/ms406049.aspx

    2007 Office System Sample: Open XML File Format Code Snippets for Visual Studio 2005
    http://www.microsoft.com/downloads/details.aspx?familyid=8d46c01f-e3f6-4069-869d-90b8b096b556&displaylang=en

    Building Server-Side Document Generation Solutions Using the Open XML Object Model (Part 1 of 2)
     http://msdn2.microsoft.com/en-us/library/bb735940.aspx

    Building Server-Side Document Generation Solutions Using the Open XML Object Model (Part 2 of 2)
     http://msdn2.microsoft.com/en-us/library/bb735939.aspx

    Open XML Developer Workshop
    http://msdn.microsoft.com/en-us/office/bb738430.aspx

    Thursday, June 25, 2009 10:17 PM

  • Nice work, Ogawa.  :)

    This does the trick.  Instead of fooling the system with a registry hack into pointing the path to a valid user profile path, it was a simpler solution to merely provide the needed directories inside the system profile's path.  I did this too before in 64bit but it didn't work because I was pointing to the wrong path!  I was using system32 when I should have used SysWOW64!

    Cheers!
    Monday, June 29, 2009 7:37 AM
  • Nice work, Ogawa.  ,)

    From early one I thought it must be something related to the eco system ( folders etc ). Thanks for solving my automation problems too. It's been a while since a solution that easy solved all the problems in one pass ,)

    Thanks

    Chris
    Chris Richner http://www.raccoom.net
    Monday, June 29, 2009 12:16 PM
  • Hi Sunando,

    thanks for pointing us towards the Open XML Format SDK 2.0. I'm using it for a scenario where I just have to create simple spreadsheet files.

    The current scenario that drove this forum thread wouldn't be solved with SpreadSheetML because we're making heavy use of the calc engine/macros  in excel. AFAIK the SpreadSheetML dos not run macros etc without any full fledge excel installation, right?

    greetz

    Chris Richner

    Chris Richner http://www.raccoom.net
    Monday, June 29, 2009 12:29 PM
  • Hi everyone.


    I've also explored that area and Office Open XML fulfills most of the requirements we need in developing our application.

    However, as Chris mentioned, it lacks the ability to refresh the value of a cell with a formula. (http://openxmldeveloper.org/forums/thread/4561.aspx) Unless it is opened in Excel, the calculated values don't get evaluated.  Plus, it must be done on the server especially if your workbook contains Data Connections which are only accessible from the server. 

    Unless the ability to refresh or re-evaluate Formulas and populate cells from Data Connections are available in Office Open XML SDK, it is not sufficient for our purposes. :(
    Tuesday, June 30, 2009 7:44 AM
  • Ok, would just like to add that this actually solves the exact same problem with Microsoft PowerPoint as well. Perhaps not surprising but it had to be checked and it was the problem I was having.

    Thanks again,
    Christer
    Christer Ogenstad @ http://www.slideexecutive.com
    Monday, July 27, 2009 10:06 PM
  • Thanks Ogawa, this worked for me too!
    Wednesday, August 19, 2009 8:07 AM
  • Hi Ogawa,

    I am having Windows 2008 Server 64 bit OS installed in one of my server and having IIS 7. The automated excel object able to launch and write files to disk but fails when to open an existing file. The same problem mentioned above in this thread.

    I already tried the way mentioned by you but its not working for me. I also changed the Component service using dcomcnfg.exe, but have no luck in resolving it.

    In registry (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList\) I am having following value for ProfileImagePath key of diffrent profiles

    S-1-5-18  : %systemroot%\system32\config\systemprofile
    S-1-5-19 : %SystemRoot%\ServiceProfiles\LocalService
    S-1-5-19 : %SystemRoot%\ServiceProfiles\NetworkService
    S-1-5-21-4011298500-3012070146-3032416786-500 : C:\Users\Administrator

    Can you please let me know if I am doing something wrong or I have to do some other things.



    Thanks & Regards,
    Sunil
    Sunil Rathore Software Engineer,Encodex Technologies,(India) http://www.encodexindia.com
    Thursday, September 03, 2009 6:29 AM
  • Similar problem occurs and same solution works for Word 2007 automated in WCF service and hosted with Windows Serice or IIS on Windows 7 x64 (dev machine) and Server 2008 x64
    Friday, September 04, 2009 4:06 PM
  • Hi Sunil,

    I have no reliable evidence, but please check the permissions of the Desktop folder.

    The Desktop folder needs to be set write permission.

    In my case, when automation user (Windows Service User or someone)  has
    no write permission of the Desktop folder, same problem occurs.

    I wish you good luck!


    Monday, September 07, 2009 6:28 AM
  • I'm in the same boat, sort of.

    Do yourself a favor and check out http://www.spreadsheetgear.com who provide an excel compatible calculation engine that can read/calc/save excel 95-2007 workbooks. 

    The one thing it can't do is run VBA macros, so if your calcs rely on those, you're kind of stuck with excel.

    If not, it may provide you with a much better platform to base service oriented excel calculation on.

    I don't work for them, but I am a customer.

    hope that helps.

    roger

    roger reynolds
    Wednesday, September 30, 2009 1:03 AM
  • Just to be fair:  You can also use/buy the Microsoft supplied solution server side solution "Excel Services 2007" now integrated in the product Microsoft Office Sharepoint Server.
    Chris Richner http://www.raccoom.net
    Wednesday, September 30, 2009 7:33 AM
  • Thank you very much Ogawa San.  your solution worked for me. I was getting COMException when I try to open the excel template. 
    Monday, October 05, 2009 1:24 AM
  • OMG, Thank you SO MUCH for finding this really odd solution. I've been banging my head against the wall for 4 hours trying to figure out why our application (which worked fine on Win2003) was not working on our new Win2008 x64 box. The issue I was having was with Word 2007, I would do  application.Documents.Open(filepath) and it would act as if it worked, but return NULL instead of a handle to the WordDocument object. I could run the code just fine if I logged into the server and ran a test application which wrapped the same exact code. It would only fail when the code was wrapped inside of a Windows service. I suspect our Excel stuff would've failed too. I added the folder (C:\Windows\SysWOW64\config\systemprofile\Desktop) that you suggested above and everythings works now! Thank you, Thank you!
    Thursday, October 29, 2009 9:59 PM
  • Sunil,

    You would not by any chance be running SP2? We are currently experiencing the same problem on SP2 and R2 is also dead with regards to this.

    Regards,
    Christer
    Christer Ogenstad @ http://www.slideexecutive.com
    Wednesday, November 11, 2009 11:28 AM
  • Hi,

    I was running into the same issue and
    I have investigated infomation about "registry hack".

    After all, I found another solution that changes no registry values
     and everything works on properly.

    This solution is ...

    ・Windows 2008 Server x64

      Please make this folder.

      C:\Windows\SysWOW64\config\systemprofile\Desktop

    ・Windows 2008 Server x86

      Please make this folder.

      C:\Windows\System32\config\systemprofile\Desktop

      ...instead of dcomcnfg.exe.

    This operation took away office automation problems in my system.

    A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.

    It disappears from Windows2008, Windows2003 had the folder,
    and I think it cause this error.

    I think it is safer than "registry hack".

    If you try this solution, please let me know results.

    Ogawa

    thanks Ogawa, this post help me.
    Tuesday, November 24, 2009 9:06 AM
  • I had the same problem with a "little" 3,300 line .vbs reporting script that writes the results directly into Excel.

    The code was updated to detect that it was running Excel 2007 and provide the required FileFormat for the SaveAs method. It ran OK under a user on Windows Server 2008/Office 2007, but failed when run under the Windows Server 2008 Task Scheduler.

    The SaveAs method returned Error Level = 1004 :SaveAs method of Workbook class failed. The strange thing was the SaveCopyAs method worked fine!

    Creating the C:\Windows\System32\config\systemprofile\Desktop solved the problem.





    Wednesday, December 02, 2009 12:14 AM
  • Hi all,

    I face pretty much the same problem, with that difference that it's not a service that needs to work with an Excel file, but a web application (IIS7).

    Obviously creating the C:\Windows\SysWOW64\config\systemprofile\Desktop directory does not do the trick.

    The specifics I'm working with:
    - Windows Server2008 x64
    - Excel 2007
    - IIS7

    Any thoughts?

    Thanks and regards,
    Fred
    Thursday, December 10, 2009 12:34 PM
  • Thank you H Ogawa. Upon creating this folder

        C:\Windows\SysWOW64\config\systemprofile\Desktop

    on my Windows 2008 Server x64, the scheduled task (which runs Excel in invisible mode) now works. Thanks again !
    Friday, December 18, 2009 7:05 PM
  • I still had problems in running VBS scripts that create and save an Excel workbook when the script was run under the Windows Server  2008 Task Scheduler by an account that was not a member of the Administrators local group.

    To determine the root cause of the Excel SaveAs problems, I created a simple script to create a Excel workbook and call the SaveAs method. The test script ran OK in the foreground when run with administrative priveleges, but failed when run via the Task Scheduler with an unpriveleged domain service account. I enabled Failure auditing for the domain service account on the test servers System32 Folder and all of the subfolders.

    The test script was then run under the task scheduler. After each run I checked the security log for failure audit entries. I then granted the domain service account and the minimum rights to each folder that it was trying to access.
    For example, the account needs the right to read the Desktop folder - that's why creating the missing Desktop folder trick works for a priveleged account. Other examples is write to:

    C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.MSO\mso984F.tmp

    C:\Windows\System32\config\systemprofile\AppData\Roaming\Microsoft\Office\Recent

    After a number of runs and changes to permissions, the script ran OK under the task scheduler. After reviewing the security requirements, the security changes for the domain service account were removed and replaced using the following procedure.

    ===========================================================================

    A simple vbs script to create and save an Excel spreadsheet run by the task scheduler with an account that is not a member of the Administrators local group will result in error 1004 –

    “Microsoft Office Excel cannot open or save any more documents because there is not enough available memory or disk space.

    • To make more memory available, close workbooks or programs you no longer need.

    • To free disk space, delete files you no longer need from the disk you are saving to.”

    The problems are related to the permissions on the folders under the C:\Windows\System32\config\systemprofile and the missing C:\Windows\System32\config\systemprofile\Desktop folder on Windows Server 2008.

    To run a .vbs script that uses Excel under the 2008 task scheduler, make the following changes.

    1.       On the server, create a local group called “Script Operators”.

    2.       Create a domain service account to be used to run the script in the Task Scheduler and add it to the server’s “Script Operators” local group.

    3.       Assign “Script Operators” the required rights to the scripts folders, generally change permissions.

    4.       Create the missing C:\Windows\System32\config\systemprofile\Desktop folder.

    5.       Assign the “Script Operators”  group the following rights.

    Folder

    Permission

    C:\Windows\System32\config\systemprofile\Desktop

    Read & Execute, List folder contents, Read

    C:\Windows\System32\config\systemprofile\AppData\Roaming\Microsoft

    Modify, Read & Execute, List Folder Content, Read, Write

    C:\Windows\System32\config\systemprofile\AppData\Local\Microsoft

    Modify, Read & Execute, List Folder Content, Read, Write

     



    Thursday, December 24, 2009 12:14 AM
  • I'm using Windows Server 2008 x64 with Office 2007.

    The creation of the Desktop folder solved the problem for Word and Powerpoint but no dice for excel. The excel.exe process got started but it just stays stuck.

    Something I found interesting is when I changed the registry (HLM\software\microsoft\windows nt\currentversion\profilelist\s-1-5-18\profileimagepath) to point to C:\Users\-Myself- instead of the default %systemroot%\system32\config\systemprofile, it works for me! and noone else. That is probably the user profile is only accessible for me.

    Any thoughts?
    Tuesday, December 29, 2009 8:25 PM
  • Just an FYI, but on my Windows 7 dev machine I was having the same error (file not found, unable to access, etc) while attempting to gen a report from an XLT under IIS 7.5  (had already granted permissions under dcomcnfg).  Creating the system32 and syswow64 folder trees (needed only desktop) immediately fixed the error.

    Great news since I have 20 or so reports that rely on these interops and I really didn't want to rewrite 20k+ lines of code into OpenXML.

    If you are starting from scratch however, I would recommend OpenXML so you don't have the hassles these interops present especially on the server-side.

    -Dustin
    tanfplus.com
    Thursday, December 31, 2009 9:55 PM
  • Hi Ogawa

    Thank you very much for this solution. Its woks fine. I work on Windows 7 / 64 Bit.

    C:\Windows\SysWOW64\config\systemprofile\Desktop


    Best Wishes


    Lubos Pribela
    Friday, January 08, 2010 6:06 AM
  • RogerDoger

    Genius approach. How do you Enable Failure Auditing I wonder?

    My Scenario is a VB6 program that automates Word 2007 and SaveAs is failing with "locked down" users.

    I am seeing SaveAs fail on a customer site when end users are logged in - but it does not fail for the IT Administrator.

    I have been through the DCOMCNFG route to make the Microsoft Document 93-2007 (whatever!) run as if administrator was using it - no joy.  

    But maybe its the folders required do not exist or permissions - but I would have thought changing the options in dcomcnfg would change that.

    Your post has set me off in another direction to ask the end user IT people to check the rights to the folders you mention.

    But any URL on a step by step guide on Enable Failure Auditing would be great.

    (I have seen frustrated posts from other developers who can not get scripts to run in secured end user environments - this is going to really cheer them up if we can find the config options for whats needed)

    Interestingly the VB .NET Office Automation example on http://msdn.microsoft.com/en-us/library/bb407305(VS.80).aspx did work on the locked down user.  Maybe going through .NET runtime sorts something out on the way privelage wise.




    Thursday, January 28, 2010 8:59 PM
  • Hi Ogawa,

    Your solution worked for me. The call to open a .doc file was returning without any error but the returned pointer to the document was NULL. I tried your solution for a x86 Windows 2008 Server and it worked perfectly. Thanks a lot!
    Tuesday, February 02, 2010 12:05 AM
  • GOOD DAY!

    MR OGAWA,

    THANKS FOR THE SOLUTION. IT REALLY WORK IN SIMPLER WAY. I DON'T HAVE TO DO MY CONFIGURATION IN IIS
    Wednesday, February 17, 2010 5:55 AM
  • Hello
    OWAGA's solution solves the problem. thanks.
    Has one found a proper fix to this?
    I also use Office 2007 in Windows 2008 R2 64 bit.

    Thanks
    Palani
    Palani
    Wednesday, February 24, 2010 6:48 AM
  • H Ogawa wrote:

    ・Windows 2008 Server x64

      Please make this folder.

      C:\Windows\SysWOW64\config\systemprofile\Desktop

    A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.

    Man, you've just saved my day! Thanks a lot! :)
    Thursday, February 25, 2010 12:25 PM
  • Hi Ogawa,

    I am having some related issue with

    Microsoft.Office.Interop.Excel.ApplicationClass excel = new Microsoft.Office.Interop.Excel.ApplicationClass();

    system is redirecting me to login page when it comes to above line. I gave permissions to Microsoft.Excel.Application in "DCOMCNFG" also. I have server 2008 and IIS 7.0

    But when i deployed the same thing on my local which is windows 7 it is giving not enough space problem. In my code iam not reading any existing file i want to generate a excel file when user clicks on a button and system need not to save it shud give that as download like (Open,Save).

    Can you please help me , I am in need of this solution very badly.

    Thanks in adance.

    Monday, March 22, 2010 10:35 AM
  • I hope i am not coming too late. I had the exact same proble windows 2003 iis 6 exel 2007 Everything is fine --->windows 2008 x64 excel 2007 Hudge disaster. I had a persistence dcom error in the system event log stating that i did not provide loacal activation rights to the network service for DCOM with CLSID {XXXXXXXXX}. But i gave to the Netework Service full rights  for Microsoft Excel Application !!!

    I was hitting my head againtst the wall for 2 days now. Searched everything. Tried the solution that is stated here (the one with the folder) Nothing...  So I went to My computer in component services and i provided to my computer full rights to every one (computers->>my computer-->right click -->properties-->com security-->both edit defaults and you know the rest. It is working!!! (Of coursee i m not telling you the ip of my server since this is a great security leak!!:))

    So my guess is that Microsoft Excel Application is not the correct DCOM component i should provide rights for. In fact it has different CLSID than the one in the event log error.

    So if anyone could please help me find out which DCOM component should I give rights to???


    Life is short! So i still have 59 years of life
    Monday, March 29, 2010 6:38 PM
  • Wonderful, many thanks Ogawa! I solved my issues with Publisher automation on win 7. I wonder how you came out with this!!!
    Friday, April 09, 2010 4:24 PM
  • 1000xThx!!!! Ogawa, you are savior!!!!
    MCSA MCITP
    Thursday, April 15, 2010 7:54 AM
  • Ogawa, I can't thank you enough for posting this answer. After 4 frustrating days with this issue, changing permissions on every single file I could think of, creating the missing folder was the exact answer. Laughably simple.
    Tyler Robbins
    Monday, April 26, 2010 12:57 PM
  • I had the exact same issue that Ogawa's solution addresses... but for some reason, the creation of C:\Windows\SysWOW64\config\systemprofile\Desktop and even setting permissions on that folder, did not fix the issue for me.  I'm on Windows 7 x64.  Running FILEMON.exe I noticed there were ACCESS DENIED results coming from other CreateFile calls under C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming.

     

    I was able to get it to work by granting NETWORK SERVICE permissions to the entire C:\Windows\SysWOW64\config\systemprofile\ tree. 

     

    Thanks for pointing me in the right direction!

    Monday, April 26, 2010 2:14 PM
  • Thank you Ogawa! I was having problems with office 2007 automation on server 2008 x64 and your solution saved the day
    Friday, April 30, 2010 12:57 AM
  • Thank you Ogawa!!! Your solution solve my problem in office automation...
    Wednesday, May 19, 2010 10:41 AM
  • Ogawa you are my hero!!!

    I make the folder Desktop in SysWOW64 in my WS2008 64 bits and the application works fine, but for activate the DCOM I need use the LocalSystem user in the applicationPool, because in the "Application Services" console only appears the "Microsoft Excel Application" ({00020812-0000-0000-C000-000000000046}) and not "Microsoft Office Excel Application" ({00024500-0000-0000-C000-000000000046}" with load is my problem...

    Thank you

    Friday, May 28, 2010 9:29 AM
  • Thank you so much M. Ogawa, it worked well for me, on a x64 with Word 2007 automation.

    Nico
    Tuesday, June 08, 2010 1:26 PM
  • Thats a fantastic fix..I am sure hundreds of developers should have felt relieved like me, on going through this solution, implementing it worked out magically..Cheers..

    Thanks a lot for the efforts.

    I was on Excel 2003, VB6, Com+, IIS7, classic ASP and Windows 2008 x64..

    Franklin

    • Proposed as answer by FranklinIssac Tuesday, June 22, 2010 5:16 PM
    • Unproposed as answer by Chris Richner Thursday, June 24, 2010 6:51 AM
    Tuesday, June 22, 2010 5:15 PM
  • Many Thanks! This helped out in a pinch.

     

    Ravi.

    Friday, June 25, 2010 3:18 PM
  • I have a question Ogawa.  It's my understanding the the %windir%\system32\config\systemprofile directory is used for the local system account.  I have a service that is running as a specific domain user that is an Administrator on the machine; however, the service could not perform automation tasks in Excel.  Once I added the Desktop folder like you suggested above, the automation tasks worked fine.  Why would this folder matter if the service wasn't running as the local system account?

    Kyjan

    Thursday, July 01, 2010 9:00 PM
  • Hi Kyjan,
     
    I think angerico's post serves as a reference for your question.
     
     
    Whether you use local user or domain user, the Excel object uses Local System profile.
     
    I found out my solution by the difference between the Local System ProfileImagePath's contents and the Local Users ProfileImagePath's contents.
    (I replaced "system32" with "SysWOW64".)
     
    I owe my solution to angerico's post. Thank you angerico.
     
    But,I'm sorry I don't know why the Excel object uses Local System profile.
     
    I would like to know the reason too.
    Friday, July 02, 2010 9:28 AM
  • As a follow-up to this - Ogawa's solution holds true for Excel 2010.

    I had created the directory in SysWOW64 when I was using Excel 2007.  Just upgraded to Excel 2010 (64bit) on my Win7 x64 OS, suddenly I am getting this error again.  Obviously, Excel 2010 64bit does not need to run in SysWOW64.  I created the directories mentioned here in the System32 folder, and viola it started working right again!

    Thanks again Ogawa!

    Tuesday, July 06, 2010 4:15 PM
  • Thanks ogawa  ... It worked Excel 2010 / Windows 2008 R2 / VS 2010

     

    I use this for generating automatic print reports  => the stuff  sumukher-msft wrote is not valid, .. because we have a couple of excel plugins on which data the print out is based.

    Tuesday, July 13, 2010 2:56 PM
  • Excellent, really dug me out of a hole that I've been trying to work around these last few days.
    Friday, July 16, 2010 2:59 PM
  • hi,

    I have same problem faced..with asp.net running application on IIS configured machine.

    so have you got the solution if yes then pls send me the solution ..

     


    markand
    Friday, July 23, 2010 7:08 AM
  • Hi,

    I was running into the same issue and
    I have investigated infomation about "registry hack".

    After all, I found another solution that changes no registry values
     and everything works on properly.

    This solution is ...

    ・Windows 2008 Server x64

      Please make this folder.

      C:\Windows\SysWOW64\config\systemprofile\Desktop

    ・Windows 2008 Server x86

      Please make this folder.

      C:\Windows\System32\config\systemprofile\Desktop

      ...instead of dcomcnfg.exe.

    This operation took away office automation problems in my system.

    A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.

    It disappears from Windows2008, Windows2003 had the folder,
    and I think it cause this error.

    I think it is safer than "registry hack".

    If you try this solution, please let me know results.

    Ogawa


    Worked for me. Thank you very much!
    Monday, August 09, 2010 10:42 PM
  • Hi,

    I was running into the same issue and
    I have investigated infomation about "registry hack".

    After all, I found another solution that changes no registry values
     and everything works on properly.

    This solution is ...

    ・Windows 2008 Server x64

      Please make this folder.

      C:\Windows\SysWOW64\config\systemprofile\Desktop

    ・Windows 2008 Server x86

      Please make this folder.

      C:\Windows\System32\config\systemprofile\Desktop

      ...instead of dcomcnfg.exe.

    This operation took away office automation problems in my system.

    A Desktop folder seems to be necessary in the systemprofile folder to open file by Excel.

    It disappears from Windows2008, Windows2003 had the folder,
    and I think it cause this error.

    I think it is safer than "registry hack".

    If you try this solution, please let me know results.

    Ogawa


    Worked for me. Thank you very much!

    Worked for me too!! Thank you.
    Thursday, August 12, 2010 7:35 AM
  • Hi Chris Richner

     

     Did you found a solution found issue? I also got the same issue . Can you please help me to solve issue.

     

    Thanks

    Chamath Jeevan (http://www.facebook.com/#!/profile.php?id=669044392)

    Sunday, August 15, 2010 6:45 AM
  •  worked for me... thanks.
    Monday, August 16, 2010 2:24 PM