Forum Discussion
liamherbert1105
Jul 29, 2024Copper Contributor
Create/Edit On-Premise type inbound connector in UI after cmdlet update
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.Manage...
Matt-Sywulak
Jul 29, 2024Copper Contributor
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. - Microsoft Community Hub
Won't likely know anything until Microsoft responds or rolls back a change.
- liamherbert1105Jul 30, 2024Copper ContributorI'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.
- Matt-SywulakJul 30, 2024Copper Contributor
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-flow/integrate-office-365-with-an-email-add-on-service#use-exchange-online-powershell-to-create-an-inbound-connector-to-receive-messages-from-the-email-add-on-service
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"?- liamherbert1105Jul 30, 2024Copper ContributorYeah 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.