Welcome to MSDN Blogs Sign in | Join | Help

PowerShell's Script Center problem

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:

Published Thursday, May 11, 2006 8:22 PM by PowerShellTeam
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

# PowerShell's Script Center problem



One thing I tried to do through PowerShell was execute the sn.exe strong
name application and it...
Thursday, May 11, 2006 4:24 PM by It's my life... And I live it...

# re: PowerShell's Script Center problem

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
}
Thursday, May 11, 2006 4:34 PM by jfbradfo

# re: PowerShell's Script Center problem

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]*
Thursday, May 11, 2006 5:28 PM by Monad Team

# re: PowerShell's Script Center problem

Darn it...I knew that...
Thursday, May 11, 2006 6:20 PM by jfbradfo

# PowerShell's Script Center problem


 One thing I tried to do through PowerShell was execute the sn.exe strong name application and it...
Thursday, May 11, 2006 10:59 PM by It's my life... And I live it...

# re: PowerShell's Script Center problem

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.
Friday, May 12, 2006 3:44 AM by Dennis E. Hamilton

# re: PowerShell's Script Center problem

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. :)
Friday, May 12, 2006 12:26 PM by skatterbrain

# re: PowerShell's Script Center problem

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.
Friday, May 12, 2006 4:44 PM by jvierra

# re: PowerShell's Script Center problem

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
Wednesday, May 17, 2006 5:56 AM by peterm

# re: PowerShell's Script Center problem

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.)
Thursday, May 18, 2006 11:09 AM by CRussel

# re: PowerShell's Script Center problem

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.
Friday, August 11, 2006 7:59 PM by David Sutton

# re: PowerShell's Script Center problem

How to get the line number of one flat file in PowerShell?

Tuesday, February 13, 2007 11:13 AM by Renato Astorino

# re: PowerShell

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

Saturday, February 24, 2007 10:27 AM by ...

# re: PowerShell's Script Center problem

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

Tuesday, March 20, 2007 10:55 AM by Trevor

# re: PowerShell's Script Center problem

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

Tuesday, April 24, 2007 4:48 PM by Chuck

# re: PowerShell's Script Center problem

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

Tuesday, April 24, 2007 7:13 PM by June Blender [MSFT]

# re: PowerShell's Script Center problem

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!

Tuesday, May 01, 2007 6:38 PM by John Baughman

# re: PowerShell's Script Center problem

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.

Saturday, June 30, 2007 12:12 PM by kdyjur

# re: PowerShell's Script Center problem

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

Monday, July 30, 2007 12:08 PM by Joaquin Menchaca

# re: PowerShell's Script Center problem

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?

Saturday, August 04, 2007 5:38 PM by Anders Olsson

# re: PowerShell's Script Center problem

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.

Friday, November 02, 2007 12:45 PM by Bill Foster

# re: PowerShell's Script Center problem

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!!!

Sunday, November 11, 2007 11:08 PM by BG

# re: PowerShell's Script Center problem

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?

Friday, December 07, 2007 3:16 PM by Milton F. Lopez

# re: PowerShell's Script Center problem

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.

Friday, January 25, 2008 3:30 AM by Prakash

# re: PowerShell's Script Center problem

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

Sunday, March 23, 2008 3:25 PM by cove

# How do I call a Powershell script within a script?

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

Thursday, April 24, 2008 2:16 PM by Karthikeyan

Leave a Comment

(required) 
required 
(required) 
 
Page view tracker