ad.min.i.an

In the PowerShell Overview Post we discussed what PowerShell is and got it installed on the machine. Now lets talk basics: variables, cmdlets, and aliases.

First, a little about Objects and classes. An object isn’t necessarily just data. It something we are going to be working with like a service. This service has properties and methods associated with it. To see this we can try the following…

get-service – lists the services on the computer
get-service | get-member – lists the properties and methods associated with an object returned by get-service.

These objects are represented by a class. The class is a blueprint or recipe for an object. Say we wanted to bake a cake. We’ll we’d follow a recipe to make and cake. In this analogy the cake is the object and the recipe is the class. Also, in the example above we used the ” | ” character. This is called a pipe and it allows us to pass the output of one cmdlet as the input to another. The get-member cmdlet will list all of the properties (attributes of the object i.e. DisplayName) and methods (preforms an operation i.e. Stop). So if we only wanted to see the members then we would use the following:

get-service | get-member -membertype property

This cmd will only list what properties we have available to us. Pretty awesome, but we can do more. We can use what’s called dot notation to access some these properties. We’ll use the get-date cmdlet here.

get-date – returns the date and time.
get-date | get-member -membertype property
(get-date).year

Ok, so we’re getting a feel for objects, their properties and methods. Now lets explore the cmdlet a little. Cmdlets naming convention is verb-noun. They are found in DLLs and there are quite a few provided and more can be added. The PowerShell Community Extensions are a must and I’d recommend adding them. It adds things like:

Get-ADObject
Get-DomainController
Set-FileTime (touch)
New-Shortcut

And scripts:

ConvertFrom-WmiDateTime.ps1
Export-History.ps1

There’s a lot more, but it should give you an idea of what’s there. So in keeping with the naming convention how do you thing we canget a list of commands? That’s right Get-Command and what is even cooler…we can specify parameters that stipulate the kind of cmdlet we’d like.

Get-Command
Get-Command -Verb set
Get-Command -Noun item

All of the topics we just discussed coupled with the Get-Help cmdlet make for a pretty good way of figuring out what we have at our disposal. Which is good, but this is still a lot of typing for instance say I wanted to view the contents of my current directory. Well there’s a cmdlet for that it’s Get-Childitem. Well that’s not an improvement over the “dir” command is it? Well it is because we can still use “dir”. Try it…yep it still works, but no this is not the little exe file you run from the DOS prompt. It’s actually an alias of the Get-Childitem cmdlet. If your a *nix guy then you have the same problem I do when in DOS…Typing things like “ls” well there’s an alias for this too. Yea I love aliases.

Get-alias – Shows a list of aliases and the cmdlet the alias.
Set-alias – allows you to set your own aliases.

And that leaves variables. Variables are storage containers that we can assign a value, object, or collection. They can be strongly or loosely typed. Meaning we can specify what the type of value is contained in the variable like an int (integer) – strongly typed. Or we can just leave it to PS to figure out – loosely typed. To create a variable we can prefix it with a “$” to denote it a variable.

$netLogon = get-service netlogon
($netLogon).status

Well I think we can just about call this in the bag. Play around with these topics because we’ll be using them…

I’m going to be working with PowerShell some this week and thought I would post about what I think. I’m a C# guy and know my way around the .Net Framework so we’ll see. I’ll also post some links to sites that lend a hand on this journey. So lets set out, but first: Pandora > Cake Radio … Golden.

PowerShell is an interpretive programing language that uses .Net classes and is highly extensible. What the heck does that mean? It’s a object oriented scripting language with a lot of power. It’s supported on Windows XP, Windows Server 2003, Windows Vista, and ships with Windows server 2008. Oh, and there are x86, x64 and Itanic…I mean Itanium-based builds. Awesome, so we have to install it to use it on all the machines we intend to run scripts on. This in my opinion is a design flaw in that we can’t run cmdlets against remote machines, but I digress (and we’ll define cmdlets soon).

So, take an administrator who understands automation and where it fits in the organization. I’ve had the opportunity to work with a few in large organizations. I’ve seen server teams consisting of 14 or more people doing deployments that take weeks cut that time down to hours. All by using scripting…Not a huge surprise to those of us who are in the know. Now this was using VBScript and WMI. And these scripts can range in length anywhere from 50 to 500 lines of code. That’s a lot of script to maintain…We’ve taken these scripts, ported them to PS and seen them reduced to oh 1 to 15 lines of code. Yea that’s the power part of PowerShell.

What other objects do we get to use while writing PS scripts? COM and WMI objects of course, here again I get ahead of my self. PS can also be extended in different ways. We can add 3rd party providers like for instance a VMware provider to manage your VM infrastructure from PS? Also, we can create our own cmdlets. The SQL server cmdlets are a great example of this. These allow us to manage our SQL Servers we have laying around. You want an example of this you say? OK, Invoke-Sqlcmd -Query does just what you’d expect. It allows us to query our SQL server metadata or databases…sweeet!

lets get to installing. First make sure you have at least .Net 2.0 installed 3.5 is current. Then go out and download PS from here. The installation is a piece of cake, so don’t sweat it. There are a couple things to note. The default location of PowerShell is C:WindowsSystem32WindowsPowerShellv1.0. Here you will find the configuration files and will be doing some PS-foo with them later.

The first hurtle we run into with running a script is the execution policy. It’s set to restricted which prevents us from running .PS1 files. The PS1 file extension represents a PS script. There are a couple of cmdlets that allow us to view and change this policy.

get-executionpolicy – this shows what the policy is set to. More info here.
set-executionpolicy – allows us to change the policy. More info here

The set-executionpolicy cmdlet polices can be found here, but for our discussion “RemoteSigned” will do the trick. This allows us to run scripts, but requires a digital signature for scripts that are run from a remote location. We’ll be running our script from our local machine, so this should suffice. A parameter we should note is the “-whatif” switch. This allows us to simulate what would happen if we executed the command. This handy little switch is around a lot and I’ll do my best to point it out.

So there’s a quick overview of Powershell.