Office 365 Mail fetching issue

ludespeedny

I cannot seem to get the Mail fetching working reliably. It seems to keep failing every 30-90 days. Today it failed and I cannot get it working again. Can anyone assist? I am on v1.18.1 and php 8.2.4. I have reconfigured the oauth settings and it grabs a token ok.

KevinTheJedi

ludespeedny

Sounds like an old issue that was resolved with the latest build of the OAuth2 plugin. You need to download the latest OAuth2 Plugin for 1.18.x from our website, upload it to your server, and fully replace the old /path/to/osTicket/include/plugins/auth-oauth2.phar file with the new one. Once you do that restart PHP-FPM (if you're running it) to clear any file cache. Once complete you should delete the existing Token, get a new Token, and it should no longer expire in 30-90 days unless you make account changes (changing password, etc.) that invalidate the current tokens (this is a MS limitation unfortunately).

Cheers.

ludespeedny

KevinTheJedi
I actually grabbed all the plugins and updated them this AM as well. Version seems to be the same, but they are all updated.

KevinTheJedi

ludespeedny

Then either your server is caching the old PHARs or you have something misconfigured causing it to expire the tokens every 30/90 days. I will say this sounds exactly like the old issue where the Refresh Token was not being updated so every 30/90 days the Refresh Token would expire and not be able to update the Access Token which causes auth to fail unless you get a new token.

Cheers.

ludespeedny

What is the best way to completely wipe all oauth settings and reconfigure that from scratch? (without wiping the tickets etc...)
I did regenerate the azure security side this am as well.

KevinTheJedi

ludespeedny

The best way is to go to the Email in question, click the Config button for Authentication, go to the Token tab, and click Delete Token. Now you can simply fill in all the new details (Client ID, etc.), click Submit, and re-auth to get a new set of tokens. From that point, if you have the latest codebase and latest build of the OAuth2 plugin you should no longer have expired tokens after 30/90 days. Just make sure when you generate the Client Secret that you set it to expire at the maximum length (2 years) so you don't have to generate and update a new secret so often.

Cheers.

ludespeedny

Ok, I'll give that a shot.

ludespeedny

This page "https://osticket.com/download/" and plugins tab is the best place to get upgraded plugins, correct?

KevinTheJedi

ludespeedny

Correct, this is our official website where we provide the officially packaged versions of the core codebase and all core plugins.

Cheers.

ludespeedny

Same issue. I tried deleting the configs from the oauth plugin and deleted the email as weel and set up a new from scratch. Same issue, although I could not get any outgoing email to work. Reverting to a backup I took this am. This is stumping me. Still get the token though, so looks like it is communicating ok. Also, running on a XAMPP install if it matters.

KevinTheJedi

ludespeedny

Maybe something wrong with the cron job or something? When you get a new token for the email and enable IMAP/SMTP and click Save Changes does it show a green success banner? If so that means it's able to authenticate successfully to those hosts/ports. So it either sounds like cron is not running successfully, or maybe there is an email stuck in the inbox and the system cannot continue fetching (check your osTicket system logs for this), or something else.

Cheers.

ludespeedny

Yeah, I get the green banner and also check and it does get a new token. I have nothing in my osticket system logs, so not sure what to check next.
Where would the cron jobs be to check. On a windows system running XAMPP

KevinTheJedi

ludespeedny

Not sure, on actual windows servers it's typically Scheduled Tasks (using Task Scheduler app) but not sure about XAMPP. You can check their docs on how to create a scheduled task/cron job for an application running on the stack.

Cheers.

ludespeedny

I think I got it. In scheduled tasks, the task is set to run as domain admin and someone changed the password recently. Putting the new password in worked!
Now, to prevent this from happening again, can I change the scheduled task to a different user, like system or something, or should I leave it as a domain admin?

KevinTheJedi

ludespeedny

You can do as you please; it's your setup. Just make sure that user has appropriate permissions to access/execute those files and programs.

Cheers.

ludespeedny

Thanks for the help!