SM 13.2 "browser has lost the session with the server"
Problem reported by Scott Hendrickson - April 1, 2015 at 12:04 PM
Known
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.

174 Replies

Reply to Thread
1
Scarab Replied
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.
1
Scott Hendrickson Replied
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.
0
Steve Reid Replied
You need to dig into your IIS logs for crashes of the app pool.
1
Scott Hendrickson Replied
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.
0
Steve Reid Replied
You should open a support ticket.
0
Von-Austin See Replied
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. 
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
Scott Hendrickson Replied
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. 
  1. If this does not fix the problem, is there a risk that it might actually cause other issues? 
     
  2. 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.
0
Robert Emmett Replied
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.
Robert Emmett
Software Developer
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
Jan Angelovic Replied
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č
0
Von-Austin See Replied
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.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
0
Von-Austin See Replied
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.
Von See
Technical Support Supervisor
SmarterTools Inc.
(877) 357-6278
www.smartertools.com
1
Darren Guzman Replied
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
1
Scott Hendrickson Replied
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.
1
Scott Hendrickson Replied
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.
0
Jason Cross Replied
Scott, where are you seeing this in the logs? I have the same issue and want to see if I have the same indicator.
1
Jason Cross Replied
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
2
Scott Hendrickson Replied
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.
0
Jason Cross Replied
Scott - have you tried the pre-release build? Did that help at all?
0
Scott Hendrickson Replied
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.
0
Jason Cross Replied
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.
0
Scott Hendrickson Replied
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.
0
Jan Angelovic Replied
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č
1
Jason Cross Replied
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.
1
Jason Cross Replied
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?
0
Steve Reid Replied
nice find... give it a try and let us know the result
1
Steve Reid Replied
The discovery of that IIS application pool setting leads me to believe this error is probably an IIS error and not directly smartermails fault.
0
Jason Cross Replied
Based on what?
0
Steve Reid Replied
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?
0
Jason Cross Replied
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.
0
Steve Reid Replied
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.
0
Jason Cross Replied
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.
0
Jason Cross Replied
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.
0
Steve Reid Replied
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.
1
Jason Cross Replied
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.
0
Jason Cross Replied
And now it has happened at 9:45a and 10:45a as well.
1
Merle Wait Replied
Just FYI..

Am on 13.3, (upgraded 1 week) receive same type of errors...on win 2012, only website running IIS.
 
1
Jason Cross Replied
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).
1
Scott Hendrickson Replied
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.
1
Scott Hendrickson Replied
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.
0
Jason Cross Replied
43 events! That's insane.
1
Steve Reid Replied
That fact that there has been tickets open on this issue for over a month and Smartertools has yet to figure it out is unnerving.
2
Scott Hendrickson Replied
I agree with buth Jason and Steve, it is insane and unnerving.  And it's getting worse.  Today between midnight and 11:30 AM MDT, ***51*** of these events have been logged. 
 
We do have some folks who use webmail as their only email program.  I would imagine that this is getting very frustrating for them.  It's a wonder I haven't heard from more of them. 
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
Jason Cross Replied
Scott, any pattern to the timing?
0
Scott Hendrickson Replied
As I mentioned yesterday, as of about 4:25 PM MDT yesterday, we had 43 of these events logged, and not all but the majority of them have indeed been at 15 minute intervals. I haven't checked today yet.
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
Jason Cross Replied
Ah sorry. I missed that part.
2
Paul Blank Replied
ST, please address this issue. 
 
3
Scott Hendrickson Replied
Does anyone have any idea as to just how many servers may be affected by this?  I have to assume (yeah, I know) that if the number was large enough, SmarterTools would be scrambling to get it fixed.  As it is, they don't seem terribly concerned. 
 
Jason, you said you've had a ticket open for over a month, right?  I only get two support tickets included with my package, and I'd hate to burn one on something that SmarterTools should already be working on. 
 
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
Jason Cross Replied
No idea how many could be affected. I do know that when I opened my ticket they said they were aware of the issue but are unable to re-create it in their lab.

I would hope that a known issue in their software wouldn't burn a support incident. But I think we all need more people who have the problem actually reporting it via a support incident if it's going to be taken care of.

When I sent some logs last week, they mentioned anticipating looking into them some time next week as they were currently finishing up a beta of Smartermail 14x.

Meanwhile, I am working on a theory as to what's happening, but need a bit more data before I push it forward.

People who are seeing the issue - have you found your number of resets to be lower on the weekends and after-hours? Also, how many users (approx) are you serving on Smartermail?