Understanding how to create effective queries using the Microsoft Graph APIs takes some work, especially with some of the more complex filters used to refine the data returned by the Graph. In this article, we look at how filters using lambda qualifiers work and explore some examples of these qualifiers in use.
Microsoft has replaced the controls which disabled document insights in Delve with new Graph-based settings. However, you might still have a bunch of users with the Delve settings who need to migrate to the Graph settings. In this article, we explore how the settings work and how to query the Graph to find the set of users who disabled the setting in Delve. We can then use PowerShell to add those accounts to the group of disabled insights users for the Graph-based settings.
Many PowerShell scripts which access Office 365 data could do with a speed boost. Replacing cmdlets with Microsoft Graph API calls is one way to get extra speed. In this article, we take a PowerShell script to report the memberships users have of Microsoft 365 groups and replace some important cmdlets with Graph API calls. The result is a big speed increase.
The preview of a new app governance add-on for Microsoft Client App Security gives Office 365 administrators insight into Graph-based apps. The add-on depends on information gathered from Azure AD and MCAS to generate insights about apps and their usage, including highlighting apps which are overprivileged or highly privileged. Although you can do some of the auditing yourself, the add-on makes it easier. It’s a preview, so some glitches are present.
The thoughts of using Microsoft Graph API calls with PowerShell might seem to be too much trouble, but used correctly, Graph API calls help scripts speed up and get to some data that is not reachable through a cmdlet. I have a simple four-step approach that I use to figure out if I need to include some Graph API calls. The routine works for me. Feel free to disagree.
Office 365 will see a batch of delayed features arrive during July 2021 along with two notable retirements and a new Personal Item Insights control. After going through the set of delayed features announced in the Microsoft 365 admin center, we share our list of the most important items here along with the two big retirements in the month and a new personal privacy control.
Sometimes it’s wise to give PowerShell scripts a turbo boost. This is certainly true for the Groups and Teams Activity report script, where a large amount of PowerShell processing has been replaced with speedy Microsoft Graph API calls. The result is much faster processing, which means that the script is more useful in large tenants. I still wouldn’t try to run it against 100,000 groups, but anything smaller should be OK. I think!
Anyone writing PowerShell code against Azure Active Directory probably uses the Azure AD module. In June 2022, Microsoft will deprecate the API underpinning the Azure AD module. Tenants who want to use PowerShell to create scripts to automate administrative processes will need to move to Graph API calls or use the Microsoft Graph PowerShell SDK. Either way, there’s a bunch of work to do to upgrade scripts.
The data used for Microsoft 365 usage reports comes from the Microsoft Graph. You can anonymize the data to replace references to user, group, and site names with system-generated values to protect user privacy. This works, but it reduces the usefulness of the reports by a large degree, so you should be prepared to switch to show full user data sometimes.
The latest update for the Teams admin center includes the ability to manage the permissions used by third-party apps to access data via the Microsoft Graph. The updates also include the ability to manage resource specific consent (RSC) for Teams apps. While third-party apps ate the obvious target, LOB apps created by tenants are managed in the same way.
PowerShell hash tables are very efficient at retrieving data, which is just what’s needed when thousands of Office 365 accounts need processing. Our script to analyze usage data extracted from the Microsoft Graph was turbo-charged when we replaced list objects with hash tables, all of which makes it much easier to identify underused Office 365 accounts and save some money on licensing spend.
Office 365 usage data for several workloads is available through the Microsoft Graph. A PowerShell script is available to grab Graph data and use it to figure out if accounts are in active use. V1.2 of GetGraphUserStatisticsReport.PS1 is available in GitHub and should be better performing when processing thousands of accounts.
It’s easy to retrieve storage data for SharePoint Online sites with PowerShell, but it’s faster with the Graph. Some disadvantages do exist, but it’s nice to have a choice. TheGraph is faster, especially with large tenants, but the SharePoint Online PowerShell cmdlets can deliver more data.
Writing code to illustrate a point sometimes falls into the trap that things don’t work so well when you scale things up. Take Graph calls for instance. Code that works well with 100 teams isn’t so good with 4,000. The solution is to keep on telling the Graph to fetch data until it’s all in the safe hands of PowerShell, and then process it.
The Microsoft Graph gives programmers a RESTful interface to Office 365 data. Flow allows even non-programmers to automate tasks by combining building blocks of Office 365 data and actions. Put the two together and you can generate some impressive results. In this example, we combine Graph and Flow to create some nagging emails to admins to encourage them to improve the tenant’s Secure Score.
The Microsoft Graph developers and some other folks inside Microsoft have launched a new series of short blog posts to help people become acquainted with the Graph. It’s a nice idea, and one that’s worthwhile to read.