Hey y'all. o/

Relevant platform info:

  • **osTicket Version: v1.15.2 (cb6766e)
  • Web Server Software: Apache/2.4.38 (Debian)
  • MySQL Version: 10.3.29
  • PHP Version: 7.3.29-1deb10u1**

Got a pretty interesting issue that I can't find too much on. Getting right to it, basically, I'm attempting to change the email addresses from one thing to another on Microsoft Outlook 365. It's a basic setup. Mailbox is a licensed user with credentials and fetches with IMAP + SSL. Mind that this is a primary email and username change, not merely trying to use an alias.

I first change the username of the Outlook 365 user, ensure it propagates, and then change the email and credentials in OST and OST confirms the changes when saved. I shoot a test from the diagnostics area... and nothing. I try to see if it'll fetch emails, and it refuses to. If I switch it back to the old username and email, it works again. So I'm at a total loss. Everything's functional on Outlook's side (from what I can see); credentials work, emails can come and go without issue.

Any of you run into something like this before?

And the fetching configuration, unchanged with the credential change. Standard stuff.

How and where are you changing the m365 information?
How long are you waiting before you try to use it?

So the M365 account information is being changed in the 365 Admin Center; it's a fully-online account that doesn't sync with a local AD environment.

And I give I've given it up to two hours to sync the change just in case, but no dice.

Did you grant IMAP privs to the account?

Admin center -> Show All -> Exchange Admin center -> Recipients
Search for the User.
Double click them.
Click on the mailbox features menu
Scroll down until you see IMAP: enabled

Yes, I can confirm that the user does have IMAP privileges enabled.

Other than the account ... your settings are identical to mine.
I trust that once you changed the settings in M365, and waited a little bit that you changed the password in osTicket?

Correct. Just for kicks and giggles, when I input the wrong credentials (password in this case) I am unable to save the new settings until the correct creds are input.

And the emails Disagnostic function seems to be a compulsive liar too, since it states it sends from the changed email address to a valid email successfully though it never arrives - with Spam and "other" folders checked as well.

I'm not sure but we change the password on our mail account in m365 on a recurring basis (because security policy dictates it even though im the only one that knows the password), and I haven't had this problem. I wonder if this is a password complexity thing... Try a simpler password at both ends?

This might help: https://www.faqforge.com/o365/office-365-password-policy/
Allowed Characters
Following are the allowed characters in Office 365 user password:

a - z
A - Z
0 - 9
@ # $ % ^ & * – _ + = [ ] { } | \ : ‘ , . ? / ` ~ “ < > ( ) ;
Disallowed Characters
Following are disallowed characters in Office 365 user password:

Unicode characters like !, ¥, Ą, Ə, ɖ, o̕, Љ, Ԁ, Ա, ؟, ܀, ހ, ߄ etc
spaces
Office 365 User Password
Office 365 password must contain minimum 8 characters and maximum 16 characters and cannot contain a user name. It requires 3 out of 4 the following:

Lowercase characters
Uppercase characters
Numbers (0 - 9)
Symbols like @ # $ % ^ & * – _ + = [ ] { } | \ : ‘ , . ? / ` ~ “ < > ( ) ;

I tried a password as simple as possible, a mix of capital/lowercase letters and some numbers, and gave it time to propagate - Because Microsoft®.

An exciting new development. New emails can be fetched on the regular schedule they were on originally, but the ability to send emails (in ticket replies, etc.) still seems to be broken.

Do you use Separate Authentication?

Nope. Your settings mirror ours.

e: My apologies, now things get interesting. That option was actually disabled upon arrival. Attempting to enable it gives me the following error message:
Failed to connect to smtp.office365.com:587 [SMTP: Failed to connect socket: php_network_getaddresses: getaddrinfo failed: Name or service not known (code: -1, response: )]

However, this shouldn't prevent emails from going though at all, no?

Hotdamn!

That was it... however the solution is somewhat... odd.

So as we both have it set, smtp.office365.com is the required server. However, if I set it to smtp-mail.outlook.com, it suddenly works, even though it's listed as the server for MSN as a provider. Email responses now work flawlessly.

Very strange, but you know what, I'm not going to question it.

Thanks so very much for your diligent support, ntozier. I truly appreciate it.

So I bet that smtp.office365.com resolves to a server cluster, and that smtp-mail.outlook.com resolved to a different server cluster. Both probably have some regionality to them... so that when you connect to one it gives you some servers that are regionally closer to you.

So it would appear. However it's just strange for it to have worked this entire time. But I guess stranger things have happened at sea.

Thanks again!

Screenshot for posterity in case MS nukes the article (may be changed).

Write a Reply...