Get-WmiObject Win32_WinSat

1. It’s a PowerShell 2.0 Module
2. Lots of great help files for every Cmdlet
3. Full coverage of the ONTAP API
4. Used “Approved” verbs
5. 357 Cmdlets

About a year ago, NetApp released a .NET version of their API. Using their DLL, I was able to write a bunch of PowerShell 2.0 Advanced Functions to automate the 20 or so tasks that my team did with our NetApps on a weekly basis. Using the .NET API, I created a module with 20 or so Advanced Functions. So far, every one of them has been implemented in the new cmdlets. There are also a great deal of cmdlets that are extremely useful that I never got around to writing.

The ONTAPI .NET API exposed functionality with an object of type Netapp.Manage.NaElement, which is basically an XML Element. Essentially, everything in the Netapp API takes in XML and returns XML. PowerShell does a great job with XML and it was relatively easy to cast from XML to PSObjects as needed. However, the new PowerShell toolkit has a bunch of wrapper classes which seem to be a bunch of de-serialized NaElement Objects. This makes working with the objects much easier.

NetApp has really done a terrific job with their adoption of PowerShell. Again, I am particularly impressed with how well they adhered to the “ground rules” for working with PowerShell. In my opinion, these cmdlets are a great example for other third party companies that are looking to adopt PowerShell.

Now, this is of course version 1. There is always room for improvement. One of the first things I noticed is that there could have been some work done on the default formatting for some of the most basic objects that we use all the time, particularly luns and volumes, NetApp.Ontapi.Filer.Lun.LunInfo  NetApp.Ontapi.Filer.Volume.VolumeInfo respectively. Frankly, I like the default view to be a table with 4 or 5 critical columns. If something has to default to format-table, its too much information to process for me, but that’s my humble opinion.

Here’s an example

I think I would prefer to have a table view that just shows the name, sizeTotal, SizeUsed, and perhaps 1 or 2 other attributes. This seems more useful out of the box to me

NetApp filers are SAN’s. They are all about storage. They are built on a hierarchical model. Frankly, I think a PowerShell Provider could be a great fit for managing a NetApp filer. However, as Jeffrey Snover often says, to ship is to choose, and I wholeheartedly belive that the cmdlets are more useful than just a provider. But, if you have a provider and cmdlets, they are definitely better together. I love using a Provider for discovery purposes. But I think in general, cmdlets are more useful for actually executing tasks. I would love to see a complimentary PS Provider in version 2 of the Toolkit.

All that being said, I tip my hat to Netapp. Great job on version 1!

I hope you find this video helpful. I would love to hear any kind of feedback on the video, positive or negative. All I can say is that it is a bit easier to talk to yourself in front of a computer after a glass of wine   Seriously, feedback is greatly appreciated.

Andy

While she was working on a Mark II Computer at Harvard University, her associates discovered a moth stuck in a relay and thereby impeding operation, whereupon she remarked that they were "debugging" the system.

When I first started scripting and writing a little code, the concept of debugging something seemed really hard. However, I have found that with a few simple steps I can debug most of my scripts pretty quickly.

Ninety nine percent of the time, debugging scripts requires being able to watch a variable at some point in a script or a function. Have you ever written a function and thought, “If only I knew what x was before y started messing with it?”

The PowerShell Integrated Scripting Environment makes this pretty easy. You can set a breakpoint on any line in the ISE using the Debug Menu and choosing “Toggle Breakpoint.” or by using the F9 shortcut key.

When you toggle a breakpoint on and then run the script, the script will stop at that point. You should note that at this point, the highlighted line has not been executed yet.

Here’s what it looks like when you hit a breakpoint. You get thrown into a nested prompt where you can poke around and look at any variables you want to. Notice the >>> prompt and notice $b has not yet been set, but $a has.

Now that you are paused right around the line of code you want to check out, you can use the “Step Into” Feature.

This will execute the next line of code in the script (the highlighted line) and then stop.

Now you can see that $b has been set but $c doesn’t have a value yet.

You can continue to step through as much as many lines as you need to until you see something that is not quite right.

This is just the beginning of what we can do in regards to debugging scripts and functions. In the next couple weeks I plan to share more as I learn about debugging and the ISE. Just to whet your appetite, you can run the command get-command –noun psbreakpoint to see what kinds of goodies await!

I went and tried to do this straight away on my local machine without the remoting bit. I copied some cmdlet source code from MSDN. As a Systems Engineer, I haven’t written many compiled cmdlets in C# but I have edited a few for my liking and written one or two when script just wouldn’t cut it. One thing I have learned is that you always need a Snapin to register your cmdlet. So you have your namespace with a class for your snapin and then a class for each cmdlet that you create.

The bottom line here is that with dynamic modules you don’t need to create a Snapin class for your cmdlet. The only other tweak is that I used the –language parameter on Add-Type to specify CSharpVersion3 so I could use automatic properties and not have to explicitly write the getter and setter for the parameter “Name.”

[string]$code = @"
using System.Management.Automation; 

namespace SendGreetingDemo1
{

  [Cmdlet(VerbsCommunications.Send, "Greeting")]
  public class SendGreetingCommand : Cmdlet
  {
    [Parameter(Mandatory=true,Position=0)]
    public string Name {get;set;}

    protected override void ProcessRecord()
    {
      WriteObject("Hello " + Name + "!");
    }
  }
}
"@            

$assembly = (Add-Type -TypeDefinition $code `
          -Language CSharpVersion3 `
          -passthru ).Assembly
$assembly | Import-Module

Advanced Functions essentially allows PowerShell users to leverage nearly all the features that are available to a developer writing a Cmdlet in C# in functions written in PowerShell script.

After the talk, one question that was brought up was “If you can leverage all of these features in Advanced Functions, at what point would you convert over to C# (or VB .NET) and write a full blown compiled binary Module.

The first is all about performance. Well written compiled code will almost always out perform well written interpreted code. There are a ton of factors here that can come into play, but as a general rule, binaries will be faster than script.

The second reason you may want to stick with compiled code is if you want to include a provider with your Module. A provider presents any kind of data store to a PowerShell user in the same way they are presented the filesystem. You can do things like set-location, new-item, set-itemproperty, cd, ls, md, etc etc. Just as an example, the PowerShell Community Extensions has a provider for Active Directory.

If you are a sys admin that has never cracked open Visual Studio, you obviously will start off with Advanced Functions. However, I would really like to point out that the glide path to compiled C# from Advanced Functions is not super steep. There is a ton of documentation on Beginner Development and how to write your first Cmdlet. So if you are interested at all in learning, I say go for it and jump in with both feet. Even if you are not looking to be a full time software developer, looking at and understanding how a compiled cmdlet is written will bring a deeper understanding to how you use PowerShell.

My wife and I are in “getting ready for new baby” mode. The C-section is scheduled for the 1st week of June.

I am guessing the next one will be in July sometime.

Once you have the name, you can call the FindName method (see line 024) on your WPF Window. This allows you to find the named control that you want to add event handling for. Using FindName, we can add the add_Click method and pass in the ScriptBlock that we want to execute on the click event.

When you run this, clicking the button will close the dialog box.

Scott Hanselman has a phenomenal list of tools that he posted back in 2007 but they are still worth a look through. Most are free and the ones that are not are worth paying for.

Scott is mainly a developer so a lot of the tools are dev focused, but a the top 10 would apply to anyone that wants to interact with their computer in a more effective way.

I have heard him mention on his podcast that people are starting to complain that he hasn’t refreshed the list in a while. Maybe we will have the pleasure of the 2009 list soon. We’ll see.