Tag: Migration

osTicket broken after an update from 1.10.x? This is probably the fix for you.

Posted on by Andy King

I recently tried to update my osTicket installation only to find it broken after upgrade with messed up menus and missing ticket queues.

If you’re still using a version of osTicket from 2018 or earlier, you are probably still on 1.10.x or lower. It’s definitely time to upgrade but before you do, there are some important steps you’ll want to follow to ensure a successful upgrade. Keep in mind if you are on osTicket 1.6.x or older, you can’t use the upgrade system at all according to the osTicket documentation for upgrading. You’ll have to migrate the date manually, which is not covered in this article.

So if you’re like me and your osTicket installation is broken after upgrading, take a look at these symptom lists below. If you haven’t tried upgrading yet, skip down to the last resolution below.

Symptom

  • All dropdown menus are broken/have css issues
  • All ticket queues are missing

Resolution

Make sure you are using PHP 7.1+. PHP 5.4 support was never officially dropped from the osTicket system requirements but it clearly causes problems past v1.10.x. Obviously at the time of writing PHP 5.x is EOL as of December 2018 already and should be phased out, but just last year osTicket still required PHP 5.x. So that’s a shame but let’s move past it.

Symptom

  • I managed to get osTicket upgraded to 1.14+ but I still see DB Error #1064 show up occasionally in the logs

Resolution

One or more of your users may be using a saved ticket search left over from an old version of osTicket which is no longer compatible. Deleting and recreating the saved search will resolve the error. See this reply on GitHub.

Symptom

  • I upgraded osTicket and now email fetching isn’t working (ticket responses/requests are not getting processed even when the cron is run manually)

Resolution

After an upgrade, sometimes osTicket needs you to re-enter the password for the account (yes, even if SMTP is still working). Re-enter the password on the email settings page (Admin Panel -> Emails -> (your desk email) -> Password)

Symptom

  • I’m getting database error logs/emails
  • I can’t make any changes to settings or tickets
  • I can’t create new tickets

Resolution

First off, just like the first symptom/resolution in this article, you should make sure you’re on PHP 7.1+ If you’re like me, you already checked that and everything is still broken. So in that case, I hope you have a database backup of your original installation pre-upgrade because it’s time to go back.

Step 1.

Rollback your osTicket database to how it was before everything broke.

Step 2.

Delete osTicket from your server and download the release you were on before everything broke: https://github.com/osTicket/osTicket/releases

Step 3.

After you have osTicket working again, we’re going to approach upgrading in a more incremental manner. osTicket keeps track of all the schema updates between your version and the upgrade, but as with all open source projects sometimes someone makes a minor change that causes retroactive problems for people like us who are behind the times. I’ll assume that you started on osTicket 1.10.x (specifically I was on 1.10.4) but this should apply to other relevant versions as well ( see first paragraph of this article, terms apply).

Download the next major version release, which in my case is 1.11. Upload the files to your server and initiate the upgrade process. Let the upgrade finish, and PHP 5.x users watch as your ticket queue disappears. Switch to PHP 7.1+ to fix this. During this entire process you will probably continue to see DB Error #1064 get logged but rest assured it will be gone by the time you’re done upgrading.

Step 4.

Continuing with our incremental upgrade approach, download the next major version release, which for me will be 1.12. Let it upgrade, and osTicket should still be working fine. Woohoo!

Step 5.

Curiously there is no 1.13 release on GitHub, so we will go with the next best thing: 1.12.5. Same rules apply, upgrade it and watch as nothing breaks. Since there were no schema upgrades, the upgrade will be instantaneous with no prompt to upgrade in osTicket. Version should report as 1.12.5 in Admin Panel. You could probably skip 1.12 and go straight to 1.12.5 if you want, but I’m not 100% sure.

Step 6.

We’re getting closer to 1.14.x. Are your palms sweating yet? Go ahead and install it. While you wait, pat yourself on the back.

Conclusion

You may be wondering why this worked. Unfortunately I don’t have an answer for you. If I had to guess, running the upgrades one by one with PHP 7.1 switched on after leaving 1.10.x may have been the reason it was successful.

Congratulations, your osTicket installation is no longer broken from an upgrade, and the menus and ticket queues are no longer messed up or missing.

I have no idea if all the aforementioned incremental steps were necessary or if this same process could have been done with fewer upgrade steps. However, I know this particular upgrade path worked for me and I don’t want to waste my time going though every single potential upgrade path to find the shortest one. I want to get on with my life, as I’m sure you do. Go back to closing tickets. Don’t forget to delete the setup folder from osTicket’s installation directory and also check out my other articles.

Incremental Data Migration for Email in G-Suite

Posted on by Andy King

Introduction

Recently I was performing an IMAP migration from a self-hosted mail server to G-Suite and encountered a situation where I needed to perform an incremental update to the migration after it had already completed. The client held off on the migration for 3 additional weeks – once it was time to try the big switch again his email was 3 weeks out of date on Google’s servers. The migration was still active in G-Suite and when I stopped his user’s migration and started it over again I found that it would mark itself “complete” instantaneously, giving me the impression nothing was actually happening. Double-checking the “Migration Settings” screen showed that the migration was indeed supposed to check from a date past when I needed it to up until today. So what’s the problem?

The Problem

When you start a migration in G-Suite, it will remain active indefinitely until you manually stop the migration. The settings you started the migration with will continue to be used on any new or repeated users you try to start a new migration for. Even though the Migration Settings window shows a date of “today” as the latest date to check for new mails, “today” in this case refers to the day you started the migration.

The Solution

In order to perform an incremental migration in G-Suite, you must exit the current migration and start a new one so that you can specify a new date range for it to check against the current data from the previous migration.

To exit the current migration, go to:
Admin console > Data Migration > Email

Then click the triple-dot menu right below your username in the upper right corner to view the options for the current migration. Choose “Exit Migration”.

Now you can start a new migration the same way you did originally. When it asks you to specify a date range for the migration, you can expidite the differential process by using a start date of when you last performed a complete migration for these accounts. In my case choosing “Last month” as a range was sufficient.

Bonus Note: In the same triple-dot menu I noticed a setting for Migration Speed – by default this is a very low value of 100 queries at a time. I suggest maxing this out unless you are migrating from a server which is still in production for a large userbase. I maxed it out to 2000 for a noticeable speed improvement.