OpenXtra has a blog entry PowerShell + Network Monitor = Powerfull Netman Tool which observes that if took a network manager tool and coupled it with PowerShell, you would have an awesome combination. A long time ago I was the architect for NetView so I feel qualified to offer this observation: YOU TOTALLY GET IT!

Most management products and certainly all monitoring products should be embedding and/or leveraging Windows PowerShell. If you are working on a product like this, you owe it to yourself (and your customers) to get PowerShell in focus and include in your next version. If you are a customer of one of these products, you should start beating up your vendors to get this included in their next release. Not only would this provide incredible power to the management tool but pretty soon, you won’t be able to manage things unless you support PowerShell (that should be a wakeup call for any of you that haven’t yet groked the fact that the ONLY way you can manage Exchange 2007 is via PowerShell).

There are a couple of ways to integrate PowerShell and a management product:

1. Provide cmdlets to expose the functions of the Mgmt product.
2. Launch PowerShell to respond to an event or action.
3. Embed PowerShell into the application.

The first 2 have been talked about a lot so I’d like to spend a bit of time discussing the 3^rd. We made the PowerShell engine available as a DLL explicitly so that applications could embed it into their applications to make them scriptable(1). The application can create one or more instances of a RUNSPACE (a SPACE to RUN PowerShell scripts or commands) and then invoke scripts or commands to run in those RunSpaces. We also provide APIs so that you can expose portions of your application as variables to those scripts.

Lee Holmes has a great blog entry HERE showing exactly what I’m talking about. He has a graphical LOGO application which exposes a TURTLE object as a variable and then executes scripts. The script can then do things like $Turtle.Right(15) or $Turtle.Forward(300).

The benefit of this approach is that you can make your application scriptable with incredibly low latency for performing the actions. Making your application scriptable means never(2) having to say, “that’s a great idea – hang in there for a couple of years till we get around to putting that in our next version“. If your application is scriptable, you get to say, “That is a great idea, here is how you can script that today and if enough people ask for it, we’ll hardwire it into our next version“. The business impact of this architecture cannot be overstated. It provides incredible agility in the marketplace and empowers your customers, your ISVs and your field people.

This pattern is absolutely critical for management products because “dealing with stuff nobody thought of” is the ontological definition of a management product. If you are working on a management product and are not adopting about this architecture – you are probably making a mistake. But the technique and its advantages are in no way limited to Management products. Lots of products (CAD systems, Games, Office, etc) get great advantage by embedding scripting engines.

1. Hat’s off to superstar John Ousterhout and his fantastic work with TCL. TCL was what first introduced me to this idea of an embeddable scripting engine and the power this approach provided.
2. OK OK – I’m overstating the case by saying “never”. That depends on what you’ve exposed and how you’ve exposed it.

Jeffrey Snover [MSFT]
Windows Management Partner Architect
Visit the Windows PowerShell Team blog at: http://blogs.msdn.com/PowerShell
Visit the Windows PowerShell ScriptCenter at: http://www.microsoft.com/technet/scriptcenter/hubs/msh.mspx