Overview of issue
When automating excel using a non-interactive session as a service or windows task scheduler it failed with an exception System.Runtime.InteropServices.COMException (0x800A03EC).
This did not happen when the same task was ran from the command prompt as the same user. The stack trace showed it was when we tried to open the excel sheet Microsoft.Office.Interop.Excel.Workbooks.Open
Automating Excel like this is strictly warned against by Microsoft as it is a pain. There are so many possible issues you have to work through.
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 behaviour and/or deadlock when Office is run in this environment.
Microsoft strongly recommends that developers find alternatives to Automation of Office if they need to develop server-side solutions. Because of the limitations to Office's design, changes to Office configuration are not enough to resolve all issues. Microsoft strongly recommends a number of alternatives that do not require Office to be installed server-side, and that can perform most common tasks more efficiently and more quickly than Automation. Before you involve Office as a server-side component in your project, consider alternatives.
Considerations for server-side Automation of Office
However you may manage despite all these strong words to not do it. In our case we had some complex excel documents with complicated formatting that was populated through a datasource that was latterly removed before saving. I didn’t fancy trying that in OpenXML, also we were required to produce old xls type files for output.
WHAT TO CHECK TO GET IT WORKING
I’ve compiled a list to check off from a number of forums, forgive me for not fully referencing it all but links to some of the posts are shown at the end.
Another well presented summary that I found after writing this can be found here: Interactive Excel permissions
The final part of the puzzle was the following post: http://www.c-sharpcorner.com/uploadfile/jayendra/how-to-create-excel-file-in-Asp-Net-C-Sharp/
I had already blogged essentially the same info below, then found the above resources, I’ll keep my version, just in case those pages vanish from the web.
Add Local Launch and Local Activation permissions to the Microsoft Excel Application DCOM Config
- Stop the windows service automating excel
- From run start bar, type dcomcnfg
- in the Component Services dialog that opens navigate to console root>>computers>>MyComputer>>DCOM Config branch of the tree in the UI
- Locate “Microsoft Excel Application” and right click properties of it
- Find the Security Tab, add the user running the service and grant rights by clicking on the edit button of Launch and Activation Permissions, I granted “alllow” to Local Launch, Local Activation. Go to task manager and check no copies of excel are running in memory by end tasking any excel.exe running under all users.
- The above post says to change the Identity tab to “The Interactive User” radio button, you could try this too, although it was the permissions in my case that made things come to life.
- Restart the service automating Excel
Create the mysterious directory
Due to what is thought to be a bug/oversight, a folder is required to exist by Excel when it is ran as a service. Most people find this step solves their problem.
Create a directory “Desktop” if it does not already exist under
“C:\windows\SysWow64\config\systemprofile\Desktop” (for 64 bit operating systems)
– then grant Read & Execute, List folder contents, Read permissions to the user running the service to this folder
More permissions to set
”C:\windows\SysWow64\config\systemprofile\AppData\Local\Microsoft” (for 64 bit operating systems)
For the user running the service grant: Modify, Read & Execute, List Folder Content, Read, Write permissions to the above folders.
Obviously also check, as you normally would that the service user has read execute permissions on the executable directory of your service and any folders it needs to run.
Source post: Run Powershell script as Scheduled task, that uses Excel COM object
This goes for all services, ensure that paths do not rely on mapped drives. Translate any mapped drives into UNC paths.
N:\myfolder\ should be something like \\mynetworkserver\nfsshare\myfolder
Mapped drives may not be available to a service user.