Same here. Been waiting until it looks more stable. We haven't yet gone more than a week without an update full of fixes. The biggest gotcha I've seen so far is that "Cyren Premium Antispam" was removed. A notable mention might be the changes to the RBLs and IDS rules and MAPI bug fixes.

no upgrade for me yet, waiting for MAPI issues to be resolved.

Same here @Mike Mulhern. MAPI is my biggest concern and the protocol I have had the most issues with.

I upgraded. The installer locked up for two hours before finally completing successfully. The server ran at high cpu for most of the day but then settled down. My biggest issue is broken CalDAV for iPhone calendar sync which ST is looking at. So far everything else is smooth. I haven’t used MAPI.

We are waiting as well.

Still waiting here too. While a lot of things are looking good, it seems there are still issues to be resolved before we can afford to upgrade our production rig. We really want to avoid to trigger a wave of angry customers this time.

Still waiting here too, not even remotely thinking about upgrading production for probably another few months. We did do some testing to make sure there was no conversion issues that needed to be reported. Our primary SM install has been rock solid with uptimes in the 3+ months at a time with nearly 0 tickets related to it.

Our SM install has not been this stable in a very long time, so it is nice to have some stability and no tickets about it.

I am still waiting from 8451.  I watch this forum in the same way.

I have upgraded a small (only 16 accounts) on premise server.

With 8510 everything seems to work well now, albeit I needed to trigger "resync user protocols" to some accounts to get they sync

What Gabriele said.
Exactly my experience. 8510 seems to be a safe upgrade. 8504 was not. I should have waited. Lost 2 customers to O365 because of that.

Today I'll update another little server on-premise at a customer office (only 53 accounts on this, all webmail and IMAP, no MAPI or EWS...).

Then I'll wait another 2-3 weeks before give a chance on my bigger server (186 unique cloud customers with many accounts each one...)

I installed to a 350 user domain and it seems fine. Not one call. 99% are webmail users.

Hi Marc. Webmail is fine. Its the Outlook MAPI integration that fucked everything in 8504. Nor was mobile clients affected.

I'm also waiting, I'm a little reluctant to upgrade a 2000 users server with mixed IMAP/POP/Webmail users and a 4600 users server where all users use Webmail integrated with LDAP.

Also holding on 8451. I do really appreciate these threads, so thanks everyone for the feedback.

We had a issue with Build 8451 and had to revert back to the Build 8251 as those who use the web version were not getting notifications of newly arrived email (even after restarting the server). A few other changes happened at that point which we needed to go revert back.

With all that we are reading, we are going to wait to update to the new build on the main server.

We did update our Backup Mail Server to use the new build and out a couple of emails on there to test. On this server, we are unable to test the MAPI/EWS as this is only the free version for the backup mail server. Most of our clients use the MAPI/EWS.

We are waiting, too.  The first RTM build and the ones following it, just have way too many 'fixes' to problems that don't exist on 8451.  

It took over a year of tickets and patches/fixes, to get a major account settled into a condition where they aren't suffering daily from MAPI bugs. We aren't going to upgrade until the current version is clean and stable, as evidenced by future updates with very few "Fixed" entries and mostly "Added" and "Efficiency" notes.

Any open issues related to MAPI or synchronization, unfortunately make the new version a non-starter for now.

 

I decided to upgrade. I started with version 8517 - upgrading from 8251.

The biggest issue I've had is with Inbox on some user MAPI accounts not syncing after the upgrade. I've had to force sync of protocols or resync all devices. I've noticed a small percent of RAM increase - about 3%.

My most problematic and whiney customers use MAPI so any MAPI fixes are appreciated. About to lose a customer to O365 because of MAPI issues.

I have experienced a memory utilization increase as well, but seems like the smartermail service now uses about 20% more. I think I will need to upgrade the server it is hosted on.

We are holding on the upgrades as well.

We've really been struggling with our MAPI and Outlook users. CPU has been really high on the server and lots of struggles with Outlook on the client machines. Trouble sending messages. Disconnects etc. It's been a long couple of weeks. We're anxious to help in whatever ways we can to get this solved. But there seems to be more work ahead.

There was a bunch MAPI related fixes on May 4th, did that update solve the problems for anyone?

Very sorry to hear about the increased RAM usage.  We're already at 72 GB installed RAM on this server, with 62-64 GB normally consumed while running, with frequent spikes to 70 GB.  CPU (Xeon) usage averages 55-65% sustained across 20 cores.  This particular server (Dell R440) was brand new less than a year ago, and only hosts about 1,700 active users.  There are no other services besides Smartermail on it.

We're keeping our fingers crossed that once all the MAPI bugs are fixed, that Outlook MAPI sync will be more reliable than the prior track (we're on 8451).  That's our biggest complaint-- Outlook not staying in sync.  Many Outlook users have gone back to IMAP with the CalDAV Synchronizer utility for now.

To be clear, we want Smartermail to succeed in the MAPI space.  We run both on-prem Exchange and manage Exchange 365 for some customers, and Smartermail is the clear winner on the administrative side.  Exchange 365 is one hassle after another.  And although Microsoft heard the outcry and agreed to continue offering on-prem Exchange licensing beyond Exchange 2022, their obscenely high pricing is clearly designed to force customers to choose 365.

 

Jay, that is crazy... We have 20k users and only run around 24GB of RAM with maybe 20 - 30% CPU.

We have only 16gb ram on our server. SM is only application hosting. Approx 150 users. During waking hours this week while users active in Outlook, we were seeing CPU averaging 50% and peaking up at 98%. RAM for Smarter Mail eating anywhere 10 to 12gb. As of this writing, Saturday CPU back down to 1 or 2% ram 8gb.

Effect of this during the week was constant syncing and disconnection from Outlook clients and webmail slows to a creep. 

Good news is that the server is accepting inbound mail.

Hopeful this will get solved ASAP. 

Everyone will see a jump a bit after their first update to these versions as we have a background process that will revisit every GRP file for each user. We do this because there is some additional information the CFG now stores, such as "HasCalendarItem" for example. This process happens in the background after a user is loaded for the first time, it happens in the background without interrupting the user but it does put load on the server. This only occurs once per user after the update to one of our recent versions, so after a couple days you should no longer see this.
This background process uses a maximum of 5 threads (on a 8 thread machine that's half your CPU). This process will also cause us to use more RAM than normal because we cache items that are recently loaded, and if were loading everything a user has we're technically caching quite a bit.

This process I'd expect large servers to finish in a day or 2 with some users being trickle updated throughout the week as they log in for the first time. User's with mobile devices will hit the server first and be visited first. I know there are other CPU/Mem concerns and we are looking a profiles as we get them. Hopefully this helps explain what the initial jump could be after upgrading in some scenarios. If you have been running for week+ on the current update it very likely that this ISNT what your seeing, but if you recently updated likely IS what you are seeing.

EDIT: You can adjust mailbox_subversion_upgrader_thread_count in your server's settings.json if you wish to speed up or slow down this process, though it still requires your users to be touched (they login, they receive an email, etc) before they upgrade.

Thanks Matt, we are hopeful for another update soon. 

Outlook clients are showing "Trying to connect..."  Users toggle around then it comes back online. But then goes out again.

Issue was seen throughout last week and the start of this week. We assumed related to CPU/Memory. But perhaps something else under the hood is causing the connection to drop?

Hi Matt, I really appreciate that detail. That is what I thought was happening for a couple days after our upgrade, and it definitely improved after a couple of days. I didn't know about that setting so it might be helpful to others who want to reduce that. Is there any way inside of the admin interface to identify that that upgrade process is happening?

You can easily identify the day I upgraded from this available memory chart:

I similarly see a cpu spike for a couple days after the upgrade. The memory trend has improved slightly after the upgrade process Matt describes, but it's not back to its previous level.

@echoDreamz  - 20k users on just 24 GB of RAM.  Are these primarily IMAP and POP3 users?  Before we added MAPI, we were averaging in the 3-4 GB range.

About 18 months ago we added a client with 1,600 users and saw average RAM consumption instantly jump into the 30-40 GB range on 4 TB of data.  As their mailboxes have grown, so has RAM consumption, to the point we're now pushing 62-68 GB daily (with higher spikes) on 7 TB of mailbox space consumed.  Users are MAPI with a mobile (EAS) device, or Webmail plus EAS.  Several dozen could not keep Outlook in sync on MAPI and switched to IMAP + CalDAV synchronizer.

We also started seeing huge RAM spikes that would cripple the server, along with CPU hanging near 100%.  Other times it's just CPU hanging, and this is on 20 cores of Xeon CPU.  Once the CPU or RAM go "runaway" it remains that way until we stop the MailService.exe process, wait for it to exit memory (usually 1-2 minutes to drain off) then restart it.  

Here's one that happened this morning right as our largest customer started their workday  (I know this is off-topic, but since we're talking about resource consumption...)  We gave it time in case it was indexing or re-syncing, but by 1 PM it was obviously not improving, so the service was restarted.

We have upgraded to the Build 8524 to solve an issue with CalDAV not connecting on macOS/iOS and with the upgrade we introduced new problems. I'm not seeing a significant difference in resource usage, though this is a rather new server in the cluster and is not having more than 1000 users yet.
But, there are some issues with the angularJS, which make the webmail interface unusable. The New e-mail window pops-up blank (the same happens when you click on Reply). The message heading is not visible (sender, recipient, date and other info). There is no download attachment option/button.
From what I see in the browser console, angular.js is blocked - due to Content Security Policy, and this results in getting 404 errors on some files, eg /interface/app/email/message-view-components/message-header.component.html. I tried to add headers with 'unsafe-eval', but this didn't solve the issue, but caused more errors.

I'm pasting error from the Chrome console:
Content Security Policy of your site blocks the use of 'eval' in JavaScript`
The Content Security Policy (CSP) prevents the evaluation of arbitrary strings as JavaScript to make it more difficult for an attacker to inject unathorized code on your site.
To solve this issue, avoid using eval(), new Function(), setTimeout([string], ...) and setInterval([string], ...) for evaluating strings.
If you absolutely must: you can enable string evaluation by adding unsafe-eval as an allowed source in a script-src directive.
⚠️ Allowing string evaluation comes at the risk of inline script injection.
1 directive
Source Location Directive Status
angular-v-100.0.8524…cc579df4200.js:1295 script-src blocked

I opened a ticket with the support yesterday, but I am not getting any answers yet. This is a major issue for us since lots of our customers use web interface exclusively.

Have you tried in EDGE or Firefox to see if its only Chrome related?

Yes, tested in Chrome, Firefox, Edge, Brave (mobile version) and the issue is same.

I have that issue in Vivaldi. It also opens in a Tab instead of a New Window.

It doesn't open in a tab for me, it just opens a blank page.
I installed latest build on another server for testing purposes, and reproduced the issue. So I would say the webmail is broken in latest release.

Hi Nikola!

You have some strange issues... We already updated 2 servers at the latest 8524 but never seens issues like yours...

Could it be that these errors are the fault of some security software (Antivirus, Firewall, EDR, etc...) that you have installed on your server?

However, just to be safe, we're waiting to see fewer bug reports before upgrading our third server, which is the biggest and has thousands of users...

I found the issue. Our installation is configured in a virtual directory, not in a website root directory (this is how it was configured in the previous build when it worked properly). So we could login but some of the content is being redirected to the root, consequently returning error 404.
Setting up the SmarterMail in a website rather than in a virtual directory solved the issue.
Thanks guys for the ideas.

Memory/CPU issues are causing our server to max now about 2x per day. We've already restarted once today. It seems to be related to MAPI or calendaring issues with Outlook. Users are reporting when toggling to the Outlook calendar, the Outlook client will hang. Maybe related to overall memory or maybe part of the issue. We're anxious for a fix. In the meantime we're restarting the service when we max out as a workaround.

@Michael - When you restart the service during business hours, are there any repercussions for the users such as webmail user sessions, users composing new emails at the time and/or drafts, etc...?

I've always feared restarting the service when there's a lot of user activity because I don't know if there are any side effects? 

Seph Parshall you raise a good point. Generally we wait until after hours to do any restarting, but in this emergency users are already so disrupted (their Outlook isn't connected and Webmail users are all hanging) - they are just happy for a fix. Our procedure is this: 1) stop the SM application pool. 2) stop the SM website, 3) stop the SM service. Wait 2 minutes. 4) re-start the SM service, 5) re-start the SM application pool, 6) re-start the SM website.

At last restart SM was eating up 14GB of our 16GB RAM and CPU was also about 90%+ 

The SM application and the server machine in general were effectively hanging.

We restart the entire VM. Sometimes in the middle of the day, unfortunately. 

The reason I ask is that when I restart on a weekend night, if some of my MAPI customers have Outlook open at their office - I have problems with them after updating and bringing SmarterMail online again.

I have MAPI client problems - even though I follow these steps...

1. Kill all sessions in SmarterMail web interface

2. Shut down IIS

3. Shut down SmarterMail service

4. Uninstall SmarterMail

5. Reboot server

6. Install new version of SmarterMail

If I restarted SmarterMail during business hours when most clients are syncing Outlook and phones and phones are connected - I would expect to have a lot more problems after bringing the server back online.

Seph,

Those are the exact same steps we do, and yes, we have customers with MAPI report coming back to a frozen outlook, an outlook stuck prompting for a login or it just says "disconnected".

Have not had any complaints about mobile devices, just MAPI+Outlook.

echoDreamz  we're seeing all same symptoms. 

frozen outlook, an outlook stuck prompting for a login or it just says "disconnected"

I just assume it's related to SM/IIS being down and not responding... Not much ST can do about that.

SHould it matter if you run cached exchange??

During a recent upgrade I also saw one Outlook client remain in the disconnected state for about 5-7 minutes post-upgrade, but at that point it connected and synced down without issue. That long delay between upgrade completion and updated sync is not something I've seen before and normally the upgrade process only causes a minor blip for end users who are running Outlook. I suspect some of the MAPI issues we're troubleshooting currently are related though so I'd like to look at this again once we get those out of the way to see if I can reliably reproduce it (since I've only seen it the once, on one account.)

@Seph: Killing all sessions prior to your upgrade could be contributing to them staying disconnected longer than they should. Can you try by simply stopping the app pool/IIS site/service, then doing your upgrade from there? The other thing I do during an upgrade is I start the app pool/IIS site while the installer is finishing writing the new build files so SmarterMail and the IIS components come back online around the same time.

@Brian: Cached Exchange Mode is the only supported method for our implementation of MAPI. I believe we have made strides in implementing components required to one day support both, but we're not quite there yet. Cached mode is defaulted in Outlook when selecting MAPI so this isn't normally a big deal, but you'll run into trouble in Terminal Services environments because it does NOT default to cached mode there due to limitations in TS. 

Thanks Kyle. I'll give it a try [IIS app pool]

I upgraded a few weeks ago and have been fielding issues with MAPI, and delayed emails in Outlook. To be honest outlook users are the ones complaining but they are also the ones in management. I have been notified that management is now looking to move away from smartermail, they, in their words "cannot run a multi million dollar company when their emails don't work properly"!

I don't understand the need to wait and make one big production release versus continuing what they were doing.  New development with monthly releases.

I would wait for a few more revisions if you have a large client base. My phone is still having problems syncing using multiple accounts. 

8531 has resolved the calendar sync problems with CalDAV to Mac Calendar and iOS Calendar that I mentioned in a comment above.

Hi Tim,

I have a suggestion that I'll tag-on with, but has been expressed by myself and others in the past.

Our concern is the either-or nature of the product development tracks.  Once a new build is in beta, development on the current track pretty much stops.  Known bugs are not fixed in the current track unless they are serious-- we're told they will be "fixed in the next major release" but that can take months, such as the most recent Beta which took months.

When you look at OS development, for example (Windows, Linux/Unix, etc.) there is always continued support of prior versions when new builds are released-- the latest RTM and at least one prior build.  (Windows 10 still gets plenty of bug fixes even though Windows 11 is the current version.  Ditto for Windows Server.)

For those of us with mission-critical customer bases, who absolutely cannot move to the new release because of the "new build bugs" which take months to resolve after going RTM, there should still be bug-fix releases for the prior track.  One of our large (as in six-figures a year) customers went through almost a year of suffering when we brought them on as a MAPI customer from a competitor, and our support ticket history is a testament to how many bugs had to be fixed to get them to a workable condition that was (mostly) free of pain.  It was so bad, their CEO demanded to be released from the contract; fortunately we were able to buy a little extra time and the next build was enough to calm the storm.

We REALLY WANT to move to the new build for the new features AND (most importantly) some bug fixes for nagging problems which are not being released in the track we're on.  But, the number of new-build bugs still being worked out prevents us from upgrading.  We just... can't... jump from "calm enough" waters and jump back into known issues.

We strongly encourage ST to reconsider the "only in the new build" bug-fix approach.  Definitely produce new builds-- that's great, and we all love "new and better".  But, for those of us who MUST have a STABLE environment at all times, please consider offering bug-fixes on both the new version and the one most prior (in this case, the 8451 track) for some reasonable period of time before abandoning the prior track.

Just a friendly suggestion, humbly submitted.

Jay:

Did that 8451 track become stable enough that clients who use Outlook and MAPI are happy with it?

Thanks

I have upgraded 2 small customer on premise servers to custom build 8536 and so far everything seems OK.

They are small installations with a few dozen users, so I can't say that I have a large number of cases, but for now I have no problems and the reported bugs all seem to have been resolved.

Now I'm going to install the new official 8538 build and let's see how it goes...

Awaiting your feedback Gabriele. :) Just about to pull the trigger as well.

I'm upgrading to 8538 right now. But time will tell. I would like to have seen more fixes for MAPI and sync issues on the list.

We are running 8538, so far all is well. The users reporting ? mark symbols and what not have reported it is resolved. A user that was experiencing issues importing an ICS file (pretty large one) also states his issue is resolved.

We are having weirdness with the IDS system, seen several IPs in the logs indicating they are blocked, but they are not shown in the IDS list, but when we clear the IDS list, the IP suddenly works again, still trying to figure that one out.

@Pronto wrote:  "Did that 8451 track become stable enough that clients who use Outlook and MAPI are happy with it? "

Yes and no.  We still get many complaints related to MAPI sync, of several different kinds:

In each case, their IT department triggers a manual sync first.  Sometimes that works, often it does not, so they remove the profile from Outlook, delete the corresponding files and start over with a new profile.  Users with larger boxes (above 10-15 GB) are more prone to this happening, and their IT guys are switching their chronic-problem users to IMAP and using CalDAV/CardDAV to sync calendars and contacts, just to make the problem "go away".  (This is a MAPI customer with around 1700 users.)

We've been told the new SM version has a lot of MAPI fixes that should solve several problems we've had tickets open for-- and we REALLY WANT to upgrade.  The new web interface feels lighter, faster, more responsive, and the extra Outlook features support is exciting-- but reading this forum, we know there are still MAPI issues being worked on.  So we will wait a while longer.  (CUDOS to those who are taking the plunge and shaking these bugs out, so we don't have to.)

So the short answer is, we are at a point with 8451 where there are still unfixed bugs, but they are "familiar" bugs and we are "stable enough" to sit tight on 8451 a while longer.  The unfixed bugs do not reflect well on us, but their IT staff has accepted it and pushback has died down.  We wouldn't DARE introduce any "new" problems right now.

 

I want to be clear, 99.999% of our problems are MAPI only.  EAS on mobile devices works great.  POP and IMAP work great.  Cal/CardDAV (with the CalDav sync utility for Outlook) works great.  In fact, we almost never had ANY problems with Smartermail until we brought on this large client who needed MAPI.  That's when we started to get very well acquainted with the ST Support team.

 

I Started on 8451 and has been through the upgrades.
So far 8538 is the best update yet and I havent heard any complaints yet.
Only thing I had to do was to delete 1 users .ost file to get the mailbox settings synced again.
So far that user, with a VERY large mailbox, hasnt had any issues since.

I find 8538 better than 8451. As for syncing problems, I've found it better since this major upgrade of 8495 - it's better to use the "Resync Protocols" feature in SmarterMail or what has worked even better is to use the "Update this folder" in the newer versions of Outlook. I'm not talking about just to "Send and Receive" on all folders but to select the Inbox and choose the "Update this folder" function in Outlook. 

So far 8538 has been very solid on the MAPI issues we had reported. Best release so far.

If you are having any issues with MAPI, I would re-sync all protocols and/or remove the profile and add the account again in Outlook.

This recent release resolved almost all known issues other than some obscure scenarios that required two or three variables to come into play and things we found not customers.  

This release is increbily solid and has been throughly tested via custom builds over the last few weeks.  Millions of users are now running the latest SmarterMail's and thats when we feel most comfortable because we feel like we are over the hump with obscure encoding or oddball character issues from obscure mail servers that break RFC's etc.

When we first release major new features or functionally especially related to protocols we build it based on RFC's.  The next phase of development is to accommodate all the bullshit the internet and rouge products throw at you!

ONly issue I have found so far is that shared ressources like a meeting room shows up as tentative even though the meeting has been accepted/mail sent and it doesnt change.

Brian,

If you haven't already, please report issue through support so we can evaluate. 

I have allready Tim :)