You Should Learn PowerShell

You Should Learn PowerShell



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 article 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.

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 read my article about the new Windows Terminal.

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 a 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.
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! 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.  

You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


You Should Learn PowerShell


Report Page