Ram,

Since you have active Maintenance and Support on your SmarterMail license key, your best bet would be to work with one of our technicians to troubleshoot this issue.  I've gone ahead and submitted a ticket for you.

@ram

What version of SM are you running?

the last version build 7242

The reason I asked is that we had issues with certain .json files becoming corrupt (the files simply contained blank spaces) on a previous build.

It was a known issue.

We’ve not seen a repeat with the last couple of builds and we’re currently on the latest release. 

I see my reply was marked as the resolution.

Was it fixed in a recent build? I can't see anything in the release notes about this.

Alex,

I'm actually not sure how your post ended up marked as the resolution.  I've un-marked it for the time being.  My apologies for the confusion.

These issues typically arise due to a couple of scenarios: 

- Power or server failure causes a sudden restart of the machine hosting SmarterMail. This causes our settings.json files to become corrupted because they were open for editing at the time.
- Third party software accessing the settings.json files during edits being performed by the mail service.

Absent these possibilities we will need to troubleshoot the issue further and have opened a ticket with this user to do so. This was something we've seen before, but there doesn't appear to be any discernible pattern to it unfortunately. The environments these issues affect are rare and are otherwise functioning well aside from the users who are impacted. 

Resolving these issues and getting your user back online is simply a matter of stopping the SmarterMail system service, then restoring a backup copy of the user's settings.json file found within the Archived Data folder found within each account, domain, and system level configuration area. 

Alex,

We applied a "maybe" fix for the issue a couple builds ago. Any users with a blank settings.json will unfortunately continue having issues (their settings data is GONE). We distributed custom builds and now public builds with this "maybe" fix and we haven't heard anything bad happening since. However, this was a very intermittent issue that would happen to a very small percentage of systems and we were never able to reproduce, so it's hard to say that we absolutely fixed the problem. It has been a few weeks though since we did this and haven't heard anything new from support, so that "maybe" fix might have actually fixed the problem for good. Customers who had this issue and actually all new version of SM have some more advanced logging to track this issue.

If anyone who thinks they may still be having the issue and you are running a recent build you can check the Errors log for these specific lines.
(This logging won't log for user's with an already blank settings.json. Just new instances of the problem. There might be cases it still logs for users, check my posted update below)
"The UserSettingsFile or the settings property is null--not writing file"
"Password encrypted is null: {EmailAddress}--not writing file"

Obviously user's losing settings is a very serious issue so trust me, we've been trying to hunt it down as much as we can. If you have this problem you can contact our support and they will escalate it as necessary. 

We've been having issues with passwords randomly being null / empty, which is odd. No AV scanner (our entire SM data drive is excluded) and our backup system uses VSS, so that shouldnt interfere with data being written.

We're seeing the same issue here, our Error log indicates a couple of Password encrypted is null: {EmailAddress}--not writing file and after taking a look at the different users settings.json the encrypted password is really empty.

I may need to double check what I mentioned earlier,
I specifically said "This logging won't log for user's with an already blank settings.json. Just new instances of the problem." however, I think there may be cases this log message this will appear for users with an already blank password. You can confirm that this is a recent issue or not by checking your Archived Data folder for the user and seeing if the file is blank or missing information from the previous days as well.

Actually our log is filled with this warning for the same user, so I think you're right, it's not only for new instances of the problem.

I have had this problem so many builds ago.

It's so strange that you've it with the latest build.

I mentioned how to identify and check for the problem. I'm going to include a little quick step-by-step on how to fix it for a user.

To fix this, you may be able to look for a settings.json.bak file containing the data next to settings.json, rename this to settings.json and restart SM. If you cannot find a settings.json for the user that is intact then the last option is to stop SmarterMail, remove the blank settings.json completely, restart SmarterMail, Once SM is back online impersonate the user and set them a password to temporarily use. When the dialog pops up for password change, if it asks for a previous password leave it blank. Once this password is set the user account's settings.json should be in working order. They will need to redo any configuration they have done on their account.

In our case the settings.json was only missing the password. I was able to set it back for these users and no more error in logs.

Not 100% sure, but I think the problem is originally from when we updated to 7136 and then to custom build 7140.

Looks like 7142 is fine.

Also at the same time we had some customers with broken calendar, and I found out the json entry for "My calendar" in the user folders.json was gone. It was still there in the pre-update archived files so I copy pasted the missing json block back and reloaded the domain.

Calendar back working.

What is strange and hopeful is that the corresponding <id>-folder.json was left intact, only the pointing entry in folders.json was wiped and only for calendar folder.

I think I will be writing a little powershell script to "grep" all users folders.json and settings.json to identify any other bogus file.

@Sébastien

I believe that used to be an older bug as well. Once work starts to calm down and our releases are out I may make an open-source tool that can do all sorts of checking to verify every user has the proper connected data and that there are no hanging old files, etc.

Hey Matt, that would be really useful to have such a tool.

 However I'm not sure what you mean by "older bug". I restored the missing data for the calendar from the folders.json dated from 4 day ago.

Looks recent to me.