I am in the same boat as Tim.  If anyone has any experience to impart, it will help us all.

My post from another thread - this is what I found testing:

We are currently testing Smartermail to replace our older mail server software.

Im must say I really like what I see. But I was surprised by finding some serious issues.
(I only now found that this version is just released) .


But from my view it should not have been put in production yet.


Testing as a new client I found to many bugs.
Some we are able to tweak our self - so we might still be a new client.


Im testing the professional version.

- Throttle not working. (max messages per hour set to 10, +1000 mail send in 31 minutes).
This is a huge issue as this is our only protection from misuse of hacked account.

- Disk usage are calculated wrong. Seems some only show inbox. but not sure thats the only issue.

- Domain validation forward address and trusted sender: "-" in domain name is wrongly taken as invalid.

- If I change primary domain admin and then delete the old admin user,
the "administrator" tab still count 2 admins, but only one is listed.
In accounts.json both still remain in the "primary_domain_admin" setting.

- Trial license does not allow support ticket.
API:
- Creating new domains return error: "unable to login" - but domain seems to be created anyway.
- Domains are created with DKIM on, with empty data. (set to off in domain defaults).
- Chat (showInXmpp) is set ON as default (from API) and the user are unable to save without switching it off first. (set to off in defaults).
- Is it legacy or not? Dont call retract it until you 100% offer a new API.


Options I would like to see:
- Possible to store password using nonreversible encryption.- Enterprise only features should be hidden not grayed out in professional version.
- Disable/hide users access to functions like calendar, tasks, notes, news feed.
- If maximum are set e.g. for throttling it should show on user pages - not unlimited.
- POP before SMTP validation to allow outgoing mail. This have been a feature in icewarp for the last 10 years or more. (And an option in many email clients)

Regarding POP before SMTP: I was under the impression that SM used POP before SMTP by default. That said, except for a few diehard local (LAN-based) Eudora users, I don't allow POP for anything. I guess it could be considered a security issue on a LAN, but this has not so far been a problem.

No normally I would not use POP before SMTP, but migrating from a software that offered this feature we get a lot of support activity as users no longer can send mail.

Frank, Tim answered all your reports/findings on your other post. 

SM17 for us (having a very large mail server) is nearly perfect. We have a few open tickets for some minor issues, but so far all the big issues have been ironed out and it is smooth sailing.

POP before SMTP is an old authentication method that is no longer required because we now have SMTP AUTH, so no need to bring in legacy stuff, especially today.

Reading Tim's answers, I would say its ready for production after next release.

Much like the original poster we stuck to 15.7 due to the shambles that was the initial releases of 16.x. However, we finally upgraded from 15.7 to the publicly available 17.x build over the weekend without any major issues. 

Treat it like any other smartermail upgrade - stop the smartermail website in IIS, unload the IIS app ppol, stop the smartermail service then uninstall 15.7. Install '17.x', ensure you point it at the same directory as the old version. 

The only two issues encountered were that despite the installer requesting the license key / login details the install was still running as a free edition. This was resolved  by re-applying the license post install. After doing this the webmail was working but no ports (smtp, imap, etc) were listening so after some deliberation we restarted the smartermail service and they came back up. Probably best to let the XML to JSON conversion to occur first. 

Other than the two issues above it appears to be working fine.

We recently upgraded from v15 to 16, and in the point of view of sysadmin I still miss V15. We receive complains about the webmail slowness every week. We didnt get nothing new and good from v16 and lost a few features from v15 and still getting negative feedback about the webmail, looks better but works worst.

But I support smartertool and I hope in a better future.

Tim,

Depending on how long you have had SM data there are some minor strangeness that can occur. We've been running SM since before v4 with the same data, adopting each current version upon release over the years, and we encountered some really old domain and old account necro going on...domains and accounts that had been deleted in SM over a decade before suddenly came back from no where when we did the v17/v100 conversion. We also had a few minor issues with Blacklists being removed (we have an unusually large Blacklist...perhaps one of the largest) and a few other miscellaneous settings disappearing from the config files. 

Basically, if there is any kind of data corruption over the years that previous installations of SM caused, glossed over, or ignored, it will rear up post-conversion. Nothing game-breaking mind you, but something you may want to look out for (to be safe be sure to verify every screen in your Settings post-conversion). As long as you have a backup of your previous configuration you can easily stop SM and restore the missing sections from your config files (via Copy+Pasta in your favorite text editor) and restart SM...but chances are if the conversion truncated entries in those files it was most likely due to corruption or bad syntax in the original. I totally grep that this is W.A.I. and not an issue with v17/v100, but rather a left-over problem probably from the v7 to v8 data conversion, or the config file changes from v13 to v14 once upon a time.

Going from v15 to v16 upon initial release was very painful for us. Now that v16 feels mature it has been easy to be complacent and not take the plunge to v17/v100 any time too soon. However, v17 is seeming fairly stable by now. There shouldn't be any significant reason to hold back at this point. (*Knock on wood*)

Well, I take back what I said in my last post! If you haven't already migrated to v17/v100 then I ***STRONGLY*** recommend that you do not!

After a test install on a VM with a copy of our data and for the most part going well, when we upgraded to the newest version with our Live data it went sideways to where it is 90% unusable for any of our customers.

I don't care about CPU usage (or the dozens of other miscellaneous issues with v17/v100 that we have found in the past three days since we upgraded). What I do care about is the fact that only 29 out of 273 domains are able to be logged into by either the end-users, domain admins, or SmarterMail admins, leaving customers from 250 domains without email services for the past several days and no way to administer those domains since we cannot impersonate them either! These are small businesses where email is MISSION CRITICAL to their livelihood and we have already lost multiple customers and domains in the past three days due to this issue being unresolved.

We immediately opened a Support Ticket with Smartertools and after three days still don't have a resolution (or even a suggestion of what to try as at this point we are desperate enough to try anything).

If a resolution from Smartertools is not forthcoming shortly we will have no option but to spend the upcoming 3 day weekend installing an alternative such as Zimbra, Kerio, or Open XChange and migrating the users of those 250 domains that are unable to login in to their SmarterMail webmail to another service. We do not have the option of leaving these customers without any form of email any longer after 3 days without.

Think long and hard before committing yourself to v17/v100. If you have a VM make sure you have a snapshot that you can roll back to immediately if/when the upgrade goes sideways.

OMG!!! must of our clients dont wait 3 hours without email

3 hours is not that bad. Here phone rings after 5 minutes 

Ouch. Thanks for keeping us apprised. 

Thankfully POP/IMAP/SMTP are still working and only webmail is down for @ 250 domains (EWS was also down for everyone but we resolved that by removing the \MRS\EWS directory that was left behind by one of the past 333 SM updates we installed over the years). The majority of our users have been pretty understanding when we explain we opened a Support Ticket and are still waiting to hear back and offer to help them setup their POP/IMAP account in an email client (Webmail users were probably only 10% or less of our userbase, thankfully). Clients who need a new email account setup NOW! are seriously upset though, but for managing most of our domains there is absolutely nothing we can do atm.

It's been especially difficult as no word from SmarterTools and I've been too busy helping get our SM web-mail users setup on POP/IMAP/EWS to troubleshoot myself until after-hours.

And webmail not working is only the first deal-breaker for us. SM Incoming Gateways also being broken, Lets-Encrypt Cert Renewals being intercepted by SM, not being able to see 2FA settings (even for the few domains we can impersonate) despite ST insisting this was fixed several builds before just make the entire v17/100 show not worth it. 

Lets encrypt sounds like a IIS issue. Not SM. Are you forcing https with url rewrite then that will stop lets encrypt unless you setup a rule. See our rule below. This work with SM.

Web mail works perfect here. So you might have a IIS issue with that also?

If administrator cant login I would check I got the right credietial.
Look in: SmarterMail\Service\Settings\administrators.json for username.

If you want to try a new password for administrator: Test12345
Put in:
 "password_hash": "1000:5cP0PKxZ/b9cPsPMW9Mxo1wLk4ZlcSpx:OsaXnBRJZoTd6dx8Da8sVfk4aVv4GaGU",

(Not 100% sure if the hash work between different installation however).



 </system.web>
  <system.webServer>
<rewrite>
            <rules>
                <rule name="Allow LetsEncrypt" patternSyntax="Wildcard" stopProcessing="true">
                    <match url=".well-known/*" />
                    <action type="None" />
                </rule>
                <rule name="Redirect HTTP to HTTPS" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" ignoreCase="false" />
                    <conditions>
                        <add input="{HTTPS}" pattern="off" />
                    </conditions>
                    <action type="Redirect" url="https://{HTTP_HOST}{REQUEST_URI}" />
                </rule>
            </rules>
        </rewrite>

Even if it's due to IIS issues, it is troublesome if you are not getting support from ST. 

Just sayin

We upgraded from 16.x to 6970 in late January.  Two problems were found after the upgrade (one of which I believe has been fixed) :

1) After upgrade all of our URIBI's and RBL's Required Lookup Values were reset to * and all mail started going to SPAM folders.  Once we figured out that problem the fix was pretty easy - We killed all the URIBI's and RBL's until we were able to find and enter the proper Required Lookup Values.  We also have a current subscription to Mail Sniffer, we left it running to provide some SPAM protection until we were able to modify the other settings.).  This problem seems to be fixed by version 6985.

2) We found that we were no loner able to view user passwords with our alternate Admin account.  Andrea provided the answer found here (https://portal.smartertools.com/community/a91647/cannot-view-user-passwords-in-ver-smartermail-6970.aspx ).

This brought up another problem in that we were unable to login to the primary admin account with what had been until the upgrade, good credentials.  We used the provided password reset tool ( https://mail.smartertools.com/d/smartertools.com/7Mi7tg/1RD8MU0GCYZV ). 

 It works and is a lot easier to use that the manual method.  Just be sure to stop the SmarterMail service before running.  It took about 20 seconds to stop the service, run the tool and restart the service again.

Hope this helps.

We are entirely ready to sever all ties with SmarterTools and never use nor recommend their products ever again. Their Technical Support is beyond useless and will respond to any Support Tickets with "So this is working now, right? We all good here bro?" without reading anything you submit or doing anything at all (okay they didn't say "We all good here bro?" but they might as well have from their flippant response to our SmarterMail being unusable post upgrade to v17/100).

If things go fine with your SmarterMail installation then everything is wonderful, but can you trust them when things go wrong or when things break SmarterMail? The reason why you should reconsider upgrading at this point is that you are entirely on your own and will get absolutely zero assistance from SmarterTools Technical Support. I would expect that behavior from Open Source Software but not from a company that is providing a proprietary product that is marketed as SaaS.

Technical Support is a very important part of any product. You hope that you won't ever need it but when you do is usually a critical time and if you can't count on a company's Technical Support to be there for you when you need them the most then you should seriously reconsider why you are using their product in the first place.

I just ran through this process this past weekend (16.3.6885 to 100.0.6985)

My #1 WTF issue... make sure you have your LICENSE CODE HANDY as eventhough this is an upgrade, you will need to re-enter it otherwise you are stuck running in TRIAL MODE.   I kid you not.   I had to dig back through emails to locate it since the system has now been upgraded and you cannot just pull it off the licensing screen.   A WARNING about this is all it would take in advance of running the update.

One other thing not listed in the instructions was after the upgrade is completed... be sure to do one final restart of the SmarterMail service (or a reboot of the server itself)  I didn't at first and was ready to revert to my preconversion snapshot because sending and receiving messages was not working.   Just on a whim restarted the SM Service ... poof!  Everything started working.

Other than that, our 300ish domains and 3,000ish mailboxes all converted in about 10 minutes.  (Your mileage may vary) with ZERO detected errors or warnings.

One thing I find odd, is that the convert_status page is STILL AVAILABLE days after I ran the conversion, but it no longer shows the convert time for each domain (which it does during the conversion and shortly after it), just now says "Up to date" for each domain.   So I dunno if this is running its own updates at night or what, but something change the status displayed in that screen.

We have had a few issues since the update to 100.0.6985:

Aside from that, the system is running well for my users.

One "benefit" I've seen is my IMAP bandwidth usage has gone WAY WAY down... can't explain why but it used to peak around 2.3G per day, now it has been under 1G for each day since the upgrade... with no complaints from customers, so I am assuming it is all working... or I have a lot of customers on vacation.   SMTP in/out seems to be about the same as from before the update but POP bw seems to have increased ever so slightly.

Hello Rod,

I'm gonna address a couple of your points. I addressed your 2nd point in your ClamAV thread. 

Your 1st point is valid, we may need to throttle a mailbox archive search so that it does not affect the performance of the rest of the server. However, archiving will be slow by nature, it's why we designed the page to "run in the background" as in searches performed have their results temporarily stored in memory, for a couple hours after finishing.

Your 3rd point is interesting, I'll check our log for those errors as there might be something we can cleanup to fix that.

Your 4th point, When users are Queued for indexing they will idle for a set amount of time before actually starting their Index. When they are Completed we keep them in the list for I think 2 minutes before removal, I can double check this. Your point about it always indexing is a good thing, it's actually doing its job as mail flows in it will have to update the index for your users. ANY change to an email, calendar/task list, contact list, or notes will trigger an index.


@Scarab, I'm sorry you've had a bad experience with support. If you are still experiencing any issues go ahead and DM me and I can work with you directly. To say we don't help is false, support has been working very hard to keep up and as far as development is concerned, we are a bit split atm since we have some working on MAPI and a couple still trying to manage bugs and support work. 

UPDATE: @Scarab, I'm glad Derek and I were able to help resolve the issue, as posted in your other thread.

Thanks again Matt.   

One of those errors (the one about not implementing IController) I've issued a support ticket for already, chatting with Tony Scholz, he seems to think it may be due to the NetworkService user not having FULL rights to the MRS folder.  (They do not... and never have prior to this...)

Will try it later tonight and see if it makes a difference... Users have already been down once today, don't want to do something that could potentially take them out of service again... and permissions changes on the Webmail website folder... that could do it.