In my company where we use AD infrastructure my working hours in outlook somehow change from working hours and my time-zone. I created a script that changes the time-zone, but don't know how to change the working hours in outlook.
QUESTIONS:
searching for POWER-SHELL OUTLOOK API gave no results - wanted to ask how to approach scripting the outlook application (or any other application) with powershell? What is the development process step-by-step? Is there an API defined for each application for powershell?
How does powershell interact with applications? Is there a general command-object infrastructure for all windows applications that powershell accesses?
And for the specific question: how to actually change the working hours in OUTLOOK?
Thank you?
Powershell can use any IDispatch-based libraries, including the Outlook Object Model. But OOM however does not provide any way to set those options. If using Redemption is an option (I am its author), you can use its RDOCalendarOptions object - next version of Redemption will expose RDOCalendarOptions.WorkDays/WorkDayStart/etc. properties.
Related
In our company we automated certain things for our customers:
Reporting, (counting Azure AD accounts, systems, mailboxes);
Create user (setting all permissions);
Create mailboxes;
managing tickets in ITSM;
Delete user .
We did use a lot of Powershell scripts and Azure Devops to automate these tasks. Now with the deprecation of basic authentication, we had to change our scripts and the way of authentication to all of our customers' Exchange Online. This made us think, is there a better way to set this up not to have these problems? We are already working with configfiles, modules, classes in our scripts.
What would be the best way to automate these tasks and not have the rework when Microsoft changes the authentication method?
Another question what would be a way to automate these tasks in low code?
The situation is that we make connection with the Azure Platform from our customers.
If you already work with modules and classes you should probably write a single "authentication" module/class that is then used in all of the subsequent scripts. If and when MS change the authentication method again - one only needs to change this one class that is called by every other script.
In terms of "low code" - it depends on what these tasks are doing.. but, one is able to use the Power Platform Office365 Connector and from there it is possible to query AAD. There is also the GraphAPI.
It really depends on your use case but the following link may be of some assistance with the "low code" question:
https://powerusers.microsoft.com/t5/Building-Power-Apps/Query-Active-Directory/td-p/724376
I need to configure email settings for a number of CRM online instances. I want to automate this as some of the sandbox environments will be reset periodically.
I have one instance configured manually (with our on prem exchange) so know what need to be done to get it working but I can't for the life of me seem to be able to retrieve and update the email server profile configuration. I either want to amend the default profile or create a new one.
I'm using the Microsoft.Xrm.Data.Powershell module so i'm able to retrieve entities and records but can't seem to find the specific data i'm after.
Has anybody done this before or able to point me in the right direction?
While I have never done this myself here are some ideas that might help:
The EmailServerProfile entity supports the typical CRUD messages, as well as specialized messages like GrantAccess, ModifyAccess, and RevokeAccess.
Options to run these from PowerShell would include:
Use PowerShell to make requests to the D365 WebAPI, which will require OAuth2
Install the Microsoft SDK Nuget Package(s) into PowerShell, load the appropriate assemblies, then create the .NET objects and run their methods. This post has more info on this type of approach.
This package says it allows you to "invoke any available CRM request", so that might be worth looking into.
I checked this package, which has a lot of commands, including Approve-CrmEmailAddress and Revoke-CrmEmailAddress but did not see anything pertaining to EmailServerProfile.
Here is an example of how I create a fully working hybrid profile in on premise Dynamics installation:
New-CrmRecord -EntityLogicalName emailserverprofile -Fields #{
name = "EmailProfile01"
servertype = [Microsoft.Xrm.Sdk.OptionSetValue]::new("3")
ownerid = $ownerIdReference
exchangeonlinetenantid = $CRMContextId.Guid
useautodiscover = $true
incomingcredentialretrieval = [Microsoft.Xrm.Sdk.OptionSetValue]::new("2")
}
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.
If you need to open an arbitrary Exchange mailbox, you can either
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.
Exchange Web Services - it is HTTP based, so you can use it from a service
Graph - just like EWS, it is HTTP based, so you can use it from a service
Extended MAPI (C++ or Delphi only). native API used by Outlook itself. It can be used in a service.
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.
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.
PowerShell Web Access allows you to run PowerShell cmdlets through a web browser. It shows a web based console window.
Is there any way to run cmdlets without typing them in to the console window? And is there any way to get the results back?
I'm envisaging an app that lets a non-technical user restart a print queue (for example) without having to know PowerShell. The app would display a list of print queues and then the user could select one and restart the queue. The app would essentially be a wrapper that takes care of the syntax and variables so that users don't need to know.
Is there a way to do that through PowerShell Web Access? Or is there some other way for a non Windows app to send arbitrary commands to a Windows server without reinventing the wheel?
Not with PowerShell Web Access**. That is designed for an interactive session.
There are a few ways you could do this. All examples are illustrative and may be outdated, insecure, etc.
Create an ASP.NET web application running C#. Run PowerShell in the C#. Use PowerShell remoting as needed. Example.
Create GUI applications using Windows Presentation Foundation or WinForms. Use PowerShell remoting as needed. Example.
Create a services with an API (e.g. REST) that PowerShell can hit.
** OK, I lied. Create a clunky solution that uses delegated, constrained endpoints accessed through PowerShell Web Access.
For each of the above solutions that uses PowerShell remoting, consider delegated and/or constrained endpoints. Example.
We have a web application that allows certain users to perform certain functions with certain parameters. Uses ASP.NET backed by C# with a set of predefined PowerShell scripts and configuration of who can do what stored in a SQL DB. For example...
Jane can restart application pool X on server Y.
John can restart service Z on server Q.
IT Support can unlock their own 'administrative' accounts from their standard accounts.
All of this can run from non-Windows computers. Some of it might be carefully exposed to allow use on Mobile devices : )
If you have the use cases, the small overhead of designing the system and writing the code behind it will pay off quite quickly.
Cheers!
I'm currently looking into expanding a project to include the syncing of notes and tasks from a web application with exchange/Outlook.
Though at the moment, this is only an idea.
Unfortunately for me, it's the first time I've considered doing any form of Exchange integration at all from any application.
So I'm wondering, is what I've set out to do even possible?
I'll most likely be using ASP.NET MVC 2, .NET 4 and Exchange 2003.
The old way to do it would be to use Outlook Interop to automate Outlook to get access to the data. However, this isn't the neatest way of doing things, and you almost certainly wouldn't want to do it on a server.
The new way of doing it is using Exchange Web Services, you can find an article here about it, but I'm not sure if they're supported on Exchange 2003...