MS O365 Oauth2 after moving to new server

AlanF

We recently moved our OSTicket to a new server and ever since, emails are not being downloaded from O365. We copied the database and configured everything to be the same, but it looks like the auth file or the tokens didn't get copied over. I've looked around a bit but haven't been able to find where the tokens were stored on the old server. Can anyone point me to the right location?

KevinTheJedi

AlanF

All data is stored in the database. Did you configure a cron job on the new server to automatically poll the mailbox?

https://docs.osticket.com/en/latest/Getting%20Started/POP3-IMAP%20Settings.html

Also, if your URL changed then you will need to edit the Azure App to update the URL(s) as well as update the OAuth2 config within the email to update the Redirect URL. Once complete you can resubmit the popup to re-auth the email and retrieve updated tokens.

Cheers.

AlanF

Thanks for the reply. The cron job is configured (Windows task manager) and when I set the logging to 'debug' I see a log entry for it running: "Cron job executed [CLI]".

The Redirect URL set up in the email config within OSTicket is to a URL that is valid for the new machine as the DNS entry was updated to point that URL to the new server.

Can you tell me which tables store the OAUTH2 information? I want to compare the old and new databases to make sure everything is identical.

EDIT: I found this in the email_account table:

Last_error_message = "Credentials: Required option not passed: "access_token"

KevinTheJedi

AlanF

Yea you simply need to delete the existing OAuth2 token (if you see a Token tab when clicking the OAuth2 Config button within the email) and retrieve a new token. Once you do that you should be good.

Cheers.

AlanF

Got it working now. For anyone else who may find this later, there were a couple of things I missed when migrating to the new server: The old server didn't get shut down right away, so the old instance was refreshing tokens and the token info in the database was out of date by the time the new instance was up and running. I also missed adding the cacert.pem file to the php.ini on the new server. Once I go that straightened out and re-authenticated using the client secret, the mail import started working.