Phantom Office 365 Mailboxes

Brass Contributor

Hey everybody - quick overview of what's going on...

 

Hybrid On-Prem with Office 365.  We have mail users (ie: contacts) in the system that do not have mailboxes on-prem or in Office 365.  They have a MSOLUser object in Office 365 but licenses for mailboxes are not assigned.

 

Today I discovered (by accident) that if the user goes to outlook.office.com and logs in with their credentials that OWA will open up and let them into their mailbox. They don't have a mailbox but they have a mailbox.  The users don't have a license, never had a license.  If I then go into powershell and do a get-mailbox they don't exist - I've tried every which way I can to validate they exist.  

 

I can send from the mailboxes without an issue in OWA as well.  The replies are honoring the mail user target address that's associated so no replies are going there.  I'm not able to get Outlook to map to these mailboxes.

 

Is this related to a service feature (teams, groups, etc) that has a requirement for some sort of anchor mailbox?  I'm totally lost on how these should exist.  I really don't want users finding out these are out there and then trying to use them. 

21 Replies
What does Get-Recipient show for one of these? I'm not in front of a PC to test this atm, but it definitely sounds interesting. Open a support ticket if you can reproduce it.

Just checked and they are recipienttype=MailUser if I do get-recipient.  I'm going to test with another tenant and see if I can do the same - if so - support ticket time.  (I would love to know if anybody else is seeing this)

 

This is the same behaviour I have seen in a tenant where I have a SPO license, but not a EXO one and I was able to create a Team and access to a kind of mailbox...able to send from the mailbox but not able to reply

Yep - validated in a 2nd tenant - mailuser has mailbox in OWA - no license, no get-mailbox results.

Hey Juan - that would lead me to believe that there's a feature in the service that "needs" a mailbox but isn't really creating one but making a phantom anchor of sorts.   I'll see if support has some clear answers

By any chance, do these accounts use the Outlook for iOS or Outlook for Android clients? If so (as explained in https://www.petri.com/outlook-ios-android-dumping-aws-q3), this might be evidence of the mailbox cache maintained within Office 365 to allow mailbox data to be processed and then synchronized to those clients. The users should not see the phantom mailboxes, so that is a bug... But can anyone confirm the theory?

Thanks for calling that out Tony, I hadn't read that in the past and it's a good primer for what I'm working on to get Outlook mobile as the "standard".

 

In this case though, the users are not using Outlook on either iOS or Android and I know they've factually never tried to get in that way.

 

I just got off the phone with support and they seem to be curious about this one too.  Maybe the PG is having some fun with us again. ;)  Either way it's feeling more and more like a bug.

Well, we've engaged the other grumpies to test on this and so far no one has been able to reproduce it. I should also be able to give it a go tomorrow. @Ingo Gegenwarth suggested that you should check the headers from OWA, as they might reveal some more info. For example, there should be a heder named "X-UPNAnchorMailbox" listing the actual UPN of the user object.

 

Do tell us what you dig up with support, it's kinda hard to troubleshoot issues like these on a public forum where you cannot share the needed details.

I dug through the headers and I'm not seeing X-UPNAnchor or anything of that sort...

 

I forgot to mention earlier that these are on-prem AD mailusers that are synched to Office 365 via AADConnect.  (might be relevant)

 

What's more interesting here:

 

Mail user target address: JTest@tenant2.com

OWA shows logged in user: JTest@tenant1.com

 

Email that arrives comes from MailUser Target Address of jtest@tenant2.com.  This means that it's actually allowing me to send out of tenant1 as a domain that isn't even registered.  Bizarre (yeah, my head is spinning)

 

I'll report back our the end resolution or more details as they come.

Just thinking, does any information exist in the phantom mailboxes?

It doesn't appear that way - but I can generate new content within it.  Contacts, sent items, calendar invites, etc.  Presents an interesting compliance issue since technically I can't discover the content if it starts there.

Word is that this may be something that engineering knows about...interesting

I had a conversation with the Outlook team and the phantoms are not their responsibility. Stranger forces are at work!

Noticed something similar in a dev tenant yesterday.
In case it could help diagnostics:
Created new user in O365 Admin (no AAD sync in place, standalone tenant), no licenses assigned.
Bought SP Online Plan 1.
Assigned SP P1 to the new user (nothing else).
In SharePoint homepage - created new team site.
In the new team site - clicked on Group conversations.
Outlook.office.com opens.

Can send mail from here but reply-to address is (redacted):<IMCEAEX-_O=EXCHANGELABS_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=6E6F20D1C7A0465088786E6633A8F67F-username+2EBILL@eurprd05.prod.outlook.com>
Can not receive mail.

 

That's unsurprising. You need an Exchange Online license to be able to access the conversations in an Office 365 Group mailbox. The SP1 license is sufficient to get to the group files, but not the conversation. However, OWA should barf in a nicer manner.

That's my point, for users with only SP1 this shouldn't create them a "pretend" email account. Posted the description as an optional aid in debugging the original issue as the result is much the same:-)

I think what happens is that the creation of the group kicks off the provisioning process to make sure that all group resources are available. Some group members might have EXO licenses, some might not. In your case, you accessed the group mailbox with a user that is not licensed to use EXO, so the attempt to send mail was rejected by the transport system because of your unlicensed status. The group mailbox and its assigned email address are perfectly valid and are required to serve people with EXO licenses...

That is indeed the case. There is no problem for EXO users in this scenario, but it is not an acceptable outcome for SP1 users to have a default link on a team site that automatically logs them into what appears to them to be a normal Outlook mail account (from which you can send mail but not receive). Ideally the link to the group conversation should be removed for unlicensed users in my opinion, or at least display some meaningful error message.

100% agree that the error handling and messages are not what they should be in this case.