Configuring SMTP Namespace Sharing between two Exchange Forests – Part 3

We have already started the series of the post by explaining the scenario and getting ready with our prerequisites beforehand. In Part 3 of this series we will be going through the below points mentioned in the first post:

  • Configuring shared SMTP Namespace as an Accepted Domain
  • Creating Connectors on the Hub Servers
  • Resolving Routing Loops

Configuring shared SMTP Namespace as an Accepted Domain

In Microsoft terminology, Accepted domain is an SMTP namespace for which a Microsoft Exchange organization handles the mail delivery. An Accepted Domain can be of the following three types:
– Authoritative: An Authoritative Domain is a SMTP domain for which the Exchange organization hosts its mailboxes.
– Internal Relay: An Internal Relay Domain is a SMTP domain for which the Exchange organization does not host some or all the mailboxes.
– External Relay: An External Relay Domain is a SMTP domain for which the Exchange organization does not host any mailboxes. The Exchange Organization acts as a Relay or SmartHost for that SMTP Domain.

We will be configuring the shared SMTP Namespace as an Internal Relay Domain. Configuring the shared SMTP namespace domain to be an Internal Relay will allow the email messages to be accepted in the Hub Transport Role. If the Recipient mailbox exists then the mail will be delivered to the recipient mailbox via the Mailbox Server role. If the recipient mailbox does not exist in the forest then the Hub Server will search for the existance of a Send Connector for the shared SMTP namespace domain. The Email will be delivered to the Hub Server role of the target forest via the Send Connector. If no Send Connector exists for the shared SMTP namespace domain, then a Non-Delivery Report (NDR) will be sent to the Sender informing the failure to deliver the message.

To add the shared SMTP Namespace as an Accepted Domain in the Exchange infrastructure of each forest, navigate to the Organization Configuration of Exchange Management Console and select the Hub Server role.

From the Actions pane on the right, under the Hub Transport select the New Accepted Domain to configure an accepted domain.

This will invoke the New Accepted Domain wizard. In the Name field enter any descriptive name for the accepted domain and in the Accepted Domain field enter the exact shared SMTP namespace, in our scenario it is DOMAINC.COM. Click on New to start the configuration.

The Completion screen on the New Accepted Domain wizard will be displayed showing the successfull creation of the accepted domain. Once done, click on Finish to end the wizard.

Remember to add the shared SMTP namespace as an Accepted Domain in both the Exchange infrastructures and also specify the shared SMTP namespace as an Internal Relay domain.

If Edge Server is used at the Gateway, then the accepted domains list will automatically be updated on the Edge Servers on the next Edge Synchronization. If however some other third-party SMTP Gateway solution is used, then modify the configuration to reflect the new shared SMTP namespace as an accepted domain on that gateway. Refer to the product documentation to get things configured on your SMTP gateway.

Creating Connectors on the Hub Servers

Exchange uses Connectors to route mails internally and externally. Send Connectors are used by the Hub Servers to send mail and Receive Connectors are used by the Hub Servers to receive mail. We need to define connectors to send or receive emails from the internet. Using connectors, we also need to specify if any domain has some special SMTP routing needs – like routing emails between two organizations.

In Part 2 of this series, I had provided a mail flow diagram that shows the Connectors which we will be configuring to achieve the sharing of a single SMTP namespace across organizations.

For the purpose of SMTP Namespace sharing between two domains, we have to create the send connectors as mentioned in the below table:

There might be someone asking this question – Why do we want to route the secondary namespaces of the remote domain using a new Send Connector? My answer would be that it is completely optional to do this. But at the same time, if you are working in a merger scenario like this one and if you have a dedicated connectivity between the two domains then why to route the emails over Internet. It makes complete sense to avoid Internet in such cases. Note that the Send Connector for secondary namespaces will only be used to send emails from your organization to the secondary namespaces of the remote domain. The delivery path from Internet for these namespaces will remain unchanged as their mail (MX) records still point to their SMTP gateways directly.

Creating Send Connectors using the information in the above table will be a cakewalk. But for demonstration purposes, I will be showing the creation of the first Send Connector. To configure a Send Connector on DOMAINA, navigate to the Organization Configuration of Exchange Management Console and select the Hub Server role. From the Actions pane on the right, under the Hub Transport select the New Send Connector to configure a new Send Connector.

This will start the New SMTP Send Connector wizard. In the Name field enter any descriptive name for the Send Connector. The name field of the Send Connector is very vital for troubleshooting message tracking logs in Exchange. In Select the intended use for this Send Connector field, enter the type as Internet.  Click on Next to continue the configuration of the connector.

In the Address space screen of the New SMTP Send Connector wizard, click on Add to specify the address space to which the connector will route the mails. While the Address space type is SMTP, enter the address as DOMAINC.COM with the Cost as 1. Click on OK to complete the addition of the address space for this send connector.

You can verify the addition the Address space. Later when you configure the Send Connector for secondary namespaces, you might be required to add more address spaces. In that case, you will be required to click on Add again to add the additional namespaces one-byone. As we are limiting this Send Connector to the primary (shared) SMTP namespace, we can proceed by clicking on Next to continue.

In the Network Settings screen of the New SMTP Send Connector wizard, select Route mail through the following smart hosts. Click on Add to add the remote Mail Servers to which the address space mails will be routed. You can either add the IP Addresses or the FQDNs of the Mail Servers. If FQDNs need to be added, ensure that the names are resolvable to the right IP addresses on the remote domain. If not, you might be required to allow the DNS communication and set-up the forwarders for the remote domains. Once the Mail Servers have been added, click on Next to proceed.

In Configure smart host authentication settings screen of the New SMTP Send Connector wizard, click on None. This will relay mails to the Mail servers of the remote domain without any authentication. Click on Next to proceed.

In the Source Server screen of the New SMTP Send Connector wizard, add the source Hub Servers that will be responsible for handling the mail delivery to this Send Connector. The Hub Server on which the New SMTP Send Connector wizard is executed is added by default. You can add the other Hub Server nodes by clicking on Add. When finished adding the Hub Servers, click on Next to continue.

In the New Connector screen of the New SMTP Send Connector wizard, verify the summary of the configuration. You can click on New to finalize the configuration and create the Send Connector.

On Completion screen,  the results will be shown indicating the success or failure of the command. Review the successful completion summary of the wizard and then click on Finish to complete the process.

After the Send Connector has been created, you will need to add the FQDN response this Send Connector will provide in response to the SMTP requests. By default, the FQDN is null.

Follow the steps shown above to create other Send Connectors as mentioned in the table earlier. After all the connectors have been created successfully, the Hub Servers will become intelligent enough to send emails to the remote domain on the shared SMTP namespace.

The next step will be to configure the Hub Servers to receive email from the remote domains. This is where Receive Connectors will come into picture.  If Receive Connectors are not configured, mail delivery failures will occur and users might receive Non-Delivery Report (NDR) indicating “5.7.1 Client was not authenticated”.  To resolve such mail delivery issues, create a Receive Connector on each Hub Transport server to accept mail from the Hub Servers in the remote domain.

To receive mails from the remote domains, we have to create the Receive Connectors as mentioned in the below table:

We will be going through the creation of the first send connector and the rest should be created using similar procedure. To create a Receive Connector, navigate to the Server Configuration of Exchange Management Console and select the Hub Server role. Select the Hub transport server role for which the recieve connector needs to be created. While the server is selected, go to the Actions pane on the right, under the Hub Server name select the New Receive Connector to create a new Receive Connector.

This will invoke the New SMTP Receive Connector. On the Introduction screen of the wizard, enter any descriptive name for the Send Connector in the Name field. In Select the intended use for this Receive Connector field, enter the type as Internet.  Click on Next to continue the configuration of the connector.

On the Local Network settings of the New SMTP Receive Connector wizard, click on (All available IPv4 Addresses) and then click on Edit to specify the IP Address on which the Hub Server role will receive email.

In Edit Receive Connector Binding screen, select Specify an IP address option and enter the IP Address on which you wish to configure the Hub Server to receive mails. This IP Address can either be Hub Server NLB or a physical IP on the server NIC which is configured to receive mail.

In the Local Network settings screen of the New SMTP Receive Connector wizard, verify the new IP Address that has been edited on the Receive Connector. Specify the FQDN that will be used as a response to the SMTP communication and then click on Next to continue.

In the New Connector screen of the New SMTP Receive Connector wizard, verify the summary of the configuration. You can click on New to finalize the configuration and create the Receive Connector.

On Completion screen,  the results will be shown indicating the success or failure of the command. Review the successful completion summary of the wizard and then click on Finish to complete the process.

This process will create a Receive Connector of the type Internet. By default, this Receive Connector will be used for all connections.

We have to modify the behaviour of this Connector to allow only the Hub Servers of the remote domain to relay email. This can be done on the Network tab of the Receive Connector properties. Remove the default range and manually add the IP Addresses of the remote Hub Servers.

On the Authentication tab of the Receive Connector properties, uncheck the Transport Layer Security (TLS) option.

On the Permissions tab, verify that only the Anonymous users option is selected. If Receive Connector is created of the type Internet, then by default only Anonymous users will be selected. Click on OK to apply the changes and close the Receive Connector Properties.

Follow the exact procedure mentioned above to create a Receive Connector on all the Hub Servers in the domain. Depending on the Exchange architecture, you might have to enter physical Hub Server IPs or the Hub NLB IP in the Network tab option Use these local IP Addresses to receive emails of the Receive Connector.

The above procedure will create a Receive Connector which will listen on a specific Hub Transport IP and will allow anonymous users from the remote Hub Servers to connect to the Receive connector.  We still have to configure this Receive Connector to relay mails from the remote Hub Servers.

Once the Receive Connectors have been created on all the Hub Servers for accepting mails from the remote domains, you will have to allow relaying on these connectors. In order to do allow relaying, execute the following command from the Exchange Management Shell

Get-ReceiveConnector -Identity ‘DOMAINAHUB1\Inbound – DOMAINB to DOMAINA’  | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Get-ReceiveConnector -Identity ‘DOMAINAHUB2\Inbound – DOMAINB to DOMAINA’  | Add-ADPermission -User “NT AUTHORITY\ANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”

Similar Receive Connectors have to be created on the Hub Servers of the Remote Domain and these connectors have to be allowed to relay emails through their local Hub Servers. Refer to the table that lists the Receive Connectors  that have to be created on each Hub Server.

Resolving Routing Loops

Manyatimes the mail received by an Exchange organization, is delivered to remote Exchange organization for mail delivery as the target recipient is not found in its Exchange organization (Internal Relay Domain behaviour). The mail is received in the remote Exchange organization and delivery is attempted but as the target recipient is also not found in this Exchange organization, the mail is returned back to the source Exchange organization (Internal Relay domain behaviour). The source Exchange receives the Email and retries the same path causing an loop to occur. Routing loops are more common in scenarios where a single namespace is shared across multiple domains. Though Exchange architecture has the provision of handling routing loops but in such scenarios routing loops can keep the Exchange servers really busy.

DOMAINC.COM is configured as Internal Relay Accepted Domain on both the domains. We have the mail flow scenario as shown below:

Consider the scenario when the DOMAINC.COM mail is accepted by DOMAINA Exchange organization. The Exchange organization will perform a recipient check and if the recipient exists, the mail will be forwarded to the organization’s Mailbox Server which will store the mail in the user’s mailbox. If the recipient does not exist in DOMAINA, the Exchange will search for the presence of a Send Connector which handles routing for the address space DOMAINC.COM. If no send connector is found, Exchange will generate an NDR to the Sender. But if a Send Connector exists, the mail will be forwarded to the remote domain DOMAINB.COM. The Exchange organization for DOMAINB.COM will perform a recipient check and if the recipient exists, the mail will be forwarded to the organization’s Mailbox Server which will store the mail in user’s mailbox. If the recipient does not exist in DOMAINB.COM, Exchange will search for the presence of a Send Connector which handles mail routing for the address space DOMAINC.COM. If no send connector is found, Exchange will generate an NDR to the Sender. But if the Send Connector exists, the mail will be forwarded back to the remote domain DOMAINA.COM. This causes a Routing Loop.  The same scenario will occur when the mail is accepted by DOMAINB Exchange organization and the recipient does not exist in either DOMAINB or DOMAINA Exchange organizations. Therefore a mechanism should be configured to detect the first loop and avoid further occurances of it by configuring an NDR to be sent to the Sender.

Mischa Oudhof has written an excellent article that handles mail routing loop issues in a Shared Namespace scenario like ours. The article can be found here.

As the process of creating Transport Rules is well documented, I would recommend you to refer the article for creating the required rules. For verification purposes, I have summarized the Transport Rules that need to be created on each domain in the below table.

At this point the Exchange organization on both sides is ready to share and route mails over a single SMTP namespace which acts as primary in both the Exchange organizations. But note that we have still not done any changes to the Email Address policy. Before we enable the recipients to communicate over the shared domain, we still have to get few other things configured. These configurations will be covered in the forthcoming parts of this series.

Summary

In this post we have covered the major elements related to the Hub Transport Server configuration that will be required to have a common SMTP Namespace shared between two Forests. We went though the creation of an Accepted Domain followed by creation of Send Connectors and Receive Connectors to handle mail routing between the two Exchange organizations. We also discussed about mail routing loops and how to resolve them. Going forward in this series, we will be implementing the email policies and enabling the clients in both domains to share a single SMTP namespace.

Click on the below link to access the different series parts:
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 1
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 2
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 4
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 5
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 6 (Not Live)
Configuring SMTP Namespace Sharing between two Exchange Forests – Part 7 (Not Live)

4 responses to “Configuring SMTP Namespace Sharing between two Exchange Forests – Part 3

  1. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 2 | Ibrahim Nore's Blog

  2. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 4 | Ibrahim Nore's Blog

  3. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 5 | Ibrahim Nore's Blog

  4. Pingback: Configuring SMTP Namespace Sharing between two Exchange Forests – Part 1 | Ibrahim Nore's Blog

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s