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.

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

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.

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.

Phantom Office 365 Mailboxes | Microsoft Community Hub

21 Replies

VegardStromsoy
Brass Contributor
Jan 26, 2017
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.
- TonyRedmond
  MVP
  Jan 26, 2017
  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.
  - VegardStromsoy
    Brass Contributor
    Jan 26, 2017
    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:-)
TonyRedmond
MVP
Jan 25, 2017
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?
- Joshua Widup
  Brass Contributor
  Jan 25, 2017
  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.
  - TonyRedmond
    MVP
    Jan 25, 2017
    Just thinking, does any information exist in the phantom mailboxes?
VasilMichev
MVP
Jan 24, 2017
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.
- Joshua Widup
  Brass Contributor
  Jan 24, 2017
  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)
  - Joshua Widup
    Brass Contributor
    Jan 24, 2017
    Yep - validated in a 2nd tenant - mailuser has mailbox in OWA - no license, no get-mailbox results.

Forum Discussion

Phantom Office 365 Mailboxes

21 Replies

Resources