I was recently helping out on a migration from Exchange 2003 to Exchange 2010. The organisation was moving from two servers, a front end and back end server to four with two Mailbox servers running in a DAG (Database Availability Group) configuration and two Client Access Servers in an array and along with Hub Transport roles on the two CAS Servers. They had been running their Exchange 2003 server for a while with routing connectors setup so the 2003 machine was handling all of the external mail and it had finally come time to decommission the old server and tell the firewall to push e-mail to the two new Hub Transport servers.
By default, Exchange 2010 sets up two connectors, one Client SERVERNAME and Default SERVERNAME with the default connector handling your external e-mail. For external servers to connect to the connector we need to enable anonymous authentication for the connector. So we went ahead, opened up the connector and ensured the Anonymous was ticked, clicked apply for good measure and then Ok. After using telnet to remotely connect to the e-mail server (via 3G) we received a Client not authenticated message after giving it the mail from command. So it was clear to me that the EMC (Exchange Management Console) wasn’t saving the authentication settings. So we resorted to PowerShell to configure the connector. I opened up the Exchange Management Shell and issued the following command
Get-ReceiveConnector -identity "Default SERVERNAME" | list
The list contained everything that was ticked bar the Anonymous that we had just enabled. So we decided to run a Set command to update the permissions list for the Default connector. I issued the following command with SERVERNAME being the name of the Exchange Server hosting the connector
Set-ReceiveConnector "Default SERVERNAME" -PermissionGroups:"ExchangeUsers, ExchangeServers, ExchangeLegacyServers, AnonymousUsers"
We then ran the Get command again and the Anonymous entry was listed. So after a few minutes we used 3G and telnet to connect back into the e-mail server and after getting passed the mail from command we were relieved that the issued was resolved and that the servers could now accept incoming external e-mail. Microsoft have a good article up on Tech Net regarding Exchange 2010 and the Receive connectors (as well as the defaults Exchange setup creates) at the following article Understanding Receive Connectors.
Note that you won’t receive this issue if your transport server is an Edge transport server as Exchange setup automatically configures the connectors for external connections.
Leave a Reply