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
Directory.Read.All AppRoleAssignment.ReadWrite.All The script $objectID = "<ObjectID of the Managed Identity>" $ServicePrincipal = Get-MgServicePrincipal -Filter "AppId eq '00000003-0000-0000-c000-000000000000'" $approle = $ServicePrincipal.
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
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
[slideshare id=151347967&doc=20190622-usingautomationinoffice365-190623120657]
Some time ago I got the question if it was possible to start using AAD Connect while some of the users are already in Office 365 with a cloud account without losing their content and access. So this was a first that I had this question and found myself searching on the internet and found an article from Microsoft that this was possible. https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-existing-tenant
This article describes that you can start syncing an on-premises AD with Azure AD when you already have users in Azure AD.
In this post, I want to take you with me how you can use app credentials in an Azure Automation script to connect to SharePoint Online. Many PowerShell scripts use a username and password, but these are less secure than using an app credential and can also be used to login to SharePoint Online in the browser. By default, connecting to SharePoint uses basic authentication and many companies are on route to disable this to make use of conditional Access and MFA.
A common situation in SharePoint is adding custom properties to a SharePoint profile. In an on-premises environment, it was very easy to link these properties to a property in AD. In SharePoint Online, you are not able to link these Azure AD properties. So how can we solve this?
There is a very simple solution for this in the Office Dev PnP PowerShell pack called ‘Set-PnPProfileProperty’.
This command sets any user profile property for the given user.
This week I did a presentation at DIWUG about how to use Azure Automation in combination with Office 365
I told about the possibilities of Azure Automation, what you can do with it in general and then zoomed in on specific tasks within Office 365 like setting the useslocation of your users. When you need a Hybrid configuration and how you can use version control with your scripts.
[slideshare id=83741543&doc=20170518-watkanazureautomationbiedenvooroffice365klanten-171209194336]
Last week I found out that the account name that you use in Azure automation are case-sensitive. We found this after a co-worker was adding a credential to the credentials assets. I had used some capital letters to read the account name a bit better in our local AD and my co-worker just wrote them down with small letters. He came back to me asking if the password was correct because the credentials did not work.