SM 13.2 "browser has lost the session with the server"

Problem reported by Scott Hendrickson - 4/1/2015 at 12:04 PM

Resolved

Hi Folks:

We started with SM Pro 7.x about 3 years ago. We just updated to SM Pro 13.2 a couple of months ago and we're having the exact same problem. Periodically, with no discernible pattern, and regardless of whether there's browser activity or not, browser sessions are lost with the following error showing on the screen: "Your web browser has lost the session with the server. Press OK to return to the login page." I know this is something that's happening at the server rather than at the browser. I've had two people her on separate computers lose sessions at the same moment. Also I've been on the phone with a client with both of us in webmail, and again both our browsers lose the session at the same moment. So I know it's a server thing. That question of course is, what's going on and how do we stop it.

Is anyone else experiencing this issue, and if so have any solutions been found? I have verified that IIS is configured just as SmarterTools instructs. I really like SmarterMail, but it's rather disappointing that this problem apparently has persisted through several major versions of the program.

Scott

Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.

178 Replies

Reply to Thread

Scarab Replied

4/1/2015 at 1:15 PM

When you run SmarterMail under IIS it is your Application Pool in IIS that determines when when logouts occur and when the pool is to be recycled, either one resulting in the symptoms you are reporting.

By default an IIS Application Pool is set to logout a connection in 20 minutes. To change the behavior of your IIS Application Pool you would go to the IIS Manager and expand your server and click on APPLICATION POOLS. Select your Application Pool for SmarterMail and click on ADVANCED SETTINGS in the right-hand pane. Under the "Process Model" section you can change the "Idle Time-Out (Minutes)" setting as desired. If your users are all getting disconnected at the same time then you would want to change your Application Pool's Recycling settings. Under the "Recycling" section you can define when IIS will recycle Application Pools (during which all logged in Webmail users would be disconnected). For example I have set all but "Specific Time" to "False" and then set mine to recycle at 1:00:00 and 5:30:00 as we commonly do not have users logged into the Webmail during these times in the early morning.

Scott Hendrickson Replied

4/1/2015 at 6:27 PM

Hi Scarab:

Thanks for the reply. As I mentioned, I've already determined that it's not the idle timeout kicking in as this has occurred sometimes within seconds or just a few minutes after a browser action, like submitting a new setting or changing folders. I believe it's more likely to be related to app pool recycling. However the SmarterMail app pool has no limits set for specific times, virtual memory, or number of requests, and the Regular Time Interval is set to 1740 minutes (29 hours). Sometimes you can stay logged onto webmail for a good while, and other times it will kick you off two or three times within just a few minutes. It's really quite frustrating, even for me. I imagine that it's even more frustrating for the handful of users who use webmail as their primary email program.

Scott

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Steve Reid Replied

4/2/2015 at 5:53 AM

You need to dig into your IIS logs for crashes of the app pool.

Scott Hendrickson Replied

4/2/2015 at 4:54 PM

Hi Steve:

I set the SmarterMail app pool to log runtime recycling events for config changes and unhealthy isapi. The next time my browsers lost their sessions, I checked the system log, and nothing had been recorded. HOWEVER in the SmarterMail Error log, I saw the following for the exact time that the browsers lost their sessoins:

[2015.04.02] =======
[2015.04.02] [CurrentUser: ]
[2015.04.02] [4/2/2015 5:27:24 PM]
[2015.04.02]
[2015.04.02] Application Stopping. Reason: A change was made to the application level configuration

I'm the only administrator, and I did not make any config changes at all, much less an app level one. So I copied everything from the log result box and counted. There have been 51 of these errors today between midnight and 5:27pm. If they all represent these session losses, that's quite disturbing.

Does anyone (at SmarterMail or otherwise) have an explanation as to why app level changes would occur without me making them.

Scott

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Steve Reid Replied

4/6/2015 at 5:19 AM

You should open a support ticket.

Employee Replied

4/7/2015 at 12:45 PM

Employee Post

Scott,

I do have a custom build that may resolve the issue you are facing, however this was to resolve a specific instance of the web session expiring and the fix may not apply to your environment.

If you'd like to give this a try, you can download and install this from here: http://www.smartertools.com/Downloads/SmarterMail/CustomBuilds/13.3.5561.17888/SmarterMail13_Setup.exe

If this does not resolve your issue I would suggest opening a support ticket with us so we can further troubleshoot this issue with you. Just reference this community post within your support ticket and we'll be glad to help you out from there.

Scott Hendrickson Replied

4/7/2015 at 5:36 PM

Hi Von!

Thanks for that info. I'm running a VPS with Windows Server 2008 R2 Std with IIS 7.5.7600.16385. I was planning on updating to 13.3.5535 this weekend. If I were to use your custom build instead, I have a couple of questions.

If this does not fix the problem, is there a risk that it might actually cause other issues?
If it does fix the problem, but it's a custom build, won't that affect my ability to do future upgrades? In other words, when 13.4.whatever comes out, being a "regular" build, wouldn't that wipe out the fix that the custom build put in place???

Thanks!

Scott

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Employee Replied

4/8/2015 at 7:55 AM

Employee Post

We typically incorporate all custom build fixes into the next minor release. So, you would still be able to upgrade to the next minor build without risk.

Jan Angelovic Replied

4/9/2015 at 5:39 AM

Hi Von, we have same issue:

[2015.04.09] =======
[2015.04.09] [CurrentUser: ]
[2015.04.09] [9. 4. 2015 14:06:35]
[2015.04.09]
[2015.04.09] Application Stopping. Reason: A change was made to the application level configuration

This appears many times a day with “Your web browser has lost the session...” message for all connected users.

We have SM 13.3.5535 on Windows Server 2012 R2 EN with all updates.

Can I use this custom build without any risk? Or it would be better wait for regular release?

Looking forward to your reply, Jan Angelovič

Employee Replied

4/9/2015 at 7:07 AM

Employee Post

In addition to Roberts comment, if this does not fix the issue, there would be minimal risk of this causing other issues. This custom build contains fixes that only apply to the web site session timeout issue.

Employee Replied

4/9/2015 at 7:09 AM

Employee Post

Greetings, installing the custom build would be considered minimal risk as this build only contains fixes pertinent to the web sessions being lost. These fixes will be rolling out in a future minor update, so it's really up to you if you want to install the custom build within your environment.

Darren Guzman Replied

4/10/2015 at 2:52 AM

Hi Von,

I'm also having this problem for our users, and quite a lot of complains regarding the session time out. I'm using SmarterMail ENT Version 13.2.5511.

I'm about to update it to the latest version hoping it will actually be solve, but seems the latest version still doesn't have this fixed.

I also have SmarterMail ENT Version 12.3.5318 but doesn't have this problem.

Hope this one will get fixed, as it's very critical to our customer.

Regards,

Darren

Scott Hendrickson Replied

4/11/2015 at 12:47 PM

Well, at first I thought it might have been fixed after the upgrade. I had a session connected for an hour and a half with minimal activity before it was disconnected. I thought the disco might have been a result of the normal inactivity timeout, but unfortunately one of those errors that said, "Application Stopping. Reason: A change was made to the application level configuration" was put in the error log at the same time both browser sessions got disco'd. So it looks like it may not be happening as often, which still would be better, but it is still happening.

SmarterMail reps, I'd really like to know what application level change is being made, or what SmarterMail is perceiving as an app level change.

Thanks!

Scott

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Scott Hendrickson Replied

4/11/2015 at 12:49 PM

BTW - Due to these entries in the error log, I would lean toward this being a SmarterMail application issue rather than a .NET or Windows OS issue, wouldn't you?

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Jason Cross Replied

4/13/2015 at 4:16 PM

Scott, where are you seeing this in the logs? I have the same issue and want to see if I have the same indicator.

Jason Cross Replied

4/13/2015 at 4:57 PM

I am having the same issue, along with the following in the log with each incident:

[2015.04.13] Application Stopping. Reason: A change was made to the application level configuration

Scott Hendrickson Replied

4/13/2015 at 5:41 PM

Hi Jason:

Yep, that's what gets put into our log too.

I'm pretty certain this is a SmarterMail program issue now because as I forgot to mention on 4/11, on 4/10 Darren Guzman said that he has two servers, and the one running version 12.3.5318 does NOT do this.

SmarterMail Folks: Any possibility someone can compare version 12.3.5318 and version 13.3.5561 to see why one has this problem and the other does not???

Thanks!

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Jason Cross Replied

4/13/2015 at 6:11 PM

Scott - have you tried the pre-release build? Did that help at all?

Scott Hendrickson Replied

4/13/2015 at 6:22 PM

I installed 13.3.5561.17888, the custom build recommended by Von above on 4/7. I'd guess that's a pre-release build. And unfortunately no it didn't help. As I mentioned in my 4/11 post, the problem still persists.

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Jason Cross Replied

4/13/2015 at 6:54 PM

That's disappointing.

I've been in contact with support, but they need me to run process monitor and catch the error. The problem is that process monitor is generating gigabytes of logs in minutes, and the issue is sporadic enough that it could be a few minutes or a few hours before it happens.

Scott Hendrickson Replied

4/13/2015 at 7:26 PM

You'd think that, since 12.3.5318 doesn't do it, they should be able to do a little digging, compare the two versions, and find the answer. I'm pretty sure they have more people to throw at this than you or I do.

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Jan Angelovic Replied

4/15/2015 at 1:22 AM

Hi, I installed custom build 13.3.5561.17888 (04/09/2015, 8 PM), for three days it looks good, but then unfortunettly issue returns:

[2015.04.13] =======
[2015.04.13] [CurrentUser: ]
[2015.04.13] [13. 4. 2015 14:48:57]
[2015.04.13]
[2015.04.13] Application Stopping. Reason: A change was made to the application level configuration
[2015.04.14] =======
[2015.04.14] [CurrentUser: ]
[2015.04.14] [14. 4. 2015 10:30:21]
[2015.04.14]
[2015.04.14] Application Stopping. Reason: A change was made to the application level configuration
[2015.04.15] =======
[2015.04.15] [CurrentUser: ]
[2015.04.15] [15. 4. 2015 8:18:47]
[2015.04.15]
[2015.04.15] Application Stopping. Reason: A change was made to the application level configuration
[2015.04.15] [CurrentUser: ]
[2015.04.15] [15. 4. 2015 9:03:51]
[2015.04.15]
[2015.04.15] Application Stopping. Reason: A change was made to the application level configuration
[2015.04.15] =======
[2015.04.15] [CurrentUser: ]
[2015.04.15] [15. 4. 2015 9:33:53]
[2015.04.15]
[2015.04.15] Application Stopping. Reason: A change was made to the application level configuration

Jan Angelovič

Jason Cross Replied

4/15/2015 at 6:15 AM

I was able to capture a process monitor log when the restart occurred and forward it on to SmarterMail. Hopefully that helps solve the issue.

Jason Cross Replied

4/15/2015 at 8:04 AM

Has any one tried setting "Disable Reycling for configuration changes" in the app pool settings to true? I'm not sure if there are any negative consequences to doing this, though.

Also, FWIW, this really seems to be happening much more often during the workday (between 8a and 5p Mon-Fri) than any other time. Anyone else see this?

Steve Reid Replied

4/15/2015 at 10:32 AM

nice find... give it a try and let us know the result

Steve Reid Replied

4/15/2015 at 11:19 AM

The discovery of that IIS application pool setting leads me to believe this error is probably an IIS error and not directly smartermails fault.

Jason Cross Replied

4/15/2015 at 11:40 AM

Based on what?

Steve Reid Replied

4/15/2015 at 11:46 AM

Based on the fact that the language use in the setting is identical to the language used in the error noted, you didn't notice that?

Jason Cross Replied

4/15/2015 at 11:47 AM

But it doesn't at all explain why the issue occurs in the first place. Configuration files are not supposed to be changing like this.

Steve Reid Replied

4/15/2015 at 11:52 AM

If you want an answer your best bet is to open a support ticket. All I am doing is offering my input, I never promised anything else.

Jason Cross Replied

4/15/2015 at 11:53 AM

I've had a support ticket open for over a month now. My point was that it feels like saying it's "probably an IIS error" based on the data feels like a bit of a jump.

Jason Cross Replied

4/15/2015 at 11:55 AM

I'm a little hesitant to make the change without input from Smartertools. I don't know if there are configuration changes that are intended to happen and what consequences this change could have.

Steve Reid Replied

4/15/2015 at 11:56 AM

So then it's probably hard to reproduce and tricky to figure out. That's why trying the setting you found is the logical next step.

Jason Cross Replied

4/16/2015 at 6:30 AM

Well, last night I tried setting "Disable Reycling for configuration changes" in the app pool settings to true.

No luck. 7:30A this morning had the same session issue with the log "Application Stopping. Reason: A change was made to the application level configuration" which leads me to think it's not IIS or the App Pool restarting, but something in the SM application itself.

Jason Cross Replied

4/16/2015 at 9:01 AM

And now it has happened at 9:45a and 10:45a as well.

Merle Wait Replied

4/16/2015 at 9:12 AM

Just FYI..

Am on 13.3, (upgraded 1 week) receive same type of errors...on win 2012, only website running IIS.

Jason Cross Replied

4/16/2015 at 9:25 AM

Another thought – is there anything in Smartermail that does periodic maintenance on files? I ask because there is a certain regularity to the problem. Not that it happens at the same time every day, or at the same intervals, but for instance, today we had the issue at 7:30a, 9:45a, 10:45a, and 11a (so far). It seems very odd that they are on exact quarter-hour increments.

Yesterday it was at 9:30a, 11:45a, 3:45p, 4:15p. Quarter-hour increments.

4/14 it was 9:32a, 11:32a, 3:47p, 5:02p. All at 15 minute spacings from each other, though offset by 2 minutes for each.

4/13 it was 8:36a, 10:51a, 11:51a, 12:06p, 12:21p, 1:36p, 2:06p, 2:21p, 3:21p, 4:06p (offset by 6 minutes but still at quarter hour increments).

Scott Hendrickson Replied

4/16/2015 at 3:10 PM

Don't forget that on 4/10, Darren Guzman mentioned that he's got two servers, one with 13.3 and one with 12.3, and the latter does NOT have this issue. For me that's the single best indicator that it's a SM application issue as opposed to a .NET or Windows issue.

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Scott Hendrickson Replied

4/16/2015 at 3:27 PM

From midnight through 4:25 PM MDT, we've had 43 of these events logged, and not all but the majority of them have indeed been at 15 minute intervals.

Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.

Jason Cross Replied

4/16/2015 at 6:53 PM

43 events! That's insane.