Bug Report

I have two instances of PSU that are connected with the same DB. (prod duplication) When I edit a script on one node and want to test it befor i commit, the script almost always runs on the wrong node. This wont be a problem when i actually commit but for testing this is problematic. Can we get a setting that scripts where triggered manually are always on the node it was started on unless specified otherwise with out setting a single node as the default? Also the workflow execution settings are empty. [image] [image] When i set this subscript do execute on the right node. I do not want to set it, because i still want the other scripts to run on the least busy node. But without the Default Run this happens: [image] The subscript executes on the wrong node. [image] Regards Best Dy.

If I select a file in the files tab, click the delete icon, then click the delete button, nothing happens. I can then no longer select other files or close the delete confirm flyout.

Nothing happens when we try to filter or sort columns: [image]

Clicking the button throws the following in the console: [image]

After upgrading to 2026.3.x, PSU commands such as Get-PSUComputer , Get-PSUEventHubConnection , and Send-PSUEvent to name a few are failing with The SSL connection could not be established, see inner exception. . I have found that adding the -Integrated parameter to the cmdlets that support it resolves them, but Send-PSUEvent doesn't have a -Integrated parameter.

When making edits to any files under the .universal folder in the Files section of the GUI the editor hangs. Refreshing the page causes the editor to not be able to load the file again until the service is restarted.

Versions: 2026.3.1 and 2026.3.2 (devolutions/powershell-universal, ubuntu-24.04) Related: forum topics 56529 and 56533 Steps to reproduce 1. Set Api__SecurityModel to Integrated (also reproduces with High). 2. Create a role that carries the token permissions and is never assigned to anyone: New-PSURole -Name 'TokenIssuer' -Permissions @('security.tokens/*') -Policy { param($User) $false } 3. Create an authenticated API endpoint with -ExecutionRole 'TokenIssuer' whose script calls Grant-PSUAppToken -Integrated. 4. Call it as a signed-in user in the Administrator role. 5. Create an anonymous endpoint (-Authentication:$false) with the same execution role and script, and call it. Actual - Step 4: Permission denied. The role specified does not have access to this resource. - Step 5: Unauthenticated. Specify an app token... - Get-PSUAppToken -Integrated and Revoke-PSUAppToken -Integrated fail the same way. - The results are identical with and without -ExecutionRole. Expected The execution role's security.tokens permissions apply to the -Integrated token cmdlets the endpoint runs. Alternatively, those cmdlets are authorized as the server identity. Impact Under any model except Permissive, no endpoint can mint, list or revoke app tokens unless the caller's own roles carry security.tokens. An anonymous bootstrap endpoint can never mint one. The only way around it is to grant token permissions to every admin or switch to Permissive, and neither is acceptable for us.

When it doesn't load, the X doesn't close the popup and you have to refresh the window. I tested a handful of pages and these are the results: Works: Scripts tab Files / Repository tab Logging tab Doesn't work: Home tab (Sometimes works - sometimes loads previous terminal contents, shows "prompt" for a bit, then goes blank) Apps tab App edit code page App page edit page

The Favicon functionality is broken. It only works if specified for an App but not system wide. More specific, these settings currently do not work: [image] [image] Thanks for considering to fix that in an upcoming release! 🤗 Best regards, Don

Good morning, After this week updates I've noticed few of my API endpoints are not behaving correctly, refusing my authentication verification. It is simple check against ClaimsPrincipal NameIdentifier. Authentication set to WS-Federation. I have two test endpoints setup for it. One just returns $ClaimsPrincipal, the other one is extracting Nameidentifier: (($ClaimsPrincipal | ConvertFrom-Json).Claims | Where-Object -Property Type -EQ " http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier").Value This value is translated differently in PSU web test, returning "Name" property instead. Same endpoint run trough browser returns correctly "NameIdentifier" which is slightly different name. The last invokation trough "Invoke-RestMethod" and token I used for users before now returns "PowershellUniversal" as Nameidentifier. I'm not sure what happened or if it's intended behaviour, as I've tested the output of powershell script for the user with his token to make sure it works. Workaround would be to rewrite the check for Name. Thanks for any info on this.

In current version if you have a param with a ValidateSet and tab between fields and use keyboard to select the option from the drop down the job will be submitted when pressing enter to choose your selection. Example Script: param( [ValidateSet( 'Test1', 'Test2' )] [string] $Test ) Reproducing: Run script Select the Test field to highlight Use arrow keys on keyboard to select value Press enter Script runs without parameter value being selected, any subsequent parameters are ignored Note that this does not affect [string[]] inputs with or without validate set. IMO, the Enter key should NEVER launch the script. There is a chance the script can be run with incomplete parameters and cause major issues.

OS: Linux Docker Image: devolutions/powershell-universal:2026.3.0-ubuntu-24.04 Note: This container has updated through almost every 2026.* release without any problems causing failed starting OBS: Image is baked into another image but other versions haven't been a problem PowerShell Universal fails to start because the security proxy does not become available within the configured startup timeout. After starting with new imagine Startup sequence: - PowerShell Universal begins starting. - Startup reaches "Starting security service..." - The security service does not successfully start within 30 seconds. - PowerShell Universal then aborts startup. - Reverting to 2026.2.5 successfully starts it again Displayed error: PowerShell Universal failed to start. Check the logs for more information. Failed to load PowerShell Universal. Timed out waiting for security proxy to start. Waited 30 seconds. Consider increasing the SecurityProxyTimeout setting in appsettings. Expected behavior: PowerShell Universal should successfully start the security service and complete application startup.

I use Invoke-PSUScript to start jobs from endpoint calls, and frequently use the Log tab in the endpoint code editor for debugging or traceback etc. Sadly this log is hard to read for 2 reasons: 1) it does not support ANSI sequences, but still displays them as text. 2) return values from Invoke-PSUScript do get written in the log, even if they are captured. So a simple $DisplayName = Invoke-PSUScript -Script 'getUser.ps1' -Wait sould not write the return value itself to the log, since it is captured in a variable, but it still does and on top all outputs (return / write-Information, etc) of that script contain ANSI sequences: [Information] [Api-/data/getUser:GET] DisplayString : John Doe So I would love to either have the log support those ANSI sequences or have it stripe them off. Also, captured return values from scrips should not appear in the log, which would be consistend to the powershell behavior in general.

Description of Issue After upgrading our PSU Dev instance from 2026.2.0 to 2026.3.0 , dashboard apps that call Get-PSUCache -Integrated intermittently fail with: You must be running this command in PowerShell Universal to use the integrated mode. This confirms -Integrated is required for these calls to function (they were designed to bypass the Management API's role/token auth entirely), and that the integrated back-channel itself is broken/flaky, not the calling code. Steps to Reproduce On a 2026.3.0 instance, create/use an app (New-PSUApp) without -GrantAppToken. In the app content, call Get-PSUCache -Key '<AnyCacheKey>' -Integrated for several distinct keys on page load. Reload the app/page repeatedly. Observe intermittent failures on arbitrary -Integrated calls with the error above — not on every load, and not consistently on the same call. Expected Behavior -Integrated calls made from inside a running PSU app should reliably execute against the same server process without needing Management API auth, regardless of load timing. Actual Behavior The integrated back-channel intermittently fails to establish/verify, causing the cmdlet to conclude (incorrectly) that it isn't running inside PSU. Let me know if you need anything else from me. Cheers

I just upgraded my installation from 2.5 to 3.2 and tested everything I have in it. Running in Linux container in Azure App Services using the images provided. Removed schedules keep running as orphaned Hangfire jobs. Removing three schedules from schedules.ps1, in the same sync that removed their scripts, deleted them from the admin console. Their recurring jobs kept firing every minute and survived a restart, each run logging Failed to execute job with schedule <name> / System.Exception: Schedule <name> not found. Nothing was visible in the UI. Workaround: re-add the schedules with -Paused under the same names, sync, then remove them. Invoke-PSUScript -Integrated now authorizes the caller. This isn't in the release notes or the cmdlet help. From an app handler it now fails with "Permission denied. The role specified does not have access to this resource." for users without script permissions, where 2026.2.5 allowed it. Also, a scheduled script with no execution role can still start another script with -Integrated, but the same script with -ExecutionRole Execute or -ExecutionRole Administrator is refused. Is that intended, and what is the supported way for an app to start a job on a user's behalf without granting the user script permissions? $EventData from form controls arrives JSON-encoded. In New-UDSelect -OnChange and New-UDTextbox -OnChange, $EventData is now "value", with the quotes, where 2026.2.5 gave value.

[Reposting with fully sanitized screenshot because there's apparently no way to modify a screenshot or edit a post after making it] Hi there, New PSU user here. I am working through configuring our server, running PSU as a service on Windows Server, no IIS. While running the PSU service as local system, I created a web app and configured Run-As credentials to use a domain account and had no issue. When I moved converted PSU service to run as a service account, as it's documented that this is best practice, my web apps will no longer start. I already tried re-creating the run as account credential secrets while running PSU service as the service account; this is not the issue. The credentials validate successfully. The PSU Service account is a local admin on the server. When I look in event viewer, I see that the Run As account is attempting to log into the server interactively (logon type 2), which is something we explicitly block for service account in our environment. Can someone explain to me if this is a bug or by design for some reason? I don't understand why the Run As account is attempting to log in interactively. See attached screenshot for details. I had this issue in 2026.2.4 and attempted an upgrade to 2026.3.1 but that did not fix the issue. [image]

it is very difficult to find the reload config files menu, i found it by accident. [image]

the file detector thing runs, but i still have to go to files and click reload endpoints or whatever it is i am working with to get psu to redploy whatever

I just installed 3.1.0 on my own laptop to test something out but I wasn't able to create apps or scripts. I signed in with a developer account. I also tried in a docker container with a trial key but same thing there. Just click the button for 'Create App' or 'Create Script' and it just freezes the whole page except for the navigation menu.

When moving a script into a folder the schedule is not updated with the new path and then the schedule disappears from the UI. I have been resorting to editing the schedules.ps1 and updating the path manually, but it would be nice to have this handled automatically. I am seeing this on all versions of PSU and most recently on 2026.3.1.

Hi, After upgrading an existing PowerShell Universal installation from 2026.2.3.0 to 2026.3.0.0 , I encountered what appears to be a regression involving module discovery when combining the built-in PowerShell 7 environment with an alternate execution credential. Configuration The affected scripts use: Environment: PowerShell 7 , configured with -Type "PowerShell7" Execution → Credential: an AD service account Modules installed under the standard machine-wide Windows module directories The original environment configuration was: New-PSUEnvironment -Name "PowerShell 7" -Variables @('*') -Description "The PowerShell 7 version included with PowerShell Universal." -Type "PowerShell7" Actual behavior When a script runs in PowerShell 7 using the AD service-account credential, modules installed in the standard module directories cannot be discovered. For example: Import-Module TOPdeskPS fails with: The specified module 'topdeskps' was not loaded because no valid module file was found in any module directory. Importing TOPdeskPS by its full path causes its dependency to fail instead: Import-Module 'C:\Program Files\WindowsPowerShell\Modules\TOPdeskPS\0.1.6\TOPdeskPS.psd1' Result: The required module 'PSFramework' is not loaded. Load the module or remove the module from 'RequiredModules' in the file 'C:\Program Files\WindowsPowerShell\Modules\TOPdeskPS\0.1.6\TOPdeskPS.psd1'. If I import both PSFramework and TOPdeskPS using their complete paths , they load successfully. This confirms that the modules themselves work in this host, but automatic module discovery does not. The problem only occurs with the combination: PowerShell 7 + AD service-account execution credential The same modules load successfully when using Windows PowerShell 5.1 or when running with another execution account. Workaround Adding the standard module directories explicitly to the PowerShell 7 environment resolves the issue: New-PSUEnvironment -Name "PowerShell 7" -Variables @('*') -Description "The PowerShell 7 version included with PowerShell Universal." -Type "PowerShell7" -PSModulePath @( 'C:\Program Files\PowerShell\Modules' 'C:\Program Files\WindowsPowerShell\Modules' 'C:\Windows\System32\WindowsPowerShell\v1.0\Modules' ) After applying this configuration, I tested several affected scripts using the AD service account and they all completed successfully without any script-specific workarounds. Expected behavior The normal machine-wide PowerShell module directories should remain available when a PowerShell 7 job is started using an alternate execution credential, without requiring them to be added explicitly to every environment. Could you confirm whether this is a known regression in 2026.3.0.0, possibly related to the changes around PowerShell versions or process hosting? I can provide sanitized PSModulePath output or relevant logs if needed. Also, tell me if this needs to be filed as a Github issue!

Environment: PowerShell Universal 2026.3.1 (possibly already 2026.3.0) Summary: After upgrading to 2026.3.x, `Get-PSUJobPipelineOutput` returns nothing for completed jobs, even though the pipeline output was produced correctly and is counted (but not shown) in the Admin Console. Repro script: $InformationPreference = 'Continue' $obj1 = [PSCustomObject]@{ Fruit = 'Apple'; Count = 3 } Write-Information "Object 1: $($obj1 | ConvertTo-Json -Compress)" $obj1 $obj2 = [PSCustomObject]@{ Name = 'Widget'; Color = 'Blue'; 'Order-State' = 'Success' } Write-Information "Object 2: $($obj2 | ConvertTo-Json -Compress)" $obj2 $arr = 1..2 | ForEach-Object { [PSCustomObject]@{ Index = $_; Value = "Item$_" } } Write-Information "Object 3 (array): $($arr | ConvertTo-Json -Compress)" $arr Steps : Run via Invoke-PSUScript (or admin console), wait for completion, then check the job's "Pipeline Output" tab and call Get-PSUJobPipelineOutput -JobId <id> (tested locally and remotely with -ComputerName/-UseDefaultCredentials). Expected: 4 objects (array unrolls to 2) with their properties, retrievable via Get-PSUJobPipelineOutput and inspectable in the Admin Console (as in 2026.1.6). Actual: - Admin Console "Pipeline Output" tab lists 4 rows but only shows the type name Deserialized.System.Management.Automation.PSCustomObject, no property values. - Get-PSUJobPipelineOutput -JobId <id> returns nothing, locally and remotely. - The job Log tab (explicit `Write-Information` JSON) confirms the correct values were actually emitted, ruling out a scripting error. Impact: Any dashboard app using Get-PSUJobPipelineOutput to show job results in a table silently displays empty data despite successful job execution.

It looks like there's a problem with the 2026.3.X images for Windows Server 2022. I'm getting this message when running docker pull: a Windows version 10.0.26100-based image is incompatible with a 10.0.20348 host The first layer for the 2026.3.0 and 2026.3.1 images for ltsc2022 is this: Apply image 10.0.26100.32230 However, on 2026.2.5, it's this: Apply image 10.0.20348.2700 Since my docker host is running Windows Server 2022, I can't check the new version of PowerShell Universal. Should I make a separate forum post for this issue, or is this something you can look into?

Version: 2026.3.1 OS: 2025 Server Datacenter (latest Windows Updates - including the Out-Of-Band one) .Net Core: 10.0.12 - Windows Server Hosting IIS Hosted - App Pool running as a gMSA Database: SQLite Whenever I attempt to browse to PSU at all, even the /admin page, I get application crashes logged and the page errors out or the application pool crashes. This is the application crash I'm getting: Faulting application name: w3wp.exe, version: 10.0.26100.1882, time stamp: 0xc6bd45bd Faulting module name: e_sqlite3.DLL, version: 3.53.3.0, time stamp: 0x4b3d3b00 Exception code: 0xc00000fd Fault offset: 0x0000000000115d7c Faulting process id: 0xB68 Faulting application start time: 0x1DD4B6FADEF5BD3 Faulting application path: c:\windows\system32\inetsrv\w3wp.exe Faulting module path: D:\Powershell Universal\e_sqlite3.DLL Report Id: 840d3897-5d38-49f7-9c2b-968392a41442 Faulting package full name: Faulting package-relative application ID: (sometimes it references ntdll.dll, but that's typically a red herring) This was happening on 2026.3.0 after upgrading from 2026.1.2, though that was routinely referencing D:\Powershell Universal\coreclr.dll . What I've tried: Verified the ZIP download hash. Manually verfied files weren't blocked (I run a Get-ChildItem -Recurse | Unblock-File in the upgrade process) Re-extracted and copied over our appsettings.json and web.confg. Reviewed and updated the appsettings.json to contain any new settings that exist in the one from the zip Upped the logging to debug in appsettings.json, I see a lot of lines about loading license information, but nothing that looks useful The only error (tagged warning but has error in the message) in the systemLog file for PSU is the following: 2026-09-23 11:26:35.921 -04:00 [INF][UniversalAutomation.Services.UniversalConfigurationService] Reading configuration for Variable 2026-09-23 11:26:35.925 -04:00 [INF][ProtoBuf.Grpc.Server.ServicesExtensions.CodeFirstServiceMethodProvider] RPC services being provided by UniversalAutomation.IPublicGitSyncService: 5 2026-09-23 11:26:36.048 -04:00 [INF][Microsoft.AspNetCore.Hosting.Diagnostics] Request starting HTTP/1.1 GET https://<internalURL>/login?returnUrl=%2Fadmin - null null 2026-09-23 11:26:36.109 -04:00 [WRN][Microsoft.AspNetCore.Session.SessionMiddleware] Error unprotecting the session cookie. System.Security.Cryptography.CryptographicException: The payload was invalid. For more information go to https://aka.ms/aspnet/dataprotectionwarning at Microsoft.AspNetCore.DataProtection.Cng.CbcAuthenticatedEncryptor.DecryptImpl(Byte* pbCiphertext, UInt32 cbCiphertext, Byte* pbAdditionalAuthenticatedData, UInt32 cbAdditionalAuthenticatedData) at Microsoft.AspNetCore.DataProtection.Cng.Internal.CngAuthenticatedEncryptorBase.Decrypt(ArraySegment`1 ciphertext, ArraySegment`1 additionalAuthenticatedData) at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.UnprotectCore(Byte[] protectedData, Boolean allowOperationsOnRevokedKeys, UnprotectStatus& status) at Microsoft.AspNetCore.DataProtection.KeyManagement.KeyRingBasedDataProtector.Unprotect(Byte[] protectedData) at Microsoft.AspNetCore.Session.CookieProtection.Unprotect(IDataProtector protector, String protectedText, ILogger logger) 2026-09-23 11:26:36.334 -04:00 [INF][Microsoft.AspNetCore.Routing.EndpointMiddleware] Executing endpoint '/Login' 2026-09-23 11:26:36.354 -04:00 [INF][Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker] Route matched with {page = "/Login", action = "", controller = ""}. Executing page /Login 2026-09-23 11:26:36.372 -04:00 [INF][Microsoft.AspNetCore.Mvc.RazorPages.Infrastructure.PageActionInvoker] Executing handler method PowerShellUniversal.Login.OnGet - ModelState is "Valid" 2026-09-23 11:26:38.618 -04:00 [INF][UniversalAutomation.Services.UniversalConfigurationService] Reading configuration for Translation 2026-09-23 11:26:38.623 -04:00 [INF][UniversalAutomation.Services.UniversalConfigurationService] Reading configuration for Settings Both reverting to the 2026.1.2 folder and reverting the VM restores functionality. For reference, my upgrade process is as follows: Create new folder, set ACL security on the folder for the gMSA. Extract the ZIP. Unblock recursively Copy web.conf and appsettings.json from the existing PSU folder to the new folder iisreset /stop Rename folders (old one gets datetime stamped, new one gets renamed to the original path) iisreset (to start IIS) The database/repository folders are separate and outside the path of the IIS site, and are not touched. Database access looks functional based on the systemLog, as in debug logging, I see it sucesfully executing queries: 2026-09-23 11:52:15.845 -04:00 [DBG] Creating DbConnection. 2026-09-23 11:52:15.846 -04:00 [DBG] Created DbConnection. (0ms). 2026-09-23 11:52:15.846 -04:00 [DBG] Opening connection to database 'main' on server 'D:\PSUDB\database.workflows.db'. 2026-09-23 11:52:15.846 -04:00 [DBG] Opened connection to database 'main' on server 'D:\PSUDB\database.workflows.db'. 2026-09-23 11:52:15.846 -04:00 [DBG] Creating DbCommand for 'ExecuteReader'. 2026-09-23 11:52:15.846 -04:00 [DBG] Created DbCommand for 'ExecuteReader' (0ms). 2026-09-23 11:52:15.846 -04:00 [DBG] Initialized DbCommand for 'ExecuteReader' (0ms). 2026-09-23 11:52:15.846 -04:00 [DBG] Executing DbCommand [Parameters=[@filter_UsableAsActivity='?' (DbType = Boolean)], CommandType='"Text"', CommandTimeout='30'] SELECT "w"."Id", "w"."BinaryData", "w"."CreatedAt", "w"."Data", "w"."DefinitionId", "w"."Description", "w"."IsLatest", "w"."IsPublished", "w"."IsReadonly", "w"."IsSystem", "w"."MaterializerContext", "w"."MaterializerName", "w"."Name", "w"."OriginalSource", "w"."ProviderName", "w"."StringData", "w"."TenantId", "w"."ToolVersion", "w"."UsableAsActivity", "w"."Version" FROM "WorkflowDefinitions" AS "w" WHERE "w"."UsableAsActivity" = @filter_UsableAsActivity ORDER BY "w"."CreatedAt" 2026-09-23 11:52:15.846 -04:00 [INF] Executed DbCommand (0ms) [Parameters=[@filter_UsableAsActivity='?' (DbType = Boolean)], CommandType='"Text"', CommandTimeout='30'] SELECT "w"."Id", "w"."BinaryData", "w"."CreatedAt", "w"."Data", "w"."DefinitionId", "w"."Description", "w"."IsLatest", "w"."IsPublished", "w"."IsReadonly", "w"."IsSystem", "w"."MaterializerContext", "w"."MaterializerName", "w"."Name", "w"."OriginalSource", "w"."ProviderName", "w"."StringData", "w"."TenantId", "w"."ToolVersion", "w"."UsableAsActivity", "w"."Version" FROM "WorkflowDefinitions" AS "w" WHERE "w"."UsableAsActivity" = @filter_UsableAsActivity ORDER BY "w"."CreatedAt" 2026-09-23 11:52:15.846 -04:00 [DBG] Closing data reader to 'main' on server 'D:\PSUDB\database.workflows.db'. 2026-09-23 11:52:15.846 -04:00 [DBG] A data reader for 'main' on server 'D:\PSUDB\database.workflows.db' is being disposed after spending 0ms reading results. 2026-09-23 11:52:15.846 -04:00 [DBG] Closing connection to database 'main' on server 'D:\PSUDB\database.workflows.db'. 2026-09-23 11:52:15.846 -04:00 [DBG] Closed connection to database 'main' on server 'D:\PSUDB\database.workflows.db' (0ms). 2026-09-23 11:52:15.846 -04:00 [DBG] 'ManagementElsaDbContext' disposed. 2026-09-23 11:52:15.846 -04:00 [DBG] Disposing connection to database 'main' on server 'D:\PSUDB\database.workflows.db'. 2026-09-23 11:52:15.846 -04:00 [DBG] Disposed connection to database 'main' on server 'D:\PSUDB\database.workflows.db' (0ms). I will note that I don't see any logs about it talking to the main DB, just this workflow db. The final lines in the systemLog are always: 2026-09-23 11:54:28.550 -04:00 [DBG][UniversalAutomation.Common.Interfaces.ILicenseService] Loading license information. 2026-09-23 11:54:29.129 -04:00 [INF][UniversalAutomation.Services.UniversalConfigurationService] Reading configuration for Translation 2026-09-23 11:54:29.135 -04:00 [INF][UniversalAutomation.Services.UniversalConfigurationService] Reading configuration for Settings 2026-09-23 11:54:29.139 -04:00 [DBG][UniversalAutomation.Services.ConfigurationScript] Reading configuration file settings.ps1 2026-09-23 11:54:29.140 -04:00 [DBG][UniversalAutomation.Services.ConfigurationScript] File exists. Deserializing items. 2026-09-23 11:54:32.682 -04:00 [DBG][Universal.Server.Routing.UniversalEndpointDataSource] Endpoints changed. Notifying change token. Any help on where to start further troubleshooting would be appreciated.

I have been using pages within psu apps and when using cmdlets like the following $job = get-psujob -id 1234123 -Integrated $Job = Invoke-PSUScript -Name "test" in the page i get the following [image] This works fine on 2026.2.5 but does not work on 2026.3.0