It should do so... that was introduced in an earlier build.

Not sure which installer you are referring too but neither should have issues.
For the linux installer, we did change the order slightly of things we do during install to make it a tad faster and more rugged against issues.
Before we would uninstall and then download the update then install. Now we download the update first before turning off the server and installing, we do this now incase for some reason the download fails you aren't left with a hosed install. 
The linux installer will also prompt you asking if you would like to upgrade and then it says the version number, so we definitely ask before kicking it off.

I was referring to Windows Installer. It doesn't stop the service before the install so it pop up dialogs to reboot the pc after.

Interesting, I have noticed that warning pop up occasionally over the past couple years but I never see it do the restart, we never got to the bottom of what exactly was causing it as it was pretty random. My guess is it maybe has something to do with windows updates? 
We have to stop the service to swap the files, we did have issues where a phantom process was remaining showing up as using just under a MB of memory but we fixed that a couple months ago.

If this is behavior you're seeing everytime and if its actually restarting the machine we may wanna start up a ticket and get some OS information and attempts at reproducing it.

@Matt

Well everytime i upgrade with the service active it pops up. Everytime i stop the service before it doesn't popup.

I didn't have any pending windows or other application updates.

I guess you must add a manual command (net stop MailService) or something similar in the MSI script before it starts the installation.

On my side I noticed that when you stop SmarterMail service from the Service manager, after a few seconds it says the service is stopped. But the mailserver.exe process is still running for at least 1 minute.

Then you see the process memory usage falling down (it takes ~10 seconds) and the process is finally disappearing.

What I think is going on is that the installer stop the services and the service manager returns that the service has been stopped, but at this point the process is still running and locking some files, so the installer wants you to reboot after the installation.

To avoid this, before an update I always stop the service first, 1-2 minutes until the process is really gone, and then start the installer. That way it never asked to reboot.

Still the service manager shouldn't return that the service is stopped if the process is still running... That would prevent the issue.

I think also the issue is more noticable on a server with a lot of domains/users/activity.

On a server with 1 domain and 3 mailbox this is not noticeable.

On a server with 5000 domains and 17000 mailboxes it is highly noticeable.

@Sébastien

Nice finding ... The service should be stopped when everything is stopped.
Seems they doing this to avoid the long shutdown of the service and eventually timeout.

Well in that case installer should wait.

My strategy for upgrading (and, sadly, downgrading...) SmarterMail:

1 - uninstall current SmarterMail

2 - reboot

3 - install new SmarterMail

4 - reboot again

5 - test if everything is working

I don't think any reboot needed as Smartermail is designed.

Issue still exists with Build 8993.

To S. Ricco

Support has noted that the SmarterMail service takes longer to wrap up than the service control program allows, so they return a success result to the service controller and then finish shutting down cleanly.   It is odd, but until they can implement a faster shutdown, it is just a known limitation.

For upgrades, I don't understand any reluctance to do a few extra steps to ensure a clean process.  Here's mine:

I’d like to clear up some confusion regarding the speed of SmarterMail’s shutdown.

A few months ago, a few builds had a bug that caused SmarterMail to take a long time to shut down. If someone attempted to upgrade SmarterMail while it was still running, it could lead to unknown issues. If you're coming from one of those affected versions, you may experience a slow shutdown, which could impact the installation of a new version but the new version itself isn't the issue, its the old version with the bug. 

The new versions of SmarterMail also includes code that prevents two SmarterMail instances from running concurrently, which helps avoid some of the unknown issues users encountered.  

SmarterMail makes every effort to finish  connections on the server before shutting down the service. It's not ideal for SmarterMail (or any process) to be terminated prematurely, as it could affect caching or writing to disk. If you have a REALLY large server with allot of concurrent connections, it will take longer than server with a small number of connections etc.  There is also a chance your server could a small number of connections but the connections themselves could be slow or taking a long time. In those cases, we have timeouts which will eventually make that connection fail gracefully.  

The Windows Services area can also be a source of frustration, as it may not accurately reflect the status of a process at times.

Hello Douglas,

I'm not complaining about this issue, just explaining what is going on and what we are doing to avoid issues when upgrading, for exemple to avoid the installer telling you you need to reboot.

Since a few years when I'm doing the upgrade or even a simple restart of the service, I always do it like this:

1) Stop the service from the service manager

2) Monitor the mailservice.exe process in process explorer or task scheduler and wait until the process is really gone

2) Do the upgrade (or start the service again) depending I'm doing a restart or upgrade.

In previous versions (a way back), nothing prevented mailservice.exe to run multiple times, so for example doing a restart would result in double mailservice.exe running, bringing issues like ports binding errors or worse, both process writing to the same files and creating corruption.

This is not happening anymore, hopefully, and is a great step ahead.

Still, an addition to the installer could be that after it requests a service stop and after it receives the feedback from the service manager, it could then monitor the running processes and check for mailservice.exe presence, and wait for it to really disappear before going on with the upgrade.

Well that would be how I would do it, if I was in charge of the installer script.

But with current status, on "big" rigs, and as long as you make sure the service has properly stopped before doing any upgrade or start of the service, there a no problems.

Kind regards

Tim

< The Windows Services area can also be a source of frustration, as it may not accurately reflect the status of a process at times.>

I agree <g>

Sébastien

< Still, an addition to the installer could be that after it requests a service stop and after it receives the feedback from the service manager, it could then monitor the running processes and check for mailservice.exe presence, and wait for it to really disappear before going on with the upgrade.>

Yeap, that's it what i'm doing with my own software installer. After i stop the service using the the service manager api i have a routine which it checks the executable if it's in use and wait with a timeout (10 seconds) before inno setup proceeds. Smartermail installation should do the same. 

Every time i stopped the service manually (either service manager either net stop mailservice.exe) the installer didn't popup any reboot dialog.

Or it's a MSI bug or need some extra configuration or something. (Never used MSI myself)

The whole story about it is you don't know if it needs actually reboot or not and since it's popping admins are rebooting the server (aka downtime) without that be needed.

Thank you