Get-PowerShell Andy Schneider's Blog about Windows PowerShell

One of the biggest features of PS V2 is the ability to do remoting. It's great to be able to run a ScriptBlock against a bunch of computers.

In the first version of the CTP, one issue I had was that I couldn't tell which object came from which computer.

It looks like CTP2 has a resolution to this. They tack on a ComputerName property to objects that are returned from a remote connection.

Notice that if I do a get-process on a local computer there is no ComputerName attribute.

However, if I get an object back from a remote system I can get a ComputerName attribute.

I am using the icm alias for the invoke-command cmdlet against a runspace that has 3 remote computers, Powershell-dev1, Powershell-dev2, and Powershell-dev3.

What I think would be nice is to have ComputerName be a default property that gets displayed automatically when you list a remote object. That way you wouldn't have to explicitly use select object or format-table/format-list to see the attribute.

A couple weeks ago we hired an intern. I recently gave him a task to create a bunch of DSN's on some servers. I told him to take some extra time and maybe figure out how to script it, and also let him know that I thought all the info was stored in the registry.

He came back into my office  later on in the day with a big smile exclaiming "This is awesome! Did you know you can navigate the registry just like a file system in Powershell ?"

I just love being there in the moment when the light bulb goes on and someone new "gets" Powershell. Its a beautiful thing!

This was another one of those "Ah Hah!" moments with Powershell. Yesterday Jeffrey Snover wrote up a great post showing how to use ScriptBlocks as parameters in a pipeline.

This reminded me of a great podcast where Scott Hanselman interviewed Bruce Payette. Back when I first listened to it, they were talking about ScriptBlock parameters and it went completely over my head.

Now if you couple their discussion on the podcast with Jeffrey's post, you can come out with some incredibly powerful knowledge and understanding of Powershell.

Also, if you are not listening to Scott's podcast on a regular basis, I have one question for you. Why the heck not? He covers all kinds of great topics from HDTV to web development.

I am really looking forward to coming home and trying this out on my Mac. Igor  Moochnick has built Pash (Posh + Bash).  I can't wait to check it out. Perhaps I was wrong when I was discussing Text vs Objects.

I am really looking forward to seeing where this goes. Good stuff!

Anybody that has been using Powershell has created a function at some point. A function is simply a named ScriptBlock that can accept parameters. Also, you very likely know that there is a Function provider in Powershell. But I am willing to bet a lot of folks haven't used the provider all that much. If I am wrong, I would love to hear some feedback on the topic.

So here I am going to create a basic function and then we will look at what we can do with the function provider to manipulate it.

   1: 6 >  function foo {"Hello $args"}

   2: 7 >  foo world

   3: Hello world

So now that we have a new function we can cd into the function drive as follows. Notice that now we can get some cool info about the function we just created.

   1: 11 >  cd function:

   2: 12 >  ls foo | fl

   3:  

   4:  

   5: Name        : foo

   6: CommandType : Function

   7: Definition  : "Hello $args"

Since we are in the function directory, we can rename a function quite easily.

   1: 15 >  rename-item foo bar

   2: 16 >  bar world

   3: Hello world

   4:  

   5: 17 >  ls foo

   6: Get-ChildItem : Cannot find path 'foo' because it does not exist.

   7: At line:1 char:3

   8: + ls <<<<  foo

   9: 18 >  ls bar | fl

  10:  

  11:  

  12: Name        : bar

  13: CommandType : Function

  14: Definition  : "Hello $args"

There is no longer a function called foo but we do have a function named bar with the exact same definition that foo had originally.

Armed with this information, occasionally I like to take a look at what one of my functions looks like.

To do this all I need is to run get-content on a function, or use the alias cat.

   1: 28 >  cat Function:\Add-Assembly

   2: param($name) return [System.Reflection.Assembly]::LoadWithPartialName($name)

There's a cool site over at http://wsman.msft.net/ that has some examples of using MRTG (Multi Router Traffic Grapher) coupled with Powershell and Win RM.

There are some Powershell scripts up there that show how to access data with WinRM in Powershell and cast it from XML to a rich PS based object.

Take a look!

I recently had  a situation where I needed to be able to search an event log for a particular value.

I wrote a quick little script so that our PM could run it with little effort

   1: param ($name)

   2: $user = '*' + $name + '*'

   3: get-eventlog application | where {$_.Message -like $user} | 

   4: format-list Message,TimeGenerated

I am basically searching for event logs that contain a particular name.

It's pretty straight forward once you find that .Message is what contains the real meat of the event log entry.

You could also obviously use get-eventlog system as well.

Since the release of Powershell there have been a variety of discussions in the community debating which is more powerful, objects or text in a shell environment. Really it depends on what you are managing with  the shell.

In the case of the *NIX world, there is a bunch of configuration files that need to be changed, and for this a text based shell is a great thing. A text based shell to manipulate text is completely appropriate.

The world of Windows is a very different story. Windows was not built around configuration files. It is an OS that is accessed and manipulated using API's and a set of objects. This of course leads into why Windows needs an object based shell.

What is really comes down to is using the right tool for the job. I am not so sure I would want to manage a Linux server with Powershell, nor would I really want to manage windows with bash.

I find it amusing that the longest task that occurs the first time you log into Server Core is "Preparing Your Desktop."

I can just here the server now... "where the heck am I going to put that console window anyway?"