External Email recieved by 365 Groups

[Jason Hopp]

I am running a hybrid environment, and mailflow still goes through our on-premise exchange server.  Due to other circumstances, we are unable to change our MX records at the moment.  In the meantime, we are moving our on-premise Distribution Lists to Office 365 groups.

The problem is that we have several customers and vendors from the outside who email these DLs, and I am unsure how they will be able to email the 365 groups through the on-premise exchange server, since I am unable to add a contact that points to group.

And we do not want to give the customers or vendors new addresses to start emailing.  That would be a nightmare.

Does anyone have any idea how when I add a 365 group with the same name and primary SMTP as a distribution list on premise (after removing the DL), and still have external people email that same address, but it goes through the our on-premise exchange server.

We are also running ADFS.  On-premise Exchange servers are 2013 CU12.  E3 licensing on 365.

This will solve a huge problem for me, so thank you for any suggestions.

[#2]

The Group writeback feature should help you with that: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-feature-...

Or you can simply create any kind of on-prem object, set its targetaddress to point to the group@tenant.onmicrosoft.com address, hide from GAL and exclude it from dirsync. Other forms of forwarding should also work.

[#3]

I have created an Uservoice some time ago about this. this is regarding aliases in the office Group.

https://office365.uservoice.com/forums/286611-office-365-groups/suggestions/17439772-make-a-group-al...

[#4]

Thanks for the response.  I have looked into and tried both, with the following results:

@Vasil Michev - Not sure what the attribute is specifically called, but we do not have the premium subscription to Azure, so the article says it won't work anyway.

@Jerry Meyer - Tried your solution to add the onmicrosoft.com smtp address as primary and let it sync.  Still no go.

Here is what I am trying and what I am recieving.

I have a on-premise distribution group with one member.  That member is a contact with the email address as testold@<domain>.com and a target address with TestGroup01@<tenant>.mail.onmicrosoft.com (can't use the <tenant>.onmicrosoft.com address because it tells me that address can not be used to route mail).  When I try to send to the on-premise account, it reaches the contact then gives me an NDR stating the target email is restricted and requires authentication.  But the attribute -RequireSenderAuthenticationEnabled is set to $false, and the accept messages are set to "All Senders" and the reject set to "No senders".

Not sure what I am missing, but do you have any other suggestions?

Jason

[#5]

I have found an Blog with a suggested work arround. http://www.michev.info/Blog/Post/1071/5-4-1-ndrs-when-sending-external-messages-to-modern-groups-aka...
Maybe your answer is in there.

Edit: After i posted it i noticed that it is Vasil's Blog :)

[#6]

Thanks, but already been through that one as well.  Doesn't work in my situation.

Got anything else?

Jason

[#7]

Jason, we have the same config (hybrid with on-prem and cloud groups). Our primary email domain umail.miami.edu still goes to our on-prem servers first and then cloud. After we migrate our groups, we create a contact on-prem with the external address of group@tenant.onmicrosoft.com. I'm not usre why you're getting "(address can not be used to route mail)." Here is a screenshot of the email properties of one of our groups.

[#8]

That tends to be the problem, I am unable to create a contact with the external address of @tenant.onmicrosoft.com because it throws an error that the proxy address already exists on another object.

Any idea how to get around that?  If I could create the contact, I believe I would be off and running, 

Jason 

[#9]

Are you syncing cloud properties/objects down to your on-prem environment? If not, how does your on-prem environment know about the group@tenant.onmicrosoft.com address. In our environment our cloud groups (and their properties) do not show up on-prem which is why we can add group@tenant.onmicrosoft.com to our contact.

[#10]

They write back to our ADFS.  So in active directory, the address is there for the group.  Our on-premise exchange does not see the groups, but because it is all tied to AD, the address already exists.

Jason

[#11 · Accepted solution]

We have figured out what we can do (hopefully).  We are going to change our MX record to point to 365.  Once that is done, we have written a script that will create placeholders in 365, allow us to remove the on-premise DL, then rerun the script with a Finish parameter that changes the group name and primary SMTP over to the actual DL.  Doing it this way, we can move smaller sections of DLs and keep the disruption to the business to a minimum.

I will write back to confirm this works.

Jason