'Logging into Outlook using powershell with no user logged on

I was wondering if its possible to create a powershell script to log into a specific outlook mail box and than add the script to the scheduled task so that no user has to be logged on.

emailpowershelloutlookautomationscheduled-tasks


Solution 1:[1]

If you need to open an arbitrary Exchange mailbox, you can either

  1. Use Outlook Object Model (which cannot be used in a service, such as the Scheduler) to log to a predefined profile (Namespace.Logon) and call Namespace.GetSharedDefaultFolder. If the set of mailboxes is always the same, you can add these static mailboxes to the profile (open them as delegate mailboxes) and access them programmatically using the Namespace.Stores collection. Again, Outlook should not be used in a service/scheduler.

  2. Exchange Web Services - it is HTTP based, so you can use it from a service

  3. Graph - just like EWS, it is HTTP based, so you can use it from a service

  4. Extended MAPI (C++ or Delphi only). native API used by Outlook itself. It can be used in a service.

  5. Redemption (I am its author - it wraps Extended MAPI and can be used in any language from a service). It lets you dynamically log to an Exchange mailbox using RDOSession.LogonExchangeMailbox / LogonExchangeHostedMailbox (no existing profile required). Other mailboxes can be opened using RDOSession.GetSharedMailbox.

Solution 2:[2]

Yes, you can log on to a specific user profile programmatically. The Logon method of the Namespace class logs the user on to MAPI, obtaining a MAPI session.

Be aware, 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. You can read more about that in the Considerations for server-side Automation of Office article.

Instead, you may consider using a low level API on which Outlook is built - Extended MAPI. Or use any third-party wrappers around that API.

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1
Solution 2 Eugene Astafiev

Related Questions