Hello Matthias,

Which version of SmarterMail are you running. If it is a recent build you might want to check in this particular domain folder if settings.json exists and if the content looks like a valid json file.

It could be corrupted if the server was shutdown abruptly or if the service crashed while it was writing to the file.

If the file doesn't seem right, you should be able to recover the settings.json file from the Archive subfolder of the domain, which contains some backups of the domain settings file.

I hope this will help.

Kind regards

Hello Sebastien

Thank you for your help. I'm using the latest version of Smartermail.

Replacing the setting.json file from Archive does not fix the problem. I checked the other json-files and the accounts.json file was corrupted. I restored the file from the Archive and now the problem are fixed.

Kind regards

Matthias Maass

Oh okay, cool you were able to recover the domain. Thanks you for letting me know.

Good morning everyone! Out of curiosity, how do you proceed with upgrades? Do you stop the SmarterMail IIS site, application pool, or system service before uninstalling? Do you uninstall or simply install the new version? One thing I like to do on busier environments is to stop all of these in series so the connected clients have time to terminate connectivity: 

1. Stop the SmarterMail IIS site and then it's application pool.

2. Stop the SmarterMail system service and wait ~30 seconds for the service to drop out of memory. 

3. Uninstall, then install the new version.

4. While the installer is copying new files; start the SmarterMail application pool and IIS site. 

We stop IIS, then manually go in and shutdown the application pools. We have two - one runs our iOS/macOS .mobileconfig generator and the other runs SmarterMail.  Both are set to be "always on" instead of "demand-start" - so shutting down IIS doesn't stop the Application Pools from staying in memory.

Then we shutdown the SmarterMail MailService.

We wait until everything is cleared from "active tasks" plus about 30 seconds - then we run the installer.

The Installer usually starts SmarterMail service on it's own.  After installer clears from memory, we restart IIS and turn the application pools back on.

The whole process takes less than 3 minutes usually. We currently service about 400 mailboxes across 90 domains on that server (for reference).

We've not had an upgrade issue - only the random bug that appears from whatever SM version we are on that almost always is triaged in the next update.  

The build is 8664, not 8644...

I'm having the same problem on a domain.

I also updated from 8657 (which I had installed at the beginning of this week) to 8664 but the problem was not resolved.

I also restored the accounts.json file before upgrading to 8657. detach and attach the domain but nothing.

The strange thing is that users work fine. That's why I didn't notice. They receive and send emails without problems.

Another very annoying thing is that I can't find any reference to the problem in the logs.

So to understand if any other domain has the problem I should open them individually one by one?

I open a ticket, but since at least the accounts work at least I save myself the urgency

Resolved.

The problem was the primary domain administrator which for some reason was no longer working

Even completely restoring his folder didn't work. fortunately it is a fictitious user. I edited the accounts.json file and changed the primary domain administrator

Once the domain has been reloaded, everything works. In fact, the previous user didn't even appear in the account list. I deleted the folder in user

When I click on a domain I get the fault. Cant even get to the affected domain admin page.

you have to use rdp. In the domain folder try to restore a previous copy of accounts.json and then from the interface do reload domain.

If it doesn't work you have to manually edit account.json (make a backup copy first) and change the primary domain account to another user of the domain.

Save. Reload and it should go

Just upgraded to 8664 and the problems went away.

I am happy to hear your domain is back up and running @Brian. Overall, the great news here is that these scenarios can be identified and added to our detection routines. Ultimately these behaviors indicate JSON issues that have gone unnoticed until our recent changes meant to catch and prevent these types of issues from introducing downtime. The unfortunate thing is that JSON file issues can happen in a lot of different places (and ways) so accounting for them all can be tricky. If you see issues like these again - please submit a ticket with us so we can get fixes implemented to catch and correct these in the future and get you going in the right direction right away. Thanks guys!

I have had a similar problem several times and it's not a corrupt domain, it's the connection. If the customer is able to hot spot through their phone, the login works. This time it was Comcast. Another customer just moved to Los Angeles and couldn't get on with his usual computer. Had to hot spot.

Kyle, for all the years and all the versions of SM I've run, I've only once stopped smartermail service before installing, and I have never once uninstalled an old version before installing a new one. As far as I know, I've never had an issue related to upgrading on the fly. 

Side note: the installer always warns me twice that a reboot will be required, and yet the installer doesn't prompt a reboot. I almost always manually reboot after the install, but the few times I haven't I've also seen no ill effects.

Hi Patrick! The uninstall/install process I follow hasn't been strictly required for some time now, but I stick to this process to get everything time to unload cleanly. That said, I've also upgraded without stopping and uninstalling and this is fine in probably 99.9% of environments I've looked at over the years. 

The only environments I'd say would benefit from following my process are ones where you've found the MailService.exe instance takes a little longer to stop/start during the upgrade. Most servers shutdown really quickly, but there are some larger environments out there with lots of MAPI traffic that take longer than I'd like when installing on top of an existing install. 

The reboot notice you're seeing during installations is something I've seen previously as well, but have never been able to narrow down what series of events leads to it. I uninstall/install/upgrade servers all day as part of my QC work and sometimes I see it, sometimes I don't, and often on the same machines. I suspect there is something in memory that Windows is alerting to, but by the time the installation is finished it's no longer a concern and so an actual reboot is unnecessary.