Yeah, logs area is under the "Manage" icon, troubleshooting then Options. While the SM 16 interface has grown on me, I still miss 15 :(.

... wondering when v16 will be out of beta... or is that called v17?

Ha!  I say when a new minor is released and a full 30 days go by without another update (hasn't happened yet for v16).

"and a full 30 days go by without another update (hasn't happened yet for v16)". Unless absolutely nothing happens to 16 which I doubt since 17 fixes will roll down into 16 I don't see 16 going without updates for more than a month for a while. We have been intentionally releasing more often, yes, that has bit us lately do to some slips but we have been thinking about adjusting our release schedule and when we do them (this week we released 16 on Monday). However, we have been very much trying to stick to weekly (or bi-weekly if not much or nothing important) for our updates to 16. Looking at the latest version of software which receives the most work and comparing it to the releases to an older version running a older version of our Frontend (and now with 17 a big piece of the backend) and considering it stable vs the current version is a bad comparison. A lot of fixes we do in 16 can't get rolled into 15 or haven't rolled to 15 because of major changes.

Hi Matt,

it's OK to have a shorter release time but it would be great to get incremental updates with not having a longer downtime for uninstalling SmarterMail and reinstalling it again.

Kind Regards

Matt, great to see that you are monitoring these forums.

Let's put ourselves in the customers' shoes -- they expect 100% uptime with no issues. That's the expectation set forth by G Suite and O365.

Unfortunately, SM is not an app on your phone that's a 1-click install.  Instead, it's 30 minutes of downtime that affects thousands of users. So we do it at 5:00am which still gets a few people upset who can't check mail. Then multiply that by 10 servers and bi-weekly SM releases and it's nearly a full-time job.  Just some perspective.  More details in this thread:

We appreciate all your effort and listening to your customers to make SM better. Thanks.

Not to mention that many of these releases are not just improvements to the product; some are fixes to bugs - some quite serious - that were introduced in previous releases.

Thank you for listening and caring such that you are available to triage a release by not letting public releases out at the end of a week prior to several days away. That is a slight commitment that means a lot and shows your professionalism in both listening and quality. 

To the above, you do NOT need to uninstall first to install an update. Only uninstall and reinstall when going between major releases. 

I like frequent releases as I do want bug fixes out as soon as they can be released. I'm still waiting on EAS Calendar not working, an open ticket, going on weeks now of unable to use my calendar in Outlook 365. I hope someone can prioritize that situation.

Hi Neal,

I have to disagree: If you take a look at the docementation (see https://portal.smartertools.com/kb/a2855/minor-upgrade-of-smartermail.aspx) you can see, that the uninstallation and re-installation of SmarterMail is always required - even when only doing minor upgrades:

Kind Regards

It may not always be required, but it seems to be the recommended procedure to uninstall before reinstall. Some recommend rebooting both after uninstall and after reinstall, to be safe. This was the mantra, as I recall, of the late great Bruce Barnes.

In the (sometimes distant) past, I have had issues with the SM built-in web server becoming re-enabled, and with having to re-enter the SM installation key, especially with version upgrades, so be on the lookout for these.

We have an automated app that handles updating for us. When we run the app, it checks the version, if an update is needed it does...

1. Downloads the latest build

2. Verifies the digital signature

3. Stops IIS and waits to confirm that the w3wp processes are all gone

4. Stops SmarterMail and waits to confirm that the mailservice.exe process is gone

5. Runs the uninstall of the current build

6. Reboots the machine

7. We log back in and the app restarts

8. Stops IIS again if needed

9. Verifies no SM services are running etc.

10. Installs the new build

11. Waits for SM to fully start, then starts IIS

Unnecessary in my opinion. Never had a problem with updating over top of the current build. That's what installers are designed to do, called minor updates. Major updates (first version number change) typically requires a removal of the old, installers should do this automatically too but we don't trust SM's installer that much!

We've had issues in the past where the installer complains it cannot update files etc. and wants a reboot of the server etc. Doing this way has never failed us or encountered any issues. Normally, we do Windows Updates alongside the SM update, since SM takes ~40 minutes to fully start, we do as much as possible in a single restart.