Custom Domain for O365 Groups in a Federated Hybrid Environment

[Ivan Unger]

So, I'm trying to wrap my head around my current problem and could use a little help.

What we have:

• Office 365 with a verified custom domain (e.g. contoso.com)
• Exchange 2013 onPrem
  • also the MX records for contoso.com point to the onPrem environment
  • therefore all incoming mails for contoso.com will be routed through our onPrem environment
• custom domain (contoso.com) is also federated
  • AAD Connect and ADFS SSO
  • therefore I cannot set the Default Domain in Office 365 to our custom domain (contoso.com)
  • is this correct? http://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin-mso_domains/cant-set-domain-to-...
• Exchange Online is connected to our onPrem Environment in a hybrid state
  • done with the Office 365 Hybrid Wizard
  • Groups Writeback has also been enabled 
    • I'm not sure if this was really necessary, since I do plan to move all mailboxes to Exchange Online, but
    • I've completed all the steps (from https://technet.microsoft.com/library/mt668829(v=exchg.150).aspx) except Step 2 - adding the "new groups domain".
      • Am I really supposed to add a new domain (in this case groups.contoso.com) to Office 365? When I try to do that, I get notified about this beeing a subdomain of my already configured custom domain and that I would have to do this through PowerShell (no further links added)
• Created Office 365 Groups, and
  • changed the primary SMTP address to groupname@contoso.com or
  • added an additionaly SMTP address to groupname@contoso.onmicrosoft.com (I've tried both variants)
  • enabled Outside Senders for mentioned groups

TL;DR

I'm not able to "reach" (send mail) our Office 365 Groups externally through our custom domain (contoso.com)

I'm getting a NDR from our internal Exchange Environemnt: DSN-Code 5.7.1 in Exchange Online

Remote Server returned '550 5.7.1 RESOLVER.RST.AuthRequired; authentication required'

My Questions is, is this even supposed to work?

I did find this article about Multi-Domain Support for Office 365 Groups (https://support.office.com/en-us/article/Multi-domain-support-for-Office-365-Groups-Admin-help-7cf56...

I can send mails this group externally when sending to groupname@contoso.onmicrosoft.com (so, the Outside Senders parameters is working correctly).

[#2]

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.

[#3]

Will contact support (or CSP in our case). 

I have them synced back onPrem, that's working "fine".

What I'm unsure about, are Steps 2 and 3 for Groups Hybrid setup. What are they even for?

• why do I need to add a subdomain of my already verified vanity domain
  • and how do I do it via PowerShell?
• what are the public DNS (MX and CNAME) for the this subdomain for?
  • it's not like those groups suddenly have new email addresses like groupname@groups.contoso.com
  • or is that how it supposed to work and I'm not supposed to use groupname@contoso.com?

[#4]

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?

[#5]

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.

[#6]

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).

[#7]

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-7cf56...)

[#8]

Thank you Ankit for the response.

So I am right to assume that there is currently no way for me to migrate our current onPrem Distribution Lists (with all their aliases), especially if they are available for external communication, without publishing or announcing a new SMTP addresses for a group (e.g. department)?

[#9]

Hello Ivan,

Could you verify if the send-Connector is configured correctly for groups.contoso.com as mentioned in the point 4 of this doc. 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

[#10]

I asked Mr. Van Hybrid about this issue. Here's his response:

So, I'm trying to wrap my head around my current problem and could use a little help.

What we have:

• Office 365 with a verified custom domain (e.g. contoso.com)
• Exchange 2013 onPrem
• also the MX records for contoso.com point to the onPrem environment
• therefore all incoming mails for contoso.com will be routed through our onPrem environment
• custom domain (contoso.com) is also federated
• AAD Connect and ADFS SSO
• therefore I cannot set the Default Domain in Office 365 to our custom domain (contoso.com) --> [MVH] correct; because a user must be synced for it to be able to authenticate.
• is this correct? http://answers.microsoft.com/en-us/msoffice/forum/msoffice_o365admin-mso_domains/cant-set-domain-to-...
• Exchange Online is connected to our onPrem Environment in a hybrid state
• done with the Office 365 Hybrid Wizard
• Groups Writeback has also been enabled 
• I'm not sure if this was really necessary, since I do plan to move all mailboxes to Exchange Online, but
• I've completed all the steps (from https://technet.microsoft.com/library/mt668829(v=exchg.150).aspx) except Step 2 - adding the "new groups domain".
• Am I really supposed to add a new domain (in this case groups.contoso.com) to Office 365? When I try to do that, I get notified about this beeing a subdomain of my already configured custom domain and that I would have to do this through PowerShell (no further links added) [MVH]: I don't believe this is necessary. The groups write-back feature will already stamp the group with a target address that matches the routing domain (which he mentions below), that will take care of mail flow for the group. I am working with Christophe to get the guidance on TN updated to reflect this.
• Created Office 365 Groups, and
• changed the primary SMTP address to groupname@contoso.com or
• added an additionaly SMTP address to groupname@contoso.onmicrosoft.com (I've tried both variants)
• enabled Outside Senders for mentioned groups

TL;DR

I'm not able to "reach" (send mail) our Office 365 Groups externally through our custom domain (contoso.com)

I'm getting a NDR from our internal Exchange Environemnt: DSN-Code 5.7.1 in Exchange Online

Remote Server returned '550 5.7.1 RESOLVER.RST.AuthRequired; authentication required'

[MVH]: It's hard to tell what the problem is. To me it looks like the hybrid mail flow might not be setup correctly. If it were, the mail would hit the on-prem servers which would then forward the email to the target address of the group (over the hybrid connector) to Office 365. The connector is authenticated (explicit tls with domain auth.), so that error should not appear. Hence why I believe something might be wrong there.

[#11]

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

groupalias@groups.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)" <adminunger@acv.at>To: IAKW IT <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: <83f62b9e9c1142f3be0bbdf4ec953e69@servername.subdomain.contoso.com>Accept-Language: en-US, de-ATContent-Language: en-USX-MS-Has-Attach:X-MS-TNEF-Correlator: <83f62b9e9c1142f3be0bbdf4ec953e69@servername.subdomain.contoso.com>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).

[#12]

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 

[#13]

Ankit,

I believe that I have the identical issue/architecture as OP with regard to the on-premesis server returning 5.7.1 Authentication Required errors when an esternal sender trys to email an Office365 Group.

You note that you are aware of this issue... is there any update/resolution?

Thanks

[#14]

Hi everyone, so I think I know what the issue is, though I don't know how to solve it, or if it is even solvable. 

Looking at this page (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-aadconnect-feature-preview)  I've found this paragraph "This group will be represented as a distribution group in on-premises AD DS. Your on-premises Exchange server must be on Exchange 2013 cumulative update 8 (released in March 2015) or Exchange 2016 to recognize this new group type."

Our single Exchange Server 2013 server is CU13, so this shouldn't not be an issue. I will update to CU14 in the coming days though just to be sure.

I believe Exchange onPrem is not recognizing the recipient (the Office 365 Group with groupname@custom.domain). When I run "get-recipient groupname@custom.domain" I don't get a hit, even though the group is written back to ADDS as a distribution group. But I've noticed that the written back distribution group does not appear in the Exchange Admin Center (ECP) under Recipients > Groups.

That's why I believe the Exchange Server is returning mails from external senders. 

The question is, should O365 Groups that are written back to ADDS also appear in the ECP, and should get-recipient find the groups primary SMTP address?

Any input?

*EDIT1*: get-distributiongroup doesn't return the written back group as well.

[#15]

Written back objects have "RemoteGroupMailbox" as the RecipientTypeDetails hence they won't show up in ECP and Get-DistributionGroup cmdlets. You can verify the written back objects using ldp and also these objects should get reolved in GAL (if you are on the right Exchange version).

[#16]

Hi Ankit,

I'm unsure how to verify this with ldp.exe.

Best I've found are the following attributes, though none mention RemoteGroupMailbox. 

• groupType: 0x8 = ( UNIVERSAL_GROUP );
  • should this say RemoteGroupMailbox?

Also unclear to me are the following attributes, could you clarify if these are correct for writtenback groups?

• msExchRequireAuthToSendTo: TRUE;
  • this is basically the error my exchange server is returning when sending to an O365 groups custom domain address
  • Setting attribute manually to FALSE gets my external message pass the onPrem Exchange (finally)
• targetAddress: SMTP:groupname@custom.domain
  • this is also different than for user mailboxes, since migrated UserMailboxes have upn@tenant.mail.onmicrosoft.com as target addresses
  • groupname@tenant.mail.onmicrosoft.com as target addresss does not work - I get an O365 bounce (only with authreq set to FALSE above) 550 RESOLVER.ADR.RecipientNotFound.
  • groupname@tenant.onmicrosoft.com as target address WORKS - finally

I've done a lot testing with those 2 attributes and I can 100% confirm that by manually changing them, I was able to use my custom domain for writtenback O365 groups.

So the question is, why is the O365 Hybrid Wizard and/or AAD Connect not doing this on its own?

Also confusing, though unsure if related: When running the O365 Hybrid Configuration Wizard I get the option to configure groups.custom.domain in addition to custom.domain as well. Do I check that box or leave it alone?

Since my initial goal is to get custom.domain to work with O365 Groups in a hybrid scenario (with MX pointing onPrem) I'm still unsure what to do with all that groups.domain.com configurations.

*EDIT1*

After further testing the culprit seems to be AAD Connect, which overwrites (with every delta sync) msExchRequireAuthToSendTo and sets it to TRUE and also resets targetAddress and sets it to identical with PrimarySMTPAddress.

After that my groups are not reachable by custom.domain. Also alias SMTP addresses are reachable, as long as the target address is groupname@tenant.onmicrosoft.com.

Additionally when manually setting a new Primary SMTP Address through powershell, a new @tenant.onmicrosoft.com address is not created. I'm unsure how AAD Connect is supposed to handle these changes, since mails only seem to go through with a proper targetAddress attribute that is not custom.domain.

[#17]

Did anyone ever figure this out? We are having the same issue. Using Exchange 2013 CU 16, AAD Connect overwriting msExchRequireAuthToSendTo and sets it to TRUE.

---

*EDIT1*

After further testing the culprit seems to be AAD Connect, which overwrites (with every delta sync) msExchRequireAuthToSendTo and sets it to TRUE and also resets targetAddress and sets it to identical with PrimarySMTPAddress.

After that my groups are not reachable by custom.domain. Also alias SMTP addresses are reachable, as long as the target address is groupname@tenant.onmicrosoft.com.

Additionally when manually setting a new Primary SMTP Address through powershell, a new @tenant.onmicrosoft.com address is not created. I'm unsure how AAD Connect is supposed to handle these changes, since mails only seem to go through with a proper targetAddress attribute that is not custom.domain.

---

[#18]

Not that I'm aware. I also think it won't be fixed as we're expected to route MX records directly at O365.

[#19]

We are having the exact same issue.  Has anyone found a fix for this?

[#20]

Unfortunately not, though I haven't tried recently.