Forum Discussion
Custom Domain for O365 Groups in a Federated Hybrid Environment
I would log a call with Microsoft support and get some help to work through this scenario. It is definitely supported to have Office 365 groups synchronized back to an on-premises AD using the latest version of AADconnect. The multi-domain article you reference has nothing to do with hybrid interoperability.
Hi Tony, I've talked to our CSP and they weren't able to find any articles that confirm this functionality explicitly.
I've managed to enable the subdomain (e.g. groups.contoso.com) for our tenant have that synced back to onPrem (e.g. groupsname@groups.contoso.com). Reminder: MX records for groups.contoso.com point to O365 directly.
I've added additionaly aliases (groupsname@contoso.com) to the group, but I'm unable to get mail through to the group by using any aliases from external or internal. Reminder: MX records for contoso.com point onPrem.
Do you have any documentation that mentions functioning vanity domains for Office 365 Groups in a federated (ADFS) environment?
Hello Ivan,
Could you verify if the send-Connector is configured correctly for groups.contoso.com as mentioned in the point 4 of https://technet.microsoft.com/en-us/library/mt668829(v=exchg.150).aspxdoc. If the connector was not configured then group should be configured to receive mails for external senders.
Could you share the NDR error details?
Thanks
Hi Ankit,
Yes, I've verified that onPrem
- groups.contoso.com is in the accepted domains and set to internal relay
- groups.contoso.com is added to the "Outbound to Office 365" Send Connector (through that powershell cmd line)
But I agree with Tonys comments, that there must be something wrong with the mail flow somehow. Because I've realized that I can't even send mails from onPrem to O365 for @groups.contoso.com groups that have this set as a primary SMTPaddress.
Here's the NDR:
Delivery has failed to these recipients or groups:
<GROUP DISPLAY NAME>
A problem occurred and this message couldn't be delivered. Check to be sure the email address is correct. If the problem continues, please contact your helpdesk.Diagnostic information for administrators:
Generating server: servername.subdomain.contoso.com
groupaliasmailto:iakw_it@groups.acv.at.contoso.com
Remote Server returned '< #5.4.4 smtp;554 5.4.4 SMTPSEND.DNS.NonExistentDomain; nonexistent domain>'Original message headers:
Received: from servername.subdomain.contoso.com (INTERNAL EXCHANGE IP) by servername.subdomain.contoso.com (INTERNAL EXCHANGE IP) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 6 Oct 2016 09:48:16 +0200Received: from sservername.subdomain.contoso.com ([IP v6 ADDRESS]) by servername.subdomain.contoso.com ([IP v6 ADDRESS]) with mapi id 15.00.1210.000; Thu, 6 Oct 2016 07:48:16 +0000Content-Type: multipart/mixed; boundary="_000_83f62b9e9c1142f3be0bbdf4ec953e69smx01vcorpacvat_"From: "UNGER, Ivan (ADMIN)" <mailto:adminunger@acv.at>To: IAKW IT <mailto:iakw_it@groups.acv.at>Subject: test to groups.contoso.com 3Thread-Topic: test to groups.contoso.com 3Thread-Index: AQHSH6X/JciWgSC/2Eyop2WgMGxIbQ==Date: Thu, 6 Oct 2016 07:48:16 +0000Message-ID: <mailto:83f62b9e9c1142f3be0bbdf4ec953e69@smx01v.corp.acv.at>Accept-Language: en-US, de-ATContent-Language: en-USX-MS-Has-Attach:X-MS-TNEF-Correlator: <mailto:83f62b9e9c1142f3be0bbdf4ec953e69@smx01v.corp.acv.at>x-ms-exchange-transport-fromentityheader: Hostedx-originating-ip: [CLIENT IP v4 ADDRESS]x-esetresult: clean, is OKx-esetid: 37303A2962C4E3676C7D62MIME-Version: 1.0X-OrganizationHeadersPreserved: servername.subdomain.contoso.com
Mail Flow for user mailboxes that use the contoso.com domain seems to be working just fine. So it can't be all wrong with the send connector. It just not working for Office 365 groups from onPrem to O365 (contoso.com or groups.contoso.com).
Hi Ivan,
We are aware of the issue because of which on-prem transport raises AuthRequired NDR messages from external users to groups (even if group allows external users).
On-prem transport throwing NonExistentDomain NDR only for groups even for the org. users is something new. We will need more details to debug it and hence I suggest you to open a ticket for the same.
Thanks
Ankit
Nope. No documentation. Hopefully one of the Groups engineers will be able to chime in and say what scenarios have been tested or validated for federation.
Too bad, of course normally we would assume groups work with custom domains, and they do, if you point the MX records directly at O365 and manage everything online.
But as soon as ADFS and AAD come into play, onPrem becomes the "owner" of the custom domain and you lose the ability to create objecty (like groups or users) online with the custom domain. Instead you have to create the user/group with the custom domain onprem and have it synced back online.
This of course doesn't work for Office 365 groups because they are special (and the O365 Groups write back is still in preview).
Hi Ivan,
For now, we recommend using existing/new cloud-authoritative domains (not a federated domain/subdomain) to stamp group addresses to work in hybrid scenarios. Also you don't need to set this domain as the default accepted domain for your organization instead you could use EAPs to get groups provisioned with addresses in the chosen group domains. Document describing how to configure EAPs for group mailboxes (https://support.office.com/en-us/article/Multi-domain-support-for-Office-365-Groups-Admin-help-7cf5655d-e523-4bc3-a93b-3ccebf44a01a?ui=en-US&rs=en-US&ad=US&fromAR=1)
