Create/Edit On-Premise type inbound connector in UI after cmdlet update

[liamherbert1105]

Following the updates on 24th July to the New/Set-InboundConnector cmdlets, you can no longer create Inbound connectors of type on-premise in the UI.

You get the error:

Microsoft.Exchange.Management.Tasks.ConnectorNotApplicablePropertyException|The properties 'RestrictDomainsToCertificate' are not applicable to connector of type
'OnPremises' with the current combination. Connector creation or modification aborted.

Essentially, the RestrictDomainsToCertificate and RestrictDomainsToIPAddresses parameters were updated to only be allowed for partner connectors.

This is understandable, since these elements aren't considered for emails delivered via on-premise connectors anyway.

However, if you try and create an on-premise connector in the Exchange Online UI, particularly for certificated based auth, the RestrictDomainsToCertificate is set to $true by default in the UI, even though the PowerShell param default is $false.

If so, you can still make the connector, you just need to do so via PowerShell, and either omit the -RestrictDomainsToCertificate parameter or explicitly set it as $false.

If you need to edit an existing connector that was created with this set to true, you need to set it to false first before editing, and again, only via PowerShell.

Set-InboundConnector -Identity "connectorID/name" -RestrictDomainsToCertificate:$false

[#2]

@liamherbert1105 Having the same issue and tried to detail it here as well. Properties are not applicable to connector of type 'OnPremises' with the current combination. - Micr...

Won't likely know anything until Microsoft responds or rolls back a change. 

[#3]

I've had confirmation from Microsoft that those connector properties are no longer, and have never been, applicable to on-premise type connectors. So although the UI is useless now, you only need to set affected properties to $false and then you may continue to edit them as required.

[#4]

Odd that they specifically call it out as a parameter in their PS example here: https://learn.microsoft.com/en-us/exchange/mail-flow-best-practices/use-connectors-to-configure-mail...

But with your comments in mind I do see how you can accomplish mostly the same functions as previous with Powershell. The only one that doesn't seem possible anymore is an IP address only Inbound OnPremises connector with RequireTls set to $true by itself. You must set a TlsSenderCertificateName as well but then the GUI shows that is the radial option selected so I guess there's probably a frontend release that supports these configurations in a more explicit fashion that's "yet to be released"?

[#5]

Yeah it seems they've only edited the articles available via the community/github. The others must be waiting for internal MS edits?
In my environments, you are able to create inbound connectors restricted to IP and certificate, but it seems that the respective RestrictDomainsToCertificate and RestrictDomainsToIPAddresses parameters are set to true always in the UI.
You can still set SenderIPAddresses and TlsSenderCertificateName in the UI.

It does seem that now if you're delivering via an on premise type connector, you must send via TLS, since you can't set it to false as that'll error out "partner connectors only".
This might cause issues for organizations delivering from on premise SMTP servers, who want to relay via 365 without TLS, a common scenario.

Wouldn't surprise me if they remove on-premise type connectors from the UI, since they're specialist scenario connectors, such as for in-line services (think Exclaimer or metadact).
In fact, as a result of this update, composite authentication is now calculated from emails delivered via on-premise connectors. Which is big new for vendors in that space.

[#6]

Looks like they reverted the PowerShell in some fashion. Old commands with Restrict... and the GUI are now working on previously affected tenants.

[#7]

Yeah I can now set to $true for those parameters too. PowerShell spec sheet remains the same, probably jumped ahead without the front end update and are waiting for that.
Or the server response that provides the error can't service it today due to the current network outage...