Why you need to learn PowerShell

 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.


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!


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


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.

Comments (8)
  1. John Ludlow says:

    I think PowerShell would gain a lot of traction with IT pros if developers were exposed to it more, because a lot of IT pros use the tools that a product’s developers ship with it.

    The package manager console in VS is fine, but it’s seen as being for, well, (nuget) package management. Outside of VS, the developer command prompt is cmd.exe. If MS turn the PM console into just a console and show how it can automate code, and turn the default
    Dev command prompt into a PowerShell one (in other words, port vsdevcmd.bat to PowerShell), developers become more familiar with its goodness.

    That might mean they start shipping PowerShell functionality for IT pros to use (for example, rather than a command line client for your server product, a PS module?).

  2. BlBrothers says:

    I think that it is necessary to make IT pros understand that PowerShell ISE -for example- is a tool in itself, but with a huge wide of options that helps to get control of their systems, tasks about services, management of user and permissions, backing
    up, customization of environments, and so on, and helps to integrate all the tools they are used to use.

    Developers can help IT pros to get their goal by developing the scripts they need; but for this, both need to change their mind, and see they both need each other.

    I discover PowerShell a few years ago, and from that moment, our team have implemented all kind of scripts, for developers and for IT pros. Everything around deployment. From then, the hence between the two teams disappeared, and now they all are used to create
    their own scripts, to get much more control on every kind of task. Everybody feel more comfortable.

    Powershell should be considered as a meeting point, and the starting line for new It generations.
    Thanks Richard!

  3. Harry Eagles says:

    Very interesting line of thought John, thank you for sharing. It would be interesting to see how many Pros feel the same way!

  4. Harry Eagles says:

    Great to hear BIBrothers! We love hearing about the different ways IT Pros and Devs are working together

  5. Greg Montessori says:

    To make PowerShell more popular, Microsoft should:

    * Require more PowerShell on certification exams.

    * Have Satya Nadella and other executives publicly mention it more; Jeff Snover cannot do it all by himself.

    * Give more coverage to PowerShell at conferences and other events.

    * Make it the default shell on Windows 10 and later.

    * Require PowerShell training for Microsoft's own developers and PMs who create APIs or other services exposed to the outside world. Upper management should "lay down the law" that PowerShell is the future and that PowerShell integration (or at least compatibility)
    is nearly mandatory.

    * Add PowerShell support in Visual Studio and MS Code by default, not just as an optional add-on, and make "PowerShell Project" a default available project type.

    * Make it very easy to write Universal GUI apps that use PowerShell in the background (or perhaps written entirely in PowerShell).

    * Promote PowerShell over VBA for Office applications and macros.

    * Accelerate the development of OneGet and Chocolatey to make the package management rock-solid, pay for the development of some must-have packages, and then promote it.

    * Make it clear under what circumstances PowerShell code will be JIT-compiled, or even given the option to pre-compile the entire PowerShell script, to help dispel any myths about PowerShell performance issues.

    * Emphasize that learning PowerShell is a gentle way to later learning C#. In general, emphasize the similarities between PowerShell and C# since C# is already very popular.

    * Release a library of security and deployment templates in the form of Desired State Configuration scripts. Make DSC as easy to use as possible.

  6. Anonymous says:

    PowerShell MVP Richard Siddaway continues his PowerShell series, this time looking at how you can get started by solving a problem in your environment.

  7. Anonymous says:

    PowerShell MVP Richard Siddaway shows you step-by-step how to easily and effectively manage your GUI-less Server Core with PowerShell

  8. Anonymous says:

    It’s awards season and what better time to celebrate the work of our great contributors?

Comments are closed.

Skip to main content