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.

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.

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.

Kirk out.

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.

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.

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.

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.

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.

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:

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.



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.

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.

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.

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.

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

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

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.

This screenshot shows two major improvements to the vWorkspace management experience by demonstrating how you can use the vWorkspace PowerPack to perform management tasks across all farms, and by demonstrating how you can use the vWorkspace PowerPack to perform management tasks across all locations in a single farm or across all locations in all farms.  In the native vWorkspace management user interface, you can only work with one farm at a time, and you can only work with one location at a time.

Scaling management tasks out in a product like this can take a long time when you need to build the capabilities into a native management user interface, and these days in many cases PowerShell is provided as the vehicle to satisfy larger scale automation and management needs.  PowerShell is great and it definitely fits the bill for these medium to large enterprise needs, however it does not provide a user interface to facilitate those management scenarios.  This is where the administrative console in PowerGUI Pro and PowerGUI really shines, because it allows you to build out rich PowerPacks with enterprise-ready solutions with very low cost and effort.

I spoke directly with Adam Driscoll (author of PowerGUI VSX, member of the vWorkspace team, and one of two developers who created the vWorkspace PowerPack) about this, and it took them less than one week to put this PowerPack together.  That’s less than one week for two developers to create a rich, functional management user interface that not only provides many of the management capabilities that come with the vWorkspace management console, but that also adds additional enterprise capabilities that the vWorkspace management console does not provide natively.  Aside from the multi-farm management and multi-location management features I mentioned earlier, it also allows administrators to upgrade the vWorkspace VM tools on the VMs you select, and it simplifies how administrators search for provisioning objects like templates, sysprep customizations, parent VHDs, and so on.  And by building these capabilities into a PowerPack, vWorkspace administrators can perform custom filtering and sorting of the data in the grid, generate rich HTML reports for that data, export the data to an external file for use in other programs, and view the PowerShell scripts that are doing all of the work, all because those features come with the PowerGUI administrative console automatically.  That’s an amazing feat for one weeks worth of effort!

The really sweet part of all of this is that it gets even better very soon.  If you’ve been following my blog recently you’ve seen that we have released two betas of PowerGUI Pro 3.0 in the last little while which comes with many great features worth highlighting, however for now I only want to mention one: MobileShell.  In PowerGUI Pro 3.0, you can provide administrators with a custom mobile management solution, defined using PowerPacks and tailored for their needs using role-based access control (RBAC).  That means that once we release PowerGUI Pro 3.0 (which should happen very soon), the vWorkspace guys will be able to publish an update to their PowerPack that enables mobile management support so that vWorkspace administrators can have a mobile management solution for very little cost!  All they will need once the vWorkspace PowerPack is updated to support this mobile management scenario is a license of PowerGUI Pro 3.0 for each administrator who wants to manage their vWorkspace environment from their webkit-enabled mobile device.  Considering that it also allows those administrators to create executable files from PowerShell scripts, work with integrated version control in a best-in-class script editor, manage systems remotely using easy PowerShell remoting capabilities, find functions they are working with using go to definition support for functions, and more, the PowerGUI Pro price of $199/user is a pretty good value.

If you are at all interested in VDI, you should give vWorkspace a look because it’s an awesome solution that keeps getting better all the time.  If you use vWorkspace already I encourage you to take a look at the PowerShell capabilities that this team is providing, particularly in the PowerPack, because a ton of additional value is being provided here that is worth checking out.  You can find the installation instructions for the PowerPack on the vWorkspace PowerPack page on PowerGUI.org.

That’s it for this post.  If you have any questions or feedback, please don’t hesitate to reply in the comments below.

Thanks!

Kirk out.

Here are some details about the improvements that have been made in the 2nd beta of PowerGUI Pro 3.0:

Improved snippets hierarchy

Several users indicated that some of our snippets were hard to find.  To resolve this issue, I’ve reorganized our snippets into an improved snippets hierarchy that should make it easier for you to find the snippets you are looking for and learn more about what you can do with PowerShell from our snippet collection.  A special thanks goes out to Denniver Reining, author of the very popular Snippet Manager Add-on.  Denniver was able to provide very useful feedback as I was going through the improvements in this release, which was very helpful.  To browse the new snippet hierarchy, simply press Ctrl+I while editing a document in the Script Editor.  Here’s a screenshot showing the top level representation of the new snippets hierarchy:

Installer option to open Script Editor

Since the first release of PowerGUI we have provided an option at the end of the installation to open the PowerGUI Admin Console.  This is useful, but myself and many of our users have requested if we could open the Script Editor as well.  With this beta 2 release, you can now open the Script Editor or the Admin Console at the end of the installation.

PowerPack Shared Scripts are now loaded from regular nodes and actions

When you author a PowerPack, you can create a function library inside a shared script for the PowerPack.  This is useful, however until now shared scripts would only load when you clicked on a script node or script action.  This has now been changed so that shared scripts are now loaded from regular nodes and actions, allowing you to keep all of your PowerPack functions in one location and then create regular nodes and actions using those functions.

Performance improvements, usability improvements and lots of bug fixes

In addition to these items, we have improved the performance in some scenarios in MobileShell and in the Script Editor, we have addressed some usability improvements in the Script Editor, the Admin Console and MobileShell, and we have fixed a lot of bugs as well (it is a beta cycle after all, and what good would a beta cycle be if it didn’t include bug fixes?).

Don’t forget all of the new features that were in the first beta!

Besides these changes, if you’re just finding out about the beta of PowerGUI Pro 3.0, make sure you read my other blog post that highlights all of the new features like compiling scripts into executables, or the new MobileShell user interface that allows you to use PowerPacks from your smartphone or tablet – those features and many more were included in the first beta of this release.  If you want to try the awesome new MobileShell capabilities, this blog post will help you get that set up in your test lab: Configuring RBAC for MobileShell in PowerGUI Pro 3.0.

Great, so where can I get beta 2?

Beta 2 is available for download now, in the same location where we posted the first beta.  You can find it on the PowerGUI Pro 3.0 beta page.  When you are installing this beta, you will need to provide a license key.  License keys for the beta are included in the zip file for the beta, right beside the msi and exe installers for the PowerGUI Pro 3.0 components – look for the asc file in the Components folder.

Please share your feedback!

We will be running the second beta for a short period while we work on finishing up this release.  Your feedback is very important during this beta cycle, so please give the beta release a try and share your feedback by posting messages on the PowerGUI forums.  The sooner we get your feedback, the sooner we can respond to it.  I’m really looking forward to hearing what you like, what you don’t like, and what else you would like to see in this and future releases, so please share your thoughts with us.

Enjoy!

Kirk out.

Step 1: Install the MobileShell Server

First, you need to find a system with IIS 7 or later installed.  Once you have a system where you will install the MobileShell server, you can run the PowerGUI ProMobileShell installer that was included in the beta package.  During that installation, make sure you indicate you will use https for your web site, because the new MobileShell user experience requires https in order for it to function properly. With the MobileShell server installation complete, you have a few configuration tasks that you need to perform to set up PowerPacks

Step 2: Add MobileShell Users to the PowerGUI MobileShell Users Local Group

Any user who will access MobileShell needs to be a member of the PowerGUI MobileShell Users local group.  The local group is created automatically by the MobileShell Server installer, so all you need to do is make sure you put the appropriate user accounts in to that local group so that they will have access to MobileShell.  Note that it may take several minutes before MobileShell checks the group again to see if there are new users in the group, so you may need to wait before newly added users can log in to MobileShell.

Step 3: Associate PowerPacks with AD Users and Groups

With your MobileShell users configured, you can now associate PowerPacks with different AD users and groups.  When a user logs on to MobileShell, they are presented with any PowerPacks that are associated with their user account or with any groups in which their user account is a member. MobileShell PowerPack configuration is done via a simple xml file.  The file does not exist by default, so you need to create it.  Invoke the following PowerShell script on your MobileShell server to create and open the configuration xml file:

$programDataPath = [Environment]::GetFolderPath('CommonApplicationData')
$powerGUIDataPath = 'Quest Software\PowerGUI Pro'
$folder = Join-Path -Path $programDataPath -ChildPath $powerGUIDataPath
if (-not (Test-Path -LiteralPath $folder)) {
    New-Item -ItemType Directory -Path $folder | Out-Null
}
$configPath = Join-Path -Path $folder -ChildPath 'MobileShellConfig.xml'
$configuration = @"
<?xml version="1.0" encoding="utf-8"?>
<Configuration>
  <Users>
    <User SID="S-1-5-21-123456789-0123456789-0123456789-01234">
      <Modules>
        <Module Path="$folder\ActiveDirectory.powerpack" Type="PowerPack" />
        <Module Path="$folder\Export Actions.powerpack" Type="PowerPack" />
        <Module Path="$folder\HTMLReporting.powerpack" Type="PowerPack" />
        <Module Path="$folder\Local.powerpack" Type="PowerPack" />
        <Module Path="$folder\Network.powerpack" Type="PowerPack" />
        <Module Path="$folder\VMware.VIToolkit.powerpack" Type="PowerPack" />
      </Modules>
    </User>
  </Users>
  <!-- <Groups>
    <Group SID="S-1-5-21-123456789-0123456789-0123456789-43210">
      <Modules>
        <Module Path="$folder\Network.powerpack" Type="PowerPack" />
        <Module Path="$folder\VMware.VIToolkit.powerpack" Type="PowerPack" />
      </Modules>
    </Group>
  </Groups> -->
</Configuration>
"@
$configuration | Out-File -FilePath $configPath -Encoding UTF8
notepad $configPath

Once you have the configuration file open, you will see the layout that is used to associate AD user or group SIDs with PowerPacks.  Copy all of the core PowerPacks that you have in the PowerPacks subfolder of your PowerGUI Pro installation folder that you want to use via the MobileShell UI into the same path where this file was created (the value of the $folder variable in the script above contains this path).  Then modify this file to contain only the PowerPacks you copied over, update the first User SID for your user account, and this will finish off the initial configuration of PowerPacks for MobileShell.  If you want to add additional users, you can copy and paste the User node in the XML document and then modify the SID for the users you add.  Retrieving a SID should be an easy task of course: simply use Get-QADUser from the Quest AD cmdlets!

Note: With this beta release there is a bug in the Groups support in this configuration document, so simply associate PowerPacks to users for now.  Thanks!

Step 4: Open the New MobileShell User Interface

The new MobileShell User Interface we have in the beta is accessed by opening your webkit-enabled web browser and pointing it to the following website:

https://MobileWebServerAddress/MobileShell/Admin

This web address allows you to try out the new systems management features that you can get from the PowerPacks you just associated with your user account.  Once you log in you should be all set to start using your PowerPacks!

A Note About MobileShell Support for PowerPacks

Note that if you try to use this new user interface with a PowerPack other than the ones that currently are included in the beta, by default the nodes and actions in those PowerPacks will not be visible in the MobileShell UI.  This must be explicitly turned on in PowerPacks that you want to access this way.  The reason behind this is because there may be some script that displays a Windows Forms or WPF-based UI on the system where they are run.  When you are remotely managing your environment via your MobileShell Server, you don’t want any UI to be displayed on the server because that would freeze your web client interface.  For this reason, nodes and actions must be explicitly configured to work with the new MobileShell UI.  I will write a separate post later about how you can do that really easily.  In the meantime, please try MobileShell with the core PowerPacks and see what you think! Hopefully this will help get you up and running with the new MobileShell UI in your test environment.  If you have any questions about this process, please let me know.

Thanks,

Kirk out.

MobileShell Now Supports PowerPack Rendering

A lot of our customers have been requesting this feature for a while (myself included!).  With PowerGUI Pro 3.0, you can now expose PowerPacks to MobileShell users!  An xml document is used to provide role-based access control (RBAC) to PowerGUI PowerPacks.  You simply associate PowerPack files with Active Directory users or groups, and when a user logs in they will see the PowerPacks that are configured for them!  Here’s a screenshot showing the top level of MobileShell, where you can see the PowerPacks that have been exposed to this user:

Just like in the Admin Console, you can browse through nodes and see child nodes:

Once you invoke a node that returns data, you can see the records showing up in the MobileShell PowerPack Rendering UI:

Clicking on any of these child nodes allows you to see more object detail if any is available as well as any actions that are available for the object:

This gives you full PowerPack support on your handheld device!  Devices supported include all iOS devices (iPhone, iPad), Android and BlackBerry 6.0 and later devices.  You can also use the Google Chrome or Apple Safari web browsers from your desktop.  If you don’t have a webkit-enabled web browser on your device or laptop, or if you want to invoke an ad-hoc command from your mobile device, you can still use the other MobileShell user experiences that we released in previous versions of PowerGUI Pro – they are still supported in PowerGUI Pro 3.0.

New Interactive Welcome Page in Script Editor and Admin Console

We have updated our Welcome Page that we have had all along in the Admin Console and we’ve made it available in the Script Editor as well.  This page now allows you to keep track of the latest PowerPacks or Add-ons on PowerGUI.org, monitor your favorite RSS feeds, see a featured video from the PowerShell and PowerGUI channel on YouTube, or read the latest tip of the day.

Create Executable Files from Scripts

Many customers have asked us for the ability to create executable files from scripts.  This is very useful, especially if you want to send someone the functionality you design in a script so that they can execute it without any difficulty.  PowerGUI Pro 3.0 includes this functionality, allowing you to build executable files that may be optionally password protected if they contain sensitive information.  You can also include any additional files that a script is dependent on as part of the package.  The only requirements for these executables are for PowerShell 2.0 itself to be installed and for the script requirements to be satisfied (if there are any).

Improved Version Control Integration

PowerGUI Pro has included Version Control support since its first release.  In PowerGUI Pro 3.0, we have improved this integration by providing a new Get Files from Version Control menu item in the Version Control menu to allow you to retrieve files from version control.  We have also simplified the check-in process so that you can disable the display of the check-in description dialog if it is not required by the version control provider.  This allows for a more streamlined check-in experience when working with Team Foundation Server.

Reset Runspace on Demand

As you create and modify scripts in the Script Editor, you are often changing the state of the PowerShell session, loading or unloading modules or snapins, or adding, removing or modifying functions or variables.  When this happens, it is a recommended practice to re-run your script from a clean state to make sure that something isn’t working simply because of the current state of your system.  Getting to a clean state in the PowerGUI Script Editor just got easier in PowerGUI Pro 3.0.  Now all you need to do is select Reset Runspace from the Debug menu and your functions, aliases and variables will be cleaned up and all of your modules and snapins will be unloaded and reloaded.

Go to Definition Support for Functions

As you work with PowerShell, the number of files containing commands you use can grow.  This commonly happens as users create multiple modules they manage or use modules they download from other sources.  In cases where you work with functions from different sources, you may want to go to a definition for a function to see how it is implemented.  In PowerGUI Pro 3.0, you can right-click on a function name in the Script Editor and go to the definition of that function by selecting Go to Definition from the context menu.

Find PowerPacks Online with Click-Once Install

You can now search for PowerPacks on the PowerGUI.org website right from within the PowerGUI Administrative Console.  Searching is done using keyword matches, and if you want to see all PowerPacks simply perform a search without entering any keywords.  Once you have found the PowerPack you want, select it and click on the Install button to download, unblock, install and import the PowerPack automatically.

Authoring Mode for the Administrative Console

If you know PowerShell, you may want all the capabilities that are available in the Administrative Console to be available to you so that you can customize it to meet your needs.  This allows you to create a tailored management experience for yourself or other users in your organization.  If you provide the Administrative Console with PowerPacks to other users in your organization, they may not know PowerShell, in which case you really don’t want them to change the configuration of the PowerPacks you give them.  The PowerGUI Administrative Console now has Authoring Mode for users who want to be able to modify PowerPacks, and basic (read-only) mode for users who shouldn’t be modifying PowerPacks.  Simply set the system up with the appropriate shortcut for the user who uses the Administrative Console and you won’t have to worry about them accidentally changing something anymore.

And that’s not all!

We also have a lot of other improvements in the product as well that were added as part of the PowerGUI Pro 3.0 release.  Here’s a list of a few more notable changes:

• Improved Action functionality in the Administrative Console;
• Automatic loading of required modules or snapins when a PowerPack is loaded;
• Automatic variables for $PGHome, $PGUICulture, $PGVersionTable and $PGSE;
• Multi-line command support for the embedded PowerShell Console; and
• For Add-on authors, $PGSE is now defined by default and name lookups of UI elements is now case-insensitive

There are other fixes as well, but this short list gives you an idea of some of the other things that are included in this release.  Each of these improvements were suggested by various members of our community, so please keep the feedback coming, we’re really listening!

This sounds great!  Where can I get the beta?

You can download the public beta of PowerGUI Pro 3.0 right now by clicking on the Download button on the PowerGUI Pro 3.0 Public Beta page on PowerGUI.org.  That page also describes what the beta package contains as well.  PowerGUI Pro can be installed side-by-side with PowerGUI freeware, so if you are a freeware user and want to try this out, you can install the beta without disrupting anything you do with the freeware product.

Provide your feedback on the PowerGUI forums!

We will be running this beta for a short period while we work on finishing up this release.  Your feedback is very important during this beta cycle, so please give the beta release a try and share your feedback by posting messages on the PowerGUI forums.  The sooner we get your feedback, the sooner we can respond to it.  I’m really looking forward to hearing what you like, what you don’t like, and what else you would like to see in this and future releases, so please share your thoughts with us.

That about wraps it up for this post, so if you made it here, thank you for reading this far and please, give PowerGUI Pro 3.0 Beta a try to see what you think about it!

Happy testing!

Kirk out.

If you’re wondering where else I’ll be, be sure to take a look at my blog post about PowerShell at TechEd 2011.  It includes sessions I will be possibly attending.  I’m also presenting an interactive session called WSV-473: Windows PowerShell 3.0: Why Wait? Get Next-Generation PowerShell Functionality Today!  If you cannot attend that session, there is a repeat as well: WSV473-INT-R: Windows PowerShell 3.0: Why Wait? Get Next-Generation PowerShell Functionality Today!

Also, why not go to TechEd in style!  Show your appreciation for PowerGUI at TechEd by sporting the latest PowerGUI desktop wallpaper on your laptop!

Hope to see you there!

Kirk out.

PowerShell content at TechEd 2011

Below you will find a list of all of the PowerShell-related sessions and resources for TechEd so that you can make sure you have them added to your schedule.  The sessions that interest me the most are highlighted in bold.

Quest Software Ask the Experts Session on PowerShell

There are other items that won’t show up in the schedule builder as well. For example, Quest Software has regular Ask the Experts sessions throughout the event, and one of those sessions will be focused on PowerShell, allowing you to ask questions to myself and Dmitry Sotnikov, watch some demos of the next version of PowerGUI® Pro, and have a chance to meet us at the event.  If this interests you, mark your calendar and join Dmitry and I in the Quest Software booth in the expo hall on Tuesday, May 17 from 12:30PM to 1:00PM, and bring your PowerShell and PowerGUI Pro questions!

WSV473-INT Windows PowerShell 3.0: Why Wait? Get Next-Generation PowerShell Functionality Today!

If you want to find me when I’m not working the PowerShell booth or answering questions during the Ask the Experts session on PowerShell, you can always come catch me at my session.  It is included in the session listing above.  I will be presenting a 400-level interactive discussion about PowerShell, WSV473-INT Windows PowerShell 3.0: Why Wait? Get Next-Generation PowerShell Functionality Today!  During this session I’ll be discussing different ways that you can get next-generation PowerShell functionality today so that you don’t have to wait as long until the next release.  This session will cover cool PowerShell features such as proxy functions, and it will also discuss Domain Specific Vocabularies, a topic I recently spoke about at the PowerShell Deep Dive.  You can read more about the session here.

Important Update:

This session has been scheduled for a second showing on Thursday, May 19, 2011 from 1:00-2:15PM, so if you can’t make the first one, come to the second!  Here’s the link to the update: WSV473-INT-R | Windows PowerShell 3.0: Why Wait? Get Next-Generation PowerShell Functionality Today!

Watch for additional opportunities to learn about PowerShell

Beyond these sessions, there are always other possible opportunities to learn about PowerShell while you are at TechEd 2011 in Atlanta.  The scheduled sessions at TechEd offer a ton of value already, but for me, the true value of a conference like TechEd comes from the unexpected and often unplanned side discussions that surprise you at a conference like this.  Some of my favorite discussions about PowerShell at conferences in the past have happened in an ad-hoc meeting, over breakfast, or in the PowerShell booth.  Never be afraid to start the discussion and ask others if they use PowerShell, and if possible keep your laptop handy so that you can pull it out and talk shop on the spot.  There is huge value in those discussions, and I highly recommend them.

That’s it from me for now.  If I hear about additional opportunities to learn more about PowerShell while at TechEd I’ll be sure to post them here.

Thanks for listening!

Kirk out.

Show your Earth Day pride, and download this beautiful desktop wallpaper today! If it doesn’t suit your style, check out the rest of the desktop wallpaper images we have in the Wallpaper category on PowerGUI.org.  There are plenty to choose from!

Kirk out.

Today marks the beginning of Microsoft’s 2011 Scripting Games.  The Scripting Games are a great way to have fun learning more about Windows PowerShell.  There are even great prizes available to be won.  There are 10 events, with a beginner and an advanced category for each event.

To participate, all you have to do is:

1. Familiarize yourself with the information on the 2011 Scripting Games page.
2. Register by signing in to the 2011 Scripting Games page on PoshCode.org.
3. Keep your eye on the Hey, Scripting Guy! blog to see when new events are posted (both the beginner and advanced Event 1 details are available now!).
4. Publish solutions to any events you decide to do on the PoshCode.org contribute page.

That’s pretty much all there is to it.  You can participate in both the beginner and the advanced categories, or you can spend all of your time focused on one category.  You can enter solutions for all events in a category, or you can cherry pick the events you have time for and enter only those.  You can start today with the first event, or join in later once the competition is already underway.  There are really no limitations on how much or how little that you have to participate in the Scripting Games.  Some prizes are available for the highest ranking participant, but others can be won simply by participating in a single event, so throw your hat into the ring and learn more about PowerShell while having fun and you might even win something.

Quest Software is an official sponsor of the Scripting Games again this year, and we have contributed many licenses of PowerGUI® Pro to the pool of prizes to be won.  If you’d like a chance to win one of the licenses that are available, all you have to do is participate in the Scripting Games by entering at least one event.  The more events you participate in the more you will increase your chances of winning.  Participating is easy, so you really should consider taking the time to give it a try…you just might learn something.

Good luck!

Kirk out.

It’s hard to believe it’s been 4 years already since PowerGUI was first made available for download on March 28, 2007.  What an amazing 4 years it has been too! What started out as a free extensible Administrative Console based on Windows PowerShell has grown into an award winning product that also includes a free extensible Script Editor with tons of useful features like Intellisense, syntax highlighting, script snippets, script signing, and many, many more.  There’s even a Pro version called PowerGUI® Pro that adds Version Control, Easy Remote Script Execution, and a component called MobileShell that allows you to perform systems management from your handheld device!

It’s been great fun having a direct hand in helping make this happen, but this product would not be what it is today without the support that we have received from the community!  Your feedback and support through our PowerGUI.org community site, on Twitter, on FaceBook, and blogs and articles around the web has been fantastic and it’s something that I appreciate every single day!  Thank you for helping this product to continue to grow!

I hope you enjoy celebrating PowerGUI’s birthday with us this week with the fantastic wallpaper, and look forward to continuing to watch this product grow for many years to come!

Enjoy!

Kirk out.

Enjoy!

Kirk out.

To download this wallpaper, simply visit the PowerGUI downloads page and scroll down to see all of the sizes and varieties that are available.  We have Fall wallpaper there as well for our friends in the southern hemisphere.  As always, all of our wallpaper images are stored in the Wallpaper folder on PowerGUI.org, so if you want to use one from a previous year or a different season or holiday, take a look around…there are currently 27 different varieties to choose from.

Enjoy!

Kirk out.

This podcast is a great source of PowerShell news and I highly recommend listening to it regularly.  It’s a great way to pass the time during your daily commute to and from work.  There are 141 episodes so far, with tons of great interviews and content, so check out this podcast when you have some time.  It’s definitely worth it.

Enjoy!

Kirk out.

As usual, it comes in two different flavors: one with the freeware train and one with the PowerGUI Pro train.  Each screenshot has 8 different resolutions available, so pick whichever one suits you best.  I already have the PowerGUI Pro version installed on my laptop.

Enjoy!

Kirk out.

P.S. I can’t help but wonder what the little PowerGUI train had to drink that made gold bubbles come out of his smokestack.

Don’t be too intimidated by the name “Deep Dive” though.  The sessions will be a deep dive into PowerShell, that’s true, but there is a half-day 300-level Windows PowerShell Pre-Deep Dive Crash Course with Don Jones on April 17, 2011 that can help bring you up to speed if you’re close but not quite there yet.

Also, if you act now by emailing TEC2011@quest.com and sign up before the end of March, your Deep Dive conference fee will only cost you $850 US.  For the depth of knowledge covered and the calibre of the presentations and the attendees who will be attending, this conference is going to be worth every penny.

Speaking of attendees, you really should check out who’s already confirmed they will be attending this event.  Here’s a list of only a few of the speakers and attendees who have signed up so far:

• Jeffrey Snover – the father of PowerShell and Lead Architect for Windows Server
• Travis Jones – Program Manager on the PowerShell Team at Microsoft
• June Blender – Lead Tech Writer on the PowerShell Team at Microsoft
• Jim Truher – co-creator of PowerShell 1.0 at Microsoft
• Ed Wilson – the Scripting Guy at Microsoft and author
• Roberto Farah – Senior Premier Field Engineer at Microsoft, author of PowerDbg
• Andy Schneider – PowerShell blogger
• Glenn Sizemore – PowerShell blogger and author
• Dmitry Sotnikov – the father of PowerGUI and PowerShell MVP
• Adam Driscoll – the creator of PowerGUI VSX
• Don Jones – PowerShell MVP and author
• Jeffery Hicks – PowerShell MVP and author
• Richard Siddaway – PowerShell MVP and author
• Sean Kearney – PowerShell MVP
• Brandon Shell – PowerShell MVP

What’s incredible is that this list is only showing some of the amazing talent that will be at this event.  I would have recommended it as a must-attend event even with only a small fraction of the superstars I have listed above attending, but with this line-up, plus many, many more PowerShell superstars, this is going to be one truly memorable experience.

I’ll be attending as well of course (I wouldn’t miss it!), and while there I will be presenting a full session on “Managing Hyper-V with PowerShell” and a Deep Dive talk on “Defining domain specific vocabularies using Windows PowerShell” as well.

Have I sold you on the idea yet?  If you want to learn more, head on over to the PowerShell Deep Dive page and read more about the event, or if you’ve already decided send an email to TEC2011@quest.com today to make sure you can take advantage of the $850 US pricing before the end of March!

Hope to see you in Vegas!

Kirk out.

While at the Summit I was meeting with some PowerShell MVPs, chatting about PowerGUI and PowerGUI Pro, and getting feedback on the two products (and taking a lot of notes!).  Claus Nielsen, a fellow PowerShell MVP from Denmark was sharing some of his ideas with me and one feature he requested was scroll buttons for our tabbed document interface to allow you to scroll the view to other tabs.  This is useful when you have many tabs open and you want to reorganize them or just scroll through the ones you have open.

I get a lot of requests from the online community as well, some of which come via twitter.  These don’t necessarily come from MVPs, although the one I’m about to use as an example does.  Brian H. Madsen (@csharpzealot) tweeted about having issues when running PowerGUI and not realizing he was in the 32-bit version of the console on a 64-bit machine.  Since you can run PowerGUI in 32-bit or 64-bit, elevated or not, it can be very useful to know how you opened it when you are working with the product.

Other feedback comes in the form of direct email.  One of our internal support reps was trying to figure out how to tell what encoding was used when saving a ps1 file because he was working with another product that didn’t seem to support that encoding.

A lot of this feedback turns into enhancement requests for the core product, but there are also many ideas that turn into features I can quickly implement in an Add-on.  All of the ideas I just mentioned in this post fall into the latter case, and between early mornings in my hotel room in Bellevue last week and a little time yesterday afternoon, I have finished implementing these (and more) in version 2.0 of the PowerGUI Script Editor Essentials Add-on.  This Add-on is definitely one of my favorites, right up there with the Blue Console Add-on and the Script Signing Add-on.  It comes with an indispensible feature set and whenever I install PowerGUI on a new system I immediately notice that it is missing and have to install it right away.

PowerGUI Script Editor Essentials 2.0 includes the following enhancements:

• You can now view and change the current file encoding by using the File | Encoding submenu.  The menu items in this submenu will automatically save the current file and the checked item indicates the current encoding for the current file.
• You can now use scroll buttons to view all of the tabs that you have open.  These scroll buttons are enabled by default, but you can always hide them or bring them back by using the View | Tab Scroll Buttons menu item.
• You can now see more useful status information in the status bar.  This includes:
• the current file encoding for saved files;
• the current process architecture (64-bit or 32-bit) for 64-bit machines; and
• the current elevation status if you are running PowerGUI in an elevated process.
Here’s a screenshot showing you what the Script Editor looks like in an elevated process on a 64-bit system once you have this Add-on loaded:

I also fixed an issue preventing the shortcuts in this Add-on from working on some non-English operating systems, and I added icons that were missing for the Increase Indent and Decrease Indent menu items so that they show up as regular buttons if you add them to your toolbar.

These features are in addition to the features that came in the first version of this Add-on, which include support for :

• enabling Word Wrap in your documents;
• showing Whitespace in your documents;
• using Virtual Whitespace when editing documents;
• Zoom in and Zoom out while working with a document;
• opening multiple files at once from the File | Open dialog; and
• filtering for *.ps1xml, *.psc1, *.xml and *.txt files in the File | Open dialog.

You can see screenshots showing these features on the Script Editor Essentials Add-on page.

If you’d like to try this Add-on, follow these three steps:

1. Open the PowerGUI Script Editor and select Tools | Find Add-ons Online… in the menu.

2. In the dialog that appears, enter “Script Editor Essentials” into the text box and click on the Search button.

3. Once the Script Editor Essentials Add-on shows up in the results, click on the Add-on to select it and then click on the Install button to install the Add-on. This will download, unblock, install and load the Add-on in your Script Editor, and you’ll have these features in your favorite Script Editor in no time!

If you’re not connected to the web, you can also install this manually by following the steps outlined on the Script Editor Essentials Add-on page on PowerGUI.org.

Now that this update is released, what else do you think qualifies as a Script Editor Essential feature?  As you can see, community feedback drives what we do, so please share your ideas!  We are listening.

Kirk out.