Unable to subscribe to Office 365 IMAP folders from MUA since 2022-11-01

First I want to thank everyone who has collaborated on pinning down this issue. This bug is stalling our organization's migration from G Suite to Office 365, since forcing every user onto the Outlook desktop app is not an option for us.

I have opened a support ticket with Microsoft pointing to this thread, requesting to be notified when the bug has been fixed.

1. Am I correct that there is currently no known work-around to this bug?
2. Is this bug acknowledged by MS and listed on some public bug tracker or similar where progress may be monitored?

Thanks for your efforts and I'm happy I was able to finally find this thread here!

I do have a small (but loyal) user base with Thunderbird, but I wasn't able to allocate much time to debug the efforts. Needless to say that I basically got somewhat "brushed off" by Microsoft first level support saying that Thunderbird wasn't a "supported client" and from that point on I had to drop the ball a bit (during a time I already had more than enough other important things to work on). So while I was able provide our users the workaround (showing all, not just subscribed folders) that all I could help them with.

I'll re-open a request and point to this forum thread. Yet I fear that Microsoft is simply not getting enough reports (I myself have ~ 200 teacher accounts, yet only 2-3 have reported such issues but when they are affected, the issue is perfectly reproducible (even with fresh Thunderbird installs). While I have > 2000 student accounts in the tenant I work with, not a single student has reported these issues either. It does seem to only affect a handfull of Thunderbird-using accounts (for now...).

Thanks for sharing this. It seems we are at least starting to see consistent messages from Microsoft.

As we might be a little while before this gets fixed, I mentioned earlier in this thread the use of Power Automate as a way of users setting up a notifier message to a personal email address of their choice when new email arrives in their O365 mailbox.

If you have any users forced to now use Outlook Online/Outlook on the Web because they have no workaround due to the type of MUA they have, some might find this useful.

If any of you fellow SAs want to have a go, this is a guide on how a user can set such a flow up if you give them access to the Power Automate app.

1. Go into the POWER AUTOMATE application
2. Click on MY FLOWS and then NEW FLOW, and AUTOMATED CLOUD FLOW
3. Give your flow a name in the box such as Notifier
4. Select the flow in the list called "When a new email arrives (V3) Office 365 Outlook"
5. Click the CREATE button
6. Leave the folder as Inbox and just click NEW STEP
7. Select the category of "Office 365 Outlook", then "Send an email (V2) Office 365 Outlook" from the list
8. An email design form will come up - where you are now designing the message that O365 will be sending to your personal email address to tell you when a new O365 message has arrived.
9. Type your personal email address in the TO field
10. Give the message an appropriate subject so you will recognise what the email is when it arrives such as "You have a new O365 email message" or "You have a new school message" or "You have a new work message" (see note)
11. Move your cursor into the body. Click on ADD DYNAMIC CONTENT and add in SUBJECT and FROM objects to the body of the email form. Search for these if you can’t see them in the list. (see note)
12. You can add text in the body too, to tidy up the appearance of the email you receive if you like, such as typing "Subject:" and "From:" in front of the dynamic objects you have inserted, and hints on how to manage your flow if you forget.
13. If done correctly, it should look something like the example below.
14. Click "save" and test it.

The flow will run in the background on your O365 mailbox, and send the newly defined notifier message to your personal email address whenever a new email arrives in O365.

Note - I have noticed if your O365 browser window is quite narrow, Power Automate actually offers up hints on what to add at these two stages, which is actually a bit annoying when you're trying to create a guide with a consistent set of screen grabs as I did for my users.

I am not alone; several users of pre-existing accounts on our tenant have been affected around the migration date (local to cloud) and have reported this.

The real number of affected accounts is unknown though, as many use Outlook over MAPI, or the O365 web-app to check their emails.

Apparently there are no issues with newly created user accounts, but this was not extensively tested.

There is indeed no evidence that the issue pertains to OAuth2.

However, my email client tried to connect automatically via the old authentication procedure on the day after the migration, before I changed the settings manually to authenticate over OAuth2. Perhaps this has messed something up in the configuration files on the server? - Just thought I should mention that.

For documentation: Set up of the affected email account on fresh installations of email clients on two different machines did not fix the issue for me. This indicates that the configuration/communication issue exists on the server (or tenant) and not on the client side.

I see. I think we all have that same problem - not enough data on the affected accounts to draw any firm conclusions.

I did another test today. I realised one of my affected accounts was part of a bulk create of around 8 accounts back in 2016 - a couple of which were never used. So I tested those and they both work fine. This tends to confirm earlier thinking that this is nothing to do with the way accounts are configured/licensed within O365.

Nothing wrong with your rationale over this being server-side though. I have seen nothing that would put the slightest doubt in my mind.