01-24-2017 11:46 AM
01-24-2017 11:46 AM
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.
01-24-2017 01:11 PM
01-24-2017 01:23 PM
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)
01-24-2017 01:43 PM
01-24-2017 01:45 PM
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
01-25-2017 09:40 AM
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?
01-25-2017 11:19 AM
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.
01-25-2017 12:08 PM - edited 01-25-2017 12:09 PM
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.
01-25-2017 12:56 PM
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 email@example.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.
01-25-2017 01:06 PM
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.
01-26-2017 01:35 AM
I had a conversation with the Outlook team and the phantoms are not their responsibility. Stranger forces are at work!
01-26-2017 01:52 AM
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.
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.
01-26-2017 02:03 AM
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.
01-26-2017 02:08 AM
01-26-2017 02:11 AM
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...
01-26-2017 03:09 AM
01-26-2017 06:22 AM
I'm sure I'll find out more from support today but you guys are uncovering what I was suspicious of originally. It would seem that this is possibly some byproduct of another requirement within the service to have a "mailbox" as an anchor.
01-27-2017 09:34 AM
Word from support is "known issue" but they can't give me any timelines or details as to when this will be remedied. Just something that everybody should be aware of if they're dealing with "mail user" objects.