We have a Windows Service which runs on 2003 Server. It opens a source Word document using the Word Interop and then does some stuff with it. It also does likewise with Excel and PowerPoint files.
Recently we've tried moving this service onto a Windows 2008 Server machine and are having real problems with it.
COMException at Microsoft.Office.Interop.Excel.Workbooks.Open COMException at Microsoft.Office.Interop.Word.Documents.Open
I get the above exceptions when the windows service is running on 2008 Server. Looking at the Task Manager, the application does load ok, but then closes again shortly after.
I've read things about Vista and Server 2008 not having a Session0 anymore, and have tried changing the Office DCOM security properties accordingly, including changing the identity of the user running them to Integrated but to no avail.
Does anyone know if this is possible at all? This is a fundamental aspect of our system and so we need to be able to do this.
Thanks
Microsoft Office supports Windows Server OS - feel free to install it on your server.
Automation is the art of making software packages do a job without you having to do anything yourself, apart from pressing a button or something to start it off. You can use Microsoft Office Access, Word, Outlook, Powerpoint and Excel automation to streamline your business workflow.
Server automation consolidates task and process automation into a single solution for more efficient application deployment as well as ongoing management across virtual and physical systems.
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 ...
I've had problems automating Office from a Windows Service under Windows Server 2008, even though that works fine under Windows Server 2003. The problem also occurs at the Open call, so it may be the same problem.
I tried following the advice given by H Ogawa in this MSDN thread, and it seemed to work. It's bizarre, but kudos to Mr. Ogawa for discovering it.
Summary of the 'Ogawa Hack': create a desktop folder for the system profile, as:
C:\Windows\System32\config\systemprofile\Desktop
and, if running on a 64-bit machine, create another one, as:
C:\Windows\SysWOW64\config\systemprofile\Desktop
Also, the folder(s) need write permission for whatever user is "driving" Office.
[Edit: corrected link URL]
[Edit 2: clarified that on 64-bit Windows, you need both folders, not just the WOW64 one]
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With