PowerShell for Microsoft 365 - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. An hour of clicking in Microsoft three hundred sixty five does the job of one typed line. That typed line is PowerShell, and it's the difference between doing a task once and doing it one hundred times. Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. Today, we're taking the fear out of PowerShell for Microsoft three hundred sixty five. You don't need an IT background because the first command you run only looks and changes nothing. By the time we finish, you'll know how to connect and how to make one line do the work of many for what PowerShell actually is. Start with the plain version because the name makes it sound heavier than it is.

0:41 PowerShell is a place where you type instructions to Microsoft. Instead of clicking your way through menus, you open a window, you type a sentence and the thing you asked for happens. That's the whole idea and everything else is detail. If you've ever typed a question into a search bar, you already understand the shape of it. The difference is that PowerShell talks directly to Microsoft three hundred sixty five. The sentence you type can add a user, check a mailbox, or pull a list of accounts. The clicking we all know is a conversation where you point at one thing at a time. Typing is that same conversation written down, and writing it down is what changes everything. Once the instruction exists as text, you can save it, run it again tomorrow, and hand it to a teammate. That saved list has a name. A script is just a collection of typed instructions you can reuse whenever you need them.

1:22 You write the job once and use it forever, which makes it a to do list that Microsoft three hundred sixty five knows how to follow on its own. The vocabulary is the scary part, not the tool. Words like cmdlet and pipeline sound like they belong to a developer, and we will get to both of them. Neither one is required to understand what is happening here. You type a line, you watch what it does and you build from there. Microsoft built PowerShell for its own products first, and that is why it reaches so much of Microsoft three hundred sixty five people and passwords, mail and files, licenses and groups. All of it can be handled from the same window. That reach is the reason administrators keep coming back to it. For a beginner, the honest reframe is this. PowerShell is not a programming language. You learn from scratch because the commands are already made and their names tell you what they do, why admins reach for it.

2:03 Here is where the clicking starts to hurt. The Microsoft three hundred sixty five admin center is built for one person at a time. Every small change means finding the right screen, clicking the right user, and then doing it all over again. Imagine fifty new starters arriving on the same Monday. Each of them needs the same account, the same access, and the same settings. And doing that by hand is fifty rounds of the same clicks. One tired afternoon, you mistype a name and nobody notices for a month. That is the problem PowerShell was made for. You write the instruction once pointed at the whole list, and Microsoft three hundred sixty five works through it while you do something else. The same sentence does the work of all fifty rounds, and it does them the same way every time. Consistency is the quiet benefit here. A human doing the same task for the twentieth time gets sloppy, while a typed instruction does not get tired or bored.

2:47 You also end up with a record of exactly what you ran, which helps when someone asks how an account got set up. None of this is about being clever. It's about handing the repetitive parts of your day to something that never complains. This isn't only for big companies. Even a small team runs into the same wall because Microsoft three. Sixty five does not get simpler. As you add people, it gets wider and width is exactly what one written line handles well. Remember the last time you set up access for a new hire? You clicked through a handful of screens and it felt fine because it was one person. Multiply that by a whole team joining at once, and the same few clicks turn into an afternoon. The modules graph PowerShell and Exchange online. Now we hit the word that shows up in every guide and it deserves a plain explanation. A module is a toolbox you load for a specific job, so you don't carry every tool at once.

3:31 You load the toolbox built for people and accounts. When you work with users and you load a different one when you work with mail. The main toolbox today is called Microsoft Graph PowerShell. It's the current way to reach Microsoft Entry ID, which is the directory that holds your users and groups. The same connection also reaches other Microsoft services, so you use one sign in instead of a different one for every service. You might think the confusing part is the number of tools, but the real shift already happened. The older tool boxes, Azure AD, PowerShell, and Ms. Online were retired, and Microsoft Graph PowerShell is what replaced them. The old names aren't needed for anything new, and the modern one is the one worth learning. There is a small naming clue that saves confusion, and it's worth remembering the new commands dropped the old Azure ad prefix and use m g instead.

4:13 That means the old command for getting a user became get m g user. The same idea with a shorter name mail gets its own toolbox called Exchange Online PowerShell. Sometimes shortened to exo. It handles mailboxes, mail rules, and distribution groups. And since twenty twenty three, it talks to Microsoft over a newer, faster connection than the one it replaced. And that pattern repeats across Microsoft three hundred sixty five. SharePoint teams, and the rest each have a toolbox of their own. So once you understand one, the others feel familiar rather than strange. Installing a toolbox is a one time job. You run a single instruction. Microsoft downloads the module from its own store and it stays on your machine for next time. Here's the part that surprises people. Learning graph PowerShell is not just about users and passwords because the same connection reaches teams, SharePoint sites and mailboxes to the skills you pick up for one service carry straight over to the next.

5:01 That's why it's worth learning the modern toolbox instead of patching old scripts. The word module is doing a lot of work in every guide you will read, and now you can translate it. It's a toolbox. You load the one for the job and the right commands appear. Connecting and signing in. Loading a toolbox is easier than it sounds because it's one instruction you run once. After that, the commands are just there waiting for you in any new window. Connecting is the step people worry about most, and it turns out to be the gentlest part. With Microsoft Graph PowerShell, you run a connect command and name the permissions you want. Then a normal sign in page opens in your browser. You sign in the way you always do, and when it works, you see a short welcome message. Those permissions have a name worth knowing. A scope is the list of things you're asking to do, and Microsoft Graph PowerShell does not hand you everything.

5:44 By default, you ask for only what the job needs, which keeps your access small on purpose. The first time you connect someone with admin rights approves that list, and that approval is called consent. After that, the connection is ready and you stay signed in for the session until you close the window or disconnect. When you're done, you disconnect so the access goes away and that's a habit worth keeping. The exchange online toolbox follows the same shape. You connect with your username and you disconnect. When you finish, the male side feels like a sibling of the graph side rather than a separate world. Sometimes a script needs to run on its own without a person signing in. For that, you can let it use a certificate instead of an account, which is the safer way to handle automation. You don't watch, you only need to install and connect once per session, and then you're free to run as many commands as you like.

6:28 That single sign in is what makes the whole thing feel less like a chore and more like a tool you leave open. And here is the head fake. For this section, you might assume the hard part is remembering the commands. The part that trips people up is the permissions, because that is where you decide what you're allowed to touch. There's one small tip that saves grief later. Keep the connection open only as long as you need it, because signing out when you're done means a lost laptop can't keep using your access key. And let's end the pipeline. Now we get to the commands themselves, and the name for them is friendlier than it looks. A cmdlet is a single, ready made command, and you don't build it, you just call it. Each one follows the same pattern of a verb and a noun. So the name tells you what it does before you run it. A command that starts with get reads something, so get em.

7:09 User reads your users and shows them to you. A command that starts with new creates one that starts with set changes and one that starts with remove takes away. Once you spot the verb, you can guess the job. Listing everyone is a good first move, but a company with thousands of users doesn't want the whole pile. You can narrow it down with a simple condition asking for just the accounts that match and Microsoft three. Sixty five returns only those. That filtering is what keeps a big organization from becoming a slow one. Then comes the idea that ties everything together. The pipeline is the little vertical bar you see between two commands. It takes whatever the first command produced and feeds it straight into the next command. Picture a conveyor belt between two stations where the first station makes something, and the second one does the next step with it. That one symbol is why PowerShell feels powerful, because you can chain small, simple commands into a longer job without writing anything complicated.

7:55 And when you forget what a command needs, PowerShell can describe itself. Help and discovery commands tell you what a command does and what permissions it asks for, so you look it up instead of memorizing it. Begin with the get commands because they only read and they show you the shape of your own organization. Reading your own users and mailboxes is the fastest way to learn what the data looks like before you ever touch it. The verb and noun pattern is not just a naming style. Microsoft keeps an official list of approved verbs, so the same words mean the same things across every module. You load, learn, get, and set once, and they mean the same thing in graph, in exchange, online and in the next toolbox you pick up. There's a reason the pipeline matters so much for a beginner. There's no need to learn one giant command that does everything, because you can stack a few small ones and read the result at each step.

8:38 Save scripting habits. This is the section that should calm you down because the worry is real and the answers are built in. The fear is that one wrong line wipes out the wrong thing, and PowerShell was designed with that fear in mind. The first tool is a switch that shows you what would happen without doing it. add it to a command and PowerShell tells you exactly what it would have changed, then stops. That lets you read the plan before you approve it, like a rehearsal for the real thing. The second tool is its partner, a switch that pauses and asks before a change goes through. You see the action. You decide yes or no, and nothing happens until you say so. Between the two, a beginner can explore a live organization without ever gambling on a guess. Then there are other habits you build yourself. Start with commands that only read and move to commands that change.

9:18 Once you trust what you're seeing. Ask for only the permissions the task needs. Because a small set of rights is easier to keep safe than a big one when you're ready to make a change. Test it on one person or one test account first. If the result looks right, widen it to the rest. And if it looks wrong, you've lost nothing. There are two more habits worth building. Never put a password directly inside a script because it will end up in a file someone can read. Use the certificate approach when a job runs on its own, and when a bulk change is very large, split it into smaller batches. A single mail operation has a time limit and a huge request can run past it. None of this slows you down for long, and most of it becomes automatic after a week. The point isn't to make you cautious forever is to let you move fast without the pit in your stomach. The rehearsal switch is worth dwelling on because it changes how you learn.

10:01 You can try a command you don't fully understand yet. Read The Planet Prince and only then decide whether to let it act. That turns every experiment into a safe one. And if you're ever unsure, the safe move is always the same. Look first, change second, and test on one before you touch the many common tasks you can automate with the safety net in place. Here's what the work looks like. These are everyday jobs, not advanced admin work, and most beginners start there. Finding and listing people is the natural starting point. A get command lists the accounts in your organization, and you can search for one person by name instead of scrolling. That alone replaces a surprising amount of clicking. Mail is the next one. The Exchange Online toolbox has fast commands for listing mailboxes.

10:41 There's also a quick test command that confirms you're connected to the mail side before you trust a result. When you manage many mailboxes, the optimized listing commands are built for exactly that. groups come up constantly, commands like update distribution, group member and add distribution group member handle who belongs to a group. So adding a whole team to a mailing list is one instruction instead of twenty. Then there's the task that becomes your favorite. Pulling a list of users or mailboxes into a file you can hand to someone is often the first real win. A report that used to take an afternoon now takes seconds. Consider the reports you build by hand, the lists you keep in a spreadsheet, and the small chores you do the same way every month. Each of those is a candidate, and each one you hand over frees up an hour. You can spend somewhere better.

11:22 The pattern to notice is that every example starts with reading. You look at what you have, you confirm it's right, and only then do you decide whether a change is worth making. That order keeps you safe and it keeps you honest. None of these tasks require a big budget or a special license beyond what your organization already has. They run from the same window on the same laptop with the tools you've already loaded. There's no need to know every command in advance. You start from the job in front of you. Look up the two or three commands it needs and the rest follows. Where to start as a beginner. If you only remember one piece of advice, make it this one. Your very first command should be a read only one something that lists information and changes nothing. That way, your first experience with PowerShell cannot break anything and you get to see real results from your own organization.

12:04 From there, the order that works is simple install the toolbox, connect. Run one command that only looks, and then try a single small change on a test target. Each step builds on the last, and none of them ask you to leap. You will not memorize the commands and that's fine. PowerShell is built to describe itself. So when you forget what a command does, you ask it. Learning the tool is really learning how to look things up. There's one more thing that should reassure you. PowerShell runs on windows, on a Mac and on Linux, so the computer you already own is almost certainly fine. You're not buying anything new to try this. The skill that matters isn't typing fast, and it isn't memorizing syntax. It's reading an instruction and predicting what it will do before you run it. And that is a muscle. You build one command at a time. If you're a visual learner, the pattern will click the moment you run your first command and watch a list appear in front of you.

12:49 Seeing your own users come back from a typed sentence is the moment this stops feeling like someone else's tool. Give yourself permission to go slowly here. A week of small read only experiments will teach you more than a month of reading, and nothing you do in that week can hurt your environment. Recap and one open question. Let's pull the whole thing together in the simplest terms. PowerShell for Microsoft three hundred sixty five is typing instructions instead of clicking, and a module is just the toolbox you load for the job. Microsoft Graph PowerShell is the main one with Exchange Online handling mail, and you connect and sign in once before you start. From there, a cmdlet is a single readymade command, and the pipeline is the conveyor belt that chains commands together a few safety switches let you preview a change before it ever happens.

13:30 That's the whole picture, and it's a smaller picture than the name suggests. So here's the question I'll leave you with and I want you to sit with it. Which single repetitive task in your own Microsoft three hundred sixty five day? Would you hand over to one typed instruction first? You don't have to answer out loud. The answer is usually the job that annoys you most. And that's exactly where a typed instruction earns its keep.