rubentapia

Hello @Dynamic66

Thank you again for the additional details.

We completed a focused test on PSU 2026.3.3 around the HTTP method behavior you reported.

In our lab, we created a POST endpoint and then tested both scenarios separately:

- Editing only the endpoint URL

- Editing only the endpoint script

In both cases, the endpoint remained configured as POST in the Admin UI, in the persisted endpoints.ps1 configuration, and when tested with external HTTP requests. We were not able to reproduce an automatic POST to GET change.

One useful finding is that newly created endpoints default to GET, but editing an existing POST endpoint did not reset the method in our testing.

The next highest-value check would be on your environment if this happens again. If possible, please compare the method shown in the UI with the corresponding sanitized endpoint definition in endpoints.ps1 immediately after the change occurs, and let us know what action was performed just before it changed.

Best regards,

Ruben Tapia

Hello @Dynamic66

Thank you for reporting this issue and for providing the screenshots.

I understand that when creating a new API Rate Limit in PSU 2026.3.3, the save operation takes an unusually long time. After refreshing the page, the Rate Limits list remains loading, even though the new configuration is present in `ratelimits.ps1`.

To help us narrow down the cause, could you please confirm the following?

1. Does this happen with every new Rate Limit, or only with a specific configuration?

2. Could you share the Method, URL pattern, Limit, and Period used for the affected rule?

3. Do you see any errors in the PSU System Logs around the time you save the rule or reload the page?

4. When the Rate Limits page remains loading, does your browser's Developer Tools (Network tab) show any failed or pending requests? If so, please share the HTTP status code and relevant error message.

We will also look into reproducing this behavior in PSU 2026.3.3 to better understand what may be happening.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

Best regards,

Ruben Tapia

Hello @realslacker

Thank you for your patience.

I was able to reproduce the reported behavior in PSU 2026.3.3 and confirmed that the same exception also occurs in 2026.3.2.

Additional testing confirmed that the issue occurs when a `[string[]]` parameter contains a value and the user switches between the Parameters and Action Preferences tabs. The behavior was reproduced consistently across multiple attempts.

Based on these findings, I'll proceed with an internal escalation for further investigation.

I'll share any relevant updates here as they become available.

Best regards,

Ruben Tapia

Hello @realslacker

Thank you for reporting this issue and for providing clear reproduction steps.

The error appears to occur when returning to the Parameters tab after switching to Action Preferences with a `[string[]]` parameter.

I’ll work on reproducing this behavior in PSU 2026.3.3 using your example and check whether it also occurs in an earlier version.

I’ll share my findings here once the testing is complete.

Best regards,

Ruben Tapia

Hello @Dynamic66

Thank you for the additional information.

This is very useful. We will adjust the lab to focus specifically on the HTTP method behavior, especially whether a POST endpoint can unexpectedly revert to GET after changes to the endpoint configuration or script.

We will include this scenario in the next round of testing and update the thread with the results.

Best regards,

Ruben Tapia

Hello @bcaydelotte

Thank you for the additional details and the system log.

The log gives us a much clearer picture. PSU is loading the PostgreSQL provider, but it fails while parsing the configured connection string:

System.ArgumentException: Couldn't set data source (Parameter 'data source')

The failure occurs inside the Npgsql PostgreSQL connection-string processing before PSU actually establishes a connection to a PostgreSQL server. This means the immediate issue does not appear to be related to the Windows service account or Windows Server 2025.

Since SQLite works correctly on the same server, I would like to verify what the installer generated when PostgreSQL was selected.

Could you please share only the sanitized portions of appsettings.json containing:

• The Plugins section

• The Data / ConnectionString setting

Also, when selecting PostgreSQL in the MSI, did you enter PostgreSQL connection information, or did you leave the remaining database settings at their defaults?

If the installer selected the PostgreSQL provider while leaving a SQLite-style Data Source value pointing to database.db, that would explain the startup failure. We would then want to reproduce that exact installer flow before determining whether this is an installer issue.

Best regards,

Ruben Tapia

Hello @meunier

Thank you for providing the logs. I reviewed them and found an important detail.

The Set-PSULicense diagnostic included in the logs is currently failing before it reaches the external Devolutions licensing service. The connection is being refused locally when the cmdlet attempts to communicate with the PSU instance on localhost:5000.

The logs also show that PSU had already stopped before that diagnostic was executed.

Please first make sure the PowerShell Universal service is running and confirm that the local PSU endpoint is reachable. Based on the logs, you can verify this with:

Test-NetConnection localhost -Port 5000

Once the local connection succeeds, please retry Set-PSULicense or the license operation from the PSU interface.

It is possible that restoring the local PSU connection will resolve the current Set-PSULicense failure. However, if you still receive the original "The SSL connection could not be established" / "unexpected EOF" error after PSU is running and the local endpoint is reachable, please note the exact timestamp and provide only the sanitized System Log entries around that attempt. That will allow us to determine whether the remaining failure is occurring during the external license validation.

Also, the ZIP currently attached contains environment-specific information. Since this is a public forum, I recommend removing that attachment and posting only the minimum sanitized log excerpt needed for troubleshooting.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs.

Please SEND logs to ruben.tapia@ironmansoftware.com

Best regards,

Ruben Tapia

Hello @Guenther Schmitz

Thank you for the update.

Since you are now running PSU 2026.3.3, could you please confirm whether the original behavior has changed after the upgrade?

Specifically, are you now able to load the table with the Status MultiSelect filter already initialized and applied to "Active", or does the table still load with the filter empty?

This will help determine whether any additional testing is needed against 2026.3.3.

Best regards,

Ruben Tapia

Hello @bcaydelotte

Thank you for the details and screenshot.

The Service Control Manager event confirms that the PowerShell Universal service is terminating after startup, but the "Incorrect function" message by itself does not identify the underlying exception. Since you are seeing the same general behavior on a fresh Windows Server 2025 installation, I would like to correlate the Windows event with the PSU startup logs before making any configuration changes.

Could you please provide the following?

• Exact PowerShell Universal version and build installed.

• Whether the simple installation using the default service identity produced the same Event ID 7023.

• The relevant portion of the PSU system log covering approximately one minute before and after the service stops.

• Any events from Windows Event Viewer > Windows Logs > Application at the same timestamp, especially entries from Universal.Server.exe, .NET Runtime, Application Error, or Windows Error Reporting.

• Whether the service stops consistently on every manual start attempt.

If no PSU system log is generated at all during startup, please let me know as that is also useful information.

Best regards,

Ruben Tapia

Hello @Mordecai

Thank you for the detailed report and for identifying the specific condition around $PSUBasePath.

The information you provided is enough for us to investigate this without asking you to repeat additional environment details. We will review the behavior in PowerShell Universal 2026.2.5 and validate the scenario where no base path is configured, including the TrimEnd() call in the Docs app.

We will update the thread once we have confirmed the behavior and determined the appropriate next step.

Best regards,

Ruben Tapia

Hello Dynamic66,

Thank you for reporting these items.

We will start by reviewing these four points against PSU 2026.3.3, with particular focus on the Live Log behavior, the documented Write-Host behavior, the Test tab, and the /assets 404 requests in the Admin UI.

At this point, I do not need any additional information from you. I will update the thread once we have completed the initial review.

Best regards,

Ruben Tapia

Hello @meunier

Thank you for the additional details. This helps narrow it down.

The HTTP 404 response from https://quoting.devolutions.net is actually useful here. It means that, from that interactive PowerShell session, DNS resolution, the proxy path, and the TLS connection progressed far enough to receive an HTTP response.

However, the following configuration:

[System.Net.WebRequest]::DefaultWebProxy = ...

only applies to the PowerShell process where you executed it. It does not confirm that the PowerShell Universal service itself is using the same proxy.

For a Devolutions-issued online license, PSU requires access to:

https://quoting.devolutions.net

Please check Settings > General in PSU and confirm whether the Proxy URI is configured there. PSU can also configure its proxy through Set-PSUSetting.

Regarding quoting.devolutions.net.cdn.cloudflare.net, the PSU documentation does not list that hostname as an additional licensing requirement. The documented requirement is access to quoting.devolutions.net, so I would not add the Cloudflare hostname separately based only on the DNS resolution.

Could you please check the PSU proxy configuration after the reinstall and retry the license?

If the proxy is already configured in PSU and the issue remains, please also let me know which PSU version was previously working. At that point, a sanitized System Log excerpt from the failed license attempt would also be useful.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

References:

https://docs.devolutions.net/powershell-universal/licensing

Best regards,

Ruben Tapia

Hello @Guenther Schmitz

Thank you for the clarification.

I completed the reproduction using PSU 4.5.6 with New-UDTable -Data and a Status column configured with FilterType multiselect.

The multiselect filter itself works as expected when used interactively. However, in PSU 4.5.6 there is no supported mechanism to load the table with that column filter already initialized and applied to "Active".

Based on the testing and the implementation available in that version, this is best characterized as a product limitation in the 4.5.6 branch rather than a failure of the multiselect filter itself.

I was able to reproduce the requested scenario consistently, so no additional information is required from your side at this point.

I will check internally whether there are any supported options for this behavior in the 4.5.6 branch, or whether addressing it would require a product change. Since this is an older PSU version, I do not want to make any commitment regarding a change or backport before that feasibility is reviewed.

I will update the thread once I have more information.

Best regards,

Ruben Tapia

Thanks @Guenther Schmitz will adjust my lab.

Regards,

Hello @Andreas

Thank you for the detailed report and for including a minimal reproduction. The information you provided is sufficient for us to begin validating this behavior on our side.

We will focus the initial reproduction on the specific configuration-load scenario you described, using API__SecurityModel=Permissive and Get-PSUIdentity -Integrated from a .universal configuration file.

We will also compare the behavior across the relevant versions, including 2026.2.4 as the last version you reported working and the 2026.3.x versions where the issue occurs. We will first isolate the behavior in a minimal Docker environment before adding the multi-node and PostgreSQL variables if they are required to reproduce it.

The 2026.3.2 and 2026.3.3 release notes do include changes related to the Integrated API Security Model and -Integrated behavior, so we want to verify specifically whether the configuration-load context is still producing an authentication failure under the Permissive model.

At this point, I do not need additional information from you. I will update the thread once we have results from the reproduction.

References:

https://devolutions.net/powershell-universal/release-notes/

Best regards,

Ruben Tapia

Hello @meunier

Thank you for reporting this.

Since the SSL error occurs both when adding the license through the UI and when using Set-PSULicense, I would first like to rule out an outbound connectivity, proxy, or TLS inspection issue from the PSU host.

Could you please confirm the following?

• What operating system and hosting method are you using, such as Windows Service, IIS, or Docker?

• Is this an online or offline license?

• Was the license originally issued by Ironman Software or Devolutions? Please do not post the license key.

• Does this server use an outbound proxy, SSL/TLS inspection, or HTTPS filtering?

• Was this license working previously on this server or on an earlier PSU version?

For online licenses, PSU needs outbound access to the appropriate licensing service. If possible, please also confirm whether the PSU server can establish an HTTPS connection to the corresponding licensing endpoint.

If the connection succeeds but PSU still reports the error, please share a sanitized excerpt of the PSU log covering the license installation attempt, including the exception and stack trace.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

References:

https://docs.devolutions.net/powershell-universal/licensing

Best regards,

Ruben Tapia

Hello @mshepard70

Thank you for reporting this.

The error indicates that the request generated by Set-PSUCache is exceeding the 30,000,000 byte request body limit. The CSV file size on disk does not necessarily represent the final request size because the imported PowerShell objects must be serialized before they are sent.

To determine whether this is a regression in 2026.3.3.0, could you please provide:

• The exact PSU version where the same script and dataset last worked successfully.

• A minimal sanitized example showing how the CSV is imported and how Set-PSUCache is called.

• Whether you are using parameters such as -Persist or -Integrated.

• Whether this is affecting a production environment and whether you currently have a workaround.

Please do not upload the CSV itself. Once we have the previous working version and the command structure, we can determine the most appropriate comparison and reproduction path.

I also reviewed the current 2026.3.3.0 release notes and did not find a documented change specifically related to Set-PSUCache request size limits.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

References:

https://devolutions.net/powershell-universal/release-notes/

Best regards,

Ruben Tapia

Hello @Guenther Schmitz

Thank you for providing the PSU version and the minimal example.

Since you are running PSU 4.5.6, I will reproduce the scenario against that same version in an isolated Docker environment and use your -Data based implementation as the reference.

I also noticed that your original post referred to a MultiSelect filter, while the sample currently uses:

-FilterType autocomplete

I will take that difference into account and validate the relevant filter behavior so we do not assume that both filter types behave the same way.

Once the reproduction is complete, I will share the findings here. If the testing identifies behavior that requires a product change, the feasibility of making a change specifically for the 4.5.6 branch would need to be assessed by the Development team. I do not want to make any commitment regarding changes to that version before the behavior and scope are confirmed.

Best regards,

Ruben Tapia

Hello @SunnyJ

Thank you very much for the update and for confirming the results after upgrading to PSU 2026.3.3.

I am glad to hear that the application is loading normally again and that you are able to access the Admin Console.

The additional detail regarding the older license file is also very helpful, especially considering the related fix included in 2026.3.3. We will keep that information with the case findings as part of the final technical context.

Thank you as well for all the testing, logs, and follow-up information you provided throughout the investigation.

This topic can now be marked as resolved.

Best regards,

Ruben Tapia

Hello @jameshennessy

Thank you for confirming those details. Since the server does not require a proxy, there is no TLS or SSL inspection, and the issue returned after the restart even though the upgrade to 2026.3.0 had temporarily restored functionality, I would like to review the complete PSU System logs covering the affected period.

Please collect the System logs from:

C:\ProgramData\PowerShellUniversal\Logs\System

If possible, include the files covering:

- The VM restart when the issue reappeared.

- The startup failure immediately after the restart.

- At least one of the time windows when a scheduled script should have executed but did not.

- The period up to the most recent occurrence of the issue.

Because the complete logs may contain environment specific information, please do not upload them to this public thread. You can compress the relevant System log files into a ZIP and send them directly to:

ruben.tapia@ironmansoftware.com

Before sending them, please review the files and remove any credentials, tokens, license keys, complete connection strings, or other sensitive information that is not required for troubleshooting.

There is no need to send the complete PowerShellHost logs or a full support bundle at this stage. The System logs are the primary evidence I would like to review first.

Best regards,

Ruben Tapia

Hello @jameshennessy

Thank you for the additional information and logs. The stack trace is especially useful because the SSL failure occurs while PSU is attempting a licensing operation during startup.

I also noted your latest update that the Portal Apps remain accessible, but the scripts attached to your daily schedules have not run.

Could you please confirm the following?

- Did the scheduled scripts stop running immediately after the same VM restart that caused the Admin and Portal issue?

- Does this server require a proxy to access the Internet, or does it have direct outbound HTTPS access?

- Is any TLS or SSL inspection performed by a firewall, proxy, or other security appliance for outbound traffic from this server?

- Were there any recent changes to the proxy, firewall, TLS inspection, certificates, GPOs, or other network policies before the issue appeared?

- Which account type is the PowerShellUniversal Windows service running under: Local System, Network Service, or a dedicated service account?

- Are any HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, or NO_PROXY environment variables configured on the server or for the PowerShellUniversal service account? You do not need to post their values, only whether they are configured.

- When the issue occurred previously on PSU 2026.2.5, did restarting, upgrading, or making any network-related change restore functionality?

For now, please do not make changes to the license file, certificates, IIS bindings, reverse proxy, firewall, or PSU configuration. I would like to establish whether the failed outbound SSL connection is related to the service context or network path first.

Best regards,

Ruben Tapia

Hello @Matthew Morrow

Thank you for the detailed information.

From the error shown, IIS is returning the 404 before the request reaches the expected PowerShell Universal endpoint. The behavior also suggests that the nested IIS path may not be preserved when the extension builds the API request, but I do not want to assume that is the cause until we confirm the exact versions and hosting path.

Could you please confirm the following?

1. The exact PowerShell Universal version.

2. The exact Devolutions PowerShell Universal VS Code extension version.

3. Whether /Beta is the IIS application or virtual application path where PowerShell Universal is hosted.

4. The URL format you normally use to access the PowerShell Universal Admin Console in a browser. You can sanitize the hostname, for example:

https://<INTERNAL_FQDN>/Beta

For now, there is no need to provide additional logs. The IIS 404 response already gives us a useful starting point.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

Once I have those details, I can narrow this down and determine whether we need to reproduce the nested IIS configuration independently.

Best regards,

Ruben Tapia

Hello @SunnyJ

Apologies for the delay in getting back to you. I have been working through several lab investigations in parallel, and I wanted to make sure I had a meaningful update before posting back here.

From the first round of testing, I was not able to reproduce the crash in my lab with PSU 2026.3.1 under IIS using SQLite. A clean InProcess deployment remained stable, and I also tested an upgrade-style scenario using a 2026.1.2 baseline with the 2026.3.1 runtime without reproducing the w3wp.exe crash.

I was also able to confirm that the session cookie CryptographicException shown in the logs can occur without terminating the PSU process, so at this point I do not consider that warning to be the primary cause of the crash.

Since that first lab cycle, additional diagnostic results have been received through our internal support process. The engineers involved are coordinating those findings with the ongoing reproduction work so that the public thread and the internal investigation remain aligned and we do not ask you to repeat tests you have already completed.

The case is currently under active internal technical review. At this stage, we are not treating OutOfProcess as a validated workaround, nor are we attributing the root cause to the session cookie warning, SQLite, or any specific faulting module without stronger evidence.

No additional action is required from you through the forum at this moment. We are reviewing the latest evidence internally, and I will update this thread again today as we consolidate the confirmed findings.

Best regards,

Ruben Tapia

Hello @jameshennessy

Thank you for the additional detail. The fact that your Portal Apps are still launching and can be accessed directly is useful because it suggests that PSU is at least partially operational, while the Admin and Portal pages are encountering the SSL connection error.

To narrow this down, could you please provide the following:

- Was PSU 2026.3.0 a new installation or an upgrade? If it was an upgrade, which version were you running previously?

- Were the Admin and Portal pages working normally on 2026.3.0 before the VM restart?

- How is PSU hosted on this server: directly as a Windows service, through IIS, behind a reverse proxy, or another configuration?

- Please provide the relevant PSU log entries from the startup immediately after the restart, including the complete exception and inner exception surrounding the SSL failure.

For now, I would prefer to review the logs before recommending certificate, TLS, configuration, upgrade, or rollback changes, since the current error does not yet identify which connection is being closed.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

Best regards,

Ruben Tapia

Hello @Guenther Schmitz

Thank you for the details.

I understand that the MultiSelect filter itself is working correctly, but you would like the table to load with the status column already filtered to "active".

I also reviewed the GitHub issue you referenced. It is relevant to initializing table filters, but it does not clearly confirm how this should be configured for a MultiSelect filter.

Could you please share:

• Your exact PowerShell Universal version.

• A minimal example of the New-UDTable and the status column definition.

• Whether the table is using -Data or -LoadData.

With that information, I can verify the behavior specifically for your implementation rather than assuming that the older AutoComplete example applies to MultiSelect as well.

Because this is a public forum, please sanitize all evidence before posting. Remove credentials, tokens, license keys, cookies, private keys, full connection strings, email addresses, usernames, customer data, tenant or account identifiers, internal domains, hostnames, IP addresses, and private URLs. Please do not upload unredacted HAR files, memory dumps, database backups, or complete configuration files to this public thread.

Best regards,

Ruben Tapia