Back in the old days of IT, when foundational infrastructure consisted of on-premise components such as servers, desktops, laptops, switches, firewalls, and the associated software, VMware, Active Directory, SQL, Exchange, SharePoint, File and Print, etc., lazy guys like me learned how to access and automate tasks using technologies such as VBScript, WMI, ADO, ADSI, DCOM. When PowerShell arrived much of the underlying technology was obfuscated in cmdlets, modules and the .NET framework. As an Infrastructure admin I still use all of these technologies to this day.
As IT infrastructure began the migration to the cloud, be that Software as a Service (SaaS), Platform as a Service (PaaS), or Infrastructure as a Service (IaaS), some of this legacy technology became less relevant. While the various development teams in Microsoft generally provided PowerShell modules to access the various systems, there wasn’t a standardized overarching way to programmatically access the M365 suite of products. Enter Microsoft Graph.
To quote Microsoft:
Microsoft Graph is the gateway to data and intelligence in Microsoft 365. It provides a unified programmability model that you can use to access the tremendous amount of data in Microsoft 365, Windows, and Enterprise Mobility + Security. Use the wealth of data in Microsoft Graph to build apps for organizations and consumers that interact with millions of users.
I don’t want to turn this post into a history of MS Graph so for those who would like to know more here is a link: Overview of Microsoft Graph - Microsoft Graph | Microsoft Docs
Given how powerful MS Graph is, and that this is Microsoft’s intended standard moving forward, it is important for any self-respecting IT administrator to familiarize themselves with this technology.
In this multi-part series, I’ll provide step-by-step guidance for anyone just starting out to get up and running quickly for accessing M365 programmatically via MS Graph, be that through PowerShell, Azure Logic Apps, etc.
In Part 1, we will cover setting up the API.
Part 1 - Setting up the API
Unlike interactively accessing MS Graph via a web browser, when you programmatically access it there needs to be an API to point your script/app to. To do this, an API needs to be registered.
In Azure AD, navigate to App Registrations blade:
Select New Registration:
Enter a descriptive name, determine who should have access, and press Register.
Who can use this application is determined by what your script, app will eventually do with the API. For example, if you’re creating an internal business process or automation, “Accounts in this organization directory only” is sufficient.
If you’re creating a B2B solution, then Multitenant may be appropriate. Similarly, if you’re creating a B2C solution, you can include personal accounts.
If you’re not familiar with MS Graph yet, and are just starting out for testing purposes, Single tenant is likely the most appropriate starting point.
After the App Registration is created you will be redirected to the Overview page.