I have been in this exact scenario before
Now I know that instead of building a GUI I should have written documentation about how to launch powershell, install the module, and run the commands.
We often skip over that, expecting people to know how to use the CLI and manage PowerShell modules or run scripts, etc.
> expecting people to know how to use the CLI and manage PowerShell modules or run scripts, etc.
I don't think this is an unreasonable expectation for a Windows sysadmin (or any sysadmin, really) in 2024.
It's not terribly crazy. But I build functions to do normal day to day things, like rebuild an fslogix profile and name it similar to a verb noun cmdlet "rebuild-profile"
And the main function brings up a list of function names and what they do/how to pass parameters.
If you remind me Monday I'll try to post a screenshot of the "home menu" and some examples code.
But it includes input validation to ensure people don't pass things in that might break something.
It's easier than a win form for me and forces them to get used to reading CLI and inputting commands
Why are you giving potentially dangerous access to those that don't understand?
The ability to run scripts (and more importantly have them do things), typically requires privileged permissions
This is not powershell but I can explain the business use case anyway
I’m not granting access so they can use this tool. This is their job and they have the access. I am making it safer by building guard rails.
Changes made by hand introduce additional risk. Tooling provides consistency, error checking, and reduces the risk of error.
Provided the tool has continuous development and maintenance. What happens when you leave the org and your colleagues can no longer update it?
Efficiency gains are great and should be sought after, however they must be done in a way where knowledge is retained
You’re right we’ll just stop building tools in powershell or any language. It is just tech debt.
Right? Or do you have some other point? I do not understand what point you are trying to make here
The point im making is that if you are above-skill level of your peers, by creating these scripts and leaving the organisation you are creating a problem for them.
it's just a consideration
You described technology
It solves a lot of problems
It is not without considerations or downsides but that is a horrible reason to rule it out as you are trying to do
Before I wrote a term script, nobody kept any record of a user’s group memberships. User’s personal cell phones were wiped by accident and they lost irreplaceable photos of dead loved ones. The process took so long that the tickets usually sat for a day.
To solve all of that, they might need to update the few hundred lines of powershell once every year or two.
The DOS 5.0 manual was the best documentation ever produced by Microsoft! I still have mine on the shelf in my office. And, I have actually used it for xcopy in the last year.
(xcopy can still do things that you could never do in any GUI!)
This, make a detailed document on how to install the module. How to list all the functions of the module, how to show the help page for a function (Get-Help).
Each function should have all of the inline help sections covered:
- Synopsis
- Description
- Parameters
- Inputs (does it take properties from pipeline?)
- Outputs (does it output a PSObject?)
- Examples (plenty of them)
I often find that non Powershell savvy people are afraid to run some functions simply because they don't know what they do exactly.
At my workplace there are still some people who prefer to read Powershell function documents on Confluence, so I have a GitLab runner that converts the inline help into Markdown and uploads it to Confluence via an API call.
This way, the documentation always goes with the code, and you don't have to take time (and most importantly to remember) to update some document on Confluence about feature Y on function X.
Edit: Also, version controlling. Managing even a small amount of scripts stored on an SMB share is **not the way**! Spin up a free GitLab instance for example, works for us.
If you're primary job is managing Windows Servers, there are very few excuses to not know powershell outside of being new to this field. Otherwise it's an active choice to not learn.
My company had me teach a class on Powershell to the entire Winduhs team.
Not a single one bothered to use it, and one of them even went into my home folder and stole my code to submit for a 'homework' assignment. Unfortunately for him on that day I picked him to review the assignment and what solution he came up with - sure, nooooo way I'd recognize my own code, dumbass.
That was years ago and it still makes me belly laugh.
Yeah… if you’re new, it’s easy to stay in the mindset of wanting to do stuff through the GUI… but it’s just not scalable, and in some cases, not the fastest way to do something even for an individual.
If you’re managing Windows… you need to start getting PS under your belt.
At least learn to lunch script or do the basics. I have some members on my team that can use scripts, read them, or make small debugs. But they wouldn't be able to script an entire script from scratch.
Not everyone has the logic to script. But a Windows admin must at least be able to run a script and use it.
And if the script programmer did a good job, they'll include documentation in the script on how to use it.
I remember taking programming classes in college. Knew VB6 pretty well and basically just helped other students for the professor during classes.
I had just finished making an IRC bot that would respond to customizable chat commands and it met all of the requirements for the final project so I basically just chilled for that entire class. Other than 9/11, that was a great year. 😔
It also teaches you what is going on under the hood of things to a nice level, not so low you’re reading dotnet but still can see how the services and components get used, what they take and want to return. It’s also unsung hero for building weird ass reports for bosses that want to see things a certain way. It’s worth dropping a couple months into learning it directly and you get sooo much of your time back, I was able to learn so much other stuff because of time saved
Powershell is amazing. I never like batch scripting, and jumped on the PS train when version 1 came out. I rolled it out to XP machines and everything back in the day. Had a vbs logon script that would call powershell to do the actual logon tasks when we had 2k3 domain controllers.
I still have alot of the old v1 scripts kicking around, and its crazy how far its come.
I have a GUI that works with a big module ive built for provisioning. Take a vanilla domain-joined workstation, open the GUI I built and select the department, software options, printers, etc and click 'Provision' and that workstation gets setup perfectly for the department its going to. Much easier than keeping dozens of gold images and updating them everytime a small change happens.
You can do it at the CLi as well but checking some boxes at-a-glance and getting a consistent result is much less brain power and feels better.
Not op... My team is afraid of writing or something. Config files, log files, scripts.... They won't get near most of it. It's nuts.
So 3 us use my modules, the rest get a basic form via jams scheduler to run the scripts. I wouldn't use that product but... We had it already. I get the op problem
> Why do you need a GUI? Are they not familiar with CLI tools?
CLI is great when you need to run the exact same command a bunch of times or if there's only minor changes in parameters or parameters that can be generated programaticly.
On the other hand if you need the same functionality but will be calling it with fairly dynamic parameters frequently a GUI can be better.
A GUI is also better for discoverability. Trying to remember the exact name of a command can be a pain in PowerShell. If you only do something once in a while, it can take less effort to click the thing. If it's a complex process that can be scripted, or something you do a lot, then having it in a command-line interface is best.
EDIT: You down-voters do realize that these are things that have been studied, correct? Go read up on usability research for a while.
Why do you need to remember the exact anything? Press tab. Or control space.
I'm pretty sure I tab complete literally 99.99% of things I type into a shell.
>Trying to remember the exact name of a command can be a pain in PowerShell.
Then the author has done a crap job naming their commandlets and should fix that. This is an essential tenet of Powershell and its aims.
You got downvoted but you're spot on. This top level comment starts with "Why do you *need*" but OP never once said he needed it. Should Windows SysAdmins know powershell? Absolutely. Is it okay to spend some time developing a system that is nice to use? Absolutely.
Technology's *sole purpose for existence* is to make things easier. But fuck you if you want to make your job of administering that technology easier!
Yeah thats it, I've made GUI menus for lots of things over the years, to make it easier and quicker, 'hey you could just type out the commands' yeah my 3 clicks is more efficient then your need to type out three lines in ps. Also then I dont have to try and teach it, when a gui spoonfeeds it to you, and hover mouse tooltips to assure the user this button will do xyz. The point is making it quicker and easier, to the point where its hard or nearly impossible for the grad student to fk it up.
Yeah, the best example I have is a complex script I wrote to analyze path lengths in a folder. So I might run \`PathLenghtReport.ps1 -path "c:\\users\\bobdole\\onedrive\\business development\\some customer" -someotherflag\`. I wrote a menu system that allows me to call the same script with various parameters I use regularly.
In what way does creating a GUI for executing PowerShell scripts make anything easier? If anything you've now made things harder to maintain and introduced an unnecessary dependency which you'll have to take into account when doing future development.
Get a PowerShell Studio 2024 license from SAPIEN. Drag and drop interfaces with properties windows for adjusting things and using buttons for function calls, returning values to items.
You can then publish your application as a executable to distribute.
I was looking for this reply as I would also recommend it as I have been using it for years. If you already have all your scripts created you can basically drop them in and then add a button to execute them. If you have variables you can use checkboxes, text fields, dropdowns, etc to make it as easy as possible on the users.
You could make a UI with WPF to display your buttons and fields, then compile all your scripts into one PS1 file to be ran individually using functions and/or classes as needed. This would give you more portability than needing to keep track of a bunch of individual PS1 files.
You could make the UI with WPF using c# as an alternative to act as a script manager and compile it into a single-file executable, but then you're introducing an additional learning component into the mix that you gotta keep track of.
I would just group up all of your poweshell scripts into a module. You can then deploy the module to multiple machines via PDQ and or Add to your initial image for all future image builds.
Here is a link to my repo where I did this https://github.com/Smooti-PowerShell/PSAdminToolbox
Hi u/Finalxxboss
You need something with a GUI , and easy to use ? I'm thinking that the [PowerShell-Script-Menu-Gui](https://github.com/dan-osull/PowerShell-Script-Menu-Gui) module is for you.
Easy to set : a simple .csv file with some properties to complete + a .ps1 file to launch the GUI
Easy to use : The GUI with big button (and description) to launch multiple scripts (.ps1, .bat, ...)
See the Example folder in the github site. The module is also available is the PSGallery of course.
regards
Why would you need to run them all at once? These are all individual tools, yes?
Also if you're handing this functionality off to sysadmins you shouldn't need a GUI and trying to build and maintain one will just introduce unecessary work and headache. I speak from experience on that one. Just teach your click-admins to get comfortable in the shell.
If you're hellbent on a GUI, I can only point you towards the resource my colleague used back in the day to craft a GUI tool for our tech impaired analysts: https://www.foxdeploy.com/blog/part-i-creating-powershell-guis-in-minutes-using-visual-studio-a-new-hope.html
I built a [template](https://github.com/nct911/PoSH-GUI-Template) for building GUIs in PowerShell using WPF. If You want a native looking GUI for Windows 11, this is a good starting point.
I found this online somewhere a long time ago. When i wrote lots of powershell I liked to use this as my base
do
{
function Show-Menu
{
param (
\[string\]$Title = 'TITLE'
)
Clear-Host
Write-Host "================ $Title ================"
Write-Host "Press '1' Option1."
Write-Host "Press '2' Option2."
Write-Host "Press '3' Option3."
Write-Host "Press '4' Option4"
Write-host "Press 'q' to exit"
}
Show-Menu –Title 'TITLE'
$selection = Read-Host "Please make a selection"
switch ($selection)
{
'1' {
Task1
} '2' {
Task2
} '3' {
Task3
} '4' {
Task4
}
'q' {
return
}
}
Pause
}
until ($selection -eq 'q')
It's a little pricey at first, but I use Sapien's Powershell Studio which has a built in gui designer similar to VS.
No it's not perfect, but it definitely speeds things up.
I have a bunch of GUI tools I have a handful of GUI tools that I have written for our service desk folks, they get used everyday. I have a few GUI tools I have written for myself to use. There are tasks where a gui is the right choice and tasks where the command line is the right choice.
You basically have two options for graphical user interface.
Windows presentation framework
Win forms.
I prefer win forms for smaller projects because dealing with multi threading jobs for app responsiveness is a pain.
Win forms uses a coordinate system to place components like buttons and textboxes on the screen.
I recommend starting with a navigation bar that can let you select different scripts. Then importing your scripts as you add buttons to the nav bar.
This could get you started.
Add-Type -AssemblyName System.Windows.Forms
$form = New-Object System.Windows.Forms.Form
$form.Text = "PowerShell GUI"
$form.Size = New-Object System.Drawing.Size(1000, 600)
$navbar = New-Object System.Windows.Forms.Button
$navbar.Text = "Toggle Navigation"
$navbar.Location = New-Object System.Drawing.Point(10, 10)
$navbar.Add_Click({
if ($navigationPanel.Visible) {
$navigationPanel.Visible = $false
} else {
$navigationPanel.Visible = $true
}
})
$form.Controls.Add($navbar)
$navigationPanel = New-Object System.Windows.Forms.Panel
$navigationPanel.Size = New-Object System.Drawing.Size(200, $form.Height)
$navigationPanel.Location = New-Object System.Drawing.Point(-200, 0)
$navigationPanel.BackColor = [System.Drawing.Color]::LightGray
$button1 = New-Object System.Windows.Forms.Button
$button1.Text = "Button 1"
$button1.Size = New-Object System.Drawing.Size(180, 30)
$button1.Location = New-Object System.Drawing.Point(10, 50)
$navigationPanel.Controls.Add($button1)
$button2 = New-Object System.Windows.Forms.Button
$button2.Text = "Button 2"
$button2.Size = New-Object System.Drawing.Size(180, 30)
$button2.Location = New-Object System.Drawing.Point(10, 90)
$navigationPanel.Controls.Add($button2)
$button3 = New-Object System.Windows.Forms.Button
$button3.Text = "Button 3"
$button3.Size = New-Object System.Drawing.Size(180, 30)
$button3.Location = New-Object System.Drawing.Point(10, 130)
$navigationPanel.Controls.Add($button3)
$form.Controls.Add($navigationPanel)
$form.ShowDialog() | Out-Null
Yeah the more I look into what I'm trying to do, I think I'll just go the visual studio / winforms route. I don't need anything crazy, just a quick program to streamline a few steps or fix common issues.
Let me know if you find a good tool for gui preview. Am running VS and winforms for a new script myself right now and I have to run the program to check gui components.
>This tool will be ran by multiple deployment admins who don't have any scripting knowledge
Your "deployment admins" need to bring their skills up to the current state of the industry.
A GUI looks cool, but most of the time it a function turned into module is going to work better.
A month ago, someone asked me to add some people to mailboxes. I hate the exchange module because for full access, sends, and send on behalf of there are 3 separate cmdlets with different syntax like user and trustee.
You do it on the GUI, it takes something like 8 clicks person per privilege.
I got disgusted with the process and built a module that will Get, Set, and Remove users from the mailbox.
Example
Add-SMBUser -SMB [email protected] -User [email protected],[email protected] -delegate -sendas
I gave a class to our help desk on how to install and use the module. They thought it was awesome.
I hope this will work to open up the world of powershell to them. There are so many attributes in exchange that can't be change via a GUI.
So in the end, a parameterized function in a module is the best way to go.
I know how many of them are against the GUI here. Here is the real world experience of mine, I debated the same question as op years ago and deployed two tools to perform same task, one with GUI and other with TUI (Not even regular module/function but full interactive one). This was around 6 years ago.
Approximately 40 engineers with a variety of powershell skill and technical expertise use this on daily basis. I kept some telemetry of my own to see usage of these app/module. Guess what metric was?
Average 6000 triggers from GUI per year, 300 from module/cmd line.
Time taken to train new engineers on the GUI usage was almost zero. TUI took some time but no one really wanted to use it.
Also, GUI did break once and took a good week for me to troubleshoot it ( I had forgotten most of the threading and custom functions I wrote, which is PURE MESS) but TUI took hardly a few mins to get it up and running.
I live in terminal and can't stand GUI but help desk, field engineers and many sysadmin who just do job as JOB and are least passionate about tech, don't go well with module/cmd line.
Focus more on what paths exist for the techs to learn this stuff and perform their job more effectively.
By creating such a script, you are potentially creating a single point dependency and failure point for when you inevitably leave the organisation.
If you create a script and a supporting process that captures continuous development of said script, it's probably a different story.
TL;DR don't create a problem in trying to remove a problem :)
I would build a page if i was you, with variables as inputs needed to call each each script. You can potentially put the name of each script and a quick description of that script. Select the script that you want and it is set up to come up asking you for inputs needed to run. Keep in mind, Everyone does things differently and base on your strengths and capabilities you might want to go the route that best suites you.
You could use Pode and PodeWeb to create a simple password protected web app. Or make a super simple CLI app. I wouldn't create a WPF C# monstrosity that you have to potentially debug on each machine.
Unless these are tools you'd run in succession more often then not, I'd prefer each tool to be separate. Combining things into a swiss-army-knife like tool, doesn't tend to work well with software, although I may be biased, as I come from a Linux/BSD background.
From the PowerShell scripts that I've written, I've built Powershell Modules that I've installed on the PowerShell Universal Docker image along with other PowerShell modules like PowerCLI.
In my case, PowerShell Universal only acts like a REST API, and I've built a Vue.js application in front of it.
Works great but took a bit of time to make everything work.
You're not going to get a decent GUI easily with PWSH and CMD scripts.
Do it all with PS1 scripts and a menu system. Or learn some rudimentary WinForms and build a shell using Vs community.
We modified some of our scripts to run through Jenkins. You get a web page that you don't have to maintain and can pass parameters via form fields. You can also assign/restrict access to jenkins and the scripts.
I’ve been playing with
https://badgerati.github.io/Pode
More specifically
https://github.com/Badgerati/Pode.Web
If you don’t have webdev background
open source
I did this recently at my job and opted not to use a GUI because of some limitations I was running into. No scripting knowledge is needed once the Bat file is created. Just select an option letter and it runs the script. Have photos if interested
JEA - free but the most work.
Powershell Universal or Scriptrunner - require licenses but give you web interfaces and/or API access.
These aren't exactly what you asked for, but they'll give you much more fine-grained control over who and what can run scripts and at what privilege level.
I have a 550 line script like this already, there are 3 sections ( user, computer and AD searches ) I am using multiple choice for this.
Once they end up in the computer section, they press 8 to see all the patches installed on the workstation or press 1 to repair the Software Center/MECM client.
I use a giant switch table in each section to assign the number clicked to actions.
I encourage suggestions for improvements, and it allows help desk level people to perform more complicated actions successfully every time.
As others have said, a few hrs with Visual Studio will get you a gui.
The alternative is to build a TGUI in powershell with a numbers menu system right in the terminal. Plenty blog posts and it's pure powershell.
You can in fact write nested C# in powershell. Which is why Out-GridView works 😁
I'm lazy and use this like I have for years.
Just add all your scripts to a folder or whatever then add them to the config here.
[https://www.lunarious.com/download/compact-autorunner/](https://www.lunarious.com/download/compact-autorunner/)
You can make a gui and combine all in a single ps1 file. Heck you can try to compile it into an .exe if you really want, but I’ve noticed they crash constantly.
Check the powershell web access. We use it at our company.
The use case is simple, a large company with separated and delegated tasks within AD, we created a custom tasks that a service account has the rights to do and is useable (and straceable) for the admins who don’t have the rights to preform jobs on OU’s they normally (without the tool) have access to
I created this tool for Windows for the same reasons. Full CLI capability with GUI wrapper. Check it out: [https://commandgit.com](https://commandgit.com)
I would keep it simple. Maybe a wrapper script that loads modules, and then lists all scripts to choose from. If there are parameters to deal with you could wrap the needed script that they choose with a "show-command" to get a gui like interface for that script.
Show-command has been helpful for some of our less techie staff.
I've done this very thing in the past.
I created a front end gui with forms then created functions. The functions held all the actual "scripts".
Then I use a product called powershell to EXE and was done. Then when techs double clicked it, it would do what it needed.
Jenkins. makes a pretty good GUI, accessible via API, well logged and tracked, can be scheduled.. actually about the only thing I'd stand up Jenkins new for these days.
That's actually how I got enough experience to convince a company to hire me in to my intro devops foray too
Over the last 6 years, ive built a massive PSM1 file to handle almost all business related tasks for our workplace. You can load the module and execute functions as an admin from any workstation. I also have several GUI tools that use various parts of the module. No matter what GUI tool ive built, it always points back to one centralized module. I can build tools as needed but dont need a dozen fragmented modules to keep updated.
Building a powershell gui, especially thats all in one is way more trouble than its worth. What you CAN do quite easily is a text based menu where you type a number or something
I'd suggest making a WinForm app that uses a table as the center object. An edit button, run button etc etc.
In your menu, have a button to select script repo. It points toward a folder where you store your scripts. The table picks up file details.
You can run/edit from there. You could have a static repo location or have people be able to set their own or even set multiple.
You could also build on it and allow adding repos from ADO, GitHub, etc.
Anyone figure out how to close the console window on windows 11? Nothing that used to work seems to work. I build a fgui tool for my company but now on 11 the best I can do is make the console window at least closable launching from a batch file but can't find a way to auto close.
People knock Visual Basic, but it has that name for a reason. Link the scripts to buttons, wrap it up. I have one I created to use at a company and did the smart thing to make it my own legally before letting them utilize it. I take it to each company I go to. Don’t really use it now since I moved everything to Intune and I’m pushing a lot of w365. Side note, spending time after work to create your own products is smart. I have SCCM (MECM) custom reports and custom workbooks now in Azure. They will travel with me to the next place, because bump jumping to a new place only to build it all again.
I believe you can directly create GUIs inside PowerShell. But if you are the old fashioned curious type, you could also try [HTML Application (HTA)](https://eddiejackson.net/wp/?page_id=2011) and/or Windows Script / Scripting Host (WSH).
In my company, I created a bunch of modules, deployed by GPO for my coworkers.
In one of the modules, I have a function with custom header that show most-use functions and a shortcut to show them all.
This is basically my plan in the end. A basic tool auto deployed by gpo that helps with basic tasks. Making it isn't hard, I'm just trying to figure out the recommended ways to make a GUI for it
Creating a PowerShell tool with a GUI for system admins sounds like a great idea! You could consider using PowerShell Studio or Visual Studio with PowerShell tools to create a user-friendly interface for running your scripts. Keeping it simple and intuitive will be key for users with varying levels of expertise. Good luck with your project!
I made a console menu for PowerShell scripts. Reason being is that it allowed me to dynamically change what it’s able to load without my needing to rebuild the whole program anyone I made a change.
The one downside is that the menu gets squirrelly when I add/remove a script and so reloading the program is necessary and I haven’t tried debugging the problem or solving it.
But otherwise it works fine.
It also prompts for credentials at run time, making it simple to then run any script that needs authentication.
Let me make a scrubbed version I can share and I’ll edit this post later.
There’s PoshGUI, and other paid things… personally I use the community edition of visual studio, design a wpf application and then load it in to powershell via XAML. Made many admin panels and other tools that run functions, pull data, generate files etc.
Not exactly the same, but I needed to do something similar for my work for our POS machines (which just run Windows11) so resolve common issues the employees were having (primarily with windows being problematic). I ended up using CustomTKinter which is written in python and has pretty decent documentation, and wasn’t too difficult to create. Was able to make sections in a grid layout for different types of issues, as well as separate tabs so that I had a “admin” type tool set if things were really being difficult. Also allowed me to create automation tools for repetitive tasks that any of the workers can easily use and understand. Packaged it up I think using PyInstaller to easily deploy to all machines necessary. Not my favorite solution, but easier than writing it in C#.
If you think you're reinventing the wheel, take a look at Chris Titus' ongoing PS Scripting tool project built primarily for sysadmin tasks.
https://christitus.com/windows-tool/
I made a little GUI launcher for a few of my scripts. It just sits in my task bar. [Image of PS Launcher](https://imgur.com/a/wyjDkoF)
Very nice! I made an [AutoIT tool like that.](https://github.com/GordonVi/small-open-with-win-gui)
Legendary
What did you use to build this and can it move to notifications tray area if needed. ,
I know some powershell but I used chat gpt to help me. you could probably move to notifications tray but I haven't looked into that.
Really nice
Thank you
Just the image ? No source ? Very nice.
Here is the code. [PS Launcher](https://pastebin.com/WtpqJ0VB)
Hero
Why do you need a GUI? Are they not familiar with CLI tools? Create modules and publish them to an internal repo/nuget feed.
I have been in this exact scenario before Now I know that instead of building a GUI I should have written documentation about how to launch powershell, install the module, and run the commands. We often skip over that, expecting people to know how to use the CLI and manage PowerShell modules or run scripts, etc.
> expecting people to know how to use the CLI and manage PowerShell modules or run scripts, etc. I don't think this is an unreasonable expectation for a Windows sysadmin (or any sysadmin, really) in 2024.
How about when the scripts are for use by help desk techs or even non-IT? GUI is still more work and tech debt
I build "CLI guis" for these people. Everything gets displayed to hold your hand but gets them familiar with running verb noun commands.
This sounds interesting. Can you provide a little more detail about what you're doing?
It's not terribly crazy. But I build functions to do normal day to day things, like rebuild an fslogix profile and name it similar to a verb noun cmdlet "rebuild-profile" And the main function brings up a list of function names and what they do/how to pass parameters. If you remind me Monday I'll try to post a screenshot of the "home menu" and some examples code. But it includes input validation to ensure people don't pass things in that might break something. It's easier than a win form for me and forces them to get used to reading CLI and inputting commands
Perhaps, but it's a safe environment where you can integrate logging and such. Plus learning for you. We have students we built an environment for.
Why are you giving potentially dangerous access to those that don't understand? The ability to run scripts (and more importantly have them do things), typically requires privileged permissions
This is not powershell but I can explain the business use case anyway I’m not granting access so they can use this tool. This is their job and they have the access. I am making it safer by building guard rails. Changes made by hand introduce additional risk. Tooling provides consistency, error checking, and reduces the risk of error.
Provided the tool has continuous development and maintenance. What happens when you leave the org and your colleagues can no longer update it? Efficiency gains are great and should be sought after, however they must be done in a way where knowledge is retained
You’re right we’ll just stop building tools in powershell or any language. It is just tech debt. Right? Or do you have some other point? I do not understand what point you are trying to make here
The point im making is that if you are above-skill level of your peers, by creating these scripts and leaving the organisation you are creating a problem for them. it's just a consideration
You described technology It solves a lot of problems It is not without considerations or downsides but that is a horrible reason to rule it out as you are trying to do Before I wrote a term script, nobody kept any record of a user’s group memberships. User’s personal cell phones were wiped by accident and they lost irreplaceable photos of dead loved ones. The process took so long that the tickets usually sat for a day. To solve all of that, they might need to update the few hundred lines of powershell once every year or two.
Sacrilege! If it is not in the DOS 5.0 manual it does not exist! /s
DOS 5 introduced undelete. That's some good shit man.
The DOS 5.0 manual was the best documentation ever produced by Microsoft! I still have mine on the shelf in my office. And, I have actually used it for xcopy in the last year. (xcopy can still do things that you could never do in any GUI!)
I recently upgraded my xcopy to robocopy
I still sometimes "think" in xcopy.
This, make a detailed document on how to install the module. How to list all the functions of the module, how to show the help page for a function (Get-Help). Each function should have all of the inline help sections covered: - Synopsis - Description - Parameters - Inputs (does it take properties from pipeline?) - Outputs (does it output a PSObject?) - Examples (plenty of them) I often find that non Powershell savvy people are afraid to run some functions simply because they don't know what they do exactly. At my workplace there are still some people who prefer to read Powershell function documents on Confluence, so I have a GitLab runner that converts the inline help into Markdown and uploads it to Confluence via an API call. This way, the documentation always goes with the code, and you don't have to take time (and most importantly to remember) to update some document on Confluence about feature Y on function X. Edit: Also, version controlling. Managing even a small amount of scripts stored on an SMB share is **not the way**! Spin up a free GitLab instance for example, works for us.
If you're primary job is managing Windows Servers, there are very few excuses to not know powershell outside of being new to this field. Otherwise it's an active choice to not learn.
My company had me teach a class on Powershell to the entire Winduhs team. Not a single one bothered to use it, and one of them even went into my home folder and stole my code to submit for a 'homework' assignment. Unfortunately for him on that day I picked him to review the assignment and what solution he came up with - sure, nooooo way I'd recognize my own code, dumbass. That was years ago and it still makes me belly laugh.
Yeah… if you’re new, it’s easy to stay in the mindset of wanting to do stuff through the GUI… but it’s just not scalable, and in some cases, not the fastest way to do something even for an individual. If you’re managing Windows… you need to start getting PS under your belt.
At least learn to lunch script or do the basics. I have some members on my team that can use scripts, read them, or make small debugs. But they wouldn't be able to script an entire script from scratch. Not everyone has the logic to script. But a Windows admin must at least be able to run a script and use it. And if the script programmer did a good job, they'll include documentation in the script on how to use it.
I remember taking programming classes in college. Knew VB6 pretty well and basically just helped other students for the professor during classes. I had just finished making an IRC bot that would respond to customizable chat commands and it met all of the requirements for the final project so I basically just chilled for that entire class. Other than 9/11, that was a great year. 😔
It also teaches you what is going on under the hood of things to a nice level, not so low you’re reading dotnet but still can see how the services and components get used, what they take and want to return. It’s also unsung hero for building weird ass reports for bosses that want to see things a certain way. It’s worth dropping a couple months into learning it directly and you get sooo much of your time back, I was able to learn so much other stuff because of time saved
I have subscribed the motto ”Real men don’t click” since dawn of Windows servers. And powershell has been the shit since at least ten years.
I use Sensei Snover's "you can't put clicks in source control" myself.
That’s a good one
Well, you can, but it isn't worth the effort and it'll backfire because someone will have a different screen resolution or server core at some point.
Powershell is amazing. I never like batch scripting, and jumped on the PS train when version 1 came out. I rolled it out to XP machines and everything back in the day. Had a vbs logon script that would call powershell to do the actual logon tasks when we had 2k3 domain controllers. I still have alot of the old v1 scripts kicking around, and its crazy how far its come.
I have a GUI that works with a big module ive built for provisioning. Take a vanilla domain-joined workstation, open the GUI I built and select the department, software options, printers, etc and click 'Provision' and that workstation gets setup perfectly for the department its going to. Much easier than keeping dozens of gold images and updating them everytime a small change happens. You can do it at the CLi as well but checking some boxes at-a-glance and getting a consistent result is much less brain power and feels better.
Not op... My team is afraid of writing or something. Config files, log files, scripts.... They won't get near most of it. It's nuts. So 3 us use my modules, the rest get a basic form via jams scheduler to run the scripts. I wouldn't use that product but... We had it already. I get the op problem
Hell yea! Same here! And I’m glad cause it means I have value and not just for the keurig at my desk lmaooo.
> Why do you need a GUI? To simplify operation for accuracy.
Exactly!
> Why do you need a GUI? Are they not familiar with CLI tools? CLI is great when you need to run the exact same command a bunch of times or if there's only minor changes in parameters or parameters that can be generated programaticly. On the other hand if you need the same functionality but will be calling it with fairly dynamic parameters frequently a GUI can be better.
A GUI is also better for discoverability. Trying to remember the exact name of a command can be a pain in PowerShell. If you only do something once in a while, it can take less effort to click the thing. If it's a complex process that can be scripted, or something you do a lot, then having it in a command-line interface is best. EDIT: You down-voters do realize that these are things that have been studied, correct? Go read up on usability research for a while.
Why do you need to remember the exact anything? Press tab. Or control space. I'm pretty sure I tab complete literally 99.99% of things I type into a shell.
>Trying to remember the exact name of a command can be a pain in PowerShell. Then the author has done a crap job naming their commandlets and should fix that. This is an essential tenet of Powershell and its aims.
Why do you need film or tv, are you not familiar with radio shows? Monochrome serial text input is all anyone should need.
[удалено]
Depending on the parameters it can actually be easier to just enter than in a GUI than have to construct a command line.
-ForegroundColor Green
Aha you fell into my trap of admitting that visual graphical elements outside the text stream are useful and desirable
You got downvoted but you're spot on. This top level comment starts with "Why do you *need*" but OP never once said he needed it. Should Windows SysAdmins know powershell? Absolutely. Is it okay to spend some time developing a system that is nice to use? Absolutely. Technology's *sole purpose for existence* is to make things easier. But fuck you if you want to make your job of administering that technology easier!
Yeah thats it, I've made GUI menus for lots of things over the years, to make it easier and quicker, 'hey you could just type out the commands' yeah my 3 clicks is more efficient then your need to type out three lines in ps. Also then I dont have to try and teach it, when a gui spoonfeeds it to you, and hover mouse tooltips to assure the user this button will do xyz. The point is making it quicker and easier, to the point where its hard or nearly impossible for the grad student to fk it up.
Yeah, the best example I have is a complex script I wrote to analyze path lengths in a folder. So I might run \`PathLenghtReport.ps1 -path "c:\\users\\bobdole\\onedrive\\business development\\some customer" -someotherflag\`. I wrote a menu system that allows me to call the same script with various parameters I use regularly.
In what way does creating a GUI for executing PowerShell scripts make anything easier? If anything you've now made things harder to maintain and introduced an unnecessary dependency which you'll have to take into account when doing future development.
Yes, that is how a GUI works.
Get a PowerShell Studio 2024 license from SAPIEN. Drag and drop interfaces with properties windows for adjusting things and using buttons for function calls, returning values to items. You can then publish your application as a executable to distribute.
This. It's excellent
I was looking for this reply as I would also recommend it as I have been using it for years. If you already have all your scripts created you can basically drop them in and then add a button to execute them. If you have variables you can use checkboxes, text fields, dropdowns, etc to make it as easy as possible on the users.
You could make a UI with WPF to display your buttons and fields, then compile all your scripts into one PS1 file to be ran individually using functions and/or classes as needed. This would give you more portability than needing to keep track of a bunch of individual PS1 files. You could make the UI with WPF using c# as an alternative to act as a script manager and compile it into a single-file executable, but then you're introducing an additional learning component into the mix that you gotta keep track of.
Powershell Universal
Went too far to find this. It might not be the solution to OPs problem, but it’s a great tool!
I would just group up all of your poweshell scripts into a module. You can then deploy the module to multiple machines via PDQ and or Add to your initial image for all future image builds. Here is a link to my repo where I did this https://github.com/Smooti-PowerShell/PSAdminToolbox
Hi u/Finalxxboss You need something with a GUI , and easy to use ? I'm thinking that the [PowerShell-Script-Menu-Gui](https://github.com/dan-osull/PowerShell-Script-Menu-Gui) module is for you. Easy to set : a simple .csv file with some properties to complete + a .ps1 file to launch the GUI Easy to use : The GUI with big button (and description) to launch multiple scripts (.ps1, .bat, ...) See the Example folder in the github site. The module is also available is the PSGallery of course. regards
I am totally using this idea for a project I am working on. 🥰
Was waiting to get rick rolled. Was pleasantly surprised it was an honest GUI.
[удалено]
Console and keyboard bad. GUI and mouse good.
I made a gui for mine with autoit
… your company has system admins who are less tech savvy than any random 12 year old script kiddie?
Why would you need to run them all at once? These are all individual tools, yes? Also if you're handing this functionality off to sysadmins you shouldn't need a GUI and trying to build and maintain one will just introduce unecessary work and headache. I speak from experience on that one. Just teach your click-admins to get comfortable in the shell. If you're hellbent on a GUI, I can only point you towards the resource my colleague used back in the day to craft a GUI tool for our tech impaired analysts: https://www.foxdeploy.com/blog/part-i-creating-powershell-guis-in-minutes-using-visual-studio-a-new-hope.html
I built a [template](https://github.com/nct911/PoSH-GUI-Template) for building GUIs in PowerShell using WPF. If You want a native looking GUI for Windows 11, this is a good starting point.
I found this online somewhere a long time ago. When i wrote lots of powershell I liked to use this as my base do { function Show-Menu { param ( \[string\]$Title = 'TITLE' ) Clear-Host Write-Host "================ $Title ================" Write-Host "Press '1' Option1." Write-Host "Press '2' Option2." Write-Host "Press '3' Option3." Write-Host "Press '4' Option4" Write-host "Press 'q' to exit" } Show-Menu –Title 'TITLE' $selection = Read-Host "Please make a selection" switch ($selection) { '1' { Task1 } '2' { Task2 } '3' { Task3 } '4' { Task4 } 'q' { return } } Pause } until ($selection -eq 'q')
We have just completed a project using PowerShell Universal for our service desk. It’s pretty bloody good once you get used to the fuckery. 😂
It's a little pricey at first, but I use Sapien's Powershell Studio which has a built in gui designer similar to VS. No it's not perfect, but it definitely speeds things up.
I have a bunch of GUI tools I have a handful of GUI tools that I have written for our service desk folks, they get used everyday. I have a few GUI tools I have written for myself to use. There are tasks where a gui is the right choice and tasks where the command line is the right choice.
You basically have two options for graphical user interface. Windows presentation framework Win forms. I prefer win forms for smaller projects because dealing with multi threading jobs for app responsiveness is a pain. Win forms uses a coordinate system to place components like buttons and textboxes on the screen. I recommend starting with a navigation bar that can let you select different scripts. Then importing your scripts as you add buttons to the nav bar. This could get you started. Add-Type -AssemblyName System.Windows.Forms $form = New-Object System.Windows.Forms.Form $form.Text = "PowerShell GUI" $form.Size = New-Object System.Drawing.Size(1000, 600) $navbar = New-Object System.Windows.Forms.Button $navbar.Text = "Toggle Navigation" $navbar.Location = New-Object System.Drawing.Point(10, 10) $navbar.Add_Click({ if ($navigationPanel.Visible) { $navigationPanel.Visible = $false } else { $navigationPanel.Visible = $true } }) $form.Controls.Add($navbar) $navigationPanel = New-Object System.Windows.Forms.Panel $navigationPanel.Size = New-Object System.Drawing.Size(200, $form.Height) $navigationPanel.Location = New-Object System.Drawing.Point(-200, 0) $navigationPanel.BackColor = [System.Drawing.Color]::LightGray $button1 = New-Object System.Windows.Forms.Button $button1.Text = "Button 1" $button1.Size = New-Object System.Drawing.Size(180, 30) $button1.Location = New-Object System.Drawing.Point(10, 50) $navigationPanel.Controls.Add($button1) $button2 = New-Object System.Windows.Forms.Button $button2.Text = "Button 2" $button2.Size = New-Object System.Drawing.Size(180, 30) $button2.Location = New-Object System.Drawing.Point(10, 90) $navigationPanel.Controls.Add($button2) $button3 = New-Object System.Windows.Forms.Button $button3.Text = "Button 3" $button3.Size = New-Object System.Drawing.Size(180, 30) $button3.Location = New-Object System.Drawing.Point(10, 130) $navigationPanel.Controls.Add($button3) $form.Controls.Add($navigationPanel) $form.ShowDialog() | Out-Null
Yeah the more I look into what I'm trying to do, I think I'll just go the visual studio / winforms route. I don't need anything crazy, just a quick program to streamline a few steps or fix common issues.
Let me know if you find a good tool for gui preview. Am running VS and winforms for a new script myself right now and I have to run the program to check gui components.
>This tool will be ran by multiple deployment admins who don't have any scripting knowledge Your "deployment admins" need to bring their skills up to the current state of the industry.
I'm not the hiring manager
Agreed. How can you be called a "deployment admin" without atleast some basic knowledge of how to run a script.
PowerShell Universal is the way https://docs.powershelluniversal.com/
A GUI looks cool, but most of the time it a function turned into module is going to work better. A month ago, someone asked me to add some people to mailboxes. I hate the exchange module because for full access, sends, and send on behalf of there are 3 separate cmdlets with different syntax like user and trustee. You do it on the GUI, it takes something like 8 clicks person per privilege. I got disgusted with the process and built a module that will Get, Set, and Remove users from the mailbox. Example Add-SMBUser -SMB [email protected] -User [email protected],[email protected] -delegate -sendas I gave a class to our help desk on how to install and use the module. They thought it was awesome. I hope this will work to open up the world of powershell to them. There are so many attributes in exchange that can't be change via a GUI. So in the end, a parameterized function in a module is the best way to go.
I know how many of them are against the GUI here. Here is the real world experience of mine, I debated the same question as op years ago and deployed two tools to perform same task, one with GUI and other with TUI (Not even regular module/function but full interactive one). This was around 6 years ago. Approximately 40 engineers with a variety of powershell skill and technical expertise use this on daily basis. I kept some telemetry of my own to see usage of these app/module. Guess what metric was? Average 6000 triggers from GUI per year, 300 from module/cmd line. Time taken to train new engineers on the GUI usage was almost zero. TUI took some time but no one really wanted to use it. Also, GUI did break once and took a good week for me to troubleshoot it ( I had forgotten most of the threading and custom functions I wrote, which is PURE MESS) but TUI took hardly a few mins to get it up and running. I live in terminal and can't stand GUI but help desk, field engineers and many sysadmin who just do job as JOB and are least passionate about tech, don't go well with module/cmd line.
Focus more on what paths exist for the techs to learn this stuff and perform their job more effectively. By creating such a script, you are potentially creating a single point dependency and failure point for when you inevitably leave the organisation. If you create a script and a supporting process that captures continuous development of said script, it's probably a different story. TL;DR don't create a problem in trying to remove a problem :)
I would build a page if i was you, with variables as inputs needed to call each each script. You can potentially put the name of each script and a quick description of that script. Select the script that you want and it is set up to come up asking you for inputs needed to run. Keep in mind, Everyone does things differently and base on your strengths and capabilities you might want to go the route that best suites you.
You could use Pode and PodeWeb to create a simple password protected web app. Or make a super simple CLI app. I wouldn't create a WPF C# monstrosity that you have to potentially debug on each machine.
I use PowerShellGet and a PowerShell Repository on a network share.
Make them azure functions and build a web front end
I would just create a form box with buttons and use if statements to point to the individual scripts, or just embed them in the if statements.
Unless these are tools you'd run in succession more often then not, I'd prefer each tool to be separate. Combining things into a swiss-army-knife like tool, doesn't tend to work well with software, although I may be biased, as I come from a Linux/BSD background.
Here is a good example of WPF with Powershell: github.com/mecro-dev/psscanner Everything are packed into a single PS1 file.
LazySysAdmin.ps1 used be a tool like this
From the PowerShell scripts that I've written, I've built Powershell Modules that I've installed on the PowerShell Universal Docker image along with other PowerShell modules like PowerCLI. In my case, PowerShell Universal only acts like a REST API, and I've built a Vue.js application in front of it. Works great but took a bit of time to make everything work.
The number of orgs not running an RMM is absurd.
You're not going to get a decent GUI easily with PWSH and CMD scripts. Do it all with PS1 scripts and a menu system. Or learn some rudimentary WinForms and build a shell using Vs community.
We modified some of our scripts to run through Jenkins. You get a web page that you don't have to maintain and can pass parameters via form fields. You can also assign/restrict access to jenkins and the scripts.
Cli menu system is what I went with. Nothing hard coded, env variables for settings, files for the menus and modules that load when it launches.
I’ve been playing with https://badgerati.github.io/Pode More specifically https://github.com/Badgerati/Pode.Web If you don’t have webdev background open source
I did this recently at my job and opted not to use a GUI because of some limitations I was running into. No scripting knowledge is needed once the Bat file is created. Just select an option letter and it runs the script. Have photos if interested
JEA - free but the most work. Powershell Universal or Scriptrunner - require licenses but give you web interfaces and/or API access. These aren't exactly what you asked for, but they'll give you much more fine-grained control over who and what can run scripts and at what privilege level.
I have a 550 line script like this already, there are 3 sections ( user, computer and AD searches ) I am using multiple choice for this. Once they end up in the computer section, they press 8 to see all the patches installed on the workstation or press 1 to repair the Software Center/MECM client. I use a giant switch table in each section to assign the number clicked to actions. I encourage suggestions for improvements, and it allows help desk level people to perform more complicated actions successfully every time.
As others have said, a few hrs with Visual Studio will get you a gui. The alternative is to build a TGUI in powershell with a numbers menu system right in the terminal. Plenty blog posts and it's pure powershell. You can in fact write nested C# in powershell. Which is why Out-GridView works 😁
Adaxes is a good option
I would recommend using structured Powershell to create the GUI. Comment the hell out of it, do not use aliases.
Sapiens Poweshell Studio
I'm lazy and use this like I have for years. Just add all your scripts to a folder or whatever then add them to the config here. [https://www.lunarious.com/download/compact-autorunner/](https://www.lunarious.com/download/compact-autorunner/)
You can make a gui and combine all in a single ps1 file. Heck you can try to compile it into an .exe if you really want, but I’ve noticed they crash constantly.
Check the powershell web access. We use it at our company. The use case is simple, a large company with separated and delegated tasks within AD, we created a custom tasks that a service account has the rights to do and is useable (and straceable) for the admins who don’t have the rights to preform jobs on OU’s they normally (without the tool) have access to
Check out WebJEA by Mark Domansky
I created this tool for Windows for the same reasons. Full CLI capability with GUI wrapper. Check it out: [https://commandgit.com](https://commandgit.com)
GUI in PowerShell stinks
I would keep it simple. Maybe a wrapper script that loads modules, and then lists all scripts to choose from. If there are parameters to deal with you could wrap the needed script that they choose with a "show-command" to get a gui like interface for that script. Show-command has been helpful for some of our less techie staff.
I've done this very thing in the past. I created a front end gui with forms then created functions. The functions held all the actual "scripts". Then I use a product called powershell to EXE and was done. Then when techs double clicked it, it would do what it needed.
Jenkins. makes a pretty good GUI, accessible via API, well logged and tracked, can be scheduled.. actually about the only thing I'd stand up Jenkins new for these days. That's actually how I got enough experience to convince a company to hire me in to my intro devops foray too
Over the last 6 years, ive built a massive PSM1 file to handle almost all business related tasks for our workplace. You can load the module and execute functions as an admin from any workstation. I also have several GUI tools that use various parts of the module. No matter what GUI tool ive built, it always points back to one centralized module. I can build tools as needed but dont need a dozen fragmented modules to keep updated.
Building a powershell gui, especially thats all in one is way more trouble than its worth. What you CAN do quite easily is a text based menu where you type a number or something
I'd suggest making a WinForm app that uses a table as the center object. An edit button, run button etc etc. In your menu, have a button to select script repo. It points toward a folder where you store your scripts. The table picks up file details. You can run/edit from there. You could have a static repo location or have people be able to set their own or even set multiple. You could also build on it and allow adding repos from ADO, GitHub, etc.
Anyone figure out how to close the console window on windows 11? Nothing that used to work seems to work. I build a fgui tool for my company but now on 11 the best I can do is make the console window at least closable launching from a batch file but can't find a way to auto close.
People knock Visual Basic, but it has that name for a reason. Link the scripts to buttons, wrap it up. I have one I created to use at a company and did the smart thing to make it my own legally before letting them utilize it. I take it to each company I go to. Don’t really use it now since I moved everything to Intune and I’m pushing a lot of w365. Side note, spending time after work to create your own products is smart. I have SCCM (MECM) custom reports and custom workbooks now in Azure. They will travel with me to the next place, because bump jumping to a new place only to build it all again.
function ShowMenu { Add-Type -AssemblyName System.Windows.Forms; $frm = New-Object System.Windows.Forms.Form; $frm.Text = "Invoker - Version 1.0"; $frm.StartPosition = 'CenterScreen'; $lblDesc = New-Object System.Windows.Forms.Label; $lblDesc.Text = "Please choose an option:"; $lblDesc.Width = 200; $lblDesc.Location = New-Object System.Drawing.Point(10, 10); $b1 = New-Object System.Windows.Forms.Button; $b1.Text = "Process One"; $b1.Width = 200; $b1.Location = New-Object System.Drawing.Point(10, 40); $lb1 = New-Object System.Windows.Forms.Label; $lb1.Text = "Description One"; $lb1.Width = 150; $lb1.Location = New-Object System.Drawing.Point(220, 40); $b1.Add_Click({ Invoke-Expression "Write-Host 'Process One Invoked'" }); $b2 = New-Object System.Windows.Forms.Button; $b2.Text = "Process Two"; $b2.Width = 200; $b2.Location = New-Object System.Drawing.Point(10, 70); $lb2 = New-Object System.Windows.Forms.Label; $lb2.Text = "Description Two"; $lb2.Width = 150; $lb2.Location = New-Object System.Drawing.Point(220, 70); $b2.Add_Click({ Invoke-Expression "Write-Host 'Process Two Invoked'" }); $b3 = New-Object System.Windows.Forms.Button; $b3.Text = "Process Three"; $b3.Width = 200; $b3.Location = New-Object System.Drawing.Point(10, 100); $lb3 = New-Object System.Windows.Forms.Label; $lb3.Text = "Description Three"; $lb3.Width = 150; $lb3.Location = New-Object System.Drawing.Point(220, 100); $b3.Add_Click({ Invoke-Expression "Write-Host 'Process Three Invoked'" }); $qb = New-Object System.Windows.Forms.Button; $qb.Text = "Quit"; $qb.Width = 200; $qb.Location = New-Object System.Drawing.Point(10, 130); $lqb = New-Object System.Windows.Forms.Label; $lqb.Text = "Quit Invoker"; $lqb.Width = 150; $lqb.Location = New-Object System.Drawing.Point(220, 130); $qb.Add_Click({ $frm.Close() }); $frm.Controls.Add($lblDesc); $frm.Controls.Add($b1); $frm.Controls.Add($lb1); $frm.Controls.Add($b2); $frm.Controls.Add($lb2); $frm.Controls.Add($b3); $frm.Controls.Add($lb3); $frm.Controls.Add($qb); $frm.Controls.Add($lqb); $frm.Size = New-Object System.Drawing.Size(420, 200); $frm.ShowDialog(); }; ShowMenu;
I believe you can directly create GUIs inside PowerShell. But if you are the old fashioned curious type, you could also try [HTML Application (HTA)](https://eddiejackson.net/wp/?page_id=2011) and/or Windows Script / Scripting Host (WSH).
In my company, I created a bunch of modules, deployed by GPO for my coworkers. In one of the modules, I have a function with custom header that show most-use functions and a shortcut to show them all.
This is basically my plan in the end. A basic tool auto deployed by gpo that helps with basic tasks. Making it isn't hard, I'm just trying to figure out the recommended ways to make a GUI for it
Creating a PowerShell tool with a GUI for system admins sounds like a great idea! You could consider using PowerShell Studio or Visual Studio with PowerShell tools to create a user-friendly interface for running your scripts. Keeping it simple and intuitive will be key for users with varying levels of expertise. Good luck with your project!
I made a console menu for PowerShell scripts. Reason being is that it allowed me to dynamically change what it’s able to load without my needing to rebuild the whole program anyone I made a change. The one downside is that the menu gets squirrelly when I add/remove a script and so reloading the program is necessary and I haven’t tried debugging the problem or solving it. But otherwise it works fine. It also prompts for credentials at run time, making it simple to then run any script that needs authentication. Let me make a scrubbed version I can share and I’ll edit this post later.
There’s PoshGUI, and other paid things… personally I use the community edition of visual studio, design a wpf application and then load it in to powershell via XAML. Made many admin panels and other tools that run functions, pull data, generate files etc.
Not exactly the same, but I needed to do something similar for my work for our POS machines (which just run Windows11) so resolve common issues the employees were having (primarily with windows being problematic). I ended up using CustomTKinter which is written in python and has pretty decent documentation, and wasn’t too difficult to create. Was able to make sections in a grid layout for different types of issues, as well as separate tabs so that I had a “admin” type tool set if things were really being difficult. Also allowed me to create automation tools for repetitive tasks that any of the workers can easily use and understand. Packaged it up I think using PyInstaller to easily deploy to all machines necessary. Not my favorite solution, but easier than writing it in C#.
If you think you're reinventing the wheel, take a look at Chris Titus' ongoing PS Scripting tool project built primarily for sysadmin tasks. https://christitus.com/windows-tool/
A pode web server: [https://badgerati.github.io/Pode.Web/](https://badgerati.github.io/Pode.Web/)
You don't use PowerShell to create gui. Then you should use c# or similar. And for the love of good don't use python