9
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
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
Employee 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.
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?
1
Jason Cross Replied
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
Jason Cross Replied
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
Jason Cross Replied
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
Jason Cross Replied
Also, this is in the DebugLog at that time:
09:19:18 - ApplicationShutdown called
09:19:18 - ApplicationShutdown completed successfully
09:19:18 - The application has started 1 times.
0
Bob Bell Replied
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
Jason Cross Replied
Bob - please do a support request. I think we need more people to officially request support for this to get the attention it needs.
0
Bob Bell Replied
I did thanks Jason. They are looking into it now.
Web Engineer http://www.fullblownwebdesign.com
0
Paul Blank Replied
Any news on this?
 
Thanks!
0
Jason Cross Replied
No word from my support ticket in two weeks. Getting very frustrated.
0
Bob Bell Replied
After reverting to version 12.2.5283 of SmarterMail I noticed a dramatic improvement. Yesterday I only had to refresh the page twice in 24 hours, instead of 30-40 times.
Web Engineer http://www.fullblownwebdesign.com
0
Paul Blank Replied
Two weeks? yikes.
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
Bob Bell Replied
Thank you for looking into the problem and for the detailed explanation Bryon. I appreciate your efforts in trying to find the culprit. I cannot help because my upgrade contract has expired, but I hope someone else can help you find the problem. Thanks again!
Web Engineer http://www.fullblownwebdesign.com
0
Scott Hendrickson Replied
Hi Bryon:

I should be able to do the upgrade this weekend. I think I received an email from the support ticket with a link to the download. Can you tell me which, if any, of the functions you named above might occur at 15 minute intervals???

My plan would be to disable them one at a time, starting with those that seem like they would be the least disruptive to normal system operation. Can you give me an idea of which of those functions least disruptive and which might be more?

Thank you!!!

Scott
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Employee Replied
Employee Post
Scott, most of those aforementioned background tasks are on 15 min timers.
0
Scott Hendrickson Replied
Can you give me an idea of which of those functions are less disruptive and which might be more when shut down for several hours at a time, because the disconnect doesn't always occur at 15 minute intervals? I'd like to start with the less disruptive ones and work my way up.

Thank you!
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Employee Replied
Employee Post
Scott, the file clean up is probably least disruptive--you'll just amass older files until turned back on. If you have several ActiveSync users, turning off ping will stop their push notifications.

Really which tasks and in what order you want to turn the tasks off are up to you. That's one reason Bryon included the descriptions so you could make an educated choice.
0
Jason Cross Replied
If we disable events, does that mean we won't get notification messages or reminder popups?
0
Paul Blank Replied
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
Jason Cross Replied
I'm not convinced the problem comes from IIS at all. It looks to be more of a .NET related issue to me on the application level.
0
Paul Blank Replied
That's another story, then. But then it would be time to take a look at the functionality of .NET and decide if there's a better way to do that.
0
Jason Cross Replied
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
Employee Replied
Employee Post
Jason, correct. With events disabled, there will be no notification popups / messages.
0
Scott Hendrickson Replied
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
Scott Hendrickson Replied
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
Scott Hendrickson Replied
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
Scott Hendrickson Replied
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
Jason Cross Replied
Scott - do you have a backup process of any sort that backs up the MRS directory at any point during the day, even if not when the issues happen?
0
Scott Hendrickson Replied
Yes. The provider takes a system snapshot once a week (not sure what time) and I back up most of the data on the system nightly between midnight and 9am.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Scott Hendrickson Replied
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.
0
Jason Cross Replied
Make sure you set values for all fields.
0
Jason Cross Replied
Any way to exclude the MRS folder? Once I did that my resets dropped to only a few a day (and that was BEFORE stopping tasks). Not completely sure why, but I believe some backup programs place locks or scans on files between backups to speed up the process when backup starts.
0
Scott Hendrickson Replied
Ah! So I need to set each value, even if it's not being changed? Would've been nice to know that, I'll give it a shot. Not how I'd have programmed it, but hey....
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Scott Hendrickson Replied
Thanks, Jason, that did the trick.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
User Replied
Sorry, I should have included that in my post on how to use those new web service functions.
1
Scott Hendrickson Replied
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.
0
Scott Hendrickson Replied
Actually from my posts above, it looks like it was more like around 4pm when I disabled RSS, sorry.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
User Replied
Do your nightly backups work on the SmarterMail MRS folder? If so can you have it exclude that folder? I can't think of anything that would need to be backed up in there.
0
Scott Hendrickson Replied
No, the backup just grabs a few of the more important XML and DAT files from the Service folder.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
1
Scott Hendrickson Replied
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
Scott Hendrickson Replied
Forgot to mention: Even with all services running, there still seem to be far fewer incidents with this program version than with the previous one.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Paul Blank Replied
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
Jason Cross Replied
Is everyone else having the issue of background tasks re-enabling themselves automatically over time?
1
Scott Hendrickson Replied
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
Jason Cross Replied
I agree. I have a feeling it has to do with activity in some way though, which is hard to replicate in a lab environment. I believe that's why I never see issues on the weekend when our volume is near 0 or on holidays.

Based on what we are seeing, my gut instinct makes me think the problem has to do something with if a user is online doing an action that generates a temp file at the some moment that temp files are cleaned, or something like that. Something that requires a conflict between a recurring process and a random interaction - which would be very hard to re-create.

Scott - do you have any way to actively exclude the MRS directory from your backup altogether?
0
Scott Hendrickson Replied
I don't have a way to exclude it from the provider's weekly snapshot, but if that had something to do with it, I would expect the problem to happen only once per week. Also MRS is not included in the list of directories for backup. Plus I just double checked, and that directory is not in the backup files.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
If the snapshot is a VM snapshot or similar, that shouldn't matter. My system does one nightly and it doesn't correlate in any way to a lost session.
0
Scott Hendrickson Replied
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.
0
User Replied
Okay, thanks for going through each of those. At least we can cross those off as the cause. We will go back to the drawing board on this and I will post as soon as we have a new approach.
0
Scott Hendrickson Replied
Is anyone else trying this, disabling those background services one at a time???  If so have there been any different results?
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Working on it, but then an application reset sets all of the tasks back to enabled...
0
Scott Hendrickson Replied
Yep, same thing happened to me. That means the background service you disabled is not the cause of the problem. When that happened here, I moved on to the next service.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
When I have StrayFileDeletion turned off I can go days without an issue.  Invariably the application resets at some point and StrayFileDeletion is turned back on automatically, kicking off multiple resets per day.
0
Steve Reid Replied
Nice, hope ST can jump on this and perhaps all the setting to stick after restart. Then at least you could say for certain.
0
Paul Blank Replied
Pardon my ignorance, but is Stray File Deletion a Windows or SM service?  Since I haven't tried this, where is the switch to disable the service?  Thanks.
0
Jason Cross Replied
Is a background task of Smartermail. See earlier in the thread on how to do so with the latest SM release.
0
Scott Hendrickson Replied
Jason, which of the newest releases were you on when this occurred? If not the one I'm currently on, I'll have to update and try StrayFileDeletion again.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Version 13.4.5602
0
Paul Blank Replied
Thanks, Jason. The instructions are in plaintext and were easy to find, once I knew what I was looking for. If this indeed proves to be the cause, here's hoping that ST will dial-down the priority of StrayFileDeletion, or at least allow us to schedule it to only run off-hours.
0
Steve Reid Replied
Would be nice to hear comments from ST
1
Paul Blank Replied
It would be nice to know if ST has any comments regarding this ongoing issue.
0
Employee Replied
Employee Post
We have a custom build of SmarterMail 13 that will only run the StrayFileDeletion task between 1 and 2 AM of the servers time.  We sent this out to the open tickets we have on this issue.  If anyone else wants to try this build to see if it mitigates the issue, here is the custom build:
 
http://www.smartertools.com/Downloads/SmarterMail/CustomBuilds/13.4.5627.28157/SmarterMail13_Setup.exe
 
Can anyone with this issue install this custom build and let us know if there is any difference in the frequency of sessions dropping?
 
Thanks.
0
Jason Cross Replied
When did this go out? I have had an open ticket for some time, so I am surprised I didn't get notified of it.

I will install and check.
0
Paul Blank Replied
Nice to hear.
0
Employee Replied
Employee Post
Hello,
 
I'm just checking in to see if this build has helped reduce the dropped sessions or not?
0
Jason Cross Replied
I won't be able to install it until this weekend.
0
Jason Cross Replied
I installed last night. Had a reset at 1:14a but none so far today. Will continue to keep an eye on it.
0
User Replied
Thanks for installing that. The fact that it reset at 1:14 AM supports the theory that the file cleanup is the issue as this custom build limits the file cleanup task to running from 1 AM to 2 AM. We will wait for some more information to come in to confirm or deny that the file cleanup task is causing this issue.
0
Scott Hendrickson Replied
Sorry about the theory. I finished installing it last night around 11:30pm MDT. I just checked the log, and since midnight, there have been 26 restarts. 20 of them were after 2am, and 6 of those were after 9am, the time when backups ended.

As a reminder, our backups do not touch the MRS directory and so shouldn't have anything to do with the problem anyway. What's being backed up is users' mail and a few of the XML and DAT files for the system config.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
1:14a again last night for me. Otherwise clear.
0
Jason Cross Replied
Scott - do backups touch anywhere else in the Smartermail program directory? That's a ton of restarts - any rhyme to reason with their timing? Are you seeing the 15 minute spacing?
0
Scott Hendrickson Replied
The only stuff in the program directory that gets backed up are a few of the XML and DAT files. Even so that certainly wouldn't account for all the times it happens when backups are not going on.

I see that 15 minute spacing sometimes, but not consistently. I also see 30 and 45 minute spacings.

BTW - As of this posting, since 9am today there have been 21 restarts. And yeah, that's a helluva lot of restarts. I have a few clients who use webmail as their primary email, and they're getting very frustrated.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Is it possible to temporarily exclude it from backing up ANYTHING in the program directory to see if that makes a difference?

I agree, it sounds odd as the problem isn't exclusive to when backups occur, but I can tell you I had the same problem, with a once daily backup restarts all day long, and when I excluded the program directory my restarts dropped down to maybe 3-4 a day, and the latest change regarding file cleanup so far has stopped even that.

The best I can figure is that some backup programs touch the files even when not actively backing up to track changes and speed up backup time when it occurs.

I guess my point is that we won't know if it helps you too until you try it.
1
Scott Hendrickson Replied
Sorry guys, I thought I'd replied to Jason yesterday, but apparently I never hit the Post button. 
 
Yesterday afternoon at Jason's request, I did set my backup so it doesn't touch anything in the SM program folders at all.  At the time there had been only 3 restarts in the early morning hours, and as it turned out after those, there were no more all day yesterday. 
 
As of noon today, there's been only 1 at 5:27 AM.  WOO HOO!!!  We may have something here.  Oh, hope I didn't just jinx it. ;-) 
 
Jason: My apologies for acting like a hard-headed, technically oriented customer by saying, "It shouldn't work that way."  I should've known better having had to overcome that very objection many times in the past. 
 
Ok guys, I'll keep you posted....
 
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Trust me, I get it. I had the same hesitation myself when I made the change, and I'm glad it's helping!

Now if we could just figure out WHY whatever is happening is causing the application to restart.
0
User Replied
You should be able to just have it exclude the MRS folder. There isn't really anything that should need backing up in there and that is the only folder where messing with the files could cause an app pool restart.
0
User Replied
We will review all the file handling to see if there is a way a file might get locked locked indefinitely. That's our current theory on what might be causing the app pool restart.
0
Jason Cross Replied
Bryon - you'd think so, but it sounds like Scott DID have the MRS directory excluded. It was only after excluding the entire program directory did the problem stop.
0
Scott Hendrickson Replied
Jason's right. I never was backing up anything in the MRS folder. The files I was backing up were in the Service folder. They were...
bayes.dat
greyList.dat
domainList.xml
greyListBypass.xml
LastLoginTimes.xml
ldapConfig.xml
mailConfig.xml
SMVersions.xml

Somewhere in the SmarterMail docs (don't remember where now) I saw where these were the most critical files for moving a program installation from one server to another, so I figured they'd also be the most important ones to restore if an installation got hosed.

To be completely honest, I'm still sort of backing those files up. It's just that now I'm using a little DOS batch file to put copies in my Dropbox folder, the entire process for which takes about a second-and-a-half to complete--if that.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Scott Hendrickson Replied
Just when I thought we might be out of the woods.  You know, this is probably going to increase the number of gray hairs on my head significantly.  
 
Only the one lone restart yesterday.  And that quick little batch file ran at 11:30pm last night without incident.  Then this morning at 12:12:05 AM, it started again.  So far today there have been 30--that's right, 30 already--by 10 AM, 16 of which occurred between 12:12 and 12:14.  So more than half of the 30 from this morning occurred during a 2 minute period.  Remember: The regular backup no longer touches anything in any SmarterMail folder, so I don't see how it possibly could be that. 
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Can you make sure that it somehow didn't get re-added? Also are you running the build posted here recently?
0
Scott Hendrickson Replied
Yes I can, and no it didn't.

Yes, build 13.4.5627.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Weird. How has it gone the rest of today?
0
Scott Hendrickson Replied
Since 10am, there have been 7 more resets, the last one being at 3:57:40 PM.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
So lower than most days, but still pretty high. Also note that 3:57p is a 15min increment from 12:12a (12+45 = 57).

What happens if you disable all of the other background services now?
0
Scott Hendrickson Replied
I didn't know you were talking about multiples of 15 minutes. I thought you were talking about them actually being 15 minutes apart. I do notice that many of them occur in multiples of 15 minutes. Sorry about that.

I haven't been through the background services with this build yet, because we're working on another possible theory. In my support ticket, Von-Austin asked if I could see any other processes besides SmarterMail accessing the SM folder tree when I used ProcMon. I hadn't thought to try that yet, so I set it up with filters so it catches just the relevant events. I watched it for about 15 minutes, and in that time, two "foreign" processes did access the Service folder: Dropbox and MsMpEng.exe (Defender). At the time, there was no restart, so neither of those is likely the culprit. Still I turned off Dropbox since I don't use it that often, and I want to add the SM folder tree to Defender's exceptions but am having trouble getting the GUI started, since it wasn't installed originally with server.

Anyway I plan on turning ProcMon on around 11:15 tonight and letting it run overnight to see if it catches anything other than what I've already seen.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Good plans. If Dropbox is touching that folder, I could see that being similar to the backups, as I'm pretty sure Dropbox does file monitoring in the same way.
0
Scott Hendrickson Replied
Yes, but it's not supposed to touch anything outside of its own folder tree.

FYI - 47 restarts so far today. :-(

I've sent Von-Austin some info from ProcMon, but I don't think it's going to show anything useful. There are 3 things accessing any of the SM program folders: MailService.exe accesses the Service folder, w3wp.exe accesses the MRS folder, and MsMpEng.exe (Windows Defender process) accesses the Service folder.

Apparently the Defender service gets installed with Windows Server, but not the GUI. I tried installing the GUI, but when I went to fire it up, a message was displayed saying that, "The program is turned off." There was a link to turn it on, but I'm hesitant to click it. Not sure it it would just connect the GUI to the service or something else.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Steve Reid Replied
In a quick search I see a few people stating that Windows defender gets installed with "desktop experience", maybe you need to uninstall that feature?
0
Jason Cross Replied
Try this (via Powershell):

To add custom exclusions in addition to the ones automatically added, start a Windows PowerShell console as an administrator, and run the following command:
Add-MpPreference -ExclusionPath "c:\temp"
To remove exclusions, start a Windows PowerShell console as an administrator, and run the following command:
Remove-MpPreference -ExclusionPath "c:\temp"

(temp being the folder in this case)
0
Scott Hendrickson Replied
Steve: The MS Antimalware engine was installed with Server, unfortunately with no good way to control any part of what it does. Desktop Experience I thought would've installed the GUI part, but apparently that's not quite the case. Either way if I uninstall DE, MsMpEng.exe, the MS Antimalware engine, will remain.

Jason: From my support ticket, Von-Austin already had me try Get-MpComputerStatus. When I tried to run it, it came back "...not recognized...". It looks like that interface is part of Server 2012 R2, but not 2008 R2. I did try what you posted above (found the same thing in my research), but it too came back not recognized.

On a related note, I went into MSE and added the SM paths to its exceptions since, according to its own description, MSE is supposed to be both antivirus and antimalware. I'm hoping that's what's "in charge" of MsMpEng.exe.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Scott Hendrickson Replied
BTW - 57 today by 12:20pm.
 
Just to make sure everyone's on the same page, the main problem is the restarts where...
  • Reason: A change was made to the application level configuration
I noticed that when I recycle the app pool myself (or presumably when the scheduled recycle occurs) a slightly different error is logged...
  • Reason: The hosting environment shut down the application. 
In my ticket, I asked if there is a file somewhere that logs changes to application level configuration? If there was I would think we should be able to cross check the time in the error log with that log to see what application level configuration change was made when the restart occurred.  Or would that just be too easy? 
 
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
That's crazy. It's even crazier that you had such a drop-off that one day and then they all came back.

If you filter your Windows Event Logs to the second of the restart, anything stand out?
0
Scott Hendrickson Replied
I think I checked that the other day, but just to be sure I checked again. The only restarts that have related event log entries are the "...hosting environment shut down..." ones, which have an entry stating that a process for the app pool requested a restart at its schedule time. For the actual problem restarts, I saw nothing related in any of the logs, App, System, Security, or Admin. If there's another log in there that's more directly related to SmarterMail, please tell me where to find it.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Scott Hendrickson Replied
Haven't heard anything on my ticket since Thursday afternoon. 
 
I'm guessing it's not possible to use port 80 on the same IP for both IIS hosting other sites (even though they have host names defined in their bindings) and the SmarterMail built in web server, right?  I'm trying to think of a way to verify whether the restarts are actually being cause by SmarterMail itself, which is how I'm leaning, or by IIS, which seems to be how SmarterTools and Microsoft are leaning, but I don't think this would work.  
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
I'm pretty sure that's not possible, not on the same IP. You could put SM on a different port and then put a redirector in IIS to redirect traffic to the alternate port website.
0
Bruce Barnes Replied
So long as you do not have an SSL certificate bound to a site in IIS, you can have as many IIS host headers built around that IP address as you like.
 
If you have an SSL certificate bound to a site in IIS, then you can have only one IIS host header setup for the site on the IP address.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
Scott Hendrickson Replied
Oh right.  There is one webmail site that uses SSL; totally spaced that. 
 
So there has got to be some other way to verify once and for all whether these app restarts are being produced by IIS or by SmarterMail itself. 
 
Any other ideas???
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Bruce Barnes Replied
No, I am watching everyone else diagnose this one as I have my hands full with other stuff right now.
Bruce Barnes ChicagoNetTech Inc brucecnt@comcast.net Phonr: (773) 491-9019 Phone: (224) 444-0169 E-Mail and DNS Security Specialist Network Security Specialist Customer Service Portal: https://portal.chicagonettech.com Website: https://www.ChicagoNetTech.com Security Blog: http://networkbastion.blogspot.com/ Web and E-Mail Hosting, E-Mail Security and Consulting
0
Jason Cross Replied
Smartertools - any idea if the updated cleanup timings are in place on Smartermail 14 as well?
0
Employee Replied
Employee Post
Jason, they will be included in the next SM 14 release, which is scheduled tentatively for tomorrow, 18 June.
0
Scott Hendrickson Replied
Update:  Since those couple of days last month when we had only a few, through 6/22 we'd been having anywhere from 30 to 60+ restarts per day.  Yesterday we had only 8, and today as of just before noon, we've had only 5. 
 
Yesterday I noticed a boolean app pool setting called "Disable Recycling for Configuration Changes", which was False as the default.  I figured since any significant changes to the config should happen if I make them, and I can recycle the app pool manually, I set this to True.  We'll see what happens. 
 
If anyone knows of a good reason why this should be left on False, please let me know. 
 
Thanks! 
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
J.Austin Replied
Hello everyone,
 
I had the same problem and was able to address the issue by changing the 'Maximum number of worker threads' to 1 in the IIS AppPool properties under the performance tab in the section labeled 'web garden'.  Environment: Windows 2003 / IIS 6.0 / SmarterMail 13.4.5603.  Hope this helps!
0
Jason Cross Replied
I had seen this before and set to true, and at the time I hadn't seen an improvement from it. That being said, if it helps you, that's great!
0
Scott Hendrickson Replied
I'm running Server 2008 R2 and IIS 7.5. There's a similar setting called Maximum Worker Processes under Advanced Settings / Process Model, and it's already set to 1. Thanks anyway though. :-)
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Smarter Mail 14 is doing the same thing.  I have clients that are trying to send emails and attachements and they are getting an "oops" screen.  I opened my browser, tried to log in and got the same oops screen. so this has not beend resolved yet even with a major version update ?
 
The log shows this line : [2015.07.12] System.Web.UI.ViewStateException: Invalid viewstate.
For when i tried to log in.
 
Also a little unsettling is that if you click on
http: //mail.leewardhabitat.org/Main/frmCompose.aspx?popup=true
it generates log data.
If your not logged in you should not be able to get to that page to begin with.
 
Notice on all of these the "Current User" shows nothing. like null ?  Opposed to other errors where it shows "unknown" or an actual user name.

[2015.07.09] [CurrentUser: ]
[2015.07.09] [7/9/2015 12:51:50 PM]
[2015.07.09]
[2015.07.09] Application Stopping.  Reason: The hosting environment shut down the application
[2015.07.09] =======
[2015.07.09] [CurrentUser: ]
[2015.07.09] [7/9/2015 1:09:28 PM]
[2015.07.09]
[2015.07.09] Application Stopping.  Reason: The hosting environment shut down the application
[2015.07.09] =======
[2015.07.09] [CurrentUser: ]
[2015.07.09] [7/9/2015 2:09:49 PM]
[2015.07.09]
[2015.07.09] Application Stopping.  Reason: The hosting environment shut down the application
[2015.07.10] =======
[2015.07.10] [CurrentUser: ]
[2015.07.10] [7/10/2015 5:10:09 AM]
[2015.07.10]
[2015.07.10] Application Stopping.  Reason: The hosting environment shut down the application
[2015.07.10] =======
[2015.07.10] [CurrentUser: ]
[2015.07.10] [7/10/2015 7:49:33 PM]
[2015.07.10]
[2015.07.10] Application Stopping.  Reason: The hosting environment shut down the application
[2015.07.10] =======
[2015.07.10] [CurrentUser: unknown]
[2015.07.10] [7/10/2015 7:49:55 PM]
[2015.07.10] http: //mail.leewardhabitat.org/Main/frmCompose.aspx?popup=true
[2015.07.10]
[2015.07.10] System.Web.UI.ViewStateException: Invalid viewstate.
[2015.07.10]     Client IP: 72.253.91.179
[2015.07.10]     Port: 49262
[2015.07.10]     Referer: http: //mail.leewardhabitat.org/Main/frmCompose.aspx?popup=true
[2015.07.10]     Path: /Main/frmCompose.aspx
[2015.07.10]     User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
[2015.07.10]     ViewState: /wEPDwULLTIwOTM1MzM4MDAPFg4eCF9fX1RpdGxlBQtOZXcgTWVzc2FnZR4FX2hUU0JnHgRfc0dGaB4QTGFzdFNldFNpZ25hdHVyZQX0GjxkaXYgc3R5bGU9IiI+CjxkaXYgc3R5bGU9IiI+Jm5ic3A7PC9kaXY+CjwvZGl2PgoKPGRpdiBzdHlsZT0iIj4KPGRpdiBzdHlsZT0iIj48YnIgc3R5bGU9IiIgLz4KPHN0cm9uZz48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgY29sb3I9IiMwMDY2MDAiIGZhY2U9IidUcmVidWNoZXQgTVMnIiBzaXplPSIyIiBzdHlsZT0iIj5KbyBCYXV0aXN0YTxiciBzdHlsZT0iIiAvPgpFeGVjdXRpdmUgRGlyZWN0b3I8YnIgc3R5bGU9IiIgLz4KSGFiaXRhdCBmb3IgSHVtYW5pdHkgTGVld2FyZCBPYGFodTwvZm9udD48L3N0cm9uZz48L2Rpdj4KCjxkaXYgc3R5bGU9IiI+PHN0cm9uZz48Zm9udCBjbGFzcz0iQXBwbGUtc3R5bGUtc3BhbiIgY29sb3I9IiMwMDY2MDAiIGZhY2U9IidUcmVidWNoZXQgTVMnIiBzaXplPSIyIiBzdHlsZT0iIj45MS0yOTEgS2FsYWVsb2EgQmx2ZC4sIEJheSBBIDYvODwvZm9udD48L3N0cm9uZz48L2Rpdj4KCjxkaXYgc3R5bGU9IiI+PHN0cm9uZz48Zm9udCB...
[2015.07.10] Application Error
www.HawaiianHope.org - Providing technology services to non profit organizations, low income families, homeless shelters, clean and sober houses and prisoner reentry programs. Since 2015, We have refurbished over 11,000 Computers !
0
Scott Hendrickson Replied
Hi Curtis!

Yours is not quite the same issue. The entries in our error logs say, "Reason: A change was made to the application level configuration", which is a bit different from yours. Plus for us, or for me at least, I never get an Oops screen. I just get a message saying, "Your web browser has lost the session with the server. Press OK to return to the login page.", and when I click OK, I do get the login screen and just need to login again.

Plus I just discovered the cause, or at least a major contributing factor, in my particular case. Details to follow....

Scott
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Scott Hendrickson Replied
Hi Guys! 
 
I think I discovered the problem yesterday, or at least a major contributing factor.  It's something that's not supposed to have anything to do with websites.  Quite a while ago, I discovered we had a significant problem with attempted break ins on our server, both through RDP and FTP.  I installed a small program called IPBan to help with the RDP issue.  This program created and used its own rule in the Windows firewall and so did not have any affect on websites.  I ended up changing the RDP port, which actually proved to be most effective in the end.  I also installed a similar program for FTP that parses the FTP site's log file looking for failed logins.  If it finds 5 or more failures in an hour, it blocks the IP by entering it into IP Address and Domain Restrictions in IIS, supposedly just for the default ftp site.  
 
Well last night I used ProcMon again, this time to monitor SmarterMail's w3wp.exe worker process itself as opposed to the SmarterMail folder structure.  I found that at one point, it accessed the file C:\inetpub\temp\appPools\SmarterMail\SmarterMail.config, which apparently is a config file for the SmarterMail app pool that I didn't even know existed.  It was at this exact time that the app pool recycled or otherwise dropped the browser sessions.  Sure enough, each app pool's config file was modified at that same time, thus producing the app level config change.  I believe it disrupted the other app pools too, but wasn't as noticeable.  
 
When I first set up IPBan for FTP, I had it firing every 15 minutes, and strangely enough, the resets actually were less frequent.  When I went to SM v14, I happened to notice that the powershell script for IPBan was using a great deal of memory, so I set it to trigger once per hour instead of every 15 minutes.  When I made that change, the resets actually became more frequent and more consistent, which eventually allowed me to tie them to IPBan.  
 
What I don't understand is why it affects websites.  The offending IPs are supposed to be blocked just for FTP sites.  However I checked in those app pool .config files, and there is a section called system.ftpServer/security/ipSecurity.  I'm not sure if this section is supposed to be there for app pools, if somehow it was mistakenly added by the script (which I did not write by the way), of it it's some odd IIS thing.  I believe this is the line that does the actual blocking....
 
add-webconfiguration /system.ftpServer/security/ipSecurity -location "IIS:\Sites\Default FTP Site" -value @{ipAddress="$ipban";allowed="false"} -pspath IIS:\
 
Does anyone see anything there that says to add blocked IPs to anything other than the default ftp site?  I could post the rest of the script if necessary.  It's less than 30 lines total. 
 
 
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Employee Replied
Employee Post
Scott, I investigate the SmarterMail.config file within C:\inetpub\temp\appPools\SmarterMail folder.  This file is not generated by SmarterMail.  It seems any website managed by IIS has a corresponding .config generated.  With procmon running on that file, I manually stopped my mail service and the file was immediately modified.  Again this happened when I manually restarted the mail service.  Because it's a config file, I believe this is a expected behavior for that file.
 
As for the "add-webconfiguration" we do not have that in any of our .config files. It very well could have been added by the script.
0
Scott Hendrickson Replied
Hi Robert:

That "add-webconfiguration" line I posted was FROM the script, not the .config file. I posted it here in case anyone who's more familiar with powershell scripts might recognize something.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Scott Hendrickson Replied
OK, big breakthrough, sort of. 
 
I'm now able to reproduce a reset at will.  Just before posting a reply to my ticket, I went into IIS on the server and manually added a single IP deny entry into IPv4 Address and Domain Restrictions. First I did so specifically for the Default FTP Site, and nothing happened to SmarterMail. My connection to the admin area was fine. Then I added a deny entry into FTP IPv4 Address and Domain Restrictions AT THE SERVER LEVEL, and boom, my SmarterMail admin connection was reset. So I'm guessing that IPBan script is making entries at the server level, and if I could figure out how to have that script make the entries at the Default FTP Site level instead, everything would be fine. 
 
Anyone familiar with powershell scripts?  I know, I know, not the forum for that. :-(
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Jason Cross Replied
Interesting. We don't use FTP via IIS, which could account for why you continue to see resets since the change to the cleanup process while we do not. My guess is this is a separate issue with the same consequence (otherwise the change to the backup timing and the cleanup process would not have cleared up my issues).
0
Paul Blank Replied
Is there any new info / resolution on this? 
0
Employee Replied
Employee Post
Are you experiencing this issue? We understood that everyone that was experiencing this issue have since resolved it. We don't have any open tickets related to this. Unfortunately, all tickets had unique causes--no commonality between users.
0
Paul Blank Replied
OK thanks. Have some issues with a client that has older version of SM, but won't be opening a ticket on this unless it is still there after a complete upgrade of the server and SM software to current version, which will happen soon!
0
Merle Wait Replied
Ok, did I miss something, we are most current release of SM.. 14. ?  = and are still experiencing this.  What do I need to fix?
0
Employee Replied
Employee Post
Merle, because of the nature of this issue, I recommend that you open a support ticket. As I stated, the fixes differed for each ticket related to this issue.
0
Scott Hendrickson Replied
Hi Merle. Make sure you look at anything on the server that affects IIS in ANY way. In my case it was something completely unrelated to SmarterMail. It was a security program that ran every so often and, if necessary, made entries in IIS's IPv4 Address and Domain Restrictions. It was supposed to be affecting just the default FTP site. However the tool was making entries at the server level instead of just the default FTP site, and this cause updates in config files (that I didn't even know existed) that affected not only the default FTP site, but also ALL websites on the server. It just so happens that SmarterMail is the only site on this server that makes use of logins and session state, so it was the only one showing the browser-lost-the-session symptom.
Scott Hendrickson SOS4Net, Inc. Centennial, CO. U.S.A.
0
Merle Wait Replied
Guess I'll open a ticket (probably next week) ... Only Sm is running on IIS as a site, and FTP isn't even turned on running. Thanks
0
Employee Replied
Employee Post
Merle, to begin, I would verify the server has all updates applied, including any optional updates found in Windows Update.
1
Matthew Leyda Replied
Its now 2017 and Ver 15 (And I assume Ver16) still has this problem. Will it ever get fixed?
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Paul Blank Replied
Great question. Matthew!
0
Gabriele Maoret Replied
Same issue here!
0
Matthew Leyda Replied
Time for a update to one of the questions SM seems to be ignoring.
Its now LATE 2017 and Ver 16 (And I assume Ver17) still has this problem. Will it ever get fixed?
Kendra Support http://www.kendra.com support@kendra.com 425-397-7911 Junk Email filtered ISP
0
Paul Blank Replied
I did some tweaks some time ago for a client with an older version of SM (v11.x) and that issue had gotten much better, though not totally resolved. Look at Scarab's response and suggestions, at the top of this thread, from April 1, 2015. I found those tweaks quite helpful.
0
Von-Austin See Replied
Employee Post Marked As Resolution
Matthew if you are still facing the issue in SmarterMail 15 or SmarterMail 16 I would strongly recommend opening a support ticket so we can continue to trace and troubleshoot this issue with you.
Von See Technical Support Supervisor SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
Noreen Braman Replied
well. Can it be that it is 2019 and this is still an unresolved issue? Earlier this year we had "brower has lost session" messages by the dozens, and also, the inability to get the software to load in the first place. At that time, the problem was attributed to the new security certificates, and our webhost updated the certificates and also the server on which our email was hosted. Now here we are, several months later, and the same thing is happening again. I get NO error messages in the smartermail portal, but you can see users signing in over and over and over again within a short period of time. Those users who can get the window to open at all. When I look in the SMTP log, I see Authentication of the user, then Authentication failed, then disconnected.OVER AND OVER AND OVER. I have 408 pages of this since 11:15 this morning. I have one user who can't connect at all, and my email has been running just fine until 5 minutes ago when I lost connection to the browser but was able to reconnect immediately. We are frustrated beyond belief, especially seeing now that this type of error has been happening in one form or another since 2015. These are brand new MACS running High Sierra and we have a MAC based server. Our webhost is using Windows.  I have reopened my previous support ticket, but am facing an office full of fed up people who just want me to scrap Smartermail altogether. They are clamoring for Outlook. And we have been here since 2007.
0
Kyle Kerst Replied
Employee Post
Hello Noreen, thanks for including the details on this as it helps paint a picture of what might be going on there. This is not a behavior we see in other environments aside from the rare ticket we receive on this. In those scenarios there is usually a valid explanation for it, typically originating in the web server components themselves. To get to the bottom of this I recommend a couple of things: 

- If you're not running the latest release of SmarterMail I suggest getting that done first and foremost so that you're leveraging the latest and greatest in our web interface and system services. If you need help with this please just let me know I'd be happy to pass along instructions. 
- If you aren't already running SmarterMail as an IIS site, I recommend getting moved into IIS and shutting down the built in webserver as this should net better overall results. Once moved into IIS, adjust your application pool's Advanced Settings to recycle only on a nightly basis, and remove any idle timeouts. 
- Please apply any available Windows and .NET framework updates as we have seen a variety of issues resolved with the Microsoft quality rollup to .NET that was released a few months back. 

If these don't resolve these issues I would recommend investigating further with Fiddler Web Debugger as this should give you a better idea of why the browser is losing connection with the server. If all else fails I suggest submitting a support ticket so we can help dig into it. Hope this helps!
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com
0
Noreen Braman Replied
Thanks Kyle, but what SmarterMail has to understand is that there are many of us out here who may be power users, but get SmarterMail as part of a package from a webhost. It is frustrating and time consuming to go back and forth between you and the web host, especially since this just happened a few months ago (we had a support ticket then) and we thought that the suggested solution was the end of it - and also when users are fuming and the work of a confidential service organization dealing with people in distress cannot be done.  After moving our email to a virtual server in order to upgrade the version (shared hosting clients are still on 11.2) we have lost valuable time and contact with clients. Because this is the second go-round with this, I can't justify "trying stuff" to see what works, especially when I don't have access to it myself. After 12 years with SmarterMail we are going to move on to another system. Thanks for the quick response.
1
Kyle Kerst Replied
Employee Post
I understand Noreen, and I'm sorry for the frustration you've been experiencing. Unfortunately though without troubleshooting its difficult for us to narrow down exactly where the issues are coming from. Often these issues originate in the web server components (IIS) - that is not to say these issues aren't stemming from an underlying SmarterMail problem - only that we have to try things and implement logs to get at the source of trouble so we know how to resolve it. 

I can tell you that we have not seen issues like these reported in the latest releases of SmarterMail and so I do recommend getting upgraded and seeing if that helps. The application pool settings changes I referenced previously are also something we recommend to our server administrators pretty regularly, so I recommend implementing those as well. 

I'm sorry to hear you'll be moving to another system. If you change your mind we are here and are happy to help. Have a great rest of your week Noreen. 
Kyle Kerst System/Network Administrator SmarterTools Inc. (877) 357-6278 www.smartertools.com

Reply to Thread