PowerShell's Script Center problem

PowerShell's Script Center problem

Rate This
  • Comments 29

Fellow Scripters,

We’ve heard that some of you think our PowerShell sample scripts on the TechNet Script Center stink. Do you have any idea how much that hurts? We slave over hot keyboards day in and day out trying to help you ungrateful scoundrels learn more about scripting. And how do you repay us? Nasty emails and smear campaigns, that’s how….just a sec…what’s that?...what do you mean they have a point? Really? Oh. OK.

Ahem. Yes, well then…as I was saying, in my official capacity as someone writing an email message to a fellow named Lee, that I hope he’ll post on a blog for me, I’m here to explain why the PowerShell sample scripts on the Script Center are not at all elegant and basically look like VBScripts translated into PowerShell scripts. For those of you who haven’t experienced the horror first hand (you might want to chase your offspring out of the room at this stage), here’s one of the offending scripts.

$strComputer = "."
$colItems = get-wmiobject -class "Win32_LoadOrderGroup" -namespace "root\CIMV2" `
-computername $strComputer



foreach ($objItem in $colItems) {
      write-host "DriverEnabled: " $objItem.DriverEnabled
      write-host "GroupOrder: " $objItem.GroupOrder
      write-host "Name: " $objItem.Name
      write-host
}

If you happen to be into this sort of vulgarity, here’s a link to the entire repository of the beasts: http://www.microsoft.com/technet/scriptcenter/scripts/msh/default.mspx.

So what, exactly, were we thinking? And when are we going to get our act together and post some elegant scripts? Don’t we know that PS:>get-wmiobject Win32_LoadOrderGroup would have accomplished the same thing and demonstrated some of the Power in PowerShell?

Here’s the deal. Our performance is judged by the number of lines of script we write. We needed to figure out a way to keep the line count up and the bonuses rolling in. (you would not believe what it costs to fill up a Ferrari these days!). So, we told management that we wanted to create PowerShell scripts that looked exactly like the typical VBScripts you find on Script Center.

We spun this tale about how we wanted to help ease our beloved Script Center customers into the PowerShell world by showing them how their existing knowledge translates easily to PowerShell. They can still set a strComputer variable to “.” to reference the local machine, they still have a For Each loop, there’s still a statement that let’s them display information on the screen.  Heck, if they look at the two scripts side-by-side, they’ll surely see the parallel statements and thereby be gently introduced to a bit of PowerShell syntax.

On Error Resume Next
strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")
Set colItems = objWMIService.ExecQuery("Select * from Win32_LoadOrderGroup")
 
For Each objItem in colItems
    Wscript.Echo "Driver Enabled: " & objItem.DriverEnabled
    Wscript.Echo "Group Order: " & objItem.GroupOrder
    Wscript.Echo "Name: " & objItem.Name
    Wscript.Echo
Next

Of course we expected to be found out eventually and, apparently, eventually has arrived early this year. So, what are we going to do about it? We’ll we’re not going to take down those existing scripts anytime soon. (we need the line count, remember?). We are, however, working another scam. We’re soliciting elegant PowerShell scripts from internal folks at Microsoft who do have a clue. This is brilliant. We claim that we want to “leverage their expertise” or benefit from their “understanding of real-world customer scenarios” or some other buzz-word-laden suck up sentence and they do our work for us.

Unfortunately, we still have to organize what we get and do the production work required to get the samples posted. We’re a tiny little team and we’re currently working on improving the command line help in PowerShell. Though we’ve tried, we can’t figure out a way to make that work easier or to get someone else to do it for us. So, the new PowerShell script samples are on hold until we’re done.

Now, in case you haven’t picked it up, we’re pretty open to benefiting from the hard work of other people. If you’ve got some elegant PowerShell scripts that you’d like to see on the Script Center, we’d like to help you help us. Just click on the following link, click Submit a Script, agree to donate all of your future earnings to us and fill out the form. No promises, but we’ll do our best to post the submissions (only if they’re elegant of course).

http://www.microsoft.com/technet/scriptcenter/csc/default.mspx

 

Many thanks (ungrateful scoundrels),

Dean Tsaltas

 Official Spokesman for the Script Center team
….on this one particular, inconsequential issue
….only because the rest of the team didn’t have time and Lee demanded something by the end of the day

[Edit: Fixed some typos]
PSMDTAG:TYPE:WMI:

Leave a Comment
  • Please add 5 and 3 and type the answer here:
  • Post


  • One thing I tried to do through PowerShell was execute the sn.exe strong
    name application and it...
  • Your WMI example isn't exactly accurate, as get-wmiobject doesn't return every property of a given WMI class.  Assuming I don't want to see the __* properties, the following will return all properties of a WMI class:

    $strComputer = "."
    $wmiClass = "Win32_OperatingSystem"
    $namespace = "root\CIMV2"
    $colItems = get-wmiobject -class "$wmiClass" -namespace $namespace -computername $strComputer
    [Microsoft.PowerShell.Commands.MemberDefinition[]]$properties = $colItems | `
         get-member -membertype property | `
         where { $_.Name -notlike "__*" }

    foreach ($objItem in $colItems) {
         foreach ($property in $properties) {
               write-host $('{0}: {1}' -f $property.Name,$objItem.get_Item($property.Name))
         }
         write-host
    }
  • ah yes - however, our format-list cmdlet allows you to use wildcards with the property names.   So this becomes

    get-wmiobject Win32_OperatingSystem | format-list [a-z]*
    or, more precisely
    $strComputer = "."
    $wmiClass = "Win32_OperatingSystem"
    $namespace = "root\CIMV2"
    get-wmiobject -class $wmiClass -namespace $namespace -computername $strComputer |  format-list [a-z]*
  • Darn it...I knew that...

  •  One thing I tried to do through PowerShell was execute the sn.exe strong name application and it...
  • That is one of the funniest tech-blog posts I have seen in a long time.  You made it a perfect end for my catching up on unread blog feeds.  Thanks.
  • I'm not going to pick you guys but it would be nice to see more scripting examples other than WMI re-coding.  How about managing user, group and computer accounts in AD via DirectoryServices or ADSI even?  How about performing file operations (read/write/rename/move/delete/etc)?  How about touching on the subject of login scripting with PS (if that is even possible yet)?  Just some thoughts.  The tool itself is amazing and impressive.  We just need some bread crumbs to find our way to the fountain of experimentation. :)
  • Good post.

    I started with PS the same way just to see how it handled the transition.  I was very surprised to see that many existing bits of script knowledge moved righ tover.

    Dear PowerShell Team

    Current scripters will quickly become acclimatized if we give them inelegant transitinal scripts.  It would be a good idea to deliver two versions.  One in classic style and one in PS "most-elegant" style.  This would help scripters to understand how to leverage the "declaritive" nature of PS. This is a conceptual hurdle that will occur after seeing the two side by side for a bit.

    I will attempt to add some dual style examples in the near future.  THe next script I do that would clearly be quicker and easier with PS get's posted to teh CSC.  I won't dedicate my earnings to you but I will except any all all donations.
  • the critiques are right - the WMI samples sucks. I am a big fan of the scripting guys (I even nominated them for the nobel peace price twice), but they should teach using the Ps the right way from the very beginning and not teach VBscript people (who are a minority anyway) how to produce just more "spagetthi code" (an old term used for the BASIC language in general)

    Peter
  • jvierra is right - if we must have transitional scripts, give us both ways to do it. The stupid ugly VBS way, and a more elegant and native PS way. (And that Lee guy is, as always, right.)
  • Actually, I didn't think it was funny at all.  PowerShell is positioning itself as a critical technology for the Windows administrator.  According to the available sample scripts, if you want to "list stuff", then this is the shell for you!  If you actually want to "do stuff", then you should just stick with VBScript.  Of course, that's not really true, but you try explaining that to admins whose only exposure to PowerShell's scripting capabilities are those samples (as I've had to).

    They not only suck, they're offensive.
  • How to get the line number of one flat file in PowerShell?

  • Lavoro eccellente! ..ringraziamenti per le informazioni..realmente lo apprezzo: D

  • Haha, this made me laugh. People should be constructive in their criticism, and if you're getting crap from people for trying to help them learn scripting, then that's uncalled for. God forbid you actually be a little verbose and show us the cmdlet property names so that we learn them! *sigh*

    Good job Powershell Team.

    Trevor

  • One thing that would help PowerShell immensely is if the help references actually worked (e.g. "get-help about_variable" command returns an error when I try it on my XP machine.)

    I think if frustrations like this were cleared up, people would just start writing scripts, and not complain.

    BTW, I'm trying to figure out a way to get PoserShell to restart my comp

Page 1 of 2 (29 items) 12