PowerShell Universal v4.0 Vision and Roadmap

Announcements
1
This is a companion discussion topic for the original entry at https://blog.ironmansoftware.com/powershell-universal-v4-roadmap/
5 Likes
2

Good read,

This line made me chuckle though

good replacement for Task Manager

PSU is an absolute Heavy Task Manager Client :smiley: Task Scheduler replacement thoughā€¦

Glad to read about better Multi Admin Support, looking forward to 4.0.1 :smiley:

3

Client side events will also bridge the connections between PSU server and Desktop!
That is a very nice feature!

4

This would be really nice, I donā€™t care much for C# personally, but Iā€™m a huge python and Bash fan.
An option to use Python as Execution engine, would increase my daily workflow with a factor 100.

I write logs to files, so when my users complaint about something I can go back and see the state and what they clicked when the error accrued. To have this a centralized place with all the necessary info would be amazing!

Iā€™m looking forward to beta-test v4 :smiley:

1 Like
5

Whoopsā€¦typoā€¦

I bet we could create a Task Manager with PSUā€¦

6

Great job Adam. I think youā€™ve definitely got a good vision for the future of PSU.

Especially looking forward to the modularity and documentation plans.

I canā€™t say enough how excellent this product is and how much I enjoy using it.

1 Like
7

One noteā€¦Iā€™m actually not excited about the drag/drop designer idea.

The ā€œpageā€ UI is one corner of PSU that I donā€™t particularly like. Iā€™m guessing thereā€™s a place for it but itā€™s not for me.

8

Thanks, Mike!

I have to admit, I find the Pages as they are currently implemented to be not very useful, confusing and often broken. Itā€™s one of the reasons to mention it on the roadmap. The v4 designer may end up being a tool for quickly laying out components rather than a full-fledged designer (like windows forms). I do often see new users gravitate towards pages, reach some basic limitation and then decide to use a dashboard.

I do have to admit that UD pages do have a tendency to be more dynamic than a page designer could probably account for but Iā€™d like to find a way to make it faster to prototype simple tools. I have some ideas that blend together the simplicity of a designer but with the high customization of the dashboard scripts. Weā€™ll see how it all shakes out.

Either way, the existing way to develop dashboards isnā€™t going away so there should be no worry about being forced into the designer in whatever implementation it ends up with.

1 Like
9

Now this is exciting stuff!

ā€œPowershell Universal Agentā€ is an interesting stretch goal when combined with client side events.

Speaking for myself, Iā€™m the Desktop/Endpoint guy. My use case with PSU covers a few different areasā€¦

  1. Endpoint data collection. Currently I just have scripts running as scheduled tasks to collect computer information. This information is then fed back to PSU through an API, where it is stored in a DB.

  2. I have a dashboard that provides a front-end for pulling information from said DB, along with ā€œconnectingā€ the data to other sources (Intune for endpoint management, Snipe-IT for asset tracking). In this case, itā€™s the ā€œglueā€ which keeps all these disparate products aligned with their information.

Now for Modularityā€¦

I have long wondered how I could possibly extend management capabilities of client devices using PSU. The biggest point to me is: how to make sure the client-server connection cannot be abused or used maliciously. I think the ā€œAgentā€ could solve this. I would be very excited to try my hand at a open source RMM tool which uses PSU to do the ā€œhard stuffā€ like security and auth, so I can focus on features.

So all in all, very cool stuff and I look forward to playing around. Thank you for all your hard work in providing such a great platform :slight_smile:

10

Sadly as a ā€œnewā€ user, I agree. Even though I see a lot of untapped potential in them. The way to build them is so far removed from how I build almost everything else through PSU. Just donā€™t see the value in investing time into leveraging them over Dashboards.

If somehow as you mention you can take the visual aspect of it, and combine it in some way with the code editor style of Endpoints or dashboards. I would be all over that in a heartbeat! :smile:

11

Thatā€™s what Iā€™m hoping to achieve. I think the current Pages are too ā€œno codeā€ and what we really need is ā€œcode in the right spots with a dash of visual designerā€.

3 Likes
12

Good work! In particular fond of pipelines and single pane logging here.

13

Excellent post.

I would personally love to see the following as an evolution of the following:

  1. Enhanced Git support

    The ability to apply Git at the Dashboard level, so I can have a Git repo per Dashboard.

  2. Multi Arch support.

    This has been briefly touched on here and here in Forum posts. Currently, PSU is built from a Microsoft provided image of Ubuntu with PowerShell included. It would be good to see a move to the official Docker Hub hosted image of Ubuntu and then PowerShell installed as part of the build process.

    The reason for this is that the Microsoft images only support a single arch type per image (AMD64/x86_64). We are beginning to see a new generation of enterprise ready vmā€™s and single board devices of the not so new ARMv8 architecture, which has good compute using low power levels. Adding the emulation layer needed to get PSU 3 working wipes out any saving, and with AWS offering a new line of ARM64/ARMv8 services, this would be a massive win on the compatibility front.

  3. Support for another Database engine.

    Currently, If I would like to use an external database, I have the choice of hosting my own SQL Server or using a cloud hosted SQL database. I would like to see something like MariaDB, MySQL or PostgreSQL (which ever works best) so I can add this to my Docker environment without the need to go down the Microsoft SQL route and deal with the licencing requirements which come with it. This would also allow me to run a database on ARM or another non x64_64 architecture.

  4. Work towards Kubernetes functionality

    At some point, most likely the next time I re-architect. I would like to be able to have the option of hosting a Kubernetes deployment pretty much anywhere I decide to go. Items 2 & 3 are what stop me from testing this without incurring quite a cost. I would like to be able to host a full licence deployment of something like a Raspberry Pi4 or cluster of nodes. If we get the PSU agent mentioned on the post, this would be a perfect ā€˜worker nodeā€™ option.

I know there is a lot there. I hope this list does not give @adam any type of hypertension at the pure scope of some of it. The above would enable me to run a more dynamic cost-effective and more environmentally friendly (if that will boost my case) deployment of PSU.

5 Likes
14

An idea for Pages would be a Visual and Code view. In the visual view you design and in Code view you have acces to all code generated by the designer. It is possible of course then to break the design and the visual editor cannot read the code anymore and work with it but that is my responsibility as developer.

What you could also try is to have ā€˜code behindā€™ on controls. At certain levels of events you get to type code. So an entry fields would have a lot of properties and these events: HoverIn, HoverOut, Click, Release, Etc. On each of these you could have some code.

But in the end you will create a full fledged UI designer ala Visual Studio and I am not sure if that is wise :slight_smile:

I used Clarion in the past as desktop developer and in the code editor you could put you cursor on a window structure and press Ctrl-F to start formatting a screen based on that code structure.

Something like this:

WINDOW         Name('MyWindow'),Title('My First Window')
   INPUT          Name('Address'),Type('single'),Length(20),Required, etc....
   BUTTON         Name('OkButton'),Type('3d'),Length(20),Required, Color(grey), Icoe('Save'), etc...
END

Putting your cursor on that structure and pressing Ctrl-F would who the visual editor and once you left that, the code needed to represent the window/page would be in that structure.
You could invent ā€˜markersā€™ around visualisation code/structures and then once a hotkey is pressed, that structure is read and represented to the developer.

But overall I agree, limiting Pages to a visual editor only is not attractive at all and limits possibilities. Itā€™s a tad too ā€˜end user experienceā€™ for me where the development is not meant for end users but more geared towards power users, developers, IT admins, that kind of thing. As it stands, it feels like something is missing and it seems to be the lack of influence and control over these Pages.

15

Yes, I would also give big thumbs up to non-MS database support. We want to deploy a PSU cluster but the requirement for MS SQL gives us only two options:

  1. pay a lot for the MS SQL Failover Cluster / Always On Availability Groups
  2. go with a single-point-of-failure solution, eg. MS SQL Express

@adam - could you please consider this for future releases?
Thanks! Lukas

1 Like
17

Lets hope so. So far the stretch goal has not been assigned to a milestone: Support for PostgreSQL / other database technologies Ā· Issue #1801 Ā· ironmansoftware/issues Ā· GitHub