Poshoholic

It’s hard to believe that April is almost here already.  Last week we had record high temperatures reaching 31°C (that’s 87.8°F for those of you living south of the border), and the night before last it was -16°C (or 3.2°F).  What wonderful consistency.  Maybe that’s why I like PowerShell so much, because it provides great consistency that just isn’t apparent in so many other places in life (that’s a swell tagline: “Use PowerShell, because it’s more consistent than the weather” ).  Anyway, I digress…back to the topic at hand.

This April is “Learn More About PowerShell” month!  Ok, so it’s not official (it’s not like I’m a mayor or anything), but with all of the opportunities to learn about Windows PowerShell in April, it seems like a fitting title, so I’m declaring it that anyway.  Now, where to begin.

2012 Scripting Games

The first Monday in April (that’s April 2, Monday next week) marks the official opening of the 2012 Scripting Games!  The Scripting Games are a great event, because they provide opportunities for beginner and advanced scripters alike to learn more about Windows PowerShell.  There are beginner and advanced divisions, with 10 events in each division.  You participate by visiting the official 2012 Scripting Games page starting on Monday April 2 to see the events that are published so far, and you have one week to submit a solution by publishing a script to the 2012 Scripting Games page on PoshCode for each event that you want to enter.  Note that at the time of this writing, the 2012 Scripting Games page on PoshCode shows information related to the 2011 Scripting Games, so for now just put a reminder in your calendar to check these two links out on April 2.

Once you submit a solution, you can move on to the next event if it is available.  All solutions will be judged by a great panel of expert judges, and once the events close there will be expert commentaries published so that you can learn how different community experts solve these problems with PowerShell scripts.  Watch for my expert commentary to Beginner Event 3 once that event has closed for submissions.

The 2012 Scripting Games will run until April 13, 2012, although you’ll have 7 days from the day that each event is posted, so there will still be some time to compete and get your entries in.  There are many prizes to be won, including grand prizes of full conference passes for TechEd North America 2012 (another great opportunity to learn more about PowerShell), software licenses for products like PowerWF, and more!  Also, don’t delay in getting your entries in, because you’ll barely have time once you’re done to pack your bags for the 2012 Microsoft Management Summit in Las Vegas if you’re going to that conference!

2012 Microsoft Management Summit

In just 2½ weeks from now, the 2012 Microsoft Management Summit (MMS) will start, and it’s going to be an amazing conference this year.  With the upcoming Microsoft System Center 2012 release, and with Windows 8 currently available as a Consumer Preview in the client and the server varieties (both of which include the pre-release version of PowerShell version 3), there are plenty of new opportunities to scale up your PowerShell prowess and scale out your scripting capabilities while learning how to get the most of these new products and platforms by leveraging PowerShell automation.

At the MMS 2012 conference, there are a total of 13 breakout sessions, 3 instructor led labs, and 5 self-paced labs where you can learn more about Windows PowerShell.  There is also a PowerShell booth that will be staffed by members of the Windows PowerShell team and a few PowerShell MVPs.  I’ll be working the PowerShell booth as will Aleksandar Nikolic, so please come see us and ask questions if you have any.  There will also be other booths for products like the Microsoft System Center 2012 release, which comes with even more PowerShell capabilities than before.  Additionally, there are many companies in the Expo hall that leverage PowerShell in their products and/or provide cmdlets to facilitate automation in their environments, such as NetApp, Veeam, Splunk and Devfarm Software (the company that I work for) to name but a few.  I’ll be working the Devfarm booth when I’m not in the PowerShell booth, so if you look around a little you’ll have a good chance of finding me.

If you’re going to MMS 2012, and you want to learn more about PowerShell, make sure you take advantage of these resources while you’re there.  The knowledge passed on to you through one breakout session, lab, or discussion with someone in the learning center or expo hall takes many, many hours to put together, and getting that knowledge first hand can be a huge timesaver for you in the long run!

PowerShell-related Content at MMS 2012

The following list identifies all of the PowerShell-related sessions and resources that have been announced so far for the MMS 2012 conference for your convenience.  To get the most value out of your conference, make sure you add the sessions, labs, and other items of interest to your schedule so that you don’t miss out on these great learning opportunities.  I have highlighted the sessions most interesting to me in bold in the list below.

2012 North America PowerShell Deep Dive

As if all of these PowerShell learning opportunities weren’t already enough, there’s even more you can do in “Learn More About PowerShell” month.  At the end of April, a week after MMS is finished, the 2nd annual North American 2012 PowerShell Deep Dive conference will start.  This conference is second to none when it comes to learning more about PowerShell.  The sessions are fantastic, and the conversations perhaps even more so.  What makes this conference unique is the focus on shorter, 35-minute sessions that quickly drill into a specific topic and give you a ton of information on that topic.  There are also short, 5-minute lightning rounds which give speakers an opportunity to quickly show off one of their favorite aspects of PowerShell.  The 35-minute format, 5-minute lightning rounds, and the depth of the content in these sessions are unique to this conference, and you won’t get the same value for PowerShell content anywhere else.  Add to that the evening script club-style events and it’s really an experience that is second to none.  I highly recommend you consider attending if you’re already using PowerShell and want to take your skills to new heights.  You can still register for this great event on the registration page for The Experts Conference (TEC).

This conference takes place in sunny San Diego from April 29th until May 2nd, and it gives you 3 days of 100% PowerShell content.  I’m fortunate enough to be attending this conference as well, and I’ll be giving sessions about proxy functions and about WMI and PowerShell.  If you do attend, please make a point to say hello and introduce yourself if I haven’t met you already.

Here’s a quick look at the content that is being presented at the PowerShell Deep Dive this year:

Wow, that’s a lot of PowerShell!  With all of these opportunities, whether you’re trying to learn PowerShell without incurring a huge expense, or travelling to conferences to learn more about technologies there, there’s definitely something for everyone in what looks to be an awesome “Learn More About PowerShell” month.

Good luck, wherever your learning adventures take you!

Kirk out.

Note: This blog post refers to an issue identified in PowerSE 2.7.0. It has been corrected in PowerSE 2.7.1, which is now available.

With the release we published yesterday, both PowerSE and PowerWF received a new feature: product-specific profiles.  This feature allows you to have profile scripts that you only want run in PowerSE or PowerWF run there so that you don’t have to use if statements to check the host name in your profile scripts.  With this feature we also created the initial PowerSE and PowerWF profile scripts such that they dot-source the native PowerShell profile script by default so that what runs in PowerShell also runs in PowerSE.

Unfortunately there is one small detail that was left out of the PowerSE installer for this feature: the installation of the initial PowerSE-specific profile. As a result, if you download PowerSE 2.7, your PowerShell profile won’t run right away.  Fortunately the fix is simple.  All you need to do is invoke this script from inside PowerSE 2.7:

if (-not (Test-Path -LiteralPath $profile)) {
    Set-Content -Path $profile -Value @’
if (Test-Path -LiteralPath $profile.CurrentUserPowerShellHost) {
    . $profile.CurrentUserPowerShellHost
}
‘@
}

Once you have run that script, your PowerSE profile will exist and it will be defined to load your PowerShell profile.  Restart PowerSE 2.7 and you’ll have your PowerShell profile loaded by default again.

Note that this does not apply to PowerWF users, the profile scripts were added correctly to the installer for that release.

My apologies for the inconvenience.  We hope to have this resolved in the product itself very soon.  In the meantime this short script should work around the issue for you.

Kirk out.

This morning PowerWF and PowerSE 2.7 were released to the web and they can now be downloaded from http://www.powerwf.com.  These releases offer a lot of new value to PowerWF and PowerSE users, as follows:

PowerWF 2.7 Highlights

New Start Page with New Workflows

The start page in PowerWF has been completely redesigned to provide immediate value out of the box for PowerWF customers.  The new design highlights the Workflow Library that is included with PowerWF, allowing customers to play workflows in the library without opening a workflow or script document.  Users can also customize the workflows on the start page and add their own groups of workflows for easier runbook automation.  This immediate out of the box value is included for PowerWF customers to allow them to leverage the power of Workflows and PowerShell in their environments without requiring any knowledge of PowerShell or Workflows.

New Management Packs for System Center Service Manager (SCSM)

PowerWF for Service Manager has always included several useful management packs for SCSM in the product.  In this release, even more management packs for SCSM have been added.  Now, with a click of a button you can deploy management packs that automatically close resolved incidents, expire inactive problem announcements, cancel pending activities for closed change requests, identify problems from incident trends, notify incident authors about unresolved incidents, and get SCSM statistics.  These management packs are only available for licensed users of PowerWF for Service Manager.

Improved Toolbox Search

The search engine in the Activity toolbox just got better!  Now you can search using command names or keywords and PowerWF will return the best matches based on the terms you provided.  This includes searching with keywords that are only referenced in activity documentation and not in the command name itself.  For example, if you’re a VMware administrator, simply entering “vMotion” into the search box will reveal the MoveVM activity that is necessary to perform vMotion tasks.

Product-Specific Profile Support

PowerWF now uses its own product-specific profile support, and it updates the $profile variable to include the paths to each of the relevant profiles that you use. By default the PowerWF profile dot-sources the native PowerShell console profile, however you can change this behaviour as required by simply modifying the profile yourself in PowerSE.

PowerSE 2.7 Highlights

Easier Breakpoint Management

Breakpoint management in PowerSE just got a lot easier.  PowerSE now includes a Breakpoints pane to allow you to see all breakpoints you have set in your scripting environment, and you can now manage breakpoints using the breakpoint cmdlets and see the breakpoints you have created in the Breakpoints pane.  This gives you easy creation of line breakpoints using the Toggle Breakpoint feature or command and variable breakpoints using the Set-PSBreakpoint cmdlet (or sbp alias for short).

Breakpoints Preserved Across Sessions

Breakpoints are now automatically preserved across sessions, allowing you to continue debugging your scripts from one session to the next.  They are also preserved when you close a file, so you won’t have to reset breakpoints each time you return to a script you were working on.  You can still remove breakpoints of course, using the Toggle Breakpoint feature or the Remove-PSBreakpoint cmdlet.

Improved Help Search

PowerShell help topic files are now included in the help search pane, allowing you to search for help for integral keywords like if or foreach, or for topics like “Advanced functions”, or you can learn more about remoting by searching for “Remote”.  Also, if no results are found when you search, PowerSE will now include a keyword search in command descriptions to allow for users to discover commands using related terms, such as “vMotion”.

Product-Specific Profile Support

PowerSE now uses its own product-specific profile support, and it updates the $profile variable to include the paths to each of the relevant profiles that you use.  By default the PowerSE profile dot-sources the native PowerShell console profile, however you can change this behaviour as required by simply modifying the profile yourself in PowerSE.

And that’s not all!

This shows you a few of the highlights of this release, but of course there were plenty of bug fixes, some performance improvements, and a few other minor enhancements that were included as well.  Whether you’re a current PowerWF or PowerSE customer, or someone who is looking for great tools for working with PowerShell, Workflow, and Management Packs, I strongly encourage you to give this release a try and let us know what you think.

Kirk out.

Recently there was a discussion between community experts and a product team about a module they are working on.  The topic being discussed was cmdlet aliases: whether or not they should provide aliases for their cmdlets out of the box and if so, how they should be provided.  Aliases are great for ad-hoc PowerShell work, which is what most PowerShell users do at this point, and incredibly useful when you’re trying to put out a fire and managing your infrastructure using PowerShell.  However, there are many important things that module authors need to consider when planning aliases for their cmdlets, as follows:

1. There are many cmdlets out now, and more and more every month.  Coming up with a vsa (very short alias) that is unique is a challenge at best, and the more time goes by the more tla’s (three-letter aliases) will get used up.  The likelihood of an alias conflict is already high, and increasing all the time given the number of commands that are available both from Microsoft and from third party vendors.

2. The land grab with alias names is worse than it is with functions or cmdlets.  With functions or cmdlets, you can have multiple modules loaded with conflicting names and access either command using the fully qualified command name.  With aliases though you are not provided this same capability – there can be only one.  Aliases are simply commands set to a single value and they cannot be qualified using a module name qualifier to disambiguate if a name conflict arises.

3. Depending on how careful (or not) that developers are, it is very easy for a module author to completely take over (overwrite) an existing alias with no warning or message indicating that this has happened, resulting in potential command hijacking between module teams.  A simple call to Set-Alias does this without warning.  On the flipside, if developers don’t hijack aliases, then some of the aliases they would otherwise create may simply not be defined.

4. When aliases are hijacked, unloading a module doesn’t correct the problem because an alias that was overwritten by a module alias will simply become completely unavailable when the alias is removed as the module is unloaded.

As far as I am aware, this situation does not improve with the next version of PowerShell either, so it’s years away from getting better.

Believe it or not, even with these things in mind, I’m actually still pro aliases.  I just think that some extra care/thought needs to be put into their definition.  There is no real standard here that both satisfactorily addresses the issues identified above and that allows for consistency across companies/teams at this time.  Given that is the current state of affairs, if you are considering aliases for your module I recommend one of the following approaches:

1. [SAFEST] Rather than trying to come up with something that can be shipped despite these issues, at this time I think aliases would be best addressed in a "tips and tricks" type of blog post, proposing a short script that defines some useful aliases for the module/snapin in question in order to allow admins to be able to deal with fires quickly using ad-hoc PowerShell commands via some aliases.  Such a script should generate warnings whenever a name conflict is discovered so that users are aware when an alias either cannot be created or is overwritten.

2. [EXPERIMENTAL] Ship aliases with your module, but try to make sure they really are unique.  For example, if you’re a vendor whose company name starts with Q, you could prefix all of your aliases with "q".  This is attractive because there are no verbs that start with "q", so right from the start you’ve dramatically reduced the chance that you’ll have a conflict, setting yourselves up better to have aliases that belong to you.  Then you would only have to coordinate within your company to make sure the aliases used across teams are unique.  This isn’t foolproof though because there may be multiple products/vendors that adopt the same standard, and if the name of your company or product starts with G, the likelihood of a conflict would be much higher (the alias prefix used for "get-*" cmdlets is "g") so you may want to choose a pair of letters instead.  Regardless, you’ve likely reduced the risk, and you could generate a warning whenever you run into a conflict that prevents an alias from being created.

3. [RECOMMENDED] Lots of 1 and a little bit of 2: use unique alias names that work for your product team/company, but don’t ship them with the module.  Instead, push them out as a value add on a blog post, and see how the community responds.  At the same time work with MVPs and Microsoft to get these issues addressed such that a shorthand system for command names does work.  Some MVPs, already proposed a few things to the Microsoft PowerShell team that could help here (aliases for module names for one — think PS\gsv for a core PowerShell version of Get-Service or EX\gu for the Get-User cmdlet that comes with the Microsoft Exchange module or AD\gu for the Get-User cmdlet that comes with the Microsoft Active Directory module, and so on), but more discussions need to happen and this will take more time.

I recommend the third option because given the current issues with alias hijacking and with no support for disambiguation, it seems to be the best solution for now (from my perspective at least).  If you have come up with other alternatives that resolve these issues, please share them with the community so that this improves going forward.

Hope this helps,

Kirk out.

Every year around Christmas I anxiously await the New Year to see if I receive the Microsoft MVP award again that year.  Well that email came on January 1, 2012, and I’m quite thrilled about this one because it’s a milestone this time (year 5 as a PowerShell MVP).  Thanks to the community for being so great to work with, and thanks to Microsoft both for recognizing individual efforts with the MVP program and for creating such great products like Windows PowerShell!  Work has never been so much fun!

Kirk out.

A little over a week ago we released PowerSE 2.5.3 to the web.  You can download the latest release here.  This release includes many great improvements to the PowerSE product, many of which were requested by you, so thanks for your feedback and please keep it coming!

No time limit for freeware

With this release, we’ve removed the requirement to re-download this product every 60 days.  This was our number one feature request since we made PowerSE a freeware product.  Now when you download PowerSE 2.5.3, it is truly freeware and you can use it as long as you like!

PowerVI Integration

Since PowerVI has joined the Devfarm family of products, we have now improved the integration between PowerVI and PowerSE and PowerWF. This enables easier authoring and testing of VMware automation scripts and workflows before you publish them to be integrated in the vSphere client, and it highlights one of the greatest values of the Devfarm products – the rich integration between them that make everything much easier.

Tabs to spaces support

We’ve added support for configuring how tabs are used in the PowerSE Script Editor.  If you want spaces inserted when you press the Tab key while editing scripts, all you need to do is to set $psise.Settings.AutoConvertTabsToSpaces to $true in the embedded console.  If you want the tab size to be something other than the default value of 4, you simply set $psise.Settings.TabSize to the number of spaces you want to use for tab characters.  These only need to be set once, so you can simply make the calls in the embedded console and then you’ll always have it configured that way going forward.

Enhanced history pane

The history pane in PowerSE has always been useful, but now it’s much better!  With the history pane in PowerSE 2.5.3, you can identify which commands were successful and which were not, all at a glance by looking at the icon.  You can also tell which commands were allowed to run to completion and which were cancelled.  Most importantly, you can identify the duration of any command that you run, so if you are trying to get the most performance from your scripts, this is an easy way to compare the performance for several related commands so that your scripts run as fast as they can.

Greatly improved support for international environments

In previous releases of PowerSE, there were a number of defects preventing international keyboard layouts (i.e. those other than “US English”) from working properly in the embedded console.  Those defects have been fixed, so now you can use the embedded console with international keyboards just fine.

We also added support for Unicode characters to the embedded console, making it easier for customers to get the output they expect regardless of where they happen to be.

Multi-select support in the File|Open dialog

With PowerSE 2.5.3, you can open multiple files in one folder at once by simply selecting the files you want before you click on the Open button.  This can be a big timesaver when you are working with modules containing many files!

Smarter variable Intellisense

When you enter a variable name in a script, it can be difficult to determine if you are entering the name of an existing variable or if you are creating a new variable.  Previous releases would sometimes complete a variable name incorrectly when you were in fact creating a new variable name.  This shouldn’t be a problem any longer, because we now allow you to enter new variable names and the auto-completion should only happen when you want it to happen.

Proper ps1xml file support

In PowerSE 2.5.3, if you are working with ps1xml files, you will now get proper Intellisense as well as auto-completion of xml elements as you would expect.

Fast clearing of the embedded console window

In today’s era of PowerShell, we all want to do more in less time, so much so that even typing in cls in the embedded console and pressing Enter can be cumbersome when you do it repeatedly.  PowerSE 2.5.3 allows you to clear the embedded console window at any time by simply pressing Ctrl+Del.

And more…

This is just a short list of some of the key changes we have made in this release.  There are others that I want to talk about, but I’m going to save a few for follow-up blog posts.  We’ve been spending a lot of time on PowerSE recently, and between our hard work and your great feedback, we’ve built a fantastic, best-in-class PowerShell script editor!  If you write PowerShell scripts, I encourage you to give this release a try, and be sure to let us know what you think!  Also, if you have any questions, feel free to leave me a note on my blog or pop over to www.devfarm.com and ask us directly in the chat window.  We’re always listening!

Thanks,

Kirk out.

I always enjoy this time of year.  There is something about the transition that happens over Labour Day weekend that always gets me excited.  Maybe it’s a lingering feeling of anticipation over the new year at school or university from years gone by, a feeling that I can still appreciate these days as I watch my kids getting excited about their education and the new activities they will sign up for this fall.  Regardless, it’s always a fun time of year for me.

This year though I have some extra reasons of my own to be even more excited.  As of this morning, I am now working as Product Manager for the PowerWF and PowerSE products at Devfarm Software!  I am absolutely thrilled about this new position!  Devfarm has a great team and a great set of products, and I’m really happy to be able to help them drive those products forward.

With this news, today marks the end of a month that included some vacation time, some time to step back and refocus, and some time for reflection on what to do next.  During this time I received a ton of support from friends and followers in the PowerShell community, and for that I am very grateful.  This support helped one particular sentiment that I came across stay with me:

You know for a (while) I (wondered if) going back to the amazing experience of (PowerShell) wouldn’t be a good idea, but really now I’ve come completely around because (software can be) stressful and hard to make but ultimately what makes (it) fun is the people that you work with, and the fact that (I’m) going to be working with a lot of the old gang, with a lot of friends, and obviously making some new friends is really the point of being here, so I’m extremely thrilled.¹

This really represents how I have felt since my departure from my last job as Product Manager for PowerGUI.  I really love PowerShell as a technology, but as great as that technology is, it just wouldn’t be the same without the community that surrounds it.  PowerShell is blessed to have a tremendous community, and I am very, very proud to be able to continue to participate in that same community as a Product Manager for some really cool products that use PowerShell, as a PowerShell MVP, and as a geek who fell in love with technology a long time ago.

Now that I’ve found my new direction and focus, it’s time to get down to business.  Whether you’re a current user of PowerWF or PowerSE or someone who is interested in trying PowerWF or PowerSE, I’d love to connect with you to hear what you like (or don’t like) about these products as well as what you would like to see added to them in the future.  Feel free to reach out to me at any time either in my blog comments or by using the Contact Me form on my blog.  I’m really looking forward to working with you.

Kirk out.

¹ Paraphrased from Peter Jackson’s speech on the first day of filming for “The Hobbit”; his exact speech can be heard here: http://www.youtube.com/watch?v=LqzJ1LFh6x0&hd=1&t=9m15s.

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:

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.

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.

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:

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:

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.