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

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.

I'd take that with a pinch of salt, as I'm sure they didn't provide any justification/evidence for why they think it might be a client side problem + as we know, Microsoft's own test script provided to me exhibits the exact same problems as the various affected MUAs too.

I found this old posting from 2016 the other day where Microsoft caused the same problem as we are all seeing now. Unfortunately, I can't access the Microsoft incident report after all this time to see if there is any more useful info on what happened - so I have flagged it up to Microsoft.

https://thunderbirdtweaks.blogspot.com/2016/01/outlookcom-office365-imap-subscribed.html

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. That would explain:

1. Why the problem affected ALL of the O365 accounts on Thunderbird on my own machine, as all will have been accessed at the same time when I started Thunderbird
2. Why I was able to add several test accounts to Thunderbird after the event, that had never been accessed with IMAP before, and these all work perfectly well - and still do.

I suspect this will mysteriously resolve itself at some point.

Wow - I am flabbergasted by the "support's" incompetency.

But hey, let's just archive and forget about these bug reports; problem solved.

Only thing left to do now, is to wait for some forum agent's run-of-the-mill reply to be selected as the accepted answer and this thread to be locked.

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.

Microsoft do publish major incidents, because system administrators see these on the system health view in the Admin Centre - and you can see there are some currently showing below. Just not this issue yet.

There are two things that can constructively be done by system administrators in this case.

1. Get their own ticket logged as I have been saying for some weeks, so Microsoft can see what the service impact looks like.
2. Help users with any workarounds.

We'd probably all agree that Thunderbird users have an adequate workaround. But even using Outlook Online as the very worst case doesn't have to be quite as annoying as it sounds and it is within system administrator's gift to help.

For example, I have users who by choice, only ever access my service via Outlook Online - and what I do to make their lives easier is give them access to an application called Power Automate in O365 and instructions on how to setup a notifier message. What this does is trigger when a new mail message arrives, and sends a separate email message to a personal account of their choice with the subject and sender added to the body of the message so they know what it might be about and whether to bother logging on to take a proper look. I could see this being helpful for students in an educational setting for example.

It's quite common for us system admins to universally block the users from setting up autoforwards to external/personal addresses as it's a potential leak of corporate info. But depending on the particular situation, that policy could be temporarily relaxed as an alternative to the notifier message approach above. O365 can provide alerts and reports to allow that situation to be managed.

To be clear, I'm not trying to defend Microsoft. I am simply pointing out that in the world of relatively cheap cloud computing, there is actually a price to be paid in terms of service and support. But on the flip side, this is the first incident that has consumed any significant amount of my time in five years of operation to date.

I wouldn't disagree with your sentiments - just offering up some thoughts on why this might be taking time to resolve.

We have north of 30,000 educational establishments in the UK (schools, universities etc. ) and many will be on O365 as it simply doesn't make financial and operational sense for them (or any SMEs for that matter) to retain on-premise Exchange, Sharepoint etc. these days. That pattern of migration has been going on many years and this issue won't make the slightest bit of difference to the direction of travel. I have a vague recollection of seeing a figure of in excess of 200,000 companies using O365 in the UK and us being the largest market for the service outside the US. You can probably double that for a Europe wide figure, and European tenants are hit by this issue too.

My point is that this issue has just 85 people flagging the same question as the OP. That figure might be hiding many more and a whole heap of annoyance - but in the context of such a mind-bogglingly large service, it barely registers. Even if it is registering with Microsoft, fixing it might need diligence and care if the fix, or method of fix, has potential to impact a service that vast - most of whom will be blissfully unaware of this.

It's just one of those harsh realities of cloud computing these days.