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!