Complete PSU crash following modification of an application's runtime environment
Complete PSU crash following modification of an application's runtime environment
------------------------------------------------------------
Product: PowerShell Universal
Version: 2026.3.3
Hosting: IIS
OS: Windows Server 2025
Database: SQL Server
------------------------------------------------------------
In PSU, it is possible to create an application that runs on PowerShell 7. It will start up and display the application as follows:
New-UDApp -Content { 'Hello, everyone!' }
However, if the environment is changed to "Integrated" and then switched back to PowerShell 7, the application remains stuck in a "Deployed" state, and subsequently, no one can log in to PSU using a domain account.
The following error message appears:
Status(StatusCode="Unavailable", Detail="failed to connect to all addresses", DebugException="Grpc.Core.Internal.CoreErrorDetailException: {"created":"@1793109706.532000000","description":"Failed to pick subchannel","file":"..\..\..\src\core\ext\filters\client_channel\client_channel.cc","file_line":3218,"referenced_errors":[{"created":"@1793109706.532000000","description":"failed to connect to all addresses","file":"..\..\..\src\core\lib\transport\error_utils.cc","file_line":165,"grpc_status":14}]}")
The issue persists even after restarting the IIS service; only the local PSU admin user is able to log in.
To restore the service, one must disable the application's automatic startup, switch it back to "Integrated," and then restart the IIS service once more.
Furthermore, it is not possible to run an application on PowerShell 7 while also executing it as a GMSA (Group Managed Service Account).
Thank you in advance for your expertise.
All Comments (1)
Hello Dylan,
Thank you for the detailed steps.
In our lab on 2026.3.3 in IIS with Windows authentication, the pool ran as a gMSA and we restarted the app after each environment change.
With no account in the app's Credential field, the app ran as the pool's gMSA, kept running through Integrated and back and an IIS restart, and a domain account signed in after every step.
With the same gMSA in the app's Credential field, it never started on PowerShell 7, and restarting it failed with "Failed to login user (1326)". It ran on Integrated, which ignores that field, and stopped again back on PowerShell 7, even after an IIS restart. Yours first started on PowerShell 7, so this may not be your case.
If your pool still runs as a gMSA, a PowerShell 7 app runs as that gMSA when the app's Credential field (Execution tab) and its environment's Run As field are empty. The IIS hosting guide also says that with a service account pool, no Run As account can be set and scripts can only run as that account.
https://docs.devolutions.net/powershell-universal/config/hosting/hosting-iis#id-3.1-choosing-an-app-pool-identity
Domain sign-in kept working in our lab even with the app stopped, so I need these details.
1. The system log from that day, to look for app start and connection errors (by default the systemLog files in C:\ProgramData\PowerShellUniversal\Logs\System).
2. Your IIS application pool's identity today.
3. Which account, if any, is in each of those two fields.
4. Whether you restarted the app after each change.
5. Whether domain users sign in with Windows authentication or the login form, and a screenshot of their error if you kept one.
As this topic is public, please send them by forum private message or to service@devolutions.net with case number 00134508.
Best regards,
Michel
Michel Audi