During the Hacktoberfest challenge over the past few years, if you wanted to do this with PowerShell-based projects it was more difficult. You would have had to find someone who had open source PowerShell modules or scripts that you could participate in, or you could even use your own projects when the Hacktoberfest challenge was just about commits to open source repositories, but it has evolved since then and now it’s all about submitting pull requests to other repositories so you need to start playing nice with other people’s projects. It’s much easier now though, because PowerShell Core is open source, the PowerShellGet and Package Management modules just went open source, much of the documentation is open source, there are other PowerShell modules that are already open source, and more modules are going open source every day. There’s even an open source PowerShell module for DigitalOcean automation (ok, shameless plug, I wrote that one). Also, it doesn’t matter if you’re a developer, a devops engineer, a module author, a casual scripter, a PowerShell user who wants to improve documentation, or a PowerShell community member who has an idea for an RFC that would help improve the language — all of these roles have opportunities for pull requests to be submitted to help make PowerShell better for everyone. Do you know how easy it is to submit a pull request for a PowerShell docs change? Brain. Dead. Simple.

Since PowerShell has so much open source goodness now, this year lets make some noise by raising the visibility of PowerShell open source projects, and show the DigitalOcean Hacktoberfest challenge what the PowerShell community can do! According to the Octoverse, Microsoft has already demonstrated themselves as the organization with the most contributors to open source projects. Let’s take that a step further, and raise the bar by submitting a ton of pull requests against PowerShell projects this month! If you’re up for the challenge, aside from a really cool t-shirt and great stickers for your laptop, you’ll also get the pride of having contributed to something truly great!

Want to get started?  Head on over to the Hacktoberfest site and click on the Start Hacking link to sign up. There are also a lot of great resources on that site if you haven’t done open source pull requests before — just scroll down to the bottom of the page. Then, throughout the month of #Hacktober, spend some time contributing to one of the many great open source PowerShell projects. Note that this isn’t limited to specific pull requests for issues tagged with #Hacktoberfest — any pull request will do.

Then, if you happen to be attending the IT/Dev Connections 2016 conference, consider coming to my Anatomy of a PowerShell Pull Request session where I’ll be talking a lot more about a lot of this kind of thing. And at any time, if your stuck, tap myself or any of the other members of the PowerShell community that are plugged into this open source movement via Twitter, or on the PowerShell Slack channel (you can sign up for that here) and ask for help! Lastly, if you’re a PowerShell open source project owner, consider tagging issues you really want people to look at in #Hacktober with the #Hacktoberfest tag so that they get more attention during this challenge (this isn’t a requirement — it is merely a facility to help community members discover issues they could submit a pull request for).

To keep visibility high and encourage others to participate, as you submit pull requests consider sending out a tweet about them with the #PowerShell and #Hacktober hashtags along with a link to this post so that others can discover the challenge as well!

Are you with me? Let’s make #Hacktober a milestone month for PowerShell open source project pull requests!

Kirk out.

As part of the many improvements and updates that Microsoft has been working on for Windows 10 and PowerShell 5, they created a new module that is very important for the PowerShell ecosystem to take note of.  It’s so important, that you need to pay attention to it even if you’re not using PowerShell 5 much yet.

PowerShell Script Analyzer (PSScriptAnalyzer) is a module whose intent is to provide a detailed analysis of PowerShell script and module files.  This includes ps1, psm1, and psd1 files.  In computer programming, this is referred to as a linting tool.  A linting tool is simply a piece of software that identifies and flags suspicious usage of the software that is identified through static analysis of the source code.  PowerShell Script Analyzer performs this task by analyzing whatever ps1, psm1, and psd1 files you tell it to and using a set of built-in and user-defined rules that each identify specific undesirable or suspicious usage of the PowerShell language in those files.

This module is very important because any module that is published to the PowerShell Gallery in the future will automatically be analyzed with this module.

When PowerShell Script Analyzer was originally exposed to the community, it was as a built-in module that ships with PowerShell 5.0.  That was useful, however the PowerShell Script Analyzer team wanted to get more community involvement with this module.  To achieve that goal, they pulled the module from the April preview of PowerShell 5.0 and made it available as open source on GitHub instead (hooray for open source!).  That was a step in the right direction, but it still required PowerShell 5.0 to function, and if you’re anything like me, you still spend most of your time in PowerShell 3.0 or 4.0.  Since it’s open source though, that opens up some new possibilities, so recently I forked the project on GitHub and added downlevel support for PowerShell 3.0 or later.  I have a pull request to have this integrated into the main project that is currently being reviewed, so hopefully in a little while this PowerShell 3.0 support will be integrated into the main project and available on the PowerShell Gallery.  In the meantime you can find my fork here, and you can download the module built from that fork here: PSScriptAnalyzer for PowerShell 3.0 and later.  Now that this module includes support for PowerShell 3.0 or later, more community members can participate and provide feedback on this important module.

You should immediately start using the PSScriptAnalyzer module to perform static analysis of anything that you share with the community so that what you publish is clean.

Once you have this module on your system, you probably want to know how to use it.  This module currently includes two PowerShell cmdlets: Get-ScriptAnalyzerRule and Invoke-ScriptAnalyzer.  Get-ScriptAnalyzerRule will return a list of the rules that are in use by Script Analyzer to perform its analysis of your script files.  At this time there are 7 informational rules, 26 warning rules, and 4 error rules.  Invoke-ScriptAnalyzer will analyze one or more files that you identify using the rules that are in use by Script Analyzer, notifying you of any infractions to those rules so that you may correct them.

The final list of rules that are used in the RTM release of PSScriptAnalyzer will be decided upon based on community feedback.  Additionally, how those rules function is dependent on community feedback, and the list of rules that will ultimately block a module from being published to the PowerShell Gallery will also be chosen based on community feedback.

You should provide feedback to the PSScriptAnalyzer team about the rules that it uses, identifying bugs of course, but also identifying rules that shouldn’t be rules, rules that are missing, rules that have an incorrect severity, and any other changes that should be considered regarding the rules that are used.

If you have feedback to share, you should do so on the Issues and Discussions page of the PowerShell Script Analyzer project.  If you haven’t clicked on that link already, do so now.  You’ll see that there are a lot of discussions that are currently ongoing, and issues that are already being raised.  Given the importance of this module for the PowerShell community, if you have feedback to share, share it!  The PowerShell Script Analyzer team needs it.

The PowerShell Script Analyzer team is so eager to engage with the community that they have even started hosting live update meetings to the public.  These are currently planned for every three weeks, but that schedule may change as required.  The next meeting is currently scheduled for Tuesday, May 26th at 2PM EDT (link to calendar invite).  It would also be worthwhile to keep an eye on the Twitter accounts of PowerShell MVPs (you can find me here: @poshoholic) as well as on the PowerShell Team Blog and the PowerShell Slack channel (more on that in another post) for further announcements about these meetings.

With all of those details out of the way, you may be wondering how you can use this module.  That’s a good question, because documentation hasn’t been published for this module yet.  The module is very easy to use, but at first the information it provides can be very overwhelming so you should take small steps when you’re just getting started.  I’m going to use the remainder of this blog post to walk through what it is like using this module.  Don’t be intimidated.  This module is still under development, and the details you uncover when you start using it can be a little daunting.  If you’re having a hard time, reach out to the rest of the community for feedback and someone should be able to help you through it.

Remember, this module will be analyzing files that have not previously been analyzed, ever, identifying places where you might want to improve those scripts, so at first it may seem very noisy.  Also keep in mind that some of the things it identifies are completely benign – this is where community feedback comes in, so that we can help steer the team towards a final set of rules that really makes sense.

As an example, I’m going to use PSScriptAnalyzer to analyze my HistoryPx module.  First, I’ll change the current location to the root of my HistoryPx module (On my system I simply cd into Modules:\HistoryPx).  Then once I’ve done that, I’ll run an analysis on the psm1 file, by invoking the following command:

Invoke-ScriptAnalyzer -Path .\HistoryPx.psm1

Here’s what the results of that command look like:

This shows me that according to PSScriptAnalyzer, I have 8 rules that are being broken, and each of these rules has a severity of warning.  Now that I have some output, I need to review what it is telling me to see if I have anything that I actually need to change.  Here’s a breakdown of what these rules are trying to tell me:

The first two warnings are based on a rule that is called PSAvoidGlobalVars.  That rule simply indicates that you shouldn’t use global variables.  In HistoryPx, I refer to the $Error variable, and I use $global:Error to do so.  In this case, the warnings are benign, because the rule is too strict.  It should actually check to see if I am using non-builtin global variables, not global variables in general.  That is my opinion at least, and since it doesn’t do that right now, I’m going to open an issue with the PSScriptAnalyzer team on GitHub using the link I provided earlier (copied here).  A quick search revealed no open issues related to PSAvoidGlobalVars, so I opened one (here).

While typing the rest of this blog post, the PSScriptAnalyzer saw the issue I logged and responded thanking me for reporting it and indicating they would fix it soon.  This type of responsiveness makes supporting them and contributing to this module an absolute pleasure!

The third warning comes from a rule called PSAvoidUsingPositionalParameters.  When you share scripts, using positional parameters is discouraged because the person reading your script may not know what parameter is being used.  To address this problem, you should always use named parameters in your scripts.  PSScriptAnalyzer did its job by identifying where I had left out a positional parameter, so I need to fix that.  The warning indicates which file and what line number were being analyzed when the warning was found, so I simply open up HistoryPx.psm1, make the change by adding the missing “-Message” named parameter, and then move on to the next warning.

Warning number 4 indicates that I shouldn’t use the trap statement.  I use the trap statement in script modules I write because it ensures that terminating errors are properly treated as terminating errors if they are raised while the module is loading, which ensures that the module does not load in a semi-functional or broken state.  Therefore, this warning is benign for me and another issue I need to open with the PSScriptAnalyzer project (which I did, here).

Note: if you do come across something where you feel you need to open an issue, search the Issue page using the Filter box for the rule name and see if the issue has already been posted first.  If so, contribute by adding any comments you want to share to that issue rather than opening a new issue.  That will help the PSScriptAnalyzer team decide what to do with these issues once they are opened.

Moving along, warnings 5 through 7 all come from the PSAvoidUninitializedVariable rule, which identifies that I haven’t initialized a few variables before using them in my psm1 file.  However, that rule only identifies when variables are initialized in the same file – it does not identify when variables are initialized elsewhere, and in this case, as with all of my modules, I initialize these variables in a snippet that this module uses, so the warning is benign.  For these warnings, I can open another issue about the rule, but I’m a bit of an exception in this case.  Alternatively I can suppress the warnings if they are truly benign and not considered a bug by adding a System.Diagnostics.CodeAnalysis.SuppressMessageAttribute to my script module file.  For example, if I add this to the top of my psm1 file, warnings 5 through 7 go away:

[Diagnostics.CodeAnalysis.SuppressMessageAttribute(‘PSAvoidUninitializedVariable’, ”)]
param()

This suppresses that rule in the current file for all variables.  I can suppress it for a single variable by replacing the empty single quotes with a variable name in single quotes, but that only suppresses the rule for one variable.  From what I can tell there is no way for me to suppress the rule for multiple variables (wildcards are not supported, and if I use multiple attributes, the last one I use wins).  There are some obvious bugs/design issues with this right now, but the point is, you should be able to suppress rules that you know you can safely ignore.

Be careful when you suppress rules.  If you suppress a rule, you want to suppress it in a minimalistic fashion, so that you still get the benefit of that rule in other places.

In this case, I’m not sure what the right action is, but the rule itself has issues, so I decided to open up an issue as a discussion topic on GitHub (here).

If you feel something is wrong but you don’t have a bug to log, opening a discussion on the Issue page is a great approach to take.

With that out of the way, I’m on to the last warning that was raised for my HistoryPx module: PSUseDeclaredVarsMoreThanAssignments.  This warning is nothing but confusing for me.  It is being raised because PowerShell Script Analyzer thinks I’m doing something wrong when I assign a script block to a property on a variable that it thinks is not initialized.  That would be wrong if the variable was actually not initialized, but the warning in this case seems simply like a bug, so I’m logging it (here).

At this point, I have passed through all the warnings generated by the analysis, made one change to correct one of them, and started logging some issues to deal with the others.  As development continues on PSScriptAnalyzer, this scale should tip dramatically to the point where you have more correctible warnings/errors for your scripts and much fewer issues to log.  For now though, it is a work in progress, but I suspect that over the next little while you’ll see a lot of improvements to address the issues that are being identified in the community.

With one file done, I can now check another file, or run analysis recursively over my entire module.  To perform recursive analysis, you would run this command from your module root folder:

Invoke-ScriptAnalyzer -Path . -Recurse

That will recursively analyze all files in your module so that you can get a high level view of everything that needs to be corrected.  The goal here is simple: continually fix the issues over time so that when you run this command recursively, you only see new issues that pop up (or ideally, no issues at all).  That will be the best way for you to maintain a high quality for any modules and scripts that you want to share with the community.

There are more things you can do with this module (such as create your own rules), but for now I just wanted to give you a taste of what it is like, and how the feedback process works so that you can start giving it a try and participating in the community effort to steer this in the right direction.

I hope to see you at the PowerShell Script Analyzer Community Meeting next Tuesday!

Kirk out.

For all of its strengths, Windows PowerShell is not without its fair share of weaknesses.  One of the weaknesses in PowerShell that has been with the scripting language since version 1.0 is how it handles formatting.  When it comes to formatting data, you have two options: use one of the core Format-* cmdlets (Format-Table, Format-List, Format-Wide, or Format-Custom), or create a format ps1xml file that defines one or more formats for a specific type in an XML document.  The former only works for the script consumer, because the core Format-* cmdlets actually convert rich object data into format data, not bearing any resemblance to the original objects with properties and methods that you started with.  The latter works for the script author as well as the script consumer, however it is significantly more complicated to implement, and it has its share of limitations as well (for example, once a default format is defined for a type, a script author will not be able to have the results of their script rendered in another format by default without taking some extra steps that shouldn’t be necessary).  The end result of these limitations and complications is a formatting system that is not fully leveraged in the majority of PowerShell scripts that are shared among the community.

I recently found myself looking at this problem and asking myself one more time if I could do better (it is a problem that I had looked at in the past).  The variety of formats that are available is encouraging, and you can generate some pretty useful report-like output when you take the time to leverage the formatting system.  But something would have to be done to fix the user experience.  The end goal I was envisioning was quite clear: a distinct separation of the presentation layer from the data processing layer such that formatting information would never get in the way of data processing.

Fortunately, PowerShell is quite well set up for this type of change.  Every command that you run has its results sent through the Out-Default cmdlet.  Out-Default internally knows what to do with whatever you throw at it, whether that be object data or format data (which really is object data as well, but I’m making a distinction here).  When you return an object from a command to the console, if that object is not format data, Out-Default internally will look at the object type, identify the default format for that type, convert the object into format data and then output that format data to the console.  If Out-Default does receive format data instead because the object was already converted into format data, it simply renders that format data in the console.  Given that is the case, it should be possible to modify the core Format-* cmdlets so that they attach format data to the objects that they format instead of converting object data into format data, and it should also be possible to modify the core Out-Default cmdlet so that it detects format data when it is attached to an object and renders that format data directly to the console instead of looking at the object type to decide what format to use.  That, my friends, is exactly what I did.

FormatPx is a module made up of a nested binary module that defines five proxy cmdlets (Format-Table, Format-List, Format-Wide, Format-Custom, and Out-Default) plus one new cmdlet (Format-Default) and a script module that automatically applies the Force parameter whenever Format-Table, Format-List, or Format-Wide are used.  It changes how the core Format-* cmdlets work as described above, and it also makes it easier to get format information from types that include a custom format as their default.  Here’s a short screencast showing FormatPx in action:

(Note, do not adjust your computer, there is no audio in this screencast.)

That’s a decent overview of what you get with the FormatPx module – a separation of the formatting layer from the data processing layer, giving you much more control over the presentation of your script results without ps1xml file complexity while still allowing script consumers to view the results in whatever format they like.  What do you think?

Kirk out.

So far, eight years into using PowerShell, this is my favorite PowerShell one-liner:

At first glance, can you tell what this does?  Take a minute to think about it, I’ll wait.

Ok, now that you’ve thought about it a bit, you might have realized that it is not that easy to figure out everything that this does, so let me break it down into parts.

gci –r -force

If your familiar with PowerShell, this part is pretty straightforward.  gci is an alias for Get-ChildItem, and this command tells PowerShell to get a recursive (-r) directory listing of all files and folders, including any hidden files or folders (-force), starting from the current location.

measure -sum PSIsContainer,Length -ea 0

measure is an alias for Measure-Object, a cmdlet that can perform calculations on a collection of objects that it is passed from a pipeline.  In this case, we’re going to aggregate (-sum) two values from properties in this collection: PSIsContainer and Length. We’re also going to hide any errors we get from trying to access folders that we don’t have access to (-ea 0).  How Measure-Object measures the objects it receives is the most interesting part of this pipeline.

You can probably guess why we would want to calculate the sum of the Length property, but why would you want to calculate the sum of the PSIsContainer property?  PSContainer is a boolean value that indicates whether or not an item returned from Get-ChildItem is a container.  A value of $true indicates it is a folder, and a value of $false indicates it is a file.  When you calculate the sum of a bunch of boolean values in PowerShell, PowerShell first converts those boolean values into their integer equivalent.  $false implictly converts into a value of 0, and $true implicitly converts into a value of 1.  Given this is the case, by aggregating the PSIsContainer property, you’re effectively calculating a sum of the number of containers in the result set.

$di,$fi =

PowerShell allows you to assign a multi-valued result set to different variables by separating the variables with a comma.  In such an assignment, the first object returned will be assigned to the first variable, the second assigned to the second variable, and so on until the last variable which will contain all remaining objects.  In this case, we’re assigning two variables, and each will contain a single value.  Since we’re aggregating two properties (PSIsContainer and Length), Measure-Object will return two objects containing measurement information: one for PSIsContainer and one for Length.  The measurement information for PSIsContainer will be assigned to $di and the measurement information for Length will be assigned to $fi.

Also, in addition to calculating the aggregate for the two properties, Measure-Object also counts the number of objects that it processes to perform that calculation and includes that count in the result as well.  In cases where an object does not have a property that is being measured, that object will not be included in the count, so folders, which do not have a Length property, will not influence the values returned in the second measurement information object that is assigned to $fi.

Putting it all together

When I run the aforementioned one-liner on my PowerShell folder, here are the values I get from $di and $fi, respectively:

Count    : 6516
Average  :
Sum      : 2012
Maximum  :
Minimum  :
Property : PSIsContainer

Count    : 4504
Average  :
Sum      : 917710488
Maximum  :
Minimum  :
Property : Length

For the $di object, the Sum property identifies how many directories were found in the search.  This was determined by aggregating the integer value of the PSIsContainer property on the objects that were measured.  The Count property identifies how many items altogether were processed (directories and files, both of which have a PSIsContainer property).

For the $fi object, the Sum property identifies the total size of all files that were found in the search, and the Count property identifies how many files were found in the search.

Put this all together, and you have a PowerShell one-liner that gives you folder stats, identifying the number of files and folders in a folder as well as the total size of all files in that folder.  Neat, huh?  I think the reason why I like this PowerShell one-liner the most is because it demonstrates how a little creativity can be applied to get useful information that is not available in a native cmdlet from several sources in a simple and elegant manner.

What’s your favorite one-liner, and why?

Maybe I should start a meme with this.  Jeffrey Hicks, Shay Levy, Ed Wilson, June Blender, and Hal Rottenberg, tag, you’re it!

Kirk out.

The links in the table above will take you to blog posts that provide some more context about what these modules do.  If you’d like to raise your PowerShell game by using some cool new functionality in PowerShell 3.0 or later today, please give these modules a try and let me know what you think!

Happy Halloween!

Kirk out.

While I don’t believe that is true (I actually find history quite fascinating), it is certainly how I would have responded if asked about history while taking it in high school.  I’m not the only one who felt this way back then either.  When I asked my wife for her opinion about it, she told me that it was in her history class where she learned to write upside down with her non-dominant hand.

My problem with history is the presentation of it.  It can be fun and include a lot of contextual detail that is presented with zeal and that connects with the audience; or, like my high school history class, it can be presented as a timeline with boring details attached to it.

PowerShell automatically tracks the commands that you invoke in a history table that you can view at any time with the Get-History cmdlet.  If you invoke Get-History (or its alias, h) after you’ve been using PowerShell for a bit, you should see results similar to the following:

That’s not entirely useless, because it shows commands that we ran earlier, but as far as presentation goes it’s pretty boring, right?  Now, this is only the default format for history in PowerShell, and as with most data in PowerShell this screenshot doesn’t paint the full picture.  Each entry also includes other fields that are not shown in the default format, as can be seen here:

The problem is, that’s all you get: a timeline with boring details attached to it.  The ExecutionStatus property tells me whether a command completed or failed, but the usefulness of that information is very limited because a value of Failed only means the command failed with a terminating error; if a command failed with a non-terminating error, then ExecutionStatus will simply indicate that the command completed, which is not very useful knowledge to have.  Start and end execution times are useful, but that means I need to do math to determine how long various commands took, or re-run the commands inside of Measure-Command.  There’s no zeal behind the presentation of this information.

Fortunately, PowerShell is extensible, so I decided I should be able to do better.  Here’s my view of what PowerShell history should be, as provided by HistoryPx:

HistoryPx is an open-source PowerShell module that transparently integrates into the PowerShell environment where it is loaded.  You simply load the module by importing it with Import-Module into an environment running PowerShell 3.0 or later, and once it is loaded it will start tracking extended history information for every command you run.  Extended history information includes the command duration, whether or not the command was successful, any output returned by the command, and any errors that were added to the $error log by the command.  When you invoke Get-History, the new default format for extended history information presents most of these details, or you can pipe the results to Format-List * to get all properties where you can see the core history properties as well as the extended information added by HistoryPx.

In addition to providing extended history information in PowerShell, the HistoryPx module includes one other feature that is quite useful.  It defines a double-underscore ($__) variable in the global scope that will always contain the output of the last command that was executed.  When the last command doesn’t have any output, $__ will be assigned a value of $null.  This comes in handy when you invoke a command that takes time to complete but forget to capture the results in a variable.

If you want to give this module a try, head on over to the HistoryPx page on GitHub where you can learn how to install or update it in your environment and read additional details provided in the readme file on GitHub.  If you are concerned about memory usage with this module, your questions are addressed in the readme as well.  This is only the first release of this module, and I am already starting to track features that I want to add to another release.  If you do give it a try, please let me know what you think, either in the comments on this blog post or in GitHub, and please log any issues you find on GitHub as well.

Thanks!

Kirk out.

In recent months I have been working on trying to reduce duplication in my own work by keeping my modules and functions as DRY as possible.  One challenge with keeping code DRY in PowerShell is in deciding which is the most appropriate method to do so.  There are many opportunities to keep your code DRY in PowerShell.  You can create:

• cmdlets
• advanced functions
• basic functions
• unnamed functions (aka script blocks)
• script files
• type extensions for the Extended Type System (ETS)
• classes with properties and methods, either in a .NET assembly that is imported into PowerShell, or if you’re using PowerShell 5.0 or later, in PowerShell itself

Despite each of these extension points being available to PowerShell, they don’t always fit the scenarios you need them to, perhaps because they are not appropriate for the intended purpose, because they have some limitation that you can’t work around, or perhaps for some other reason.  For example, I find myself writing all of these, and there are certain pieces of code that I want to set up for easy sharing in many of these types of extensions without being an extension point itself.  When you have logic that you might use anywhere that you could write PowerShell, how do you set that up in such a way that you can consume it in all of those locations easily regardless of the machine you are running on, without taking a dependency on physical file paths?  That last point is important, because standalone ps1 files may be one possible answer to this need, except invoking them requires knowing where they are, and when you invoke them you must decide whether to dot source them or call them with the call operator, which in turn means you must know the implications of such a decision.  Plus, when their use spans all of PowerShell (any script, any module, any function), where do you put them without having to burden the consumer with extra setup work?  And how can you create more of these while making them discoverable, and able to be added to or removed from a system with ease?

Snippets are a great answer to these questions.  Snippet is a programming term that has been around for many years, and it generally refers to a small region of re-usable code.  They are also a lot more than a fancied-up bit of copy/paste functionality.  They have parameters, or fields, that control how they run.  They can surround text you have selected, or simply insert into the current cursor location.  Most importantly however, for me at least, is that snippets can be invocable, and that, my friends, is key because when you’re trying to maintain a DRY code base, you don’t want to inject boilerplate code blocks in many locations…you want to invoke them.

With snippets being a great solution to this problem, I decided to try to build a snippet-based solution that would allow for discoverable, invocable snippets.  I wanted this solution to be able to find snippets regardless of what computer you were running on, as long as you followed a few simple rules.  I wanted this solution to keep snippet definitions as simple as the creation of a ps1 file.  And I wanted this solution to allow for snippets to be invoked in the current scope by default, and in a child scope as an option.

Enter SnippetPx.  SnippetPx is a module that provides two very simple commands, plus a handful of snippets.  The two commands are Get-Snippet, which retrieves the snippets that are discoverable on the local computer, and Invoke-Snippet, which allows a snippet to be invoked by name, with or without parameters, in the current scope or in a child scope.  With this module, any ps1 file that is stored in a “snippets” folder inside of the current user’s Documents\WindowsPowerShell folder, the system %ProgramFiles%\WindowsPowerShell folder, or as a subfolder under the root of any module that is discoverable via PSModulePath will be discoverable as a snippet.  You can see some examples by looking in the “snippets” folder in the SnippetPx module itself, or by looking in another module that includes some snippets such as the TypePx module.  Also, any snippet that is discoverable by this module is invocable by the Invoke-Snippet cmdlet.

Since creating this module, it has quickly become a core module that my other modules take a dependency on in order to keep my code DRY.  That effort has already paid off for myself because it has allowed me to update a block of code that is defined in a snippet and only have to make that change once, while all other locations where that snippet is invoked simply run with the new code change.  I encourage you to give it a try and see if it helps you remove what might otherwise be repetitive code that is more difficult to maintain than it should be.

If you would like to give SnippetPx a try, you can download Snippet from GitHub (yes, it is open source, along with the binary module where Invoke-Snippet and Get-Snippet are implemented) or from the PowerShell Resource Gallery (aka the PowerShellGet public repository).  Feedback is more than welcome through any means by which you want to communicate with me: the Issues page for this project on GitHub, social media channels, comments on this blog, etc.  In the meantime, I will continue to identify opportunities to create more snippets that will be useful to others and push them out either as updates to SnippetPx or in the modules where those snippets are used.

One more thing: if you do decide that you want to create some snippets of your own, there are some useful details in the Notes section of the help documentation for the Get-Snippet and Invoke-Snippet cmdlets.  I strongly recommend giving that a read before you dive into creating invocable snippets, as it provides some additional detail on how snippets are discovered as well as recommendations on the naming of your snippet ps1 files.

Thanks for listening!

Kirk out.

Every programming language must be designed with debugging in mind, and PowerShell is no exception.  No matter who you are, no matter how well you know the language, you will inevitably come across something that isn’t working like it should.  What you do in these situations depends on your comfort level with programming and debugging.  For some, this means adding lines to the code that produce extra output so that they can get a handle on what is going on.  For others, this means rolling up the sleeves and stepping through the code in a debugger.  And there are others still who aren’t comfortable enough with programming or debugging, so they turn to others for assistance.  Regardless of which of these approaches you would take, I believe I have a module that can help.

DebugPx is a free, open source PowerShell module that was designed to make it easier to troubleshoot problems in PowerShell code.  It comes with two core commands: breakpoint and ifdebug.  It also includes a few helpful utility commands to control how the breakpoint command works.  The core commands are described as follows:

Both of these commands are very powerful and they can make troubleshooting problems in PowerShell scripts a lot easier.  Let me provide some background details so that you understand the problems that these commands solve, problems that still exist in PowerShell 5.0 today.

PowerShell version 1.0 did not come with breakpoint support.  It had a debugger, and that debugger is still useful today, even though a new debugger has been in PowerShell since version 2.0.  It had a -Debug common parameter that was available on every cmdlet and, since version 2.0 of PowerShell, on every advanced function as well.  It had a $DebugPreference built-in variable.  It also had a Write-Debug cmdlet that allowed you to have some level of debugger control over your scripts.  The behaviour of the Debug common parameter, $DebugPreference and how those affect Write-Debug behaviour is quite interesting, and once you understand how those work together, you may see why their implementation leaves some opportunities on the table.

When you invoke a cmdlet or an advanced function with the -Debug common parameter, PowerShell internally sets the $DebugPreference variable value to Inquire within the scope of that command.  As far as PowerShell preference variables go, a value of Inquire means that PowerShell will prompt the user to ask if they want to continue the execution of the associated command, stop the associated command immediately, or enter a the debugger at that point, allowing the user to invoke PowerShell commands to troubleshoot the system.  This behaviour seems like it was designed to fill the void when PowerShell did not have breakpoints, because it allowed scripters to enter the debugger as long as they threw a few Write-Debug commands into their scripts.

The problem with this approach is that it tries to do too many things and mixes up several distinct needs in the process.  The ability to write debug information to the debug stream during script execution, and the ability to enter the debugger on a breakpoint at a specific location in a script are two distinct needs that are mashed together when they shouldn’t be.  Another limitation with this approach is that scripters can’t simply change the way a script is invoked in order to gather additional debug information from an environment where they aren’t able to debug with breakpoints as easily, because using -Debug meant prompting the user every time Write-Debug would be called, and often you’re trying to help a user who is having a problem in this scenario, not confuse them by asking them to continue a bunch of Write-Debug calls while telling you what is happening.  Yet another limitation with this approach is that there is no easy way to include PowerShell commands inside of an advanced function or script that will only execute when you are debugging, allowing a command or script author to include support for generating debug output but only when that command or script is invoked with -Debug.

When breakpoints were later added along with a new debugger in PowerShell 2.0, PowerShell script authors were suddenly able to set breakpoints in their scripts, either visually using PowerShell ISE or for conditional breakpoints, command breakpoints, or variable breakpoints using the Set-PSBreakpoint cmdlet.  This functionality solved the need for breakpoints, and it started the separation of the need to enter the debugger from the need to be able to write debug output; however, the -Debug common parameter behaviour didn’t change, so there still wasn’t a good vehicle for writing information to the debug stream without any requirement for user interaction during the process.  Also, while this breakpoint functionality was useful, it came with its own share of limitations.  If you were working in an environment other than PowerShell ISE that didn’t have visual support for setting PowerShell breakpoints (such as notepad++, sublime text, or some other awesome editor), you simply had no choice but to work with the Set-PSBreakpoint cmdlet, which isn’t a very friendly way to set breakpoints in PowerShell, putting it mildly.  Also, if you were debugging PowerShell code across multiple sessions, you would have to reset your breakpoints every time, either manually or using a profile or some other script, none of which is very practical.

DebugPx was designed to solve almost all of these problems with the breakpoint and ifdebug commands.  With the DebugPx module installed and discoverable via the PSModulePath environment variable, you can trigger a breakpoint at a specific location by simply invoking the breakpoint command (or the bp alias, for short).  These breakpoints are identifiable in any editor because you can see the commands in the files where they are used.  They work in unsaved files.  They even work in an interactive PowerShell prompt, or inside of a block that you run in PowerShell using copy/paste, or inside of a block that you select in ISE and run by using the Run Selection (F8) feature.  They are properly ignored if they are inside of a function that uses the System.Diagnostics.DebuggerHidden attribute.  They are conditional if you invoke them with a condition script block (which would map to the first, ConditionalScript parameter), or unconditional otherwise.  They can be globally enabled or disabled using the Enable-BreakpointCommand or Disable-BreakpointCommand commands.  They will only cause PowerShell to enter the debugger if they are encountered in an interactive session.  And if you want a message to be displayed when the breakpoint activates (for example, as a reminder why you wanted to break when that obscure scenario that you previously couldn’t catch occurs), you can pass a message to the -Message parameter and the breakpoint will output the message to the host when the breakpoint is triggered.

If you are debugging in other scenarios, where you may not be able to use the breakpoint command to enter a debugger because you are not in an interactive session (such as in background jobs, scheduled tasks, Azure Automation or Service Management Automation scripts, or perhaps in a remote customer’s environment), you can include rich debug information inside of an ifdebug command script block, and anything that is output from inside of that script block will automatically be written to the debug stream without prompting the end user.  This includes object data, text strings, or anything else you want to write to the debug stream in order to figure out what is going on when that script runs.  If the command containing ifdebug is not invoked with -Debug, PowerShell will simply skip directly over that script block, avoiding running debug logic when it is not needed, which is better for performance.

Both the breakpoint command and ifdebug can be used in the middle of a pipeline as well.  This is important because it allows for writing debug information to the debug stream or triggering a breakpoint in the middle of a pipeline during the processing of that pipeline.  If you use the breakpoint command in a pipeline and you either have the breakpoint command disabled or you are in a script block with the DebuggerHidden attribute set, or if you use the ifdebug command in a pipeline and you didn’t run the script with -Debug, both the breakpoint and the ifdebug commands will simply pass the pipeline object down to the next stage in the pipeline for additional processing.

At this point, you’re probably getting a feeling for the kind for the power that these commands provide.  Let me show you a few simple examples that demonstrate how you might use them in practice.  You can try these examples at the command prompt in the PowerShell host of your choice, or in a script file, or in functions you write, or script module files, or workflows, etc.

Enter the debugger in the middle of a series of commands

$services = Get-Service wuauserv,bits
breakpoint
Restart-Service -InputObject $services -WhatIf

Enter the debugger conditionally in the middle of a pipeline (using the bp alias)

gsv audiosrv,bits,wuauserv | bp {$_.Name -eq ‘bits’} | spsv -WhatIf

Display a message as you enter the debugger reminding you why you are doing so

Get-Process -Name Idle,PowerShell,Explorer |
    breakpoint {$_.Id -eq 0} -Message ‘Process ID is zero???’ |
    Format-Table

Disable the breakpoint command so that you can run without debugging

Disable-BreakpointCommand
gsv audiosrv,bits,wuauserv | breakpoint {$_.Name -eq ‘bits’} | spsv -WhatIf
‘See, the breakpoint command did not cause PowerShell to enter the debugger!’

Re-enable the breakpoint command so that it functions normally again

Enable-BreakpointCommand

Skip over breakpoints in a script block by using the DebuggerHidden attribute

& {
    [System.Diagnostics.DebuggerHidden()]
    param()
    breakpoint
    ‘The breakpoint command is effectively disabled in the current scope.’
}
‘But it still works in scopes that do not use the DebuggerHidden attribute.’
breakpoint

Create a function that generates some useful debug information

function Test-IfDebug {
    [CmdletBinding()]
    param()
    ifdebug {
        # This may be useful when debugging, but I wouldn’t want to gather
        # this information in everyday use. It is an exaggerated example of
        # what you might want to collect when debugging something.
        ‘*************** Current Operating System ***************’
        Get-WmiObject -Class Win32_OperatingSystem | Format-List *
        ‘*************** Running Services ***************’
        Get-Service | Format-List *
        ‘*************** Running Processes ***************’
        Get-Process | Format-List *
    }
    Get-Service w*
}

Invoke that function without debugging

Test-IfDebug

Invoke that function with debug output turned on

Test-IfDebug -Debug

Compare the performance of the two

Measure-Command {Test-IfDebug}
Measure-Command {Test-IfDebug –Debug}

I think those examples provide a good demonstration of how these commands work.  As I hinted at earlier in this article, I am super-excited about this module and I’m thrilled that I can share it with you now.  If you want to give it a try, install the latest version in your environment by following the instructions on the DebugPx project page on GitHub.  I have a few more features planned for this debugging toolkit, and I would be very happy to entertain your ideas as well, so please let me know what you think!  Have fun debugging!

Kirk out.

1.week.ago

Isn’t that a beautiful programming example? That wasn’t a heading you just read, it was a piece of code. It’s simple, it’s very expressive, it’s self-documenting, and it’s pretty hard to misunderstand the intent when you look at it.  That’s not PowerShell code though…it’s Ruby.

Over the past year or so I have taken some MOOCs offered by Coursera and edX.  After playing games that I created for my assignments in Python, I started learning more about Ruby.  Ruby is a wonderful, expressive, dynamic programming language with a vibrant community that has a lot in common with PowerShell.  It also offers more functionality than PowerShell does in some areas, and I started missing some of that expressive syntax that I was able to use in Ruby when I would switch back to working in PowerShell.

Here’s how you can accomplish the same task natively in PowerShell:

(Get-Date).AddDays(-7)

It doesn’t offer quite the same punch, does it?  Between all of the brackets, the need to call out to Get-Date, and adding negative days to be able to get a timestamp representing 1 week ago, it just isn’t quite as palatable to me.

The beauty of a more mature language like Ruby is that it’s not just about the availability of a week method for numeric classes, nor the availability of an ago method for a time span class.  It’s the availability of years, months, weeks, days, hours, minutes, seconds and milliseconds, all in singular or plural.  It’s the availability of ago to refer to a date in the past, or fromnow to refer to a date in the future.  Want UTC instead of local time?  There’s a inutc method too, as well as so many other cool things.  Small details matter.

Fortunately, like Ruby, PowerShell is also a dynamic language that has all sorts of extensibility built-in, allowing me to continue to enjoy expressive, Ruby-like syntax, even while working in PowerShell.  I know PowerShell’s extensibility quite well, and have been leveraging it since version 1.  These Ruby features inspired me to create a new PowerShell module, bringing some of the method simplicity, elegance, and usefulness from Ruby into PowerShell for the rest of the PowerShell community to enjoy.  I called it TypePx.  It’s open source, and it defines useful type extensions and simplifies type acceleration to reduce much of the typing that would otherwise be required when working with types in PowerShell.  Also, it works on PowerShell 3.0 or later, and it’s available now.

Here are examples of some of the beautiful things you can do with TypePx:

# Get a timespan in a human readable way
(10).years
(2).months
(12).hours

# Use relative dates, as mentioned above
(1).week.ago
(30).days.ago.inutc

# How about using relative dates in a practical way with event logs?
Get-EventLog -LogName System -After (2).Days.Ago
# You can use it when monitoring file age too
dir *.ps*1 | where LastWriteTime -lt (1).year.ago

# Compact (remove null values) from an array
$a = 1,$null,2,$null,3
$a.Compact()
# Return unique elements in an array
$a = 1,1,2,3,3,4,4,5,6
$a.Unique()
# Reverse an array
$a = 1,2,3,4
$a.Reverse()
# Slice an array into chunks
$a = 1,2,3,4,5,6
$a.Slice(3)[1]
# Flatten a multi-dimensional array
$a = (1,2),(3,4),(5,6)
$a.Flatten() 

These are only a few examples of what you can do with TypePx.  Have you ever worked with hashtables and noticed how annoying collection management is when it comes to hashtable values?  June Blender was looking for a solution to this the other day, and TypePx solves that problem.

$ht = @{}
$ht.Add(‘A’,’This is not a collection’)
$ht.AddArrayItem(‘B’,’This is a collection’)
$ht.AddArrayItem(‘B’,’This adds to the collection’)
$ht

By now you have probably seen the cool foreach and where “magic” methods that were added to PowerShell as part of version 4.0.  What about version 3.0 though?  TypePx solves that problem too by adding foreach and where methods to PowerShell 3.0 with all of the bells and whistles that are available in PowerShell 4.0.

Here are a handful of other problems that TypePx makes easier:

• comparing an array to multiple search strings at the same time in a single call;
• comparing a string to multiple search strings at the same time in a single call;
• calculating the sum of an array or of a property on a collection of items;
• accessing the value hidden inside of a SecureString;

TypePx isn’t just about type extensions either.  It’s also about type acceleration.  In fact, it was originally released as my old TypeAccelerator module that I had previously shared on PowerShell Magazine and posted in the PowerShell Resource Gallery, but then I renamed it and included full documentation for the *-TypeAccelerator commands as well as all of the type extension goodness I described above.  Type acceleration support is a great way to improve the quality of your PowerShell code when you are working with long type names.  Rather than explain it here though, you might want to give my article on PowerShell Magazine a read if you haven’t already since it explains what type acceleration is in more detail and gives examples that show why you might want to know more about it.

To download the latest version of TypePx, please refer to the installation instructions in the readme documentation on GitHub.

That wraps up this article.  Please let me know what you think in the comments!

Now if only PowerShell would properly recognize numeric literals as objects so that you could invoke methods and access properties on them without having to use brackets…

Kirk out.

Now that I am working full-time with Provance, I’ll be getting up to speed as quickly as I can on the IT Asset Management Pack and the Data Management Pack products that we offer to help companies properly manage the assets they have inside their organization.  I know there is already some PowerShell support in one of the products, although I haven’t personally taken a look at it yet (but you can bet I will be soon).

For those of you who regularly follow my blog, if you happen to use either of these products in your organization, I’d love to hear about it.

Kirk out.

The event will take place on April 24 from 1pm – 5pm.  During this time the PowerShell Team will work with attendees to collectively solve a problem from the ground up using many of the new features in Windows PowerShell 3.0 and Windows Server 2012.

Starting from base Windows Server 2012 images, you will walk through:

• Writing a PowerShell script workflow to perform Server deployments
• Creating a constrained endpoint that hosts only the deployment workflow
• Delegate a set of credentials for the workflow to use
• Exposing the workflow and it’s results through a RESTful web service
• Using Windows PowerShell Web Access to manage the workflow

This is a BYOD event, so please don’t forget to bring your own laptop to follow along!

The facilities we have for the conference can only accommodate 50 people at this event.  To give everyone a fair chance to sign up, on December 1st we will send an email from EventBrite to everyone who has already purchased their conference ticket so that they can then sign-up for this free event.  If you want to have a chance to attend this workshop, you will have a much better chance if you buy your ticket before that date!

There will also be other activities that afternoon for those who cannot attend this event due to their travel plans, or if all of the workshop tickets are all gone. If you are able to stick around though and if you can attend this workshop, this should be a fantastic way to end the conference!

Kirk out.

After almost 100 people voted for the sessions they would like to see the most at the 2013 PowerShell Summit, the results are in!  These votes are for the sessions chosen by the community, and additional sessions from the PowerShell Team will be announced at a later date (as soon as I have them).

Below you will find the not-quite-finalized list of community sessions that will be included in the 2013 PowerShell Summit, sorted alphabetically by speaker.  It is not quite finalized because I am still awaiting final confirmation from a handful of speakers (those marked with an asterisk).  I will update this post as the final confirmations come in.

Thank you to everyone who submitted a session proposal for this conference.  There were a lot of great proposals this year, and I personally think no matter which sessions were voted for, the conference would have been fantastic.  Also thank you to anyone who took the time to vote for their favorite sessions.  Your votes really helped us a lot here, both for the upcoming 2013 conference and for conferences we’ll be planning in the future too!

If you would like to attend this conference so that you can learn from these great sessions and others that are not yet announced, and so that you can participate in the fantastic conversations that happen at such an event, you can purchase your ticket here: http://powershell.org/summit/.

Here is the list of sessions that made the final cut:

Keep an eye on my blog for additional news about this conference, because more exciting news is on the way!

Thanks,

Kirk out.

As of this morning you can vote for the sessions that you want to see at the 2013 PowerShell Summit!  We have 97 session proposals (see below), plus additional content from the PowerShell Team.  Your vote is really important, so please take some time to indicate what you would like to see from a PowerShell-specific conference with deep technical depth.

Here’s what you need to do:

1. Open the voting survey in a new tab or window (this link will automatically open in a new window).

2. Review the list of proposed sessions side by side with the table below.  The table below contains the titles, descriptions, and presenter details for every proposal that is in the survey.  This should save you a ton of time when you’re trying to identify the sessions that you want to see.

3. Pick your top 20 sessions that you would like to see at this conference.  There will be more than 20 sessions, but if everyone sticks to voting for their top 20 we’ll get a good distribution in the survey and it will provide a better sample of what everyone wants to see.

Once you’ve done that, then just sit back and wait until we announce the official agenda after voting closes on midnight, October 28, 2012.  That gives you 2 full weeks to vote for what you would like to see.  Once voting closes, myself and other conference organizers will review the votes, coordinate with speakers, include additional content from the PowerShell team, and build an agenda for the conference.  Building the agenda and confirming with presenters will take a little time, so don’t expect to see it posted the morning of October 29.

Here are the session proposals that you can choose from:

Thank you for helping us create this great conference!

Kirk out.

We are now accepting content proposals from anyone who wants to present at this conference.  All you need to do to submit your session proposals is to add a new topic to the Session Submissions forum on PowerShell.org for each session you want to present.

Who can present?

Anyone who has something to share with other PowerShell experts and enthusiasts that will help them learn more about PowerShell can propose a topic they would like to present at this conference.  There will be a survey shared with the community that allows them to vote for the sessions they want to see, so ultimately the community will decide who can present at this conference.  Note that when reviewing the community results, the conference organizers reserve the right to make some modifications to the sessions that are selected to balance the topics that are discussed and to be able to better accommodate speakers who are offering to present multiple sessions.

What topics will be discussed?

There will be around 100 PowerShell experts and enthusiasts at this conference, including some PowerShell MVPs, some non-PowerShell MVPs, and some members of the PowerShell team.

At a conference like this they will be looking for advanced sessions that show them deep technical content on various aspects of PowerShell as well as real-world practical applications of PowerShell.  They’ll likely want to learn more about workflow, remoting, CIM, and many other technologies used by PowerShell.  They’ll also likely want to learn about how PowerShell is used in practice with PowerShell extensions like PowerCLI to manage vSphere deployments at Scale, or how PowerShell is being used with multiple technologies (SharePoint, System Center Orchestrator, Exchange, NetApp, Active Directory, etc.) to deal with the real-world management challenges that exist in enterprise organizations.  These are just some examples of the topics that might be discussed in sessions at this conference.  It is important to note that no presentations will include any NDA information.  As mentioned, topics will be voted on by the community and then those results will be reviewed by conference organizers to come up with the final list of topics that will be presented at the conference.

Please keep in mind that there will be two tracks for this event: one will have the content with the deepest technical depth, and another will have real world and more intermediate to advanced level content.  With two tracks, you really shouldn’t be shy about submitting sessions if you think you might have something to add.  Chances are, if you’ve been using PowerShell for a while and if you continue to use it very regularly, you probably have knowledge and experience that you can share with others.  Don’t worry about which track your session will ultimately fall in.  The conference organizers will figure those details out as part of their agenda planning.

Where will the conference be held?

The conference will be held on Microsoft campus in Redmond in buildings 40 and 41 from April 22 to 24th, 2013. There may be additional activities surrounding the conference, but the core sessions will be April 22, 23 and 24.

When can I submit a proposal?

You can submit a proposal now.  Simply post your proposal as a new topic on the Session Submissions forum on PowerShell.org for any sessions that you want to present.  Session proposals will be accepted on that forum until October 14, 2012 at midnight PST (take note of that date!).  Once that deadline is met, on October 15, 2012 we will publish a list of all proposals with a voting system that will allow community members to vote for their favorite sessions.  Votes will be accepted over a 2 week period, and the week of October 29th the conference organizers will review the votes and sessions and put together the list of accepted sessions, contact speakers for confirmation, etc.

We strongly encourage you to submit multiple session proposals so that you increase your chances of having a session accepted.  Note that you can submit a proposal even if a related session has already been proposed by someone else.  In fact, if you want to present multiple sessions, I would encourage you to submit the sessions that you want to present, without holding back if a similar session is already proposed.  There are advantages to presenting multiple sessions (see below), and the community will indicate what they want to see in the end anyway.

If you will be attending the conference whether you have a session proposal accepted or not, you should buy your conference ticket as soon as possible to take advantage of the early bird pricing.  If you can only attend this conference if you have enough proposals accepted to cover the bulk of your expenses (see below for details on the benefits of being a presenter), you should submit your sessions now regardless and once the session review process is completed, conference organizers will contact you to make sure you are able to commit to attending and presenting at the conference.  You can also fire me a note if you want to make me aware ahead of time that you can only attend if you have at least 3 sessions accepted, either using my contact me form or via email (on gmail or hotmail, either works, using the nickname I use on this blog as the user id).

Why should I submit a proposal?

Personally speaking, I find presenting information that has been learned through hard work to be very rewarding.  I also find receiving information that others have learned through their hard work to be very rewarding as well.  It’s all about the community participation and sharing of knowledge.  Aside from being proud of your work and sharing it with others, there are more tangible benefits for speakers with accepted sessions as well.

For every session proposal that is accepted (voted high enough by the community and accepted in the final review by the conference organizers), speakers will receive a $300 travel stipend as well as up to $200 to offset 1/3 of their registration cost.  That means someone presenting 3 sessions will receive $900 that they can use towards their travel expenses and a full refund of their registration fee.  This should make it much clearer why it is advantageous to submit multiple session proposals.

One last reason why you should submit a proposal: the value of the conversation that comes with an event like this is extremely high.  You’ll be able to talk to others about your challenges and ideas, learn from their efforts, perhaps find people you want to work with on various community projects, etc.  It’s the networking alone that drives me to attend events like this.

How do I write a proposal?

Each proposal you enter must include three pieces of information:

• a title for the session you are proposing,
• your full name, and
• a 1-2 paragraph description of what the session will contain.

You must create one topic per proposal.  Don’t put all of your sessions on one topic, and don’t reply to current topics when creating proposals, please.

In general when planning your proposal, focus on content that will come with more demos, and less on slide-heavy content.  This is a conference for experts and enthusiasts who are looking for deep technical content on PowerShell-related topics in interactive sessions.  With this crowd, rich, demo-focused sessions will be preferred over slide-heavy sessions.

You should also review some of the proposals that are already submitted as examples.  Keep in mind that the sessions are 35 minutes long with 10 minutes of Q&A at the end (although questions often come up during the sessions at an event like this).  35 minutes may seem like a lot of time, but it goes by quickly, especially when doing demos.

Summary

That’s a lot of information, so here is a summary of the essential points along with links to additional information.

* With a high probability for a short, half-day event adjacent to this.

I look forward to reading your session proposals!

Thanks,

Kirk out.

I officially stopped working for Devfarm on July 6, but I had a few items for PowerWF 3.0 that I wasn’t quite finished with yet so I spent a good part of last week wrapping up development of those items.  When I wasn’t doing that, I was hard at work on getting the public beta of wmix out the door (something that I’ll talk more about later).  With wmix published and my tasks at Devfarm now complete, it’s time to focus on finding what’s next.

If you or someone you know are looking for a talented Product Manager with:

• a very strong technical background with 15 years of experience in software development and infrastructure management;
• recognized deep technical expertise as a 5-time recipient of the Microsoft MVP award for Windows PowerShell, including almost 6 years of dedicated Windows PowerShell experience;
• experience establishing a brand, building awareness, and leveraging social media in marketing;
• strong presentation skills and experience presenting at large conferences such as TechEd; and
• an entrepreneurial spirit

then please drop me a line and lets talk about it.

Thanks,

Kirk out.

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.

Following the analogy that Windows releases are like Star Trek movie releases then, and that the success of Windows 7 was analogous to that of Star Trek: First Contact, it would seem that next two releases of Windows should be pretty much flops.  Star Trek: Insurrection and Star Trek: Nemesis were both pretty forgettable films, offering very little to get excited about.  Maybe Microsoft has picked up on these intertwined fates, inspiring them to try to skip over these failures by fast forwarding to the very successful “reboot” of the Star Trek movie franchise by picking coming out with what they call a “reimagined” Windows.  Did they succeed in making this jump?  Is Windows 8 a truly inspiring, innovative, reimagining of the Windows OS?

Only time will tell what the outcome will be.  First impressions really count though.  Today, based on experiences with the Windows 8 Consumer Preview, Windows 8 appears as if it will show off very well on a tablet device, where the new UI makes more sense.  For business users like me though that rely heavily on their keyboard and mouse to get work done, I’m really afraid that they’ve gone and hidden all of the great features it includes behind a completely different UI paradigm that just doesn’t jive with the needs of a business worker.  It may work well for casual computing at home, but so far it looks to me like businesses might want to consider skipping this one for their non-touch devices like laptops and desktops, at least until they can reconfigure it more like Windows 7 by removing the whimsical metro UI elements such as tiles, charms and “magic” corners.

What do you think?  Is the reimagined Windows living up to your expectations?  Do you think the new metro UI has a place in business computing?  Or do you wish you had your start menu back?

I’m curious if I’m alone in my perspective or not.  My gut tells me I’m not going to be alone in this perspective.  Sound off in the comments and let me know what you think.

Kirk out.

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.

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.