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

Good news is this morning we found out that the issue got solved without notice.

We received a message a week ago about Microsoft Support saying they would start to see progress in around 15 days, but the solution came much faster.

Haven't received yet a confirmation email by them, but the folders seem to work fine in all the users affected and in all tenants.

Same here - looking pretty positive then. I've asked Microsoft 1st line on my ticket what the issue was.

I copied my message to the 1st line engineer's first line of escalation as I have done previously, and I've just noticed that individual's Display Name came up with (Shanghai Wicresoft) appended to it, so it looks like Microsoft have outsourced/off-shored O365 1st line to a third party - Wicresoft International. That might explain why there feels to be something of a barrier between 1st line and Microsoft Product Group.

O365 is accredited to hold data at UK "OFFICIAL" classification, so for Microsoft to be using a third party in China to do "support", it seems reasonable to assume that Wicresoft have little (if any) access to core Microsoft services and platforms and are just there as filter to protect Microsoft and deal with the easy queries.

As we might be a little while before this gets fixed [...]

By our side, we have confirmation this won't be fixed in the near future/weeks.

Thanks to dozens of replies and messages to Microsoft Support, today we received this overwhelming mail (translated from Spanish).

I have asked internally and we are aware that there are several users affected by this problem,(Cannot subscribe to IMAP folders), however there is no solution available yet.Our engineers are trying to enable additional logging that might help them identify the cause of the problem,but this additional logging won't be enabled until sometime in January of next year.The only solution I can suggest for now is to use an email client that is not using IMAP.I'm afraid the only thing I can tell you is you have to wait until our engineers collect,analyze the logs and provide a solution. This will take time.I am very sorry that I cannot be of more assistance and that I cannot solve your problem right now.If you have any questions let me know, I remain at your disposal.

It was difficult and tedious to break that first layer of support, when they were constantly asking things not related to the problem, but at the end, with this answer we have a bit of relief since they mention they are looking into that specific bug.

So, moving things forward, we will stay attentive to the messages they may give us in the following weeks and hoping the fix won't come much later than Feb.

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.

We are on break so my case is archived. They looked at your ticket and they were not convinced it wasn't a client problem. They were convinced that

112 lsub "" *

was much different than

1780 lsub "" *.

I tried to explain RFC3501 and tagged responses but they couldn't understand.

Sort of sounds like the same lack of understanding that is causing the problem to start with. I guess this is what happens when you outsource software development and support departments to AIs...

If I was the one deciding, I would take my money elsewhere. Unfortunately, I am not the one deciding here, only the one suffering. So far, I can use Alpine as a workaround, but that will probably stop working if they go ahead and disable password-based login... Then I guess I will just have to tell my bosses that I no longer will read or respond to company email...

[...] even though the impact on my service/users is minimal now.

[...]

this will hit a relative minority of tenants who have no control over the end users/devices accessing their service, and won't hit businesses running Outlook on their corporate desktops as they simply aren't using IMAP.

While the issue for users of Thunderbird as a mail client is a minor inconvenience right now due to mentioned work-around,

such a solution does not seem to exist for other mail clients. They are forced to abandon their MUA and use the web form instead.

I am not sure whether this has been mentioned before, but using mail clients with affected accounts does not only affect the ability to see the subscribed folders, but also the ability to copy messages to these. For example, the sending of an email may apparently fail due to the inability of the mail client to copy the sent message to the SEND folder that it is expecting to be connected to. Happened to me with both Evolution and Thunderbird mail clients, the latter without the work-around.

Let me be clear; the issue is not a cosmetic one, but a service breaking fault.

And let's not fool ourselves, the fault is likely an error and not a deliberate design choice. Just consider that Microsoft's own product, the Outlook email client*,* is equally affected when using the IMAP instead of the MAPI protocol for connections. See: https://answers.microsoft.com/en-us/outlook_com/forum/all/microsoft-365-imap-folders-are-broken-no/3fadaa09-86cf-4129-89f3-09a270afa0b2

I agree that the majority of Microsoft O365 customers may very well be corporate clients or smaller businesses. And most of these are likely in more or less full control of their tenant's user accounts, and are equally likely to force them to use Outlook over MAPI as an email client.

However, consider that Microsoft has been quite aggressive with its push into the Education market, especially since the start of the 2019 COVID pandemic and the urgent rise in need of online tools for collaboration. See their web; this is what O365 - among other things - is primarily being advertised for: https://www.microsoft.com/en-us/education/products/microsoft-365 (Note: They put a lot of work into fancy advertising of their software solutions. But not a single mention that their services may not work for non-Windows OS users.)

During these desperate times many educational facilities may have signed contracts with Microsoft over O365 products simply out of pure desperation.

It is clear though, that educational settings (schools, colleges, universities, research institutions) have no control whatsoever over their users in regard to which operating system or software they use. And this is a good thing for education and science! Tools used in learning and teaching should be independent of corporate (read: Microsoft's) control or student's/researcher's financial situation, and be up entirely to the users' choice.

It is perfectly fine if an educational institution signs a contract with Microsoft over a product that offers additional services or applications to be available for its users. However, it becomes a problem, when such institution outsources a core service to Microsoft, such as the hosting of a O365 mail Exchange server, as we have seen multiple times in this thread.

If Microsoft (inadvertently) breaks compatibility of their O365 mail service with non-Microsoft-based mail clients, and thereby forces users to switch to Microsoft-based client solutions, then this sounds like a break of contract at best, and like them throwing their weight around in their self-governed monopoly at worst.

The current situation is unacceptable for their Education market customer base!

And this is regardless of the relatively small numbers of apparently randomly affected users, as it may be a looming symptom of worse disregard that may be yet to come...