Why you need to learn PowerShell

  • Article

By Richard Siddaway, PowerShell MVP and author on a number of books on PowerShell, Active Directory and Windows Administration. He is a regular speaker at the PowerShell Summit and user groups, and blogs regularly on his PowerShell blog.

PowerShell is nine years old. So why write an article explaining why you need to learn PowerShell?

Even though PowerShell usage has increased dramatically since its introduction in November 2006, many IT Pros still aren’t using PowerShell on a regular basis, or even at all. There may be many reasons why you aren’t using PowerShell – lack of time to learn; no need in your job; GUI tools get the job done or even that you think it’s too hard.

During PowerShell’s nine-year lifetime your IT environment has changed dramatically. There has been three new versions of Windows Server; new versions of Exchange and SQL Server; the rise of virtualisation and a major game changer in the shape of cloud based technologies. These changes increase the complexity of IT environments. As an architect I’ve always tried to reduce the complexity of my customer’s IT environments, but technology changes often defeat that goal.

The rate of technology change is greatly accelerating – ‘cloud cadence’ is the rallying call these days, meaning changes are smaller and much more frequent. Rapid continuous change is the name of the game. Keeping your skills up to date so you can administer these new and changing technologies is a difficult and very time consuming task.

 

Does such a tool exist?

Wouldn’t it be great if there was a tool where you could learn the basics and then apply that knowledge across the technologies you’re going to be working with? Thinking of an example environment you might have:

  • Windows Server 2008 R2, 2012 and 2012 R2
  • Office 365
  • SQL Server 2012
  • VMWare
  • Hyper-V
  • Active Directory, DNS and DHCP
  • IIS and web applications
  • File Shares and DFS
  • Network switches
  • A few Linux machines

Better still you want the tool to be able to manage other third party technologies such as Citrix, and technologies that you may adopt such as Azure or SharePoint.

The good news is that it already exists. It’s called PowerShell.

With PowerShell you can manage everything listed above and a whole lot more - If you want to see the scope of managing Windows servers take a look at TechNet. The list of things you can manage is huge – and growing. Windows Containers are a hot topic for windows Server 2016. The PowerShell commands to manage containers already exist.

 

So what is PowerShell?

Ask a number of PowerShell experts and you’ll get a range of replies:

  • Command line interactive shell
  • Scripting language
  • Development language
  • Automation engine
  • Workflow engine
  • Configuration manager

They’ll then start arguing with each other which is highly entertaining, but it doesn’t help you answer the question. In reality PowerShell is all of these things. At its most basic you are working in an interactive command line shell.

The figure above shows a PowerShell interactive console on Windows 10 (PowerShell 5.0). The first command shows the command to retrieve the PowerShell processes currently running on the computer:

All PowerShell commands, known as cmdlets, have a Verb-Noun naming convention. The list of verbs is small and tightly controlled. If you want to get some information the cmdlet will always have ‘Get’ as the verb. The noun should be singular. Following these rules, you won’t be surprised to learn that if you want to retrieve information on your machines services you use Get-Service.

Pipelines

Running single commands can enable you to complete a lot of useful tasks, but the real strength of interactive PowerShell comes when you link commands into what’s known as a pipeline. You’ve probably seen pipelines before in the DOS style command shell on Windows for instance:

Dir | more

The big difference with PowerShell is that you’re not piping text like the old style DOS shell or Unix/Linux shells – you’re piping .NET objects.

This is the point at which lots of IT Pros pull a face and start to edge away. Stop. You don’t have to be a .NET developer to use PowerShell. You don’t really need to know anything about .NET to use PowerShell. At this stage just knowing you’re dealing with objects and that objects have properties is more than enough.

That leads into the second command in the figure:

This should be more or less readable. Get the processes on the machine. Pipe them into a sort command. Sort on the CPU property in a descending manner. Select the first 5 objects.

Sort and select are aliases (shortcuts) for Sort-Object and Select-Object respectively. If the full names are used the commands would look like this:

Notice that –Property has been added to the Sort-Object command. This is a parameter. By default, Sort-Object assumes that any text not recognisable as a parameter will be treated as the name of a property (this is a simplification but sufficient for now – I’ll explain fully in another article).

 

PowerShell Integrated Scripting Environment

As well as the PowerShell console you also get the PowerShell Integrated Scripting Environment, or ISE.

You have two panes in the ISE. On the right you have an editing pane where you can edit your scripts. The figure shows the same two commands that you saw in the console. The left hand pane shows the results. It can also be used to interactively run commands.

Tab Completion

ISE, and the console, come with tab completion – type part of the command name and press the Tab key. PowerShell will complete the command. This works for cmdlet names, parameter names and parameter values where the values must be one of a pre-defined collection of values.

 

Remote Administration

Running commands against the local machine is great and you can achieve a lot, but you have tens, hundreds or even thousands of machines in your environment. PowerShell has a built-in mechanism for remote administration. Many cmdlets have a –ComputerName parameter that allows you to run the command against a remote machine:

In this case I’m using the environmental variable COMPUTERNAME to provide the machine name. $env: enables access to the store of environmental variables through the environment drive. PowerShell has a concept of providers that make a data store accessible in the same way as the file system. Two of the default providers are for the environmental variables and the registry. Yes, you can dir through the registry, or even Active Directory if you have the tools installed!

Remoting

If a cmdlet doesn’t have a –ComputerName parameter, you use PowerShell Remoting (subject of a future article). Remoting is the preferred option because it uses WS-MAN as the transport mechanism rather than DCOM or RPC which most of the cmdlet based remoting uses.

Remoting is enabled by default on Windows Server 2012, and later, but has to be enabled on earlier server versions and all client versions of Windows. Remoting was introduced with PowerShell 2.0 and you have complete intermixing of connectivity so a local machine can run PowerShell 2.0 to 5.0, and the remote machine(s) can run PowerShell 2.0 to 5.0 in any combination.

Piping commands together can accomplish a massive amount. The biggest gains come when you realise that you’re repeatedly using the same pipeline of commands. Saving that into a file with a .ps1 extension gives you a script that you can reuse. The next stage is to generalise the script, for instance add a parameter to the script so that you can change the computer against which the commands are run. You now have an administration tool that you can re-use and even share with others. Time to find a new problem to solve.

 

Creating a new user account in Active Directory

If you look at many older PowerShell books or search on-line you’ll find PowerShell scripts to perform a particular task. As an example here’s a script to create a new user account in Active Directory:

$ou and $domain set the Organisational Unit (OU) and domain in which you’ll create the account. In PowerShell the $ prefix indicates a variable. The user name is ‘UserD’. The [adsi] type accelerator - a shortcut for the System.DirectoryServices .DirectoryEntry .NET class - is used to create an object representing the OU. Its Create() method is used to create the user, and the SetInfo() method is used to write the new account back to Active Directory. You then need to set the samAccountName and the UserPrincipalName.

If you have a lot of users to create in a short time frame, then generalising that script and passing in the data through a CSV file is much quicker than using the GUI tools. Creating a script like that takes some research to work out what you need to do and then test the resultant code.

Creating a new user in PowerShell

Scripting has become a thing of the past for many tasks as there are PowerShell cmdlets that now perform the same task. If you want to create a new user, you can use the New-ADUser cmdlet:

The hard bit suddenly becomes much easier. This is true across a wide range of technologies; Windows Server 2012 saw a huge increase in the number of cmdlets available in PowerShell and the breadth of technologies you can administer.

 

But what does this actually mean?

It means that once you you’ve mastered the basics of PowerShell you can apply that knowledge across all of your environment – for example, a single script that creates an Active Directory account, enables a mailbox for the user and creates a home drive. All you need to do is supply the user’s name. Much quicker than opening the individual GUIs and performing the tasks by hand. More importantly the script will perform the activity in the same way every time it’s run which cuts out a lot of potential errors.

The rise of the cloud raises more complications with the need to administer an environment that could span one, or more, cloud providers and your on premise infrastructure. The main cloud providers supply PowerShell support so you have the tools to do this.

Whatever environment or technology you’re working against the PowerShell basics are constant. You only need to learn a new set of cmdlet names. Even that is made easy because of the Verb-Noun naming convention. You can work out the verb you need and then search for the appropriate noun using PowerShell’s built in command Get-Command. Once you’ve identified the appropriate cmdlet you can view the help file with Get-Help. The discovery and the help systems make PowerShell functionality an easy matter to find.

 

Get Learning!

Hopefully, this has inspired you to start learning PowerShell. This is the first in a series of articles that will dig into various aspects of PowerShell. This article has been a bit wordy to set the scene, but in future articles we’ll dive into using PowerShell to solve real problems.

I’ll cover PowerShell resources in depth in another article but for now there are some good introductory books available – my favourites are:

Learn PowerShell in a Month of Lunches by Don Jones

And

Windows PowerShell Step by Step by Ed Wilson

The Microsoft Virtual Academy has a number of PowerShell courses and the UK PowerShell Group has meetings planned in London and Manchester.

PowerShell is here to stay and if you want to thrive in the increasing complexity of the modern IT Pro, you need to automate your administration. PowerShell is the tool to do that.