Help with Session Timeout

Is there a way to set the session timeout value, and does anyone know what the default is? Since upgrading to version 2.7 I have started using the UDStudio plugin for visual studio code, and have noticed that sessions are staying open for an unknown amount of days. For example, no one connected to my UD site over the weekend yet, I have 18 sessions running when I looked this morning (Monday). So I would assume they are sessions still running from last week. I do log every time a user gets authenticated so I am confident these are stale sessions not being closed.


Something is definitely wrong. Please file a bug. The timeout should be 25 minutes. Can you also gather a log from your environment with Enable-UDLogging?

Is there a way to share the log privately?

You can DM me on here or send an email to adam[at]

I am working on getting you the log file. I need to redact sensitive info first.

1 Like

@adam I emailed you the log file.


1 Like

I think I resolved this issue. At least it works on my machine :wink:

Nightly builds will be published tonight so you should be able to give it a shot tomorrow.

1 Like

Sounds good. I’ll look to test tonight’s build on my test box tomorrow. What do you think was the cause, and will the changes you put in the nightly have any other impact, good or bad? I would assume I may see a performance boost simply because there will be less sessions running in the background. Thanks for your help!

Thanks again,

The cause looks like the scheduled job that is responsible for clearing out the sessions wouldn’t start sometimes causing them to stack up. The issue was that we were reusing a trigger in the quartz scheduler which sometimes threw an exception. It was actually evident in this bug but it appeared that everything was working aside from the error in the log.

What wasn’t working was the scheduled job. I’ve fixed that error and the scheduled job is correctly cleaning out stale sessions like it should.

You might notice a performance improvement and less memory usage. It won’t have to look up as many endpoints with fewer sessions but it’s honestly probably negligible. I would think the memory impact would be the greatest improvement.


Hi @adam :smiley: I installed the nightly build yesterday, and did some testing. So far I have not seen any changes.

There is one thing however, that stands out. When installing the nightly for enterprise, is the expected behaviour to install the UniversalDashboard.Community module along side the UniversalDashboard module? I used the script found here: to install the latest nightly.

I also noticed the script doesn’t account for when the UD module is installed at “C:\Program Files\WindowsPowerShell\Modules” instead of “C:\Users\USERPROFILE\Documents\WindowsPowerShell\Modules”. I addressed this by uninstalling and reinstalling the stable 2.7 UD module to the path referenced in the script. What is the correct way of installing the enterprise nightly?

I did also attempt to download the nightly from here: When I run the module I manually downloaded, I was unable to sign into my dashboard.


You shouldn’t install the enterprise with the community edition. The enterprise module contains all the same functionality of community.

If you install the enterprise nightly and just move it to your program files path, that should work. When you download it manually from the website like that you need to make sure you run “Get-ChildItem | Unblock-File” on the directory otherwise windows won’t load it correctly.

That build also has additional logging added to the session management code so if you could get a log and look for these log messages:

logger.Debug($“Clearing out timed out sessions. IdleTimeout is: {IdleTimeout}”);

logger.Debug($“Session {x} timed out. Last touched: {value.LastTouched}”);

Sorry to be a pain, but I am unable to get the nightly working. Here are the steps I took to install it.

  1. Downloaded the file.
  2. Extracted
  3. Renamed the extracted folder from “UniversalDashboard.1386” to “UniversalDashboard”.
  4. Copied renamed folder to “C:\Program Files\WindowsPowerShell\Modules”.
  5. Opened PowerShell as administrator and then ran “Get-ChildItem -Path C:\Program Files\WindowsPowerShell\Modules -Recursive | Unblock-File”
  6. Started dashboard as normal.

I can visit the site and my login page displays as it normally would. I am however, unable to login. When using the stable version I have functionality written in to log all authentication attempts good or bad. This is written into the script I use for authentication. When using the nightly I am not seeing this log being written to. So it’s like the nightly version isn’t calling on the -AuthenticationMedthod parameter of New-UDLoginPage.

I feel like I’m being an idiot and not doing something correctly. Am I not installing the nightly version the right way?

Thanks :grinning:

Ack. Now I’m seeing this issue as well. I just downloaded the nightly build. Authentication isn’t working. I will look into this today and get another nightly published…Sorry for the hassle.

1 Like

I found the issue. Merge conflict with some of the javascript files. I should have noticed the tests were failing but I didn’t. Tonight’s build will resolve that.

1 Like

I installed “Nightly 20191114.3” and it does appear to improve managing session timeouts. I am no longer seeing sessions stay open for days. :grinning:

I looked for the added logging details in the UDLog file you requested, but I did not see them present in the log.

  • logger.Debug($“Clearing out timed out sessions. IdleTimeout is: {IdleTimeout}”);
  • logger.Debug($“Session {x} timed out. Last touched: {value.LastTouched}”)

If you would like to review the log file, let me know and I will work on removing all of the sensitive info.


That’s great news! I’m not exactly sure why you aren’t seeing logs but if the sessions are being removed then it’s working because it only does it in that one spot. Please let me know if you run into issues.

1 Like