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 “EX2013SRV2\Test”. 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.
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 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 “EX2013SRV2\Test”. 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 EX2013SRV2\Test -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
}
}
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.
This article Exchange Server 2013 Upgrade Fails Due to Receive Connector Conflicts is © 2015 ExchangeServerPro.com
Get more Exchange Server tips at ExchangeServerPro.com
