Configure a Shared Address Space with On-Premises Relay

 

Applies to: Live@edu

Topic last modified: 2011-11-23

There are two ways to configure a shared address space. This topic describes the on-premises relay configuration, in which all email sent to recipients in the shared address space by a sender on the Internet is first delivered to the on-premises messaging system. The on-premises messaging system is responsible for forwarding email addressed to recipients in the cloud-based email service. To learn more, see Shared Address Space with On-Premises Relay.

The following diagram illustrates the deployment of a shared address space for Contoso University.

Shared address space

Now let's walk through the process of configuring the shared address space described in the Contoso University example. The process requires configuration of elements in the cloud-based email service and in the on-premises organisation.

Tasks in the cloud-based email service

First, perform these tasks for the cloud-based email service.

1. Enroll and configure the live.contoso.edu domain

You have to enrol a different domain in the cloud-based email service than the on-premises address space or the shared address space. In this example, the domain to enrol in the cloud-based email service is live.contoso.edu.

  • Enrol the cloud-based domain

    If you are a Live@edu customer, see Enroll Your Domain with Microsoft Live@edu.

    If you are running a cloud-based email service with UNRESOLVED_TOKEN_VAL(<rte:TA_Reuse_BPOSStandard_Firstmention>), see Add or change domains and domain properties.

  • Configure IP safelisting to ensure that mail is relayed to the cloud-based email service   Use the Forefront Online Protection for Exchange (FOPE) Admin Centre to configure safelisting. For more information, see Inbound Safe Listing Scenario.

    Specifically, you must identify all the servers in the on-premises messaging system that are used to deliver email to the cloud-based email service. These servers can be categorised as follows:

    • Internal mail servers   These servers contain mailboxes or are used for routing email messages internally without being exposed to the Internet.

    • Gateway servers   These servers are connected to the Internet and are used to deliver email to the cloud-based email service.

      Note   You don't need a dedicated gateway server that only delivers email to the cloud-based email service. If the gateway servers deliver email to the cloud-based email service and to the Internet at large, they are considered gateway servers. If the on-premises messaging system uses a dedicated gateway server to deliver email to the cloud-based e-mail service only, that server is considered an internal mail server.

  • Test mail flow   Although senders on the Internet won't use the @live.contoso.edu email addresses, we recommend that you test the cloud-based domain to verify that it is functioning correctly. To do this, create one or more test user accounts and use them to test mail flow.

2. Add contoso.edu as an accepted domain

After you enroll the cloud-based domain, add the shared address space as an accepted domain so you can set the primary address for the cloud-based email service accounts in the shared address space. In this example, the shared address space is contoso.edu.

For instructions, see one of the following topics:

3. Configure contoso.edu as an internal relay domain

If you don't configure the share address space @contoso.edu as an internal relay domain, email sent from students in the cloud-based email service to faculty and staff with @contoso.edu addresses in the on-premises messaging system won't be delivered, and NDRs will be generated.

To configure @contoso.edu as an internal relay domain, use Windows PowerShell. UNRESOLVED_TOKEN_VAL(<rte:TA_RPSBeforeYouBegin>)

Run the following command:

Set-AcceptedDomain <shared address space> -DomainType InternalRelay

For our example, contoso.edu is the shared address space. Run the following command:

Set-AcceptedDomain contoso.edu -DomainType InternalRelay
4. Create cloud-based accounts with a primary email address in the contoso.edu domain

Use one of the following methods to create new accounts and set the primary email address in the shared address space.

  • Create new cloud-based users in the @contoso.edu address space.

    To create individual accounts in the Exchange Control Panel, see Create a New Mailbox. When you create an account, select the shared address space @contoso.edu, not the default cloud-based address space @live.contoso.edu. When you select the account in the contoso.edu domain, the primary email address of the account is also set in the @contoso.edu domain.

    You can use the Exchange Control Panel and a CSV file to provision large numbers of new users. Here's how: Import New Exchange Online Users with a CSV File.

  • Update the primary address of existing cloud-based accounts in the @live.contoso.edu address space to the @contoso.edu address space.

    If you've already created many accounts in your cloud-based domain before you decided you wanted a shared address space, you need to update to primary address for those accounts to the @contoso.edu address space. The Windows Live IDs of your cloud-based users can be in a completely different domain that their primary email addresses. For more information, see Change a User's Primary E-mail Address.

Tasks in the on-premises organisation

Now it's time to configure elements in the on-premises messaging system.

Configure mail forwarding to the cloud-based email service

You have to configure your on-premises messaging system to correctly forward email to recipients in the cloud-based email service. The process for doing this depends on the software used in the on-premises messaging system. Here are some possibilities:

  • Forefront Online Protection for Exchange

    • If you are running Microsoft Exchange Server 2010 on premises and you are enrolled in UNRESOLVED_TOKEN_VAL(<rte:TA_Reuse_BPOSStandardBeta>), you can find FOPE-specific configuration content for this scenario at Shared Address Space with On-Premises Relay Scenario.

  • Microsoft Exchange Server 2007 and Exchange Server 2010

    • Configure Exchange 2010 to Route Messages for a Shared Address Space

    • How to Configure Exchange 2007 to Route Messages for a Shared Address Space

      Note that the second messaging system has to be authoritative for the shared address space. In the Contoso University example, the first messaging system, which is the on-premises Exchange 2007 or Exchange 2010 organisation, is authoritative for the shared address space @contoso.edu. Therefore, to make the shared address space work, you have to do the following in the on-premises Exchange organisation:

    • Create an internal relay domain for the cloud-based domain live.contoso.edu and create a Send connector for the @live.contoso.edu address space that uses smart host routing, instead of DNS routing. The smart host value is the MX record for your cloud-based domain.

      Use Exchange transport rules and address rewriting to configure a solution to convert @contoso.edu addresses into @live.contoso.edu addresses for Outlook Live users.

      Note   If you want the cloud-based users to access their mailboxes using Microsoft Outlook 2007 or Outlook 2010, the cloud-based users must be represented in the on-premises global address list as mail contacts or mail users. The CNAME autodiscover record that is required for Outlook clients to access their mailboxes points to the on-premises Exchange organisation. In the Contoso University example, the CNAME record autodiscover.contoso.edu points to autodiscover.outlook.com. For more information about the CNAME autodiscover record, see Recommended DNS Record Updates for Live@edu.

  • Exchange 2003   See Microsoft Knowledge Base article 321721, "How to share an SMTP address space in Exchange 2000 Server or in Exchange Server 2003". In that article, Method 2 most closely resembles the Contoso University example. Method 1 requires the second messaging system to be authoritative for the shared address space. In the Contoso University example, the first email system, which is the on-premises Exchange Server 2003 organisation, is authoritative for the shared address space @contoso.edu.

  • Zimbra   See Split Domain.

  • Other messaging systems   You're on your own. Most likely, you'll have to configure some kind of connector or smart host to route email for recipients in the cloud-based email service without creating mail routing loops for nonexistent recipients. Consult the documentation for your on-premises messaging system.

Verify everything works correctly

After you have configured the shared address space, verify that mail flows as follows:

  • Inbound mail flow   All email sent to the shared address space arrives at the on-premises messaging system. Messages for faculty and staff are delivered. Messages for students in the cloud-based email service are forwarded appropriately. Messages sent to non-existent recipients generate an NDR.

  • Outbound mail flow   Email sent from students in the cloud-based email service and faculty and staff in the on-premises messaging system to external recipients shows a From: address in the shared address space: contoso.edu.

  • Replies   When external recipients reply to messages, the To: address in the reply is the shared address space, @contoso.edu.

  • On-premises delivery from the cloud-based email service   Messages sent from students in the cloud-based email service to faculty and staff in the on-premises messaging system are delivered. Messages sent to nonexistent recipients generate an NDR.

  • Cloud-based email service delivery from the on-premises messaging system   Messages sent from faculty and staff in the on-premises messaging system to students in the cloud-based email service are delivered. Messages sent to non-existent recipients generate an NDR.

Did you know?

The shared address space configuration as described in the Contoso University scenario doesn't require users in the on-premises messaging system to appear in the cloud-based email service shared address book. A communication and synchronisation solution must be established between the on-premises messaging system and the cloud-based email service to import the on-premises users into the cloud-based address book as mail users, and to synchronise periodically for updates.

If you are a Microsoft Live@edu customer, see Implement Outlook Live Directory Sync for Live@edu.

If you are running a cloud-based email service with UNRESOLVED_TOKEN_VAL(<rte:TA_Reuse_BPOSStandard_Firstmention>), see Active Directory synchronisation: Roadmap.

 
Related help topics
Loading...
No resources were found.