Powershell cannot create Outlook COM object from Command Prompt
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 same from classic Windows Command prompt (cmd.exe) even with Admin privileges, it was unable to create Outlook COM object. Here is the line to create COM object:
$objOutLook = New-Object -com Outlook.Application
This is how I call my script from cmd.exe (Administrative privileges) :
D:>powershell D:\MiscBuildTasks.ps1 -sendmail -MailTo 'farrukh@MyMail.com'
and here is the error log:
New-Object : Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)). At D:\MiscBuildTasks.ps1:81 char:12 + $Outlook = New-Object -ComObject Outlook.Application + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : ResourceUnavailable: (:) [New-Object], COMException + FullyQualifiedErrorId : NoCOMClassIdentified,Microsoft.PowerShell.Commands.NewObjectCommand
How can I make it work from cmd.exe (Windows Command Prompt)?? Thanks
Farrukh Waheed4 Answers
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.
Dmitry Streblechenko • edited Nov 16, 2018 by Dmitry StreblechenkoI had the same issue, I figured out it was a combination of 3 things.
- Running with the correct privilege level (admin)
- Using the same arch (32-bit vs 64-bit) for outlook and powershell
- Closing Outlook, since the script will open it.
gryphon
NeuronThe 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.
Eugene AstafievIf 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.
Steven BuehlerUser contributions licensed under CC BY-SA 3.0