Microsoft Graph: a Practical Guide

New
Written By Hailey Phillips

Why another Graph post?

If you’ve tried working with Microsoft Graph, I can probably guess that it maybe took a bit of time to appreciate all of its capabilities. I’ve heard MS Graph described as trying to build the car that you need to use to drive to work. For some, that might be up your alley, but for the rest of us, it can be a bit daunting.

Authentication, proper permissions, pagination, incorrect query structure… these are just a few of the examples of the complexities that can come from initially looking at MS Graph. All of that complexity, I’m sure, encouraged you to instead just download the SDK. You can just get up and go, right? You probably wouldn’t be reading this post if that were the case…

 

Power of Reframe

 

Building Blocks instead of Roadblocks

Rather than seeing all of these hurdles as roadblocks, I want to encourage you to consider them instead as building blocks. Instead of just trying to make today’s script work, you’re learning:

  • How APIs behave

  • How authentication works

  • Thinking in data structures, not just outputs

These skills compound. They’re not just about “getting Graph to work.” They’re what make you faster and more confident when you move on to building larger scale automation, working with other APIs, and CI/CD.

 

Building Blocks ‧₊˚🖇️✩ ₊˚🎧⊹ ♡


Rather than just using the Microsoft Graph SDK or moving fully to Invoke-Restmethod, let’s work on the building blocks that give exposure without too much overwhelm. The best part, this is all you’ll need:

Install-Module Microsoft.Graph.Authentication
Connect-MgGraph
Invoke-MgGraphRequest

  • Microsoft.Graph.Authetication PowerShell module that handles the authentication

  • Connect-MgGraph establishes the session

  • Invoke-MgGraphRequest universal request command that hits MSGraph endpoints.

How to Start

How I like to think about writing a script to do anything in Graph is:

  1. What am I trying to do? Am I looking for a device policy, a user, a group? That’s the starting point.

  2. Find the endpoint. I’ll typically start with Graph Explorer or I’ll use Merill’s Graph Xray. If I can see the output I’m expecting in Graph Explorer, I at least know that the data is there.

  3. Bring it into PowerShell. I’ll set a variable with Invoke-MgGraphRequest and store the response.

  4. Do something with the output. Perform whatever task I’m trying to do.

Only once I’ve addressed the above steps do I think about scale. Pagination, batching, etc those are all things that absolutely matter and should be considered, but not as step one.

This approach keeps me moving forward without drowning in complexity.

Example: Grabbing a config profile

Here’s what it looks like end-to-end: from importing the module to running in VS Code.

Import-Module Microsoft.Graph.Authentication

# Connect to Graph
Connect-MgGraph -NoWelcome

# Target the beta endpoint
$graphApiVersion = "beta"
$DCP_resource = "deviceManagement/deviceConfigurations"
$name = "Skip User ESP"

# Build the URI with a filter
$uri = "https://graph.microsoft.com/$graphApiVersion/$($DCP_resource)?`$filter=displayName eq '$name'"

# Run the query
(Invoke-MgGraphRequest -Uri $uri -Method Get -OutputType PSObject).value

As you can see, relatively straightforward and something that you can build off of without needing to import the many, many, many Microsoft Graph SDK modules.

 

Closing thoughts

This was post Block 1: MSGraph authentication to getting output you can use.

In the next post, we’ll talk about how to grow this into reusable functions and why modular patterns matter. That’s also where we’ll start talking about Git and how source control and modularity set you up for larger-scale automation.

┊˚➶ ｡˚ ☁

Hailey Phillips
Next

PowerShell Terminal Setup