none
Azure MIIS AD Sync

    Frage

  • Hi,

    Apologies if this is the wrong forum but I cannot find a suitable category :)

    I have a hybrid deployment of Exchange 2010 to be migrated to Exchange Online.

    I created a custom delivery route on our 3rd party spam filter to send email to specific users or groups directly to O365. Due the hybrid nature O365 sends any received emails to the on-prem Exchange 2010 even though the email domain is set to be Authoritative on O365 (according to MS support). This causes an issue (NDR) if the object with re-direction to O365 does not exist in AD/Exchange 2010. That is easily fixed: create an object and all is OK.

    However, the real issues is that the email should not have been re-directed to on-prem from O365 in the first place as the domain is set to be Authoritative. But I'll let that fly for now.

    Now, the real issue: Office 365 groups: There is no equivalent in Exchange 2010.

    The group is created in O365 and gets synced back to on-prem AD/Exchange as a Universal DG (e.g. Group_3191db4f-fb44-404d-a62f-951a92a00d05).

    The default is for internal user can send to this group only. No prob: Change that with "set-UnifiedGroup theshire@domain.com  -AccessType Public". Good: Now the mail gets delivered from the Internet to the Group. Now, due to the hybrid setup the mail goes to the on-prem server. Here is the conundrum I do not understand: The email gets delivered back to O365 by first, expansion of the list by the categorizer, second, routing to O365 (*.onmicrosoft.com). But!! An NDR is being sent as well stating that sender was not authenticated.

    Setting the AD attribute msExchRequireAuthToSendTo=FALSE gets changed back to TRUE with the next sync. Question then: What attribute in O365 gets written back to msExchRequireAuthToSendTo in AD?

    Mittwoch, 7. Februar 2018 07:21

Alle Antworten

  • Hi Vinkie,

    How did you change the AD attribute msExchRequireAuthToSendTo to false?

    Except change it in AD, please also try to set the group in office 365 and check if the same issue persist in next sync:

    Set-UnifiedGroup "GroupName" -RequireSenderAuthenticationEnabled $false


    Best Regards,
    Niko Cheng


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Donnerstag, 8. Februar 2018 09:42
    Moderator
  • Hi,

    Thanks for that but unfortunately that is not working. The attribute msExchRequireAuthToSendTo stays TRUE.

    On O365:

    PS C:\WINDOWS\system32> Get-UnifiedGroup <O365GroupName> | fl *req*
    RequireSenderAuthenticationEnabled : False

    It seems that the RequireSenderAuthenticationEnabled on O365 is not mapped to AD/Exchange attribute msExchRequireAuthToSendTo.

    When I change the msExchRequireAuthToSendTo=FALSE, next sync reverts it back to TRUE even though RequireSenderAuthenticationEnabled=FALSE

    Donnerstag, 8. Februar 2018 10:21
  • Did you find a solution to this?  I have the same issue.  On-prem version is 2016 with the latest CU. 

    David Hood

    Donnerstag, 28. Juni 2018 14:05
  • Hi,

    I used a work-around. The scenario is that:

    1. Send to an O365 Group group@domain.com

    2. O365 hybrid re-routes to on-prem 2010 and fails due to it not existing in on-prem

    3. Create a dummy alias (contact or user) in an OU that is NOT synced to O365 with email group@domain.com but also with a targetAddress pointing to the O365 *.mail.onmicrosoft.com email address

    Exchange 2010 (or any on-prem) does not need to know that it is an O365 group. It only has to know the email address and that it needs to be forwarded to O365 via the targetAddress.



    • Bearbeitet Vinkie Donnerstag, 28. Juni 2018 14:15
    Donnerstag, 28. Juni 2018 14:13
  • Thanks for the reply.  That seems to be the only fix out there for this issue.  

    You also disabled group write back, right? 


    David Hood

    Donnerstag, 28. Juni 2018 14:20
  • No I didn't. But the write-back in my case was done to an OU that is also not synced.
    Donnerstag, 28. Juni 2018 14:22