PSU 2026.3.4 – PowerShell 7 handshake failures and internal gRPC connection errors
PSU 2026.3.4 – PowerShell 7 handshake failures and internal gRPC connection errors
Hello everyone,
I'm currently evaluating PowerShell Universal 2026.3.4 for potential use in our environment. I have used PSU in the past and am now considering using it again.
I installed PSU locally on a Windows 11 machine using the MSI installer, running it as a Windows service under `LocalSystem`.
Unfortunately, neither the default PowerShell 7 environment nor an additional custom PowerShell 7 environment works. Even simple test scripts fail to execute. The `Integrated` environment generally works.
The PSU logs show:
[WRN] Job process exited before handshake was received.
PowerShell process 2724 exited before responding
to the job handshake.
The host logs contain:
[ERR] Failed to start server.
Grpc.Core.RpcException:
StatusCode="Unavailable"
Detail="failed to connect to all addresses"
at IJobAgent.SetAgentInformation(...)
at UniversalAutomation.Host.GrpcProtocol.SetClientPort(...)
Additionally, commands such as `Get-PSUApp -Integrated` and `Get-PSUEndpoint -Integrated` fail in the built-in PSU console. Both take quite some time before returning the same gRPC error:
StatusCode="Unavailable"
Detail="failed to connect to all addresses"
So far, I have checked the following:
Tested the PSU service under both `LocalSystem` and an AD service account, with no difference.
Verified that the internal gRPC client port is reachable locally over both IPv4 and IPv6.
Checked proxy/NO_PROXY settings and Kestrel endpoints.
Reviewed `PSModulePath` without finding any obviously invalid directory paths.
Found no related application crash events in the Windows Event Log.
Some host logs also contain:
[ERR] Error checking module path
System.ArgumentException:
The path is not of a legal form.
at UniversalHost.AgentService.Initialize(...)
My question: Am I missing a basic configuration step or prerequisite for a standard MSI installation running as a Windows service? Or is this a known issue with PSU 2026.3.4?
Since both external PowerShell 7 environments and internal PSU cmdlets are affected, I suspect the issues might be related to PSU's internal gRPC communication.
Any suggestions would be greatly appreciated.
Thanks in advance!
All Comments (4)
Having the same issue here after upgrading, relevant post: Job fails to run on PS5.1 after upgrade from 2026.2.4 to 2026.3.4 - Devolutions Forum
We use integrated env most and that works for PSCore, though I saw this error when using get-psuscript/invoke-psuscript, or if we use PS5.1 env, I'll test it on another env such as ps 7
Just tried on 'PowerShell Latest' and had the same issue, so it being an issue on 5.1 is not relevant, it seems any non integrated environment throws this for me, or internal psu commands within the integrated environement using the -integrated flag
Not sure if this is related to our issues as well. We are on a different version though. https://forum.devolutions.net/topics/57219/job-timout-issue#247681
Hello Daniel,
Thank you for the detailed description and the logs.
Your symptoms match a known issue in PowerShell Universal 2026.3.x (ticket PSU-1520, for internal reference only).
Starting with 2026.3.x, PSU connects to its PowerShell 7 processes over the IPv6 loopback address ::1.
When a proxy is set with the HTTP_PROXY or HTTPS_PROXY environment variables, these local gRPC calls are also sent to the proxy, unless NO_PROXY lists ::1.
A NO_PROXY value of localhost,127.0.0.1 is no longer enough.
This is why the Integrated environment works, while PowerShell 7 jobs and the -Integrated cmdlets in the console fail with "failed to connect to all addresses".
It also explains why the port answers when you test it directly.
To confirm, please run these two lines as a script in the Integrated environment.
Get-ChildItem Env: | Where-Object Name -match 'proxy'
$env:PSModulePath -split ';'
The Integrated environment runs inside the PSU server process, so it sees the same variables as the service.
Please send me the output either way, since the second line also helps with the "Error checking module path" message in your host log.
If the first line returns HTTP_PROXY, HTTPS_PROXY or GRPC_PROXY, please add ::1 and [::1] to NO_PROXY where the proxy variables are defined, and keep your existing entries.
NO_PROXY=localhost,127.0.0.1,::1,[::1]
Then restart the PowerShellUniversal service and run the script again to check that the new value is visible.
If the service still shows the old value, please reboot the machine.
PowerShell 7 jobs should then complete normally.
If the first line returns nothing, the proxy is not the cause.
In that case, please also send the System and PowerShellHost logs from C:\ProgramData\PowerShellUniversal\Logs for one failed job.
The fix is planned for PowerShell Universal 2026.3.5, which is not released yet.
That release should remove the need for the NO_PROXY change.
For background on the environment types, see https://docs.devolutions.net/powershell-universal/config/environments
Best regards,
Patrick Ouimet
Thanks for the explanation and the helpful suggestions!
Adding ::1 and [::1] to NO_PROXY resolved my issue.
I initially still had permission errors when using Invoke-PSUEndpoint -Integrated and other cmdlets with -Integrated. I worked around this in my application by enabling -GrantAppToken and switching to token-based API calls.
My first PSU application is now working as expected.
Thanks again for your support!