Hello Donna, do you see anything logged in the Calendars log under Manage>Troubleshooting>View Logs? You can look for a conversion log under your install directory as well, this might point at a conversion failure for the calendar data XML files in which case we might need to reconvert them. Can we get you to submit a support ticket on this?

Hello Kyle,

Thank you for the response.  When I viewed the logs for calendar there were no results.  I was not able to find any conversion logs in the smartertools directory or the smartermail directory.  I will open a ticket regarding this.

I've just upgraded from smartermail 12.5 to smartermail build 7188 and I have exactly the same problem with every calendar of every user.
No conversion errors and nothing in the calendar log.

Is there any known solution, or is it better to open a ticket?

Stefano Liboni

Hello everyone. I've recently received word that upgrading from 12-17 is not recommended due to calendar issues like these ones. The recommended upgrade path is to step through version 15 before moving to 17 (build 7188 currently.) Do you have backup copies of these domains that can be reupgraded? No mail data should be lost so long as the damaged upgrade copies of the domains are also kept. Then we can later merge the GRP (mail data) files together in the corrected domain copy. Let me know what you're able to find out on this!

Yes, I have a backup. Obviously calendars in the backup are up to date becouse the did not have changes, but mailboxes content do have changed.

Is it possible to upgrade calendars only? 

We have not many calendars, so maybe we can reset them if it's not possible to upgrade them. Some users have their calendars syncronized with outlook, so may be the outlook data can be syncronized back to smartermail?

I also still have a backup of a windows 2008 virtual machine with an installed smartermail 12.5.

Stefano

You could likely upgrade the backup server to SM 15, then bring the calendardata.xml files to the new server. At that point we'd need to run a reconvert of the account (rename settings.json to settings.json.old) and allow it to reprocess the XML files into JSON files. Its possible these users would lose any folders, contacts, tasks, etc that were added since the initial conversion. Mail data should not be lost as this is kept in GRP files and we don't convert these during the upgrade. I recommend submitting a support ticket on this one and we can likely help you find a working solution.

Ok Kyle. Thank you. I'm going to submit a ticket.

Stefano

I have got the same problem with my SM 17, just with one user.

What can I do?

Hello Stefano, if you'd like some help with this please submit a support ticket so we can check it out. However, you can likely take a backup of your domain/user account pre-upgrade, upgrade it to 15 in a dev environment, then upgrade to the latest release. Once you've done that you should have a full set of upgraded JSON files that you can load in to the existing account on the server where they are currently not loading calendars. You'll want to roll in the JSON files while the SM service is stopped, and please be sure to take a full backup before carrying this out. 

I've also run into this problem going from 13.5 to 17.  I'm not impressed that, despite this thread existing for months the 'major upgrade' kb article makes no mention of this issue;  the 'domain conversion' page makes no mention either; Or that there isn't a fix out.

I've tried the above "take a backup of your domain/user account pre-upgrade, upgrade it to 15 in a dev environment, then upgrade to the latest release" above and that doesn't work.

A way to reset calendars to blank would be useful, at least that way our customers could move on.

Russell

Update... upgrading from 13.5 to v15 then to v16 then to v17 gives us some working calendars on the dev system (though not all oddly)!  It is not obvious which json files have changed though as there isn't a calendar specific file... will have to look through the live files now and check for differences - unless SmarterTools know the answer and any caveats to copying the jsons over (stop SM service on both servers first obviously!)...

Russell