I just saw this on Micosoft.Public.Windows.Powershell

PASH - PowerShell open source reimplementation for "others" (Mac, Linux, Solaris, etc...) and Windows (including Windows Mobile and Windows CE)

http://pash.sourceforge.net/

It just gets better and better :-)

 Trevor

One of the things that comes up quite often in my PowerShell classes is using your own .Net types so I though I'd put up a couple of entries based on a demo that I do.

I've put a zip file with all of the code mentioned in these posts into my download area.

I created a small .Net assembly containing two types, Bank and Account.

and compiled them into a file called Accounts.dll.

Now I can use Reflection.Assembly to load the dll

and create and use objects from the assembly

In the next post I'll add a custom format file so that negative bank account balances are displayed a (1000) rather than -1000.

You invoke PowerShell from SQL Server Management Studio by right clicking on a node in the tree and choosing 'Start PowerShell'. This runs 'SQLPS.exe' and starts the shell. One thing that caught me was that the resulting shell has some standard cmdlets missing. Add-PSSnapin, Get-PSSnapin, Remove-PSSnapin and Export-Console seem to have gone AWOL.

SQL Books Online states that the SQL snapins are

• Microsoft.SqlServer.Management.PSProvider.dll
• Microsoft.SqlServer.Management.PSSnapin.dll

As these are just regular snapins you can load them into the standard PowerShell host as follows -
First register the snapins using the .Net utility installutil with the commands

and check that everything is OK

Then load the snapins

Don't forget to remove and unregister (installutil /u) the snapins when you want to remove the CTP.

When we were looking at using the System.Net.WebClient class to retrieve web pages the question "how do you use this when you have to go through a proxy server and provide credentials?" came up.

A little bit of exploration with get-member and some digging in MSDN revealed that

• the System.Net.WebClient class has a proxy property that can be set to an instance of the System.Net.WebProxyClass
• the System.Net.WebProxyClass has a credentials property that can be set to an instance of any object that implements the ICredentials interface
• The class System.Net.NetworkCredential implements ICredentials
• the get-credential cmdlet returns a System.Management.Automation.PSCredential object
• the PSCredential class has a method called GetNetworkCredential that returns a System.Net.NetworkCredential object - just what we need :-)

  Putting all of that together gives us this script which will ask for credentials and feed them to a proxy server.

It just goes to show how great the combination of PowerShell and the .Net framework is!

I've just finished a great week teaching Mastering PowerShell for HBOS and a couple of interesting things came up.

When I teach the Windows.Forms module I usually show how easy it is to use one of the Visual Studio Express editions to build a form and then translate the designer generated code into PowerShell. This time however one of  the delegates pointed me at the Admin Script Editor which has a forms designer that generates native PowerShell script code :-)

You can download it from here

There are a couple of new posts from the PowerShell team that give some more information about this preview release

• The Community Technology Preview (CTP) of Windows PowerShell 2.0
• What's New in CTP of PowerShell 2.0

The first thing that catches my eye is a new version of get-wmiobject that adds in some of the sorely missed functionality of the COM interface to WMI. Hopefully the WMI interface also has some bug fixes.

Congratulations to the PowerShell team.

Check out these messages from Jeffrey Snover

• CTP: CTP != Beta!
• CTP: Platform Requirements
• CTP: Versioning
• CTP: Watch This Space

Start building your VMs :-)

This turns out to very straightforward, the key is to use the CommandLineEventConsumer class. It allows you to launch any program in response to a WMI event. In order to use it you only need to set two properties (although there are many more to explore)

1. Name - a unique name for your class instance
2. CommandLineTemplate - the command you want to run

As we want to launch a PowerShell script the command line would need to be something like

This would run the script myscript.ps1 and pass it any parameters that are added to the command line. Within the script you can access the parameters via the $args array.

A Working Example

Lets say that we wanted to stop people running Solitaire on their PCs - it's mean but hey, we're admins! The PowerShell cmdlet stop-process will kill a process if we supply the process ID so we'll pass that out from WMI to the script and pick it up via $args.

As before you need to create a filter and a consumer and join them together. So this code creates a filter that looks for instances of Solitaire starting up

Next we create a consumer, using the CommandLineEventConsumer class. %TargetInstance.Handle% picks up the process ID from the win32_process object that triggered the event and adds it onto the end of the PowerShell command line.

and finally join them together with an instance of the __FilterToConsumerBinding class

Now every time you start Solitaire the PowerShell script myscript.ps1 will run and Solitaire will be terminated :-)

Note

You might get the same errors that I noted in an earlier post when you invoke the put method. This is a known bug in PowerShell 1.0 and will be fixed in v2.0. The workaround for now is to keep invoking put until it works.

The easiest way to stop event processing is to delete the binding between a filter and a consumer. In WMI terms the '__FilterToConsumerBinding' class is known as an association class, all it does is link together two other classes. Association classes are a pain to connect to directly so it's simpler to use another type of WQL query that returns the association class connected to your filter or consumer. The code below does exactly that and once you have the associator you can invoke its delete method to break the link. Do bear in mind that a filter or consumer may be associated with more than one other filter or consumer so you might get an array of results rather than just one.

PowerShell provides a helpful type accelerator '[WMICLASS]' that makes using these WMI classes extremely easy.

Lets say that we wanted to log to a file every process that was created on a machine.

First we need to create our filter. To do this we connect to the '__EventFilter' class, create a new instance, set it's properties and save it into WMI. Note - you need admin rights to write into the WMI store so you will need to run PowerShell as administrator for these scripts to work. There is no way to provide alternative credentials when you are using the type accelerator. Get-WmiObject does support a credential parameter but it doesn't work on local connections and there's no way to use the credential when you invoke 'Put' on the new class instance.

The code below creates a filter that will check the '\root\cimv2' namespace every 5 seconds for new instances of the 'Win32_Process' class'

Now we create the event consumer - in this case we're going to use the LogFileEventConsumer. As before we attach to the appropriate class, create an instance, set its properties and store the new instance. Note the use of a string template in the text property. This allows us to pull out properties from the object that caused the event - in this case an instance of Win32_Process.

And then to start everything off we connect the filter and consumer using an instance of the '__FilterToConsumerBinding' class. This class requires that you give it the unique identifiers of the filter and consumer that you want to connect. You can always get this from a WMI object by referencing its '__Path' property.

And that's it! WMI will now record every process that starts on your machine until you delete the binding.

But it doesn't work!

You may find that when you try to invoke the 'put' method on a WMI object you get an error like this

If that happens just invoke 'Put' again (and again and again) and it will work - eventually!

You might also find that when you try to store the paths of your filter and consumer into the binding object you get nulls rather than  valid paths. Retrying a few times will fix this. I've seen this behaviour on XP and Vista. There's definitely something odd going on here but I haven't tracked it down yet.