If you work with Windows a lot, and especially if you work in IT, then if you don't know how to use
PowerShell you are holding yourself back. In this video I'm going to explain what PowerShell is,
why you really ought to learn it, and I'll give you a few tips on how to get started.
Welcome back to The Pro Tech Show, where I cover tech, tips, and advice for IT pros and decision-makers.
One of the things I really like about my job is that I get to work with a lot of
different people. Something I've noticed is that a lot of IT admins are intimidated by PowerShell.
Usually, you'll find this with people who've been working in a Microsoft-only environment for a
number of years, where everything is point and click. The command line isn't something
they're familiar with, and they don't really know where to get started, so they just don't use it.
I contend that this is a mistake. Using PowerShell can save you a ton of time by making tasks easily
repeatable and scalable. It's also now in a lot of cases the primary method for managing Microsoft's
products. If you manage Microsoft's server or cloud products you'll often find that a particular
option just doesn't exist in the graphical tool and you have no choice but to use PowerShell.
So my argument is that if you don't learn to use PowerShell at least a bit you're going to be slower
at your job, you're going to be limited in the size of environments you're able to work in, and any time
you need to change one of those PowerShell-only options it is going to be really scary, because
you won't actually know if what you're doing is correct or it's going to blow up in your face.
Although PowerShell is inherently a Microsoft technology, it's no longer limited to Microsoft
products. It's been adopted by a number of vendors as a handy mechanism for automation.
If you manage things in Azure, regardless of whether they're Microsoft-based or not you'll
find PowerShell useful. If you use AWS instead then guess what - you can still use PowerShell.
Later versions of PowerShell even run on Linux. I'm sure there will be a variety of opinions on that.
Let's start with the really basic question. What is PowerShell? It's not the same old command
prompt, but blue. PowerShell is a platform that consists of a shell and a scripting language.
If you want to learn about the difference between a shell and a console I recommend watching my
video about the new Windows Terminal, which I'll link below and up here. In terms of scripting,
PowerShell is massively more mature than the old command prompt because it comes with a full-blown
object-orientated programming language. PowerShell is built on top of the.NET framework, which
makes it incredibly powerful. Most of the time there'll be a PowerShell cmdlet available
for whatever you need to do; but if there isn't then you do have access to entire .NET framework.
If you can write a program to do it in C# then you can also do it in PowerShell. Although
writing full-on .NET code in PowerShell will get a tad clunky, it does basically mean you can do anything.
A lot of IT admins are not interested in programming, aside from some light scripting.
The way they're going to interact with PowerShell most often is through the command line console.
The bread and butter of using PowerShell are cmdlets. These are lightweight commands you
can type in to perform an action. The really nice thing about cmdlets is that they
all use a similar naming structure. This, in my opinion, makes PowerShell much easier to learn
than most command-line environments... even if it can make it a bit verbose at times.
Once you get used to the syntax then even if you don't know the command for a particular function
you can probably have a pretty good guess at it, based on what you're trying to do.
PowerShell cmdlets use the format Verb-Noun. The verb is the action you want to take.
The noun is the thing that you want to take the action on. Cmdlets all tend to share the same
verbs so you'll quickly figure out what verb you need based on what you want to do. For example, to
retrieve information about an object you'd use the "get" verb. To change an object you'd use the "set" verb.
To create a new object you'd use the "new" verb; and to delete an object you'd use the "remove" verb. This
convention applies pretty much universally. So if you want to get information about the services on
your computer you type "Get-Service". There are quite a lot of standard cmdlets that come baked
in with PowerShell, but its real strength comes from additional modules. PowerShell is used by
pretty much every Microsoft product these days and has been adopted by a lot of third parties as well.
When you install these products they often extend PowerShell's functionality by adding
their own PowerShell modules. These modules add new product-specific cmdlets and objects.
To avoid naming conflicts these modules usually add a prefix to the object name.
So the Nerb-Noun syntax can be extended to Verb-PrefixNoun. For example, the Active Directory
PowerShell module (which adds the ability to manage Active Directory using PowerShell)
uses the prefix "AD". So if you want information about an Active Directory user the verb is "Get"
because you want to get information, the prefix is "AD" because you're using the Active Directory
module, and the object is "User"; so you have "Get-ADUser". If you're doing the same thing for
a user in Azure AD you'd use the "Azure AD" module and the command would be "Get-AzureADUser".
Now let's talk about the response you see when you type a command. This one can be a little weird
to wrap your head around if you're not used to objects in a programming sense, but it's something
that makes PowerShell incredibly powerful. With the old command prompt what you saw was what you got -
text. With PowerShell what you see is a textual representation of an object. Let's look at the
"Get-Date" cmdlet. If I run that it spits back the current date, but if I take that object and use the
pipe operator (that's this vertical line) to pass it into the "Format-List" cmdlet it will display
the same object in a list and we can see there's more to it than what we saw in the initial summary.
A little tip for you: "Format-List" is very handy to see the properties of an object,
and you're probably going to use it a lot, so you can simply type "FL" for short.
The idea of PowerShell responses being objects which are made up of multiple properties is an important
one. You can select and filter on individual properties of an object. So if I take the output
of "Get-Date" and then say ".DayOfWeek" we can see that specific property. I could also pipe "Get-Date"
into the "Select-Object" cmdlet and choose which properties I want to see. Another tip for you:
Select-Object is another common cmdlet that has a shorter alias, so you can just type "Select" instead.
OK. You've seen a bit of PowerShell, but what's the benefit for you? Let's have a look at the way
you might use it. You are now the Active Directory administrator for Wayne Enterprises and its
subsidiaries. The CEO, Bruce, has decided that HR is an outdated and unfriendly name, and orders HR
to be rebranded as the People team. Your job is to update AD accounts to reflect this; but not before
you like and subscribe, because when Bruce Wayne tells you to subscribe... well you don't want to
mess with that guy! Back to Active Directory, though. Wayne Enterprises has quite a few user accounts. You
could do this in AD Users and Computers, but doing it one account at a time is going to take a very
long time. With PowerShell we can accomplish this task with a single line. Let's take a look. Rather
than just run the command straight off, I'm going to build up to it so you can see how it works. The
first important cmdlet is "Get-ADUser", which we've mentioned before. Active Directory objects
can have a large number of properties, so rather than return all of them, "Get-ADUser" only returns
a small number by default and you have to tell it which others you want. In this case we're going to
want the "Department" property. You can also provide a filter to scope which objects are returned.
If I give that an asterisk to return all of them, that spits back way too much information! In fact
I'm having to speed the video up here to get through it. If all you want to know is how many
users there are, you can pipe that into the "Measure- Object" cmdlet, or "Measure" for short. To get a
view on what we're facing I'm going to pipe it into the "Group-Object" cmdlet, or "Group" for
short, and group the results by the department property. There we go - we've got 522 HR people
left to be renamed. Wow, they've really hired a lot of HR people! As you probably guessed, I just
generated these accounts using PowerShell. There was no logic behind how many got put in each team.
Let's say we want to return just the people in the HR departments. We could change that filter
parameter to do that. If we measure that output now you can see we've filtered out everything but the
522 HR people. If I want to change this property on a user using PowerShell, I can do that using
the "Set-ADUser" cmdlet. Now, I could specify a specific user here to do this user-by-user, but
that's just as slow as doing it by pointing and clicking on each user account, individually. Instead,
I can take that "Get-ADUser" command we used before and pipe it into the "Set-ADUser" command like this.
The first part of that retrieves every user account where the department field is set to "HR",
and the second part changes the department field to "People" for all of those accounts.
Instead of spending the rest of the day pointing and clicking, we've accomplish it all in a matter
of seconds. If I go back and regroup all of those user accounts, you can see we now have 523 users in
the People department. That's the 522 changed by PowerShell plus the one I changed previously in
AD Users and Computers. Another good use of PowerShell is to automate repetitive tasks.
If there's something you need to do every day, put it in a PowerShell script
and schedule it to run every day by itself. Remember people: work smart, not hard.
Now, you might be wondering how you're supposed to know what the cmdlet are that you need to use.
Yes, the naming convention helps, but it doesn't completely solve the learning problem or tell
you what parameters to use. There are a few things that can help with this. Firstly, when you start
typing you can hit "tab" to fill in the rest of the word based on what you've already typed, and keep
hitting "tab" to cycle through various options. If you sort of know what you're after, but not quite;
that can help fill in the blanks, and it's a handy time-saver. There is a cheeky shortcut you can use
though, if you don't know where to start. Some of Microsoft's more modern graphical interfaces are
really just glorified PowerShell generators. When you click about you're really just constructing a
PowerShell command behind the scenes which gets executed when you click "OK". Let me show you with
the Active Directory Administrative Center. OK, unrelated question here. Do any of you actually use
this tool on a day-to-day basis? I ask because it was introduced in Windows Server 2008 R2
and it seems like it was supposed to replace AD Users and Computers snap-in that's from...
what? 2000? From what I've seen, though; people use it to enable the recycle bin, maybe for fine-grained
password policies, and other than that they just use the old snap-in instead; because it's faster.
Sorry, complete tangent there. I'm just interested if that's only my experience, or yours as well. Let
me know in the comments, would you? Back to the AD Admin Center. This is one of those graphical
tools that is basically a PowerShell generator. If I pick a new user here and change the department,
you can open this PowerShell history panel to see the PowerShell that got executed.
So if you want to automate a task or run it at scale, and you're not sure what the PowerShell is;
click through in the graphical tool and have a look at the PowerShell it generated.
The same thing works for Exchange as well, by the way. That aside, if you want to get a list of all
available commands you can type "Get-Command". That might be a bit overwhelming but chances
are you know what module you're after, if not the cmdlet itself. So you can narrow that down
by specifying the module name. Once you figure out what cmdlet that you want, you can type "Get-Help"
and then the name of the cmdlet to see its documentation. If you put "-Full" on it you get
very detailed documentation, along with examples. In fact, you'll find it's very similar to Microsoft's
online documentation; because that is in fact where your offline help gets downloaded from.
Whilst it is really handy to have access to all of that level of documentation from the command line,
I have to be honest. I rarely do that. If I want to check the options available for a cmdlet, I'll
pop it into Google. The first hit is generally the Microsoft documentation page which contains the
same information, but in a browser where I can read it a lot more comfortably. Why make life difficult?
Formatting exists for a reason! I'm going to wrap this one up in a minute, but a little caution first.
There are lots of PowerShell tutorials out there. I hope I've managed to convince you that it's
worth giving a go. Maybe it's not quite as scary as it may have first appeared. But with great power
comes great responsibility. Yeah, I realise I'm mixing my references, now. We've left Batman behind.
PowerShell is great for making changes at scale, but that does also mean you need to pay attention to
what you're doing. If you click your way through object-by-object you can only break one thing
at a time. With PowerShell you are fully empowered to break hundreds or thousands of objects at once.
So if you're going to make a change to hundreds of accounts like I just did,
a bit of testing first can prevent a typo from causing you a whole world of trouble. That's
it. We're done! Go and have fun automating things. But before you do that, watch one of these videos
over here. I mean you've made it this far. Why stop now? If you found this helpful give it a thumbs up, say
"hi" in the comments, and maybe even subscribe. Thanks for watching, guys. See you next time!