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

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.

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.

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!

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.

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.