Introduction to Windows PowerShell

I gave a demo of PowerShell at our OU Admins Christmas Event last December, and I’ve mentioned it a couple of times on mailing lists, but for everyone who missed those or wasn’t convinced, here’s my Introduction to Windows PowerShell…

PowerShell is a command shell and language focusing on Windows system administration. It can be used interactively to get immediate results, or you can write complex scripts and do batch processing. Although it is still not used as much as it should be, PowerShell isn’t a brand new product; it’s been around for a couple of years and version 2 is currently available in its 2nd Community Technical Preview.

Now that PowerShell is part of Microsoft’s Common Engineering Criteria (meaning that product teams pretty-much have to incorporate PowerShell into their new releases), and being incorporated as a feature in Windows Server 2008, you’ll see PowerShell usage sky-rocket! (It’s worth also saying that Microsoft aren’t the only ones adding PowerShell support to their products – VMWare, IBM, Citrix and others see the potential of managing their products this way.)

The thing that sets PowerShell apart from other shells is that it uses pipelines of objects, not of text. It is build on the .NET Framework, but you don’t need to have a developer’s appreciation of .NET to work with PowerShell. In fact one of the best ways of getting started with PowerShell is to just run it each time you were about to run cmd.exe – many of the things you’d want to do there work in PowerShell. If you’ve been a *nix admin in the past, you’ll find that some of the commands you’re familiar with work in PowerShell too.

For example, the PowerShell cmdlet (pronounced “command-let”) to list the contents of a folder, Get-ChildItem, has aliases built in, so that you can use either dir or ls in its place. The interesting thing with PowerShell is that it has providers which let you access other repositories (referred to as PSDrives) in the same way as the file system, so you can do this:

cd HKLM:\software
dir

…and see the contents of a registry hive! (Note that if you want to do a recursive directory listing, the parameters are different to the dir in cmd.exe, so you’ll want to check the help to see what you can do with the cmdlets)

Give it a go and I’m sure you’ll soon find your way around. To get started, Get-Command gives you a list of the available cmdlets; Get-Help [cmdlet] tells you what they do; Get-Member lists the properties and methods of an object; Get-PSDrive lists the PSDrives that are available to you. Knowing those cmdlets is enough to get you quite a distance.

The TechNet Script Center has a load of great resources for IT Pros at and there’s a fantastic community building around PowerShell, with a UK User Group (run by Richard Siddaway who is a PowerShell MVP – details on his blog), numerous PowerShell bloggers, and community sites. There are also a bunch of PowerShell books, most of which are pretty good, but if you’re just looking for one I’d recommend Lee Holmes’ PowerShell Cookbook.

If you don’t find that there’s support built in to products or PowerShell itself for what you want to do, there may be a 3rd party snap-in that could help. I’m making used of the free Active Directory cmdlets from Quest Software, the free Group Policy management cmdlets from SDM Software and the PowerShell Community Extensions – a large suite of additional cmdlets, providers, functions and more.

I’ll leave you with a quick PowerShell example. This is a cut down version of something that we used yesterday to enumerate the members of all the AD groups in a particular OU and save the listing for each group in a separate file named after the group:

Get-QADGroup -SearchRoot "OU=Groups,OU=ISS,DC=campus,DC=ncl,DC=ac,DC=uk" | %{$name = $_.name; Get-QADGroupMember $name | Out-File "$name.txt"}

It has probably wrapped in your browser, but that’s just with one line of PowerShell and frankly a good chunk of it is specifying the OU that we’re looking in! If you want to run that, you’ll just need to change the OU and have the Quest AD cmdlets installed. I won’t explain how it works here – I just wanted to show how much you can do with so little PowerShell. How much effort/code would it take to achieve that task another way?!

This summer all of our student user accounts will be provisioned entirely with PowerShell scripts. Keep an eye on this blog for future posts about PowerShell tools, resources and code samples.

This entry was posted in ActiveDirectory, PowerShell by Jonathan. Bookmark the permalink.

About Jonathan

Windows Server infrastructure administrator at Newcastle University since 1999. Microsoft MVP for Cloud and Datacenter Management (& previously for PowerShell). Member of the Microsoft Technical Community Council. Co-founder of the NEBytes user group. @jonoble on Twitter.

3 thoughts on “Introduction to Windows PowerShell

  1. That slowness is caused by instantiating the .Net Framework and it’s what currently makes PowerShell slightly inappropriate for the likes of login scripts. That’s why we haven’t seriously looked at rolling PowerShell out across the domain.

    In my mind, the time to do that will be with PowerShell V2, when we can take advantage of the improved performance and remoting features.

    That being said, it is on my list of items that I think should be installed in the Vista cluster desktop which we’ll be looking at more in the Autumn.

    In the meantime, you can deploy it by running the installer with the /quiet switch on machines in your OU, or you could use Karl Prosser’s method to make a portable PowerShell.

  2. Thanks Jon. It’s a command shell not just a scripting language, therefore really needs to be one’s primary command line interface to the system. That means it could do with being on all the systems in our OU, as I frequently need to visit a users machines, or log on remotely with psexec/remote desktop.

    Thinapp looks interesting but rather pricey ..

Leave a Reply

Your email address will not be published. Required fields are marked *