You are not the only one....

There are many threads with the same issue.  For us, reverting back to the prior version resolved all of the MAPI/EAS issues.

Best of luck!

Whoops, didn't take the time to look for other's with the same issue as I'm dealing with too many things at the same time. Thanks for letting me know. "Glad" to know I'm not alone here.

Are we alone in wondering how a release with SO many problems affecting such a widespread audience, ever got past the QA team and released into production?  I love Smartermail and mean no offense to the ST team, but 8965 was a disaster.

 

The patch release 8969 fixed the MAPI issues for me, support can send a link if you don't have it (not sure I'm allowed to post it here)

Support, please send us the 8969 patch release so we can resolve the MAPI issues. Thanks.

@Jay Dubb (and others too...) 

Well, I understand that everyone complains about these issues (I would too, but luckily I decided to stay on the 8930 and wait a bit before upgrading...).

But... Remember that (fortunately) we are all human and so mistakes are things that can happen...have you ever heard of CrowdStrike this weekend?... 😅😅😅

@Gabriele,

Yes, we are all human and that's exactly why policies and procedures are supposed to be in place; to ensure that these types of failures don't happen.  When you deploy software that breaks core functionality of it's primary purpose it's not a good look.

Your CrowdStrike comparison is actually spot on, but you missed the point.  CrowdStrike has lost $20 Billion, with a "B", in market share, and numerous customers, due to their incompetency and lack of proper controls.  The downstream effects are likely in the billions as well with lost revenue by their clients.  For a lot of the smaller firms that use SM, similar fallout could be devastating to their business and livelihood.

Our company manages hundreds of on prem exchange deployments, 0365 and Google Workspace accounts, and none of our clients would blame MS for an exchange failure.  Likewise, like none of them would blame SmarterTools for a SM failure.  They blame us, because we are their primary contact and in charge of ensuring that their business runs flawlessly.  On July 19th, no one with a cancelled United flight, trying to get home to their family, blamed CrowdStrike, they blamed United.

In our case, we deployed SM along side of Exchange for testing in an AD environment due to the upcoming major changes with MS Exchange.  We're looking for alternatives to MS Exchange for our clients and would be using SM as single deployment per client (no shared deployments/multiple domains).  We immediately noticed issues with 8965 and posted about them here and created tech tickets.  Since we don't have any client deployments yet and we have email continuity in our environment, it doesn't affect us like it would them.  Additionally, we would always deploy in house for testing before rolling it out to clients since we have procedures in place to limit the potential negative effects of 3rd party software.  But like I said earlier, it's not a good look and it doesn't inspire confidence.  The fact that 8965 is still available for download is confusing, at the least - It should have been pulled.

So instead of apologizing for them, I would hope that the community would hold them accountable so that policy changes can happen to prevent similar incidents in the future.  I like the product myself, but I hope that changes are made so that we aren't loosing the confidence of our clients and spending valuable resources rolling back software.

Enterprise products should have enterprise release channels - that only introduce features after they've been in production release channels (and tested) for an extended period of time...  That's the been the problem for the last year - everything went to a rolling release channel.  The fact is this is server software - not a web-browser.  Rolling release channels are just asking for disaster, as we've seen over and over.

@Todd R

Excuse me, but perhaps you didn't quite understand the tone of my answer... which was a little (but very little, eh!) to say that unfortunately mistakes happen, but MAINLY to lighten things up (the emojis "😅" should have made you understand... 😊).

I'm not apologizing for SmarterTools at all, just lightening things up.

Sorry if the effect was different...

Exactly.  The changes have been "Fast & Furious".  Too many new things added into what should have been a fast-track branch, but instead it dropped into what should be the STABLE branch and we're feeling like beta testers way too often lately.  Our client base is based on consulting relationships, and most of our customers have other lines of technology with us.  We won't even sell email service to a client unless we have an existing business relationship.  Our largest client has been with us for more than 20 years, and is one of the largest franchisees of their brand in the world (they singularly earn $billions in revenue).  When a broken email release breaks their operations-- as it absolutely DID yesterday-- it creates immediate chaos, and long-term relationship or not, they hold us harshly accountable.

Put us down as +1 asking why 8965 is still published.
 

SmarterTools: If support said that only solution was to downgrade from 8965 to 8930 in order to solve the broken MAPI problems... why is 8965 still available to download!? How many more upgrade installations need to be unwittingly affected by this?

This last year I've been fearful of every updated since we updated to Build 8664 with many issues. So now we ready the thread's to see what is good or not and wait for a good build. Sounds like, SmarterTools needs to do much more testing before releasing, especially with Enterprise version where our clients relay on the ActiveSync for running their companies.

What would a solid build be to update from Build 8664?

Hi M.G. Wallace!

If this can help you, I'm running 8930 on several servers without major issues...

Thank you @Gabriel. Surprisingly enough, we downloaded 8930 back on June 25 to update one of our mail servers, but didn't in fear of running into issues. We will move forward with upgrading in the coming weeks.

Thank you again.

@M.G. Wallace - We agree with Gabriele that 8930 is relatively stable, and have been on it for weeks.  There are MAPI issues, and we have a few tickets currently open for them, but it's nothing like 8965.  

@Jay - if there are MAPI issues then we just might hold off on updating as most of our users do use Outlook, especially the calendars and contacts. Thank you for letting us know.

We installed the patch last night and MAPI is working again.

Since this active thread suddenly went cold, I wonder if everyone reverted to an earlier build and are waiting on the sidelines for feedback, or if they took 8971 and life is good.  We're not going to update until the community says they did it and all is well.

 

Still on 8930. Holding back a bit...

No offense to ST but I’m done with upgrades for a while after reverting to 8930. I think I went nearly a year and half once without upgrading or even rebooting our SM server when it version 16.x.

Year and a half without rebooting?  I'm assuming Windows Server, with no Windows Updates applied in all that time?  OUCH!!!!!

@Jay, heck yeah! No updates, no patches, reboots, no nuttin’, just purring like a kitten. :) That was a number of years ago.

That takes guts, or some degree of insanity.  :-)  Maybe both.  I'd be more paranoid by the month knowing how many security updates were hanging out there not installed, if it was a publicly accessible server.
 

@Matthew - We did the same with one of our servers. Went just over a year with no updates and reboots. Everything on that server ran amazing. The only reason that stopped us from keeping our server running, there was a fire in our Data Center, causing us to move our services to another dedicated server location till they got our server back online. That was not fun, since we've been using the IP's for many, many years and changing IP's we needed to clean and update many services. Glad they got us back online with our original IP addresses.

Still noticing significant issues with Outlook syncing in 8972 for Linux, and also noticing issues with IMAP in both Outlook and Thunderbird. Such as all new emails not being loaded, but older emails can be loaded fine. Outlook fails to sync any new emails at all or email deletions. Some of the other issues we were having were fixed in 8972 but not everything, it seems.

@James North - do you have a ticket open for the sync failure on new emails?  

8972 has some fixes we've been waiting for, but if there are MAPI sync issues on new messages, we can't take the chance upgrading to it.

 

@Jay Dubb We opened a ticket for MAPI, EWS, EAS, and IMAP sync issues a few hours ago. This is to do specifically with the Linux version, but I believe the codebase is the same across Windows and Linux.

We've been experiencing severe issues with resource utilization (e.g. using up all 16GB of RAM and another 8-14GB of ZRAM (Swap) + 100% utilization of 8 vCPUs) in certain situations. But I don't know if it's normal for Smartermail to need that many resources for ~100 mailboxes, one of them using 30GB of disk space (almost 50% the size of the rest of the mailboxes together).

I believe the issues are separate, but they could be connected. Webmail is the only thing that's working reliably currently.

James, thank you for submitting a ticket and RSAA.

For everyone else, we have almost no known issues related to any protocols or anything performance-related. In fact, we have very few tickets overall, which is why we are responding to them so quickly.

Since most issues are unique to each person's environment and only affect a small number of users, it is essential that you open a ticket with logs, account data, and/or RSAA's so that we can investigate your specific issue as quickly as possible.