Devolutions PowerShell Universal - Devolutions Forum

Ctrl + k

Devolutions PowerShell Universal

Devolutions PowerShell Universal

Announcement

Monitor this forum to get notified when a new update is available

Support

Support forum for Devolutions PowerShell Universal

Support (Français)

Forum de support dédié aux demandes en français

Support (Deutsch)

Supportforum für deutschsprachige Benutzer

Bug Report

Report bugs for Devolutions PowerShell Universal

Feature Request

Feature request forum for Devolutions PowerShell Universal

Community Showcase

Explore and share solutions built with Devolutions PowerShell Universal

Recent Posts

Published a minute ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

Hello nikopieper, Thank you for the additional information. We reviewed the logs you provided internally. At this stage, the evidence points more strongly toward a SQL Server / HA-path latency issue rather than a PSU application or schema regression. The slow queries are not isolated to Git settings. We can see unrelated reads and writes against several PSU tables becoming slow during the same periods. In the latest sample, a query against the Computer/ComputerTag data took approximately 30 seconds. During nearly the same interval, Kestrel reported a heartbeat delay of about 30 seconds, followed immediately by a job-process handshake timeout. For the DBA investigation, the most useful window to correlate is: **2026-08-21 17:43:45 through 17:44:16 +02:00** The earlier **09:10–09:35 +02:00** interval is also relevant, as multiple unrelated queries reached approximately 7–37 seconds. If possible, please have the DBA review those periods for SQL wait types, blocking sessions or blocking chains, execution plans where applicable, storage latency, resource pressure, and SQL cluster/replica/listener health. Additionally, if permitted by your organization's policies, it would be helpful if you could provide a **sanitized copy of the affected database** using the secure upload location that Erika previously provided. Please do not post the database publicly. Before uploading it, remove or anonymize customer data, credentials, tokens, connection information, and any other sensitive or identifying information. Once the DBA information and, if available, the sanitized database are provided, we can continue correlating the SQL behavior with the PSU events we identified. Best regards, Ruben Tapia

Published 18 minutes ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

2026-08-21 17:43:45.270 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SET IMPLICIT_TRANSACTIONS OFF; SET NOCOUNT ON; UPDATE [Job] SET [CreatedTime] = @p0, [Environment] = @p1, [StartTime] = @p2 OUTPUT 1 WHERE [Id] = @p3; | Parameters: @p3=297424, @p0=8/21/2026 3:43:44 PM, @p1=PowerShell 7.4.12 , @p2=8/21/2026 3:43:44 PM, took 542.2779 ms 2026-08-21 17:43:45.274 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SET IMPLICIT_TRANSACTIONS OFF; SET NOCOUNT ON; UPDATE [Job] SET [MemoryBytes] = @p0 OUTPUT 1 WHERE [Id] = @p1; | Parameters: @p1=297422, @p0=94598485, took 545.0694 ms 2026-08-21 17:43:45.613 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT TOP(1) [j].[Status] FROM [Job] AS [j] WHERE [j].[Id] = @job_Id | Parameters: @job_Id=297426, took 344.598 ms 2026-08-21 17:43:45.614 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT [g].[Id], [g].[Branch], [g].[Bundle], [g].[BundlePath], [g].[BundleTimestamp], [g].[ExternalGit], [g].[GitEnvironmentVariable], [g].[GitSshKey], [g].[InitBehavior], [g].[Interval], [g].[ManualMode], [g].[Mode], [g].[Name], [g].[Password], [g].[Paused], [g].[ProxyUrl], [g].[Remote], [g].[SyncBehavior], [g].[UpdateSubmodules], [g].[UserName] FROM [GitSettings] AS [g] took 339.9386 ms 2026-08-21 17:43:45.614 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT TOP(1) [j].[Status] FROM [Job] AS [j] WHERE [j].[Id] = @job_Id | Parameters: @job_Id=297422, took 338.966 ms 2026-08-21 17:43:45.614 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SET IMPLICIT_TRANSACTIONS OFF; SET NOCOUNT ON; UPDATE [Job] SET [MemoryBytes] = @p0 OUTPUT 1 WHERE [Id] = @p1; | Parameters: @p1=297430, @p0=54439253, took 567.5672 ms 2026-08-21 17:44:15.770 +02:00 [WRN][PowerShellUniversal.SQL.PsuDbContext] Slow Query Detected: SELECT [c1].[Id], [c1].[Deleted], [c1].[DeploymentName], [c1].[DeploymentVersion], [c1].[EditMode], [c1].[FileSyncTimestamp], [c1].[GitBranch], [c1].[GitSettings], [c1].[GitSshKey], [c1].[GrpcPort], [c1].[HangfireServerId], [c1].[HangfireWorkerCounter], [c1].[HeartBeat], [c1].[LoadingInfo], [c1].[LoginErrorMessage], [c1].[Maintenance], [c1].[Name], [c1].[ReadOnly], [c1].[Status], [c1].[Type], [c1].[Version], [c0].[Id], [c0].[ComputerId], [c0].[Name], [c0].[Static], [c0].[Value] FROM ( SELECT TOP(1) [c].[Id], [c].[Deleted], [c].[DeploymentName], [c].[DeploymentVersion], [c].[EditMode], [c].[FileSyncTimestamp], [c].[GitBranch], [c].[GitSettings], [c].[GitSshKey], [c].[GrpcPort], [c].[HangfireServerId], [c].[HangfireWorkerCounter], [c].[HeartBeat], [c].[LoadingInfo], [c].[LoginErrorMessage], [c].[Maintenance], [c].[Name], [c].[ReadOnly], [c].[Status], [c].[Type], [c].[Version] FROM [Computer] AS [c] WHERE [c].[Name] = @nodeName ) AS [c1] LEFT JOIN [ComputerTag] AS [c0] ON [c1].[Id] = [c0].[ComputerId] ORDER BY [c1].[Id] | Parameters: @nodeName=XX, took 30154.648 ms 2026-08-21 17:44:15.795 +02:00 [WRN][Microsoft.AspNetCore.Server.Kestrel] As of ""2026-08-21T15:44:15.7690789+00:00"", the heartbeat has been running for ""00:00:29.7110717"" which is longer than ""00:00:01"". This could be caused by thread pool starvation. 2026-08-21 17:44:15.832 +02:00 [WRN][PowerShellUniversal.Automation.GrpcExecutionService] Job process did not respond to handshake in time. Killing process in 5 seconds.

Published 26 minutes ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

Hello nikopieper, Thank you for the update. I currently do not have access to the files you mentioned uploading. However, given that the issue has now recurred and PSU is currently not operational, we consider the situation critical enough to escalate it directly through our internal channels for further review. If any additional information is required after the escalation review begins, I will follow up here with the specific details needed. Best regards, Ruben Tapia rubentapia i sent you a mail with the log attached

Published 29 minutes ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

I asked for the Data from the DBA which is pending, the DB is ~8GB on a 2022 SQL Cluster

Published 32 minutes ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

Hello nikopieper, Thank you for the update. I currently do not have access to the files you mentioned uploading. However, given that the issue has now recurred and PSU is currently not operational, we consider the situation critical enough to escalate it directly through our internal channels for further review. If any additional information is required after the escalation review begins, I will follow up here with the specific details needed. Best regards, Ruben Tapia

Published 42 minutes ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

Hello, the DB "crashed" again and PSU is not working anymore. i uploaded the files

Published 3 hours ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

Hello nikopieper , Thank you for your feedback. I moved your comment to a new thread in the PowerShell Universal - Support section . We found no SQL, Git, or schema-migration changes in 2026.2.5 that would explain Git Settings queries taking 25–35 seconds. The release did update the bundled .NET runtime build and PowerShell SDK, so we would like to collect data if it recurs. Before reproducing, please take a backup. Set Data:SlowQueryLimit to 1 temporarily and restart PSU. The system log will then record Slow Query Detected entries with the SQL command and duration; please send the relevant log section from %ProgramData%\PowerShellUniversal\Logs\System\systemLog.txt (or your configured SystemLogPath), with credentials, tokens, and connection strings redacted. At the same time, please have the DBA capture the SQL Server wait type, blocking session, execution plan, and active Availability Group replica/listener for the slow requests. Since restoring the database resolved the problem, this evidence will help distinguish blocking, failover/routing, plan-cache, or storage latency from an application regression. I'll send you a link for you to upload the logs to our safe space. Thank you for your collaboration. Best regards,

Published 3 hours ago

CSharp API Endpoints

Hello tomtaylor, Thank you for the detailed report and for documenting the workarounds you identified. The four findings are specific enough for us to validate independently, so I would like to reproduce them separately rather than make assumptions based solely on the implementation details. I will review: * The current `ApiRequest` / `SecurityContext.Roles` contract against the documented example. * `#ref` and `#using` behavior with CRLF versus LF line endings. * Whether directive extraction can also match comments or string literals. * Whether `#using` requires a trailing semicolon and how that compares with the current documentation. I will also compare the behavior across the relevant PSU versions so we can determine which findings are documentation discrepancies and which, if reproduced, represent product behavior that requires further review. Thank you again for providing such a focused reproduction. Best regards, Ruben Tapia

Published 5 hours ago

Very long query times on MSSQL HA Cluster after updating to version 2026.2.5.0

After the update we have been experiencing very long query times on MSSQL HA Cluster resulting the Service not do Start due to timeouts. For git settings its was something like 25-35 seconds. After restoring the DB from yesterday and restarting the software it workes again now.

Published 18 hours ago

CSharp API Endpoints

Added the plugin yesterday and built some generic endpoints, chased down some issues I was having. I don't expect this to impact the plugins functionality, but I'm able to workaround these for the time being. PSU Version: 2026.2.2 (also found in 2026.2.4 DLLs) Host: Windows Server 2025 Web: IIS DB: SQL Component: PowerShellUniversal.Language.CSharp Finding #1 - ApiRequest.Roles is nested under nullable parent SecurityContext and is List<string> not string[] // expected usage, from current documentation var roles = request.Roles ?? Array.Empty<string>(); // corrected, working var roles = request.SecurityContext?.Roles ?? new List<string>(); Finding #2 - ref/using extraction match literal CRLF. LF-only lines never hit. CSharpExecutionService extracts directives with: private readonly Regex _reference = new Regex("#ref (.*)\r\n"); private readonly Regex _using = new Regex("#using (.*)\r\n"); Finding #3 - Directive-extraction is not anchored and will hit on comments and string literals. Reference #2. Finding #4 - Matched `#using` directives are not terminated with `;`. Documentation shows code snippets without trailing `;` // reproduce with #ref System.Collections #using System.Collections.Generic var roles = request.SecurityContext?.Roles ?? new List<string>(); // corrected with trailing ; on using directive

devolutions-automation

Published 19 hours ago

Devolutions PowerShell Universal Version 2026.2.5.0 (August 20, 2026)

IMPROVEMENTS Updated to PowerShell SDK 7.6.5 FIXES Fixed an issue starting the server when using a Devolutions license in an environment requiring proxy configuration Fixed an issue with single-quote serialization in configuration files DOWNLOADS https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.2026.2.5.0.msi https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.Agent.2026.2.5.0.msi https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.win-x64.2026.2.5.0.zip https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.win-arm64.2026.2.5.0.zip https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.linux-x64.2026.2.5.0.zip https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.linux-arm.2026.2.5.0.zip https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.linux-arm64.2026.2.5.0.zip https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.osx-x64.2026.2.5.0.zip https://cdn.devolutions.net/download/Devolutions.PowerShellUniversal.osx-arm64.2026.2.5.0.zip

Published 19 hours ago

Roles/Permissions assignment not working

Hello tt_gopsu One additional update from our testing. After reviewing the requirements for a second lab, we determined that building a fully equivalent environment would not provide reliable parity with your Windows SSO and AD configuration. The Docker-based comparison would introduce enough differences that the results could be misleading. The most useful next step is to compare the effective authorization from an affected session with the script configuration. Could you please capture the output of `/api/v1/identity/claims` while signed in as an affected user, along with the affected script’s exact `Role` assignment from the Portal/script configuration? Because this information may contain environment-specific identity data, please do not post the raw output publicly. You can send the sanitized information directly to my support email: ruben.tapia@ironmansoftware.com Please redact usernames, email addresses, group IDs/SIDs, tokens, and other sensitive values, but preserve the claim types, number of values, role names, and exact spelling/case. This will allow us to compare the effective session authorization directly with the Portal role required by the script. Best regards, Ruben Tapia

Published 20 hours ago

Roles/Permissions assignment not working

deroppi , thanks for clarifying. One question that may help us compare your setup with the behavior reported by tt_gopsu When your role-mapping logic assigns more than one PSU role to the same user, do you see all of those roles applied effectively at the same time? In particular, are the permissions from the different roles cumulative for Portal resources such as Scripts, or have you seen cases where only one of the assigned roles appears to affect resource visibility or access? No need to share your full `roles.ps1`. A description of the observed behavior would be enough. Best regards, Ruben Tapia rubentapia My setup is rather small. we only use 5 roles. these roles match 5 apps. the apps shown in the PSU portal page fit the roles user got assigned. same with file access and other actions. the roles variable is correct as well. so far I did not experience anything that would make me think role wasn’t applied successfully. i cannot revert to the old version and setup we had once. All I remember is that using the PSU provided way of assigning roles from a Azure SSO login, always ended up applying only one role. i changed to my own method, it worked and I did not bother anymore. we do not use granular permissions.

Published 21 hours ago

Roles/Permissions assignment not working

I am also going to set up a second lab with closer parity to your reported environment so we can compare the behavior under more similar conditions. Because this setup is more complex to reproduce accurately, I will likely have the results available by the end of the day tomorrow, Friday. I will update the thread as soon as that testing is complete. Regards, Ruben Tapia

Published 21 hours ago

Roles/Permissions assignment not working

Hello tt_gopsu Following up on the lab testing I mentioned yesterday, we completed the reproduction work. We tested the scenario on PowerShell Universal 2026.1.6 build 24196505312, matching your reported version, and also on 2026.2.4 build 31515244301. In our isolated lab, we were not able to reproduce the issue: * A user with only the broad role could not see the script assigned to the `execute` role, as expected. * A user with both the broad and `execute` roles could see and execute the selected script. * The resulting jobs reported both roles. * Reversing the role/claim order did not change the behavior. * Assigning the `execute` role directly to the Identity also made the script visible and executable. * 2026.2.4 produced the same results. This suggests that multiple roles can be evaluated cumulatively under the tested conditions, so I would like to focus next on the differences between our working baseline and your environment. Could you please provide: * A sanitized list of the effective claims from one affected session. * The exact sanitized `Portal > Role` assignment for one script that does not appear. * How the role/permission changes were applied, including whether the PSU configuration or service was reloaded/restarted afterward. * In the role definition previously posted, the `execute` ClaimType appeared to contain `micrsooft` instead of `microsoft`. Could you confirm whether that typo exists in the actual configuration or was introduced while copying/sanitizing the example? Our lab did not match your exact Windows SSO, AD nesting, hosting, database, repository mode, browser, or service identity, so the next step will be to introduce relevant differences one at a time into the working baseline. Best regards, Ruben Tapia

Published 21 hours ago

Roles/Permissions assignment not working

deroppi , thanks for clarifying. One question that may help us compare your setup with the behavior reported by tt_gopsu When your role-mapping logic assigns more than one PSU role to the same user, do you see all of those roles applied effectively at the same time? In particular, are the permissions from the different roles cumulative for Portal resources such as Scripts, or have you seen cases where only one of the assigned roles appears to affect resource visibility or access? No need to share your full `roles.ps1`. A description of the observed behavior would be enough. Best regards, Ruben Tapia

Published a day ago

Roles/Permissions assignment not working

deroppi thank you for this - so you basically created your own Portal? no portal. i just rely on azure for user login and sending the ad group id and user email address in the claims. then in the roles script I map group id and user email mail to roles. and I keep a privileged app with only admin access in PSU to edit the files that serve as a config for who gets which role.

Published a day ago

No Logs in Endpoints

Hello nikopieper, We found one additional configuration detail that may be relevant, and I would like to verify it in your environment before drawing any conclusions. If you are using a **Database Logging Target** for API logging, could you please check the exact value configured in the **Feature** field? Specifically, please let us know whether it is set to: `API` or: `Api` Please do not change the setting yet. We would first like to confirm the current value in your environment and correlate it with the behavior you are seeing. Best regards, Ruben Tapia

Published a day ago

Roles/Permissions assignment not working

Hello tt_gopsu, Thank you for the detailed update and for running the additional tests. The results are very useful, especially the confirmation that both roles are present in `$UAJob` and that assigning the `execute` role directly to the Identity produces the same behavior. There is no need to open another support case. We can continue tracking the issue here. Today, we will be setting up a lab to reproduce the scenario under controlled conditions. We will focus on the role assignment, Portal script visibility, direct Identity assignment, and permission behavior so we can determine whether this is configuration-related or reproducible product behavior. I will update the thread once we have the lab results. Best regards, Ruben Tapia

Published a day ago

Roles/Permissions assignment not working

deroppi thank you for this - so you basically created your own Portal? Ruben - thank you for your response. * Your exact PowerShell Universal version and build. --> 2026.1.6 * Does this behavior affect every member of the AD group mapped to the `execute` role, or only certain users? --> all of them * For one affected user, can you confirm which PSU roles are effectively assigned after Windows SSO authentication? This is rather interesting - in order to obtain this information, I created a script outputting $UAJob to Json. For the user to be able to execute the script, I had to assign "All" - immediately the script was displayed in the Portal. [image] Here are the relevant parts of the $UAJob output. This is interesting, as obviously the AD groups are assigned correctly, however only the first one (dlg.******.infra01.PSU.All) seems to have any effect: "Identity": { "Id": 72, "Name": "******\\ts77184", "Source": "Git", "RoleName": null, "Roles": null, "CredentialVault": null, "Password": null, "LocalAccount": false, "OldPassword": null, "Settings": null, "Theme": "light", "JobColumns": null, "JobStatuses": null, "PasswordLastSet": null, "System": false, "ExcludedScripts": null, "SelectedScripts": null, "DevolutionsAccount": false }, [...] "Roles": "dlg.******.infra01.PSU.All,dlg.******.infra01.PSU.******Infrastructure**.execute", [...] "ReadPermission": "automation.scripts.Get-PSUVars.ps1/read", As an additional test, if possible, please temporarily assign the same `execute` role directly to a test Identity in PSU rather than obtaining it through the Windows SSO group mapping. Then sign out, sign back in, and check whether the assigned script becomes visible in the Portal. So I assigned to role directly to the Identity, which leads to nothing being displayed in the portal anymore: [image] * After changing the role assignment, does signing out completely and signing back in change the result? --> No, also signing off from the Workstation, Private Mode, ... does not change anything. If you can also share the relevant sanitized definitions for the broad role and the `execute` role, that would help. We do not need the complete configuration. --> (I'm guessing what you mean is the relevant portions of the roles.ps1?) New-PSURole -Name "dlg.******.infra01.PSU.All" -Description "Permissions for all users" -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" -ClaimValue "S-*-*-**-**********-********-**********-******" -DefaultRoute "/portal" -Priority 99 New-PSURole -Name "dlg.******.infra01.PSU.******Infrastructure**.execute" -Description "Users allowed to execute reporting Scripts in ****** Infrastructure (**) Folder" -ClaimType "http://schemas.micrsooft.com/ws/2008/06/identity/claims/groupsid" -ClaimValue "S-*-*-**-**********-********-**********-******" -DefaultRoute "/portal" -Priority 99 I also did some tests with other users: "Identity": { "Id": 73, "Name": "******\\*******", "Source": "Git", "RoleName": null, "Roles": null, "CredentialVault": null, "Password": null, "LocalAccount": false, "OldPassword": null, "Settings": null, "Theme": null, "JobColumns": null, "JobStatuses": null, "PasswordLastSet": null, "System": false, "ExcludedScripts": null, "SelectedScripts": null, "DevolutionsAccount": false }, [...] "Roles": "dlg.******.infra01.PSU.All,dlg.******.infra01.PSU.Operator,Operator", [...] "ReadPermission": "automation.scripts.Get-PSUVars.ps1/read", --> is able the execute the script in the Portal, has "Operator" permissions in the Admin console "Identity": { "Id": 26, "Name": "******\\**********", "Source": "Git", "RoleName": null, "Roles": null, "CredentialVault": null, "Password": null, "LocalAccount": false, "OldPassword": null, "Settings": "{\"AppCodeByDefault\":false,\"ScriptListView\":null,\"SchedulesListView\":null,\"EditorSettings\":{\"ShowLineNumbers\":true,\"ShowWhitespace\":false,\"DisableAnalyzer\":false,\"Minimap\":false,\"Theme\":null},\"PageSize\":100,\"HideModuleHomePageCard\":false}", "Theme": null, "JobColumns": [ "Id", "ScriptFullPath", "Status", "StatusDescription", "EndTime" ], "JobStatuses": null, "PasswordLastSet": null, "System": false, "ExcludedScripts": [ ], "SelectedScripts": null, "DevolutionsAccount": false }, [...] "Roles": "dlg.******.infra01.PSU.admin,Administrator,dlg.******.infra01.PSU.All", [...] "ReadPermission": "automation.scripts.Get-PSUVars.ps1/read", --> is able to execute the script in the portal, has Admin permissions in the Admin Console Should we open a support case on this matter?

External resources

Devolutions Documentation

Technical SupportEmail : service@devolutions.netPhone : + 1 844 463.0419