Speaker 1: Okay, let's unpack this. Imagine you're trying to get your
Speaker 1: computer to do more for you, maybe sort through a
Speaker 1: huge pile of files, automate some boring task, or just
Speaker 1: peek under the hood a bit see how things really tick.
Speaker 1: If that sounds like you, well, then this deep dive
Speaker 1: is going to be incredibly insightful. Today we're diving into
Speaker 1: Windows PowerShell. It's this really powerful tool that honestly transforms
Speaker 1: how you interact with and manage your Windows systems. We
Speaker 1: spend a lot of time going through a pretty comprehensive
Speaker 1: cookbook on it, pulling out the best bits. Our mission
Speaker 1: today cut through the jargon, give you the essentials of
Speaker 1: what PowerShell is and more importantly, what it can actually
Speaker 1: do for you.
Speaker 2: Yeah, and what's truly powerful about PowerShell, I think is
Speaker 2: that it's just so much more than another command line.
Speaker 2: It's really a fundamental shift. It changes how administrators and
Speaker 2: even just regular users can manage Windows. It's designed from
Speaker 2: the ground up to be robust, consistent, deeply integrated. It
Speaker 2: really empowers you to be remarkably efficient. So throughout this
Speaker 2: deep I will explore how it manages that, looking at
Speaker 2: its unique approach to data. It's incredible discoverability, features, scripting,
Speaker 2: and how it connects all these different parts of your
Speaker 2: system hashtag, check tag the deep dive.
Speaker 1: PowerShell's core philosophy interacting with purpose.
Speaker 2: So if you've ever poked around in Windows, you probably
Speaker 2: remember the old command prompt right, maybe from Windows XP
Speaker 2: or an older server version. PowerShell actually looks pretty similar
Speaker 2: at first glance, and yeah, you can run familiar tools
Speaker 2: like ipcunfig or even classic DOST commands like CD and dirt.
Speaker 2: That still works. But here's where that familiarity kind of
Speaker 2: ends and the real power starts to show exactly.
Speaker 1: That familiar look. It's quite intentional, makes it less intimidating,
Speaker 1: lowers the barrier to entry, you know, beneath that surface.
Speaker 1: PowerShell is built on these core principles that prioritize efficiency
Speaker 1: and power, especially for anyone managing a Windows system. It's
Speaker 1: designed for quick, interactive use. It supports incredible discovery discovery, yeah,
Speaker 1: meaning you can find out how to do almost anything
Speaker 1: with just a few simple commands. It's amazing. Plus enables
Speaker 1: really comprehensive scripting, and it can bridge or sort of
Speaker 1: talk to all these different technologies dot net com WMI, XML,
Speaker 1: web services, active directory. Yeah, you name it, okay.
Speaker 2: And one of the first things I noticed, or that
Speaker 2: you'll notice, is the command structure. It seems really logical.
Speaker 1: It is. Most commands follow a clear verb noun pattern.
Speaker 2: Like get process or stop service.
Speaker 1: Precisely get process to see running processes, stop service to
Speaker 1: stop a service. It makes guessing new commands really intuitive,
Speaker 1: and you quickly pick up shortcuts, use wild cards. You
Speaker 1: can get exactly what you need without typing endless commands.
Speaker 3: Now, if there's one really big aha the moment we
Speaker 3: want you to take away from this deep dive, I
Speaker 3: think it's this PowerShell doesn't deal with plaintext in the
Speaker 3: way you might expect.
Speaker 2: It deals with objects. And to get why this is
Speaker 2: such a game changer, think about traditional command line tools.
Speaker 2: They often just spit out raw text. Right, So if
Speaker 2: you wanted to, I don't know, find all processes using
Speaker 2: more than one hundred millibit of memory, you'd have to
Speaker 2: use maybe other tools. Our source calls it a black art.
Speaker 1: Oh yeah, that's a good way to put it.
Speaker 2: To parse that text and pull out the numbers.
Speaker 1: And this raises an important question, why is relying on
Speaker 1: text such a problem well, because getting structured, meaningful information
Speaker 1: out of just, you know, a wall of text is
Speaker 1: incredibly difficult. It's slow, it's error prone, well.
Speaker 2: Trying to find specific facts in a giant, unformatted book exactly.
Speaker 1: PowerShell solves this so elegantly by passing full fidelity objects
Speaker 1: through its pipeline. So instead of just a string of
Speaker 1: characters everything, PowerShell works with a process, a file, a
Speaker 1: user account is a rich object, and these objects have
Speaker 1: clearly defined properties like name, id, memory, usage, creation, date,
Speaker 1: whatever makes sense for that thing.
Speaker 2: Okay, So instead of fighting with text, you're working directly
Speaker 2: with structured data that's already organized for you, that.
Speaker 1: Makes sense precisely, and that makes actions like filtering super powerful.
Speaker 1: You use wear object, rare objects, or sorting with sort objects,
Speaker 1: it becomes incredibly precise and clear because you're just saying,
Speaker 1: show me objects where the memory property is greater than
Speaker 1: one hundred milibet ah, I.
Speaker 2: Say, you're working with the properties.
Speaker 1: Directly, exactly, and you chain these commands together with that
Speaker 1: simple pipe symbol that I know, right, So the output
Speaker 1: objects from one command flowed directly as input to the next,
Speaker 1: like building with legos.
Speaker 2: Almost navigating and manipulating your digital world with objects.
Speaker 1: Okay. Building on that object idea, PowerShell takes something you
Speaker 1: already know, like navigating files and folders.
Speaker 2: Yeah, like using CD and DURR or l's right, and.
Speaker 1: It extends that concept to other parts of your computer.
Speaker 2: That's right. That's where powershells providers come in. Think of
Speaker 2: them like special adapters. They make different data stores in
Speaker 2: your system look and feel just like a file system.
Speaker 1: So what kind of data stores?
Speaker 2: Well, the big ones are the Windows Registry, environment variables,
Speaker 2: the certificate store. It means you can use the same
Speaker 2: commands set location, which is CD, get child item, dur
Speaker 2: or alls get item, new item to navigate and manage
Speaker 2: these completely different areas.
Speaker 1: So you could type set location HKLM.
Speaker 2: Exactly and suddenly you're browsing the hkey local machine part
Speaker 2: of the registry, just like it's the Sea drive. It's
Speaker 2: incredibly consistent.
Speaker 1: Okay, that's pretty cool. And what about actual files? How
Speaker 1: versatile is it? There?
Speaker 2: Oh? Very You can search for text inside files using
Speaker 2: select string like GRIP on Linux kind of yeah, but
Speaker 2: remember the object difference. Select string gives you back objects
Speaker 2: with details about each match, the line number, the match text,
Speaker 2: the file name much richer than just the text.
Speaker 1: Line okay, and structured data like XML or CSV absolutely.
Speaker 2: For XML, you can literally load the file into an
Speaker 2: XML object variable. Then you use dot notation to navigate
Speaker 2: and change things and just save it back. Super easy.
Speaker 2: And for csvs, which are everywhere right, import CSV is fantastic.
Speaker 2: It automatically turns each row into an object and the
Speaker 2: column headers become the object properties.
Speaker 1: Wow. Okay, so no manual parsing.
Speaker 2: None needed. It makes analyzing log files or any CSV
Speaker 2: data incredibly forward. And this power extends to modern web
Speaker 2: stuff too. If you're interacting with web APIs, which so
Speaker 2: much relies on now Jason data usually yep, Jason PowerShell
Speaker 2: has built in commands like convert to Jason and convert
Speaker 2: from Jason, and even better, invoke rest method which you
Speaker 2: used to call. Web APIs can often handle the Jason
Speaker 2: conversion automatically for you. It just gives you back objects
Speaker 2: directly from the API response.
Speaker 1: That simplifies things a lot. Plus I saw. You can
Speaker 1: even do things like export data to a CSV file
Speaker 1: and then use invoke item on that file.
Speaker 2: Then it opens right up and excel yeah on one
Speaker 2: command line. It bridges that gap between the command line
Speaker 2: and GURI tools really nicely sometimes.
Speaker 1: Okay, switching gears slightly. Have you ever hit that wall
Speaker 1: in Windows where a file path is just too long,
Speaker 1: that like two hundred and sixty character limit thing?
Speaker 2: Oh yeah, super frustrated.
Speaker 1: It's a classic Windows headache, isn't it. But PowerShell has
Speaker 1: a trick for that.
Speaker 2: It does, thankfully, so Windows itself actually supports much much
Speaker 2: longer paths, like thirty two thousand characters internally, but lots
Speaker 2: of the older tools and APIs, even parts of File
Speaker 2: Explorer weren't written to handle them, so they choke on
Speaker 2: anything over two sixty. PowerShell lets you work around this
Speaker 2: by creating a temporary PowerShell drive using new ps drive.
Speaker 2: You map this drive directly to the really long path.
Speaker 1: Ah, so it kind of creates a shorter alias.
Speaker 2: Exactly, and then you can use that drive letter to
Speaker 2: access the files inside, making those previously inaccessible files totally
Speaker 2: manageable from PowerShell. It's a clever fix.
Speaker 1: And here's another need trick. I came across unblock file.
Speaker 1: What's that about? You download something and Windows warns you
Speaker 1: it's from the internet.
Speaker 2: Right that mark of the web warning that's actually stored
Speaker 2: in something called an alternate data stream or ADS attached
Speaker 2: to the file, specifically one called zone dot identifier. Unbloged
Speaker 2: file simply removes that specific ADS poof the warning is gone.
Speaker 1: So PowerShell lets you manipulate these hidden file system features directly.
Speaker 2: It does. It gives you that deeper level of control
Speaker 2: that's often hidden away. And while we're on files, let's
Speaker 2: talk integrity. Verifying files haven't been changed. PowerShell can calculate cryptographic.
Speaker 1: Hashes like MB five, SAHA one.
Speaker 2: YEP, MD five, SAHA one, and importantly the SAHA two
Speaker 2: five six family. There's a handy script often used called
Speaker 2: get file hash or similar functionality built in. Now it's
Speaker 2: important understand the difference.
Speaker 1: Though.
Speaker 2: MD five and SAHA one are okay for checking if
Speaker 2: a file got corrupted accidentally.
Speaker 1: But not if someone tried to tamper with it. Right.
Speaker 2: For protecting against intentional tampering, you really need SAHA two
Speaker 2: fifixer stronger. It's much harder to create a malicious file
Speaker 2: that has the same SAHA two fifty six hash as
Speaker 2: a legitimate one critical for checking software downloads, for instance.
Speaker 1: Corrupting smart scripts and automating tasks.
Speaker 2: Okay, So We've covered interacting manipulating files and data, but
Speaker 2: the real magic for many people is automation. Right building scripts.
Speaker 1: Absolutely and PowerShell scripts are fundamentally just simple text files,
Speaker 1: usually with the PS one extension.
Speaker 2: So anything I type in interactively.
Speaker 1: You can put into it ot PS one file and
Speaker 1: run it again and again. That's the basic idea. But
Speaker 1: to make your scripts more robust and reusable, you'll quickly
Speaker 1: move to using functions. Functions let you package up a
Speaker 1: set of commands, give it a name, and then just
Speaker 1: call that name whenever you need that block logic. You
Speaker 1: can even control their scope, like is this function only
Speaker 1: available inside this script? Or can I use it anywhere
Speaker 1: in my PowerShell session?
Speaker 2: Right, and for applying custom logic to data as it
Speaker 2: flows through that pipeline we talked about.
Speaker 1: That's where fourch object is indispensable or it's alias percent.
Speaker 1: It lets you take each object coming through the pipe
Speaker 1: and do something specific with it. Perform calculations, call other
Speaker 1: commands whatever you need.
Speaker 2: This sounds incredibly flexible, but what about making these scripts usable?
Speaker 1: Like?
Speaker 2: If I write a script, how do I add instructions
Speaker 2: or explain the parameters? Make it easy for someone else
Speaker 2: or even me six months later to understand great question.
Speaker 1: PowerShell has a built in system for that, called comment
Speaker 1: based help. You write spec comments inside your script using
Speaker 1: specific keywords like synopsis, description, parameter, example.
Speaker 2: Ah okay.
Speaker 1: Then anyone using your script can just type get help
Speaker 1: your script dot ps one and they get nicely formatted help,
Speaker 1: just like for a built in siliment.
Speaker 2: That's brilliant makes your own tools feel much more professional.
Speaker 1: It really does. It's a best practice you should adopt.
Speaker 2: Early on and thinking about safety, especially if a script
Speaker 2: is going to change things delete files, stop services are
Speaker 2: their safeguards?
Speaker 1: Yes, definitely. PowerShell has what are called common parameters, and
Speaker 1: two of the most important for safety are what if
Speaker 1: and confirm.
Speaker 2: What if does that just show you what would happen exactly.
Speaker 1: If the Sambalat developer supported it, and most well written
Speaker 1: ones do. Using what if will make the command report
Speaker 1: what changes it would make, but it won't actually make them.
Speaker 1: It's like a dry.
Speaker 2: Run, perfect for testing, and confirm.
Speaker 1: Confirm makes PowerShell pause and ask you are you sure yeah?
Speaker 1: Forming the action for each item gives you that final chance.
Speaker 2: To back out, like a built in safety net.
Speaker 1: Precisely, very very useful. Especially when you're starting out or
Speaker 1: working with critical systems. That's a key point. And you know,
Speaker 1: PowerShell doesn't just live in its own bubble. It lets
Speaker 1: you reach out into other core Windows technologies. You're not
Speaker 1: limited to just it's built in somemeloans how so well
Speaker 1: for starters, you have direct access to the entire dot
Speaker 1: net framework.
Speaker 2: Which is huge, right, that underlies a lot of Windows.
Speaker 1: It's massive, millions of pre built classes and functions for
Speaker 1: doing almost anything, advanced math, file operations, networking, cryptography, UI elements,
Speaker 1: you name it. If PowerShell doesn't have a cmdallet for
Speaker 1: something specific, chances are you can do it using a
Speaker 1: dot Net class directly from your script.
Speaker 2: Wow.
Speaker 1: And beyond dot Net, you can interact with older CAMM objects,
Speaker 1: though much of that is less needed now thanks to
Speaker 1: native PowerShell features, and you can even get down to
Speaker 1: calling low level Windows API functions using a technique called pinvoke,
Speaker 1: so you.
Speaker 2: Can really bridge almost any gap if you need to.
Speaker 1: Pretty much. It makes PowerShell incredibly.
Speaker 2: Extensible orchestrating and managing at scale.
Speaker 1: Okay, so, once you're comfortable automating things on your own machine,
Speaker 1: the next big step is often managing multiple computers, right, okay,
Speaker 1: whether it's servers in a business or maybe just a
Speaker 1: few PCs at home.
Speaker 2: Exactly, And that's where PowerShell remoting becomes incredibly powerful.
Speaker 1: How does that work basically?
Speaker 2: Well, first you need to enable it on the target machines,
Speaker 2: usually with a command like enable ps remoting. It sets
Speaker 2: up the necessary firewall rules and services securely. Once that's done,
Speaker 2: you have a couple of main ways to interact remotely.
Speaker 1: Okay.
Speaker 2: You can use enter ps session computer name. This drops
Speaker 2: you into an interactive session on the remote machine. It
Speaker 2: feels almost exactly like you're sitting right there typing at
Speaker 2: its local console.
Speaker 1: So it's like SSH but for PowerShell.
Speaker 2: Very similar concept, yes. Or for running commands non interactively,
Speaker 2: especially on many machines at once, you use invoke command
Speaker 2: Invoke command right, You give it a list of computer
Speaker 2: names and a script block commands you want to run,
Speaker 2: and it executes them in parallel on all those machines
Speaker 2: in parallel.
Speaker 1: That sounds efficient, hugely efficient.
Speaker 2: You can control how many runs simultaneously with throttle limit
Speaker 2: and even run. The whole thing is a background job
Speaker 2: using as jobs, so your local console isn't tied.
Speaker 1: Up and I read something about import pa session. That
Speaker 1: sounds intriguing.
Speaker 2: Ah, yes, that's a really clever future. Imagine a remote
Speaker 2: server has some special PowerShell module installed with commands you need,
Speaker 2: but you don't have it locally. You establish a session
Speaker 2: to that server, then use import PA session. PowerShell implicitly
Speaker 2: brings those remote commands into your local session.
Speaker 1: So they just appear like local commands exactly.
Speaker 2: When you run one, PowerShell transparently sends the command back
Speaker 2: to the original remote machine for execution and returns the results.
Speaker 2: It makes managing specialized remote systems feel seamless. Now, for
Speaker 2: really complex, long running tasks, maybe something that involves coordinating
Speaker 2: steps across multiple machines and needs to survive reboots or
Speaker 2: network interrupts, PowerShell offers something called workflows.
Speaker 1: Workflows all right, how are they different from regular scripts.
Speaker 2: They're built on a different engine, the Windows Workflow foundation.
Speaker 2: They're specifically designed for orchestration and resilience. Think of tasks
Speaker 2: like provisioning a new server, which involves multiple steps, some
Speaker 2: potentially slow, maybe on different machines. A workflow can manage
Speaker 2: that entire process, and if it gets interrupted halfway through,
Speaker 2: it can often resume where it left off.
Speaker 1: Okay, that sounds useful for complex automation. And within these
Speaker 1: workflows you can run things in parallel.
Speaker 2: Yes, you can define parallel blocks, so if you need
Speaker 2: to say, copy large log files from several servers simultaneously
Speaker 2: before processing them, a workflow can handle that concurrent execution easily.
Speaker 1: And can you still use regular PowerShell commands inside them?
Speaker 2: You can, yes, within special inline script blocks, so you
Speaker 2: get the robustness of the workflow engine plus the flexibility
Speaker 2: of standard PowerShell scripting. Now shifting slightly. When we talk
Speaker 2: about robustness and IT systems, the concept of tr transactions
Speaker 2: often comes up right.
Speaker 1: Like with databases or bank transfers, either everything succeeds or
Speaker 1: nothing does.
Speaker 2: Atomicity exactly that principle ensuring consistency. Powershall actually supports transactions,
Speaker 2: primarily for managing the Windows registry, but potentially other things too.
Speaker 2: You use start transaction to begin a transaction block, then
Speaker 2: any cmittle it's you run with the dead use transaction
Speaker 2: parameter are part of.
Speaker 1: That transaction, and then something goes wrong.
Speaker 2: If an error occurs, or if you explicitly call undue transaction,
Speaker 2: all the changes made within that transaction are automatically rolled back.
Speaker 2: The registry or other transactional resource is left exactly as
Speaker 2: it was before you start it.
Speaker 1: So you can guarantee a set of changes either all
Speaker 1: complete or none of them take effect precisely.
Speaker 2: It's key for maintaining system integrity during complex configuration changes.
Speaker 1: And finally, one more advanced topic, making scripts react to
Speaker 1: things happening on the system.
Speaker 2: Event handling, Yes, power shall provides a really unified way
Speaker 2: to handle system events. This could be dot net events,
Speaker 2: WMI events, which cover a huge range of system activities
Speaker 2: like services, stopping processes, starting hardware changes, or even custom
Speaker 2: events your own scripts generate.
Speaker 1: So my script could automatically trigger when, say, a specific
Speaker 1: service stops unexpectedly.
Speaker 2: Exactly you register an event subscription using register object event
Speaker 2: or register WIMI event, specifying the event you're interested in,
Speaker 2: and action a script block to run when that event fires.
Speaker 1: That opens up possibilities for really dynamic, responsive administration.
Speaker 2: It really does you move from just running scripts on
Speaker 2: a schedule to having scripts intelligently react to the state
Speaker 2: of the system in real time. HASHTAGA, hashtag out trip.
Speaker 1: So after all that, what does this really mean for you?
Speaker 1: The listener? The informed digital citizens? We talked about We've
Speaker 1: only really scratched the surface of what Windows PowerShell can do,
Speaker 1: but hopefully you've seen it's way more than just a
Speaker 1: fanci or command prompt. From its core object oriented nature
Speaker 1: that just simplifies everything to its amazing remoting and workflow
Speaker 1: stuff for managing things at scale, PowerShell is this deeply integrated,
Speaker 1: super adaptable tool. It helps you automate, manage, and genuinely
Speaker 1: understand your Windows environment much better. It really feels like
Speaker 1: a shortcut to being well, incredibly capable and efficient.
Speaker 2: Yeah, and that really raises an important question for you,
Speaker 2: doesn't it. How will you start using this? How will
Speaker 2: you begin applying some of this power? Maybe just by
Speaker 2: playing with the discovery commands we mentioned, get command, dash
Speaker 2: verb get to see all the things you can get
Speaker 2: or get help, get process full to really dig into
Speaker 2: one command, or maybe pipe some command output into outgridview.
Speaker 2: That's a fantastic way to visually explore the rich object
Speaker 2: data we've been talking about.
Speaker 1: Oh yeah, outgrid to you is great.
Speaker 2: Remember, getting PowerShell is partly a shift in mindset. It's
Speaker 2: moving from thinking about text to thinking about structured objects
Speaker 2: and making that shift that's what unlocks the immense power
Speaker 2: it offers.
Speaker 1: We definitely encourage you to experiment try out some of
Speaker 1: the commands we mentioned today. See for yourself how PowerShell
Speaker 1: can really transform how you approach, manage your digital world.
Speaker 1: Until next time, keep learning and keep exploring.