I have a script used to send mails via Microsoft Outlook from command prompt. This works fine if I run it from inside PowerShell or ISE console. But when I tried to execute
CO_E_SERVER_EXEC_FAILURE
in case of Outlook means the calling app and the COM server are running in different security contexts. If the command prompt is running with elevated privileges, either make sure Outlook is started with elevated privileges as well or that it does not run at all when your code is executed - this way Outlook will be started by your code and it will run with the same elevated privileges.
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.
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.
If your installation of Outlook is 32-bit, make sure you are using the 32-bit version of PowerShell (x86) and not the 64-bit one.
I had the same issue, I figured out it was a combination of 3 things.