Microsoft Graph PowerShell SDK - Simply Explained

Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What the Microsoft Graph PowerShell SDK actually is. Microsoft retired two of the admin modules that PowerShell scripts relied on for years, and the replacement is friendlier than it sounds. That replacement is the Microsoft Graph PowerShell SDK, the same Microsoft Graph layer that sits behind a lot of the admin tools you already. Click. Welcome to the M365 FM podcast, where we explore the people, ideas, and technologies shaping the future of work. You don't need to be a developer to use it, and you don't need to memorize anything before we start. By the end, you'll know what it does, where it fits in Microsoft three. Sixty five and Azure and the mistakes that trip almost everyone up. Let's start with the plain version. The Microsoft Graph PowerShell SDK is a large set of commands you type into PowerShell window, and those commands do real Microsoft three hundred sixty five work for you? That's the whole idea. Microsoft builds it as a wrapper around something called Microsoft Graph. The commands are a friendly layer on top of an interface you never have to touch by hand. One detail makes that rapper feel less mysterious. The commands are generated straight from the Microsoft Graph interface. When Microsoft adds something new to the platform, a matching command tends to appear quickly. You're not learning a frozen tool, you're learning one that keeps pace with the service behind it. The admin center is probably what you picture for managing Microsoft three hundred sixty five, and for a single small change, it works well. The SDK earns its place when the same small change has to happen a thousand times the same way, without anyone forgetting a step. Picture adding two hundred new starters next month. Clicking through menus for every one of them eats an afternoon while a short script finishes the job before your coffee goes cold. The name is the scariest part, so it deserves taking apart. SDK stands for Software Development Kit. That sounds like it belongs to programmers, but in this case, the kit is just commands with ordinary verbs like get, new, set, and remove. If you have ever typed a command into a terminal, you already have the muscle for this. It also runs almost anywhere. The same commands work on windows, on a Mac and on Linux, and they run in both modern PowerShell seven and the older windows PowerShell five point one that ships with many machines. That range matters because a script you write on your laptop can run on a server later without being rewritten. There's a practical reason to care beyond curiosity. Microsoft made this the official replacement for the older tools, so it's the direction the entire platform is moving. Learning it now means learning the language that Microsoft three. Sixty five and Azure are increasingly written in. And that's a real line on a resume. The single front door that is Microsoft Graph. Underneath the commands sits Microsoft Graph. Understanding it makes everything else click into place. Microsoft Graph is one front door with one key. Instead of learning a different address and a different login for every Microsoft service, you learn a single address and a single key that opens the whole building. A couple of those words deserve plain definitions. The address is called an endpoint, which is just the web location your command sends its request to. The key is called a token. A small, short lived pass that proves you're allowed in. The SDK handles both of them for you, so you rarely see them at all. The commands themselves are generated from that interface, so they follow a steady pattern. You can predict. Get user reads users new user creates one set user changes one and remove user deletes one. The little egg in the middle is shorthand for Microsoft Graph. Once you can read one command, you can make a solid guess at hundreds of others. What makes graph special is the reach that same single address and single key open entry ID. The new name for Azure AD Plus, SharePoint exchange, outlook and teams. This is why one tool can list your users, pull their mail settings, and post into a teams channel without you juggling five separate logins for a beginner. The win is simpler than it first appears. You stop hunting through menus to answer basic questions. A count of every user is one command. A list of accounts that haven't signed in for ninety days is one command plus a filter. The data is the same data you see in the portal, only now you can reach it by typing. There's a small trick worth remembering for those counting jobs. You can ask graph for a near-instant count of an entire collection, which turns the question of how many users we have into an answer that arrives right away. Instead of a slow scroll through pages. It's a tiny feature that changes how you think about big lists. Hold on to that idea because it explains something bigger later on, which is why Microsoft had to shut the old modules down in the first place. How you sign in and what permissions really mean. Everything begins with a single command called connect M graph, and it does two jobs at once. It asks you which permissions you want, and then it opens a sign in page where you approve them. That approval step is called consent. It's the moment you decide what this session is allowed to touch. Permissions are the part people rush, and they're also the part that matters most in the SDK. Nothing is handed to you in advance. You request exactly what you need, which means a script built to read user profiles can't quietly go and delete mailboxes because it was never given the right to. A concrete example makes the idea stick. If your only goal is a report of who is in the tenant, you ask for a read only permission over user profiles and nothing else. That one decision means the worst thing the script can do is read, no matter what goes wrong later in the code. There are two ways to sign in, and the difference deserves 10s of your attention. Delegated access means you log in as yourself, so the tool can only do what you could already do by hand. App only access means there is no human at the keyboard, which is exactly what you want for a job that runs at two in the morning while everyone sleeps. Big permissions usually need an administrator to approve them the first time you request a new one, the consent screen appears and someone with the right role clicks. Yes, and many tenants. That means a privileged role administrator. After that, the tenant remembers the approval, so you don't repeat it. Every session. One helper is worth knowing early. Find Mograph command takes any command and tells you which permissions it needs. So instead of guessing between read access and write access, you ask the tool a companion command. Find Mograph permission works the other way around, starting from a permission and showing you what it unlocks. The other half of the story is discipline because you stay signed in for the entire session. A powerful session left open on a shared machine is a loose end, and closing it takes one command disconnect. Mograph ends the session and throws away the token, which is a habit to build from your very first script. Your first commands from listing users to messaging teams. Once you're signed in, the commands read almost like sentences. Everyone starts with a familiar verb, then the letters mg. Then the thing you're working with get reads new creates, set changes, and remove deletes so the shape stays consistent no matter what you point it at. Begin with the simplest command to feel the pattern. Get em user returns the people in your organization, and if that list runs long, you narrow it with a filter. A filter is just a plain condition written in quotes, something like the user principal name matching, a specific email address, and the command hands back the match. From there, you can walk a chain of relationships, which is where the real power shows up. Ask for a user, then ask which teams they belong to. Then list the channels inside one of those teams and then post a message into a channel. Each step reuses the identifier from the step before, so the commands link together like that. That last example shows the range. In one short sequence, you moved from identity to collaboration to communication, all with the same sign in and the same style of command. Nothing about the syntax changed, even though the work did. One distinction keeps you out of trouble because reads and writes carry different risk. A read pulls information back and needs a read permission. A write creates or changes something and needs a write permission, which is usually where the consent screen appears again. You can also shape the answer before it arrives. Request only the columns you need and the response gets smaller and faster, which matters a great deal. Once a list runs into the thousands. When the work is done. Disconnect. McGruff signs you out and ends the session cleanly. There's an honest limit here. Query options vary from one command to the next, and some filters only work when you add an extra setting that tells graph to be patient with large amounts of data. If a filter seems to do nothing at all, it may be failing quietly. Always glance at what actually came back. The everyday admin jobs it quietly replaces. This is the point where the SDK stops being a curiosity and starts giving you your afternoons back. Let me walk through the jobs it handles best. Onboarding is the classic one. Someone in HR sends you a spreadsheet of new starters, and instead of creating each account by hand, a script reads the file and creates them in a loop. It handles two hundred accounts in a single run with no typos from tired copy and paste licenses come next, and they're where the money hides. Every Microsoft three hundred sixty five license has a cost, and most organizations have people holding licenses. They no longer use a short script, lists who has what, and a matching script assigns or removes licenses in bulk. That's the sort of finding that turns up in a finance conversation. Cleanup is the third job, and it's the job everyone avoids. The list includes accounts belonging to people who left shared mailboxes nobody owns, and groups with no members left in them. The SDK finds that mess quickly because it can filter and count across thousands of objects in seconds. Teams provisioning is another quiet favorite. When a new project starts, someone has to create the team, add the right people, and set up a few standard channels. A script can do all of it the same way every time. That consistency is worth more than the saved clicks because nobody has to remember the checklist. Then there's the superpower of running it unattended. You can host a script in Azure Automation and let a managed identity sign in for it, which means there's no password sitting in the file for someone to find. It runs on a schedule, does its work, and leaves a report where you asked for it. Put those together and a pattern appears. The SDK is at its best when a task is repetitive, when it touches a lot of records, or when it has to happen on a schedule. Whether or not anyone is awake. And that's the real upside. The catch is that a handful of habits bite back if you get careless, and those are exactly the ones I want to put in front of you next. The mistakes and limits that catch almost everyone. Now, the honest part, because this is where beginners get burned. None of these are reasons to avoid the SDK, but all of them are reasons to slow down at the start. The first trap is permissions piling up without anyone noticing When you sign in interactively, the SDK uses a Microsoft app called Microsoft Graph Command Line Tools, and every new permission you approve gets added to that app for your whole tenant. Nobody ever goes back to remove the permissions they stopped needing, so the pile grows month after month. Then one day it breaks in a confusing way. Somewhere around one hundred and forty permissions. The sign in can fail with an error claiming the user cancelled the login when the real cause is the pile itself. The message points at the browser, and the problem is nowhere near the browser. That makes for a genuinely baffling afternoon. The fix is to clean house before you hit the wall. You can remove permissions you no longer need, and it pays to treat that approved list like a closet instead of a landfill. A short review a couple of times a year keeps the sign in healthy and keeps your tenant honest. The second trap is the beta version of the module. The SDK ships in two flavors, where one talks to the stable servers and the other talks to a preview service where features can change without warning. It's tempting to reach for the shiny preview command to get a job done early, and that trade rarely pays off. Preview features can break your script on an ordinary Tuesday with no notice. Save them for experiments and keep real work on the stable side. The third trap is pagination, and it fools almost everybody the first time. A list command does not hand you everything at once, it hands you one page, often around one hundred rows, and then it stops, which makes people think their data has gone missing. A switch exists that follows the pages for you, and another setting controls how large each page is so you can balance speed against load. The fourth trap is throttling, which is the service protecting itself. If you hammer Microsoft Graph with too many calls too quickly, it pushes back with an error that basically says too many requests, plus a header telling you how long to wait. Retrying instantly makes it worse because every retry still counts against your limit. The good news is, the SDK already knows how to wait and try again, so most of the time you simply let it. There is a gentler version of the same lesson for giant jobs. When you need to pull enormous amounts of data out of Microsoft three hundred sixty five, a separate bulk service exists for exactly that, and it isn't subject to the same limits as the everyday commands. Most beginners will never need it, but it's good to know the ceiling has a door in it. The last trap is asking for every column when you need two. When you pull a large list, trim the response down to the properties you actually use because a smaller answer travels faster and reads more clearly. Small habits like that separate a script that works from a script that works at scale today. Why the old Azure ad modules are gone for good? Let's go back to where we started because now the retirement makes sense. Those old modules weren't retired because Microsoft got bored of them. They were retired because the whole platform consolidated onto Microsoft Graph, and the old tools only reached part of it. The timeline is already history. Microsoft first named March of twenty twenty four as the retirement date, then pushed it back because the change was so large. Support actually ended on March thirtieth, twenty twenty five. After that, the two modules left one at a time. Miss online stopped working for all tenants by late May of twenty twenty five, and Azure AD PowerShell was retired shortly after July first, twenty twenty five. Tenants didn't get a personal warning, so a lot of scripts just quietly stopped. The names changed along with the tools. Anything that used to say Azure AD or Miss Online now says so get Azure ad user becomes get MG user. Microsoft publishes a map from the old names to the new ones, and it's the quickest way to translate a script you inherited from someone else. You might think this was a cosmetic rename, and it wasn't. The rebuild runs on modern authentication, which is a security upgrade, and that's the real reason the shift happened at all. The old sign in patterns were getting riskier, and the new foundation closes doors that had been left open. One more thing is worth a mention. A newer module called Microsoft Entra PowerShell is built specifically for entry ID tasks, and it's over ninety eight percent compatible with the old Azure AD commands. It even ships with a switch that lets many old scripts run almost unchanged, which can be the gentler road if you're staring at a pile of legacy work. The practical takeaway is simple if you maintain a script that still calls the old modules, it's already living on borrowed time, and the sooner it moves to the new names, the less painful the move will be. The map makes the translation mechanical for most commands, and the awkward ones are better rewritten by hand anyway. Where this fits next to Azure, the Portal and Graph Explorer. Let's zoom out for a moment and see the bigger picture. The same graph interface you're learning is what a lot of Microsoft's own tools use underneath. So this isn't a side skill you pick up and forget. It's closer to the shared language of the platform. On the Azure side, these scripts live comfortably in services like Azure Automation or an Azure function, where a managed identity handles the sign. In that identity is an account Azure creates and looks after for you. So there's no stored password, nothing to rotate, and nothing to leak. That's the grown up way to run automation, and it comes within reach sooner than you'd think. If you prefer to learn by poking around Open Graph Explorer, it's a free browser tool where you type a request and watch the exact call happen, and it's a safe place to break things. Before you ever point a script at real Users, you can copy what works and take it back into PowerShell. There's also the raw interface sitting under the SDK, and it helps to know it exists. It's the same service with more manual work because you assemble the request yourself, the SDK hands you named commands and tidy objects instead. And for a beginner, that difference is the whole reason to start here. The choice between clicking and scripting comes down to repetition. For a one off change, click because it's faster and there's no reason to write anything. The moment a task repeats or scales past a handful of people, that's the line where a script wins. It helps to see the SDK as one way into a much larger space. The portal is another way in. Graph explorer is a place to practice, and the raw interface is the same thing with the friendly handles removed. You don't have to pick one forever, and most people move between them depending on the job in front of them, what to remember and where to go next. Let me pull the thread together. The Microsoft Graph PowerShell SDK is a set of commands that talk to Microsoft three hundred sixty five and Azure through Microsoft Graph, and it replaced the older modules that were retired in twenty twenty five. You sign in once. You ask for only the permissions you need, and you use ordinary verbs you already recognize the bumps to remember are the permissions pile. The temptation of preview features, the pagination that hides your data, and the throttling that punishes impatience. Keep those four in mind, and you'll avoid most of the pain that new users run into. So here's the question I'll leave you with. If you could hand one repetitive Microsoft three hundred sixty five task to a script tomorrow, which task would it be and what's actually stopping you from trying it this week if this made the topic feel less intimidating? Subscribe to M365 FM to master the tools and the mindset shaping the future of work.