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

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

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).



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]

Leave a Comment
  • Please add 1 and 3 and type the answer here:
  • Post
  • Sorry about that, Chuck. The correct name is about_shell_variable. I've fixed it in the help and the fix will be available in the next release.

    To restart your computer, use the

    "shutdown -r" command. You can type it in Windows PowerShell, cmd.exe, or in the Start/Run box.

    To see all of the parameters of the shutdown command, type shutdown -?.

    I use shutdown to restart my remote machines. It has a -m \\computername parameter.

    Again, sorry for the inconvenience.

    June Blender [MSFT]

    Windows PowerShell Documentation

  • PowerShell is fantastic! I like the sample scripts, they actually helped my create a build process for a .NET 2.0 web application complete with deployment, zip and other functionality. Ok, so most of the work is handled by MSBuild, but it wouldn't happen without my PS script driving it by collecting SVN revision number, the build number, trunk or branch build and the branch name. Then, reading a config file (in good ol' XML) and filling some other variables to be passed to MSBuild.

    I looked into doing this in cmd and VBS, and the choice was clear. PowerShell ruled out all the others.

    Thanks for everything, PowerShell Team! Here's to the future!

  • I have to say that VBScripters are the majority. Most of us have been writing them for years and are adapting to the new technology that PowerShell presents.

    I for one think that the examples are just fine.

  • I think you would get your best mileage by hiring a die-hard Linux-UNIX type that knows shell scripting and a few scripting languages (one of them must include Perl).  Then tie him/her up in a dungeon and wipe him/her until s/he cranks out Powershell code to do stuff that doesn't involve ADSI or WMI.

    On more serious note, what is sorely needed is real world scripts on system administration, chores that are commonplace in UNIX.  This involves text manipulation, analyzing events, generating reports, etc.  Typical chores that would be done with grep, sed, awk or just perl, like frequency hashes, trend analysis.  

    It seems Powershell oriented more of neat playground for object introspection and easier access to complex APIs, but not focused a lot on real shell usage.  So more articles to flesh out the language would be well received.

    - Joaquin

  • I totally agree that there should be other script examples than just the same WMI scripts over and over again.

    I mean, the only commands we've learned about using the example scripts are "get-wmiobject" and "write-host". Isn't PS more versatile than that?

  • I think everyone has the same opinion. The current scripts are useful for the beginner and the person looking to move to PS from VB. Additional examples of real world administration would be most appreciated.

    On another note you guys have been doing outstanding work. I and i am sure everyone else truely appreciate your efforts.

  • Come on guys, where are the new scripts. I'll think I'll stick to VBScript for now, until we get some more samples. Its been over a year!!!

  • This blog does stretch in time to scary degree. Assuming a transition to PS is ever going to happen, the Technet script repository would be a good place to start. Rather than having a node dedicated to PowerShell in the repository, each of the existing scripts should be re-classified as "legacy" and accompanied by a PS equivalent, preferably an "elegant" one.

    Is anyone home?

  • Here is what i think...if someone thinks that the scripts on MS is crap then its their opinion and to prove it they should post on the web. i find MS scripts to be very good for learning. Thanks guys you are doing a great job. lot of those scripts have solved problems for me at work.

  • So what happens when the get-wmiobject call fails?

    One problem I have with scripting under Windows (VBS) is that the examples have no error checking in them. Which means in the wild you find admins have hacked together scripts that can really screw things up if a single call fails or will simply fail to run if a call fails -- the combination of which is really miserable, and silly. It would be nice if there was a greater emphasis improving the robustness of scripting under windows, give examples with real error checking in them, show how to recover from minor failures.

    My 2c from the wild...

  • I got 2 *.ps1 scripts

    Master.ps1 - which has couple of functions

    Test.ps1 - test script file which calls Master.ps1

    both are in same directory and I call the .\Master.ps1 file and it works fine, but the functions are not exposed.

    but if I execute those functions in the PowerShell editor its exposed.

    Cant I run a ShellScript within a Script file.

    Can someone please throw some light on my query

  • Insert the command that requires you to declare variables

    Declare variables named x, y, and z.

    Assign the values 10 to x and 20 to y.

    Add x to y and store the result in z.

    Test if x + y equals 40.

    If it does, print out the message “x + y = 40”.

    If it does not, print out “x + y = ##” (Where ## equals the total.)

    Print out an “End of Script” message.

  • guilty as

    that's a one liner

  • the link to the repository is broken. maybe you could write a script to fix that

Page 2 of 2 (29 items) 12