Questions about an Advanced PowerShell Class Design

As we continue collecting responses to an outline survey about an Advanced PowerShell class, I've come up with a couple of questions and would appreciate any feedback you'd care to leave here.

Keep in mind that we're a bit bound by this course being Microsoft Official Curriculum. I gotta make sure, in other words, that the average MCT can teach it. Ahem. I also have to face facts that people don't read or obey course pre-requisite suggestions, and that a lot of people taking the course will have zero programming background.


Question 1: GUI

First, we desperately want to include some module on "building friendly GUI tools for techs and end-users." It's a massively demanded topic. That said, hand-coding a GUI in either WinForms or WPF is physically painful and time-consuming, and nobody would do it. Asking the class to use SAPIEN PowerShell Studio is probably not on the table; Microsoft has rules, these days, about third-party applications in classes, even if they're free (which Studio isn't). Using Visual Studio to generate WPF XAML is probably also out of the question - it adds a lot of build effort for just a single module.

So I'm down to a couple of options. Option A would be to provide students with a basic module that used PowerShell commands to construct a WinForms GUI. They would have after-class access to the module, too. After all, the big thing to teach here is less about how to physically build a GUI (if you were serious about it, you'd get PowerShell Studio), and more about the process of hooking up code to the GUI. By providing a module that shortcuts the hand-coding effort, we'd get to the important bit.

But there's also a valid perspective that creating little distributable GUI tools is dumb, and that you should be building Web-based ones instead. We could certainly build a module around a simple ASPX page - which is much easier to hand-code with a few examples in front of you - that hosts the PowerShell engine to execute PowerShell commands. They're centralized, great self-service tools, and easy to crank out once you've got a pattern to work from (which we'd provide in the class).



Question 2: Workflow

We'd originally proposed a workflow overview module, with a basic example. Folks have quite rightly commented that workflow isn't all it was hyped to be. It's slow, in many cases. It's hard. It isn't really PowerShell. There aren't a ton of killer examples that you can cover in the scope of a class.

But it offers parallelization, which is a great feature. So we're considering replacing workflow with a module on parallelizing PowerShell. My thought is to do that mainly with jobs. Jobs work very consistently inside the shell, and are easy to use. They have some straightforward caveats, like the fact that they return serialized objects.

There's an argument to be made for runspace pools, too. But those get very programmer-y. You have to start worrying about concurrency, thread safety, thread and pool management, and a lot more. I'm not sure, in the context of a PowerShell class, we can sufficiently cover all those extras so that someone could be safely effective with runspace pools. I get that they're more flexible and low-level, but they're a big topic, and nothing else in the course "leads up" to that level of .NET programming.



Anything Else?

Any other suggestions aside from these two questions would be better served in the original survey. I'm not the only one evaluating those responses, and that survey is the only place we can guarantee the entire team will see everything.

Posted in:
About the Author

Don Jones

Don Jones is a Windows PowerShell MVP, author of several Windows PowerShell books (and other IT books), Co-founder and President/CEO of, PowerShell columnist for Microsoft TechNet Magazine, PowerShell educator, and designer/author of several Windows PowerShell courses (including Microsoft's). Power to the shell!


  1. I can't offer much comment on Workflows. I've not spent much time with that, it has perpetually been on my short list of things to learn. I have spent some time doing the GUI thing on top of PowerShell. In the early days I found it a lot more common as the people I was sharing my scripts with just weren't comfortable with the Shell at all. A simple GUI with a couple buttons and select boxes was all that was necessary to make the fear go away. I used the old WPK a fair bit, I think that has long since lost any "support". I have also used ShowUI which was effective for my needs and I didn't think too hard. My GUI needs were simple and I think any increasingly significant GUI on top of PowerShell is probably a fools errand in the end. Neither solution is probably applicable for an official MS course and going pure WPF or WinForms probably isn't very valuable. The "programer-y" to PowerShell ratio is pretty high.

    However I did recently use and hosted the PowerShell (System.Management.Automation) objects to present a few forms and execute the PowerShell on the back end. I really liked that solution. It was much more portable and supportable then the WPK or ShowUI solutions I created ever were. I didn't have to worry about getting somebody a new copy of the code. The web interface is far more universal and in the era of the cloud more genuinely useful for advanced PowerShell users.

    • Thanks much for the feedback, Joel. I'm a big fan of Web-based "tools" myself; I built more than a few in Classic ASP in my day, because they're central and so easily accessed from anyplace, and don't need to be deployed. In the New Era of PowerShell Web Access perhaps it's not unreasonable to suggest orgs spin up an "admin Web server" on a little VM someplace for this kind of stuff.

  2. I'm a little bit late on this (the survey closed while I was moving), but to me an advanced class should start from jobs and move all the way up to runspaces and workflows, even at the risk of crossing borders (which is what an advanced Powershell user should be able to do). Concerning GUIs, what's important to teach is how the basic implementation of an interface can be done and how each well-known graphical element (button, drop-downlists, input box, etc) works and interacts with cmdlets. The GUI part should not be long, but should be organized well enough to make people capable of adapting that part to their customer needs when they're back home.
    Other possible subjects are .NET (I mean, when and how to recur to .NET) and one-liners (understanding how the Powershell interpreter works and how to do a good use of the pipeline is extremely important). What about DSC?