Feature Request

[image] No column selector for the scripts view?

[image] I think it would be nice to see how large a specific cache item is in the DB. for example how large is your dataset for something like caching all ad user objects

Hi there, is it possible to update the button possibilities (Icon button) like MUI website? [image] best regards

The PowerShell Universal Windows service is installed without Windows Service Recovery Actions configured. If the service terminates unexpectedly, it may remain stopped until an administrator intervenes, even though the service startup type is set to Automatic. This was observed after planned Windows Update restarts. The PowerShell Universal service was stopped as part of the operating system shutdown and later reported by the Service Control Manager as having terminated unexpectedly. Because no recovery actions were configured, Windows did not attempt to start the service again. This could be prevented if the installer (for example" configures the following recovery actions by default when installing PowerShell Universal on Windows: First failure: restart the service after 60 seconds Second failure: restart the service after 60 seconds Subsequent failures: no action Reset the failure count after 24 hours Enable recovery actions for non-crash failures (FailureActionsOnNonCrashFailures = true) During an upgrade, an existing customer-defined recovery configuration must be preserved. If no recovery actions are configured, the installer should apply the default configuration above. Expected benefit This improves service availability after unexpected process termination and planned maintenance restarts, reducing the need for manual recovery.

Hi i will be nice if modules installed from galleries also is synced when running a HA Setup with multiple PSU Servers right now i need to ensure i gets on each PSU server and installing the modules because if i do it from the web interface its only works on the instance i was connected to at install. best regards Jacob

why cant we see variables of string type in the admin ui? [image] [image] Also items stored in the database as strings should show up when you are editing it rather than having a blank text box [image] [image]

Script documentation would be helpful only if we could switch between a view and edit mode in the Admin console. Currently, I don't believe there is any way to view it unless you use GitHub or copy and paste the md somewhere else. Preferably, have an option with split screen to have live view and edit as well.

Summary When using Git synchronization with separate branches for test and production environments, branch scoped resources that exist only in another branch are completely hidden from the UI. This prevents administrators from preparing or modifying those resources before promotion. I would like to request an enhancement so that branch scoped resources remain visible in all branches while respecting their execution scope. Current Setup Our environment uses PowerShell Universal Git synchronization with two separate instances: Test server → connected to the test branch Production server → connected to the main branch Changes are made only on the test system. Promotion to production is performed through a Git pull request from test to main. The production instance is configured with OneWay synchronization, ensuring that changes can only be made in the test environment. PowerShell Universal already allows assigning resources to specific branches so that they are only active in the intended branch. Problem Assume a Schedule is assigned exclusively to the main branch. Because this resource does not belong to the test branch, it is completely absent from the Test UI. As a result: The Schedule cannot be reviewed in the Test environment. Future changes cannot be prepared before promotion. Administrators must switch to the Production system to understand the current configuration. The Git based promotion workflow becomes inconsistent because some resources can only be managed in one environment. Proposed Enhancement Introduce a read only branch visibility mode for branch scoped resources. Behavior: Resources assigned to another branch should still be displayed in the UI. Such resources should be visually marked, for example: Greyed out Lock icon "Available in branch: main" indicator Resources should remain editable so that changes can be prepared and committed in the current branch. Runtime behavior must continue to respect branch assignment. For a Schedule this would mean: The Schedule is visible in the test branch. The Schedule does not execute in the test environment. The associated script is not started in the test environment. Administrators can still modify the Schedule configuration and submit the change through the existing Git workflow. Benefits Improved visibility across environments. Better support for Git based promotion workflows. Reduced need to switch between environments. Easier maintenance of production only resources. Consistent user experience across all resource types.

Description When starting a script using Invoke-PSUScript, it is possible to provide additional context via the -Notes parameter. These notes are displayed in the Job Overview and are very useful for tracking the origin and purpose of a job execution. However, the current Job Overview does not allow searching or filtering based on the contents of the Notes field. Use Case We frequently use PowerShell Universal as an execution backend for external systems. An external application invokes the PowerShell Universal API, which then starts a long-running script as a background job. In these scenarios, we often pass an external reference ID, ticket number, request ID, or correlation ID through the -Notes parameter. The information is visible in the job details, but it cannot be used to locate jobs later through the search functionality in the Jobs view. Problem As the number of jobs grows, it becomes difficult to find a specific job that belongs to a particular external request or transaction. Users must manually browse through jobs or implement alternative tracking mechanisms outside of PowerShell Universal. Proposed Enhancement Extend the Jobs search and filtering functionality to include the Notes field.

While playing around with the MCP Server, I really wish these things were possible: New Parameters for New-PSUAITool - Module and -Command like in Endpoints -Scriptblock {} to have the code inside the aitools.ps1 file. -Endpoint to use a endpoint instead of a script (Max wait time would need to be 60 or lower as a max) -ArchiveJobAfterCompletion to automatically archive the script run job log after completion or retrival, currently it creates a mess in the jobs table. New Cmdlet New-PSUAIToolResponse to add the "structured" element to the response via the mcp server. The Idea is more or less the same as the New-PSUApiResponse cmdlet. Currently the output looks like this: { "content": [ { "type": "text", "text": "Information - {\r\n \"GivenName\": \"XXXX\",\r\n \"Surname\": \"XXX\",\r\n \"UserPrincipalName\": \"XXXX@XXXXX.XX\",\r\n \"Enabled\": true,\r\n \"SamAccountName\": \"XXXXX\",\r\n \"SID\": {\r\n \"BinaryLength\": XX,\r\n \"AccountDomainSid\": \"MEH\",\r\n \"Value\": \"XXXXXXX\"\r\n },\r\n \"DistinguishedName\": \"Woo Hooo\",\r\n \"Name\": \"XXXXX\",\r\n \"ObjectClass\": \"user\",\r\n \"ObjectGuid\": \"GUID\",\r\n \"PropertyNames\": [\r\n \"DisplayName\",\r\n \"DistinguishedName\",\r\n \"Enabled\",\r\n \"GivenName\",\r\n \"mail\",\r\n \"Name\",\r\n \"ObjectClass\",\r\n \"ObjectGUID\",\r\n \"SamAccountName\",\r\n \"SID\",\r\n \"Surname\",\r\n \"UserPrincipalName\"\r\n ],\r\n \"AddedProperties\": [],\r\n \"RemovedProperties\": [],\r\n \"ModifiedProperties\": [],\r\n \"PropertyCount\": 12,\r\n \"DisplayName\": \"XXXXX XXXX\",\r\n \"mail\": \"XXXX@XXXX.XX\",\r\n \"ObjectGUID\": \"XXXXXXXX\"\r\n}" } ] } It's fine, but being able to return a structured element inside the "content" object, would help, this would also drastically help with not needing to convert to json before returning the result. A parameter to choose encoding could be nice, like formats like Markdown , XML , Json , Csv etc.

I've played with workflows some and have a decent grasp of $PSUItem and $Workflow. I haven't managed to get the "Deconstruct hashtable output" to anything that I can discern. Any chance you can add some documentation to show what that setting does?

# Dashboard-native binary downloads from buttons and forms ## Summary Please add a dashboard-native way to download arbitrary binary content from a button or form action without requiring the app developer to expose or navigate to a separate REST API URL. This is specifically needed for binary payloads such as PFX, PDF, MSG, ZIP, and image files that are generated or authorized inside a dashboard event handler. ## Problem Statement The current documented `Start-UDDownload` behavior supports `StringData`, `Path`, and `Url`, and the documentation explicitly frames it around text-file downloads. There is no documented `byte[]` or `Stream` parameter for direct binary downloads from a dashboard event. The documented binary-response path today is to create a PSU endpoint and return `New-PSUApiResponse -Data [byte[]]`. That works for APIs, but it does not solve the dashboard scenario cleanly because the app developer must introduce a separate URL surface and then route the user to it. ## Why This Blocks Secure Binary Attachment Downloads - Many dashboard flows generate or retrieve attachment bytes only after a button click or form submission. - In those flows, forcing a separate endpoint adds extra routing, auth handling, URL management, and lifecycle complexity. - Temp-file workarounds are risky because they introduce file-leakage and cleanup concerns. - URL or new-tab navigation is a poor fit for form-driven UX when the user simply clicked a button to download a file. - Some attachments must remain available only within the current authenticated dashboard interaction, not as a separately addressable endpoint. ## Desired User and Developer Experience When a user clicks a dashboard button or submits a form: - The browser download should start immediately from that action. - No visible navigation or extra tab should be required for normal use. - The exact source bytes must be preserved with no text conversion or encoding changes. - The developer must be able to set the filename and content type. - The download should run in the current dashboard auth and session context. - The feature should work for in-memory byte arrays and stream-backed content. ## Suggested API Shapes These are only suggestions, not strict design requirements. ### Option A: Extend `Start-UDDownload` ```powershell Start-UDDownload -Bytes $bytes -FileName 'certificate.pfx' -ContentType 'application/x-pkcs12' ``` ### Option B: Stream support ```powershell Start-UDDownload -Stream $stream -FileName 'report.pdf' -ContentType 'application/pdf' ``` ### Option C: Dashboard-native response object ```powershell New-UDDownloadResponse -Bytes $bytes -FileName 'message.msg' -ContentType 'application/vnd.ms-outlook' ``` Any equivalent dashboard-native abstraction would be acceptable if it avoids the need for a separate API URL. ## Security and Lifecycle Requirements - Respect existing dashboard authorization, roles, and session context. - Do not require developers to persist sensitive content to temp files for common cases. - If PSU must use temp storage internally, the files should be short-lived, isolated, and automatically cleaned up. - Dispose streams and related resources reliably. - Preserve browser download gesture requirements so popup blockers or cross-origin behaviors do not interfere unnecessarily. - Provide documented size limits or server-side safeguards for large payloads. - Prevent accidental binary corruption caused by string serialization, encoding conversion, or content-type mismatches. ## Acceptance Criteria - A dashboard button or form action can trigger a download from an in-memory `byte[]` payload. - The downloaded file matches the original bytes exactly. - The developer can specify filename and content type. - Standard use does not require a visible browser navigation or blank tab. - The feature uses the current dashboard auth context without requiring a separate custom endpoint. - Sensitive content does not leak through developer-managed temp files. - Failure cases surface a clear dashboard-side error instead of a silent no-op. - The supported size and lifecycle constraints are documented. ## Minimal Repro Example This example uses a placeholder `byte[]` PFX-like payload only to demonstrate the requested dashboard behavior. ```powershell New-UDButton -Text 'Download PFX' -OnClick { [byte[]]$pfxBytes = 0..255 Start-UDDownload ` -Bytes $pfxBytes ` -FileName 'example.pfx' ` -ContentType 'application/x-pkcs12' } ``` Current limitation: there is no documented dashboard-native way to do the above with exact binary bytes, so the developer must instead create a separate endpoint and return `New-PSUApiResponse -Data [byte[]]` from that route. ## Environment - PSU version: - PSU edition: - Hosting mode: - Browser: - Operating system: - Authentication mode: - Requested by: Copilot - Date: 2026-08-07 ## Not an API Bug This request is not claiming that PSU endpoint-based binary responses are broken. The enhancement request is for equivalent first-class support inside dashboard button and form interactions so developers do not have to expose or navigate to a separate API route just to download secure binary content.

Problem When adding a PSU MCP server in VS Code, the connection can be configured either by manually adding /api/v1/mcp to the mcp.json configuration or by using the extension's server connection feature, which automatically appends the endpoint. In both cases, the resulting MCP server connection is automatically named Universal.Server . As a consequence, multiple PSU MCP server connections appear with the same name, making it impossible to distinguish between them in the VS Code UI. Expected Behavior The displayed MCP server name should be configurable or automatically derived from the target server information. Possible approaches: Allow specifying a custom display name in the mcp.json configuration. Use the server hostname as the default connection name. Fall back to the current Universal.Server name only when no custom name or hostname is available. Current Behavior All PSU MCP server connections are displayed as Universal.Server, regardless of the configured endpoint or host. [image] Impact Users managing multiple PSU MCP server instances cannot easily identify which connection belongs to which environment (e.g. Development, Test, Production) or host, increasing the risk of connecting to the wrong server. Benefits Easier management of multiple MCP server connections Better usability and visibility within VS Code Reduced risk of connecting to the wrong environment Consistent behavior with other tools that support custom connection names [image]

Hi Adam, As discussed at PSConfEU :) Currently when you call a Script from an App with Invoke-PSUScript the called script gets shown in the Portal History even if the Users dont have access to the script. It would be nice to have an option to hide them there as we already hat some question why something is shown there. Thanks, Niko

A bit of a big ask, but would be a nice to have, not critical. Currently for API access a user either has to supply some credentials or an API token that has been pre-made ahead of time. But for OIDC based deployments only a pre-made API key is the only real option, which means you have to login to the admin ui, make the token (preferably short lived) and then put that back into your console securely. Instead for this, similar to how HashiCorp vault handles this, we're asking if Connect-PSUServer could activate a OIDC flow, whereby a flag like Connect-PSUServer -ComputerName ' https://some.psu.server.domain.com ' -OIDCMakeToken Could exist, that provides a browser link, the user goes to the browser link, goes through their OIDC flow configured in PSU and then lands at a consent screen in PSU asking for authorization to make a App Token for your current powershell session (limited by some short-lived expiry and tied to the user account that completed the flow). This in total will reduce the amount of screens an OIDC user has to go through to use the Universal module while utilizing as much of the current systems as I can think off to help with dev time. To take this a step further, this could also be tied to permissions, so that only certain users would be able to use the OIDC flow to quickly generate a App Token and/or it being a separate permission means that people can generate their own but not be permitted to control others app tokens or system app tokens because they wouldn't have access to the main app tokens area. Anyway, sorry, lots of words. The Tl;Dr: Have new flag on Connect-PSUServer to allow a user to make a API Token from the terminal with minimal browser interaction while still being secure. Would love to know what you think.

Our PSU servers are located in an internal production network without internet access. It would be nice for the AI features if we could use our http proxy server to access the OpenAI compatible endpoint within our Azure environment. I've set the proxy under Settings/General/Plattform, the AI couldn't talk to Azure (and if this would be the right way: A NOPROXY option would be needed as many internal API services are not reachable by the proxy).

In PSU Triggers, you are unable to set the parameters that a trigger provides to its trigger script, meaning that if I want to use the same trigger script but with different parameters to the default then I must copy the entire script and change the defaults to those parameters, even though the same logic is running, it just needs different parameters. This would help with script reuse for similar resulting triggers but with the goal of sending things to other destinations.

We rely heavily on Git manual mode, but the Edit/Save toggle in the header bar only appears for full platform Administrators . We've tried every permission combination we could find related to Git, without success. The Edit/Save buttons simply never render for non-admin users. Is it possible to introduce a permission (or permission set) that grants Git edit/commit capability without requiring full platform Administrator rights? [image] [image] Use case: As an administrator, I'd like others on my team, who are intentionally not platform admins, to be able to edit and commit changes to Git. All of our changes promote from Test to Prod via GitHub PRs, so we'd like non-admins to be able to commit in manual mode to stage their PRs. One thing we noticed: if a non-administrator is granted the settings.git.commit/* permission, they can reach the commit page that the "Save" button navigates to (/admin/settings/git/commit) and submit changes there, but they cannot initiate Edit mode, because the Edit/Save buttons never appear for them. Could this capability be tied to (or piggybacked on) the settings.git.commit/* permission so it also surfaces the Edit/Save controls?

Request from a customer Customer would like to disable the AI features in PSU. We should be able to hide them in the admin console as well as disable the MCP URL.

Hi :) We have a bunch of servers that are running one-way git sync (only pulling). Sometimes we have to create a new token on these servers, but the console is read-only = we cant do it. So the "fix" is to change git settings, then create the new token, and then change the git settings back. It would be great, if we could create new tokens, without having to do this.

Maybe I'm missing something, but is there a trigger that can fire for alerts in PSUNI? We've been having schedules go invalid due to some bad formatting in a query, but now that it's resolved, I'm left wondering if I can set up some notifications to external sources. I'll also look into hooking up PSUNI to Zabbix for monitoring jobs. If we had a trigger for alerts, I could send that off to my teams script for example. Does "health check failed" fire if psuni doesn't load the schedules and throws an error?

I have to scroll to the bottom to find my version, it was way more convenient on top (or at least put in a help menu).

Hi :) If you search in Winget for Devolutions, you will see most of their products - it would be awesome, to have PSU in there as well. Then we can in a very simple way, just update our products, and even include it in CI/CD pipelines.

As far as i know it can only be configured in the .universal/publishedFolders.ps1 witch unfortunately hides this awesome feature unless you read the docs. It works quite well and saved me a bunch of time. Please consider adding it to the published Folders settings modal long term :D https://docs.devolutions.net/powershell-universal/apps/custom-frontends#hosting-static-assets

Hi :) PSU sets a set of default tags on the computer object, that is based on the environment its in. It would be ideal that we could add custom tags, such as the environment (Prod / Test / Dev), Owner, business service, etc - to align it better with our current CMDB platform. I believe it should be in the appsettings.json, since this one is not normally synced to Git - so setups with a prod and a test instance of PSU, will not conflict on this. It should also allow us to write anything we want, so that we arent "stuck" with a key/value set, defined from Devolutions. Bonus - if the tags could be read on the fly, that would be nice. So adding a new tag, wouldnt have to restart the service, for it to appear - but its a nice to have thing.