Split domain with Exchange 2003 as Primary

Split domain with Exchange 2003 as Primary

   KB 15229        Last updated on 2015-08-25  




0.00
(0 votes)

Introduction

This document describes methods and procedures for setting up a split-domain configuration for a Microsoft Exchange 2000 or 2003 server and a Zimbra Collaboration Suite (ZCS) server running 5.0.15 or higher. While multiple configurations work, this document will describe the split domain configuration with Exchange as the primary and ZCS as the secondary mail servers.

Split Domain Explanation and Overview

This information has been extracted from the Microsoft KB Article 321721 and wiki articles posted on www.zimbra.com.

The Split Domain configuration for email delivery provides for email users in a single domain to reside on different email providers and allows for incremental migrations from a legacy provider to a new platform. During the migration process, one system is designated as the “primary” mail store and is responsible for receiving and routing mail for the domain (zm-train.com). The other system is considered the “secondary” mail store. The following use cases must be handled to ensure email is properly delivered, presuming an Exchange to Zimbra migration.

Use Cases

  • Internet to User on Exchange Server
  • Internet to User on Zimbra Server
  • Exchange User to Exchange User
  • Exchange User to Zimbra
  • Exchange to Internet
  • Zimbra User to Zimbra User
  • Zimbra User to Exchange User
  • Zimbra User to Internet


The Split Domain configuration requires that you share the same SMTP address space between two or more different e-mail systems. In this situation, users in each e-mail system have the same domain suffix as part of their e-mail addresses (zm-train.com) .

For the purposes of this document, the terms "address space" and "domain" are used interchangeably. This article is written from the perspective that the Exchange server is the incoming SMTP gateway from the Internet. When Exchange receives an incoming SMTP message from the Internet, Exchange first tries to resolve the e-mail addresses that are displayed in the recipient fields to objects in Active Directory. If the e-mail address resolves to an Exchange mailbox, Exchange routes the message to the mailbox. If the e-mail address does not resolve to an Exchange mailbox, Exchange routes the message to the e-mail system with which the SMTP address space is shared. The receiving e-mail system (Zimbra) then delivers the message to a local mailbox, or it generates a non-delivery report (NDR) delivery status notification (DSN) message. The e-mail system with which the SMTP address space is shared cannot forward the unresolved recipients back to the Exchange incoming SMTP gateway. If you configure the last e-mail system that is in an e-mail system chain to forward unresolved recipients to the incoming e-mail gateway, you will have a messaging loop in which e-mail messages may continuously loop between e-mail servers.

Only one e-mail system can be authoritative for a particular SMTP address space. When an e-mail system is non-authoritative for an SMTP address space, the e-mail must eventually be routed to an e-mail system that is authoritative for the SMTP address space. This behavior occurs to make sure that a non-delivery report is generated if an e-mail message cannot be delivered to a recipient. An SMTP address space can be shared with any number of different e-mail systems. In this configuration, each e-mail system is a link in a chain of e-mail systems. The first e-mail system in the chain sends messages to the second e-mail system, and so on. This behavior continues until the message is delivered to a recipient or until the last e-mail system in the chain generates a non-delivery report for the message.

Configuration

Exchange 2003 as Primary

Exchange servers require a "default recipient policy" and within that policy, Exchange must be authoritative for the "primary" SMTP address space that is specified in the default recipient policy shown in the Exchange System Manager Console. Exchange does not have to be authoritative for any other SMTP address space. With a split domain configuration, you only have to add the shared SMTP address space to another recipient policy, set that SMTP address space as the primary SMTP address space, 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.

Recipient policies dictate the SMTP address spaces for which Exchange is authoritative. To determine whether Exchange is authoritative for a particular SMTP address space, follow these steps:

  1. In Exchange System Manager, right-click the recipient policy, and then click Properties.
  2. Click the E-Mail Addresses (Policy) tab, click an e-mail address, and then click Edit.
  3. If the This Exchange Organization is responsible for all mail delivery to this address check box is selected, Exchange is authoritative for the SMTP address space. If this check box is not selected, Exchange is non-authoritative for the SMTP address space.

To share the SMTP address space with a different e-mail system, follow these steps.

Step 1: Modify the primary SMTP address for the default recipient policy

If you want to share the SMTP address space that is specified as the primary SMTP address space in the default recipient policy, you must create a new SMTP address space to act as the primary SMTP address space in the default recipient policy. The new primary SMTP address space that you create does not have to be valid in the Internet DNS. You can use a private SMTP address space such as @localhost or @zm-train.local . This address space is the SMTP address space that Exchange will use to route internal e-mail messages.

To modify the primary SMTP address space that is specified in the default recipient policy, follow these steps.

Note: By default, the domain that you specify when you install Active Directory is the SMTP address space for which Exchange is authoritative. If this SMTP address space is not the SMTP address space that you want to share, skip steps 1-7. Instead, go to "Step 2: Configure the shared SMTP address space." These steps only apply if Exchange is authoritative for the SMTP address space that you want to share.

  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.
  3. In the New E-mail Address dialog box, click SMTP Address, and then click OK.
  4. In the SMTP Address Properties dialog box, type the SMTP address space for which you want Exchange to be authoritative. For example, type @zm-train.local
  5. Click to select the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK. Note: The e-mail address space that you specified must be stamped on all e-mail-enabled objects in Active Directory. In particular, this e-mail address space must be stamped on user accounts that have mailboxes. This enables the users to access the Outlook Web Access virtual server.
  6. Click the new SMTP address that you created, and then click Set as Primary.
  7. 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.

Here is a screen shot of what things will look like.

Recipient Policy Default

You should also examine Mailbox Manager Policies to make sure that the shared SMTP address is non-authoritative. Mailbox Manager Policies also contain e-mail address. If the Default policy has been modified and the Mailbox Manager SMTP address for the shared SMTP address is still authoritative, users will receive a 5.1.1 non-delivery report (NDR). To verify that the shared SMTP is non-authoritative, follow these steps:

  1. Right-click the mailbox manager policy, and then click Change property pages.
  2. Make sure E-Mail Addresses is selected, and then click OK.
  3. Right-click the mailbox manager policy, and then click Properties.
  4. On the E-Mail Address (Policy) tab, select the shared SMTP address, and then click Edit.
  5. Click to clear the This Exchange Organiation is responsible for all mail delivery to this address check box.
  6. Perform step 5 for all Mailbox Manager Policies in the Recipient Policies container.

Step 2: Configure the shared SMTP address space

  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.
  2. In the New Policy dialog box, click to select the E-Mail Address check box, and then click OK.
  3. In the Properties dialog box, type a name for the new recipient policy, click Modify, and then click OK. Note: This configures the default LDAP filter for the policy. You can also modify this filter as appropriate for your environment. The default string is shown as (&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*))) ))))
  4. When you receive the following message, click OK: "When a recipient policy filter changes it does not mean that the proxy addresses for recipients who may no longer be under the control of the policy will be automatically re-evaluated. For these recipients to receive proxies from the new policies to which they belong, use 'Apply this policy now' on the policies that now affect these recipients."
  5. Click the E-Mail Addresses (Policy) tab, and then click New.
  6. Click SMTP Address, and then click OK.
  7. In the Address box, type the SMTP address space that you want to share. For example, type @zm-train.com.
  8. Click to clear the This Exchange Organization is responsible for all mail delivery to this address check box, and then click OK.
  9. Click the new SMTP address that you created, and then click Set as Primary.
  10. Click OK, and then click Yes when you receive the following message:

The e-mail Addresses of type(s) [SMTP] have been modified. Do you want to update all corresponding recipient e-mail addresses to match these new address(es)? (click No)

Here is what it will look like:

Recipient Policy New

Step 3: Modify the SMTP virtual server properties to remove message forwarding for unresolved recipients

  1. In Exchange System Manager, expand Administrative Groups, expand Administrative Group Name, expand Servers, expand ServerName, expand Protocols, expand SMTP, and then click the corresponding SMTP virtual server.
  2. Right-click Default SMTP Virtual Server, and then click Properties. Note: You may have to expand SMTP Virtual Servers before you can click Default SMTP Virtual Server.
  3. Click the Messages tab.
  4. Delete any entries that are displayed in the Forward all mail with unresolved recipients to host box, and then click OK. The box in red should be cleared as shown:
SMTP Config

Step 4: Configure an SMTP connector for the shared SMTP address space

After you configure the shared SMTP address space, 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.

To configure the SMTP connector, follow these steps:

  1. In Exchange System Manager, right-click Connectors, point to New, and then click SMTP Connector.
  2. In the Properties dialog box, type a name for the new connector in the Name box.
  3. 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 (the Zimbra Server). You must type square brackets ([ ]) around the host name or IP address. For example, if the IP address of the destination computer is 10.0.10.25, type [10.0.10.25]. This computer will receive all e-mail that is not resolved to objects in Active Directory.
  4. Click Add, click an Exchange server in the Add Bridgehead dialog box, and then click OK.
  5. Click the Address Space tab, click Add, click SMTP in the Add Address Space dialog box, and then click OK.
  6. 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 zm-train.com in the E-mail domain box. Then, click OK.
  7. Click to select the Allow messages to be relayed to these domains check box. Note: Because Exchange must also receive messages for the shared e-mail address space, you must let Exchange relay messages to this domain. This setting lets all the SMTP virtual servers that are listed under Local bridgeheads on the General tab accept messages for the shared e-mail address space.
  8. Click OK.

Important!! - If you have additional smtp connectors that are *.*, you will need to delete them. The default connector is not needed in this scenario

Connector-General
Connector-Address

Step 5: Restart the Routing and SMTP services

To do this, follow these steps:

  1. In the Services snap-in, click Start, click Run, type services.msc, and then click OK.
  2. Right-click Microsoft Exchange Routing Engine, and then click Stop.
  3. Right-click Microsoft Exchange Routing Engine, and then click Start.
  4. Right-click Simple Mail Transport Protocol (SMTP), and then click Stop.
  5. Right-click Simple Mail Transport Protocol (SMTP), and then click Start.
  6. Exit the Services snap-in.

After you configure these settings, Exchange can forward messages to a Zimbra system that shares the same SMTP domain name space.

Zimbra Server As Secondary

The configuration elements documented here have been completed for zm-train.com and are shown here for documentation purposes.

Zimbra Server

Hostname is my-zimbra-server.zm-train.com

mail domain = zm-train.com

The secondary MTA must accept mail for accounts that are hosted on the secondary. The first two commands (in combination) tell the Zimbra postfix to accept all addresses in the @zm-train.com domain as valid addresses.

$ zmprov md zm-train.com zimbraMailCatchAllAddress @zm-train.com
$ zmprov md zm-train.com zimbraMailCatchAllForwardingAddress @zm-train.com

But must forward all other mail for accounts on this domain to the primary system

This third command establishes default mail routing for the domain. Any users that do not exist on the Zimbra system will have their mail routed according to this rule.

$ zmprov md zm-train.com zimbraMailTransport smtp:my-exchange-server.zm-train.com:25

On the Zimbra server, we will turn off DNS lookups and internet wide message routing from the secondary host and route all mail through the primary. In the case of

Relay mail to Primary with:

$ zmprov mcf zimbraMtaRelayHost my-exchange-server.zm-train.com:25

Turn off DNS lookups with:

$ zmprov mcf zimbraMtaDnsLookupsEnabled FALSE

After configuration changes, restart services/server if needed.

$ postfix stop
$ postfix start

Outbound email:

Either of the mail servers will be able to send email out independent of the other by allowing outbound smtp traffic from their respective ip addresses through the firewall.

Testing

Be sure to exercise each of the Use cases described earlier to verify mail routing is occurring as expected.

Migration Notes

To prevent the possibility that mail will be delivered to the Exchange mailbox during the migration, you should consider stopping the SMTP service on the Exchange Server during migration.

Manage user expectations. Rules created in Outlook and Notes will not get migrated with the current version of the Exchange Migration Wizard (6.0.6). Personal distribution lists should get migrated but don't always due to how they may have been stored on the Exchange server. If your Exchange server has database corruption, the Migration wizard will migrate as much as possible. In some cases with bad corruption of the Exchange database, it may be necessary to export messages to a pst file in Outlook and use the PST import wizard to migrate data.

Migration Completion

After each user is migrated from Exchange to Zimbra, the following steps will need to be taken for mail to be routed properly for that user.

Remove the user’s mailbox from Exchange using the following steps. Do not delete their user account.

  1. In Exchange System Manager, right click on the username, and select “Delete Mailbox”, and click next and finish to confirm the action. Next, right mouse click on the user account, click Exchange Tasks, click "Establish email address" and click next. Under "External Email Address" click modify. Add an smtp address with username@domain.com. Then click Next and Finish. This action will tell Active Directory to deliver email for this account, but forward it through the connector to the Zimbra server. The action does not remove the mailbox from the Exchange Database. If problems happen after the migration, the user can be re-associated with the mailbox, however, mail delivered to the Zimbra Server would have to be migrated back to the Exchange Account.
  2. Update the User Account on Zimbra for local delivery

On the Zimbra Server, logon as the zimbra user and from the command line:

zmprov ma user@zm-train.com zimbraMailTransport lmtp:myzimbraserver.zm-train.com:7025


Verified Against: ZCS 8.6, 8.5, 8.0 Date Created: 1/27/2010
Article ID: https://wiki.zimbra.com/index.php?title=Split_domain_with_Exchange_2003_as_Primary Date Modified: 2015-08-25



Try Zimbra

Try Zimbra Collaboration with a 60-day free trial.
Get it now »

Want to get involved?

You can contribute in the Community, Wiki, Code, or development of Zimlets.
Find out more. »

Looking for a Video?

Visit our YouTube channel to get the latest webinars, technology news, product overviews, and so much more.
Go to the YouTube channel »

Jump to: navigation, search