The "Excel command" action under the hood uses COM-automation to automate Excel operations. Unfortunately, it's the only automation interface provided by Microsoft for Excel. It's very outdated and has many limitations (e.g permissions, concurrency). It has problems running under the LocalService account (which is the default account for EasyMorph Server service) as well. The LocalService account lacks some obscure permissions, hidden folders, and God knows what else that is required by COM-automation compared to a regular Windows user account. That's why the "Excel command" action can work on your Desktop, but can stop working on the Server.
What to do in this case:
If you have the Enterprise edition of EasyMorph Server, try using a separate worker that runs under a Windows user account. This option is not available for the Team edition. The Server Admin Guide explains what is a worker and how to configure one.
If running "Excel command" is crucial for your Team edition of Server, try changing to Server service account from LocalServer to a Windows user account. This is a big change that can affect folder permissions required by other tasks so make sure you understand the implications. The Server Admin Guide explains how to change the Server service account.
Don't run workflows with "Excel command" on Server. Run them in EasyMorph Launcher, if possible.
Of course, Excel must be installed on the Server for options 1 and 2 above to work.
When we designed the "Excel command" we knew about the limitations of COM-automation and we anticipated many issues with it on EasyMorph Server. Nevertheless, we've added it because it can be extremely useful despite all the issues.
FYI - One thing I noticed when working with this excel command action is that if the excel workbook has any datasets, pivot tables, queries that have Refresh Upon Opening Workbook CHECKED, bring back an error. Once I unchecked that setting on any/all datasets, pivots, queries it worked!
Also, I noticed that Recalculate workbook action only recalculates formulas and does not trigger a RefreshAll action on any datasets, which is incorrectly stated in another posting.
Given the importance of the information in this post, I’m copying it here, just in case the author decides to shut down the blog.
Stumbled upon an interesting one today, where I had a legacy application that needs to open excel to generate some excel spreadsheets. But when this happened i got the usual error:
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.
For this example the application is running under an application pool account called ExcelAppPoolAct
Obviously the first step is to grant the correct permissions in component services. To do this:
Navigation to Adminstrative Tools->Component Services->MyComputer->DCOM->Microsoft Excel Application
Right Click on Microsoft ExcelApplication and select Properties
Click the Security tab
Change Launch and Activation Permissions to Customize
Click Edit
Add ExcelAppPoolAct
Check Local Launch and Local Activation
Next we need to configure the systemprofile directory. You need to create a Desktop folder in one of the following paths, dependant on which version (32-bit or 64-bit) of Microsoft Office you are running.
Office Version
Folder
32-bit
C:\Windows\System32\config\ systemprofile|
64-bit
C:\Windows\SysWOW64\config\systemprofile|
The next step is to configure the appropriate permissions to the folders for the Application Pool account, ExcelAppPoolAct. Again the folder is dependent on your version (32-bit or 64-bit) of Microsoft Office.
