Sep 20 2016 06:23 AM - edited Sep 20 2016 06:27 AM
So, I'm trying to wrap my head around my current problem and could use a little help.
What we have:
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).
Sep 20 2016 10:43 AM
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.
Sep 21 2016 04:44 AM
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?
Oct 04 2016 04:16 AM
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?
Oct 04 2016 07:31 AM
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.
Oct 05 2016 06:04 AM
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).
Oct 05 2016 09:05 AM - edited Oct 05 2016 09:14 AM
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...)
Oct 05 2016 10:30 PM
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)?
Oct 06 2016 05:12 AM
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
Oct 06 2016 01:54 PM
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:
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.
Oct 06 2016 10:28 PM
Hi Ankit,
Yes, I've verified that onPrem
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).
Oct 07 2016 12:57 AM
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
Oct 27 2016 06:28 PM
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
Nov 18 2016 06:35 AM - edited Nov 18 2016 06:40 AM
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.
Nov 21 2016 12:19 AM - edited Nov 21 2016 12:20 AM
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).
Nov 21 2016 01:53 AM - edited Nov 21 2016 02:33 AM
Hi Ankit,
I'm unsure how to verify this with ldp.exe.
Best I've found are the following attributes, though none mention RemoteGroupMailbox.
Also unclear to me are the following attributes, could you clarify if these are correct for writtenback groups?
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.
Apr 18 2017 07:44 PM - edited Apr 18 2017 08:26 PM
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.
Apr 18 2017 10:57 PM
Sep 20 2017 08:20 AM
We are having the exact same issue. Has anyone found a fix for this?
Sep 21 2017 11:22 AM