# Fixing Office 365 Anonymous Group Write-back and External Delivery

• 6
•
•
• 1
•
•
7
Shares

Yes, Hell has frozen over. The cows have come home. The lady of size has sung.

I have come up with a “best case” solution for the Office 365 hybrid group write-back problem.

# Background

For the long(er) background, you’ll probably want to go see this post.

1. Office 365 Groups can be written-back to on-premises environments to make them visible to on-premises users.
2. If your MX record is pointed to an on-premises environment and you have Office 365 Group write-back turned on and some of those groups are configured for anonymous receive (ie, allowed to receive unauthenticated or anonymous messages from the internet), external senders will receive an NDR with the ever-popular and cryptic message “You do not have permission to send to this recipient.”

As was previously discussed in the post, this is because AAD Connect writes a constant value of True for the msExchRequireAuthToSendTo attribute of a written-back group. The synchronization service cannot read the actual value of the attribute from the cloud, which is why a constant needs to be used.

The calamity.

# Solution overview and limitations

So, here is how to fix it the best way we can at the moment.  It involves changing the constant value of msExchRequireAuthToSendTo from True to False.  This will allow the on-premises system to route the mail to Office 365, where the value stamped on the actual object will be evaluated.  If the cloud value is True, Office 365 will generate an NDR and relay it back out.  If the cloud value on the group is False, the message will be delivered.

The caveat is this:

Mail will be delivered to any on-premises mailboxes that are members of any Office 365 groups regardless of the cloud value if this configuration change is made to the attribute globally.

To minimize this risk, I recommend modifying the Description attribute of all the Office 365 groups that will require anonymous (external) delivery with a value that you can use as a scoping filter–that way, we can target updating only groups that have a specific keyword in the description of the group.  For this exercise, I modified the description attribute to start with the word EXTERNAL.

# Pre-pend description field with EXTERNAL

1. Connect to Office 365 via PowerShell.
$Credential = Get-Credential$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $Credential -Authentication Basic -AllowRedirection Import-PSSession$Session
2. List all the groups that allow external senders.
Get-UnifiedGroup -ResultSize Unlimited | ? { $_.RequireSenderAuthenticationEnabled -eq$false } | Select Alias,Name,Notes

3. Update the description (Notes) field to prepend the text to use as a scoping filter (in this case, EXTERNAL).
Get-UnifiedGroup -ResultSize Unlimited | ? { $_.RequireSenderAuthenticationEnabled -eq$false } | % { Set-UnifiedGroup $_.Identity -Notes "EXTERNAL -$($_.Notes)" } 4. Verify the update. Get-UnifiedGroup -ResultSize Unlimited | ? {$_.RequireSenderAuthenticationEnabled -eq \$false } | Select Alias,Name,Notes

5. Wait for an AAD Connect delta sync cycle to run (or initiate one yourself from the AAD Connect server’s PowerShell interface with the following command):
Start-ADSyncSyncCycle -PolicyType Delta

Note: This is a one-time update.  Going forward, you’ll need to train your users to both:

• Ensure the “Let people outside the organization email the group” checkbox is selected in the group configuration
• Update the description of the Office 365 groups they manage that need to accept mail from external senders to include the text that’s going to be used as the scoping filter.  They can do this by editing the group in Outlook (Select Group from Outlook navigation pane | Group Settings | Description) or in Outlook Web App (People | Groups | Edit Group | Description) and putting the necessary text in that you want to use as a scoping filter in the description field.

# Create an outbound to Active Directory rule to modify the attribute value

1. Launch the Synchronization Rules Editor (Start | Synchronization Rules Editor).
2. Under the Direction label, select Outbound.  Click Add New Rule.
3. Enter a Name for the rule, select your Active Directory connector under Connected System, and then select group for both the Connected System Object Type and the Metaverse Object Type.  Ensure the Link Type is set to Join, and then enter a low precedence number (such as 50). Click Next when finished. If you have more than one Active Directory forest configured in AAD Connect, select the forest to which Office 365 groups are written back.
4. On the Scoping filter page, click Add group.
6. In the Attribute column drop-down, select cloudMastered.  Under Operator, select EQUAL. In the Value box, type true.  Click Add clause, select description. Under Operator, select STARTSWITH. In the Value box, type EXTERNAL.  Click Next.
7. On the Join rules page, just click Next without adding anything.
8. Click the Add transformation button.
9. Under the FlowType drop-down, select Constant.  Under the Target Attribute, select msExchRequireAuthToSendTo.  Under Source, enter false and click Add.
10. Close the Synchronization Rules Editor.

# Preview the objects

1. From the Synchronization Service user interface, select the Active Directory connector.  If you have more than one Active Directory connector, select the connector representing the directory where the Office 365 groups will be written back.
2. Right-click on the connector and select Search Connector Space.
3. Under Scope, select RDN, and in the Specify relative distinguished name (RDN) or anchor value box, enter CN=Group_ (all Office 365 groups written back on-premises are prefaced with Group_) and click Search.
4. Select a group from the list and click Preview. Note: You may want to select Column Settings… and add the Display Name column so you can more easily identify your synchronized groups.
5. Select the Full Synchronization radio button and click Generate Preview.
6. Expand Connector Updates | CN=Group_<guid> | Export Attribute Flow, and then look in the window for the msExchRequireAuthToSendTo attribute.  Note the value in the column should be false.
7. Click Close twice to close the Preview and Search Connector Space dialog boxes.

# Make it so

1. Right-click the Active Directory connector, click Run.
2. Select the Full Synchronization option and then click OK.  This will run the synchronization rule on all in-scope objects and stage the changes for export.
3. After the run profile task has completed, right-click the Active Directory connector, select Run, select Export and click OK.  This will write the changes to Active Directory.
4. After the run profile task has completed, launch Active Directory Users and Computers, navigate to the organizational unit containing the written-back Office 365 Groups, expand a group, and on the Attribute Editor tab, view the value for msExchRequireAuthToSendTo. Or, alternately, add the msExchRequireAuthToSendTo column to ADUC and review them all.

Now, your external senders should be able to relay to your Office 365 groups via your on-premises gateway.  Woo!

Helping companies conquer inferior technology since 1997. I spend my time developing and implementing technology solutions so people can spend less time with technology. Specialties: Active Directory and Exchange consulting and deployment, Virtualization, Disaster Recovery, Office 365, datacenter migration/consolidation, cheese.

1. Thanks for the great writeup on an important issue! Like others, I’m also getting NDRs with the “554 5.4.6 Hop count exceeded – possible mail loop” error after I’ve implemented these changes described.

It looks like the email is getting to the on-prem exchange server, and it’s no longer being rejected due to a lack of authorization. The mail server knows that a group exists matching the destination email address, but doesn’t know how to deliver it.

In the case of a user mailbox, the on-prem AD account has a targetaddress attribute which is populated with an email address using the cloud tenant domain (e.g. mydomain.mail.onmicrosoft.com). The exchange server has a send connector scoped to that domain, and knows to pass messages addressed to that domain to Exchange Online for delivery. For Office365 groups being written back to AD, the targetaddress attribute is set to the same as the primary email address of the group (e.g. mygroup@mydomain.com). Exchange knows that it handles messages for that domain, and doesn’t know to pass the message on to Exchange Online.

I tried manually updating a group’s targetaddress to use the onmicrosoft.com version of the domain. I then sent a test email to the group from an external address. The message was delivered to the group members, but not to the group mailbox. It looks like the message was passed to EO, where it expanded the DL and delivered the message to the group members, but when it tried to deliver to the group itself it passed the message back to on-prem exchange.

I expect that this wouldn’t be a problem if you use a seperate subdomain for groups. Since they share the primary domain in our environment, messages get stuck in a loop and eventually bounce. I can see why it’s behaving the way it is, but I’m not sure how to go about correcting the issue.

1. How are your accepted domains set up in your on-premises Exchange environment? You may want to try to set your public domains that you have shared with Office 365 to “internal relay.”

1. STEVE WHITCHER says:

I don’t think I got a notification that you had replied, or if I did I overlooked it. Our accepted domains are set to Authoritative in both the On-Premises and Online environments. A send connector in on-prem exchange directs mail destined for the “domain.mail.onmicrosoft.com” domain to Office 365.

My understanding was that the domains should be configured as authoritative when used in a hybrid environment. Is changing them to Internal Relay a supported config?

1. Yes. You typically shouldn’t have them authoritative in both spots. Since the GAL is the official record of who exists in the org, if you have the domain set to authoritative it well never forward out. You can get Exchange (either on-premises or cloud) to forward to the other environment in the same namespace by setting the domain to Internal Relay.

2. Navaid Farooqui says:

I was able to resolve this issue. I have asked Microsoft Support to recommend this workaround so the Development team can bake this into the actual code.

Basically I had to add the @Domain.Mail.OnMicrosoft.com address to the list of Proxy Addresses of the Office 365 Group from Exchange Online Shell

Then change the TargetAddress to this @Domain.Mail.OnMicrosoft.com address (You will have to delete the TargetAddress attribute from the Synchronization Rules so it doesn’t sync back and overwrite)

After this test email from On-Premise and External source. It should work for both

1. STEVE WHITCHER says:

Thanks for this Navaid. Let me make sure I understand you correctly –

In Exchange Online, you add a proxy address with the domain.mail.onmicrosoft.com domain to the O365 group.

In exchange On-Prem, you change the target address to point to the domain.mail.onmicrosoft.com domain.

Do I have all that right?

When sending mail from an external source to an office 365 group, does the message get delivered to the group mailbox as well as each individual member’s mailbox? When I had tried changing the target address previously the message was not getting delivered to the group mailbox.

Blocking sync of the target attribute from Online to On-Prem seems like something that might come back to haunt me in the future. I wonder if I could instead add another transformation to the sync rule described in the article, which would modify the domain used in the target address. That way it would be filtered to the EXTERNAL description, and would be applied automatically instead of me having to manually change the target address on each group. I’ll have to read up on these synchronization rules a bit more to see if that can be done using an expression rule.

It definitely seems like this would be the right track. Thank you very much for sharing!

1. I wouldn’t block or delete the sync rule for targetAddress, as that will cause issues for things like mail-enabled users that are synchronized. You should set the domain for the Office 365 group to your @domain.com address, because all mail for @domain.com will flow through your hybrid connector to Office 365 if you’ve set your on-premises domain to internal relay.

2. Tom Turpin says:

I too am receiving:

554 5.4.6 Hop count exceeded – possible mail loop (in reply to end of DATA command)

I believe it is due to my Exchange environment not knowing of the Write-Back Office 365 Groups in my AD structure. I have not solved this issue thus far.

1. Tom Turpin says:

My issue has been resolved. I had issues with regard to internal routing on our MX record service as o365 is not our MX record.

3. Naght says:

Hey, thanks for the great article. I have implemented this configuration. Prior to implementing this config, when emailing the O365 group from an external email address, the external user would receive the following NDR: Your message can’t be delivered because delivery to this address is restricted.

After implenting the change mentioned in your article, the external user now receives this NDR:
554 5.4.6 Hop count exceeded – possible mail loop
554 5.0.0 Service unavailable

Have you encountered this before? any ideas on resolving this?

1. Do you have Office 365 group write-back enabled, are the groups visible in your on-premises GAL, and are they configured to allow anonymous access in office 365?

4. Naght says:

Thanks for this great article. I’ve implemented this, and the external sender receives a NDR with emailing the office 365 group. NDR states:

554 5.4.6 Hop count exceeded – possible mail loop
554 5.0.0 Service unavailable

Please let me know how this issue can be resolved. Thank you

This site uses Akismet to reduce spam. Learn how your comment data is processed.