PowerShell - Simply Explained

Welcome to another episode of Microsoft Knowledge Nuggets on M365. FM, I'm your host, Mirko Peters. What if I told you there's a tool already sitting on your computer that can automate almost anything? Think about your typical workday. You log in and open a few applications, click through the same menus you clicked yesterday, run the same reports, check the same services. Maybe you spend an hour doing something that feels like it should take five minutes. That tool I'm talking about is PowerShell. By the end of this episode, you'll understand what PowerShell actually is, how its commands work and why it's the hidden superpower of the Microsoft ecosystem. We'll start with the basic idea, work through the building blocks, and by the end, you'll have real automation you can use today. The big picture, what PowerShell actually is. So what exactly is PowerShell? Most people hear the name and think it's just a fancy command prompt. It's not. PowerShell is a full automation platform. Think of it as a command line shell, a scripting language, and a remote management tool all in one. In the command line shell, you type commands and get results, but it's also a scripting language that lets you write programs that run on their own and a remote management tool that controls dozens or hundreds of machines from a single window. 20 years ago, automating something on Windows meant using a mess of different tools. You used batch files for simple tasks, VB script for more complex ones and separate admin consoles for exchange, Active Directory and file servers. None of them talk to each other. You'd copy data from one tool, paste it into another, and hope nothing got lost. PowerShell changed all that. It's one tool that talks to everything. Windows itself, Azure, Microsoft 365, Exchange, Teams, SharePoint, Active Directory, and even Linux machines now. You use the same language, the same patterns, the same commands, no matter what you're targeting. And it's cross platform. PowerShell 7 runs on Windows, Linux and Mac OS. So in a mixed environment, you don't need to switch tools. Here's the thing. If you work in IT, PowerShell is the language of the Microsoft ecosystem. It's how you talk to your infrastructure and automate the boring stuff, so you can focus on the interesting problems. But before we get into what it can do, let's look at how it actually works. The verb noun pattern, how PowerShell commands work. Every PowerShell command follows a simple pattern called verb noun, and it's exactly what it sounds like. The verb tells you what you want to do. Get set, new, remove, start, stop. And the noun tells you what you're targeting like process, service, user, item, or mailbox. So get process gets you a list of running processes, get service shows you all the services on your machine. Set date changes the system time, stop service stops the service. The pattern is so consistent that once you learn it, you can guess commands you've never seen before. Want to start a service type start service need to remove a user type remove user. It's that straightforward. PowerShell was designed to be discoverable, so you don't need to memorize hundreds of commands. Your best friend here is the get command CMD let run get command noun service. And it shows you every command that works with services get service, start service, stop service, restart service, set service, new service, remove service. All of them right there just by asking, let me give you a concrete example. Say you want to know what commands can manage processes. You run get command noun process. You get back get process, start process, stop process, debug process, wait process. You don't need to guess the tool tells you that's what makes power shells so different from old school command line tools where you had to memorize every flag and switch. And here's why that matters. You don't learn power shell by memorizing a thousand commands. You learn the pattern and you can figure out the rest as you go. It's like learning that every verb in a language follows the same conjugation. Once you know the rule, you can apply it anywhere, but this is where power shell really breaks away from everything else. Objects not text, the game changer. So here's the thing that makes power shell fundamentally different from every command line tool that came before it. Traditional command lines output text, you run a command and get lines of characters on your screen. And that's it. If you want to do something with that output, you have to pass it, cut it up, extract the parts you need using string manipulation and it's fragile. One space out of place and your whole script breaks. Power shell doesn't work that way. It gives you objects structured data with properties and methods. When you run get process, you don't get a text table. You get process objects. Each one has properties like name, ID, CPU, memory, start time and methods like kill. You can pull those properties filter on them, sort them, export them. You can do things with the data that would take 20 lines of text passing in a single command. That's the game changer. Let me show you the old way using command prompts task list command. You get a text table. If you want to find processes using more than 50 CPU, you have to write passing logic. You have to account for column widths, spacing, headers, it's messy and it breaks constantly. The power shell way looks like this. Get process piped away object with a condition, piped to export CSV. That's one line filter only processes using more than 50 CPU, save to a CSV file done. What makes this all work is the get member Cmd let you pipe any command to get member and it shows you every property and method those objects have. It's like peaking under the hood. Run get process, get member. And suddenly you see everything name, id, handle, CPU, working set, start time. And methods like kill, refresh, wait for exit, you don't have to guess what data is available. The tool tells you here's a real world scenario. Say you're an admin managing 50 servers. You need to find all stop services across all of them. The old way you'd remote into each server open services. MSC check manually write it down. That takes hours. The power shell way you write one command, get servers on each machine, filter where status is stopped, export to a CSV. One command, 50 servers, same result every time. No clicking through GUIs, no manual note taking, no mistakes from copying data between windows. And here's why this matters. Object output means you can chain commands together. The output from one command feeds directly into the next as structured data. You're not passing text, you're manipulating objects. It's the difference between sorting through a pile of loose papers and working with a filing cabinet where everything has a label. So now you know the pattern and the pipeline. Let's talk about the commands you'll actually use. The five essential Cmdlet groups. You don't need to learn hundreds of Cmdlets to be productive with power shell. Start with five groups and you'll cover about 80% of what you'll do day to day. Group one is discovery. It's the most important because it teaches you power shell from within itself. Get help, get command, get member. These three are your learning tools. You don't need to memorize anything because you can always look it up. Get help shows you how to use any command. Get command shows you what commands exist and get member shows you what data those commands output. If you learn nothing else, learn these three. Group two is file system. Covering the everyday file tasks you do constantly. Get child item lists, files and folders, copy item copies them, remove item deletes them and get content reads file contents. You can do in one line what would take clicking through multiple folder windows. Group three is system, managing what's running on your machine. Get process shows running processes, get service shows services and start service and stop service control them. Restart computer reboots a machine if you've ever opened task manager or services. MSE these commands replace all of that and they work remotely. You can check services on 100 machines without leaving your desk. Group four is filtering and shaping where the pipeline really shines. Where object filters data based on conditions, select object picks which properties you want to see, sort object orders your results and group object aggregates them. These CMD let's turn raw data into useful information. Without them, you're just dumping data to the screen. With them you can ask specific questions and get specific answers. Group five is export how you save your work. Export CSV writes to a file you can open in Excel, outfile writes to a text file, and convert to JSON converts to JSON format. These CMD let's let you turn your commands into reports, logs or data files. You run a command filter the results and save them. That's a report, that's automation. Here's a quick example for each group. With discovery you'd run get command, noun service to see every service related command. With file system get child item C plus logs, recurs, where object length GT 10 made of me finds large log files. For system get service, frontware object status, ecu stopped lists stopped services. For filtering, get process, art, sort object CPU descending. Select object, first five shows the top five CPU hogs. And for export get service and export CSV services. CSV saves everything to a file. Here's why this matters. These five groups cover the vast majority of what you'll do. You don't need to be a power shell expert, just no way to start. And the best place to start is the group that teaches you everything else. Let's talk about discovery. Discovery first, get help, get command, get member. Let me tell you about the single most important cmd. you'll ever learn. Get help, it's power shells built in manual. Type get help, followed by any command name. And it shows you the syntax parameters and most importantly, working examples. You don't need to search the internet or memorize anything. The documentation is right there inside the tool. Say you want to understand how get process works. Type get help, get process. And it shows you the syntax, what parameters it accepts, and what each does. But the real goal is in the examples, get help, get process. Examples jump straight to working code you can copy and run. That's how you learn power shell from within power shell itself. Then there's get command. This cmd.let lists everything available in your session. Every cmd.let function and script. And you can filter it. Get command.verb. Get shows you every get command of which there are hundreds. Get process, get service, get date, get item, get child item, get content. All of them, just by asking, get command. And now service shows you every command that works with services. Get service, start service, stop service, restart service, set service, new service, remove service. You don't need to guess what's available. The tool tells you. And then there's get member. The one that unlocks everything. Pipe any command to get member. And it shows you what's inside the objects that command returns. Run get process, get member. And you see every property and method of process objects. Name, ID, CPU, working set, start time, and methods like kill. Refresh, wait for exit. You don't have to wonder what data is available. You can inspect it directly. Why this matters? You never need to memorize everything. You can learn as you go. Get help teaches you how to use commands. Get command shows you what commands exist. And get member shows you what data those commands return. These three cmd.lets are your learning tools. They make power shell self documenting. Once you know what's available, the next step is shaping that data into something useful. Filtering, shaping, and exporting. Turning commands into reports. Here's the thing about power shell. The power isn't in any single command. It's in how you combine them through the pipeline. You take the output from one cmd.let, pipe it into another, and build complex operations from simple building blocks. Where object is your filter that only passes through objects matching your condition. So get service, where object status EQ. Running gives you only running services. No scrolling through a list of 100 services. The command does the filtering for you. Select object picks, which properties you want to see. Get process, select object. Name, CPU, working set, returns just the data you care about. It strips away handles, page memory, and session IDs, leaving only the columns you asked for. That's how you turn a wall of data into a clean readable table. Sort object orders your results. Get process, hmm, sort object CPU. Descending shows you the most CPU intensive processes first. So you can find the problem immediately instead of scanning through an unsorted list. Export CSV saves everything to a file you can open in Excel. This is where the magic happens. You run a command, filter it, shape it, and save it. That's a report and that's automation. Here's the full pattern put together. Get service, most where object status EQ. Stopped, select object name, display name. Export CSV stop services. CSV, it's one command that gets all services, filters to only stop once, picks just the name and display name and saves the result to a CSV file. You can run this on one machine or 100 and you get the same result every time. This is what replaces hours of clicking through GUIs and manual copy pasting. Instead of opening services, MSC on every server scrolling through the list, writing down what stopped and typing it into a spreadsheet. You run one command. It takes seconds, it's accurate and it's repeatable. Why this matters? You go from reactive to proactive. You can run these reports on a schedule. Every morning a script checks your services, exports the results and emails them to you. You spot problems before they become emergencies because you know what's running, what stopped and what needs attention. Instead of waiting for something to break, you stay ahead of it. So now you have the pieces, the discovery tools to learn what's available, the filtering tools to find what matters and the export tools to save your results. Let's see how they all fit together into one system. How it all connects? The pipeline in action. The pipeline is the heart of PowerShell, not just a feature. Every CMD-LED outputs objects and the pipeline sends those objects directly into the next CMD-LED. That simple idea is what makes PowerShell so powerful. You build complex operations from simple building blocks, one pipe at a time. Let me give you a real scenario. Say a user calls because their account is locked out. This happens all the time. Someone types their password wrong too many times and suddenly they can't log in. The old way of handling this is a pain. You open Active Directory users and computers. Scroll through the list, find the user, right click, check the account, unlock it, then open Event Viewer to find the lockout event, then manually note the time and source. That whole process takes five to ten minutes per user. And if you have multiple users calling in, you spend your whole morning on this one thing. The PowerShell way is completely different. One command, get a user, filter, lockout, EQ true, finds every locked account in your domain. Then you pipe that into Unlock AID account and that's it. The script finds the locked accounts and unlocks them, then you pipe the result to a logging function or export it to a report. You have a record of what happened when it happened and which accounts were affected all from one line of code. And here's the thing, the same pattern works everywhere. Exchange mailboxes, Teams, channels, SharePoint sites, Azure resources, the CMD-Lets change, but the pipeline stays the same. You get something, filter it, do something to it and save the result. For example, get mailbox, filter by some condition, set a property export to CSV, or get team, filter by membership, add a member, log the change. The pattern is identical every time. Why this matters? Once you understand the pipeline, you can automate almost anything. The pattern is the same whether you're managing one user or a thousand, one server, or a hundred. You learn the pattern once and apply it everywhere. All right, you've seen what it is and how it works. Now let's talk about what you should actually do next. Your first steps to automation. So where do you start? Open PowerShell and Run Get Help to start exploring. Type Get Help, Get Process and see what it shows you. Then type Get Help, Get Service examples and look at the working examples. This is how you learn the tool from inside the tool. No searching the internet or watching tutorials needed. The documentation is right there. Next pick one task you do every week. You see it's checking which services are running on a server, listing files in a folder or exporting a report. Write a one-liner for it and start simple. Something like Get Service, where object status, EQ running. That's a one-liner. Run it, see the output and save it. You just automated something you used to do manually. Then use Get command and Get member to discover what's possible. You don't need to know everything upfront, just how to find what you need. Get command, noun service shows you every service related command, and Get Process. Get member shows you every property of process objects. The tool tells you what it can do and you just have to ask. The best first step is simple. Automate the task you do most often. Even a simple one-liner saves you time. If you check services every morning, write a one-liner that checks them for you. If you clean up temp files every week, write a one-liner that does it. Start small and build from there. Now where do you go from here? Microsoft learn has free PowerShell learning paths. They're structured, practical, and completely free. The PowerShell gallery has thousands of community modules, so someone has probably already written a module for whatever you're trying to do. You don't need to reinvent the wheel. PowerShell is a skill, not just a tool. The more you use it, the more it clicks. You don't need to be a developer. You just need to start. Ten minutes a day is enough to build real capability. Run one command today, run two tomorrow, and before you know it, you're automating things you never thought you could. So that's PowerShell. The language that connects the entire Microsoft ecosystem. Open it up and Run Get Process to see what it looks like. Then subscribe for more knowledge nuggets and drop a comment about what you want to automate. What's one task you wish you could automate? Let me know. in a future episode.