33 Replies

Jason Blanchard Replied

1/28/2021 at 8:43 AM

I'll try to clear out the cookies on my computer, but it looks like it might be something else. I only say that because I'm seeing users from different companies all getting logged out at the same time. A lot of the ones that got logged out earlier have been connected for an hour now. Who knows. I'm going to keep an eye on it throughout the day.

Jason Blanchard Replied

1/28/2021 at 12:30 PM

Here's some more info. I'm using Firefox to login to webmail. I tried to delete any cookies for the site but there were none to delete. But I continue to get logged out. I logged in with a test account in chrome. It's been logged in for 30+ min straight while my Firefox session has logged out 3 times in that 30 min time span. Any idea why there wouldn't be any cookies stored in firefox? It's just strange considering I've never had login issues before the update.

Derek Curtis Replied

1/28/2021 at 1:40 PM

Employee Post

Did you check all your time zone settings? We’ve seen this same issue a few times over the last month or so and it has always been resolved by ensuring time zones are consistent across the browser, device, OS, mail server and any equipment that sits between all of these. (As much as possible.)

Derek Curtis

CCO

SmarterTools Inc.

Jason Blanchard Replied

1/29/2021 at 7:05 AM

Yeah my timezone settings matched. One thing that helped in firefox was I had to disable "Enhanced Tracking Protection" for that site. I think firefox was preventing it from storing cookies? I turned it off yesterday afternoon. I'm going to try to let it stay connected today to see if that resolves it.

Jason Blanchard Replied

1/29/2021 at 7:49 AM

Ok so that didn't fix it. It just logged everyone out of webmail 5 minutes ago.

ActorMike Replied

1/31/2021 at 6:48 AM

I've had this issue as well for several months in the admin when impersonating a user. SM won't save drafts and effectively logs out the impersonated user which requires logging back in again.

Bert Garrett-Tuck Replied

4/28/2021 at 2:29 PM

Hi

My webmail users have begun to have the issue described here and are becoming a bit irate. I have even been randomly kicked out of the web interface when logged in as an admin user.

It started after the V7 update.

Again, timezone settings are all consistent (NZDT at the moment) - and calendar appointment time mismatches have been resolved for the most part.

I've directed everyone to clear their browser's cache and cookies. Even resort to changing to another browser (Chrome vs Edge). They're still kicked out randomly.

Kyle Kerst Replied

4/28/2021 at 3:49 PM

Employee Post

@Jason: Since you're seeing ALL users logged out simultaneously this would indicate the SmarterMail IIS site or application pool might be restarting/timing out. Can I have you check to confirm its set up not to use Start Mode: Always Running, has no periodic recycle time configured, and is set up to restart only once nightly? These settings are all found within the Advanced Settings for the SmarterMail application pool in IIS.

Kyle Kerst

Lead Internal Network/System Administrator

SmarterTools Inc.

JerseyConnect Team Replied

4/29/2021 at 10:23 AM

You're not alone. We've been facing this issue of users getting randomly logged out for several months now. There's at least one other thread on this topic as well, https://portal.smartertools.com/community/a93922/users-get-logged-out-from-webinterface.aspx.

Support had us instruct our users to get Fiddler traces of the issue occurring. After providing those to support the issue has been escalated to development. I suggest opening a support ticket so they can help you get Fiddler traces of the logouts occurring. Hopefully with more data from different customers they'll be able to resolve this faster.

Matt Petty Replied

4/29/2021 at 11:46 AM

Employee Post

Yea, this is a frustrating one because I've seen it happen to me a couple times when impersonating and working on other stuff. We've had a few ideas at what could cause it but every attempt to reproduce results in no problems. I've had this issue on my to-do for a bit now and I've picked it up and tried working with it a couple times. If you're planning on submitting a ticket we can try to find more commonalities as to what could be causing it. Letting us know things like the browser they use, how often it occurs, any actions performed shortly before it happening, and what devices they have connected to their account can help a lot. Also if you can manage to capture this happening while the chrome debugger is open (Ctrl+Shift+i) and capture the network traffic and console window that would help a whole lot, but with how intermittent this is, it's been a challenge.

EDIT: Also additional info that could help is, Are all users seeing it or is it happening to just a couple. This gives me more to look at when trying to figure out commonalities.

Matt Petty

Senior Software Developer

SmarterTools Inc.

https://portal.smartertools.com/kb/a3539/random-or-semi-regular-webmail-logouts.aspx

Patrick Fanning Replied

7/6/2021 at 8:53 AM

Is this not fixed or at least a realistic work around, I have web clients that are really getting ... well not happy.

Lost one client with 40 users over this ...

Only change to the server was the last update install.

Patrick Fanning

CTO Advanced Group

Andrew Barker Replied

7/6/2021 at 9:33 AM

Employee Post Marked As Resolution

During some recent testing, we noticed a SignalR problem which occurred in inactive tabs when using Chromium-based browsers, such as Chrome and Edge. Even once we understood the problem, we were unable to reliably replicate the random logouts, but the nature of the SignalR problems makes it likely that the issues are related.

When a tab is inactive, Chromium extends all intervals and timeouts to at least one minute. Since, by default, SignalR is configured to disconnect after 30 seconds of inactivity, inactive tabs would drop the connection, then reconnect a minute later. Any processes relying on the SignalR connection would fail if they tried to communicate during this minute long disconnect. This includes the process which updates the authentication token held by the client, which in turn could trigger an apparently random logout.

To correct this, we adjusted our SignalR configuration and keep-alive pings to take into account the delay imposed by Chromium browsers. After making these changes, we have not seen any indication of SignalR issues. We included these fixes in the build 7852, released on July 1.

Andrew Barker
Lead Software Developer
SmarterTools Inc.
www.smartertools.com

JerseyConnect Team Replied

7/6/2021 at 9:35 AM

Patrick, there was a fix in 7845 that was suppose to resolve the issue, but our users are still experiencing it.

Employee Replied

7/6/2021 at 1:32 PM

Employee Post

Hi JerseyConnect Team,

I'm sorry to hear that the logout issue is still occurring for your users. The fix we implemented appeared to resolve this for some of our customers, but not all. In order to continue diagnosing the lingering issue, we'll need a Fiddler trace of the logout occurring. If you're able to replicate this issue regularly, will you please work on getting a trace of it occurring? Once you have a trace, please attach it to your support ticket so we can get this to the development team for their review.

Thank you,

JerseyConnect Team Replied

7/7/2021 at 10:58 AM

Looks like I was replying at the same time Andrew was, so I didn't see his update. Interesting to see that this may be SignalR related as we recently had an issue with that as well.

Unfortunately I've been unable to replicate the issue myself. So after I get SM updated I'll ask my customers for new Fiddler traces.

Jane Noel Replied

7/16/2021 at 11:19 AM

I have updated to 7859 last weekend in an effort to solve this problem for one user. After the update I have 2 users complaining of constantly being logged out. We have not been able to replicate the issue.

I saw Andrea mentioned Fiddler. I need to know more about that.

Should I have my clients install Fiddler Cap on their computer to capture data for a ticket? Or should I install a different version on the server in an attempt to capture the data?

JerseyConnect Team Replied

7/19/2021 at 6:06 AM

They need traces from the client side. Here's the instructions that support gave us:

Download here: https://www.telerik.com/download/fiddler

Once installed, you'll then need to change the settings so it can decrypt any HTTPS traffic that occurs during the testing:

https://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/DecryptHTTPS

Once that's ready to go, please close any applications/tabs aside from webmail, then try to recreate the issue. When finished, use the File>Save>All Sessions menu option to export the list of web requests as an SAZ file.

Jane Noel Replied

7/19/2021 at 7:17 AM

Thanks Jersey!

Bill Hughes Replied

9/22/2021 at 3:00 PM

Hey did this issue get resolved? We have been struggling with users complaining of exactly this for a couple of months. We have been chasing network issues. We recently updated to 7914 in the hopes of fixing the issue. It has not. I have no idea why this thread did not come up in earlier searches... but I am here now! :-)

If anyone could give me an idea of how to resolve it, I would be very grateful.

Jane Noel Replied

9/22/2021 at 3:09 PM

Bill, we updated a couple more times for other issues and this one seemed to resolve itself. We never even got to the point of using Fiddler.

Kyle Kerst Replied

9/22/2021 at 3:09 PM

Employee Post

Hey there Bill! The vast majority of affected users have only seen this intermittently or were resolved by correcting time/timezone and related areas from our KB article. If you're still seeing this on the latest release I recommend starting with the KB article below and submitting a ticket if you need a hand tracking this down:

I hope this helps. Have a good one!

Kyle Kerst

Lead Internal Network/System Administrator

SmarterTools Inc.

JerseyConnect Team Replied

9/23/2021 at 6:18 AM

I know we had a few customers switch to mail clients to work around the issue. Besides that we haven't gotten any new complaints nor have we heard back from anyone we asked to send us Fiddler traces. I can only assume the issue resolved itself or people are simply dealing with it.

Brian Messman Replied

8/16/2022 at 2:39 PM

Hate to beat the dead horse here, but we've had intermittent user session logouts since migrating over to SmarterMail. All time settings are synced at the domain level, so no possibility for issues there. We're about at wit's end and 3+ years after deployment the problem still isn't fixed. There's no rhyme nor reason why it happens only to certain users....all PC's are imaged exactly the same and are identical at the software / settings level. We've deleted cookies / sessions, etc. to no avail. I seriously doubt it's an issue related to inactive Chrome tabs, as users have reported to me that they will be in the middle of writing an email and get punted back to the login screen mid-stroke. Completely unacceptable in a medical environment to say the least....

Kyle Kerst Replied

8/16/2022 at 4:27 PM

Employee Post

Hi Brian, sorry to hear you're having these issues! 9 times out of 10 these logouts are happening due to time discrepancies on the client PCs. Are your users leveraging automatic time settings where their client sets its time from an NTP server? If so, can you try manually setting one of these clients to the correct time then monitor for a couple of days to see if those issues clear up? Beyond that, are the affected users known to use VPN connectivity or have browser extensions installed that could be introducing trouble? If you can get a ticket submitted on this we'd be happy to dig into it with you!

Kyle Kerst

Lead Internal Network/System Administrator

SmarterTools Inc.

Brian Messman Replied

8/17/2022 at 9:51 AM

Again,

All suggestions on every thread I've found about this issue have been tried. Time settings are handled by the PDC, and all machines are synced to the second and in the same time zone. All machines are the product of images and contain the exact same payload of applications and settings per department, but there's no indication that one department's settings are causing the issue as one user out of the billing department of approx 15 is affected, one or two in nursing, one in admin, etc. Users cannot install software or modify settings per Group Policy. These machines are directly connected to our LAN, so no VPN. I've gone so far as completely replacing a user's PC and the problem persisted (though not as regularly). That indicates to me that local settings such as site cookies have no bearing (at least for that particular user), and it happened even before her PC was joined to the domain while using a local account (also indicating it's not a domain profile or roaming issue).

I've simply accepted the nature of the beast at this point and move problematic users off the web client. We have too much going on at the moment to delve into the issue any deeper, but I wanted to ring in and let the forum know that this issue persists for some of us - many for several years and counting from what I can gather from Google searches on the subject matter.

Brian Messman Replied

8/17/2022 at 9:58 AM

To be clear:

SmarterMail has been a great product for us, and the few times we've needed to reach out to you guys for support in the past 3+ years has been handled very quickly and professionally. I didn't mean to sound stand-offish. =)

Kyle Kerst Replied

8/17/2022 at 10:28 AM

Employee Post

Hey Brian, thanks for your followup on this. Not to worry on the tone at all, I totally get it. I figured you'd probably already run through those suggestions a few times but wanted to confirm as we haven't had any reports of this in quite some time now that didn't boil down to one of those possibilities.

The one thing I can say it sounds like may still need to be tested is setting the client PC time manually instead of allowing it to check and set itself from the time server. I'm not sure why exactly this works in some cases, but we found evidence of intermittent NTP protocol issues in Windows under those scenarios specifically.

If you do get some time to dig into this with us please submit a ticket and we can help get to the bottom of it for you!

Kyle Kerst

Lead Internal Network/System Administrator

SmarterTools Inc.

Matt Petty Replied

8/18/2022 at 7:44 AM

Employee Post

Just adding to the pile of potentials here but things like privacy blockers, strict settings on browsers, or aggressive cleaning of caches could cause behavior like this too. If you feel like trying to debug you could leave the browser debugger open and making sure SignalR test passed via the console (it prints if it passed or not) and then monitoring the network tab for any 401 responses (which triggers logout). Us knowing what call is potentially getting the 401 triggering a logout could help us dig a little bit.

Just some more stuff to try if you feel like it.
P.S. It sounds like your in a controlled environment where all the computers are running the same software doing the same stuff etc. If possible try to bring a third-party into the mix that's "not like the others" and see if that machine also experiences issues.

Matt Petty

Senior Software Developer

SmarterTools Inc.

M

Merle Wait Replied

8/18/2022 at 8:42 AM

Just FYI and to follow-up

Am having the same problem as report here...
https://portal.smartertools.com/community/a94932/how-to-trace-determine-webmail-connection-issue.aspx#137169

Have verified that the time zone issue.. is not the issue.

Tony Scholz Replied

8/18/2022 at 12:42 PM

Employee Post

Have you tried to verify that the time is correct on the server itself, where SmarterMail is running.

- not the time zone

- just that the clock is not off and effecting the refresh/auth tokens

https://time.is/

This has fixed many problems from webmail log outs to multi factor auth apps codes timing out

Thank you

Tony Scholz

Lead Network/System Administrator

SmarterTools Inc.

Paul Blank Replied

8/22/2022 at 9:32 AM

So users in different time zones will be logged out under normal circumstances? Doesn't seem logical.

Tony Scholz Replied

8/22/2022 at 10:11 AM

Employee Post

Hello Paul,

This check is not about the users timezones but the server itself. The auth token has an expiration time and a refresh time. If the servers time is off by too much it breaks the calculation and the refresh fails. This check is all local to the server and does not touch the users tine or timezones.

Hope this helps to clarify the issue.

Thank you

Tony Scholz

Lead Network/System Administrator

SmarterTools Inc.