Custom Environments not working after upgrade to 2026.3.3

Hello nikopieper,

Thank you for the log, and for testing with the built-in environments before rolling back.

What the log shows: on some starts, the app's process starts, but when it creates its first runspace, one of its connections back to the PowerShell Universal server fails ("failed to connect to all addresses", in IsDebuggerAttachedAsync). On other starts, the app process did not report back to the server within 30 seconds, and the server terminated it: "App process running but did not response after 30 seconds. Terminating process."

To find what your environments do differently from the built-in ones, we want to run your exact definitions on 2026.3.3 in our lab, with an app and a script. Could you send us:

1. The New-PSUEnvironment lines of your custom environments, from .universal\environments.ps1 in your repository folder (by default %ProgramData%\UniversalAutomation\Repository: https://docs.devolutions.net/powershell-universal/config/repository/). You can copy them from your current 2026.2.3 installation; no upgrade is needed. If that file does not list them, a screenshot of each environment under Manage > Environments > Environments works too.

2. The operating system, and how PowerShell Universal runs: Windows service, IIS, Linux or Docker.

3. Whether the failing apps or scripts use a Run As credential.

One note while you stay on 2026.2.3: if your instance uses a Microsoft SQL Server database, it is affected by security advisory DEVO-2026-0031 (low severity), which applies to 2026.2.5 and earlier and is fixed in 2026.3.0: https://devolutions.net/security/advisories/DEVO-2026-0031/

Best regards,

Michel

Hello,

PSUs runs on Windows Server 2022 with the integrated Webserver and the apps are not using a Run As Credential.

I also tried creating a new env in 3.3 but this had the same error.

these are our environments, I changed the Names to numbers, but there are no special characters in the regular name:

$Parameters = @{

Name = '1'

Path = 'C:\Program Files\PowerShell\7\pwsh.exe'

Modules = @('*')

Variables = @('*')

PersistentRunspace = $true

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = '2'

Variables = @('*')

PersistentRunspace = $true

Type = 'PowerShell7'

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = 'Integrated'

Path = 'Universal.Server'

Variables = @('*')

Description = 'An environment for running scripts directly in the PowerShell Universal server.'

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = '3'

Path = 'C:\Program Files\PowerShell\7\pwsh.exe'

Modules = @('activedirectory','hdi.credmod','hdi.psutools')

Variables = @('*')

PersistentRunspace = $true

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = 'PowerShell 7'

Variables = @('*')

Description = 'The PowerShell 7 version included with PowerShell Universal.'

Type = 'PowerShell7'

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = 'PowerShell 7.4.12

'

Path = 'C:\Program Files\PowerShell\7\pwsh.exe'

Variables = @('*')

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = '4'

Path = 'C:\Program Files\PowerShell\7\pwsh.exe'

Modules = @('*')

Variables = @('*')

PersistentRunspace = $true

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = 'test'

Path = 'C:\Program Files\PowerShell\7\pwsh.exe'

PersistentRunspace = $true

}

New-PSUEnvironment @Parameters

$Parameters = @{

Name = 'Windows PowerShell 5.1'

Variables = @('*')

Description = 'Windows PowerShell 5.1'

Type = 'WindowsPowerShell'

}

New-PSUEnvironment @Parameters

Hello nikopieper,

Thank you for your environment definitions.

We made four clean test installations of PowerShell Universal 2026.3.3 in our lab, as a Windows service, with PowerShell 7.4.12 as the Path of your environments that point at pwsh.exe (in two of the four installed at C:\Program Files\PowerShell\7), and ran one app and one script in six of your environments (without your hdi modules).

On the first start, in two of the four installations, some apps failed with one of the errors in your log, which starts with:

Failed to get dashboard. Status(StatusCode="Unavailable", Detail="failed to connect to all addresses" It came from IsDebuggerAttachedAsync, as in your log, and those apps did not recover within the next few minutes. This happened in your environments test and 2 and in the built-in PowerShell 7. After each of our two service restarts, all apps started. Your script failures and your 30-second error did not occur in these runs.

Could you tell us:

1. After your upgrade to 2026.3.3, did you restart PowerShell Universal (its service, if it runs as one) or the server before reverting?

2. If you can repeat the upgrade on a snapshot: first check your apps and scripts and note which environments fail, then save a zip of %ProgramData%\PowerShellUniversal\Logs (with its PowerShellHost and System subfolders). Then restart PowerShell Universal once, check again, and send us both results and the zip before you revert.

Best regards,

Michel

Hello,

1. Yes i restarted the server and services several times

2. i sent them to you via direct message

Hello nikopieper,

Thank you for the logs.

They show that the restart did not help on 2026.3.3: after it, apps still stopped with "App process running but did not response after 30 seconds". So it does not behave like the first-start failure we reproduced last week, which cleared on restart. In the User log, PowerShell Universal Apps Documentation starts, while IPMP fails when it connects back to the server. Your logs also show a proxy, which refuses the server's update check (status 403).

In our lab we reproduced a similar pattern with proxy environment variables, which we have not yet seen on your server. In 2026.3.3, an app or script process connects back to the server at ::1 or 127.0.0.1; 2026.2.3 and 2026.2.5 (the version in your logs) use localhost and 127.0.0.1. With http_proxy and https_proxy set for the PowerShell Universal service and no_proxy=localhost,127.0.0.1, every app and script in five tested environments, built-in PowerShell 7 included, failed on 2026.3.3 (apps with the same 30-second error), while 2026.2.3 ran them all. With no_proxy=localhost only, an app in the Integrated environment kept working while the others failed. With no_proxy=localhost,127.0.0.1,::1,[::1], every app and script ran on 2026.3.3, also after a service restart.

Could you check:

1. Whether http_proxy, https_proxy or no_proxy are set on that server: as system environment variables, as user environment variables of the account that runs PowerShell Universal, or, if it runs as a Windows service, on the service itself. Please send us the value of no_proxy and where it is set.

2. If they are set: on a snapshot with 2026.3.3 installed, make sure no_proxy contains localhost,127.0.0.1,::1,[::1] wherever it is set (keep its other entries), restart the server, and check your apps and scripts again.

If none is set, please tell us how the proxy is configured there.

Best regards,

Michel

I added ::1,[::1] , everything else was there before including the IP and FQDN of the Server.

Now it seems to work again. All Apps are starting, i will monitor now if all scripts and automations are also working.

Was there anything changed in 2026.3 which result in that ?

without ::1,[::1] it worked for over a year now in the old versions

Hello nikopieper,

Thank you for testing it, and good to hear that all your apps start again.

Yes, this changed in 2026.3. When an app or script process connects back to the PowerShell Universal server, 2026.3.3 connects to ::1 or 127.0.0.1, whichever answers first; 2026.2.3 and 2026.2.5 connected to localhost or 127.0.0.1. When no_proxy does not contain ::1, a connection to ::1 goes to the proxy instead of to the server: in our lab, the proxy received these connections as requests for [::1], and received none while ::1,[::1] were in no_proxy. This matches your result, where adding ::1,[::1] was the only change to no_proxy.

We have reported this to our development team. Please keep ::1,[::1] in no_proxy, also when you upgrade again.

If a script or automation still fails, please send us a zip of %ProgramData%\PowerShellUniversal\Logs from that day, with the time it failed.

Best regards,

Michel

Hi Michel,

Ok i could not read that out of the release notes but its fixed now.

Yesterday all scripts worked as expected, i will now update our other Prod Systems

Hello nikopieper,

Thank you for confirming that your scripts also ran as expected.

For your other production servers: on each one where http_proxy or https_proxy is set, make sure no_proxy contains localhost,127.0.0.1,::1,[::1] wherever it is set there (keep its other entries), as on this server, and restart the server after the update to 2026.3.3. Without it, apps and scripts there can fail after the update in the same way.

If an app or script fails on one of them after the update, please reply here with a zip of %ProgramData%\PowerShellUniversal\Logs from that server and the time it failed.

Best regards,

Michel