Hi, Jason

In most cases, when customers see logouts in webmail, the issue has to do with a time zone setting. Here's a KB on some things you can look for to help with this issue: 

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.

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.

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.)

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.

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

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.

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.

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.

@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. 

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.

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.

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

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

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,

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.

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?

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

Thanks Jersey!

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. 

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.

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!

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.

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....

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!

 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.

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.  =)

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!

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.

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.

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

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

Thank you

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

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