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.
Today, while I was testing out some transport rules, I wanted to send a bunch of test messages to make sure they were firing correctly. I wanted to create some custom messages and be able to automate them, and I wanted to use an outside relay service that requires SMTP authentication.… [ Continue reading ]
I have created a more detailed example of how to do this here: https://www.undocumented-features.com/2018/09/14/fixing-office-365-anonymous-group-write-back-and-external-delivery/
Office 365 Groups are glorious creations. There are, however, some instances where they don’t work as you anticipate (or hope). One of those scenarios is when you are configured in hybrid coexistence with the following scenario:
In this scenario, external emails sent to Office 365 groups (via your organization’s MX record pointing on-premises) will be returned with one of our favorite NDRs:
“You do not have permission to send to this recipient.”
This happens because the RequireSenderAuthentication attribute (which maps to msExchRequireAuthToSendTo) written to the synced group object is set to the constant True inside of AAD Connect (as shown in the rule “Out to AD – Group SOAInAAD”):
Which translates to this on written-back group objects:
In order to fix this, you need to either update the rule (Edit | Disable and Make a Copy) or update the msExchRequireAuthToSendTo attribute on the synced group objects if you are keeping your MX pointed on-premises, or update the MX to point to Office 365.… [ Continue reading ]
UPDATE: [11/20/2018] I had an error in the transport rule configuration in the last example, as well as a note that a TR would NDR external traffic. I have this post accordingly.
We’re all familiar with how Office 365 tenants work–when you spin up a new Office 365 tenant, you get a managed domain (tenant.onmicrosoft.com). … [ Continue reading ]