Thursday, May 22, 2014

Exchange 2013 (SP1) - Migration - Part 8 - Mail flow

Send and Receive Connectors

We had already determined, in a previous post, that internal mail flow is functional. Users of my organization can send (and receive) mail to (and from) each other.

In fact, there are "implicit" connectors that manage mail flow that is internal to the organization. These connectors are not visible in the administrative interfaces and do not need to be configured.

Inbound and outbound mail flow (to and from the rest of the world) requires some additional configuration.

Send Connecter (outbound messages)

Outbound mail flow is the most simple. One or more "send connectors" regulate mail flow in this direction. Send connectors exist at the "organizational level" and are stored in the Active Directory configuration partition (with other Exchange related settings). In other words, send connectors are not "server-specific" and do not need to be recreated when a new server is added or in the context of a migration.

I thought I could simply send a message to an external recipient without any additional configuration. The message never arrived.

In fact, we do need to make one adjustment to the send connector: add the new server (in our case, the Exchange 2013 server) to the "source servers" attribute.

This is the procedure if we prefer the Exchange Admin Center:

In the image above, only the Exchange 2007 server (EX1) is present.

So we click on the plus sign "+" and add the Exchange 2013 server (EX13-1):

That leaves us with this:

Now I can send a test message to an external recipient.

So this single adjustment was all that was required in my environment. Other situations may be different. For example, if the firewall blocks outbound SMTP traffic except for messages sent from the existing mail server (the Exchange 2007 server, for example), another exception would have to be made for the new Exchange 2013 server.

Otherwise, if we prefer the EMS, we could use this cmdlet:

Set-SendConnector MYNET-SendConn-1 -SourceTransportServers EX13-1

However, we then loose the Exchange 2007 server (EX1):

Get-SendConnector | fl SourceTransportServers

SourceTransportServers : {EX13-1}

What happened?

The cmdlet above overwrites the existing settings and only includes the servers indicated.

If I want both servers, I have to indicate both, even if one is already indicated:

Set-SendConnector MYNET-SendConn-1 -SourceTransportServers EX13-1,EX1

Get-SendConnector | fl SourceTransportServers

SourceTransportServers : {EX13-1, ex1}

Receive Connector (inbound messages)

In previous versions of Exchange, the default Receive Connector permissions did not allow mail from anonymous senders (users from another organization, for example). It was necessary to check the appropriate box as shown below:

That is the view in the Exchange 2007 EMC. We can see these settings from the Exchange 2013 EAC as well (remember to designate the Exchange 2007 server - EX1 in my case):

Perhaps because this default setting complicated Exchange installations for less experienced administrators (I've seen it mentioned in more than one Technet forum discussion), Microsoft enabled the equivalent setting in Exchange 2013:

Yes, the equivalent connector in Exchange 2013 is called "Default Frontend (name of server)". There are more connectors in Exchange 2013 than in Exchange 2007. However, for a default installation, we do not have to know the specific details of each connector. In fact, we do not have anything to configure here (for a default installation, once again). The server will accept inbound mail from external sources as is, since "Anonymous users" is already checked:

As mentioned previously, I was able to send test messages between users in my organization even before configuring any send or receive connectors. Before sending to and from the Internet (using a Gmail or account, for example), I had to adjust settings on my firewall. In particular, I had to adjust IP addresses so mail traffic would be directed to the Exchange 2013 server (EX13-1) rather than the Exchange 2007 server (EX1). I will not provide details of those changes since they would be useless for anyone using a different type of firewall.

It might also be necessary to adjust external DNS settings, expecially if Exchange 2007 and 2013 coexist for a certain time. In my case, however, I will perform a rapid migration of all the mailboxes at once, without any coexistence between the two versions of Exchange. In that case, changing the DNS records so they point to the Exchange 2013 server should be enough. Otherwise, we would still change those records BUT ALSO add a so-called "legacy" entry for the Exchange 2007 server.

So, for internal DNS, we would have something like this:


- is the IP address of the Exchange 2013 server.

- is the IP address of the Exchange 2007 server.

The allows Exchange to proxy or redirect connections from the Exchange 2013 server to the Exchange 2007 server, notably for users whose mailbox is still located on the older server.

We would also adjust external DNS records (hosted by our ISP or a domain name registrar) but those entries would point to the external (Internet facing) IP address of our firewall.


So, in summary, we ensure mail flow in and out of the organization by configuring what follows:

  1. Send and Receive connectors (if they are not configured correctly by default).
  2. Firewall settings (1 to 1 NAT in particular).
  3. DNS records.

For testing, we can:

  1. Send a message TO an external email account (Gmail,
  2. Send a message FROM an external email account.

I have been able to do both consistently the last several days.


  1. This comment has been removed by the author.

  2. Nice Explainer. I've had good experience with EdbMails Edb to PST recovery tool - which provides a complete solution to recover Exchange Database (EDB) files. It is quick and uses deep scan to recover most data out of even corrupted databases.It supports public, private folder recovery. And also supports migration to Live exchange and Office 365. Archive mailbox migration is also supported by edbmails

  3. Great article, it provides the helpful information related to migrate exchange server 2003 to exchange server 2013. but I found the automated solution ( ) that provides the facilitate to migrate user mail boxes,and other settings to exchange 2013. This tool fully supports migrations through domain and forest relationships. It allows to select what items and attribute are migrated and chose folder type in the connection wizard to process only select items suchas emails, tasks, contacts, notes, journals and calendar appointments.