I’m using a UD app secured with Windows Active Directory authentication in PowerShell Universal. I’m having trouble with frequent logouts and session timeouts. I do need authentication in place, but I would like my session to remain valid for up to 24 hours of inactivity before I’m logged out.
What I’m seeing now is a message that says: “Your session has timed out. Refresh the page.” I don’t mind seeing that message or clicking the refresh button, but after I click refresh I’m fully logged out and have to sign in again with my AD credentials. What I would like instead is for the page to simply reload and keep me authenticated.
I’ve tried adjusting the session timeout in appsettings.json and adding a JavaScript keep-alive on the page, but neither has worked. Are there additional configuration settings for UD apps using Windows authentication in PowerShell Universal that might be overriding the session timeout or causing this behavior?
Product: PowerShell Universal
Version: 5.6.12
Hello Brian,
Thank you for the details and for confirming you are on PowerShell Universal 5.6.12.
In PSU v5, there are two separate timeout controls that can affect what you are seeing: the web server session timeout and the app session timeout. For a 24-hour session, the first thing I would like to confirm is how the app is being defined. Could you paste the portion of your app definition (for example, the section where the app is created and authentication is configured) and confirm whether you are using New-PSUApp or New-UDApp?
If you are using New-PSUApp, please try explicitly setting the app timeout to 1440 minutes (24 hours) using -SessionTimeout 1440. If you also mean “24 hours of no mouse or keyboard activity,” then additionally set -IdleTimeout 1440 (idle timeout is separate and disabled by default).
Separately, if you changed "SessionTimeout" in appsettings.json, please confirm where you made that change. To ensure the setting persists (and is actually being used), it is recommended to place overrides in $Env:ProgramData\PowerShellUniversal\appsettings.json rather than only editing the install directory file.
Finally, does this happen mostly when the browser tab is left in the background? Some browsers pause inactive tabs, which can allow sessions to expire even though the page is still open.
https://docs.powershelluniversal.com/apps/sessions
https://docs.powershelluniversal.com/config/settings
https://docs.powershelluniversal.com/security/enterprise-security/windows-sso
https://docs.powershelluniversal.com/config/hosting/hosting-iis
Best regards,
Ruben
I’m using a UD app secured with Windows Active Directory authentication in PowerShell Universal. I’m having trouble with frequent logouts and session timeouts. I do need authentication in place, but I would like my session to remain valid for up to 24 hours of inactivity before I’m logged out.
What I’m seeing now is a message that says: “Your session has timed out. Refresh the page.” I don’t mind seeing that message or clicking the refresh button, but after I click refresh I’m fully logged out and have to sign in again with my AD credentials. What I would like instead is for the page to simply reload and keep me authenticated.
I’ve tried adjusting the session timeout in appsettings.json and adding a JavaScript keep-alive on the page, but neither has worked. Are there additional configuration settings for UD apps using Windows authentication in PowerShell Universal that might be overriding the session timeout or causing this behavior?
Product: PowerShell Universal
Version: 5.6.12
Hello. I am using a UD-App with pages. Ex. “New-UDApp -Title ‘Admin Dashboard’ -Pages $Pages -Theme $Theme “.
I can confirm the change was made here Env:ProgramData\PowerShellUniversal\appsettings.json
I use Firefox and I left the tab open in the foreground and after about 20 minutes I get a message that says “Your session has timed out”.
In PSU v5, the documented default web server session timeout is 25 minutes, and sessions are intended to be sliding so they should not expire while the window is open and active. Since you are seeing the timeout at around 20 minutes even with the tab in the foreground, that points more to the hosting layer or a process recycle than a simple “tab sleep” scenario.
Two things that would help narrow this down quickly:
-
Are you hosting PSU under IIS or self-hosted (Kestrel)? If IIS, please review the application pool idle timeout and recycling settings. IIS recycling can remove all app sessions, and the IIS hosting guide calls out disabling Idle Time-out and setting recycling intervals appropriately.
-
Can you paste the exact SessionTimeout setting you currently have in the ProgramData appsettings.json, and confirm you restarted PSU after the change? The docs recommend ProgramData overrides specifically so settings persist across upgrades.
One additional detail: with Windows Authentication, PSU also caches group membership claims for the configured session timeout (default 25 minutes). If the effective session timeout is still low, this caching aligns with what you are observing.
I am running it via Kestrel. It could be the session timing out in the background but 25 minutes does sound about right when the dashboard logs me out. This isn’t an end of the world issue for me but if it can be fixed with something I am doing simple then I’m game. Below is my appsettings.json.
{
“Kestrel”: {
“Endpoints”: {
“HttpsFromPem”: {
“Url”: “https://:443",
“Certificate”: {
“Path”: “C:\Scripts\Certs\REDACTED.pem”,
“KeyPath”: “C:\Scripts\Certs\REDACTED.key”
}
},
“HttpsAlternate”: {
“Url”: "https://:8443”,
“Certificate”: {
“Path”: “C:\Scripts\Certs\REDACTED.pem”,
“KeyPath”: “C:\Scripts\Certs\REDACTED.key”
}
}
}
},
“Plugins”: [
“SQL”
],
“Data”: {
“RepositoryPath”: “%ProgramData%\UniversalAutomation\Repository”,
“ConnectionString”: “Server=CS-API-WIN-01\SQLEXPRESS;Database=PowerShellUniversal;Integrated Security=True;TrustServerCertificate=True”
},
“Mode”: “Server”,
“PSUTelemetry”: false,
“SessionTimeout”: 10080
}
Based on the documentation, app sessions are intended to be sliding and should not expire while the window is open and active. Since you are seeing the timeout at roughly 20 minutes even with the tab in the foreground, that pattern more commonly aligns with the hosting layer recycling or idling the worker process rather than a browser “tab sleep” scenario.
To help me narrow this down and also try to replicate the behavior on my side, could you confirm which installation and hosting method you are using:
-
Are you hosting PowerShell Universal under IIS, or running it as the default self-hosted service (typical MSI install)?
-
What is the exact SessionTimeout value currently set in your ProgramData appsettings.json, and did you restart the PowerShell Universal service after making the change?
If you are hosted in IIS, please also review the application pool settings that can cause session loss, specifically Idle Time-out and Recycling intervals. The IIS hosting documentation recommends disabling the idle time-out and setting the regular recycling interval to 0 to avoid unexpected restarts that disconnect sessions.
Once I have the hosting type (IIS vs self-hosted) I will attempt to reproduce the behavior and advise the next steps based on the results.
-
Are you hosting PowerShell Universal under IIS, or running it as the default self-hosted service (typical MSI install)?
- I am running it as the default self-hosted service. I do not have the IIS roll installed on the server.
-
What is the exact SessionTimeout value currently set in your ProgramData appsettings.json, and did you restart the PowerShell Universal service after making the change?
- “Mode”: “Server”,
“PSUTelemetry”: false,
“SessionTimeout”: 10080.
- Yes I have restarted the entire server a few times since making the change.
If you think running in IIS is preferred though I could move over to that.
I have my server installed the same way, MSI as a service, and I don’t have the same experience, I mean, sessions will timeout after 25min and provide the popup to refresh, but this is only if they’ve been left idle as Ruben mentioned. If I’m active, they dont time out.
Also when they do timeout, my experience is that the page refreshes, logs me back in (I use azure OIDC) and put me right back on the page I was previously on - again seems different from what you’re describing your experience to be.
Not sure if it has anything to do with the differences in authentication mechanisms but I would certainly recommend using OIDC or SAML via Azure/Entra if you can, it’s been a pretty seamless experience once it’s setup.
It is possible then I am trying to do something that is not supposed to be done by design. If the tab is in the background or foreground I will get the below message after some time. When I press refresh page it will fully log me out of the software and require a logon. Since this is a dashboard I was hoping for it to stay up indefinitely after it is logged in. Again I might be misusing features of the software and it might not be designed to work this way. Below are what I am being presented with.
Thank you for confirming you are hosting with Kestrel and that the behavior aligns with an approximately 25-minute timeout. I also see you have "SessionTimeout": 10080 configured in your appsettings.json.
Per the PSU sessions documentation, the default web server session timeout is 25 minutes and it is controlled by SessionTimeout in appsettings.json. Since you are still observing the default behavior even after setting a much higher value, the next step is to verify that the running PSU instance is actually loading the file you modified.
To help me reproduce this on my side and narrow down why the effective timeout remains at the default, could you confirm your installation type:
- Is this the standard MSI install running as the Windows Service (self-hosted Kestrel), or are you hosting PSU under IIS?
Additionally, please confirm:
-
The exact path of the appsettings.json you edited (for example, $Env:ProgramData\PowerShellUniversal\appsettings.json) and whether the PSU service was restarted after the change.
-
If possible, share the relevant excerpt from your system log around startup so we can confirm configuration is being applied. Logs are typically located under %ProgramData%\PowerShellUniversal.
Once I have the installation type (IIS vs MSI self-hosted), I will attempt to replicate the behavior and provide the next recommended steps.
