You Should Learn PowerShell

Den W. Den W. 18 November
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.You Should Learn PowerShell 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. You Should Learn PowerShellI could also pipe "Get-Date" into the "Select-Object" cmdlet and choose  which properties I want to see. You Should Learn PowerShellAnother 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. You Should Learn PowerShellTo 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. You Should Learn PowerShellThere 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. You Should Learn PowerShell

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. You Should Learn PowerShellThe 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. You Should Learn PowerShellOK,  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.You Should Learn PowerShell 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.You Should Learn PowerShell 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.  

Comments (0)

    No comments yet

You must be logged in to comment.

Sign In / Sign Up