Category: PowerShell

A letter of apology to the VMware PowerPack community

Kirk Munro6 Comments

UPDATE 10-JAN-11: I just published a beta version of the VMware vSphere PowerPack with PowerCLI 4.1 or later support.  You can read more about the beta and how to install it here.

I have heard via email and Twitter that quite a number of you were disappointed when you upgraded PowerGUI® Pro or PowerGUI® to version 2.3 only to discover that the VMware PowerPack does not work with PowerCLI 4.1.1.  Instead the VMware PowerPack today has a firm requirement for PowerCLI 4.0 U1.  I apologize for the disappointment that you have experienced with this and I felt I should take a minute to talk about the situation we are facing and let you know what our plans are going forward.

When VMware released version 4.1 of the PowerCLI, they completely changed the object model that they were using in earlier releases.  This change came with many undesirable and unwelcome side effects, effectively breaking backwards compatibility with many scripts that are built on top of the PowerCLI cmdlets, and the VMware PowerPack was no exception to the effects of those breaking changes.  We have been working with VMware to ensure that they are aware of the ramifications of changes like this, but it is an uphill battle because while they have said that they were committed to providing backwards compatibility for the old type names back into the PowerCLI in 4.1.1, our testing shows that this backward compatibility is not there like it should be.  Further, you may now start to see many warnings from scripts that previously ran without warning or errors because VMware is planning to deprecate many of the properties that were there in previous versions.  These warnings are a concern because they show that VMware is continuing to make changes that will break older scripts going forward without much communication at this point about why they are making those changes.  I am working with many other MVPs and vExperts in the community to give feedback about why this is really not a good idea, but unfortunately we haven’t had any knowledge about the changes in these releases any earlier than you have, so we haven’t been in a position to work closely with VMware to help prevent complications such as the ones introduced in the 4.1 and 4.1.1 releases.

Now we are faced with a decision about what should be done going forward.  I cannot simply do an upgrade for the VMware PowerPack to require 4.1.1 because existing customers who are using PowerCLI 4.0 U1 and who may not be able to upgrade to 4.1.1 right away due to internal policies will have a broken PowerPack on their hands if their PowerPack is auto-updated.  I can however create a separate version of the VMware PowerPack that does not auto-update to support users who have upgraded to PowerCLI 4.1.1 and who want to use the VMware PowerPack.  This will take some time though because the changes are not straightforward, and if you want a version of the PowerPack that has been put through the property quality control channels we will have to retest everything to make sure it works with the new version, which is no small feat for a PowerPack of this size.  I may also be able to create a version that works with both PowerCLI 4.0 U1 and PowerCLI 4.1.1, however I’m not very optimistic about that at this time.  There is also a VMware Community PowerPack available that I do not manage, and it suffers the same challenges.  All of this adds up to a lot of things to consider and a lot more work than should be required when looking at the right way to upgrade this PowerPack (and those considerations apply the VMware Community PowerPack as well as I just mentioned since it is partially dependent on the VMware PowerPack as well as the PowerCLI).

What will most likely happen is that we will create a version of the VMware PowerPack that requires PowerCLI 4.1.1 or later, and that we will try to support two different versions of the PowerPack for a while until we eventually deprecate the older version.  That is not what I would like to do, but my hand is being forced here so that is the only realistic option I see in front of me.  I may be able to create a preliminary beta version of that PowerPack fairly quickly, however it will not have been put through a full test cycle and it will not address the warnings that appear from properties that are being deprecated – that will require much more time and effort.  I will of course notify you when this beta version is available.  Our plan is obviously to support every new release of snapins and modules that come out that are used with our PowerPacks, ideally the moment that those releases become publically available, but usually providing that support is much easier than this so please bear with us as we work through the messy situation we’re in right now.

In the meantime I would recommend that you continue to use PowerCLI 4.0 U1 with the VMware PowerPack and the VMware Community PowerPack because it works very well and is something we can support today.  At the same time you can of course put version 4.1.1 of the PowerCLI in a separate VM so that you can work with both versions for a while — we are talking about a virtualization solution after all…

Thank you for your patience and continued support while we work through these challenges together.

Sincerely,

Kirk Munro

PowerGUI® reaches 1,000,000 downloads!

Kirk Munro2 Comments

Today is a major milestone in the history of PowerGUI.  PowerGUI has been downloaded 1,000,000 times since the release of the first public version of PowerGUI freeware that went beta on March 28, 2007!  This couldn’t have happened without the strong community that has grown around PowerGUI and PowerGUI.org.  PowerGUI would simply not be the great product that it is today without you, so thank you for your continued support!

Here is the download count history since March 2007:

Note that this does not represent the actual number of users of PowerGUI.  This represents the number of times that PowerGUI has been manually downloaded from the PowerGUI.org site by a user who left-clicks on the download link.  Right-clicks are not counted, so these numbers are not 100% accurate but they give an impression of the growth of the community, and that growth is pretty amazing.  Even without perfectly accurate numbers, I’m thrilled with the success that PowerGUI has achieved and I am very proud to be a part of it!

I think this calls for some fireworks, don’t you?  With the release of PowerGUI Pro and PowerGUI 2.3 that I published last week, I also uploaded the Christmas 2010 wallpaper to our download site, complete with fireworks coming from the smoke stack on the train.

thumbnail

If you’d like to have this wallpaper on your computer desktop to celebrate the holiday season, click on the image above to open the PowerGUI downloads page where you can pick the size (there are 8 to choose from) and flavour (we have freeware and Pro editions of the wallpaper) that you want.

Thanks again to everyone who uses PowerGUI for your support!  I look forward to continuing to work with you while taking PowerGUI Pro and PowerGUI to new heights in 2011!

Cheers!

Kirk out.

PowerGUI® Pro and PowerGUI® 2.3 are now available!

Kirk Munro6 Comments

Today I am happy to announce that PowerGUI Pro  and PowerGUI 2.3 are now available.  This is a really exciting release for all PowerGUI users because there are a lot of cool new features in this release.

For PowerGUI Pro customers, we’ve spent quite a bit of time on MobileShell and made the following enhancements:

  • More mobile device support!
    MobileShell now supports iPhone 3G, 3GS, and 4G, iPad, BlackBerry OS 5.0 and 6.0, Android OS 2.1 and 2.2, and even Windows Phone 7 OS devices!
  • Improved user experience for MobileShell on smartphones!
    Since smartphones have limited real estate for apps, we have redesigned MobileShell to better fit your smartphone device.  Now when you log in you will see your favourite scripts first, front and center, and optionally you can go to another tab if you want to do some ad hoc scripting.  If you are using an iPhone and prefer the old UI, you can specifically use that UI but the new UI is highly recommended for smartphone devices.  Larger devices such as desktop browsers and the iPad still use the old UI since they have more real estate to work with.
  • Improved favourite script management for MobileShell admins!
    Now admins can preconfigure the default favourites that are assigned to users when they first log on to MobileShell.  This makes it easier for you to set up the default commands you want available for your team once and then when they log in for the first time they will get assigned those commands automatically.
  • Role-based assignment of MobileShell commands!
    Admins can now associate modules with Active Directory users and groups so that when a user logs on to MobileShell, all public commands in any module associated with their user account or with a group they are a member of are automatically made available to them as favourites.  This allows you to manage your MobileShell commands in modules using the PowerGUI Script Editor, and whenever you publish a new version your MobileShell users will automatically have the commands from that version available on their handheld device when they log on!

We didn’t forget the freeware community either!  This release also includes the following features for both PowerGUI Pro and PowerGUI (freeware):

  • Virtualization support in PowerGUI!
    With version 2.3, the VMware PowerPack is now available as a core PowerPack included in the PowerGUI Admin Console.  This PowerPack is a fantastic way to manage your virtualization infrastructure.  If you want an example of how this might make a difference for you, have a quick look at this blog post.
  • HTML Reporting support in PowerGUI!
    We have had an Advanced Reporting PowerPack available for download from PowerGUI.org for a while now.  That PowerPack has recently been renamed the HTML Reporting PowerPack, and it now comes with PowerGUI.  This PowerPack allows you to generate HTML reports with features such as indenting, grouping, collapsible sections, and support for list or tabular format for any data you have in front of you in the PowerGUI Admin Console grid.  Just click on the “Create report…” action, configure the report you want to generate, and it will handle the rest for you!
  • Enter-PSSession and Exit-PSSession support!
    You asked, we answered.  Now you can use Enter-PSSession and Exit-PSSession from within the PowerGUI Script Editor to manage remote machines as if you were working on them locally.
  • Greatly improved snippet support!
    This one is a personal favourite of mine.  Snippets are a great way to create a lot of useful PowerShell functionality really quickly.  You just insert the snippet you want, fill in the input fields, and you’re done!  We have had this for a while, and now we have added more features to this support including:

    a) Support for user defined snippets!  If you have snippets you want to use in PowerGUI, you no longer have to have admin access to put them in the snippets subdirectory under the PowerGUI installation folder.  Instead, you can put them into your Documents\WindowsPowerShell\snippets folder and they will automatically be picked up by the PowerGUI Script Editor.  Even better still, if you have a snippet that comes with PowerGUI that you want to override, you simply use the same relative path in the snippets folder in your profile and your snippet will be used in place of the one that comes with PowerGUI!

    b) Support for snippets in modules!  If you import a module, and if that module has a snippets subfolder, then PowerGUI will recognize those snippets and they will be available in the Script Editor automatically.  This allows module authors to include snippets as part of their offering so that users can learn how to use the module commands much more easily!  If you author a module and share it with others, I strongly encourage that you add snippets to that module.  Your module users will thank you for it!

    c) Support for using snippets from any path on your system!  PowerGUI now uses a PGSnippetPath environment variable to decide where to look for snippets, allowing you to reference snippets from any path you include as part of that environment variable!

    Can you tell I love the snippet features? Smile

Of course we also included some bug fixes as usual.  One worth highlighting is that the PowerGUI Script Editor can now be used to debug files that are in a path containing paired square brackets.  We have had several customers let us know that they use these types of paths and that our new debugger wouldn’t stop on breakpoints for them, and this issue is now fixed.

This is a totally awesome release, and I’m really happy that I can finally share it with you!  If you are already a PowerGUI Pro or PowerGUI user, you’ll probably notice the auto-update notify you of the new release when you start it up very soon.  If you don’t want to wait though, you can always force PowerGUI to check for updates using the “Check for Updates” menu item in the help menu, or you can update it manually by downloading it from Quest SupportLink if you use PowerGUI Pro or from the PowerGUI.org download page if you use the freeware version.

I will be recording screencasts for some of these specific features very soon so that you can see how they work first hand, but don’t hesitate to try them out in the meantime and ask questions if you have any.  Also please share any feedback you have for this release, I’d love to hear what you think of it and what you would like to see in future releases!

As always, thanks for your continued support, PowerGUI would not be what it is if we didn’t have such a great community!

Happy scripting!

Kirk out.

PowerGUI® Challenge 2010 Winners!

Kirk Munro4 Comments

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

Kirk Munro87 Comments

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

Kirk Munro2 Comments

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?

Kirk Munro3 Comments

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® Pro and PowerGUI 2.2 are now available

Kirk Munro15 Comments

I just finished releasing the bits for PowerGUI Pro 2.2 and PowerGUI 2.2 to the web.  This release contains some really useful updates to PowerGUI, most notably a new debugging engine based on the native PowerShell 2.0 debugger.  This allows you to do take advantage of all of the debugging functionality in PowerShell 2.0, including support for:

  • The Disable-PSBreakpoint, Enable-PSBreakpoint, Get-PSBreakpoint, Remove-PSBreakpoint and Set-PSBreakpoint cmdlets;
  • Command and variable breakpoints;
  • $MyInvocation;
  • and more

For basic debugging support of a single script file you might not notice a difference right away, but if you do anything beyond basic scripting the new debugging engine will be a welcome change.  It allows you to set breakpoints in a module that you have loaded or a script file that you have dot sourced, and the debugger will open the file with the breakpoint if it is not already open and stop on the breakpoint when the breakpoint is hit.  It also allows you to debug module scripts themselves by setting a breakpoint within a module psm1 file and loading the module using the Import-Module cmdlet from the embedded PowerShell Console.  Breakpoints are retained between sessions as well, so that you can pick up where you left off day after day.

In addition to the debugger changes, there are a number of useful bugfixes included in this release such as improved compatibility between the PowerGUI Script Editor and the Quest AD cmdlets when using STA mode (the default), proper $MyInvocation support in scripts, and other fixes that allow Start-Job and Invoke-Command to be used in scripts that are run through the debugger.

To get the latest release, if you are a PowerGUI Pro customer you can visit SupportLink to get the most recent version or if you use the freeware version you can visit the PowerGUI Downloads page and download and install the release from there.  Alternatively, for both PowerGUI Pro and PowerGUI freeware you can simply wait until auto-update kicks in and prompts you to upgrade (auto-update checks for a new version once per day, the first time you open the product each day), or you can use the Help | Check for Updates menu item in the Admin Console or Script Editor to check for updates without waiting for the next time it checks automatically.

Note to 2.2 public beta testers: if you were participating in the PowerGUI 2.2 public beta, and if you upgraded your beta install to the release candidate when we had posted it, then you already have the RTM version of PowerGUI.  We collected feedback during the release candidate stage and did our own internal testing and the release candidate was solid enough that we were able to leave it as is.  This means that you don’t have to do anything to upgrade to the 2.2 release in this case.

As always, if you have questions, comments, concerns, we’re always listening.  Please let us know what you think of the new capabilities that are introduced with the new debugging engine!

Kirk out.

The heat is on! Enter the PowerGUI® Challenge today!

Kirk Munro1 Comment

Last month I announced the PowerGUI Challenge, a contest that gives you the opportunity to win some money while having fun with PowerShell and PowerGUI.  Well the contest is going on right now (it started last Friday), and contestants have already started submitting their entries.  This is a great way to collect feedback from the community which allows you to make your entries even better.  The contest runs from October 15, 2010 to November 15, 2010 and it gives you a rare opportunity to show your PowerShell talent to a line-up of fantastic judges.

So far we have two entries, one in each category:

  • a Copy to Colorized HTML Add-on for the PowerGUI Script Editor that makes it easier to copy and paste your scripts into HTML compliant programs like Microsoft Outlook or Windows Live Writer with line numbers and syntax highlighting preserved; and
  • a SharePoint 2010 PowerPack for the PowerGUI Admin Console that allows you to manage some SharePoint entities that were missing or buried in Central Admin from an easy to use management console.

These are great entries, and since they were posted early the authors will be able to collect feedback and improve their entries before the contest finishes.  One of them has already received quite a bit of feedback and posted an update, and we’re not even a week into the contest yet!

If you’re interested in participating in the contest, here is what you should do:

  1. Visit the contest page to familiarize yourself with the rules and to discover the resources that are available to you.  There is a lot of information out there to help you out once you know where to find it.
  2. Decide whether or not you want to create a PowerPack (management interface extension) for the PowerGUI Admin Console or an Add-on for the Script Editor.  If you work with products that have PowerShell interfaces for them already, creating a PowerPack is really easy.  In fact, you might even be able to do it in 10 minutes.  There are plenty of products out there with PowerShell support that don’t have a PowerPack already, so pick your favorite and put a PowerPack together.  Some possibilities that come to mind are the System Center products, Forefront products, and Intel’s vPro module.  There are plenty of others too.  If you prefer working with scripts and the command line than a user interface, think about additional features you would like to see in the PowerGUI Script Editor and try adding them yourself.  There are a lot of Add-ons available already to give you samples to work with, plus an Add-on Authoring Toolkit and a tutorial to help you get started.  There are even snippets to make it easier to create Add-on extensions.  There are tons of possibilities for Add-ons, and you’re only limited to where your imagination can take you.
  3. Ask questions!  Anyone including the judges can answer questions you have about the contest or about PowerPack and Add-on creation.  If you have a cool idea but you’re not sure how to do it with PowerShell scripts, ask!  I have contestants who contact me regularly with questions via direct mail, and others who post questions on the PowerGUI Forums.  These resources are there to help you out, even during the contest period, so use them early and often to help you get ahead on your entry.
  4. Learn by example.  There are tons of PowerPacks and Add-ons available in the PowerGUI Library.  If you’re trying to figure something out, there are likely other PowerPacks or Add-ons out there that do something similar.  They are all open source, so you can see the PowerShell scripts that drive their functionality.  These are great resources!
  5. Post early, update often.  The community is already established to give you feedback, so use it to your advantage.  Leveraging the community will only help make your contest entry stronger.

You can use either PowerGUI Pro or PowerGUI to create your Add-ons and PowerPacks, and anything you create will work in both products so pick your favorite and get started soon!  I look forward to seeing your entries, and will be happy to answer any questions you may have along the way to help you out.  Have fun!

Kirk out.

PowerGUI®, Lego edition

Kirk Munro4 Comments

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