One for the road: Stepping away from PowerGUI®

Today was one of my most difficult days in my 7½+ year career at Quest Software.  The same week that I was given a performance raise (I got that email on Monday), this afternoon I got a phone call from the director over my business unit letting me know that my position has been cut effective immediately.  Part of a book balancing effort it seems –  funny (or not so much) how life works sometimes.

I’ve accomplished a lot while working at Quest, and spent a ton of professional and personal energy on the company and its products, particularly PowerGUI (far too much energy if you ask my wife, and today I must say I’m tending to agree).

Since I started working with the PowerGUI team at Quest back in 2007 (back in the version 1.0.x days) I have:

  • been awarded the Microsoft MVP award for my community support Windows PowerShell four years in a row
  • received recognition as a Quest Software expert in Windows Management (only 1% of the company employees have received this recognition)
  • provided feedback and direction over the product and its features through 3 major release cycles and many minor releases
  • supported the product and the community as a PowerPack developer, then as a PowerShell Solutions Architect, and most recently as the Product Manager (although I never could get those other positions backfilled so I ended up wearing all three hats most of the time)
  • released dozens of extensions for the product, including PowerPacks for platforms such as Active Directory, VMware, Hyper-V, and Exchange, and Add-ons such as the Script Editor Essentials Add-on or others for specific features such as script signing, transcription, the PowerShell blue console theme, and many more
  • pushed the number of commercial features in PowerGUI Pro from two when I took over as Product Manager to over six in the current version with many more on the way
  • initiated strategic partnerships with key enterprises such as NetApp and Intel and helped them create their own PowerPacks for their platforms
  • helped drive traffic to the powergui.org site through my blog and through social media as we grew the number of downloads from 100000 to over 1.2 million
  • provided feedback and direction to internal teams at Quest with PowerShell support in their products
  • successfully presented well-received PowerShell-focused sessions at many user groups and also at conferences such as Microsoft TechEd, the TEC conference, the PowerShell Deep Dive (a mini-conference in the TEC conference), and TechDays Canada
  • been elected as President for the PowerShellCommunity.org site
  • coordinated and provided direction over the first ever PowerShell Deep Dive conference

Unfortunately, most of that is now a legacy as it came to an abrupt end today.  I’m still a PowerShell MVP, and I will still be involved with the PowerShell community, however my work on PowerGUI has stopped for now.

Before I step back from this though, and before I reorganize/refocus my efforts onto more important things, I wanted to share one more new PowerGUI feature that I recently created for the community that I have spent so much time with these past 4 years.  I still have a strong affinity for PowerGUI and a lot of my heart and soul has gone into this product, and this feature is just a small example of that effort.  The new feature comes as part of the Call Stack Window add-on that I just published in the PowerGUI Add-on library.  Here’s a screenshot showing you what this add-on looks like in action:

PowerGUI Script Editor Call Stack Window

This add-on adds a call stack window to your PowerGUI Script Editor every time you start debugging a script. Working with a call stack while you debug anything beyond the most simple of scripts is essential because it provides you with a list of all nested calls that led up to the current line of script in your debug session. You can use this to determine where functions are being called from by setting a breakpoint inside a function and then walking up the call stack to see the script used to call the function. Also, this window has double-click support, so if you would like to go to any location in the call stack, simply double-click on the location you wish to see and the add-on will take you there, even if the file in question isn’t open at the time.

I was considering putting this feature in the Pro version in a future release, but that is beyond my control now so I decided I’d share what I have today and let you guys have fun with it.  Since I created the feature in this add-on, it’s been an incredibly useful feature to me and I hope you guys enjoy it as well.  To get this Add-on, simply select Tools | Find Add-ons Online in your PowerGUI Script Editor and search for “Call Stack”.

That will most likely be my last PowerGUI-centric post for a while, and it will be my last post for at least a week while I take a much needed vacation before moving on to new things.

Thank you for your continued support through the past four years.  I hope this post finds you well.

Sincerely,

Kirk Munro
Former Product Manager of PowerGUI Pro and PowerGUI

P.S. If you are in need of someone with my skills, either as a Product Manager, a PowerShell MVP, an expert in Windows management (with a strong focus on Active Directory and Exchange although I’ve also gotten deeply involved in virtualization with Hyper-V and VMware as well), a social media/community site manager, or as a freelance writer, my schedule has all of a sudden become much less busy and I’m interested in filling up that time with new work once I come back from vacation, so please get in touch.

PowerGUI® 3.0 Hotfix: Double-clicking on a ps1, psm1, or psd1 file to open the Script Editor shows the Start Page as the active page in the Script Editor

This article describes an issue that was introduced into both PowerGUI and PowerGUI Pro when version 3.0 was released and provides a recommended solution to that issue.

Problem

While the PowerGUI Script Editor is closed, double-clicking on a ps1, psm1 or psd1 file or right-clicking on one of those file types and selecting “Open with PowerGUI Script Editor” will open the file you selected in the Script Editor as expected; however the Start Page will appear as the active tab in the Script Editor instead of the file you opened.

Affected Products

  • PowerGUI 3.0 (freeware)
  • PowerGUI Pro 3.0

Solution

To resolve this problem, a new version of the Script Editor Essentials Add-on has been released.  This version (3.0.0.75) includes a modification to the Script Editor behaviour such that any file you use to open the PowerGUI Script Editor will immediately become the active file.

To install this hotfix, please follow these steps:

If you are connected to the Internet

  1. Open the PowerGUI Script Editor.
  2. Run the following command from the embedded PowerShell console:
    $oldState = $PGSE.Configuration['/CollectAndSendInformation']
    if (-not $oldState) {
        $PGSE.Configuration['/CollectAndSendInformation'] = $true
    }
  3. Select Tools | Find Add-ons Online to show the Find Add-ons Online dialog.
  4. Type “Script Editor Essentials” into the text box at the top of the Find Add-ons Online dialog.
  5. Click on the Search button.
  6. Once the search results are returned, Select the Script Editor Essentials Add-on if it is not already selected.
  7. Click on the Install button to download, install and load the Script Editor Essentials Add-on.
  8. Once the Script Editor Essentials Add-on is installed, run the following command from the embedded PowerShell console:

    if (-not $oldState) {
        $PGSE.Configuration['/CollectAndSendInformation'] = $false
    }
  9. Close the PowerGUI Script Editor.

If you are not connected to the Internet

  1. Open your web browser and browse to http://www.powergui.org/entry.jspa?externalID=2952.
  2. Follow the steps outlined in the “Manual install” section on that page, copying the Add-on.ScriptEditorEssentials.zip between machines as appropriate.
  3. Close the PowerGUI Script Editor.

At this point you should be able to double-click on ps1, psm1 or psd1 files if you file association is set up and have those files open in the PowerGUI Script Editor as the active document.

Feedback

This solution is being provided based on the feedback of users who notified us about the issue two days ago on the forums.  If you have any questions about this solution, please let us know in the forums or in the comments on this post.

Thanks!

Kirk out.

PowerGUI® Pro 3.0: Mobile Systems Management Using MobileShell

In case you missed the announcement last Friday, PowerGUI Pro 3.0 was released to the web.  With this release we included a new feature that I’m really excited about: Mobile Systems Management Using MobileShell.  We’ve had MobileShell for quite a while, but prior to this release you could only use it to invoke your favorite scripts or commands from modules associated with your user account as well as ad hoc commands you wanted to run.  Here’s a screenshot tour showing you what this interface would look like on a handheld device:

PowerGUI Pro MobileShell - Favorites - 1 of 4   PowerGUI Pro MobileShell - Favorites - 2 of 4   PowerGUI Pro MobileShell - Favorites - 3 of 4   PowerGUI Pro MobileShell - Favorites - 4 of 4

As you can see from this, the capabilities in this version were very cool (what’s not to like about running PowerShell from your smartphone), but they were somewhat limiting as well because you couldn’t really work with a management user interface from your handheld device this way.

PowerGUI Pro 3.0 changes all of that, by including a new management interface for MobileShell that is based on PowerPacks (in case you don’t know already, PowerPacks are extensions for the PowerGUI Administrative Console that provide a management experience much like MMC, but that are driven entirely by Windows PowerShell commands and scripts).  With 3.0 we’ve provided a new mobile interface for MobileShell that allows you to use PowerPacks associated with your AD user account or groups that you are a member of from your mobile device!  Also, we’ve made the management experience even more responsive at the same time, so now you can do more with MobileShell and it will do it more quickly than before!  All you need is a mobile device with a WebKit-enabled web browser (sorry, that means no BlackBerry 5.x or Windows Phone 7 support for now).

Here’s a screenshot tour showing you how this new experience can be used to do something very simple like unlock a user account:

PowerGUI Pro MobileShell ScreenShot Tour - 1 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 2 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 3 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 4 of 12

PowerGUI Pro MobileShell ScreenShot Tour - 5 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 6 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 7 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 8 of 12

PowerGUI Pro MobileShell ScreenShot Tour - 9 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 10 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 11 of 12   PowerGUI Pro MobileShell ScreenShot Tour - 12 of 12

As you can see from this screenshot tour, this user experience is much richer and it gives you a full management console on the go, allowing you to respond to issues you are responsible for no matter where you are or what time it is.  It’s also configurable using role-based access control (RBAC), so you can assign different PowerPacks to different MobileShell users based on their AD user and group membership.  Even better, we make configuration of this functionality even easier by providing you with a MobileShell Administration PowerPack as part of the PowerGUI Pro 3.0 package.

If you’re interested in trying this functionality out, here’s what you need to do:

  1. Make sure you have an IIS server ready where you can install it.
  2. Install MobileShell on the IIS server.  The MobileShell installer is pretty self-explanatory.
  3. If you didn’t add the MobileShell users during the installation, add anyone who you want to be able to access MobileShell to the PowerGUI MobileShell Users group (note: there may be a delay once you add users before they have access, up to 15 minutes).
  4. Install the PowerGUI Pro Admin Console on the IIS Server with the MobileShell Administration PowerPack.
  5. Open the PowerGUI Pro Admin Console.
  6. In the MobileShell Administration PowerPack, select Users and then click on the Add User action to add your user account.  Repeat this for each user account you want to provide access to.
  7. Select the PowerPacks node and then click on the Publish PowerPack action.  Provide the path for the PowerPack you want to expose via MobileShell and then click on OK.  Repeat this for each PowerPack you want to expose via MobileShell.
  8. Go back to the Users node, select the users you want to provide PowerPack access to, and then click on Assign PowerPack to assign one of the PowerPacks you have published to the selected users.

At this point you should be ready to go with your first MobileShell management experience.  Point your WebKit-enabled web browser to https://serverName/MobileShell/Admin, sign-in, and you’re off and running!

Note: PowerPacks don’t support the new MobileShell management experience by default.  We made the decision to make it off by default because we wouldn’t be able to tell which PowerPacks would display UI on the web server (such as a message box) reliably.  Any PowerPack can support this new experience though, they just need to be updated to suppor tit. The core PowerPacks that ship with PowerGUI Pro have been updated to support this new management experience so you’re already enabled with a rich mobile management experience for Active Directory, VMware, Exchange, and Windows management.  I’ll write another post later that describes what is required to turn on mobile management for a PowerPack.

That’s it for this post.  If you have any questions, don’t hesitate to ask.

Kirk out.

PowerGUI® Pro and PowerGUI® 3.0 are now available

Today’s an exciting day because I’ve finished releasing PowerGUI Pro 3.0 and PowerGUI 3.0 to the web!  This release is something we’ve been working on for a long time, and it has a ton of new goodies for you to play with.  You can learn more about the individual features in this release in the highlights below.  When reviewing these features, anything that is only available in PowerGUI Pro will be marked as a Pro feature.

Mobile Systems Management (Pro feature)

Ever wish you could immediately respond to hot issues from wherever you are without having to run to the office or to your home computer?  Now you can!  PowerGUI Pro 3.0 now provides you with a mobile systems management console on your handheld device!  Better yet, the systems management console you use is fully customizable using PowerShell scripts!  You can also configure different management experiences for different users and groups in your organization by using role-based access control (RBAC) to define which PowerPacks are assigned to various AD users and groups.  Since this leverages the PowerPack model, that’s a whole lot of mobile systems management possibilities for you to pick and choose from.

Here’s a screenshot showing what this looks like as you browse through the Active Directory PowerPack using MobileShell and retrieve an AD user you want to modify:

PowerGUI MobileShell - Managing an AD user object

Currently the list of mobile devices that support this new management interface include:

  • iOS devices
  • BlackBerry devices (BlackBerry OS 6.0 and higher)
  • Android devices (Android OS 2.2 and higher)

You can also use this from a desktop or laptop by connecting with the Chrome 11 and higher or Safari 5 and higher web browsers.

    Customizable Start Page (some Pro-only functionality)

    Completely new to this release, we have created a customizable Start Page that appears when you launch the Script Editor or the Admin Console.  The Start Page is designed to allow you to keep aware of what’s going on in the PowerShell community, provide you with a tip of the day, featured videos, and the most recent additions to the library of Add-ons and PowerPacks on PowerGUI.org.  This feature is available in both the free and the Pro versions, however Pro users get an extra bonus here: with PowerGUI Pro you can customize the RSS feeds that are shown on this page to get even more of your favorite PowerShell news or, if you don’t want to use it that often and you’re a PowerGUI Pro customer you can simply indicate that PowerGUI should not show it on start-up.  Personally I’m a Pro user and I use the new Start Page every day to keep up to date on news.

    PowerGUI Pro Script Editor Start Page

    Create Executable from Script (aka Compile Script; Pro-only)

    Another new feature in PowerGUI Pro in this release is the ability to create executables from script.  This feature greatly simplifies having someone else in your organization run some functionality that you’ve built in a PowerShell script.  Instead of sending them a script, worrying about execution policy, providing them with instructions about how to run the script, and wondering if they’ll modify (and break) the script or not, you can simply provide them with an executable program that does whatever your script was designed to do.  You can also be comfortable with the contents of these programs, either encrypting them with a password or leaving them decrypted, in which case the scripts that are packaged in the executable program are obfuscated to keep their contents hidden from prying eyes.

    PowerGUI Pro Script Editor - Create Executable From Script

Go to Function Definition (Pro-only)

Yet another new feature in PowerGUI Pro 3.0 is support for going to the definition of any function from the name of that function in a script file.  This feature is very useful, both when you’re building your own function libraries or modules, and when you are using other function libraries or modules.  With this feature you can right-click on the name of any function in a script file that you’re looking at and select Go to Definition from the menu that appears.  If it’s not a function, nothing happens, but if it’s a function, you’ll be taken to the location where that function is defined, even if you have changed the file, so it’s great when you’re editing scripts.  If it cannot find the function definition in a file, such as when you right-click on a function that is defined by PowerShell itself, you can show the definitions of those functions in a new file, making it easy to override behaviour this way.  This is great functionality whether you are working by yourself or with a team of users (where you may not know the location of functions you are working with).

Improved Version Control Support (Pro-only)

We spent some time in this release sprucing up our version control support.  PowerGUI Pro has always supported integrated version control.  Now that support is better, allowing you to retrieve files from version control that you have never checked in or out without having to go to a separate client.  It also supports version control providers that have their own check-in dialog, allowing you to make sure you only get prompted for comments during check-in once.

Reset Runspace on Demand

Here’s a really useful new feature that’s available in both freeware and Pro.  As you work with PowerShell, you create variables, add functions, and change the state quite a bit.  A best practice worth following is before you publish any scripts, make sure that they pass your tests in a clean environment.  In previous versions of PowerGUI this would require resetting your runspace with each debug (something I don’t recommend anymore), or restarting PowerGUI.  Now you can simply select Debug | Reset Runspace, and your environment will be reset without having to close and re-open the product.

PowerGUI Pro Script Editor - Reset Runspace on Demand

Improved Snippets Support

Snippet support in PowerGUI has always been best-in-class, but in this release they get even better!  We now have a brand new snippets hierarchy that reorganizes our existing snippets and adds a bunch of new ones.  Snippets are a huge timesaver when it comes to writing PowerShell scripts, and we’ve just made it easier to find the snippets you’re looking for by organizing them better into appropriate folders and adding additional snippets where some were missing.  Personally I’m a huge fan of snippets, and would love to know what other snippets you would like to see going forward.

PowerGUI Pro Script Editor - Snippets Hierarchy

Also, I’m going to call out a specific feature in our snippet support that you may be interested in knowing about.  If you create a module with commands and you want those commands to be easy to use, one very natural way to help your users learn your commands is to provide snippets.  In PowerGUI, when you load any module that has a snippets subfolder as a child of the module base folder, those snippets will immediately become available in the PowerGUI Script Editor.  That means as a module author, all you need to do is ship your module with snippets in a snippets subfolder and any PowerGUI user will automatically get access to them when they load the module.  This is a very cool feature, and one that I encourage you to try out and support.

Performance Improvements

During our beta cycle for this release we spent a lot of time looking at performance and were able to make some changes now and plan some changes for later.  With this release, we have dramatically improved our parser performance, which means that files will parse more quickly in the PowerGUI Script Editor.  This in turn means files will open more quickly, which means the Script Editor itself will open more quickly when you’re loading a lot of files.  There are more performance improvements coming, but we’ve already made great progress and I’m sure you’ll be happy with the improvements in this area!

Multi-line Support in the Embedded Console

Rich Beckett, this bud’s for you!  Rich and a bunch of other PowerGUI users pointed out that they didn’t like how our Script Editor would return an error if you pressed enter when it was obvious that the line was not finished yet (for example, when you finish a line with a round curly brace, or a pipeline symbol, or a line continuance character like the backtick).  We’ve fixed this now, so you can enter multi-line commands without having to worry about getting errors and without having to think about pressing Shift+Enter to get a newline in the command pane.

One-click Install for PowerPacks

In our previous release we added support for one-click install for Add-ons in the Script Editor, allowing users to search for Add-ons on PowerGUI.org and install them with a single button click (there are some highly recommended Add-ons available by the way, so check them out if you haven’t already). Now we’re providing the same support for PowerPacks, so you can search online for PowerPacks, select the ones you like from the list of results, and click on a button to download, unblock, install and load those PowerPacks in the Admin Console. We have a large library of PowerPacks available, which you can see by clicking on the Show All button in the Find PowerPacks Online dialog. I strongly recommend you give them a look, because there is a ton of useful PowerShell functionality in those PowerPacks.

AdminConsole.FindPowerPacksOnline

Admin Console Authoring Mode

If you’re like me, from time to time in the Admin Console you accidentally move something, or delete the wrong thing, or make some change you didn’t intend to make. Being able to change any PowerPack is great because it allows for rich customization, but when you’re just using the PowerPacks day to day, you may not want to make any changes. It’s also possible that you’re providing the PowerGUI Admin Console to some staff members who need the features but not the customizability. In those cases, you can now launch the Administrative Console in default (non-authoring) mode, and be assured that you can’t accidentally break one of the PowerPacks. When you need to make changes though, you can open the Administrative Console in Authoring mode and create and customize whatever you like!

Improved Action Support

The handling of Admin Console actions was improved a lot in this release.  Now when you select one or more rows in the grid in the Admin Console, only the actions appropriate for those rows will be displayed.  If you select mutliple objects of different types (files and folders, for example), you will only be presented with actions that apply to both types of objects.  Also, only the relevant actions that don’t require any selection will be displayed when you click on a node or action and no data is returned.  All of these changes make using the Admin Console much easier than before.

Improved Shared Script Support

Shared Scripts in the PowerGUI Admin Console allow you to define functions that you want to have access to in more than one location in a shared script file. These script files would only previously be loaded once you clicked on a script node or script action in a module, meaning that you could not create a simple node or simple action from a function in a shared script file. That’s changed now, such that shared scripts are invoked when you click on any node or action in a PowerPack.

VMware PowerCLI 4.1+ Support

We’ve had a beta version of the VMware PowerPack available for a while that provides support for PowerCLI 4.1.  This release of PowerGUI includes that PowerPack in release form, officially catching PowerGUI support up to the latest VMware PowerCLI releases.

Of course there’s more!

There are a ton of other minor changes in this release as well, ranging from usability improvements to bug fixes to changes that make it a little easier to create PowerGUI Add-ons.  We have new automatic variables ($PGHome, $PGUICulture, $PGVersionTable and $PGSE).  We automatically load PowerPack requirements now when a PowerPack is loaded.  I’m sure there are other changes in this release that I’m forgetting, but suffice it to say, we put a ton of energy into this release and it shows (I’m exhausted! Smile).

Great!  How can I get it?

PowerGUI Pro is a fantastic PowerShell-based product with a ton of value for the $199 US price tag, even more with this 3.0 release.  If you like the features in PowerGUI Pro or if you like what we’re doing with PowerGUI in general and feel it’s time you put your money where your mouth is, simply point your browser to http://www.quest.com/GetPowerGUIProNow to go to our eStore and buy yourself a copy (or two or three Winking smile).

If you’re not ready to commit to the Pro version just yet, please give our new PowerGUI Pro 3.0 release a try by browsing to http://www.powerguipro.com and clicking on the Try button on that page to download a trial version.  A license key will be sent to you to allow you to try it out for 30 days.  If all you’ve been using so far is the freeware version, we have put a lot of energy into the Pro release in 3.0 and this is a trend that will continue going forward, so I strongly encourage you to give it a try and see what you think.  Note that PowerGUI Pro and PowerGUI (freeware) install side by side, so you can try it on the same system where you use the free one…just pay attention to the shortcut you use to launch it so that you get the one you’re looking for!

After you’ve tried out PowerGUI Pro, if you’re not able to spend $199 for the product right now, then we do have the freeware version available from www.powergui.org.  You can’t miss the big Download button near the top of that page.

Of course, if you already have either PowerGUI Pro or PowerGUI freeware, both of these will auto-update to the new version automatically when the auto-update system detects the new version is available.  This should happen the next time you start-up the product.

An Important Note About Feedback and Usage Statistics

With all of our releases, feedback is what drives us and motivates us to continue doing what we’re doing, and this release is no exception.  We received a ton of feedback during our beta cycle and were able to fix some serious issues because of it.  I need to shout out a special thanks to Glenn Sizemore, Chris Piper and Thomy Kay for their feedback – it was particularly helpful!  The key point here though is that the feedback system really works.  If you love something, let us know, we’d love to hear how PowerGUI is making your life easier!  If you don’t like something, let us know that as well, we’ll see what we can do to make it better!  Or if you think we’re missing something, well, let us know!  We’ll see what we can do to put that in!  I manage this product and we have developers who develop this product, but ultimately I’m taking most of my direction from you guys, so please keep the feedback coming!

Also, regarding feedback, I would be remiss if I didn’t mention one last feature that we’ve added to this release.  This release introduces anonymous data collection to PowerGUI.  It was important for us to add this for the reasons I just highlighted in the last paragraph – your feedback is that important, and we can learn a lot about where we need to spend our effort by reviewing usage data.  The data gathered does not contain any personal information, nor does it contain any scripts you write or anything like that.  It’s simply data about how you are using the product.  Please opt-in for this usage data collection so that we can make the product even better going forward.  You can always opt out, but feedback is important, so we’d really appreciate it if you would opt-in.

That’s it for this post.  I hope you like this release, and look forward to hearing about how it’s making a difference for you!

Enjoy!

Kirk out.