by

Guest Post: Migrating between email servers- SMTP Namespace Sharing (Part 2)

Fourth in our series of Guest posts by Exchange MVP’s is Clint Boessen, in the last post he explored the complexities of sharing an email domain- known as a SMTP namespace- essential when migrating between servers or running multiple mail servers. In this post he walks you through the technical steps needed to achieve this when migrating from 2003 to 2010.

Clint Boessen is an Exchange MVP from Western Australia focusing on Microsoft Business Productivity solutions.  Clint works for 4Logic Pty Ltd, an Information Technology and Consulting Company who is a Microsoft Partner predominately focusing on Microsoft.  Clint has a diploma in Network Engineering, an MCSE, MCITP and is currently working towards his MCM in Exchange Server. Clint maintains his own blog containing lots of hints, tips and tricks for IT Professionals which can be viewed at http://clintboessen.blogspot.com.

Part 2: Configuring SMTP Namespace Sharing between Exchange 2003 and Exchange 2010 organizations

Welcome to part two of this three part series on SMTP Namespace sharing. In part one of this series we had a look at what SMTP Namespace sharing is and how it can be configured across multiple email systems. If you missed part one of this series you may view it here Part 1: An overview on SMTP Namespace Sharing.

In part two we are going to look at how to configure SMTP Namespace Sharing between two Active Directory forests. One forest will run Exchange 2003; the other will run Exchange 2010. I have created a lab environment for our two forests which I have used to document the configuration steps. SMTP Namespace Sharing will be setup for @contoso.com.

SMTP Namespace Sharing on Exchange 2010

The first thing we need to configure in Exchange 2010 for SMTP Namespace sharing is the accepted domain. Accepted domains are any SMTP namespace for which an Exchange organization sends and receives e-mail for a given SMTP Namespace. Accepted Domains can be configured in one of 3 ways:

  • Authoritative Domain To specify that e-mail messages are delivered to a recipient that has a domain account in your Exchange organization, select this option.
  • Internal Relay Domain To specify that e-mail messages are either delivered to recipients in your organization or relayed to a server outside your Exchange organization but still under the authority of your company or IT department, select this option.
  • External Relay Domain To relay e-mail messages to an e-mail server outside the Exchange organization, select this option.

To configure SMTP Namespace Sharing for @contoso.com we must setup @contoso.com as an Internal Relay Domain.

Now that Exchange 2010 is able to accept email for @contoso.com provided we have our Receive Connectors configured correctly. Now we must create a Send Connector to route the email to the Exchange 2003 forest for any unresolved recipients. Follow the below steps for setting up the Send Connector:

Note: To achieve the correct routing behavior, you must specify a Hub Transport server as the source server for the Send connector. If the Edge Transport server is specified as the source server for the Send connector, a routing loop will occur.

  1. In Exchange Management Console under Organization Configuration à Hub Transport click New Send Connector on the action pane.
  2. Provide the Send Connector a descriptive name. The usage type determines the default permissions sets that are assigned on the connector and grants those permissions to the trusted security principals.
  • Internal Select this usage type if the e-mail system with which Exchange 2010 shares an address space is another Exchange 2010 organization
  • Internet Select this usage type if the e-mail system with which Exchange 2010 shares an address space is a third-party e-mail system.

Select Internet as the foreign email system is Exchange 2003.

  1. On the Address space page, click Add. In the SMTP Address Space dialog box, enter the domain name to which this connector will send mail, for example, contoso.com or *.contoso.com. You may select the Include all subdomains check box to use this connector to send e-mail to all subdomains of the address space. If necessary, you can also provide a specific cost for this connector. When you’re finished, click OK. Leave the Scoped send connector check box cleared, and then click Next.

  2. On the Network settings page, select Route mail through the following smart hosts. Click Add.
  3. In the Add Smart Host dialog box, select IP Address or Fully qualified domain name (FQDN) to specify how to locate the smart host. If you select IP Address, enter the IP address of the smart host. If you select Fully qualified domain name (FQDN), enter the FQDN of the smart host. The sending server must be able to resolve the FQDN. When you’re finished, click OK. To add more smart hosts, click Add, and repeat this step. If you want to use a specific list of external DNS servers instead of the DNS servers specified in the adapter settings, select the Use the External DNS Lookup settings on the transport server check box. When you’re finished, click Next.

  4. On the Configure
    smart host authentication settings page, select the method that’s used to authenticate to the smart host. The following smart host authentication methods are available:
  • None
  • Basic Authentication
  • Basic Authentication over TLS
  • Exchange Server Authentication
  • Externally Secured (for example, with IPsec)

Exchange 2003 by default automatically allows Anonymous email from all IP addresses on its internal subnet. As a result choose None under Authentication type.

Note: It is recommended to configure Basic Authentication over TLS in production environments.

  1. Click Next.
  2. On the Source Server page, click Add to add a source server. By default, the Hub Transport server that you’re currently working on is listed as a source server. In the Select Hub Transport or Subscribed Edge Transport dialog box, select the Hub Transport servers that will be used as the source server for sending messages to the shared address space. When you finish adding source servers, click OK. Click Next.

  3. On the New Connector page, review the configuration summary for the connector. If you want to modify the settings, click Back. To create the Send connector by using the settings in the configuration summary, click New.
  4. On the Completion page, click Finish.

SMTP Namespace Sharing on Exchange 2003

Configuring Exchange 2003 for SMTP Namespace sharing is very different to Exchange 2010. Exchange 2003 must be authoritative for the primary SMTP address space that is specified in the default recipient policy. Exchange 2003 does not have to be authoritative for any other SMTP address space configured on the default recipient policy. To configure SMTP Namespace sharing we must ensure Exchange 2003 is not authoritative for @contoso.com as this will not allow Exchange 2003 to forward unresolved recipients for @contoso.com to Exchange 2010. As Exchange 2003 must be authoritative for the primary SMTP address specified in the default recipient policy we must create a second recipient policy to set @contoso.com as primary and then click to clear the This Exchange Organization is responsible for all mail delivery to this address check box in the SMTP Address Properties dialog box. This creates the same effect as configuring “Internal Relay Domain” on an Exchange 2010 Accepted Domain shown above.

Currently my Exchange 2003 server has @contoso.com setup as my primary SMTP Address on my default recipient policy. As you see I am unable to unselect This Exchange Organization is responsible for all mail delivery to this address as it is the default policy.

We need to share the @contoso.com SMTP address space which is specified as the primary SMTP address space in the default policy. As a result we must create a new SMTP address space in the default recipient policy. The new primary SMTP address space that you create does not need to be valid in the Internet DNS. You can use a private SMTP address space such as @localhost or @example.local. In this lab environment we will be using the address space @source.local which Exchange 2003 will use to route internal e-mail messages.

Perform the following configuration on your default recipient policy.

  1. Start Exchange System Manager, click Recipient Policies, right-click Default Policy, and then click Properties.
  2. In the Default Policy Properties dialog box, click the E-Mail Address (Policy) tab, and then click New.

  1. In the New E-mail Address dialog box, click SMTP Address, and then click OK.
  2. In the SMTP Address Properties dialog box, type the SMTP address space for which you want Exchange to be authoritative.
  3. Click to select the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK.

  4. Click the new SMTP address that you created, and then click Set as Primary.
  5. Remove the SMTP address that you want to share from the default recipient policy. To do this, click the SMTP address that you want to share, and then click Remove.

Now create a new recipient policy to be used for SMTP Namespace sharing.

  1. Create a new recipient policy for the shared SMTP address space. To do this, right-click Recipient Policies, point to New, and then click Recipient Policy.

  1. In the Properties dialog box, type a name for the new recipient policy, click Modify, and then click OK.

  2. Click the E-Mail Addresses (Policy) tab, and then click New.

  3. Click SMTP Address, and then click OK.
  4. In the Address box, type the SMTP address space that you want to share. For example, type @example.com, or type @microsoft.com. In this lab we used @contoso.com.
  5. Click to clear the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK.

  6. Click the new SMTP address that you created, and then click Set as Primary.

  7. Click OK, and then click Yes when you receive the following message:

    Note: If you use the above procedure and update user SMTP addresses using a recipient update policy, ensure a system state backup of Active Directory is performed on a domain controller before commencing the changes. ADModify.NET is an alternative way for updating user SMTP email addresses if the recipient update service is disabled. This is often the preferred way of performing the task as ADModify.NET allows you to revert changes.

After you configure the recipient policy for SMTP Namespace sharing, you must specify the means for Exchange to determine where to route messages that do not resolve to an object in Active Directory. To do this, create an SMTP connector that has the shared SMTP address space in the Add Address Space dialog box of the connector object. If you do not add the SMTP connector with the shared address space, any incoming e-mail that is destined to the shared SMTP address space is interpreted as an attempt to relay. In this situation, Exchange does not accept the incoming e-mail. Additionally, you must specify a server to which Exchange will forward unresolved e-mail. You can specify this destination server by using its host name or by using its IP address.

Perform the following steps to create the SMTP connector.

  • In Exchange System Manager, right-click Connectors, point to New, and then click SMTP Connector.

  • In the Properties dialog box, type a name for the new connector in the Name box.
  • Click Forward all mail through this connector to the following smart hosts, and then type the host name of the destination computer or the IP address of the destination computer. You must type square brackets ([ ]) around the IP address. For example, if the IP address of the destination computer is 192.168.1.10, type [192.168.1.10]. In this lab the destination smart host is Ex2010.destination.local. Hostnames do not require brackets around the name.

    This computer will receive all e-mail that is not resolved to objects in Active Directory.

  • Click Add, click an Exchange server in the Add Bridgehead dialog box, and then click OK.

  • Click the Address Space tab, click Add, click SMTP in the Add Address Space dialog box, and then click OK
  • In the Internet Address Space Properties dialog box, type the shared SMTP address space in the E-mail domain box. When you type the shared SMTP address space, do not include the at (@) symbol. For example, type example.com in the E-mail domain box. Then, click OK. In the lab environment we added contoso.com.
  • Click to select the Allow messages to be relayed to these domains check box. Because Exchange must also receive messages for the shared e-mail address space, you must let Exchange relay messages to this domain. This setting let’s all the SMTP virtual servers that are listed under Local bridgeheads on the General tab accept messages for the shared e-mail address space.

  • Click OK.
  • This email will be coming into Exchange 2010 from anonymous. A receive connector needs to be setup on the Exchange 2010 server to allow anonymous emails to come from the IP addresses of the Exchange 2003 servers in the source forests. For information on how to do this please see:

    http://clintboessen.blogspot.com/2009/07/allow-network-applications-to-relay.html

SMTP Namespace sharing is now configured between both Exchange 2003 Active Directory and Exchange 2010 Active Directory forests. There is another method for configuring SMTP Namespace sharing on Exchange 2003. This method involves modifying the SMTP virtual server under “Forward all mail with unresolved recipients to host”.

I do not recommend this method for two reasons.

  • It does not stamp the message header which can result in mail loops.
  • If you have any users accounts in the Exchange 2003 forest with the Exchange attributes associated to the account but no mailbox, whenever a user in the Exchange 2003 forest sends an Exchange enabled user account an NDR will be generated stating “A configuration error in the e-mail system caused the message to bounce between two servers or to be forwarded between two recipients. Contact your administrator“. It is not smart enough to realise the user does not have a mailbox and to forward it to Exchange 2010. In Exchange users that have Exchange attributes enabled but no mailbox are known as “Mail users” whereas users that have mailboxes are known as “Mailbox users”. There are times you want Mail users and not Mailbox users. When we perform cross-forest mailbox migration the source user account will revert to a “Mail User” and will still contain the Exchange 2003 attributes. These attributes and SMTP email address are important for keeping the GAL (Global Address List) populated in the source domain.

This concludes part two of this three part series. In part three we will be setting up SMTP Namespace Sharing between Exchange 2010 on-premises and Office 365 in the cloud.

  • Erndog5800

    I’m a little confused by this.  On the Exchange 2010 Configuration side, how do you distinguish between the SMTP connector to the outside world and the SMTP connector to the 2003 server, or any server you want to send unresolved recipients to? Aren’t the two SMTP connectors essentially identical, with the exception of the smarthost?   There’s nothing to say, “if it is an unresolved recipient, use connector B instead of Connector A”..