PowerGUI® Challenge 2010 Winners!

Several weeks ago on November 15, the 2010 PowerGUI Challenge contest came to a close.  The challenge was great this year and we received a lot of fantastic contest entries, with many in the Script Editor Add-on category that was new to this year’s contest.  Since the close of the contest, myself and the many esteemed judges who had volunteered their time this year for the contest have been busy reviewing contest entries, trying them out to see how they work, looking at the scripts they contain, and assigning scores to each entry.  It has taken a while, but today the last results for the contest came in and I have added up the judges scores and calculated the participation (activity) scores so now I can share the results with you.  Without further ado, here are the winners of the Quest Software’s PowerGUI Challenge 2010:

Most Active Participant James Brundage from Start-Automating who contributed 6 add-ons during the contest including the WMI Spy Add-on and the Demo PowerShell Add-on (1st and 2nd runner-up in the Best Add-on category)!
Second Most Active Participant Phillip Sullivan from MVP Systems Software who published a great JAMS PowerPack, and also threw in JAMS Job Scheduler snippets just for fun!
Best PowerPack Adam Murray for his fantastic
HP Virtual Connect Management Pack!
Best Add-on Denniver Reining for his awesome
Snippet Manager Add-on!

Congratulations to all of the winners!

Most of the winners are new to our PowerGUI contests, but there is one seasoned veteran in this list.  A special kudos goes out to Adam Murray for his hat trick: Adam has taken home prizes in our contest for three years in a row!  In 2009 he won the Best PowerPack award with his IIS 7 PowerPack and in 2008 he won two awards, one for Most Active Participant in the first sprint in 2008 with his SQL Server 2005 Reporting Services PowerPack and another for Second Most Active Participant in the second sprint in 2008 with his WebSphere MQ PowerPack.  Way to go Adam!

If you’re one of the winners, we’ll be contacting you shortly about your prize.

I also have to thank everyone who participated in the contest.  Honorable mentions go to DJ Grijalva for the SharePoint 2010 PowerPack and Gyorgy Nemesmagaci for the Help Browser Add-on.  These were both great entries that made the competition very close.

Whether you participated in the contest or not, I strongly encourage you to check out these entries as well as others by visiting the PowerGUI Challenge 2010 contest folder or by visiting the PowerGUI Library on PowerGUI.org.  The PowerGUI Library contains dozens of Script Editor Add-ons, Admin Console PowerPacks, snippets, other fun items such as desktop wallpaper, and much more.  There’s a lot of really great value waiting for you in that library to make your PowerShell experience even better!

Happy scripting!

Kirk out.

PowerShell Quick Tip: Creating wide tables with PowerShell

A few weeks back I took a trip to Columbus, Ohio where I had the opportunity to meet with the members of the Central Ohio PowerShell Users Group and talk about PowerShell and PowerGUI®.  During that event, one of the attendees highlighted a problem they were having.  The problem he highlighted is a fairly common one, so I wanted to share the problem and solution here.

When using PowerShell to generate tabular output, the table that is generated is limited by the width of the buffer.  This is intentional so that the tables always fit in your console window so that they can be easily understood, and for the most part this doesn’t get in the way too much because you can control which columns are shown in the table so that you get the data that is most important to you or you can use Format-List to generate list output when you really want a lot of data.  It can get in the way though if you want to share data from a large table with someone else, store data in a text file for archival purposes, etc.  In these cases you are faced with a challenge because Format-Table does not appear to allow you to create large tables like this due to a few issues that get in your way.

Issue #1: PowerShell truncates table output by default

Let’s say you want to create a table showing a list of aliases for Invoke commands and you want to view all properties for those aliases.  The command to do this seems pretty straightforward, simply calling Get-Alias -Definition Invoke-* and passing the results to Format-Table -Property * to show all of the columns.  Here are the results of that command, showing a table with column names that span multiple lines and rows with data that is not useful:

image

As you can see, the content of the table is truncated so you can’t really tell what the data is in the table, and if you output the results of that command to a file where the lines can be longer you still get the same results.

Issue #2: Auto-sized tables are limited to the width of your screen buffer

If you try to solve this problem by looking at the help for Format-Table, you may come across the AutoSize parameter.  The AutoSize parameter allows you to tell PowerShell that you want the formatter to automatically size the table columns, showing as much data as possible.  Here is what happens if you add the AutoSize parameter to the same command you just ran:

image

This is on the right track for what you are after, but notice the warning text that is output at the top of the resulting table.  It indicates that 10 columns do not fit into the display and were removed.  If you pipe the results of this command to Out-File, PowerShell will simply pass what you see on the screen to the file you are writing to, which is not sufficient for your needs.

Solution: Strings are not subject to the limitations of other objects in PowerShell

When you pass the results of Get-Alias to Format-Table, the Alias data is converted into objects that describe how the table should look.  These objects are then passed implicitly to the Out-Default cmdlet which renders the objects according to their format configuration as well as the current console configuration.  In fact, every PowerShell command you run ends with the results being implicitly passed to Out-Default.  Even if you pass the results of our Format-Table call to Out-File instead, Out-File will render the objects according to their format configuration and the current console configuration.  This is the limitation that is making this seemingly simple task so difficult.  What we need to do then is to make sure that the data that is sent to Out-File or Out-Default is pre-formatted so that it is not limited by the size of the screen buffer.  How do you do that you ask?  The answer is simple: use Out-String.

Out-String is a cmdlet that allows you to convert any output to string format, and you can specify the width of that string using the Width parameter which allows you to exceed the limitations of the PowerShell console buffer size.  When strings are passed into Out-Default and Out-File they are simply written as is without any truncation or automatic text wrapping.  With that additional piece of knowledge you can pass the results of your Format-Table cmdlet call to Out-String using a width that is large enough for the table output, which successfully forces the objects to be rendered with the width that you want without having to change the buffer size.

Here is a screenshot showing what happens when you pass your Format-Table output to Out-String, specifying a width of 4096 characters:

image

That might not look very useful either, but look what happens when you take this one step further and pass the results to Out-File.  Here is the command to do this:

Get-Alias -Definition Invoke-* `
| Format-Table -Property * -AutoSize `
| Out-String -Width 4096 `
| Out-File C:\aliases.txt

Opening the resulting aliases.txt file shows the following contents:

image

This is only showing part of the results, but did you notice the horizontal scroll bar at the bottom of the window?  It illustrates that you have achieved your goal, creating a table wide enough to show all data in the table inside of a text file that can then be sent to others, stored for archival logging purposes, etc.

Sidebar: If you have a specific property that contains a collection of items, that property may still show an ellipsis in the file produced here if the number of items in that collection exceeds the number assigned to the built-in $FormatEnumerationLimit variable.  In this case, if you want to see the entire collection of items, you should temporarily change the value in $FormatEnumerationLimit to something large enough to show your collection (-1 if you want to see all items) and then run a command similar to what I have shown you above.  The default value of $FormatEnumerationLimit is 4, which can be limiting when generating a file like this.  Increasing this value will give you a full report of what you have in the data you are processing.

With that knowledge in hand, the takeaway for you here is to make sure that you autosize your Format-Table results and that you pass them to Out-String with an appropriate width before you write it to a file if you want to output large tables in text format.

Thanks for listening!

Kirk out.

PowerShell Quick Tip: Process your errors more efficiently with Group-Object

Instead of going through your errors one at a time, since there are often cases where the same error is repeated multiple times, use Group-Object with $error to filter out the duplicates so that you can see what the real errors are that you need to deal with.  For example, right now I have 256 errors stored in my $error variable.  To figure out what I need to really look at, I can invoke this command:When working with large script files or modules, you may encounter situations where you have a large number of errors that you need to deal with.  This can be overwhelming, especially when you have looping constructs in your scripts that cause the errors to be raised over and over again.  When you are facing hundreds of errors output from a script, how do you process them all?  Fortunately there is a quick an easy way to make sense of your errors and identify what really needs to be fixed.

All errors are recorded by default in the $error variable.  This variable allows you to access any errors you have received in PowerShell, to a maximum count as identified by the $MaximumErrorCount variable.  By default this is set to 256, and dealing with 256 errors can be impossible without the proper divide and conquer strategy.  Also, the $error variable even includes errors that were hidden by trap, catch, or error action preferences, so this variable is very useful when troubleshooting all errors you have in your scripts.  As mentioned though, this can be a lot of information to digest, so it is important to know how to process it efficiently.

Instead of going through your errors one at a time, since there are often cases where the same error is repeated multiple times, use Group-Object with $error to filter out the duplicates so that you can see what the real errors are that you need to deal with.  For example, right now I have 256 errors stored in my $error variable.  To figure out what I need to really look at, I can invoke this command:

$error | Group-Object | Format-Table Count,Name -AutoSize

That gives me the following results:

Count Name
----- ----
1 Exception calling "ShowDialog" with "0" argument(s): "Property 'PS...
2 Property 'PSiscontainer' cannot be found on this object. Make sure...
240 Property 'Extension' cannot be found on this object. Make sure tha...
13 Property 'Name' cannot be found on this object. Make sure that it ...

This short list of four errors is much less intimidating than a huge list of 250 errors.  Once you have the short list, it becomes much easier to figure out where to get started.  You can also go further by expanding on these details like this:

$Error | Group-Object | Format-List Count,@{Name='Error';Expression={$_.Name}},@{Name='Location';Expression={$_.Group[0].InvocationInfo.PositionMessage}}

A command like that will yield results that look something like the following:

Count    : 1
Error    : Exception calling "ShowDialog" with "0" argument(s): "Property '
PSiscontainer' cannot be found on this object. Make sure that it
exists."
Location :
At C:\Users\kmunro\Documents\WindowsPowerShell\Modules\Add-on.Te
st\Add-on.Test.psm1:860 char:20
+         $Form1.ShowDialog <<<< ()
Count    : 2
Error    : Property 'PSiscontainer' cannot be found on this object. Make su
re that it exists.
Location :
At C:\Users\kmunro\Documents\WindowsPowerShell\Modules\Add-on.Te
st\Add-on.Test.psm1:1236 char:16
+                         if ($obj. <<<< PSiscontainer) {
Count    : 240
Error    : Property 'Extension' cannot be found on this object. Make sure t
hat it exists.
Location :
At line:1 char:11
+ if ($this. <<<< Extension.Length -gt 0){$this.Name.Remove($thi
s.Name.Length - $this.Extension.Length)}else{$this.Name}
Count    : 13
Error    : Property 'Name' cannot be found on this object. Make sure that i
t exists.
Location :
At line:1 char:7
+ $this. <<<< Name

That’s much better.  Now I can see which errors are happening most frequently and concentrate my efforts on them while knowing I only have a few unique errors to deal with.

I hope this helps you work out errors in your own scripts and modules.

Kirk out.

P.S. Wouldn’t it be cool if there was a PowerGUI Script Editor Add-on that showed you the contents of the $error variable, grouped like this, with the ability to double-click and go to the appropriate position in the appropriate file…could make a great entry for the PowerGUI Challenge contest that is going on right now!

PowerGUI® Challenge: Have you taken the challenge yet?

In 10 days on November 15, the 2010 PowerGUI Challenge comes to a close.  The PowerGUI Challenge is a contest that gives you a chance to win some money while having fun with PowerShell and PowerGUI.  The rules are pretty simple: create a PowerPack or an Add-on for PowerGUI and post it in the contest folder for a chance to win one of the prizes.  The best part is that it is possible to create a contest entry in 10 minutes once you do a little research and watch a few videos.  That’s only 1 minute a day for the next 10 days, or a fun 10 minute break from doing something else that you really don’t want to be doing.  If you want to learn more, here is what you need to do:

1. Review the contest details on the contest page (http://www.powergui.org/contest.jspa).  That should answer a lot of the up front questions you might have and it will highlight a few useful resources (but I’m going to highlight some of the most important ones here as well).

2. Take a moment and watch this screencast that demonstrates how easy it can be to create a really useful Add-on for the PowerGUI Script Editor:

3. Now that you know what an Add-on is and how easy it can be to create one, take a few more minutes and watch this screen cast that demonstrates how easy it can be to create a really useful PowerPack for the PowerGUI Admin Console:

4. Create your Add-ons and PowerPacks and post them to the contest folder once you have them working.  The earlier you post your entries, the more time you will have to collect valuable feedback so that you can polish them up before the contest ends on November 15th, and the more you participate the more chances you have to win (some of the prizes are based on level of participation, others are based on best PowerPack or Add-on).

What a great way to spend time having fun with PowerShell and PowerGUI on those dull, Fall days!

Good luck with your entries, and don’t hesitate to ask questions to myself or any of the other judges!

Kirk out.

PowerGUI®, Lego edition

My children made me really happy this morning.  It’s my birthday today, and every birthday I’m greeted by my son and daughter who are very anxious for me to come downstairs so that they can shower me with all sorts of gifts (cards they made, drawings, crafts, etc.).  It’s always a wonderful experience, but this time it came with something a little more unexpected.

This morning I was present with this wonderful gift:

PowerGUI Lego

How cool is that?  My son is a Lego fanatic and he and my daughter asked for a PowerGUI sticker a few weeks ago, which I happily gave to them.  The sticker looked something like this, minus the blue in the background:

Original PowerGUI Logo 

It turns out that this Lego project is the reason they wanted the sticker.  Quite a nice resemblance, don’t you think?  This wouldn’t have been possible if we didn’t have such a cool Logo for our product (thanks Dmitry!).  Sure, you could make a Lego mosaic version of the PowerShell Logo, but this is just so much more fun! Smile

Color me a happy camper today!

Kirk out.

P.S. This totally reminded me of a blog post I published over 3 years ago about Lego PowerShell.  PowerShell isn’t just about IT automation…it’s about fun toys for kids too! Smile

Come learn more about PowerGUI® on tonight’s PowerScripting Podcast

Over three and a half years ago, Jonathan Walz posted the very first recording of the PowerScripting Podcast, a podcast that is dedicated to PowerShell.  What started out as a small, solo effort that produced episodes on a not-so-regular basis matured into the best PowerShell podcast around, with two co-hosts (Jonathan Walz and Hal Rottenberg) that continually produce anywhere between 2 and 4 episodes every month!  To date there are 127 episodes available, full of PowerShell news, tips and tricks, and interesting interviews with people who are heavily invested in PowerShell.  It’s really a great resource for anyone looking to learn more about PowerShell during their daily commute, and I highly recommend checking it out.

As the PowerScripting Podcast evolved, so did the way in which it was recorded.  All recent episodes of the podcast are recorded live using UStream, which is great because it gives you a chance to hang out in the chat room and ask questions to the guest being interviewed.  All you need to do is visit the PowerScripting Podcast channel on UStream during the recording, which you can usually learn about by checking out the PowerScripting Podcast blog.  Recordings are typically done between 9 and 11PM EST on Thursday nights.

This time Hal and Jonathan are a little behind on putting out the announcement about the next podcast, but I have the inside scoop so I wanted to share the news to give you a chance to check it out.  Tonight I’ll be hanging out with Hal and Jonathan on the PowerScripting Podcast channel, and I welcome you to come and join me in the chat room and ask questions about PowerShell, PowerGUI, PowerGUI Pro, the PowerGUI Challenge contest, what it’s like being a Poshoholic, or anything else you feel like asking.

Hope to see you there!

Kirk out.

How to create PowerGUI® Script Editor Add-ons the easy way

In case you haven’t heard, there is a contest coming up that gives you the opportunity to win some money while having fun with PowerShell and PowerGUI.  In order to win something in the contest you have to enter, and in order to enter you have to create either a PowerPack for the PowerGUI Admin Console or an Add-on for the PowerGUI Script Editor.  I have spent a lot of time creating Script Editor Add-ons over the past few months, and when you work on things like Add-ons it can be very helpful to have the right tools at your side.

One of my favorite tools that I like to use for any repetitive PowerShell scripting is PowerShell snippets.  A PowerShell snippet is an xml document (.snippet file) that defines a short piece of PowerShell script with a few fields that can be customized when the snippet is inserted into a script.  Think of a snippet as a little user interface for injecting small pieces of PowerShell script into larger scripts that you are work on.  Snippets are incredibly useful and easy to create and customize, allowing you to arm yourself with tons of useful pieces of PowerShell script and save yourself a lot of typing.

While working on the Add-ons I have been publishing I decided I should build up a collection of snippets so that I could focus my efforts on the core logic inside the Add-on that makes it do wonderful things like sign scripts, create modules, and build other Add-ons, and less on the trivial details like adding and removing menus, menu items, toolbars, toolbar buttons and dockable windows.  This effort has resulted in a collection of 31 snippets that make creating a PowerGUI Script Editor Add-on much easier and today I have published that collection so that anyone can use them when creating their own Add-ons!

If you want to see an example of how easy it is to insert one of these snippets, here is a screenshot showing the snippet menu that appears after I press Ctrl+I (or Edit | Insert Snippet), along with some of the nested folders and their contents showing some of the snippets that are available:

image

If you want to build Add-ons, these snippets make it much easier to get started.  All you need to do is the following:

1. Download the Authoring Toolkit Add-on version 1.0.2 or later.  In version 1.0.2 I updated the Add-ons that are generated such that they use a $pgse variable for the root of the Add-on SDK.  Most of the snippets are dependent on this variable, so you should either download this version of the Add-on or make sure you are using a $pgse variable as the root of the Add-on SDK in Add-ons you have already started building.

2. Download the Script Editor Add-on snippets.  The download page describes how to install the snippets.  Note that since they must be copied into a Program Files folder, you must have the proper permissions to put them there.

3. Create a new Add-on or open an Add-on you are already working on and start using the Edit | Insert Snippet menu item to build more extensions to the PowerGUI Script Editor UI.

Between the Authoring Toolkit, the tutorial, the SDK documentation, and now these snippets, you should now have plenty of tools available to make it easier for you to create snippets for the contest that starts on October 15th.  I’m looking forward to seeing your entries!

Kirk out.

P.S. As I was publishing this I thought of a bunch more snippets that could be useful, but this is a good first set to get you started. If you like snippets and there are other snippets you would like to see, related to Add-ons or anything else you do with PowerShell, let me know so that I can know where you would like to see more effort in the future.  Thanks!

PowerGUI® Online

With the PowerGUI Challenge contest only a few weeks away, you may be wondering where you can go to learn more about PowerGUI in preparation for the contest.  Or maybe you’re looking for inspiration for the kinds of things you can do by using PowerShell with PowerGUI so that you can plan an entry for the contest.  To help provide some assistance with this, a few minutes ago I just published the first release of the new PowerGUI Online Add-on.  This Add-on adds a new PowerGUI Online menu to your Script Editor that provides you with fast access to dozens of useful resources for PowerGUI.  It includes links to many online resources, including:

  • Contest resources
  • Discussion forums
  • Learning center
  • PowerPack categories
  • Script Editor Add-ons
  • PowerGUI Team members on Twitter
  • Developer resources (PowerGUI VSX)
  • The PowerGUI channel on YouTube
  • Request a script
  • and more!

There are a lot of online resources available to help you get the most out of PowerShell and PowerGUI, and this Add-on pulls them all together into one organized menu.

One thing I really like about this Add-on is that when you click on any of the items in this menu, if you are running the PowerGUI Script Editor in STA mode (which is the default) the associated web page will be loaded right in the Script Editor!  Here’s a screenshot showing the Add-on in action with the embedded web browser appearing as another tab in the Script Editor:

PowerGUIOnline.Menu

If you are not running in STA mode (which means you are running in MTA mode), then the web pages associated with the PowerGUI Online menu items will load in your default web browser when clicked on.

This is the first release of this Add-on, so please let us know what you think.  It’s really easy.  Just click on the Feedback menu item in the new PowerGUI Online menu and leave us a note on our forums.

Kirk out.

P.S. Keep watching this blog for more useful content related to the PowerGUI Challenge contest that is coming soon.

Fall 2010 Wallpaper for PowerGUI® and PowerGUI Pro

With the change in seasons comes a change in the look of the PowerGUI site.  It happens so quickly online that it reminds me of the Whomping Willow in Harry Potter shaking briskly until all of a sudden all of its leaves drop immediately to the ground.

Since today is the first day of Fall (or Autumn, if you prefer; and I believe it was the first day of Fall yesterday in Europe), we have a beautiful new desktop background available for download.

Just click on the image above and you’ll see the downloads page where you can pick the size that you want.  Also while you are visiting our site you’ll see the new Fall theme applied to the menu.

Notice anything else different about these images?  Like the images used in the banner and badge for the contest that I announced yesterday, these images are sporting our new PowerGUI logo!  The train we use for our logo has always been an interesting subject of discussion, and now we have a new look for our favorite little train.  Also, this wallpaper is the first one that comes in two different flavors as well: one using the PowerGUI logo and another using the new PowerGUI Pro logo.  Check it out:

new-logo

All sizes available for the new wallpaper are listed on the Downloads page on powergui.org.

One last note worth mentioning on this topic: I just reorganized our library by putting all of our desktop wallpaper images into one folder.  If you want to use a different desktop wallpaper that we have made available in the past, you can take your pick from any of the previous wallpaper images we have published in the PowerGUI Wallpaper folder on PowerGUI.org.

I hope you enjoy the change in seasons as much as I do!

Kirk out.

Use-PowerShell | Enter-Contest | Receive-Prize

Ladies and gentlemen, start your engines!  The 3rd annual PowerGUI® Challenge is about to begin!

That’s right, this year Quest Software is sponsoring yet another PowerShell contest that gives you a chance to win some money by having fun with PowerShell and PowerGUI.  I’m totally excited about the contest this year, because there are more prizes, more categories, more judges, and more possibilities with what you can do than ever before!  If any of your entries make it into the top 10 in the two main categories (PowerPacks and Add-ons), they will be put in front of our incredible panel of celebrity judges for review and suggestions.  Judges this year include Jeffrey Snover, Hemant Mahawar, Don Jones, Jeffery Hicks, Shay Levy, Brandon Shell, Aleksandar Nikolic, and Marco Shaw.  If you’ve read even a little bit about PowerShell on the web, I’m sure a few of those names ring a bell.  Dmitry and I will review the entries and offer our own feedback as well.

Sound interesting?  Here’s what you should do:

  1. Head on over to the PowerGUI Challenge contest page and read all of the details about the contest, paying close attention to the tips and the resources that are listed there to help you out.
  2. If you’re not familiar with them already, take a look at the kinds of things you can do with PowerPacks and Add-ons by visiting the PowerPack Library and the Add-ons Library and trying some of them out (and make sure you install the Authoring Toolkit Add-on if you plan on creating Add-ons yourself – it’s a real time-saver).
  3. Enter the contest!  The only way to make sure you don’t win anything is by not trying at all, and this is a really fun way to discover some of the cool things that you can do with PowerShell beyond regular scripting.

The contest runs from October 15 to November 15, so you have a lot of time to get yourself warmed up before the official start date, and then you can start adding your entries and getting community feedback.  Don’t wait, start learning more about what you can do by experimenting now!

In the meantime, I’ll be providing additional resources to help you out that I’ll announce on my blog as well, so keep your eyes open for more useful contest resources.

As always, don’t hesitate to ask questions if you have any.  As Alan Renouf (one of our winners in last year’s contest) knows, I’m more than happy to provide feedback and answer questions.

Happy scripting!

Kirk out.