Lately, I have been working on some self-service tooling so that the employees can do specific tasks themselves, like updating members of a Shared Mailbox instead of creating a ticket and asking IT to do this. To build this solution, we have developed an Azure Function with API management as the back-end and a PowerApp as the front-end.
Our team uses PowerShell a lot, and the easiest way to communicate with Exchange Online is using PowerShell.
Assigning permissions to a Managed Identity is more complex than an app registration; the only way is thru PowerShell or Microsoft Graph. So this time, I created a simple script to add permissions to a Managed Identity using the Graph PowerShell modules.
Prerequisites You need two modules for this:
Microsoft.Graph.Applications Microsoft.Graph.Authentication Rights The rights that are needed to assign rights and find the correct IDs are
In PowerShell 7, I have noticed that on my machine the Progress bar was not showing by default. I found that annoying, so I searched for how to get it back; this was very easy in the end.
Reveiling it again All you have to do is add this line of code to your script
$ProgressPreference = 'Continue' Show it at the top This line will display the progress bar again; the only difference with the previous PowerShell versions is that it now shows it inline instead of at the top of the window.
In the last few weeks, I took some time to refactor most of my scripts and Azure Automation script to use the Microsoft Graph Modules over the Azure AD Module. As I explained in my previous blog, the Azure AD module is declared deprecated.
How to start updating The first thing to do of course is to install the latest Microsoft Graph Modules with:
Install-Module Microsoft.Graph Connecting to the Graph Connecting to the Microsoft Graph is almost the same as via Azure AD, except there are a few extra options
Five years ago, I wrote an article about enabling PIM roles with Powershell, and last week I took it upon myself to convert it using the Microsoft Graph PowerShell modules
Why would you move? The primary reason to start moving to the graph modules is that the AzureAD and other modules were declared deprecated last year; see this post for all the details https://techcommunity.microsoft.com/t5/microsoft-entra-azure-ad-blog/azure-ad-change-management-simplified/ba-p/2967456 The modules still work but will not get any updates anymore.
The last few weeks I had to create a few PowerShell scripts where I had to combine certain information from several sources.
The way I used to do it was to do a where-object on an ID in an array. This works well, but I noticed that on large datasets it takes a lot of time. A where-object on a dataset of 30.000 items it takes on average between 1 and 2 seconds.
This weekend I had the privilege to speak at SharePoint Saturday in Madrid. The session was about Automation in Office 365. See the slides below
Last month Microsoft announced that they enable auditing by default on every mailbox. Before this, you needed to run a script on every newly created mailbox to enable auditing for the items you wanted. Microsoft provided a script for this that can be found on GitHub.
The announcement can be found on techcommunity.
In this announcement, they say that every new mailbox gets the default set of auditing. This default set can be updated from Microsoft’s side, but when you have enabled auditing by yourself or the script, they provided it stays that way.
Collaborating with Microsoft Teams is very easy, and I’m using it at several customers. At one customer the teams are getting multi-language where before every conversation was in Dutch, now with new team members that are not speaking Dutch they have trouble going back into the conversations and do not understand what is written. Luckily Microsoft Teams now offers the ability like Skype to have translations for this.
We found that this was not enabled by default in the tenants that I worked checked.
This week I had the privilege to speak at DIWUG about securing your Office 365 environment. This time I started from a governance point of view. So what policies do we have and do we need before we can set up the security in Office 365. Also what licenses are available and do we need additional licenses to satisfy our security needs.