Forum Discussion
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...
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.
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.
Looks like they reverted the PowerShell in some fashion. Old commands with Restrict... and the GUI are now working on previously affected tenants.
- 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...