Sikov - stock.adobe.com

Tip

Improve IT efficiency with a PowerShell self-service portal

You can jump over the technical barriers that impede automation efforts in your organization by exploring how to deploy a web-based portal that hosts your scripts.

Automation scripts make life easier for IT, but a PowerShell self-service portal that all employees can use can benefit the entire organization.

Imagine this scenario: You're recognized in your organization for your PowerShell automation skills that get work done easier and faster. Management asks you to make tools for other teams, but they aren't adopting these tools the way you expected. One way to solve this challenge is to build a web-based automation portal.

Web portals reduce the difficulties of distributing automation tools inside an organization. A web portal invites all users to one destination that provides a similar experience for each visitor.

My path to becoming an automation engineer

I started to learn PowerShell because I felt I needed to learn to use this automation tool to keep up with what was happening in IT. It was a difficult process. It took me a long time to understand the fundamentals. But I was hooked from the start.

At a certain point, my PowerShell skills got noticed, and my co-workers requested scripts. I tried to help my peers learn how to make their own automation scripts, but few of them shared my enthusiasm in this area. The lack of interest from others created an opportunity for me to demonstrate some of my newly obtained skillset.

What are the advantages of a web-based automation portal?

A web portal can break down the barriers to automation usage. It starts with creating a script. Once it's ready to share, you typically turn that code into a function. But sharing functions with team member who lack PowerShell expertise can be frustrating.

You might have heard a few of the following comments after sharing your code:

  • "I ran your code, and nothing happens."
  • "It says I need to change the execution policy. What does that mean?"
  • "Your code said something about a required module."

This gets exponentially more difficult if you need to deploy a tool to a hundred team members who aren't PowerShell literate. While you know how to write and work with this code, you also need to find a way to make it work for people who don't have the same technical skills. If it's difficult, they won't use it. What seems easy for you with PowerShell may be daunting for others.

One way to solve this is to remove the barriers that impede user adoption. A web-based portal bridges this gap by taking automation that typically runs inside a command prompt and executes it from the familiar setting of a web page. You can set up a web-based portal that runs a script when the user clicks a button.

Which PowerShell self-service portal should I use?

A handful of companies, such as PowerShell Universal, ScriptRunner and Au2mator, offer commercial products that fill this need for a self-service portal. One tool you can download and deploy in an afternoon is called WebJEA.

WebJEA is an open source toolkit built by Mark Domansky and hosted at GitHub. WebJEA is free to use. It builds a web portal automatically through code and runs scripts in that web portal with minimal configuration.

WebJEA takes scripts you normally run inside a PowerShell command prompt and makes them accessible through a web page you customize to your preferences. As an open source project, anyone can contribute code to add new features or reach out to the author to make a request. All it takes is a simple GitHub pull request.

What are some of the advantages of WebJEA?

The beauty of WebJEA is how easily it works. It reads a directory of scripts and displays them as interactive web pages. People who use the portal don't need elevated permissions to execute the scripts or any special configuration. They visit a webpage and click a button.

Behind the scenes, WebJEA is a website that runs as a service account. The scripts executed in the portal run in the context of that service account. Any script you add to the WebJEA config is automatically read and made available to end users. Any input parameters you have in your scripts are converted to input boxes on the webpage.

The following screenshot shows the WebJEA interface for a script that accepts a username as input and then returns information about the user from Active Directory. WebJEA read the script and turned that one input parameter into a web form. After entering a username, WebJEA displays the results in a just a few seconds.

WebJEA output
The PowerShell script hosted by the WebJEA portal gives the results from Active Directory after entering a username.

The WebJEA module automates the installation process. After you fill out the configuration file, WebJEA uses Desired State Configuration to install all required services, build the website and set up a directory for you to place your scripts into. The install process is covered in detail on the GitHub page.

What are the WebJEA prerequisites and requirements?

If you have some understanding of configuring a website, then you'll find it straightforward to set up WebJEA. The GitHub site has excellent documentation on the configuration process. Despite having little website experience, I installed the tool and had a working portal in a few hours with only a few speed bumps.

The requirements needed to run WebJEA are low. The WebJEA website needs a place to run, and virtual machine is a perfect match for this. WebJEA will run on a domain-joined server running Windows Server 2016 -- either the full GUI or Server Core -- with Windows PowerShell 5.1.

WebJEA runs on top of IIS. The WebJEA module will install the pieces needed to build an IIS website.

WebJEA does not require much CPU and RAM, but more resources will increase performance. I run a portal on a VM with 8 GB of RAM, 2 vCPUs and 75 GB of disk space. But CPU/RAM requirements will depend significantly on your usage. Domansky says he has run WebJEA just fine with 4 GB of RAM and 2 vCPUs.

WebJEA can use SSL for a more secure connection.

WebJEA also needs a service account for the IIS app pool that it creates during installation. Best practices recommend the use of a group-managed service account with password rotation. WebJEA supports this configuration by default. This will keep passwords hidden and managed by Active Directory. If you're not ready to use this type of Active Directory account, then you can use a standard service account.

What are the limitations of WebJEA?

You should know the shortcomings of WebJEA, which will affect how you write your code so that output works as expected.

First the scripts will run with limited feedback. Nothing gets displayed to the client until the script finishes. You also can't use some advanced cmdlets, such as Write-Progress, and you cannot pass credentials to scripts via the webpage input fields.

All parameters passed to the script are strings. All output will be string output. Essentially, what's sent to Write-Host is what will output on the screen. WebJEA pipes all output to Out-String to generate usable output from any return data. You can control data organization with various cmdlets, including Select-Object and Sort-Object. You can also control the layout with Format-List and Format-Table.

Why it's worth looking into WebJEA

It only takes a few hours to deploy WebJEA. Its dashboard is easy to configure and modify to add scripts. I have gotten positive feedback from co-workers who use it. WebJEA is open source and costs nothing. WebJEA will help you and your team stand out and solve the challenges of deploying automation to the masses with one installation.

Next Steps

Learn how to use the PowerShell Trim method

Dig Deeper on IT operations and infrastructure management

Cloud Computing
Enterprise Desktop
Virtual Desktop
Close