agent-18762_1280PowerShell is a shell language by nature. This means it was designed for the command-line. 95% of the PowerShell scripts you are building today are most likely executed from the PowerShell console in some way. However, did you realize that you can build professional-looking GUIs from within PowerShell? Due to PowerShell’s tight integration with the .NET Framework, you are able to do this through two different methods; Windows Forms and Windows Presentation Foundation.

This post isn’t going to be how to build GUIs. There is a lot of information out there on how to do that. Stephen Owen has a great series on it. I will also have a small course on Pluralsight on building GUIs with Windows Forms and PowerShell soon as well. Rather, I’d like to over some considerations of when you might choose to create a GUI rather than a command-line tool.

To demonstrate this, I’d like to tell you about an experience I recently had with a client.

In a previous job, I was a Microsoft System Center Configuration Manager (SCCM) administrator and got a lot of experience performing software deployments. As such, clients sometimes hire me to design scripts and various solutions to help them get software installed or removed on a lot of clients at once.

Ready to stop reading and start learning about PowerShell, DSC, Windows Server, Sharepoint, IIS and dozens of other categories? If so, check out the hundreds of free technical demo screencasts available on the new, IT career development platform TechSnips.

In this job, I was asked to build a tool that would remotely install and uninstall a few different pieces of software. No problem. After 10 or so hours I built, tested and ran this tool through its paces and it worked great. It successfully removed 5 pieces of software on three different operating systems, installed one and rebooted as necessary. It worked well, was configurable and I thought it was a great tool.


The client hands it to his helpdesk and it fails miserably and the helpdesk refuses to use it.

Why? Simply because of the PowerShell execution policy and a couple of minor bugs that were easily fixable. The tool didn’t just work right away and the helpdesk didn’t have the patience to run through the preliminary testing in order to make it work in their environment. The gotchas were tiny, little things to me but huge problems for the helpdesk that didn’t know anything about the tool.

Build a GUI and They Will Come

The answer was the build a GUI.


As you can see, this is MUCH easier for the helpdesk to understand. Rather than explaining to them how to open up the PowerShell console, setting execution policy and troubleshooting in PowerShell they now can simply open this up and be done. I also packaged this up into an EXE file for them.

This tool outlines clear directions right in the tool, allows them to pick and choose software and the computers the software is getting deployed to. It also includes a Status column beside each computer to show the status of the deployment in real-time as it’s happening.


Even though you can build something that saves time, reduces human error and automates the crap out of something doesn’t mean it’s going to be used. If you’re building tools for others, you must think about usability from their standpoint.

Design the tool in a way that they can understand. If you don’t, they will probably complain and tell you your tool is crap due to their ignorance. But, it’s not necessarily their fault. They don’t know any better. The fault is on you. You should recognize the audience that will be using your tool and build it in a way that fits their job; not yours.

%d bloggers like this: