PowerShell Universal v4.0 Vision and Roadmap

PowerShell Universal

March 15, 2023

quote Discuss this Article

PowerShell Universal version 3.0 was released April 22nd, 2022. Since then, we’ve had 70 releases to add new functionality, fix bugs and improve user experience. We are reaching the end of our PowerShell Universal v3 feature development. Now that we have reached this milestone, we are looking forward to PowerShell Universal version 4.0.

Over the next few months, we’ll be building on our v3 platform to deliver the next major version of PowerShell Universal.

Release Themes

Below you will find the themes for this release. We believe that we have a solid platform to build upon and will begin to fine tune many of the features that already exist. Our themes include:

Modularity

PowerShell Universal is an extremely versatile platform, with many moving parts and endless possibilities. That said, we see a lot of customers building similar tools and we want to make it easier to share development between users, teams and Ironman Software.

The templating engine in PowerShell Universal leaves a lot to be desired. Templates can be destructive and do not remove easily. We’re rebuilding the extensibility model from the ground up to provide a more isolated and safe plugin model that doesn’t cause issues with your existing configuration. We’ll also be replacing the Templates nomenclature with a more PowerShell centric term by utilizing the “PowerShell Universal Modules” going forward. It also helps to indicate that modules are readonly and extend, rather than change, an environment.

Some goals for the new extensibility model include the following.

Module Preferred Development

Using modules in PowerShell Universal currently isn’t the greatest experience. While you can define your own modules, they are mostly just an arbitrary script where you can store global functions. We are looking at ways to surface modules more easily throughout the platform.

For example, you’ll be able to create scripts and schedules from Module and Command names rather than just scripts.

Invoke-PSUScript -Module "MyModule" -Name "MyCommand"

By relying less on hardcoded paths and more on modularity, we can allow PSU to be more composable. It also means you can bring in modules unrelated to PSU and tie resources like schedules directly to their functionality.

In addition to making resources easier to tie to modules and commands, we’ll working on making the module development experience much more enjoyable and productive by improving the editing experience and automatically reloading functionality related to modules when they change.

Safe installation and uninstallation of modules

Modules should not modify existing configuration. While installing a module may cause issues, it should be easy enough to uninstall the problematic module without affecting the system.

We’re also planning on supporting dependencies so modules can share the same base functionality between them. You can think of an AD module that is a dependency between both an AD API and an AD dashboard module. You’ll also be able to take a dependency on a module in the PowerShell Gallery; like dbatools. This means that all you need to do is install your desired functionality and all the dependent modules will be installed as well.

Simple publishing mechanism

We’d like to make it much easier to publish modules. We have several ways to publish a template at the moment and would like to consolidate that into a single mechanism. We’d also like it to be similar to publishing to the PowerShell Gallery. This will be accomplished with a Publish-PSUModule cmdlet in the Universal module. You’ll also be able to export your PowerShell Universal configurations as packaged modules using a cmdlet like Export-PSUModule against a running PSU instance that you can then publish.

We will also be exposing a custom NuGet feed via IronmanSoftware.com. PowerShell Universal Dashboard utilized the PowerShell Gallery to store UD modules but we have decided against doing this going forward. It clutters the Gallery without providing any value to non-PSU users. You’ll be able to use PowerShellGet v3 cmdlets to install modules as well as through the PSU admin console. We’ll be deprecating the Universal Dashboard Marketplace and validating components that still work in PSU. We’ll include those modules in the feed if they pass validation.

Stretch Goal: Platform and Admin Console Extensions

We’re considering implementing a C# and\or PowerShell based plugin system for the PowerShell Universal platform and admin console. This would be used internally to add new functionality and formalized to allow for others to extend the platform. We are considering extension points such as:

The SDK would be provided as a NuGet package or PowerShell module.

Unified User Interface Tooling

We currently have two different mechanisms for building user interfaces: dashboards and pages. We’d like to unify the tooling to allow for the creation of simple UIs without code as well as providing the full functionality of the dashboard features available today.

The Great Rename

We hope to rename the dashboard functionality to better indicate the actual function of the feature. Universal Dashboard was misnamed long ago and we are considering better ways to describe what it really does. We’re also looking at ways to better organize the smaller parts of dashboards to help reduce the size of dashboard scripts so it is much easier to develop large and\or complex tools.

We are not set on naming, over even the specific groups of resources, but as an example, you would see something like this in the User Interface drop down in the admin console.

If you have ideas for the best way to describe what a dashboard really is, we’re all ears.

Drag and Drop Designer

We are working on providing a drag and drop designer that will work with dashboards. This will allow users new to the platform, or users that do not need the complexity of a dashboard, the ability to quickly build and prototype tools. The designer will output PowerShell script but may require some rigidity to allow for the designer to work properly.

Components that require more complex definitions can be written in code and placed on pages. It will also be possible to avoid the designer all together and write code by hand. It may not be possible to load existing dashboards directly into the designer but we will evaluate that as we move forward.

Support for Existing Pages

Pages built with the existing drag and drop designer will still work but will be running within the standard dashboard framework (Material UI) rather than within the admin console framework (Ant Design). This will allow pages and dashboards to interact without the need for iframes or other hacks to mount one in the other. It will also allow for the blending of navigation and routing.

Theme Editor

We hope to provide a visual theme editor to allow for easily modifying colors and styles without having to write code. The first implementation will allow for simple configuration of base colors for both the light and dark theme as well as some stylist details like spacing.

Enhanced Automation

While the PowerShell Universal automation platform makes a good replacement for Task Manager and schedule jobs, it is still lacking alongside other enterprise-ready automation platforms. In this release we have some items to help bridge that gap.

Pipelines

One of the missing features of PowerShell Universal is the ability to tie multiple scripts together into a pipeline. This is possible by taking advantage of Invoke-PSUScript or by calling scripts directly from other scripts. This isn’t ideal and isn’t as discoverable as we would like.

Similar to jobs, pipelines will be able to be invoked by schedules, triggers and ad-hoc. We are also considering, similar to PowerShell Workflows, persisting state between steps in the pipeline to allow for rerunning only partial pipelines in the event of failures or restarts.

Client-Side Events

We will be introducing a cmdlet within the PowerShell Universal module called Register-PSUEvent. Similar to Register-ObjectEvent in PowerShell, it will accept a script block that will be run when the event happens. The cmdlet will connect to the PowerShell Universal server, using the credentials specified, over a web socket. Administrators will then be able to push events to connected clients based on events within PSU or manually via a cmdlet such as Invoke-PSUEvent.

This will allow for edge nodes or other servers to take action locally when certain events happen on the server. This is great way to build out a system where you can run scripts on remote nodes in a push mode rather than polling in a loop.

Stretch Goal: PowerShell Universal Agent

As a stretch goal, we’d like to introduce a PowerShell Universal Agent process. The agent process would be capable of running jobs but would not provide the entire PowerShell Universal admin console, API server or dashboard support. Agents would be able to register with different queues and could be the target of jobs and schedules from the admin console.

Diagnostics and Debugging

Determining what is happening within PowerShell Universal can sometimes be difficult as logging and other diagnostic information is spread throughout the platform. Another focus of this release will be to address the need for better developing and diagnostic tooling.

Single Pane Logging

We will be consolidating all the logging mechanisms into a single structure log system that can be viewed for a single place so you can trace scripts across the platform. This will include logs such as APIs, dashboards, the web server and scripts.

We hope to retain logs in a way that we can search and render them in the most useful way possible. We’ll also be introducing tracking IDs so you’ll be able to follow the path from Dashboard to API to script and back.

Debugging

The current debugging implementation is a bit difficult to use and not approachable by most users. We considering ways to better expose debugging tools directly alongside code to make it easier to identify issues without having to write to files or use Show-UDToast.

It’s always been a dream to have breakpoints directly in the PSU editors that, when hit, would switch the editor into a debugger mode that would display variables, allow for stepping and running debugging commands. Obviously, this is no small feat so we are trying to find the best approach to provide a better debugger without spending our entire development effort on it.

Live Documentation

Rather than relying solely on the current markdown-based documentation, we’d like to provide documentation built on PowerShell Universal. This documentation will continue to be open source as well as included with the product directly. We will still take advantage of markdown but will likely render it within dashboards alongside live examples of components. We will continue to publish to Gitbook as it provides the best SEO but we will be linking to live examples of our components on a hosted PSU instance.

In v3.8, we introduced the static pages feature to better support the performance required for documentation such as this.

Seamless Upgrade

As part of the v4 effort, we will be ensuring that the upgrade is as seamless as possible. We will be limiting breaking changes and ensuring that you will be able to just upgrade the application files from v3 to v4 without changes to your configuration files.

That said, there are some breaking changes that we are already aware of:

Improved MSI Installer

Most of our customers are running on Windows. While working with MSI can be tedious, it does provide reproducible installs in a way that manually deploying ZIP files cannot. We hope to improve our MSI install to include additional configuration options like HTTPS certificates, IIS installs, and service account privileges. We hope to alleviate some of the manual management necessary when setting up a new PSU server.

Improved Scripted Install

The current implementation of Install-PSUServer is a bit clunky and we’d like to improve it. We would also like to allow for more configuration options and better validate it against target platforms to ensure it works more successfully on more systems. The cmdlet will also directly invoke the MSI on Windows rather than using the ZIP file to unify our non-Unix install methods.

Stretch Goal: Auto-upgrade

A stretch goal for this release is to include an auto-upgrade functionality. This is currently in planning and we will likely only upgrade a subset of deployment scenarios, such as MSI.

Continued Efforts

In addition to some general release themes, we will also be focusing on efforts that we have undertaken over the last major release cycle.

High Availability

While we have made large strides in PowerShell Universal’s ability to provide a redundant platform for your automation tools, we would like to continue to focus on this aspect of the platform as more and more users scale out their instances. Some highlights include:

Module Support

Certain modules do not work well in PowerShell Universal. We’ll be focusing some of our effort in to ensuring that popular modules “just work” in PowerShell Universal. Some of our targets include:

If you have a module you’d like us to take a look at, please open an issue on GitHub.

Developer Tooling

Our VS Code extension has become a bit of a second-class citizen when it comes to the tooling in our admin console. We’d like to change that and provide a better experience for developers using VS Code. We have some ideas on hwo to make this better but would love to hear feedback. Some of our ideas include:

Do note that our VS Code extension is open source and always open to contributions.

Timeline

We will be releasing beta versions of PowerShell Universal v4 over the next few months. This timeline is subject to change. We will likely have interim beta releases between these milestones as features and bug fixes are released.

Beta 1 - April 11th, 2023

The first beta will include extensibility improvements, logging and client-side events, along with smaller fixes and features in our backlog.

Beta 2 - May 9th, 2023

The second beta will include unified user interface improvements, pipelines and live documentation.

RTM - June 13th, 2023

Final release of PowerShell Universal v4.

Version Support

Below is the support timeline for our versions of PowerShell Universal.

v2 - End of Support

PowerShell Universal v2 will reach end of support and maintenance on June 13th, 2023.

v3 - Maintenance

PowerShell Universal v3 will continue to be supported through June 13th, 2024. We will be releasing one more feature build of PowerShell Universal v3.9 on May 9th, 2023 with small features merged from our v4 work along with other features based on customer demand.

v4 - Feature Development

New feature development will take place in v4 until June 11th, 2024 when the release will enter maintenance and will be supported through June 10th 2025.

Conclusion

While this is our vision for v4 going forward, we are very user driven and very open to feedback. Our release milestones on GitHub will continue to evolve as we work through this release. Feel free to comment on the forums or on GitHub with issues, concerns and suggestions.

Do note that this is just a general overview of our goals and not a complete list of items we hope to address. If you don’t see your issue listed here, don’t fear, we will be moving items around in the backlog as we move into development of this next major version.