During an upgrade of Exchange Server 2013 to a new cumulative update some customers may experience an issue where setup fails, leaving the server in a non-operational state.

The error thrown by setup is:

Mailbox role: Transport service FAILED

The following error was generated when “$error.Clear();

$connectors = Get-ReceiveConnector -Server $RoleFqdnOrName;

foreach($connector in $connectors) { if($connector.MaxLocalHopCount -gt 1) { Set-ReceiveConnector -Identity $connector.Identity -MaxLocalHopCount 5 }};

” was run: “Microsoft.Exchange.Management.SystemConfiguration Tasks.ReceiveConnectorRoleConflictException: The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector “EX2013SRV2Test”. Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.

This error is caused by a receive connector conflict. When the error occurs setup stops, but unfortunately it has already removed the previous build of Exchange in readiness to install the newer build. So the server is left in a completely non-operational state.

In this article I’ll explain:

Why this error occurs in the first place

How to fix it so that you can run setup again to repair your failed server

How to check for this problem before you try to run a cumulative update

Why This Error Occurs in the First Place

The reason that this error occurs is that the server has two (or more) receive connectors bound to different transport services that are trying to listen on the same IP address and port number. My fellow Exchange MVP Andrew Higginbotham has a very detailed explanation of this here.

Every Exchange 2013 or Exchange 2016 server is configured with a set of default receive connectors that follow a standard naming convention that includes the server name.

Three default receive connectors are homed on the Front End Transport service:

Default Frontend SERVERNAME – this connector listens on TCP port 25 to accept SMTP connections, and acts as the entry point for email into the Exchange organization. It is pre-configured to perform that role, and there are few scenarios in which modifying this connector is appropriate. As a general rule I recommend you do not disable, modify, or remove it. Think of this receive connector as the connector of last resort.

Client Frontend SERVERNAME – this connector requires client authentication, accepts secure SMTP connections (with TLS applied), and listens on port TCP 587.

Outbound Proxy Frontend SERVERNAME – this connector listens on TCP port 717 and is only used when a send connector is configured to proxy outbound email through the front end servers or services. This is an optional configuration, and not very common.

Two default receive connectors are homed on the Transport service:

Default SERVERNAME – this connector accepts connections from other Mailbox and Edge Transport servers using TCP port 2525. Clients do not connect directly to this connector, and there are no reasons for you to ever disable, modify, or remove this connector.

Client Proxy SERVERNAME – this connector accepts connections from Front End Transport services on the same server, or on other servers, using TCP port 465. Again, clients do not connect directly to this connector, and you should not disable, modify, or remove it.

You should not modify or remove the default connectors. Any other connectors on the server are likely to have been manually created, and that’s where the problem can occur. The short version is that when creating the receive connector the wrong transport role was chosen.

“Hub Transport” is the wrong choice here. Unfortunately it is also the default choice, and a lot of Exchange admins experienced in previous versions of Exchange would recognise “Hub Transport” as the role where a receive connector would have been created. However, there is no “Hub Transport” role in Exchange Server 2013, nor is there a service called “Hub Transport”. You could argue that “Hub Transport” shouldn’t even be an option in that particular dialog.

Fortunately the most recent builds of Exchange Server 2013 (SP1 and above, from what I’m told) contain logic to prevent an administrator from choosing the wrong option and causing the connector conflict.

Of course, that doesn’t help customers who have perhaps deployed the RTM version of Exchange Server 2013 first, and then later tried to upgrade to the latest CU. This is more common than you might think it would be, due to some customers acting with the incorrect assumption that the RTM build needs to be deployed first before any service packs or cumulative updates are applied.

Those customers, if they happen to have created conflicting receive connectors, are going to have a bad day when they upgrade. So let’s look at how to fix it.

How to Fix it so You Can Run Setup Again to Repair Your Failed Server

For organizations with multiple Exchange 2013 servers the fix is simpler, because you can still access the Exchange Admin Center on one of the operational servers. In mail flow -> receive connectors you can select the non-operational server and see the list of connectors on that server. In this example the connector named “Test” is highlighted, and you can see that it is bound to the “HubTransport” role.

That same connector name was in the error that was thrown by setup earlier, which is how you know which connector(s) to look for.

The values that you specified for the Bindings and RemoteIPRanges parameters conflict with the settings on Receive connector “EX2013SRV2Test”. Receive connectors assigned to different Transport roles on a single server must listen on unique local IP address & port bindings.

To change the role for the connector open the Exchange Management shell and run Set-ReceiveConnector as follows.

[PS] C:\>Set-ReceiveConnector EX2013SRV2Test -TransportRole FrontendTransport 1 [ PS ] C : \ & gt ; Set - ReceiveConnector EX2013SRV2Test - TransportRole FrontendTransport

For single server organizations it’s a little tricker. With no operational Exchange 2013 servers the management tools can’t be used. Instead we need to dive into ADSIEdit.msc to fix the connector. Launch ADSIEdit.msc and connect to the “well known Naming Context” of Configuration.

The receive connector objects can be found in Configuration -> Services -> Microsoft Exchange -> Your Organization Name -> Administrative Groups -> Exchange Administrative Group (FYDIBOHF23SPDLT) -> Servers -> Server Name -> Protocols -> SMTP Receive Connectors.

The attribute we’re interested in is the msExchSmtpReceiveRole. In the example below are two receive connectors. The one on the left has the role attribute set to 16384, which is Frontend Transport. The one on the right is set to 32, which is Hub Transport.

Modify the value from 32 to 16384 on your receive connector and then apply the change.

After taking either of the corrective actions above re-run the cumulative update and setup should proceed past the failed step and complete successfully.

How to Check for this Problem Before Running an Update

As I mentioned earlier there is logic in current builds of Exchange Server 2013 that should prevent this issue from occurring in future, but for those of you reading this who are planning to upgrade from a very early version of Exchange 2013 you might be concerned and want to avoid the problem entirely. There are two ways to do this.

The first is to simply open your Exchange Admin Center and look at the receive connectors on your servers. If you see custom connectors that you’ve created and that are bound to the Hub Transport role then you can pro-actively apply the Set-ReceiveConnector fix demonstrated above and you should be fine from there.

If you’re still unsure then you can simply run the same PowerShell commands that setup is executing when it throws the error. I’ve adjusted them slightly here for readability and added the -WhatIf switch so that Set-ReceiveConnector doesn’t make any actual changes to your configuration.

$connectors = Get-ReceiveConnector; foreach($connector in $connectors) { if($connector.MaxLocalHopCount -gt 1) { Set-ReceiveConnector -Identity $connector.Identity -MaxLocalHopCount 5 -WhatIf } } 1 2 3 4 5 6 7 8 $ connectors = Get - ReceiveConnector ; foreach ( $ connector in $ connectors ) { if ( $ connector . MaxLocalHopCount - gt 1 ) { Set - ReceiveConnector - Identity $ connector . Identity - MaxLocalHopCount 5 - WhatIf } }

Pasting those lines into the Exchange Management Shell and pressing enter will check all of the receive connectors in your org for the conflict.

Read the errors carefully though, because it will throw one for your mis-configured connector but also for other default connectors that are not mis-configured. Obviously you should only apply the fix to your custom connector and not modify any of the default connectors on the server.

Summary

As you can see this is an unfortunate error condition that has quite a severe impact on Exchange 2013 servers during an upgrade. In particular, single server organizations are left with no operational servers at all after this error occurs. Hopefully anyone in that situation will be able to quickly find the solutions demonstrated in this article and get their server up and running again.