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

This is purely speculation but I'm wondering if Microsoft broke IMAP again in a similar way on this occasion, issued a quick code patch to fix it, but didn't restart the relevant services properly - leaving some accounts to hang in a broken state with the defective code. Affected accounts could simply be the ones that happened to try and connect with IMAP within the time frame it took Microsoft to realise they had a problem.

I suspect the real cause is different from the hypothesized one.

The reason is that issues with my affected account arose not at the beginning of November,

but only later that month when our Exchange tenant was migrated from a local server to the Microsoft O365 cloud. During this procedure classic password authentication was also substituted for OAuth2.

The issues started immediately after.

I must have missed that point in your particular case. It certainly puts a different slant on it. What does your system administrator think of the issue? Did it affect all of the pre-existing accounts that were migrated? Have they had any problems with any new mail accounts created since the migration took place?

I'm still not convinced of any link to the Oauth2 change though. My affected and unaffected accounts were running Oauth2 long before the change. The Microsoft test script requires you to log in as the user you're testing at the start of the script and it is clearly using Oauth2 to do that. The only difference between an affected and an unaffected account is the server response to the LSUB commands.

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 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.

An individual in our tenant reported the symptoms of this problem to me, but it took some time before I could verify the problem, since none of my testing accounts manifest it. Then I found this thread, which has been helpful in establishing that our tenant is affected. (I reluctantly connected my own account to Thunderbird with IMAP.)

I have reported the problem to Microsoft through official channels, and they have confirmed that it is a bug. They stated today that there are changes coming to logging on their side that should help them identify the cause, but also that these improvements will not come until January. Here's to hoping!

An individual in our tenant reported the symptoms of this problem to me, but it took some time before I could verify the problem, since none of my testing accounts manifest it. Then I found this thread, which has been helpful in establishing that our tenant is affected. (I reluctantly connected my own account to Thunderbird with IMAP.)

I have reported the problem to Microsoft through official channels, and they have confirmed that it is a bug. They stated today that there are changes coming to logging on their side that should help them identify the cause, but also that these improvements will not come until January. Here's to hoping!

Thanks for sharing that feedback David. I gave them another prod on my ticket today so we'll see if they give me the same response as and when they reply. I see it still hasn't found it's way onto Service Health and it will make me a lot happier if it does - not least because SAs will actually be able to see it rather than go hunting as you have had to.

I was trying to understand where my user mailboxes live in the Exchange Online architecture yesterday, and did a get-mailbox in Powershell. The results were actually quite surprising. i.e. if EUPR02DGnnn-dbnnn (below) is a reference to a virtual server and the database number on that server, my users are literally spread all over the place with hardly any repetition.

Now I was hoping that I might FINALLY see the common denominator I have been searching for these last few weeks, such as my affected accounts all being on the same node, but was rather disappointed to see there isn't. The four affected accounts I have access to are on these four nodes:

EURPR02DG275

EURPR02DG111

EURPR02DG226

EURPR02DG407

All I can say with any certainly is my working accounts I have access to are NOT on any of these four- but I thought I'd post this up in case any other SAs can see any of these cropping up in their affected users.

If we're looking at a situation where out of a potentially huge number of database nodes, an indeterminate number have some buggy code on them, it would explain a few things:

1. Why Microsoft are having to now go digging to find them as they have indicated to you.
2. Why this seems to have remained below the radar - but that could also be because Microsoft haven't put it out there :)
3. Why tenants all over the place are affected, but it seems relatively few user reports from each.
4. Why G0RLa8 got hit with this later than most of the rest of us. i.e. If a bulk creation of 8 accounts in 2016 on my tenant put them all on different nodes (as it in fact did - I have just checked) then it stands to reason that G0RLa8's migration from on-premise may well have sprinkled all their organisation's accounts all over the place too, including onto some affected nodes.
5. Why the fault clings tenaciously to affected accounts (I even did a soft-delete on one of my affected ones yesterday, restored it, and the problem still came back!), and no unaffected accounts have even been seen to fail.
6. Why a load of old test accounts of mine are working fine when I stuck them on Thunderbird, as they will simply not be on affected nodes.

But a cautionary note is that SAs/service desks adding brand NEW users might still be hit if O365 happens to shove them in the wrong place.