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.

67 Replies

Reply to Thread
1
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
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.
1
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
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
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.
1
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č
1
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
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
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.
1
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
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.
1
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
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?
1
The discovery of that IIS application pool setting leads me to believe this error is probably an IIS error and not directly smartermails fault.
1
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.
1
Just FYI..

Am on 13.3, (upgraded 1 week) receive same type of errors...on win 2012, only website running IIS.
 
1
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
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
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.
1
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
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.
2
ST, please address this issue. 
 
3
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.
1
Ok, so I just had a session reset and checked the Windows security logs for the exact second.  In that second there were 750 events logged, many of them relating to data under c:\Program Files (x86)\SmarterTools\SmarterMail\MRS\App_Data being checked or updated.  
 
\App_Data\Definitions\User\UR_TrustedSenders.xml
\App_Data\Definitions\User\UR_OutSpam.xml
\App_Data\Definitions\User\UR_IncSpam.xml
\App_Data\Definitions\User\UR_GreyList.xml
\App_Data\Definitions\User\UR_Viruses.xml
\App_Data\Logs\Administrative Log 2015.04.20.txt
etc
 
I'm pretty sure that this points to a process that runs periodically from within Smartermail that checks/updates the various files and somehow triggers the application itself to think an "application level change" has occurred.
0
Further info.  This morning we had the restart.  Logs from the time show a number of deletes on temp files.
 
C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\MailProcessing\023ffbf4-57e1-4e78-9a0b-69450ea0e799.tmp
C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\MailProcessing\03b3ac09-6adf-4055-b15e-fc644362984e.tmp
C:\Program Files (x86)\SmarterTools\SmarterMail\MRS\MailProcessing\09a15fce-0ebf-456d-a202-2b7a8dd69a0b.tmp
 
363 events in that one second (not all events were separate files, each touch generated a few events for reading the attributes, deleting the temp file, confirming delete, etc).  
 
For comparison in the second prior, there were 5 events.
0
Just had another reset.  30 minutes from previous one.  This one shows in the log like yesterday - 500+ events centered around AppData updating.  
 
\App_Data\Definitions\User\UR_TrustedSenders.xml
\App_Data\Definitions\User\UR_OutSpam.xml
\App_Data\Definitions\User\UR_IncSpam.xml
\App_Data\Definitions\User\UR_GreyList.xml
\App_Data\Definitions\User\UR_Viruses.xml
\App_Data\Logs\Administrative Log 2015.04.21.txt
etc
0
I am having the same exact problem. My clients are threatening to go to Gmail if I can't fix the constant need to refresh the browser. How can I fix it?
  • SmarterMail Enterprise Edition
  • Version 12.4.5364
 
Thanks.
Web Engineer
http://www.fullblownwebdesign.com
0
Any news on this?
 
Thanks!
4
Employee Replied
Employee Post
Hello,
 
We have spent a large amount of time trying to understand and fix this issue but it has proven to be very difficult to solve.
 
The error log entry for when the application pool restarts was added specifically for this issue.  That's this one that you are seeing:
 
Application Stopping. Reason: A change was made to the application level 
 
There are many reasons that an application pool can be restarted so this is just one of around fifteen different log entries that you may see.  For example, if you copy a file to the bin directory the reason will state that a change has been made to the bin folder.  Of course, it appears to always be the same for this issue.
 
We are writing that out based on what .Net gives us as the reason for why the Application_End event is called.  Unfortunately there is no additional information given.  We started a ticket with Microsoft hoping they could help us zero in on the exact cause, but they did not prove to be very helpful.  Ultimately they decided the issue was due to writing, updating and deleting a lot of files in the app_data directory.  We have always done that though and we could not reproduce the issue according to this theory.  We created an app that does nothing but write, update and delete files in a specified directory and pointed that app to the app_data\logs, app_data\temp and mailprocessing folders for hours without a single application pool restart.  We did hundreds of thousands of file creations, updates and deletions to each of those folders during our test.
 
From previous tickets for this issue it appeared that it started happening after releasing version 12.2.  We had those customers revert to 12.1 where the issue did not happen.  After upgrading to a later version the issue occurred again.
 
The initial post by Scott Hendrickson for this thread said "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.".  I am interpreting that to mean that the issue was also happening with version 7?  Is that correct?
 
Jason Cross mentioned that it seemed the issue occured in 15 minute spacings on some days which could be due to background tasks operating on certain intervals.  We do have various timed background tasks in webmail, so we added web service functions that can enable or disable those.  These functions are specifically for troubleshooting this issue as you would generally want all of the background tasks running.
 
We released version 13.4 earlier today that includes these web service functions.  Here is an explanation of where they are and how to call them:
 
You will need to be logged directly into your SmarterMail server.  From there open a browser and go to your webmail login page.  Change the url by appending "/services/svcServerAdmin.asmx" to the root webmail url.  So for mail.smartertools.com I would go to mail.smartertools.com/services/svcServerAdmin.asmx.
 
Once there you should see links for each web service function.  The new ones are EnableOrDisableBackgroundTask and GetBackgroundTasksStatus.  The EnableOrDisableBackgroundTask function is what lets you enable or disable the various background tasks. Click on that and you will see fields for the auth username and password which need to be your system administrator credentials.  The rest of the fields take either "true" or "false" as the values which enables or disables the associated background function.
 
The GetBackgroundTasksStatus function returns the status of each of the functions so you can verify which are running and which aren't.
 
Here is an explanation of what each of these functions do:
 
StrayFileDeletion: Cleans up any stray files it finds in the web sites App_Data\Logs, App_Data\Temp, MailProcessing and Temp folders.
 
RSS: Retrieves RSS feed information.
 
WebStats: Pushes logged in webmail user counts to the service.
 
Events: Retrieves reminders from the service.
 
ToastNotifications: Retrieves toast notificaitons from the service.
 
WeatherUpdater: Retrieves weather information shown on calendar page.
 
UploadTokenCleaner: Enforces the expiration date for files in file storage that have been made available for public download for a limited duration.
 
Ping: Handles pushing new items to Exchange ActiveSync connections.

You should be able to disable any of these for reasonable stretches of time without too much disruption.  Can anyone that is having this issue with SmarterMail 13 install the new version and see if disabling any of these background functions will resolve the issue?  Hopefully we will be able to pinpoint the issue to a specific background task.  If not we will at least have eliminated those as a cause and we can look into other possibilities.
0
It is somewhat disquieting, since the issue seems to come from IIS, and is so difficult to trace, that SmarterMail does not have its own robust web server.  Other Windows-based mail server software that I've seen comes with a production-ready web server built-in, while SM's included server is not recommended for production use.
 
Perhaps this is the right time for ST to beef up the web server in SmarterMail and make that the default. This would put much more control of webmail back into the hands of the SmarterMail developers, where it belongs, instead of leaving it up to IIS, which is a staggeringly-complex piece of work.
 
It's a good bet that many of the components/features of IIS are not necessary for SmarterMail's webmail component, and complicate matters greatly.
 
Comments, please!
 
 
 
0
Has anyone installed the new firmware and disabled some background tasks yet?  I installed last night, but not enough time has passed to determine if it was useful or not.
0
Thought I would've been able to this past weekend, but it didn't work out.  May have to wait for this weekend.  I'll post when I've done the upgrade and again as I get results.
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
I installed 13.3.5596.26501 last night between 12 and 1. So far I have not disabled any of the background services, yet there's been only one of those Application Stopping incidents entered in the error log today right around the time I did the update. Previously after nearly 10 hours, there would've been several. On the 7th, there were 43 all day, and on the 6th, 53. However all day yesterday even before I installed the new version, there were only 2 in the log. The only difference I know of for yesterday was that on the 7th late night, I installed three optional windows updates, KB3048761, KB3045645, and KB3020370, none of which I thought had anything to do with IIS or .NET. I'll let you know what happens.
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
As of this posting, the app has stopped only three times today, and one of those times, a slightly different error was logged.  Instead of "Reason: A change was made to the application level configuration", it was "Reason: The hosting environment shut down the application".  
 
Even without disabling any of the background services, this is already a huge improvement.  I'm going to go the rest of the day and see what happens.  If there are several more app stops, I'll start disabling background apps one at a time tomorrow. 
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
Yesterday all day there were only four Application Stopping incidents entered in the error log.  One was due to "The hosting environment shut down the application" instead of "A change was made to the application level configuration", and one would've been due to the regularly scheduled app pool recycling, which is set for every 1740 minutes (29 hrs).  However today so far there have been 8.  One of which could be the normal app pools recycling, but that still leaves 7 that probably should not have occurred.  I'm going to start disabling the background services one at a time and will let you know which, if any, have any effect.  Stay tuned....
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
I'm sorry to report that upon submitting the word false, with or without quotes, in the Rss: or weatherUpdater: fields, I got the following error. I also tried submitting 0 and 1 but got the same result.
 

Cannot convert to System.Boolean.
Parameter name: type ---> String was not recognized as a valid Boolean.

Because there's an extra space between convert and to, it looks like the submitted value isn't making it through to the routine that's supposed to process it. I ran GetBackgroundTasksStatus again, and it showed all the background tasks were sill enabled, so the error was not erroneous.

Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
1
Yesterday evening around 5 or 5:30pm, I disabled the RSS background service.  There were no more incidents the rest of the night.  However  at 12:12am this morning, there were 7 in the space of 17 seconds.  There were 11 more between 1:42am and 8:27am, but so far no more by about 12:30pm. Could this particular bunch have to do with nightly backups, which run between midnight and 9am, and if so, why???  Also I just checked RSS and it was back on, so I disabled it again to see what happens the rest of the day. 
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
1
Yesterday after 8:27am, there were app stops at 3:27pm, 5:42pm, and 9:43pm.  Of course RSS would've been restarted yesterday afternoon after the 3:27 stop, so I'm guessing it's not the culprit.  This morning only 4 stops during overnight backup time.  Since 9am (end of backup time) there was 1 at 10:12am.  I disabled WeatherUpdater this time and will see what happens.  Unfortunately, I don't always know when the app stops occur, so I can't re-disable a service right after one occurs.  I'll try to keep an eye on it today. 
 
Stay tuned....
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
I am hoping that ST or someone finally gets to the bottom of this.  Webmail disconnection should almost never happen over a healthy LAN, and disabling various services simply should not be necessary, especially on a server that's primarily running SmarterMail.  Over a WAN connection, obviously, there are more variables.
0
Is everyone else having the issue of background tasks re-enabling themselves automatically over time?
1
It's pretty apparent that they did not intend for those background services to stay disabled across app restarts.  Though it seems like that wouldn't be too helpful for diagnostics, I suppose if the app that's disabled happened to be causing the problem, there wouldn't be any more stops. 
 
Yesterday was a pretty good day.  I didn't get to work with the server so no bg services were disabled, but there were very few app stops.  Like usual there were a handful during the backup period between midnight and 9am, but only two after that at 9:57am and 11:12am (1:15 apart); no more the rest of the day. 
 
So far today has been the opposite.  There were 54 between midnight and 9am and 21 more between 9am and noon.  I'll continue testing today. 
 
It's really quite annoying having to test with a live environment because ST can't reproduce the problem in their labs.
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.
0
Well, I got through the rest of the background services today.  One at a time I disabled the ones I hadn't tried yet, and each time after a while another app stop occurred.  I'm guessing that if any single service was THE cause of the problem, there would have been no more app stops until I restarted it. 
Scott Hendrickson
SOS4Net, Inc.
Centennial, CO. U.S.A.