Tuesday, June 2, 2015

New EOP connector validation fails when connector is disabled

Recently Microsoft announced a new feature for creating connectors in Exchange Online Protection: Announcing a new way to create connectors in Office 365. What it basically does is adding a few steps to the wizard after an admin creates an outbound connector. In these steps the configuration of the connector is being validated by sending a test email.

image

Validation is mandatory and a connector can only be saved after you performed validation, whether validation failed or succeeded. I think this is a great feature because configuration mistakes can be easily made and often result in huge queues filling up or lot of NDRs being sent.

Now unfortunately there is an issue with the current implementation. Consider a scenario where you need to prepare a connector but you're not ready to enable the connector and actually modify the mail flow configuration. When you for instance need approval first or wait for a maintenance window to activate the changed configuration.

The wizard anticipates this scenario and allows you to uncheck the "Turn it on" option on the second page of the wizard:

image

Before the latest update this would result in a disabled but configured connector. Currently this results in a failed validation, even if the settings of the connector are all correct.

In this example I created an outbound connector from Office 365 to a Partner Organization, used the default options where TLS is applied and added the Hotmail.com domain to the connector. After validation the Send test mail step fails:

image

The error message is "The domain of the recipient is not configured as part of connector". The Detailed Log doesn't provide any details about why the test failed. In fact it didn't even fail, the test email was received successfully:

image

This issue is being caused by the fact we choose not to enable this connector. If we would not have removed the checkmark and allow EOP to create and enable the connector the validation succeeds. This is obviously a bug and should be improved by either being able to validate a disabled connector or give the admin some feedback that validation failed because the connector being in a disabled state.

So what can we do to create the connector successfully? Here we have several options. First is to enable the connector during creation and validation and disable it immediately afterwards. Another option is to check if the test email was receive on the remote system and ignore the failed validation. Finally we can test the process in a test (or trial) tenant, however this tenant would likely not be 100% identical to our production tenant.

A service request was raised with Microsoft Support and I'm expecting a fix somewhere in the near feature.

10 comments:

Gianluca Semprini said...

Thanks a lot!
I was stuck on this problem for a week... thanks, thanks again.

Jetze Mellema said...

You're welcome!

Anonymous said...

Great tip, thanks!

Anonymous said...

Yep, had me stumped too, thank you!

Anonymous said...

I was lucky this is one of the top Google hits for "The domain of the recipient is not configured as part of connector"

Thanks!

JS Bark said...

Still seems to be the case in late 2016, thanks.

Anonymous said...

Had the same issue. Thanks much for the solution.

Anonymous said...

Thank you for this. It is actually a bit sad the error is still very vague 18 months later.

Eric Berry said...

Helpful article, thank you!

Still an issue July 5, 2017

"This feature will never tell you that it's working until you turn it on in a live environment"
Cool beans, Microsoft

Unknown said...

I just got stumped on this as well. I'm glad we've got somewhere on here who has bitten the bullet and "gone live"