Navigate your checklist Before you begin with Exchange Sign up for Office

Transcription

1 Contents Navigate your checklist... 3 Before you begin with Exchange Sign up for Office Verify coexistence prerequisites when deploying AD FS with Exchange Collect needed information for Exchange Configure single sign-on Configure Active Directory synchronization Verify service configuration Install Exchange 2010 coexistence server with Exchange Configure management interfaces with Exchange Enable Mailbox Replication Proxy service Configure virtual directories Configure accepted domains Configure Exchange certificates with Exchange Configure Address Policy with Exchange Configure Outlook Anywhere Configure service autodiscover DNS record Configure federated delegation for coexistence Configure Organization Relationships with Exchange Configure Outlook Web App with Exchange Configure Send and Receive Connectors with Exchange Configure centralized transport with Exchange Create a test mailbox for shared domains Redirect Outlook Web App connections to coexistence server for Exchange

2 Move or create a mailbox for shared domains Configure cloud-based mailboxes for federated sharing Post-configuration tasks for Coexistence with Exchange Coexistence checklist complete Understanding Access to Outlook Web App with a Single URL with Exchange Understanding Certificate Requirements Understanding Coexistence Understanding Coexistence Permissions Understanding Coexistence Management with Exchange Understanding Coexistence with Exchange 2007 Prerequisites Understanding the Coexistence Server with Exchange Understanding Edge Transport Servers with Coexistence Understanding IRM Coexistence Understanding Identity Federation Understanding Shared and Split SMTP Namespaces with Exchange Understanding Shared Free/Busy with Exchange Understanding Transport Options with Exchange

3 Navigate your checklist Now that we ve asked you a few questions about your environment, it s time to review how to use your Exchange 2010 Deployment Checklist. How can I see my answers to the environment questions? That's easy. There are two ways: Click the left arrow at the bottom of this page or, click Review your answers at the top of the left pane. Then you can see a summary of how you answered the questions. How can I change my answers? Go to the Review your answers page. Right after the summary of your responses, you'll see where you can click to make changes. You can also click Start Over at the top of any page. When you change your answers, you'll get a whole new checklist that's tailored to those answers. How can I move through the checklist? You can browse the checklist by clicking a step in the left pane or by using the right and left arrow buttons. While you can browse in any order you want, you do need to complete the steps in the order shown. If you try to jump ahead and complete a step, you'll find that you won't be able to mark the step as complete. That's because the previous steps were skipped. What do I do when I finish a step? Pat yourself on the back! Then, you can either click the check box to the left of the step or the check box icon at the bottom of the screen. Then, you can move on to the next step. The progress bar will change as you mark steps complete so you can easily track your progress. What if I get interrupted? You can exit the Exchange Deployment Assistant at any time and return to the same computer later to continue. Please be aware that if you access the Deployment Assistant from a different computer, progress from your session on the original computer is not available. Can I print this stuff? Yes! See the Print Send Download Checklist icons at the top of this page? They're on every page of the checklist. You can print the step you're working on, and you can even download the 3

4 entire checklist. Also, if you'd like to send mail to someone about a step, click Send. A link to the step is automatically included in the mail. Before you begin with Exchange 2007 Deploying coexistence in your organization provides many benefits. However, to enjoy those benefits, you'll need to first do some careful planning. Before you go any further with the Exchange Server Deployment Assistant, we urge you to review this entire topic to make sure that you fully understand how deploying coexistence could affect your existing network and Exchange organization. Important: To successfully deploy coexistence in your organization, you must participate in the Microsoft Office 365 for enterprises beta program. This is a requirement to create a cloud-based organization. We ll give you instructions to sign up for Office 365 later in the checklist; however, acceptance in the beta program is available only to a limited number of participants. What is coexistence? In the Deployment Assistant, coexistence is when you create a new cloud-based Exchange organization in Microsoft Office 365 for enterprises and then connect it to your existing onpremises Exchange 2007 organization by adding and configuring an Exchange 2010 coexistence server. After deploying the coexistence server, the following features can be enabled between the organizations: Mail routing Mailbox moves Shared global address list (GAL) Shared calendar and free/busy information Message tracking, MailTips, and Multi-mailbox search Learn more at: Understanding Coexistence Example Coexistence Scenario Take a look at the following figure. It's an example topology that provides an overview of a typical Exchange 2007 deployment. Contoso, Ltd. is a single forest, single domain organization with two domain controllers, one Exchange 2007 server with the Mailbox, Client Access and Hub Transport server roles installed, and a single Edge Transport server. Remote Contoso users use Outlook Web App to connect to Exchange 2007 over the Internet to check their mailboxes and access their Outlook calendar. 4

5 By the way, the name of the organization in this example, Contoso, Ltd., is also used throughout the Deployment Assistant. When you're working through the steps in your checklist, remember to replace the references to contoso.com with your organization's domain name. Existing Contoso on-premises organization Let's say that the network administrator for Contoso is interested in deploying coexistence and decides to use the Exchange Server Deployment Assistant. The admin answers "Yes" to each of the initial questions posed by the Deployment Assistant. After completing the coexistence checklist, the new topology has the following configuration: Users will use their existing network account credentials for logging on to the on-premises and cloud-based organizations. User mailboxes located on-premises and in the cloud-based organization will use the same address domain. For example, mailboxes located on-premises and mailboxes located in the cloud-based organization will both in user addresses. All mail is delivered to the Internet by the on-premises organization. The on-premises organization controls all messaging transport and serves as a relay for the cloud-based organization. On-premises and cloud-based organization users can share calendar free/busy information with each other. Organization relationships configured for both organizations also enable cross-premises message tracking, MailTips, and message search. 5

6 On-premises and cloud-based users use the same URL to connect to their mailboxes over the Internet. Using those answers, the Admin begins to work through the coexistence deployment checklist that's tailored to Contoso. After completing the checklist, Contoso has the following organization configuration. Configuration of Contoso coexistence deployment If you compare Contoso's existing organization configuration and the coexistence configuration, you'll see that deploying coexistence has added servers and services that support additional communication and features that are shared between the on-premises and cloud-based organizations. Here's an overview of the changes that a coexistence deployment has made from the initial on-premises Exchange organization. Configuration Before coexistence deployment After coexistence deployment Coexistence server Not applicable; single organization only Installed in the on-premises organization to deploy coexistence Mailbox location Mailboxes on-premises only Mailboxes on-premises and 6

7 Configuration Before coexistence deployment After coexistence deployment cloud-based Message transport Outlook Web App Unified GAL for both organizations Single-sign on used for both organizations Organization relationship established and a federation trust with Microsoft Federation Gateway Free/busy sharing On-premises hub transport and edge transport servers handle all inbound and outbound message routing On-premises mailbox server receives all Outlook Web App requests and displays mailbox information Not applicable; single organization only Not applicable; single organization only Not applicable, single organization only Free/busy sharing between onpremises users only On-premises coexistence server handles internal coexistence message routing between the on-premises and cloud-based organization. The edge transport server handles external inbound and outboud message routing. On-premises coexistence server redirects Outlook Web App requests to either the on-premises Exchange 2007 mailbox server or provides a link to log on to the cloud-based organization On-premises DirSync server replicates Active Directory information for mail-enabled objects to the cloud-based organization On-premises Active Directory Federation Services (AD FS) server supports using singlesign on credentials for mailboxes located either onpremises or in the cloud-based organization Trust relationship with the Microsoft Federation Gateway. Organization relationship established between the onpremises and cloud-based organization Free/busy sharing between both on-premises and cloudbased users 7

8 Things to Consider before Configuring Coexistence Now that you're a little more familiar with what coexistence is, it's time to carefully consider some important issues. Deploying coexistence could affect multiple areas in your current network and Exchange organization. Supported Organizations The Deployment Assistant is specifically targeted to on-premises Exchange 2007 deployments that are contained to a single Active Directory forest and domain. If your organization contains multiple active directory domains, other versions of Exchange, or mail systems other than Exchange, you will need to perform additional steps not outlined in the Deployment Assistant. If your existing on-premises organization is a multiple Active Directory forest and domain deployment, we recommend you delay deploying coexistence until the Deployment Assistant is updated to support these types of organizations. Note: Active Directory synchronization between the on-premises and cloud-based organizations is a requirement for deploying coexistence. During the Microsoft Office 365 Beta program, the upper limit for replicating mail-enabled Active Directory objects to the cloud-based organization is 10,000 objects. Replicating more than 10,000 mail-enabled Active Directory objects is not supported. Certificates Secure Sockets Layer (SSL) digital certificates play a significant role in deploying coexistence. They help to secure communications between the on-premises coexistence server and the cloudbased organization. If you're already using digital certificates in your Exchange organization, you may have to modify the certificates to include additional domains or purchase additional certificates from a trusted certificate authority (CA). If you aren't already using certificates, you will need to purchase one or more certificates from a trusted CA. Certificates are needed early in the coexistence deployment checklist and are a requirement to configure several types of services. Learn more at: Understanding Certificate Requirements Bandwidth Your network connection to the Internet will directly impact the communication performance between your on-premises organization and the cloud-based organization. This is particularly true when moving mailboxes from your on-premises Exchange 2007 server to the cloud-based organization. The amount of available network bandwidth, in combination with mailbox size and the number of mailboxes moved in parallel, will result in varied times to complete mailbox moves. Additionally, other Office 365 cloud-based services, such as Microsoft SharePoint Online and Lync Online, may also impact the available bandwidth for messaging services. Before moving mailboxes to the cloud-based organization, you should: 8

9 Determine the average mailbox size for mailboxes that will be moved to the cloud-based organization. Determine the average connection and throughput speed from your on-premises organization to Microsoft Online Services. Run speed tests during the expected hours that you plan to move on-premises mailboxes to the cloud-based organization. Use this tool: Microsoft Online Services Performance Test Calculate the average expected transfer speed, and plan your mailbox moves accordingly. Learn more at: Company Network Requirements Edge Transport Servers Some Exchange 2007 organizations may not have Edge Transport servers deployed. In these scenarios, both inbound and outbound external messaging and coexistence mail flow between the on-premises and cloud-based organizations will be handled by the coexistence server. If present, Edge Transport servers will handle non-coexistence external inbound and outbound mail routing and the coexistence server will handle messaging between the on-premises and cloudbased organizations in an Exchange organization. Learn more: Understanding Edge Transport Servers with Coexistence Unified Messaging Unified Messaging (UM) is supported in a coexistence deployment between your on-premises and cloud-based organizations. Your on-premises telephony solution must be able to communicate with the cloud-based organization. This may require that you purchase additional hardware and software. If you want to move mailboxes from your on-premises organization to the cloud-based organization, and those mailboxes are configured for UM, you should configure UM coexistence prior to moving those mailboxes. If you move mailboxes before you configure UM coexistence, those mailboxes will no longer have access to UM functionality. Lear more at: Plan for UM Coexistence Information Rights Management Information Rights Management (IRM) enables users to apply Active Directory Rights Management Services (AD RMS) templates to messages that they send. AD RMS templates can help prevent information leakage by allowing users to control who can open a rights-protected message, and what they can do with that message once it's been opened. IRM in a coexistence deployment requires planning, manual configuration of the cloud-based organization, and an understanding of how clients use AD RMS servers depending on whether their mailbox is in the on-premises or cloud-based organization. Learn more at: Understanding IRM Coexistence 9

10 Mobile Devices Mobile devices are supported in a coexistence deployment. Exchange ActiveSync is enabled by default on the coexistence server and will automatically redirect requests from mobile devices to mailboxes located in either the cloud-based organization or the on-premises mailbox server. All mobile devices that support Exchange ActiveSync should be compatible with a coexistence deployment. Learn more at: Mobile Phones Client Requirements We recommend that your clients use Microsoft Office Outlook 2010 for the best experience and performance in the coexistence environment. Outlook 2007 is compatible with coexistence, but some features may not be available. Important: Pre-Outlook 2007 clients are not supported by the Office 365 service or by on-premises organizations configured for coexistence. Pre-Outlook 2007 clients that connect directly to the Office 365 service, and clients that connect to on-premises Exchange servers that coexist with Office 365, must be upgraded to a supported version. Licensing for the Cloud-based Service To create mailboxes in, or move mailboxes to, a cloud-based organization, you need to sign up for Office 365 for enterprises and you must have licenses available. When you sign up for Office 365, you'll receive a specific number of licenses that you can assign to new mailboxes or mailboxes moved from the on-premises organization. Each mailbox in the cloud-based service must have a license. Note: During the Office 365 Beta, the default number of user licenses for the cloud-based organization is 50. If you need more than 50 user licenses, you will need to submit a request to Office 365 Beta support. Antivirus and Anti-Spam Services Mailboxes moved to the cloud-based organization are automatically provided with antivirus and anti-spam protection by Forefront Online Protection for Exchange (FOPE). We recommend that you evaluate whether FOPE services protecting your cloud-based organization are sufficient to cover the antivirus and anti-spam needs of your on-premises organization. You may need to upgrade or configure your on-premises antivirus and anti-spam solutions for maximum protection across your organization. Learn more at: Microsoft ForeFront Online Protection for Exchange 10

11 Public Folders Public folders are not supported in the Office 365 and cloud-based mailboxes won't have access to public folders located in the on-premises Exchange organization. Existing on-premises public folder configuration and access for on-premises mailboxes will not be changed when deploying coexistence. Questions? Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Sign up for Office 365 Using Microsoft Office 365 for enterprises allows you extend your on-premises organization to the cloud, and it's a requirement for configuring coexistence. Coexistence provides many advantages, including greater messaging flexibility, storage for large user mailboxes, reduced hardware costs, and convenient user management support. How do I do this? You must subscribe to Office 365 for enterprises to create a service tenant that you can use to coexist with your on-premises Exchange organization. Office 365 for enterprises provides you with an Exchange organization in the cloud. Learn more at: Sign up for Office 365 How do I know this worked? After you create your cloud-based service tenant with Office 365 for enterprises, you'll get an e- mail from Microsoft that confirms the successful creation of the tenant. Logging on to your cloudbased service will confirm that creating the service organization was completed successfully. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Verify coexistence prerequisites when deploying AD FS with Exchange 2007 Before you go any further with the Exchange Deployment Assistant, make sure that your organization's operating system, hardware, software, clients, and other elements meet the 11

12 requirements for coexistence between your on-premises organization and the cloud-based service. If they don't, you won't be able to complete the steps in the Deployment Assistant and you won't be able to successfully deploy coexistence for your organization. Learn more at: Understanding Coexistence with Exchange 2007 Prerequisites To successfully install the Exchange 2010 coexistence server in your current Exchange organization, the following components are required. Physical Servers You will need a single, physical server for each of the following coexistence components: Exchange 2010 coexistence server Active Directory Federation Services (AD FS) server Active Directory synchronization server Exchange 2010 Coexistence Server The coexistence server must have one of the following operating systems installed: 64-bit edition of Windows Server 2008 Standard Service Pack 2 64-bit edition of Windows Server 2008 Enterprise Service Pack 2 64-bit edition of Windows Server 2008 Standard R2 64-bit edition of Windows Server 2008 Enterprise R2 Additionally, the following prerequisites must be installed:.net Framework 3.5 SP1 Internet Information Services (IIS) Windows PowerShell V2.0 Windows Remote Management V2.0 Learn more at: Understanding Coexistence with Exchange 2007 Prerequisites Active Directory Federation Services Server When you set up identity federation, it provides a true single sign-on (SSO) experience for users to access both the on-premises and cloud-based organizations with a single username and password. To use identity federation, you'll need to make sure the AD FS server meets specific requirements. Learn more at: Prepare for identity federation Active Directory Synchronization Server The Active Directory synchronization server replicates mail-enabled Active Directory objects to the cloud-based organization to support a unified global address list (GAL) between your organizations. 12

13 Note: During the Office 365 Beta program, the upper limit for replicating mail-enabled Active Directory objects to the cloud-based organization is 10,000 objects. Replicating more than 10,000 mail-enabled Active Directory objects is not supported. Learn more at: Active Directory synchronization: Roadmap Existing Directory Servers Schema master The latest 32-bit or 64-bit edition of the Windows Server 2008 Standard or Enterprise operating system or later. Global catalog server In every Active Directory site where you plan to install the Exchange 2010 coexistence server, you must have at least one global catalog server that is either the latest 32-bit or 64-bit edition of Windows Server 2008 Standard or Enterprise, or the latest 32-bit or 64-bit edition of Windows Server 2008 R2 Standard or Enterprise. Active Directory forest The Active Directory forest must be Windows Server 2008 forest functional mode. Domain Controller You must have the latest 64-bit edition of the Windows Server 2008 Standard or Enterprise operating system or the Windows Server 2008 R2 Standard or Enterprise operating system or the Windows Server 2008 Datacenter or Windows Server 2008 R2 Datacenter. Existing Exchange 2007 Servers 64-bit edition of Microsoft Exchange Server 2007 SP3 or later Installed Mailbox, Client Access and Hub Transport server roles Windows Server 2008 forest functional level Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Collect needed information for Exchange 2007 To deploy coexistence between your on-premises Exchange organization and the cloud-based organization, you're going to need information about your current deployment. You might want to print this step so you can record your organization's information and have easy access to it as you go through the checklist. Learn more at: Understanding Coexistence You can use the following table to gather information about your existing organization that you're going to need before you get started. When you're working through your checklist, replace the 13

14 example information that you see in the checklist with the information you've provided in this table. For example, if the external fully qualified domain name (FQDN) of your Exchange 2007 server is exchange.adatum.com, enter that FQDN in the "Value in your organization" field. Description Example value in checklist Value in your organization Active Directory forest root Internal Exchange 2007 server host name External Exchange 2007 server FQDN Proposed internal coexistence server host name Proposed external coexistence server FQDN Outlook Web App URL Primary SMTP namespace User principal name domain Microsoft Online ID domain Corp.contoso.com EX2007 mail1.contoso.com EX2010 mail2.contoso.com Owa.contoso.com Contoso.com Contoso.com The following table lists new services that you configure as part of the coexistence deployment. For the values you provide in the table below, we recommend that you replace contoso.com with your domain name and use the example subdomains provided below. For example, if your domain is adatum.com, we recommend that you enter service.adatum.com in the "Value in your organization" field for the service SMTP namespace. Description Example value in checklist Value in your organization Service SMTP namespace Important You must not use the service tenant FQDN, specified below, as the service SMTP namespace. We recommend that you use service.<your domain>. Internal Active Directory Federation Services (AD FS) server hostname Service.contoso.com ADFS 14

15 Description Example value in checklist Value in your organization External AD FS server FQDN Internal directory synchronization server host name Exchange federation trust namespace On-premises Autodiscover FQDN Service Autodiscover FQDN Service tenant FQDN Note You can only choose the subdomain portion of this FQDN. The domain portion must be "onmicrosoft.com". Sts.contoso.com DirSync Exchangedelegation.contoso.com Autodiscover.contoso.com Autodiscover.service.contoso.com Contoso.onmicrosoft.com Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure single sign-on Identity federation provides a true single sign-on (SSO) experience so that users can access both the on-premises and cloud-based organizations with a single user name and password. Configuring identity federation also allows you to enforce your organization's password policies and account restrictions in both the on-premises and cloud-based organizations. Learn more at: Understanding Identity Federation How do I do this? Configure identity federation for your on-premises organization as follows. 1. Add an additional physical server to your on-premises organization to support an installation of Active Directory Federation Services (AD FS) and make sure the server meets the requirements to run AD FS. 2. Install AD FS. 15

16 3. Configure identity federation between your on-premises organization and the cloud-based service. Learn more at: Prepare for identity federation How do I know this worked? After adding the MSOL federated domain using the Microsoft Online Services Identity Federation Management Tool, you can run the following code in the Microsoft Online Services Federation Management Tool to view the configuration settings of the Microsoft Online Services federation. Get-MSOLFederationProperty -DomainName <your primary SMTP domain> Verify that both AD FS server and Microsoft Online Services have been added as sources for your primary SMTP domain in the returned results. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure Active Directory synchronization Active Directory synchronization (DirSync) between your on-premises organization and the cloudbased organization enables a unified global address list (GAL) and gives you the ability to manage all Active Directory user accounts on-premises. All account changes replicate automatically to the cloud-based organization. Learn more at: Active Directory synchronization: Roadmap How do I do this? You can configure Active Directory synchronization for your on-premises organization as follows: 1. Add an additional physical server to your on-premises organization to support an installation of the Microsoft Online Services Directory Synchronization tool and make sure the server meets the requirements for installing DirSync. 2. Install the Microsoft Online Services Directory Synchronization tool. 3. Configure DirSync between your on-premises organization and the cloud-based organization. Learn more at: Installing DirSync How do I know this worked? Log on to the administration portal for the cloud-based organization and verify that all Active Directory user accounts settings have been replicated to the cloud-based organization: 1. Log on to: Cloud-based service administration portal 2. Click Admin on the home page. 3. Click Users in the Management menu to verify that your on-premises users are listed on the cloud-based service. 16

17 Note: Just because a user account is displayed here doesn't mean that the user mailbox has been moved to the cloud-based organization. The displayed accounts represent only that a cloud-based organization account has been created for users and that the account credential information has been replicated from the on-premises organization. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Verify service configuration Now that you've configured both single sign-on and Active Directory synchronization between your on-premises organization and the cloud-based organization, it's time to make sure that everything's working correctly. The steps below create a new test user in your on-premises organization. Active Directory synchronization is working correctly if the user is automatically synchronized to the cloud-based service. Single sign-on is working correctly if, after synchronization is complete and the user is assigned a license, you can log on to the cloud-based Outlook Web App using the user's onpremises credentials. Important: When a user is assigned a license, a mailbox is created for the user in the cloud-based organization if the user doesn't have an on-premises mailbox. This is why it's important, for this test, to make sure that the user you create in the on-premises organization isn't configured with an on-premises mailbox. Learn more at: Understanding Coexistence How do I do this? To create a mailbox in the cloud-based organization, do the following: 1. Open Active Directory Users and Computers on a server in your on-premises organization. 2. Open the container or organizational unit (OU) where you want to create a new Active Directory user. 3. Click Action in the menu bar, click New, and then click User. 4. Enter the required user information. Because this user will be associated with a test mailbox, we recommend that you clearly identify the user as such. For example, name the user "Test User". 5. In the User logon name field, provide the user name that the user should specify when logging into their user account. This, combined with the user principal name (UPN) in the 17

18 drop-down box next to the User logon name field, makes up the Windows Live ID of the user. This typically matches the user's address. Click Next. 6. Enter a password for the new user, specify any options you want to set, and click Next. 7. Click Finish. 8. Wait for directory synchronization to synchronize the new user to the cloud-based service. Note: By default, directory synchronization occurs once every three hours. To force immediate directory synchronization, open C:\Program Files\Microsoft Online Directory Sync\DirSyncConfigShell.psc1 on the Active Directory synchronization server and type the following at the command prompt. Start-OnlineCoexistenceSync 9. Log on to: Cloud-based service administration portal 10. Assign a license to the new user. Learn more at: Activate synced users How do I know this worked? To verify that you've created a test mailbox and that the mailbox is accessible in the cloud-based organization, do the following: 1. Log on to: Cloud-based service administration portal 2. Verify that the user has been synchronized to the service directory. If the user has synchronized correctly, the user will appear in the user list in the administration portal. 3. Verify that the user has an associated license by doing the following: a. Click the name of the user to open the user's property information. b. Click Licenses to view the licenses available to the user. If a license has been assigned to the user, the check box next to the license will be selected. 4. Log out of the administration portal, and close your browser window. 5. Open a new browser window, and attempt to log on to the user's mailbox by browsing to the cloud-based organization's Outlook Web App URL, and logging on with the user's credentials. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Install Exchange 2010 coexistence server with Exchange 2007 The Exchange 2010 coexistence server enables communication between your existing Exchange 2007 servers and the cloud-based service. The coexistence server consists of the Client Access, 18

19 Hub Transport, and Mailbox server roles. You'll need to do a few things to install a coexistence server, so let's get started. Learn more at: Understanding the Coexistence Server with Exchange 2007 How do I install Exchange 2010? We recommend installing the latest update rollup for Exchange 2010 on all your servers. Although you can install update rollups on a server after Exchange 2010 has been installed, it's less time-consuming to incorporate the update rollup into the install server installation process. To do this, copy the contents of the Exchange 2010 DVD to the file system, and then copy or move the downloaded update rollup file to the Updates folder in the installation tree. When you perform the procedure below, the update rollup will be installed as part of the initial installation process. Microsoft releases update rollup packages approximately every six to eight weeks. The rollup packages are available via Microsoft Update and the Microsoft Download Center. In the Search box on the Microsoft Download Center, type "Exchange 2010 update rollup" to find links to the rollup packages. Find update rollup packages at: Microsoft Download Center You'll use the Exchange Server 2010 Setup wizard to install the coexistence server. Important: You don't need to provide an Exchange 2010 license key on the coexistence server during the Office 365 beta. During the beta, you can run the coexistence server in trial mode with no loss of functionality. 1. Download Exchange 2010 Service Pack 1 (SP1). 2. On the coexistence server, run Exchange2010-SP1-x64.exe to extract the installation files. 3. Navigate to the extraction location and double-click Setup.exe. 4. TheExchange Server 2010 Setup welcome screen appears. In the Install section, the software listed for Steps 1 and 2 was installed with the Exchange 2010 prerequisites. However, if these prerequisites aren't already installed, click the appropriate step to install them. 5. When Steps 1 and 2 are listed as Installed, click Step 3 to expand the Exchange language options, and then choose the appropriate option: a. Install all languages from the language bundle This option installs all the Exchange 2010 languages from an Exchange 2010 language bundle. You can connect to the Internet to download the latest applicable language bundle or to use a previously downloaded language bundle on a local drive or network share. Internet connectivity is required for Exchange Setup to download the language pack bundle. b. Install only languages from the DVD This option installs only the languages included with the Setup DVD. The installation of additional languages support requires installing the languages from the language bundle. 6. After Step 3 is complete, click Step 4: Install Microsoft Exchange. 7. On the Introduction page, click Next. 19

20 8. On the License Agreement page, review the software license terms. If you agree to the terms, select I accept the terms in the license agreement, and click Next. 9. On the Error Reporting page, select Yes or No to enable the Exchange Error Reporting feature, and click Next. 10. On the Installation Type page, select Typical Exchange Server Installation. This will install the Hub Transport, Client Access, and Mailbox server roles plus the Exchange Management Tools. To optionally change the installation path for Exchange 2010, click Browse, locate the appropriate folder in the folder tree, and then click OK. Click Next. Note: You can opt to perform a custom installation of Exchange 2010 if needed. If the custom installation is selected, you must install the Hub Transport and Client Access server roles to successfully deploy coexistence. The Mailbox server role is optional. 11. Use the Configure Client Access Serverexternal domain page to configure an external fully qualified domain name (FQDN). This is the FQDN that you give to Outlook Web App users to connect to the Exchange 2010 coexistence server. For example, mail2.contoso.com. Select the check box, enter your FQDN, and then click Next. 12. On the Customer Experience Improvement Program page, optionally join in the Exchange Customer Experience Improvement Program (CEIP). The CEIP collects anonymous information about how you use Exchange 2010 and any problems that you encounter. To join the CEIP, select Join the Customer Experience Improvement Program, choose the industry that best represents your organization, and then click Next. 13. On the Readiness Checks page, review the Summary to determine if the system and server are ready for the coexistence server to be installed. If all prerequisite checks completed successfully, click Install. If any of the prerequisite checks failed, you must resolve the displayed error before you can proceed with installing the coexistence server. In many cases, you don't need to exit Setup while you're fixing issues. After you resolve an error, click Retry to run the prerequisite check again. Also, be sure to review any warnings that are reported. 14. The Progress page displays the progress and elapsed time for each phase of the installation. As each phase ends, it's marked completed and the next phase proceeds. If any errors are encountered, the phase will end as incomplete and unsuccessful. If that happens, you must exit Setup, resolve any errors, and then restart Setup. 15. When all phases have finished, the Completion page displays. Review the results, and verify that each phase completed successfully. Clear the check box for Finalize this installation using the Exchange Management Console, and then click Finish to exit Setup. 16. When you're returned to the Setup welcome screen, click Close. On the Confirm Exit prompt, click Yes. 17. Restart the computer to complete the installation of the coexistence server. 20

21 How do I know this worked? The successful completion of the Exchange Setup wizard will be your first indication that the installation process worked as expected. To further verify that the coexistence server installed successfully, you can use the Shell to run the following command. Get-ExchangeServer <server name> This cmdlet outputs a list of the Exchange 2010 server roles that are installed on the specified server. You can also check the Exchange setup log (ExchangeSetup.log), located in <system drive>\exchangesetuplogs to verify that the coexistence server was installed as expected. Learn more at: Verify an Exchange 2010 Installation Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure management interfaces with Exchange 2007 Now it's time to add your cloud-based organization to the Exchange Management Console (EMC) and learn how to create a remote PowerShell session so that you can manage your cloud-based recipient and organization configuration. When you add your cloud-based organization to the EMC, don't be surprised to find that many fields that are typically available in the EMC for your on-premises Exchange organization won't be available in the cloud-based organization. This is because many aspects of the cloud-based configuration, recipients in particular, are managed from the on-premises Exchange organization. Some tasks require that you use a remote PowerShell session instead of the EMC to configure your cloud-based organization. When that happens, you can use the instructions below to open a remote PowerShell session to the cloud-based organization. Learn more at: Understanding Coexistence Management with Exchange 2007 How do I configure the EMC? You can add your cloud-based organization to the EMC on the coexistence server by using the following steps: 1. Install the Microsoft Online Services Connector on the computer where the EMC is installed. Get it here: Microsoft Online Services Connector 2. Open the EMC on the coexistence server. 3. In the console tree, click the Microsoft Exchange node. This is the top-most node in the tree. 4. In the action pane, click Add Exchange Forest. 21

22 5. In the Add Exchange Forest dialog box, complete the following fields: Specify a friendly name for this Exchange forest Type the name of the Exchange forest. This name will display in the console tree. Specify the FQDN or URL of the server running the Remote PowerShell instance Select Exchange Online, which contains the URL necessary to access your cloud-based organization. Logon with default credential Select this check box if you've configured Active Directory Federation Services (AD FS) 2.0 to enable single sign-on and you've configured the on-premises Active Directory account you're logged into as an administrator in the cloud-based organization. If you want to specify different credentials, clear this check box. 6. If you didn't select the Login with default credential check box, provide credentials of an administrator in your cloud-based organization. How do I connect remote PowerShell to the cloudbased organization? To connect to the cloud-based organization using remote PowerShell, the computer you're using must have Windows PowerShell 2.0 and Windows Remote Management (WinRM) installed. Windows PowerShell on the computer must also be configured to run scripts. Learn more at: Install and Configure Windows PowerShell Use the following steps any time you need to create a remote PowerShell session with the cloudbased organization and run commands. Important: Be sure to disconnect the remote PowerShell session when you're done. If you don't disconnect the session, you could use up all the sessions available to you. You're allowed to have up to three concurrent remote PowerShell sessions. If you use all the sessions available to you, you'll need to wait for the sessions to expire. 1. Open Windows PowerShell. 2. Enter the credentials of an administrator account in the cloud-based organization using the following command. $LiveCred = Get-Credential 3. Create a connection to the cloud-based organization using the following command. $Session = New-PSSession -ConfigurationName Microsoft.Exchange - ConnectionUri -Credential $LiveCred -Authentication Basic -AllowRedirection 4. Load the Exchange cmdlets on the local computer using the following commands: Import-PSSession $Session 22

23 How do I disconnect remote PowerShell from the cloud-based organization? After you've completed the tasks you wanted to perform in the cloud-based organization, you need to disconnect the session between your local computer and the cloud-based organization. Use the following command to disconnect remote PowerShell from the cloud-based organization. Remove-PSSession $Session How do I know this worked? If you've successfully added your organization to the EMC, a new organization node will appear in the console tree. When you expand the new organization, you will see the Organization Configuration, Recipient Configuration, and Toolbox nodes. The Client Access, Hub Transport, and Unified Messaging nodes aren't displayed in the console nodes of cloud-based organizations. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Enable Mailbox Replication Proxy service The Microsoft Exchange Mailbox Replication Proxy service (MRSProxy) is installed on Exchange 2010 Client Access servers. MRSProxy facilitates mailbox moves between your onpremises Exchange organization and your cloud-based organization. MRSProxy is disabled by default, so before you can move mailboxes to the cloud-based service, you need to enable it. If you've installed more than one Exchange 2010 server with the Client Access role installed, verify that you've modified the web.config file on each Exchange 2010 server. Learn more at: Understanding Move Requests How do I do this? Do the following to enable the MRSProxy on the Exchange 2010 coexistence server. Caution: Before you make any changes to the web.config file, make a copy of the file and store it in a safe location. 1. On the coexistence server, open the following file with a text editor such as Notepad. <Exchange Installation Path>\V14\ClientAccess\ExchWeb\EWS\web.config 2. Locate the following section in the web.config file: <!-- Mailbox Replication Proxy Service configuration --> <MRSProxyConfiguration 23

24 IsEnabled="false" MaxMRSConnections="100" DataImportTimeout="00:01:00" /> 3. Change the value of IsEnabled to "true". 4. Save, and then close the web.config file. How do I know this worked? When you enable the MRS proxy, you'll be able to move mailboxes from the on-premises Exchange organization to the cloud-based organization. If you encounter an error when moving a mailbox, such as "The Mailbox Replication Proxy service is disabled", verify that you've correctly modified the web.config file on the coexistence server. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure virtual directories You need to configure the external fully qualified domain name (FQDN) of your Exchange 2010 coexistence server on several virtual directories. This helps the coexistence server determine the domain names that must be added to the digital certificate that you'll create in a later step. In this step, you'll configure the external FQDN as the external URL on the Exchange Web Services (EWS), Outlook Address Book (OAB), and the Exchange ActiveSync (Microsoft-Server- ActiveSync) virtual directories. The external FQDNs for Outlook Web App (OWA) and the Exchange Control Panel (ECP) directories were set during the installation of the coexistence server. Learn more at: Understanding Client Access How do I do this? Run the following commands in the Shell on the coexistence server to set the external FQDN of the coexistence server as the external URL on these virtual directories: 1. Set the external URL on the EWS virtual directory. Set-WebServicesVirtualDirectory "EWS (Default Web Site)" - ExternalUrl " 2. Set the external URL on the OAB virtual directory. Set-OabVirtualDirectory "OAB (Default Web Site)" -ExternalUrl " 3. Set the external URL on the Microsoft-Server-ActiveSync virtual directory. 24

25 Set-ActiveSyncVirtualDirectory "Microsoft-Server-ActiveSync (Default Web Site)" -ExternalUrl " ActiveSync" How do I know this worked? To verify that you've successfully configured the external URL on the virtual directories on the coexistence server, run the following commands: Verify that the external URL is set on the EWS virtual directory Get-WebServicesVirtualDirectory "EWS (Default Web Site)" Format- Table Name, ExternalUrl Verify that the external URL is set on the OAB virtual directory Get-OabVirtualDirectory "OAB (Default Web Site)" Format-Table Name, ExternalUrl Verify that the external URL is set on the Microsoft-Server-ActiveSync virtual directory Get-ActiveSyncVirtualDirectory "Microsoft-Server-ActiveSync (Default Web Site)" Format-Table Name, ExternalUrl Each of the commands that you run will return the name of the virtual directory, and the value that's stored in the ExternalUrl property. The value stored in the ExternalUrl property should match the value that you provided when you configured the virtual directory. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure accepted domains Accepted domains are any SMTP namespaces for which an Exchange organization sends or receives . You need to configure the following accepted domains: SMTP namespace and secondary accepted domain This accepted domain is used as the target address for recipients that are located in the cloud-based organization. This namespace is configured in the on-premises organization. It's also created in the cloud-based organization as a secondary accepted domain. In this checklist, service.contoso.com is used for the SMTP namespace and secondary accepted domain. Important: You must not use the service tenant FQDN, for example, contoso.onmicrosoft.com, as the SMTP namespace or secondary accepted domain. We recommend that you use service.<your domain>. Learn more at: Understanding Accepted Domains 25

26 Delegation namespace This accepted domain is used by federated delegation to create a federation trust between the on-premises Exchange organization and the cloud-based organization. This namespace is configured only in the on-premises organization. In this checklist, exchangedelegation.contoso.com is used for the delegation namespace. Learn more at: Understanding Federation How do I configure an accepted domain in my onpremises organization? You can use the New Accepted Domain wizard in the Exchange Management Console on the coexistence server to create a new accepted domain for the on-premises organization: 1. In the console tree, click Organization Configuration for the on-premises Exchange forest. 2. Navigate to Organization Configuration> Hub Transport. 3. In the action pane, click New Accepted Domain. The New Accepted Domain wizard appears. 4. On the New Accepted Domain page, complete the following fields: Name To identify the accepted domain for the cloud-based organization, type a unique name in the Name field. We recommend that you select a meaningful name to help you easily identify the purpose of this accepted domain. You must use a unique name for each accepted domain. Accepted Domain Use this field to identify the SMTP namespace for the cloud-based organization so that the on-premises Exchange organization also accepts messages for this domain. For example, type service.contoso.com to set the cloudbased organization service.contoso.com as an accepted domain. 5. Select the Internal Relay Domain option to specify that messages for the cloud-based organization are delivered to recipients in your organization who have their mailbox located on the cloud-based organization. 6. On the Completion page, review the following, and then click Finish to close the wizard: A status of Completed indicates that the wizard completed the task successfully. A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. 7. Repeat these steps to create the accepted domain for the delegation namespace. For example, exchangedelegation.contoso.com. How do I configure the secondary accepted domain in the cloud-based service? You need to add a secondary domain to the cloud-based service so that the on-premises organization can route mail to the cloud-based organization. There are two ways to add a secondary domain to the cloud-based service, depending on whether you add a subdomain to a 26

27 domain you've federated using Active Directory Federation Services (AD FS), or whether you've chosen another domain to route mail to the service that hasn't been federated. If you've federated a domain name, we recommend that you use a subdomain under that federated domain. For example, if you federated the domain contoso.com, add a subdomain of service.contoso.com to your cloud-based service. If you haven't federated a domain using AD FS, or if you decide to use another domain to route mail to the cloud-based organization, you can use the administration portal in the cloud-based service to add the domain. Add a subdomain to a federated domain Do the following to add a subdomain under a federated domain to the cloud-based service. 1. Open the Microsoft Online Services Identity Federation Management tool on your AD FS server. 2. Provide your credentials by running the following command. Use the Windows Live user name and password of an administrator in your cloud-based service. $Credential = Get-Credential 3. Establish a connection to the AD FS server by running the following command. Set-MSOLContextCredential -Computer ADFS -MSOLAdminCredentials $Credential 4. Add the subdomain to the cloud-based service by running the following command. Add-MSOLFederatedDomain -Domain service.contoso.com Add a domain using the administration portal Perform the following steps to add a domain to the cloud-based organization. 1. Log on to: Cloud-based service administration portal 2. Click Admin, and then click Domains. 3. Click Add a domain. 4. Enter the SMTP namespace. For example, service.contoso.com. Then, click Next. 5. Click Verify domain. 6. Follow the instructions provided to verify your domain ownership. When complete, wait 15 minutes and then click Verify. How do I know this worked? The successful completion of the New Accepted Domain wizard will be your first indication that creating the new accepted domains on the coexistence server worked as expected. To further verify that the accepted domains are configured correctly, you can run the following command in the Exchange Management Shell on the coexistence server to verify the configuration settings are correct for the accepted domains. 27

28 Get-AcceptedDomain To verify that you've successfully added the SMTP namespace as a domain in the cloud-based organization, do the following: 1. Log on to: Cloud-based service administration portal 2. Click Admin, and then click Domains. 3. Find the domain you just added, and verify its status is set to Active. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure Exchange certificates with Exchange 2007 Digital certificates are an important requirement for secure communications between the onpremises Exchange 2010 coexistence server, clients, and the cloud-based organization. You need to obtain a certificate that can be installed on the coexistence server. We recommend that you purchase a third-party certificate from a trusted certificate authority (CA). We also recommend that your certificate's common name matches the primary SMTP domain for your organization. Learn more at: Understanding Certificate Requirements How do I obtain a certificate? Before you can configure certificates on the coexistence server, you need to obtain a certificate from a trusted CA. Complete the following on the coexistence server if you need to generate a request for a new certificate that will be used on the coexistence server. 1. In the console tree, click Server Configuration for the on-premises Exchange organization node and then select the coexistence server. 2. From the action pane, click New Exchange Certificate to open the New Exchange Certificate wizard. 3. On the Introduction, in the Enter a friendly name for the certificate field, provide a descriptive name for the certificate request, and click Next. 4. On the Domain Scope page, see the Enable wildcard certificate check box. You can use it to specify the root domain of the wildcard certificate you want to create. Unless you have many domains that you want to include with this certificate, we recommend you do not select this check box. Click Next. Note: If you choose to enable a wildcard certificate, skip to step 7. 28

29 5. If you didn't enable a wildcard certificate on the Domain Scope page, on the Exchange Configuration page, select each of the following services, then click Next: a. Under Client Access server (Outlook Web App), select Outlook Web App is on the Intranet and specify the internal FQDN of your coexistence server. For example, Ex2010.corp.contoso.com. Then select Outlook Web App is on the Internet and specify the external FQDN of your coexistence server. For example, mail2.contoso.com. b. Under Client Access server (Exchange ActiveSync), select Exchange Active Sync is enabled and specify the external FQDN of your coexistence server. c. Under Client Access server (Web Services, Outlook Anywhere, and Autodiscover), select Exchange Web Services is enabled. Then select Outlook Anywhere is enabled and specify the external FQDN of your coexistence server. Then select Autodiscover is used on the Internet, select Long URL, and specify the Autodiscover URL you want to use for your coexistence server. For example, autodiscover.contoso.com. d. Under Hub Transport server Select Use mutual TLS to help secure Internet Mail and then specify the external FQDN of your coexistence server. e. Under Legacy Exchange server Select Use legacy domains and specify the FQDN of your Exchange 2007 server. For example, mail1.contoso.com. 6. On the Certificate Domains page, review the domains that will be added to this certificate. Verify the domains you specified on the previous page are present. Then, do the following and click Next: a. Click Add and specify the delegation domain for your coexistence server. For example, exchangedelegation.contoso.com. Click OK. b. Click Add and specify the OWA domain for your coexistence server. For example, owa.contoso.com. Click OK. c. Verify that the external FQDN of your exchange server is set as the common name. If it isn't, select the external FQDN entry and click Set as common name. 7. On the Organization and Location page, provide the relevant information. Location-related settings apply to the location of your coexistence server. Then click Next. 8. On the Certificate Configuration page, verify your settings and click New. 9. On the Completion page, click Finish. 10. Submit the generated request to a trusted third-party CA. You must select a certificate that allows for the number of domain names you specified in step 6. Follow the instructions from your CA to select and obtain a certificate. 11. Save the certificate obtained from the CA on a network location accessible to your coexistence server. Learn more at: Understanding Digital Certificates and SSL How do I import and configure the certificate? After you have obtained a certificate, complete the following steps on the coexistence server to import your certificate and configure Exchange services to use the certificate for coexistence: 29

30 1. In the console tree, click Server Configuration for the on-premises Exchange organization node. 2. From the action pane, click Import Exchange Certificate to open the Import Exchange Certificate wizard. 3. On the Introduction page, click Browse to select the file that contains the certificate to be used for coexistence, and then enter the password for the certificate. 4. On the Exchange Server Selection page, select the on-premises coexistence server, and then click Next. 5. On the Import Exchange Certificate page, verify that all previously selected options are correct, and then click Import. 6. On the Completion page, verify that the certificate import was successful and click Finish. 7. In the console tree, click Server Configuration for the on-premises Exchange organization node and then select the certificate you just imported. 8. In the action pane, click Assign Services to Certificate to open the Assign Services to Certificate wizard. 9. On the Select Servers page, select the on-premises coexistence server, and then click Next. 10. On the Select Services page, use the check boxes in the Select Services section to choose the services you want to assign to your certificate. If you chose services during certificate creation, check boxes for these services will already be checked. You must, at a minimum, select Simple Mail Transfer Protocol (SMTP) and Internet Information Services (IIS). Click Next. 11. On the Assign Services page, verify the configuration summary and click Assign. 12. On the Completion page, verify that all the services were assigned correctly. How do I know this worked? The successful completion of the Import Exchange Certificate and the Assign Services to Certificate wizards will be your first indication that importing and assigning services to the certificate worked as expected. To further verify that the certificate has been successfully imported, you can run the following command in the Exchange Management Shell on the coexistence server to view the certificates in the local certificate store and the services assigned to the certificate. Get-ExchangeCertificate Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration 30

31 Configure Address Policy with Exchange 2007 The Exchange 2010 coexistence server that you're introducing to your Exchange 2007 organization will handle mail transportation and routing of messages. Therefore, you'll need to modify the address policy for your users and mail-enabled objects. Adding a shared service-routing namespace as a custom secondary domain for your recipients enables them to receive messages that use the service routing namespace. Learn more at: Understanding Shared and Split SMTP Namespaces with Exchange 2007 How do I do this? You can update your existing default recipient address policy using the Exchange Management Console on either your Exchange 2007 server or Exchange 2010 coexistence server. We recommend updating the default recipient address policy using the Exchange Management Console on your Exchange 2007 server: 1. In the console tree, navigate to Organization Configuration > Hub Transport on your Exchange 2007 server. 2. In the result pane, click the Address Policies tab, and then select the default recipient address policy. 3. In the action pane, click Edit. 4. On the Introduction page, click Next. 5. On the Conditions page, click Next. 6. On the Addresses page, select Add to enter an address for your servicerouting namespace. 7. On the SMTP Address dialog, check the address local part check box and select the Use alias radio button. Additionally, select the Select the accepted domain for the address radio button and use the Browse button to select the FQDN of your service-routing namespace from a list of Accepted Domains. For example, service.contoso.com. Click OK after selecting the service-routing namespace in the Select Accepted Domain dialog and then click OK to continue. 8. Click Next to continue. 9. On the Schedule page, select the radio button for Immediately in the Apply the address policy section. 10. Click Next to continue. 11. On the Edit Address Policy page, review your configuration settings. Click Edit to apply your changes to the address policy. Click Back to make any configuration changes. 12. On the Completion page, review the following, and then click Finish to close the wizard: A status of Completed indicates that the wizard completed the task successfully. 31

32 A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. 13. Click Finish to close the wizard. How do I know this worked? After you've added the new namespace to the address policy and waited for the policy to update, you should see the namespace in each recipient's address list. For example, [email protected]. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure Outlook Anywhere Outlook Anywhere enables users in remote office or mobile users to connect their Microsoft Office Outlook 2007 or later clients to your Exchange organization without requiring them to connect to a virtual private network (VPN). Learn more at: Understanding Outlook Anywhere Important In addition to your coexistence server, your other on-premises Exchange servers must also be configured for Outlook Anywhere (formerly known as RPC over HTTP) if you want remote users to be able to connect remotely to those servers without using a VPN. Learn more at: Configure Outlook Anywhere in an Environment with Earlier Versions of Exchange How do I do this? You can use the Exchange Management Console on the coexistence server to enable Outlook Anywhere. 1. In the console tree for the on-premises organization, navigate to Server Configuration > Client Access. 2. In the action pane, click Enable Outlook Anywhere. 3. In the Enable Outlook Anywhere wizard, type the external host name or URL for your organization in the box under External host name. Note: This is the URL that users will use to connect to the Exchange server by using Outlook Anywhere. For example mail2.contoso.com, 4. Select an available external authentication method. You can select Basic authentication or NTLM authentication. 32

33 5. If you're using an SSL accelerator and you want to use SSL offloading, select the check box next to Allow secure channel (SSL) offloading. Important: Don't use this option unless you're sure that you have an SSL accelerator that can handle SSL offloading. If you don't have an SSL accelerator that can handle SSL offloading, and you select this option, Outlook Anywhere won't function correctly. 6. Click Enable to apply these settings and enable Outlook Anywhere. 7. Click Finish to close the Enable Outlook Anywhere wizard. How do I know this worked? After you enable Outlook Anywhere on your coexistence server and your other on-premises Exchange servers, you can test for end-to-end client Outlook connectivity by doing either of the following: Run the Test-OutlookConnectivity cmdlet. The cmdlet tests for Outlook Anywhere and TCP/IP connections. If the cmdlet test fails, the output notes the step that failed. Run the Outlook Anywhere connectivity test using the Exchange Remote Connectivity Analyzer (ExRCA). When you run this test, you get a detailed summary showing where the test failed and what steps you can take to fix issues. Both tests try to log on through Outlook Anywhere after obtaining server settings from the Autodiscover service. End-to-end verification includes the following: Testing for Autodiscover connectivity. Validating DNS. Validating certificates (whether the certificate name matches the Web site, whether the certificate has expired, and whether it's trusted). Checking that the firewall is set up correctly (ExRCA checks overall firewall setup. The cmdlet tests for Windows firewall configuration.) Confirming client connectivity by logging on to the user's mailbox. Learn more at: Test Outlook Anywhere Connectivity Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure service autodiscover DNS record To enable Outlook 2010, Outlook 2007, and mobile clients to connect to mailboxes in the cloudbased organization, you need to configure an Autodiscover DNS record for the cloud-based organization. The Autodiscover DNS record must be created on the namespace that you're using for recipients in the cloud-based organization. For example, if your service namespace is 33

34 service.contoso.com, the Autodiscover DNS record you need to create is autodiscover.service.contoso.com. How do I do this? You need to create a CNAME DNS record that refers DNS requests for autodiscover.service.contoso.com to the Autodiscover DNS record for the cloud-based organization. The Autodiscover DNS record for the cloud-based organization is autodiscover.outlook.com The DNS record that you need to create is the following: Autodiscover record DNS record type Target Autodiscover.service.contoso.com CNAME Autodiscover.outlook.com Refer to your DNS host's Help for more information about how to add a CNAME record to your DNS zone. How do I know this worked? To verify that you've created your Autodiscover DNS record correctly, do the following on an Internet-accessible computer that can perform DNS lookups. 1. Open a Windows command prompt. 2. Run the following command. nslookup autodiscover.service.contoso.com The following should be returned if you've correctly configured the DNS record. (Depending on your DNS configuration, it may take an hour or more for changes to DNS to replicate across the Internet.) The IP address returned may be different than the address in the example below. Server: dns.corp.contoso.com Address: Non-authoritative answer: Name: autodiscover.outlook.com Address: Aliases: autodiscover.service.contoso.com 34

35 Configure federated delegation for coexistence Federated delegation is a relationship established between your on-premises organization and the cloud-based service that uses a federation trust with the Microsoft Federation Gateway. Federated delegation is a requirement for configuring centralized mail delivery and many mailbox management features. Additionally, when coupled with configuring an organization relationship between the Exchange organizations, it enables users in both organizations to share their calendar availability (free/busy) information with each other. Federated delegation is also a requirement for other rich messaging features such as MailTips, Message Tracking, and Multi- Mailbox Search. Configuring federated delegation for your on-premises organization requires several steps: 1. Create a federation trust with the Microsoft Federation Gateway for your on-premises organization. (A federation trust with the gateway for the cloud-based organization is automatically created when you create the cloud-based service account.) 2. Create domain proofs for the domain you want to use as the account namespace and for any other domain you want to add as a federated domain on the Microsoft Federation Gateway. We recommend that you use a domain namespace for the federated account namespace that's different from the domain you're using as your primary SMTP domain. To differentiate that this subdomain is used for federated delegation functionality, we recommend creating a separate subdomain of "exchangedelegation". An example of a federated delegation subdomain is exchangedelegation.contoso.com. 3. Create a text (TXT) record in the Domain Name System (DNS) zone of each accepted domain you want to federate. The TXT record contains the federated domain proof encryption string generated in the previous step. 4. Configure the domains for federation. Learn more at: Understanding Federated Delegation How do I create a federation trust with the Microsoft Federation Gateway? You can use the New Federation Trust wizard in the Exchange Management Console (EMC) on the coexistence server to create the federation trust with the Microsoft Federation Gateway for the on-premises organization. 1. In the console tree, click Organization Configuration for the on-premises Exchange forest. 2. In the action pane, click New Federation Trust. 3. On the New Federation Trust page, click New. Note: This automatically creates a self-signed certificate for the federation trust with the gateway and deploys the self-signed certificate to the Exchange servers in your 35

36 organization. The default name of the new federation trust is Microsoft Federation Gateway. 4. On the Completion page, click Finish to close the wizard. How do I create domain proofs for federated domains? You must use the Exchange Management Shell to create the domain proofs for your federation domain and your primary SMTP domain. Run the Get-FederatedDomainProof cmdlet for both of these domains. This example generates the domain proof string used for the TXT record for the federated delegation domain exchangedelegation.contoso.com and the primary SMTP domain contoso.com. Get-FederatedDomainProof -DomainName exchangedelegation.contoso.com Get-FederatedDomainProof -DomainName contoso.com Save the output values returned in the Proof field because you'll need them in the next step. Paste the output values into a text editor, such as Notepad, so that you can copy it from the text editor and then paste it into the Text field of the TXT record property. How do I create a TXT record in DNS for the accepted domains? Now you must add TXT records for both the exchangedelegation.contoso.com domain and the contoso.com domain. Each TXT record must include the domain proof string that was generated when you ran the Get-FederatedDomainProof cmdlet in the previous step. For example, if the federated domain is exchangedelegation.contoso.com and your primary SMTP domain is contoso.com, the TXT records would be similar to the following: Domain exchangedelegatio n.contoso.com contoso.com DN S rec ord typ e TX T TX T Text 7Zyr2i/fE/M/T3AwCpitDbF30Fk/TdzXME6f7d1lDaKGthPdoS+UF94t4 3D2nU5hLNnIAP+5A3jJR2ik9HDPgg== Eh/po5qT098GMPklJU2DShrYO9mPseTn5i9wWKOKebmceLPuLCp aejyj83w53h/ycuzpy2vso621bho4dns7jg== Refer to your DNS host's Help for information about how to add a TXT record to your DNS zone. 36

37 How do I configure the domains for federation? You can use the Manage Federation wizard in the EMC on the coexistence server to configure federation for the accepted domains: 1. In the console tree, navigate to Organization Configuration for the on-premises Exchange forest and then select the Microsoft Federation Gateway federation trust 2. In the action pane, click Manage Federation. 3. On the Manage Federation Certificate page, information is displayed for the certificates used for the federation trust. This includes information for the current certificate, the next certificate, and the previous certificate. Select the current certificate and make sure the Contacting the Microsoft Federation Gateway to get its certificate and federation metadata check box is selected. Click Next to continue. Note: It is normal for the certificate Distribution Status to be displayed as Unknown in the Manage Federation Certificate list. To update the distribution status, click the Show distribution state control. 4. On the Manage Federated Domains page, click Add to add the federated delegation domain as a federated domain first. By selecting the federated delegation domain first, it will be automatically designated as the account namespace for the federation trust. The Select Accepted Domain dialog box displays all accepted domains in the Exchange 2010 organization. For example, select the exchangedelegation.contoso.com domain to set this domain as the Account Namespace. 5. On the Manage Federated Domains page, click Add to also add the primary SMTP domain as a federated domain. For example, select the contoso.com domain. 6. Verify that the federated delegation domain is displayed with bold formatting. This bold formatting indicates that it is designated as the account namespace for the federation trust. If it is not designated as the account namespace, select the federated delegation domain and click the Set as Account Namespace control to designated it as the account namespace. Note: It is normal for the domain State to be displayed as Unknown in the Manage Federated Domains list. 7. In the address of organization contact box, enter the address of the designated organization contact for federation. This address is used only as a contact address and doesn't have any federated delegation configuration properties. 8. Select the Enable Federation check box to enable federation. You can also use this check box to disable federation for the Exchange organization if needed. Click Next to continue. 9. On the Manage Federation page, review the Configuration Summary, and then click Manage to execute the changes. 10. On the Completion page, click Finish to close the wizard. 37

38 How do I know this worked? The successful completion of the federated delegation process for your on-premises organization depends on several separate configuration settings. So, you should verify that each component area has been correctly configured. Federation Trust The successful completion of the New Federation Trust wizard will be your first indication that the federation trust creation process worked as expected. To verify that the federation trust has been created successfully, open the EMC and select the Organization Configuration node. Click the Federation Trust tab to display the properties of the federation trust with the Microsoft Federation Gateway. To further verify that the federation trust was created successfully, you can run the Get- FederationTrust and the Get-FederationInformation cmdlets in the Exchange Management Shell. These cmdlets output the properties of the federation trust that have been configured for your on-premises organization. You should also create a test user account using the New-TestCasConnectivity User.ps1 script located in <ExchangeInstallPath>\Scripts and then run the Test-FederationTrust cmdlet in the EMC to verify that delegation tokens can be properly received from the Microsoft Federation Gateway. TXT Records You can verify the TXT records are correctly configured by viewing the record properties in your DNS management tools or by using the Nslookup command-line tool. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure Organization Relationships with Exchange 2007 Creating an organization relationship between your on-premises organization and the cloudbased organization enables users in both organizations to securely share their calendar availability (free/busy) information with each other. To enable sharing, you will need to create an organization relationship for both your on-premises organization and your cloud-based organization. Creating an organization for your on-premises organization configures the calendar availability (free/busy) information options that define what your on-premises users are allowed to share with your cloud-based service users. Learn more at: Understanding Federated Delegation How do I do create an organization relationship for my on-premises organization? You can use the New Organization Relationship wizard in the Exchange Management Console on the coexistence server to create the organization relationship. 38

39 1. In the console tree, click Organization Configuration for the on-premises Exchange forest. 2. In the action pane, click New Organization Relationship. 3. On the Introduction page, complete the following fields: Name Type a name for the organization relationship. For example, "To Cloud" would distinguish that this relationship is for the cloud-based organization. Enable this organization relationship Select this check box to enable this organization relationship. Enable free/busy information access Select this check box to specify that this organization relationship should be used for retrieving free/busy information from the onpremises organization by the cloud-based organization. Specify free/busy data access level Select one of these options to specify what type of free/busy information should be retrieved from the on-premises organization by the cloud-based organization: Free/busy access with time only or Free/busy access with time, plus subject and location Specify a security distribution group that indicates what internal users free/busy data is accessible Select this check box if you want to specify a distribution group to list your users who can have their free/busy information accessed by the cloud-based service organization. Use the corresponding box to type the SMTP address of a security distribution group within your organization, or click Browse to search for the group. 4. On the External Organization page, complete the following fields: Automatically discover configuration information Select this option to have Exchange locate the configuration information of the cloud-based organization by using Autodiscover. Specify a federated domain of the external Exchange organization Enter a federated domain of the cloud-based organization (for example, service.contoso.com). You can't specify more than one domain. Note: You can also choose to manually enter the federated domains for the cloud-based organization during this step. If you elect to manually configure the federated domains, enter both the service-routing namespace and the primary SMTP namespaces for your on-premises organization. For example, the federated domains include both the service.contoso.com and contoso.com domains. If either of these domains is missing from the organization relationship, the sharing of free/busy availability information may not function correctly. 5. On the New Organization Relationship page, review your configuration settings. Click New to create the organization relationship. Click Back to make changes. 6. On the Completion page, review the following, and then click Finish to close the wizard: A status of Completed indicates that the wizard completed the task successfully. 39

40 A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. During the Office 365 Beta program, you must also manually configure TargetSharingEpr parameter for the on-premises organization relationship in order for on-premises users to access free/busy information for cloud-based organization user calendars. 1. Log on to Outlook Web App for Office 365 using the test mailbox you created earlier in the checklist. 2. On the main Outlook Web App page, click the Help icon and select About from the drop down list. 3. On the About page, make a note of the information listed for the Host name and the Client Access server version fields: a. The Host name will list the endpoint you will manually enter for the TargetSharingEpr parameter for the on-premises organization relationship with the cloud-based organization. For example, the Host name will be similar in format to "sn1prd0992.outlook.com". b. The Client Access server version must be or greater. If the server version is less than , you will need to log on to a different cloud-based user account to obtain the Host name endpoint for the TargetSharingEpr parameter. 4. Use the following command in the Shell on the on-premises coexistence server to set the TargetSharingEpr parameter. Set-OrganizationRelationship -Identity To Cloud" -TargetSharingEpr " After creating the organization relationship, you must also manually add the primary SMTP namespace and enable MailTips and message tracking for the organization relationship so these features function correctly. If you chose to manually add both the service-routing and primary SMTP namespaces as federated domains in the New Organization wizard, you will only have to enable MailTips and message tracking. To add the primary SMTP namespace and enable MailTips and message tracking to the onpremises organization relationship, use the following command in the Shell on the coexistence server. Set-OrganizationRelationship -Identity "To Cloud" -DomainNames "service.contoso.com","contoso.com" -MailTipsAccessEnabled $True - MailTipsAccessLevel All -DeliveryReportEnabled $True After creating the organization relationship, you must add an address availability space to define the access method and credentials used to exchange free/busy information between your Exchange 2007 Mailbox server and the coexistence server. 1. To add an address availability space for your on-premises organization, use the following command in the Shell on the coexistence server: Add-AddressAvailabilitySpace -AccessMethod InternalProxy -ForestName service.contoso.com -UseServiceAccount $True 40

41 How do I do create an organization relationship for my cloud-based organization? You can use the New Organization Relationship wizard in the Exchange Management Console on the coexistence server to create the organization relationship. 1. In the console tree, click Organization Configuration for the cloud-based organization Exchange forest. 2. In the action pane, click New Organization Relationship. 3. On the Introduction page, complete the following fields: Name Type a name for the organization relationship. For example, "To On-Premises" would distinguish that this relationship is for the on-premises organization. Enable this organization relationship Select this check box to enable this organization relationship. Enable free/busy information access Select this check box to specify that this organization relationship should be used for retrieving free/busy information from the cloud-based organization by the on-premises organization. Specify free/busy data access level Select one of these options to specify what type of free/busy information should be retrieved from the cloud-based organization by the onpremises organization: Free/busy access with time only Free/busy access with time, plus subject and location Specify a security distribution group that indicates what internal users free/busy data is accessible Select this check box if you want to specify a distribution group to list your users who can have their free/busy information accessed by the on-premises organization. Use the corresponding box to type the SMTP address of a security distribution group within your organization, or click Browse to search for the group. 4. On the External Organization page, complete the following fields: Automatically discover configuration information Click this button to have Exchange locate the configuration information of the on-premises organization by using Autodiscover. Specify a federated domain of the external Exchange organization Enter a federated domain of the on-premises organization (for example, contoso.com). You can't specify more than one domain. Note: You can also choose to manually enter the federated domains for the onpremises organization during this step. If you elect to manually configure the federated domains, enter both the federated delegation namespace and the primary SMTP namespace for your on-premises organization. For example, the federated domains include both the exchangedelegation.contoso.com and contoso.com domains. If either of these domains is missing from the organization 41

42 relationship, the sharing of free/busy availability information may not function correctly. 5. On the New Organization Relationship page, review your configuration settings. Click New to create the organization relationship. Click Back to make changes. 6. On the Completion page, review the following, and then click Finish to close the wizard: A status of Completed indicates that the wizard completed the task successfully. A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. After creating the organization relationship, you must also manually add the federated delegation namespace and enable MailTips and message tracking for the organization relationship so these features function correctly. If you chose to manually add both the federated delegation and primary SMTP namespaces as federated domains in the New Organization wizard, you will only have to enable MailTips and message tracking. To add the federated delegation namespace and enable MailTips and message tracking for the cloud-based organization relationship, use the following command in the Shell on the cloudbased organization. Set-OrganizationRelationship -Identity "To On-premises" -DomainNames "exchangedelegation.contoso.com","contoso.com" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True After the Office 365 Beta program has concluded After the Office 365 Beta program has concluded, you should use the Shell to remove the endpoint for the TargetSharingEpr parameter for the on-premises organization relationship and use the EMC on the coexistence server to automatically reconfigure the endpoint for the TargetAutodiscoverEpr parameter. 1. Use the following command on the on-premises coexistence server to remove the endpoint for the TargetSharingEpr parameter. Set-OrganizationRelationship -Identity "To Cloud" -TargetSharingEpr $Null 2. In the console tree, click Organization Configuration for the on-premises Exchange forest and select the on-premises organization relationship. For example, "To Cloud". 3. On the Action pane, select Properties. 4. On the Properties page, select the External Organization tab and then select Automatically discover configuration information. 5. Click OK. Important: Verify that the organization relationship has been correctly updated by using the Get- OrganizationRelationship cmdlet. You should see an endpoint listed for the 42

43 TargetAutodiscoverEpr parameter and the TargetSharingEpr parameter should be undefined. How do I know this worked? The successful completion of the New Organization Relationship wizard will be your first indication that creating the organization relationship worked as expected. To further verify that the organization relationship is configured correctly, you can also run the following command in the Shell. Get-OrganizationRelationship fl Learn more at: Set-OrganizationRelationship and Configure Organization Relationship Properties Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure Outlook Web App with Exchange 2007 When you configure coexistence between your on-premises Exchange 2007.organization and the cloud-based organization, your users will see two Outlook Web App URLs. The first URL refers to your on-premises Exchange 2007 Client Access server, and the second URL is the cloud-based URL used by mailboxes that you move to the cloud. If you want to make the transition easier for users whose mailboxes are moved to the cloud, you can configure the Exchange 2010 coexistence server to handle all Outlook Web App requests using a single, common URL. The following will happen when an Outlook Web App request arrives at the coexistence server: Request for an Exchange 2007 mailbox The coexistence server automatically redirects Outlook Web App requests for Exchange 2007 mailboxes to the Internet-accessible Exchange 2007 Client Access server. Request for a cloud-based mailbox The coexistence server displays the Outlook Web App URL in the cloud-based organization and instructs the user to use the new URL. The user has the option to add the new URL to their browser's Favorites list. To configure Outlook Web App for coexistence, you must also do the following: Make both your Exchange 2007 Client Access and Exchange 2010 coexistence servers accessible from the Internet and configure external FQDNs for each server. This task is covered later in this checklist. When you're ready for your coexistence server to accept incoming Outlook Web App requests, reconfigure your primary Outlook Web App URL to reference the coexistence server external FQDN. We recommend that you use owa.<domain> for your primary 43

44 Outlook Web App URL. For example, owa.contoso.com. This task is covered later in this checklist. Learn more at: Understanding Access to Outlook Web App with a Single URL with Exchange 2007 How do I configure on-premises Outlook Web App redirect? For the coexistence server to redirect Outlook Web App requests from users who have mailboxes on an Exchange 2007, the InternalUrl and ExternalUrl properties on the Exchange 2007 Client Access servers must be set correctly. The InternalUrl property should be set to the URL that's used by users to access their Exchange 2007 mailbox from your internal network. The ExternalUrl property should be set to the URL that's used by users to access their Exchange 2007 mailbox from the Internet. On each Exchange 2007 Client Access server, do the following in the Shell: 1. Check the configuration of Outlook Web App ExternalUrl and InternalUrl properties: Get-OwaVirtualDirectory "Ex2007\OWA (Default Web Site)" Format- Table InternalUrl, ExternalUrl 2. Verify that the values set in the InternalUrl and ExternalUrl properties are set correctly. 3. If the values aren't set correctly, configure the correct URLs: Set-OwaVirtualDirectory "Ex2007\OWA (Default Web Site)" -InternalUrl " -ExternalUrl " 4. Repeat for each Exchange 2007 Client Access server in your organization. How do I configure cloud-based Outlook Web App redirect? To enable the coexistence server to display the Outlook Web App URL for the cloud-based organization to users whose mailboxes have been moved to the service, use the following command on the coexistence server: Important: Don't add a trailing slash ( / ) to the end of the URL in the following command. Set-OrganizationRelationship "To Cloud" -TargetOWAUrl " How do I know this worked? Use the following steps to validate that you've correctly set up Exchange 2007 Outlook Web App and cloud-based Outlook Web App redirection. 44

45 Important: You haven't reconfigured your primary Outlook Web App URL to reference the coexistence server yet. To test your configuration, you'll need to reference the externally accessible FQDN of the coexistence server. You'll reconfigure your primary Outlook Web App URL at a later step in the checklist. To verify whether you've correctly configured Exchange 2007 redirection, do the following: 1. Browse to the Outlook Web App URL of your coexistence server. You need to use the externally accessible FQDN of the coexistence server. For example, 2. Enter the credentials of a mailbox that's located on your Exchange 2007 server. 3. If Exchange 2007 redirection is working, the coexistence server will automatically redirect your request to the Exchange 2007 server and log you on to the mailbox automatically. To check whether you've correctly configured cloud-based redirection, do the following: 1. Browse to the Outlook Web App URL of your coexistence server. You need to use the externally accessible FQDN of the coexistence server. For example, 2. Enter the credentials of the test mailbox that you created in the cloud-based organization. 3. If cloud-based OWA redirection is working, the coexistence server should present you with the new Outlook Web App URL that you can use to open the mailbox in the cloud using Outlook Web App. You can click the link to take you to the cloud-based service, and you can click Add to Favorites to add the cloud-based URL to your browser's Favorites list. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure Send and Receive Connectors with Exchange 2007 Before the Exchange 2010 coexistence server can send or receive messages to or from the cloud-based organization, you need to create a Send connector for the service-routing namespace and configure the existing default Receive connector to accept anonymous connections from the Internet. Learn more at: Understanding Send Connectors, Understanding Receive Connectors How do I create a Send connector? Do the following on the coexistence server to create a Send connector. 1. In the console tree, click Organization Configuration in the on-premises forest, and then click Hub Transport. 45

46 2. In the action pane, click New Send Connector. 3. On the Introduction page, in the Name field, enter the name of the new send connector that will be used to send messages to the cloud-based organization. For example, To Cloud Service Connector. 4. In the Select the intended use for this Send connector drop-down box, select Internet, and then click Next. 5. On the Address space page, click Add. 6. In the SMTP Address Space dialog, enter the service-routing namespace in the Address space field, and then click OK. For example, service.contoso.com. Click Next. 7. On the Network settings page, select Use domain name system (DNS) "MX" records to route mail automatically and click Next. 8. On the Source Server page, verify the Exchange 2010 coexistence server is included in the server list. If not, click Add, select the Exchange 2010 coexistence server, and then click OK. Click Next. 9. On the New Connector page, verify your settings and then click New. 10. In the details pane, right-click the new Send connector and then click Properties. 11. In the Properties dialog, enter the external fully qualified domain name (FQDN) of the Exchange 2010 coexistence server in the Specify the FQDN this connector will provide in response to HELO or EHLO field. For example, mail2.contoso.com. Click OK. How do I configure the default Receive connector? Do the following on the coexistence server to configure the default Receive connector to accept connections from the Internet. Important: Be sure to configure a new external IP address on your firewall to accept inbound connections on TCP port 25. Then direct connections on that IP address to the internal IP address of your coexistence server. For more information, see your firewall's documentation. 1. In the console tree, click Server Configuration in the on-premises forest, and then click Hub Transport. 2. Select the Exchange 2010 coexistence server in the details pane, right-click Default EX2010, and then click Properties. 3. In the Receive connector properties window, click the Permission Groups tab. 4. Select Anonymous Users, and then click OK. 46

47 How do I know this worked? If you've successfully created a new Send connector, the Send connector will appear in the details pane under Organization Configuration > Hub Transport. If you've successfully configured the default Receive connector, the Receive connector will accept connections from anonymous connections from the Internet. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure centralized transport with Exchange 2007 You've chosen to route all the messages sent between the Internet and mailboxes in your cloud-based organization through your on-premises Exchange 2010 coexistence server. By routing messages through your on-premises coexistence server, you can apply transport rules, anti-virus policies, and anti-spam rules against the messages. The procedures in this step of your checklist configure the following mail flow in your organization: Messages sent between a mailbox in your cloud-based organization and the Internet will flow through the on-premises coexistence server. Messages sent between mailboxes in the cloud-based organization will remain within the cloud-based organization. They won't be sent through the on-premises coexistence server. Messages sent between an on-premises Exchange mailbox and a mailbox in your cloudbased organization will flow through the on-premises coexistence server. In addition to the settings you need to configure in your on-premises organization and in your cloud-based organization, you also need to configure settings in Forefront Online Protection for Exchange (FOPE). FOPE is located between your cloud-based organization and the Internet and provides anti-virus and anti-spam protection for your cloud-based mailboxes. FOPE also controls where outbound messages from your cloud-based organization are routed, and what senders are allowed to send mail to your cloud-based organization. Learn more at: Understanding Transport Options with Exchange 2007 How do I configure transport settings in my onpremises organization? For this procedure, you will use the Exchange Management Shell to configure the following: Transport Layer Security (TLS) for all messages sent between your on-premises and cloudorganizations. Inbound and outbound messages sent between your on-premises and cloud-organizations are trusted. Anti-spam rules won't be applied to these messages. 47

48 All mail sent to your cloud-based organization is routed through a FOPE smart host. 1. On your on-premises coexistence server, create a new remote domain for inbound messages received from the cloud-based organization. New-RemoteDomain "Inbound Remote Domain" -DomainName contoso.com 2. On your on-premises coexistence server, create a new remote domain for outbound messages sent to the cloud-based organization. New-RemoteDomain "Outbound Remote Domain" -DomainName service.contoso.com 3. On your on-premises coexistence server, configure the inbound remote domain to trust messages sent from the cloud-based organization. Set-RemoteDomain "Inbound Remote Domain" -TrustedMailInboundEnabled $True 4. On your on-premises coexistence server, configure the outbound remote domain to enable trusted delivery of messages to the cloud-based organization. Set-RemoteDomain "Outbound Remote Domain" - TrustedMailOutboundEnabled $True -TargetDeliveryDomain $True - AllowedOOFType InternalLegacy -AutoReplyEnabled $True - AutoForwardEnabled $True -DeliveryReportEnabled $True -NDREnabled $True -DisplaySenderName $True -TNEFEnabled $True 5. On your on-premises coexistence server, modify the To Cloud Send connector to enable TLS transport and route all mail sent to your cloud-based organization through a FOPE smart host using the following command. Set-SendConnector "To cloud" -RequireTLS $True -TlsAuthLevel DomainValidation -TlsDomain mail.messaging.microsoft.com -Fqdn mail2.contoso.com -ErrorPolicies DowngradeAuthFailures 6. On your on-premises coexistence server, set the following parameter on the Receive connector to enable the server to accept messages sent from the cloud-based organization as internal messages. Set-ReceiveConnector "ex2010\default ex2010" TlsDomainCapabilities mail.messaging.microsoft.com:acceptoorgprotocol How do I configure transport settings in my cloudbased organization? For this procedure, you will use the Shell to configure the following: Configure the shared SMTP domain as an internal relay domain and set the domain as outbound only. Inbound and outbound messages sent between your on-premises and cloud-organizations are trusted. Anti-spam rules won't be applied to these messages. 48

49 1. In the cloud-based organization, create a new remote domain for inbound messages received from the on-premises organization. The domain name must contain the name of the certificate published on the coexistence server. Note: This domain must match the FQDN you specify in the TLS certificate matching domain when you create the inbound FOPE connector later. New-RemoteDomain "Inbound Remote Domain" -DomainName mail2.contoso.com 2. In the cloud-based organization, create a new remote domain for outbound messages sent to recipients in the on-premises organization. The domain must be the domain portion of the recipient address of on-premises recipients. New-RemoteDomain "Outbound Remote Domain to On-Premises Recipients" -DomainName contoso.com 3. In the cloud-based organization, configure the inbound remote domain to trust messages sent from the on-premises organization. Set-RemoteDomain "Inbound Remote Domain" -TrustedMailInboundEnabled $True 4. In the cloud-based organization, configure the outbound remote domain to on-premises recipients to enable trusted delivery of messages to the on-premises organization and enable rich client features. Set-RemoteDomain "Outbound Remote Domain to On-Premises Recipients" -TrustedMailOutboundEnabled $True -TargetDeliveryDomain $True - AllowedOOFType InternalLegacy -AutoReplyEnabled $True - AutoForwardEnabled $True -DeliveryReportEnabled $True -NDREnabled $True -DisplaySenderName $True -TNEFEnabled $True 5. In the cloud-based organization, configure the outbound remote domain to Internet recipients to enable trusted delivery of messages to the on-premises organization. Set-RemoteDomain Default -TrustedMailOutboundEnabled $True 6. In the cloud-based organization, set the accepted domain for the shared SMTP domain to be an internal relay domain, and set the domain as outbound only, using the following command. Set-AcceptedDomain "contoso.com" -DomainType InternalRelay - OutboundOnly $True How do I configure FOPE to route mail to and from my on-premises organization? With this procedure, you'll configure the following: 49

50 Inbound connector in FOPE that accepts messages sent to your cloud-based organization only from your on-premises coexistence server. The connector is also configured to only accept messages sent using TLS. Outbound connector in FOPE that sends all messages sent from your cloud-based organization to the Internet through your on-premises coexistence server. The connector is also configured to send messages using TLS. 1. Browse to: FOPE administration center 2. If this is your first time accessing FOPE, do the following: a. Click Need your password. b. Enter the address of the account in the cloud-based service in the User name field. This is the address you specified when you created the account in the cloudbased service. For example, c. Log on to your cloud-based service admin account at Open the message sent by FOPE to that account and retrieve the password provided. d. Browse back to: FOPE administration center 3. Enter the address of the account in the cloud-based service in the User name field. 4. Enter your FOPE password in the Password field. 5. Click the Administration tab, and then click the Company tab. 6. Click Add next to Inbound Connectors under Internet endpoint connection settings. 7. In the Add inbound Connector dialog, configure the following: Name Enter a name for the inbound connector. Description Enter a description for the inbound connector. Source domains Leave this text box blank. It will be populated with *.* in the next step. Select the Apply this Connector to messages from any source domain check box. Source IP addresses Specify the source IP address that your firewall presents to hosts on the Internet. Depending on the configuration of your firewall, this might be the external IP address of your coexistence server, or it might be the WAN IP address of the firewall. Select the Reject messages not originating from these source IP addresses check box. Select the Forced TLS option. Select the Certificate matches domain checkbox and in the associated text field, specify the certificate subject name that you configured on the on-premises coexistence server. For example, mail2.contoso.com. Note: The FQDN you specify here must match the domain you specified when you created the "Inbound remote domain" in the cloud-based organization earlier. Click Save. 50

51 8. Click Enforce next to the inbound connector you just created. Select the check box in the Enforce Inbound Connector dialog box and then click OK. 9. Click Add next to Outbound Connectors under Internet endpoint connection settings. 10. In the Add outbound Connector dialog, configure the following: Name Enter a name for the outbound connector. Description Enter a description for the outbound connector. Destination domains Leave this text box blank. It will be populated with *.* in the next step. Select the Apply this Connector to messages that are sent to all destination domains check box. Select the Deliver all messages to the following destination check box. Select the FQDN option and specify the external FQDN of the on-premises coexistence server. For example, mail2.contoso.com. Select the The certificate domain matches the following option and in the associated text field, specify the certificate subject name that you configured on the on-premises coexistence server. For example, mail2.contoso.com. Click Save. 11. Click Enforce next to the outbound connector you just created. Select the check box in the Enforce Outbound Connector dialog box and then click OK. How do I configure an MX record? Before you can send messages to recipients in the cloud-based service that have a service.contoso.com SMTP address, you must add a mail exchanger (MX) record for the service.contoso.com domain. The MX record must refer to the FQDN created for your cloudbased organization. To find the FQDN that you should use to create your MX record, do the following: 1. Log on to: Cloud-based service administration portal 2. Click Admin, and then click Domains. 3. Click the SMTP namespace for your cloud-based organization. For example, service.contoso.com. Note: If no DNS settings are shown for your domain, contact Microsoft Office 365 support. 4. Click DNS Settings. 5. In the Exchange Online DNS records table, find the row where Type equals MX. Use the value in the Points to address field. For example, <value>.mail.eo.outlook.com. After you've found the FQDN to use with your MX record, create the MX record in your DNS zone. For example, the MX record for service.contoso.com is the following: 51

52 Delivery domain DNS record type MX priority Cloud-based organization domain service.contoso.com MX 0 <value>.mail.eo.outlook.com Refer to your DNS host's Help for more information about how to add an MX record to your DNS zone. How do I know this worked? To verify that you've correctly configured your transport settings, send test messages between the Internet and your cloud-based organization, and between on-premises Exchange mailboxes and mailboxes in your cloud-based organization. Then do the following to verify your settings are correct: To perform the following tests, you must have a test mailbox in your cloud-based organization. Verify recipients receive each of the test messages. In the SMTP headers of a message sent from the Internet to a cloud-based mailbox, verify that (TLS) is present on the hop between your on-premises coexistence server and the FOPE smart host. In the SMTP headers of a message sent to an Internet recipient from a cloud-based mailbox, verify that the message is correctly routed through your on-premises coexistence server. Also verify that (TLS) is present on the hop between your on-premises coexistence server and the FOPE server. In the SMTP headers of messages sent between on-premises mailboxes and cloud-based mailboxes, verify that the X-MS-Exchange-Organization-AuthAs header is set to Internal. If you're having problems configuring transport, you can enable protocol logging to provide you with additional information. Protocol logging enables you to record the conversations that take place between your coexistence server and other mail hosts. You can use this information to determine whether you're connecting to the correct mail hosts, whether SSL certificates are being exchanged, and so on. Learn more at: Understanding Protocol Logging, Configure Protocol Logging Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Create a test mailbox for shared domains We recommend that you create a test mailbox in the cloud-based organization so that you can test your configuration changes as you progress through the checklist. Learn more at: Understanding Coexistence 52

53 How do I do this? You can use the New Remote Mailbox wizard in the EMC on the coexistence server to create a test mailbox in the cloud-based organization. If you want to create more than one test mailbox, you'll have to use this wizard for each test mailbox. You can't use the wizard to create multiple test mailboxes. Note: You must have a remote domain configured as the target delivery domain for the cloudbased organization to complete the New Remote Mailbox wizard process. 1. In the console tree, click Recipient Configuration in the on-premises organization node. 2. In the action pane, click New Remote Mailbox. 3. On the Introduction page, select User Mailbox to create a mailbox that will be owned by a user to send and receive messages. Click Next to continue. 4. On the User Information page, specify the following settings: First Name Type the first name of the new user. Last Name Type the last name of the new user. User logon name Type the user logon name of the new user and select the primary SMTP domain used for your other on-premises users. For Password Type the password. Confirm password Retype the password. 5. Click Next to continue. 6. On the Archive Mailbox page, make sure the Add an archive mailbox check box is not selected. Click Next to continue. 7. On the New Remote Mailbox page, review your configuration settings. Click New to create the test mailbox. 8. On the Completion page, review the following, and then click Finish to close the wizard: A status of Completed indicates that the wizard completed the task successfully. A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. 9. Set the immutable ID of the new remote mailbox to the user principal name (UPN) of the mailbox. For example, if you set the UPN of the mailbox to [email protected], use run the following command in the Shell on the coexistence server. Set-Remot box david -ImmutableID [email protected] Note: By default, directory synchronization occurs once every three hours. To force immediate directory synchronization, open C:\Program Files\Microsoft Online Directory Sync\DirSyncConfigShell.psc1 on the Active Directory synchronization server and type the following at the command prompt. Start-OnlineCoexistenceSync 53

54 10. Log on to: Cloud-based service administration portal 11. Assign a license to the new user. Learn more at: Activate synced users How do I know this worked? When you create a test mailbox on the cloud-based organization, the successful completion of the New Remote Mailbox wizard will be your first indication that creating the mailbox worked as expected. To verify that you've created a test mailbox and that the mailbox is accessible in the cloud-based organization, do the following: 1. Log on to: Cloud-based service administration portal 2. Verify that the user has been synchronized to the service directory. If the user has synchronized correctly, the user will appear in the user list in the administration portal. 3. Verify that the user has an associated license by doing the following: a. Click the name of the user to open the user's property information. b. Click Licenses to view the licenses available to the user. If a license has been assigned to the user, the check box next to the license will be selected. 4. Attempt to log on to the user's mailbox by browsing to the cloud-based organization's Outlook Web App URL, and logging in with the user's credentials. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Redirect Outlook Web App connections to coexistence server for Exchange 2007 After you've configured the Exchange 2010 coexistence server to redirect Outlook Web App requests to either your Exchange 2007 server or the cloud-based organization, you need to direct Outlook Web App connections to the coexistence server. This step of the checklist assumes you've configured your Exchange 2007 and coexistence servers as follows: You can open TCP port 443 from the Internet to both the Exchange 2007 server and the coexistence server. This setting is required so that users can connect to the Outlook Web App Web site and for the cloud-based organization to connect to the Availability service to check free/busy availability. The Exchange 2007 server has an external fully qualified domain name (FQDN). For our purposes of providing an example, the external FQDN of the Exchange 2007 server is mail1.contoso.com. 54

55 The coexistence server has an FQDN. For our example purposes, the external FQDN of the coexistence server is mail2.contoso.com. Users accessing their mailbox use a dedicated Outlook Web App URL. For our example purposes, the URL is owa.contoso.com. The Outlook Web App URL points to the external FQDN of the Exchange 2007 server, which is mail1.contoso.com. Learn more at: Understanding Access to Outook Web App with a Single URL How do I do this? Redirecting inbound Outlook Web App connections to your coexistence server requires you take the following actions. 1. Configure your firewall to accept inbound connections on TCP port 443 for both your Exchange 2007 server and the coexistence server. Each server requires its own external IP address that directs inbound connections to the respective server's internal IP address. For more information about how to configure this, see your firewall's documentation. 2. Update the DNS records for your organization to point the external FQDNs of your Exchange 2007 and coexistence servers to the correct external IP addresses for each server. See the table below for examples. 3. Update DNS records for your organization to direct requests sent to owa.contoso.com to the FQDN of your coexistence server, mail2.contoso.com. The following table shows examples of the DNS record changes needed to redirect Outlook Web App connections to your coexistence server. FQDN DNS record type Target Mail1.contoso.com A Exchange 2007 server external IP Mail2.contoso.com A Coexistence server external IP Owa.contoso.com CNAME Mail2.contoso.com Refer to your DNS host's Help for more information about how to update DNS records in your DNS zone. How do I know this worked? If you've completed these steps successfully, users who access their mailboxes via Outlook Web App will be directed to the Outlook Web App login screen on the coexistence server. Verify the following behavior occurs: Exchange 2007 mailbox A user whose mailbox resides on the Exchange 2007 server should be redirected by the coexistence server to the Exchange 2007 Outlook Web App URL, 55

56 Cloud-based mailbox A user whose mailbox resides in the cloud-based organization should be presented with the Outlook Web App URL of the cloud-based organization, The user can then click the link to access their mailbox or add the link to their browser's favorites. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Move or create a mailbox for shared domains You can choose to either move existing mailboxes to the cloud-based organization or create mailboxes in the cloud-based organization. Move a mailbox Moving mailboxes from the on-premises organization to the cloud-based organization uses a remote mailbox move request. This approach allows you to move your existing Exchange user mailboxes to the cloud-based organization instead of creating user mailboxes and importing their mailbox content. Create a mailbox Instead of moving existing mailboxes in your on-premises organization to the cloud-based organization, you can create mailboxes in the cloud-based organization for users in your Exchange organization. These mailboxes are called remote mailboxes, and they are included in the on-premises Active Directory. Active Directory synchronization (DirSync) automatically synchronizes this new mail user object to the cloud-based service which then converts it to a user mailbox. Learn more at: Understanding Recipients How do I move mailboxes to the cloud-based organization? You can use the New Remote Move Request wizard in the Exchange Management Console (EMC) on the coexistence server to move existing user mailboxes in the on-premises organization to the cloud-based organization: 1. In the console tree, click the Recipient Configuration node for the on-premises Exchange forest. 2. Click Mailbox, and select one or more user mailboxes from the Result pane. Note: By default, the Mailbox Replication Proxy service (MRSProxy) running on the coexistence server automatically throttles the mailbox move requests when you select multiple mailboxes to move to the cloud-based service. The total time to complete the mailbox move depends on the total number of mailboxes selected, the size of the mailboxes, and the properties of the MRSProxy. To learn more about customizing the MRSProxy, see: Throttling the Mailbox Replication Service 56

57 3. In the action pane, select New Remote Move Request. 4. On the Introduction page, view the mailboxes that you selected in the result pane. If you want to remove or add recipients, click Cancel, and then make the changes in the result pane. 5. Select Move only the user mailbox, and then select Next. 6. On the Connection Configurations page, specify the following settings: Source Forest This read-only field displays the on-premises organization on which the mailboxes that you are moving reside. Target Forest Select the cloud-based organization from the list. FQDN of the Mailbox Exchange Mailbox Replication Service proxy server in the source forest Type the name of the externally-accessible FQDN for the on-premises organization coexistence server on which the MRS proxy resides. For example, mail2.contoso.com. Use the following source forest's credential Enter the credentials of a recipient administrator who has permission to move mailboxes from the on-premises organization. User Name Type the administrator's domain and user name. Password Type the administrator's password. 7. Click Next to continue. 8. On the Move Settings page, for Target Delivery Domain, type the FQDN of the cloudbased service. For example, service.contoso.com. 9. Click Next to continue. 10. On the New Remote Move Request page, review the settings for this remote move request, and then click New. 11. On the Completion page, review the following, and then click Finish to close the wizard: A status of Completed indicates that the wizard completed the task successfully. A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. 12. Log on to: Cloud-based service administration portal 13. Assign a license to the new user. Learn more at: Activate synced users After the mailbox move request reaches a status of Completed or Completed with warning, you must clear the move request to remove the InTransit flag from the mailbox. You won't be able to move the mailbox again until you clear the previous move request. 1. In the console tree, click the Recipient Configuration node for the cloud-based Exchange forest. 2. Click Move Request, and select one or more recipients that have a Move Request Status of Completed or Completed with warning. 3. In the action pane, click Clear Move Request. 4. A warning message appears confirming that you want to clear the move request. Click Yes. 57

58 How do I do create a mailbox in the cloud-based organization? You can use the New Remote Mailbox wizard in the EMC on the coexistence server to create user mailboxes in the cloud-based organization. If you want to create remote mailboxes, you'll have to use this wizard for each remote mailbox. You can't use the wizard to create multiple remote mailboxes. Note: You must have a remote domain configured as the target delivery domain for the cloudbased organization to complete the New Remote Mailbox wizard process. 1. In the console tree, click Recipient Configuration in the on-premises organization node. 2. In the action pane, click New Remote Mailbox. 3. On the Introduction page, select User Mailbox to create a mailbox that will be owned by a user to send and receive messages. Click Next to continue. 4. On the User Information page, specify the following settings: First Name Type the first name of the new user. Last Name Type the last name of the new user. User logon name Type the user logon name of the new user and select the primary SMTP domain used for your other on-premises users. For Password Type the password. Confirm password Retype the password. 5. Click Next to continue. 6. On the Archive Mailbox page, make sure the Add an archive mailbox check box is not selected. Click Next to continue. 7. On the New Remote Mailbox page, review your configuration settings. Click New to create the remote mailbox. 8. On the Completion page, review the following, and then click Finish to close the wizard: A status of Completed indicates that the wizard completed the task successfully. A status of Failed indicates that the task wasn't completed. If the task fails, review the summary for an explanation, and then click Back to make any configuration changes. 9. Log on to: Cloud-based service administration portal 10. Assign a license to the new user. Learn more at: Activate synced users How do I know this worked? When you move existing user mailboxes to the cloud-based organization, the successful completion of the New Remote Move Request wizard will be your first indication that moving the mailbox worked as expected. 58

59 Because the mailbox move process takes several minutes to complete, you can also verify that the move is working correctly by opening the EMC and selecting the on-premises organization Recipient Configuration node. Select the Move Request node to display the move status for the mailboxes selected in the New Remote Move Request wizard. The value of the Move Request Status is Moving during the mailbox move and is Completed when the mailbox has successfully moved to the cloud-based service organization. Learn more at: View Move Request Properties After the directory replication process has completed, you can check that the remote mailbox located on the cloud-based organization has been successfully created by verifying the mailbox properties. To do this, navigate to the Recipient node in the EMC for the on-premises organization and log on to the cloud-based service. Then, navigate to Admin Services > User Management > Users. The user mailbox should be available and configurable. Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Configure cloud-based mailboxes for federated sharing Federated sharing requires an immutable identifier that uniquely identifies a mailbox to other Exchange organizations. The immutable identifier (immutable ID) must be explicitly set on each cloud-based mailbox and should match the user principal name (UPN) of the mailbox. The ImmutableID property must be set on the on-premises object associated with the cloud-based mailbox, which is then synchronized to the cloud-based organization. Learn more at: Understanding Federated Delegation How do I configure a mailbox that's been moved to the cloud-based organization? In the Exchange Management Shell on the coexistence server, do the following to set the immutable ID of a mail user to the UPN of that mail user. 1. Retrieve the UPN of the mail user you want to configure. Get-MailUser david Format-Table Name, Alias, UserPrincipalName 2. Set an unused property on the mail user to upgrade it to a version that can be managed by the coexistence server. In this example, the ModeratedBy property is used. Respond "Yes" to the prompt asking if you want to upgrade the object. Set-MailUser david -ModeratedBy administrator 3. Set the immutable ID of the mail user to the mail user's UPN. Set-MailUser david -ImmutableID [email protected] 59

60 4. Clear the property that was set to upgrade the object. Respond "Yes" to the prompt asking if you want to upgrade the object. Set-MailUser david -ModeratedBy $Null If you don't want to set this property individually for each mailbox that's moved to the cloud, you can use the following commands to configure the mailboxes in bulk. Run these commands each time you move one or more mailboxes to the cloud. 1. Retrieve a list of all mail users that don't have a value set for the immutable ID and that also have an external address that points to the cloud-based SMTP namespace. Replace "service.contoso.com" with your cloud-based SMTP namespace, but be sure to keep the wildcard character ( * ). $MailUsers = Get-MailUser -Filter {(ImmutableID -Eq $Null) -And (External Address -Like "*service.contoso.com") } 2. Set the UPN on the immutable ID for each mail user that's returned. The UPN is taken from the UserPrincipalName property on the mail user and set on the ImmutableID property. This example uses the ModeratedBy property to upgrade the mail user to a version the coexistence server can manage. Choose another property if your organization already uses the ModeratedBy property. $MailUsers ForEach {Set-MailUser $_.Alias -ModeratedBy Administrator -ForceUpgrade; Set-MailUser $_.Alias -ImmutableId $_.UserPrincipalName; Set-MailUser $_.Alias -ModeratedBy $Null - ForceUpgrade} How do I configure a mailbox that's been created in the cloud-based organization? In the Shell on the coexistence server, do the following to set the immutable ID of a remote mailbox to the UPN of that mail user. 1. Retrieve the UPN of the remote mailbox you want to configure. Get-Remot box david Format-Table Name, Alias, UserPrincipalName 2. Set the immutable ID of the remote mailbox to the remote mailbox's UPN. Set-Remot box david -ImmutableID [email protected] If you don't want to set this property individually for each mailbox that's moved to the cloud, you can use the following commands to configure the mailboxes in bulk. Run these commands each time you move one or more mailboxes to the cloud. 1. Retrieve a list of all remote mailboxes that don't have a value set for the immutable ID. $Remot boxes = Get-Remot box -Filter {ImmutableID -Eq $Null} 2. Set the UPN on the immutable ID for each remote mailbox that's returned. The UPN is taken from the UserPrincipalName property on the mail user and set on the ImmutableID property. 60

61 $Remot boxes ForEach {Set-Remot box $_.Alias -ImmutableId $_.UserPrincipalName} How do I know this worked? To verify that you've set the immutable ID of a mail user or remote mailbox object to the UPN of that object, use the following commands in the Shell on the coexistence server. The ImmutableID and UserPrincipalName properties should match each other. To view the ImmutableID and UserPrincipalName properties for a mail user, do the following. Get-MailUser david Format-Table Name, Alias, ImmutableID, UserPrincipalName To view the ImmutableID and UserPrincipalName properties for a remote mailbox, do the following. Get-Remot box david Format-Table Name, Alias, ImmutableID, UserPrincipalName Having problems? Ask for help in the Coexistence and Migration forum. To access the forum, you'll need to sign in using an account that's granted administrator access to your cloud-based service. Visit the forum at: Coexistence and Migration Post-configuration tasks for Coexistence with Exchange 2007 After you complete the configuration steps for deploying coexistence, you should complete the post-installation tasks to enable any additional needed functionality. Configure Permissions in the Cloud-based Organization By default, the administrative account that you specified when the cloud-based service was created is granted administrator permissions to the cloud-based organization. This account can configure all aspects of the cloud-based organization and manage recipients located in the organization. You can add additional administrators as needed. End users are also granted permissions when their mailboxes are moved to or created in the cloud-based organization. By default, they can configure things like their own contact information, distribution group membership, subscriptions, telephone number, and so on. You can configure the default role assignment policy or create new role assignment policies. Administrative and end user permissions that are configured in the on-premises organization aren't transferred to the cloud-based organization. You must re-create your permissions in the cloud-based organization. 61

62 Learn more at: Understanding Coexistence Permissions Configure Additional Remote Domains The Deployment Assistant has shown you how to configure transport between your on-premises organization and the cloud-based organization. If you have configured remote domains between your organization and other organizations to customize settings such as the type of encoding to use, whether non-delivery reports are enabled, the character set to use, and so on, you should re-create similar custom remote domains in your cloud-based organization. Learn more at: Understanding Remote Domains Configure Unified Messaging Unified messaging is supported in a coexistence deployment between your on-premises and cloud-based organizations. Your on-premises telephony solution must be able to communicate with the cloud-based organization. This may require that you purchase additional hardware and software. If you want to move mailboxes from your on-premises organization to the cloud-based organization, and those mailboxes are configured for unified messaging, you should configure unified messaging coexistence prior to moving those mailboxes. If you move mailboxes before you configure unified messaging coexistence, those mailboxes will no longer have access to unified messaging functionality. Lear more at: Plan for UM Coexistence Configure Information Rights Management Information Rights Management (IRM) enables users to apply Active Directory Rights Management Services (AD RMS) templates to messages that they send. AD RMS templates can help prevent information leakage by allowing users to control who can open a rights-protected message, and what they can do with that message once it's been opened. IRM in a coexistence deployment requires planning, manual configuration of the cloud-based organization, and an understanding of how clients use AD RMS servers depending on whether their mailbox is in the on-premises or cloud-based organization. Learn more at: Understanding IRM Coexistence Configure Outlook Web App Mailbox Policies Outlook Web App mailbox policies enable you to manage access to features in Outlook Web App. For example, you can control whether users can open the Calendar or other folders in their Inbox, customize their theme, use the spell checker, access file attachments, and more. By default, every mailbox in the cloud-based organization is assigned to the default Outlook Web App mailbox policy. The default policy allows access to all features of 62

63 Outlook Web App. You can configure the default Outlook Web App mailbox policy or create additional policies and assign them to mailboxes. Outlook Web App mailbox policies that you've defined in your on-premises organization aren't transferred to the cloud-based organization. You must re-create your Outlook Web App mailbox policies in the cloud-based organization. Learn more at: Understanding Outlook Web App Mailbox Policies Configure Exchange ActiveSync Mailbox Policies Exchange ActiveSync mailbox policies enable you to apply a common set of policy or security settings to a user or group of users. These policies are applied to the mobile devices that are connected to a user's mailbox. For example, you can control whether users can use the camera on a mobile device, whether a password is required, the maximum calendar age, and so on. By default, every mailbox in the cloud-based organization is assigned to a default Exchange ActiveSync mailbox policy. The default policy doesn't place any restrictions on mobile devices connected to cloud-based mailboxes and doesn't require that passwords be used on the device. You can configure the default Exchange ActiveSync mailbox policy or create additional policies and assign them to mailboxes. Exchange ActiveSync mailbox policies that you've defined in your on-premises organization aren't transferred to the cloud-based organization. You must re-create your Exchange ActiveSync mailbox policies in the cloud-based organization. Learn more at: Understanding Exchange ActiveSync Mailbox Policies Client Configuration Users running Outlook 2007 or Outlook 2010 who connect using Outlook Anywhere will be automatically reconfigured to connect to the cloud-based organization when their mailbox is moved. Users who connect a mobile device to their mailbox may be required to manually reconfigure their device, depending on the version of Exchange ActiveSync the device uses. If the device doesn't reconfigure itself automatically, the user can re-create the Exchange ActiveSync association or change their POP or IMAP settings. Learn more at: Set Up Your Account on Your Mobile Phone If your users use an client other than Outlook 2007 or Outlook 2010, they must use POP or IMAP if their mailbox is moved to the cloud-based organization. Important: Pre-Outlook 2007 clients are not supported by the Microsoft Office 365 service or by onpremises organizations configured for coexistence. Pre-Outlook 2007 clients that connect directly to the Office 365 service, and clients that connect to on-premises Exchange servers that coexist with Office 365, must be upgraded to a supported version. Learn more at: Setup 63

64 Coexistence checklist complete Congratulations on successfully completing your checklist in the Exchange Deployment Assistant! Tools you can use To determine the overall health of your Exchange servers and topology, you can use the Microsoft Exchange Best Practices Analyzer (ExBPA). The tool scans Exchange servers and identifies items that don't conform to Microsoft best practices. After the data is collected, ExBPA compares what it finds on your system with Exchange best practice rules and then provides a detailed report. The report lists recommendations that you can consider to achieve greater performance, scalability, and uptime. You can find ExBPA in the Toolbox in the Exchange Management Console. The Exchange Remote Connectivity Analyzer Tool is a Web-based tool that helps you troubleshoot connectivity issues. The tool simulates several client logon and mail flow scenarios. When a test fails, many of the errors have troubleshooting tips to assist you in correcting the problem. Take a look at: Exchange Remote Connectivity Analyzer Tool And, for more information about Exchange planning and deployment, you can always review the related content in the Exchange TechCenter Library. Find it all at: Planning and Deployment Give us feedback please We would really appreciate your feedback about the Exchange Deployment Assistant. What worked for you? What could we have done better? What do you recommend we change for the next version? Tell us what you think at: Feedback: Exchange 2010 Deployment Assistant Understanding Access to Outlook Web App with a Single URL with Exchange 2007 Providing a single, common URL to access Exchange mailboxes using Microsoft Office Outlook Web App can help to make transitioning to a coexistence deployment easier and less confusing for your users, particularly users whose accounts are moved to the cloud-based organization. By enabling the coexistence server to automatically redirect Outlook Web App requests to the on-premises mailbox server or to provide a link to users for their mailbox in the cloud-based organization, users only need to remember one URL to access Outlook Web App no matter where their mailbox is located. 64

65 Outlook Web Access and the On-Premises Exchange 2007 Server Your existing on-premises Exchange 2007 server supports allowing your users to access their mailbox using Outlook Web App. Outlook Web App provides users with a browser-based experience that is similar to the experience when using the Outlook 2003 mail client. To launch Outlook Web App from outside the corporate network, users typically type the externally accessible FQDN of the mailbox server followed by the Outlook Web App virtual directory name, such as in a Web browser and then provide their network credentials when prompted. Users can also typically launch Outlook Web App from the internal network by typing the internal server name followed by the Outlook Web App virtual directory name, such as in a Web browser. Network user credentials are also required when launching Outlook Web App from the internal network. The URLs that users use to access Exchange 2007 Outlook Web App are configured using the following parameters on the Set-OwaVirtualDirectory cmdlet: InternalUrl This parameter specifies the URL used by users on your internal network to access Exchange 2007 Outlook Web App. For example, ExternalUrl This parameter specifies the URL used by users to access Exchange 2007 Outlook Web App from the Internet. For example, If you are a small organization with only a single Exchange 2007 Client Access server, you may not have set these properties before. When deploying coexistence, you have the option of redirecting Outlook Web App requests from the coexistence server to your Exchange 2007 Client Access server automatically. For this redirection to work, you must configure the InternalUrl and ExternalUrl properties on the Outlook Web App virtual directories with values that direct users to the correct URLs for your Exchange 2007 Client Access server. Redirection from your coexistence server to the Exchange 2007 Client Access server is discussed in more detail later in this topic. Learn more at: Managing Outlook Web Access Virtual Directories in Exchange 2007 Outlook Web App and the Coexistence Server In a coexistence deployment, you are typically moving existing user mailboxes from your onpremises Exchange 2007 mailbox server to the cloud-based organization in phases. Maintaining the ability to access mailboxes using a Web browser for users during mailbox migration is often very important. Outlook Web App, formerly known as Outlook Web App, is available for user mailboxes that are moved to the cloud-based organization and provides a similar Web-based messaging experience. Outlook Web App in the cloud-based organization contains several new features, additional browser support, and a more streamlined interface compared to the experience provided by Outlook Web Access in Exchange

66 Normally, the URL that a user needs to specify to access Outlook Web App depends on whether a user's mailbox is located on an on-premises Exchange 2007 server or in the cloud-based organization. The coexistence server, however, enables you to provide a single Outlook Web App address which will either automatically redirect your users to the correct Outlook Web App URL or provide them with the correct URL they can click on. We recommend that you configure the coexistence server to handle Outlook Web App requests and use a single URL to access user mailboxes. Using the installed Client Access server role, you can configure the coexistence server to take one of the following actions depending on the location of the user's mailbox: Mailbox on the on-premises server For mailboxes located on the on-premises Exchange 2007 mailbox server, the coexistence server looks up the internal or external URL of a Exchange 2007 Client Access server, and redirects the user to that URL automatically. The user then communicates directly with the Exchange 2007 Client Access server to access Outlook Web App. Learn more at: Understanding Proxying and Redirection Mailbox in the cloud For mailboxes located in the cloud-based organization, Outlook Web App requests made to the coexistence server are not automatically redirected to the cloud-based organization. Instead, the coexistence server displays a Web page that provides users with a link to the Outlook Web App endpoint for the cloud-based organization. Users also have the option to save the URL as a favorite in their Web browser. Configuring the coexistence server to take these actions requires the following process: 1. Configure the Outlook Web App virtual directory on the Exchange 2007 Client Access servers with the internal and external URLs users use to access Exchange 2007 Outlook Web App. 2. Configure the organization relationship on the coexistence server to display the cloud-based Outlook Web App URL for user mailboxes located in the cloud-based organization. 3. Update the existing DNS record to direct Outlook Web App requests to the coexistence server. This configuration requires that both the Exchange 2007 Client Access server and the coexistence server accept Outlook Web App connections from the Internet. This is because the coexistence server redirects Outlook Web App requests to the Exchange 2007 Client Access server. Each server requires its own public IP address and TCP ports 80 and 443 to be opened on your firewall. Understanding Certificate Requirements Digital certificates are an important part of securing the communication between the on-premises Exchange organization and the cloud-based service, other on-premises Exchange servers, and your clients. Certificates enable one entity to trust the identity of another. This helps to ensure that a client or server is communicating to the right source. In the deployment of a coexistence organization, several services make use of certificates: 66

67 Active Directory Federation Servers (AD FS) Either self-signed certificates or certificates issued by a trusted third-party certificate authority (CA) are used to establish a trust between Web clients and federation server proxies, to sign security tokens, and to decrypt security tokens. Learn more at: Certificates Exchange federation A self-signed certificate is used to create a secure connection between the on-premises Exchange 2010 coexistence server and the Microsoft Federation Gateway. Learn more at: Understanding Federated Delegation Exchange services Self-signed certificates or certificates issued by a trusted third-party CA are used to help secure Secure Sockets Layer (SSL) communication between Exchange servers and clients. Services that use certificates include Outlook Web App, Exchange ActiveSync, Outlook Anywhere, and message transport. Existing Exchange servers Your existing Exchange servers may make use of certificates to help secure Outlook Web App communication, message transport, and so on. Depending on how you use certificates on your Exchange servers, you might use self-signed certificates or certificates issued by a trusted third-party CA. Learn more at: Understanding Digital Certificates and SSL Certificate Requirements for Coexistence When you deploy a coexistence organization, you must configure certificates. You can choose to use self-signed certificates or purchase certificates from a trusted third-party CA. Multiple services, such as AD FS, Exchange 2010 federation, Exchange 2010 services, and Exchange, each require certificates. Depending on your organization, you may decide to do one of the following: Use a self-signed certificate for each service Use a third-party certificate that's used by all services across multiple servers Use a third-party certificate for each server that provides services The type of certificate you use, and whether you choose to use the same certificate for all services, or dedicate a certificate for each service, depends on your organization and the service you're implementing. Here are some things to consider about each option: Self-signed certificate Self-signed certificates aren't trusted by other servers or clients. For clients and servers to accept a self-signed certificate presented by a server, you must manually import the certificate into each client and server. Third-party certificate across multiple servers If you have many clients and servers that must trust the self-signed certificate, or if you can't access each client or server, you may want to consider using a third-party certificate. Third-party certificates that are used by services across multiple servers may be slightly cheaper to obtain, but they may complicate renewal and replacement. The complication occurs because, when a certificate needs replacement, you need to replace the certificate on every server where it's installed. 67

68 Third-party certificate for each server Using a dedicated certificate for each server that hosts services allows you to configure the certificate specifically for the services on that server. If you need to replace the certificate or renew it, you only need to replace it on the server where the services are installed. Other servers aren't impacted. We recommend that you use a dedicated third-party certificate for the AD FS server, another certificate for the Exchange services on your coexistence server, and if needed, a certificate on your Exchange server. Federated delegation on the coexistence server uses a self-signed certificate by default. Unless you have specific requirements, there's no need to use a third-party certificate with federated delegation. The services that are installed on a single server may require that you configure multiple fully qualified domain names (FQDNs) for the server. Purchase a certificate that allows for the required number of FQDNs. Certificates consistent of the subject, or principal, name, and one or more subject alternative names (SAN). The subject name is the FQDN that the certificate is issued to. SANs are additional FQDNs that can be added to a certificate in addition to the subject name. If you need a certificate to support five FQDNs, purchase a certificate that allows for five domains to be added to the certificate: one subject name and four SANs. Service Server Suggested FQDN Active Directory Federation Services (AD FS) (if you've chosen to configure AD FS) Federated delegation (if you've chosen to configure federated delegation) AD FS Coexistence server Sts.contoso.com Exchangedelegation.contoso.com Autodiscover Coexistence server Autodiscover.contoso.com Transport Coexistence server Label that matches the external FQDN of your Exchange 2010 coexistence server, such as mail2.contoso.com. Outlook Anywhere Coexistence server Label that matches the internal FQDN of your Exchange 2010 coexistence server, such as Ex2010.corp.contoso.com. Label that matches the internal host name of your Exchange 2010 coexistence server, such as Ex2010. Outlook Web App (Exchange 2010) Coexistence server Owa.contoso.com Outlook Web App (existing Exchange server) Existing Exchange server Label that matches the external FQDN of your existing Exchange server, such as mail1.contoso.com. 68

69 Understanding Coexistence Coexistence offers organizations the ability to extend the feature-rich experience and administrative control they have with their existing on-premises Microsoft Exchange organization to the cloud. Coexistence provides the seamless look and feel of a single Exchange organization between an on-premises organization and a cloud-based organization. In addition, coexistence can serve as an intermediate step to moving completely to a cloud-based Exchange organization. Types of Coexistence A coexistence deployment can be either simple or rich: Simple coexistence offers only the basic feature of a unified global address list (GAL) and mail routing between the on-premises and cloud-based organizations. Rich coexistence offers the features of simple coexistence plus additional messaging features typically available in an on-premises Exchange deployment, including sharing free/busy and calendar information between the organizations and the ability to move mailboxes from the on-premises organization to the cloud-based organization. Note: The Exchange Server Deployment Assistant only supports a rich coexistence deployment. The following table summarizes the feature differences between simple coexistence and rich coexistence. Feature Mail routing between onpremises and cloud-based organizations Mail routing with a shared domain namespace (both organizations SMTP domain) Simple coexistence Yes Yes Rich coexistence Yes Yes Unified GAL Yes Yes Free/busy and calendar sharing between on-premises and cloudbased organizations No Yes Centralized mail flow control; the No Yes 69

70 Feature on-premises organization can control mail flow for both organizations Single Outlook Web App URL for both the on-premises and cloudbased organizations Move existing on-premises mailboxes to the cloud-based organization Centralized mailbox administration using the onpremises Exchange Management Console (EMC) Message tracking, MailTips, and multi-mailbox search between on-premises and cloud-based organizations Simple coexistence No No No No Rich coexistence Yes Yes Yes Yes Coexistence Components Deploying coexistence involves several different services and components: Microsoft Office 365 The Office 365 service provides a cloud-based Exchange organization as a part of its subscription service. Organizations deploying coexistence must create and configure this cloud-based Exchange organization. Coexistence Server A coexistence server is an Exchange Server 2010 server that is installed in your existing Exchange organization, and it's required for coexistence deployments. It enables messaging features and messaging delivery between your existing Exchange organization and the Office 365-based Exchange organization. Microsoft Federation Gateway The Microsoft Federation Gateway is a cloud-based service offered by Microsoft that acts as the trust broker between your on-premises Exchange 2010 organization and the cloud-based Exchange organization. Organizations deploying rich coexistence must create a federation trust with the gateway. Learn more at: Microsoft Federation Gateway Active Directory Synchronization (DirSync) DirSync replicates on-premises Active Directory information for mail-enabled objects to the cloud-based organization to support the unified GAL. Organizations deploying coexistence must deploy DirSync on a separate, on-premises server. 70

71 Understanding Coexistence Permissions The cloud-based organization is based on Exchange 2010 and, like on-premises organizations, uses Role Based Access Control (RBAC) to control permissions. Administrators are granted permissions using management role groups while endusers are granted permissions using management role assignment policies. Learn more about RBAC at: Understanding Permissions Administrator Permissions By default, the user that was used to create the cloud-based service is made a member of the Organization Management role group in the cloud-based organization. This user can manage the entire cloud-based organization, including configuration of organization-level settings and management of cloud-based recipients. You can add additional administrators in the cloud-based organization, depending on the management that needs to take place. You can add additional organization administrators and recipient administrators, enable specialist users to perform compliance tasks such as discovery, configure custom permissions, and more. All permissions management for cloud-based administrators must be performed in the cloud-based organization using either the Exchange Control Panel (ECP) or remote PowerShell. However, it's important to note that there is no transfer of permissions between the on-premises organization and the cloud-based organization. Any permissions that you've defined in the onpremises organization must be re-created in the cloud-based organization. See the following topics for more information: Create a Role Group Add a Role to a Role Group Remove a Role from a Role Group Copy a Role Group Add Members to a Role Group Remove Members from a Role Group End User Permissions As with administrator permissions, end users in the cloud can be granted permissions. By default, end users are granted permissions via the Default Role Assignment Policy. This policy is applied to every mailbox in the cloud-based organization. If the permissions granted by default are sufficient, you don't need to change anything. If you do want to customize end user permissions, you can either modify the existing Default Role Assignment Policy, or you can create new assignment policies. If you create multiple assignment policies, you can assign different policies to different groups of mailboxes, enabling you to control permissions granted to each group depending on their requirements. All permissions 71

72 management for cloud-based end users must be performed in the cloud-based organization using either the ECP or remote PowerShell. Like administrator permissions, end user permissions aren't transferred between the on-premises organization and the cloud-based organization. Any permissions that you've defined in the onpremises organization must be re-created in the cloud-based organization. The following table lists the permissions granted by the Default Role Assignment Policies in the cloud-based organization. Default Role Assignment Policy Permissions Management role MyBaseOptions MyContactInformation MyDistributionGroupMembership MyDistributionGroups MyMailSubscription MyProfileInformation MyRetentionPolicies Description The MyBaseOptions management role enables individual users to view and modify the basic configuration of their own mailbox and associated settings. The MyContactInformation management role enables individual users to modify their contact information, including address and phone numbers. The MyDistributionGroupMembership management role enables individual users to view and modify their membership in distribution groups in an organization, provided that those distribution groups allow manipulation of group membership. The MyDistributionGroups management role enables individual users to create, modify, and view distribution groups, and to modify, view, remove, and add members to distribution groups they own. The MyMailSubscription role enables individual users to view and modify their subscription settings such as message format and protocol defaults. The MyProfileInformation management role enables individual users to modify their name. The MyRetentionPolicies management role enables individual users to view their retention tags, and to view and modify their retention tag settings and defaults. 72

73 Management role MyTextMessaging MyVoic Description The MyTextMessaging management role enables individual users to create, view, and modify their text messaging settings. The MyVoic management role enables individual users to view and modify their voice mail settings. See the following topics for more information: Add an Assignment Policy Remove an Assignment Policy Add a Role to an Assignment Policy Remove a Role from an Assignment Policy Change the Assignment Policy on a Mailbox Change the Default Assignment Policy Understanding Coexistence Management with Exchange 2007 Both your on-premises organization and the cloud-based organization are based on Exchange. In particular, the coexistence server and the cloud-based organization are based on Exchange This enables you to reduce the number of administrative interfaces that you need to use to configure Exchange coexistence. When you install the coexistence server, Exchange 2010 management tools are automatically installed on the server. These management tools are used to configure the coexistence server by default, but they can also be used to configure the cloud-based organization. These tools include the Exchange Management Console (EMC), a graphical administrative interface, and the Exchange Management Shell, a Windows PowerShell-based command-line interface. Exchange Management Console The EMC enables you to perform many deployment tasks and most common day-to-day administrative tasks. It's installed by default on every Exchange 2010 server, but it can also be installed on any of the following 64-bit operating systems: Windows Server 2008 SP2 Standard and Enterprise Windows Server 2008 R2 Standard and Enterprise Windows 7 Windows Vista Service Pack (SP) 2 73

74 If you only want to administer the on-premises coexistence server with the EMC, you only need to install the Exchange management tools and their prerequisites. However, if you want to use the EMC to administer the cloud-based organization, you must also install the Microsoft Online Service Connector on any computer where the management tools are installed. The connector adds additional components required for the EMC to properly authenticate with the cloud-based organization. Adding the cloud-based organization to the EMC is similar to adding another Exchange 2010 forest to the EMC. When the cloud-based organization is added to the EMC, it appears as another node in the navigation tree. From there you can select the cloud-based organization and configure organization and recipient objects. Keep in mind, however, that many objects that are present in the on-premises organization node aren't available in the cloud-based organization node. The following are examples of settings not available in the cloud-based organization node: Physical server configuration Send and Receive connector configuration Transport limits Transport dumpster Custom delivery status notification (DSN) codes Address lists Offline address books Managed default folders address policies Database management Database availability groups The following screenshot shows the on-premises organization and cloud-based organization in the same console. 74

75 On-premises and cloud-based organizations in the Exchange Management Console In addition to adding the cloud-based organization node, some additional features become available in the EMC. For example, you can use the EMC to perform mailbox moves between the on-premises organization and the cloud-based organization. Learn more at: Exchange Management Console Exchange Management Shell The Shell enables you to perform any task that the EMC does, and some additional tasks that can only be performed in the Shell. The Shell is a collection of Windows PowerShell scripts and cmdlets that are installed on a computer when the Exchange 2010 management tools are installed. These scripts and cmdlets are only loaded when you open the Shell using the Exchange Management Shell icon. If you open Windows PowerShell directly, the Exchange scripts and cmdlets aren't loaded and you won't be able to manage your on-premises organization. Note: You can create a manual Windows PowerShell connection to your local on-premises organization, similar to how you manually connect to the cloud-based organization below. 75

76 However, we strongly recommend that you use the Exchange Management Shell icon to open the Shell to manage your on-premises coexistence server. When you open the Shell using the Exchange Management Shell icon on a computer that has the management tools installed, you can manage your on-premises organization. However, you can't manage the cloud-based organization when you open the Shell using this icon. This is because opening the Shell using the Exchange Management Shell icon automatically connects you to the local coexistence server. If you want to manage the cloud-based organization using Windows PowerShell, you must open Windows PowerShell directly and not via the Exchange Management Shell icon. When you open Windows PowerShell, you can then manually specify where you want to connect. When you create a manual connection, you specify an administrator account in the cloud-based organization, and then you run a command to create a connection. When the connection is established, the Exchange cmdlets you have permissions to run are made available to you. Learn more at: Use Windows PowerShell If you're new to the Shell, check out the following topic to learn the basics about how the Shell works, command syntax, and more. Learn more at: Exchange Management Shell Understanding Coexistence with Exchange 2007 Prerequisites Before you can really start to use the Deployment Assistant, your system and servers must meet requirements. If they don't meet these requirements, you won't be able to complete the steps within the tool and you won't be able to configure your on-premises Exchange 2007 organization for coexistence with a cloud-based organization. This topic provides information about the following: Permissions needed to install and manage Exchange 2010 Requirements for directory servers, hardware, software, clients, and other elements, including: Windows Server 2008 Service Pack 2 (SP2) or later or Windows Server 2008 R2 operating system prerequisites that are required for all Exchange 2010 server roles Language selection options in Setup and the specific languages that are supported for Exchange 2010 The Exchange Management Shell, the command-line interface for Exchange 2010, and the Exchange Management Console, the GUI management tool for Exchange 2010 Note: Before installing Exchange 2010, we recommend that you install any critical or recommended updates from Microsoft Update. 76

77 Exchange Pre-Deployment Analyzer You can use the Exchange Pre-Deployment Analyzer (ExPDA) to perform an overall topology readiness scan of your environment. This scan focuses on overall topology readiness and not the ability to run Exchange 2010 on the local computer. ExPDA provides a detailed report that will alert you if there are any issues within your organization, which could prevent you from deploying Exchange For example, ExPDA will notify you if you haven't deployed the minimum required Exchange service pack on all your Exchange servers. If your organization passes the ExPDA readiness scan, you can go ahead and use the Exchange Deployment Assistant. To get ExPDA from the Microsoft Download Center, see: Exchange Pre-Deployment Analyzer Permissions to Install and Manage Exchange 2010 Exchange 2010 requires different permissions to install and to manage your server roles. When you're installing Exchange 2010 servers in your organization, the account you use might not be the same account that you use for administering and managing your server roles. To manage your server roles, Exchange 2010 uses the Role Based Access Control (RBAC) permissions model. Exchange 2010 uses RBAC to manage permissions on the Exchange 2010 coexistence server. With RBAC, you can control what resources administrators can configure and what features users can access. The RBAC model in Exchange 2010 is flexible and provides you with several ways to customize the default permissions. RBAC has two primary ways of assigning permissions to users in your organization, depending on whether the user is an administrator or specialist user, or an end-user: management role groups and management role assignment policies. Each method associates users with the permissions they need to perform their jobs. The following sections list the tasks found in the Deployment Assistant and the permissions required to complete the task. Note: Some features may require that you have local administrator permissions on the server you want to manage. To manage these features, you must be a member of the Local Administrators group on that server. Installation Permissions By default, the account that's used to install Exchange 2010 in the organization is added as a member of the Organization Management role group. When you install the coexistence server into your Exchange 2007 organization, Exchange Setup will prepare your Active Directory schema if you have the correct permissions. If you want to separate your Active Directory schema preparation from the coexistence server installation, see: Prepare Active Directory and Domains For information about how to add permissions, see: Add Members to a Role Group The following permissions are required to install the coexistence server in your organization: Local Administrator on the server on which Exchange 2010 will be installed 77

78 Enterprise Administrator in the Active Directory forest where Exchange 2010 will be installed Schema Administrator in the Active Directory forest where Exchange 2010 will be installed Exchange Management Permissions The table below lists the configuration permissions that you need to successfully use the Deployment Assistant. Some tasks need to be performed only in the on-premises organization while some tasks also need to be performed in the cloud-based organization. If a task needs to be performed in the cloud-based organization, you must ensure that you have the required permissions in that organization. Permissions in the on-premises organization aren't replicated to the cloud-based organization. Note: The user account used to create the cloud-based organization has all the permissions required to perform the tasks in this checklist. Learn more at: Understanding Coexistence Permissions Some procedures require you to perform tasks on your Exchange 2007 servers. For information about how to manage permissions in an organization with Exchange 2007 and Exchange 2010 installed, see: Understanding Permissions Coexistence with Exchange Task Permissions required On-premises or cloud-based organization Import digital certificates Local Administrator On-premises organization Configure settings on virtual directories Configure virtual directories Server Management Organization Management Server Management On-premises organization On-premises organization Create accepted domains Organization Management On-premises and cloud-based organization Create and modify Send and Receive connectors Organization Management On-premises organization Create a federation trust Organization Management On-premises organization Create organization relationships Configure Mailbox Replication Service (MRS) proxy Move mailboxes Organization Management Local Administrator Organization Management Recipient Management On-premises and cloud-based organization On-premises organization On-premises and cloud-based organization 78

79 Task Permissions required On-premises or cloud-based organization Configure Exchange 2007 authentication Configure Exchange 2007 e- mail address policies Local Administrator Exchange Administrator On-premises organization On-premises organization Directory Servers Here are the requirements for the directory servers in your organization: Schema master The latest 64-bit edition of Windows Server 2008 Standard or Enterprise operating system. Global catalog server In every Active Directory site where you plan to install Exchange 2010, you must have at least one global catalog server that is either the latest 64- bit edition of: Windows Server 2008 Standard or Enterprise; or Windows Server 2008 R2 Standard or Enterprise. Active Directory Forest The Active Directory forest must be Windows Server 2008 forest functional mode. Domain Controller You must have the latest 64-bit edition of the Windows Server 2008 Standard or Enterprise operating system or the Windows Server 2008 R2 Standard or Enterprise operating system. Hardware The recommended hardware requirements for Exchange 2010 servers vary depending on several factors including the server role(s) that are installed and the anticipated load that will be placed on the servers. Processor x64 architecture-based computer with processor that supports 64-bit architecture Memory Minimum 4GB with a recommended maximum of 2GB per core (8GB minimum). Learn more at: Understanding Memory Configurations and Exchange Performance Disk space At least 1.2 GB on the drive on which you install Exchange and additional 200 MB of available space on the system drive. Drive DVD-ROM drive, local or network accessible File format Disk partitions formatted as NTFS file systems Operating System Here are the supported operating systems for Exchange 2010: 64-bit edition of Windows Server 2008 Standard Service Pack 2 79

80 64-bit edition of Windows Server 2008 Enterprise Service Pack 2 64-bit edition of Windows Server 2008 Standard R2 64-bit edition of Windows Server 2008 Enterprise R2 Exchange 2010 Management tools can use the operating systems listed above plus: 64-bit edition of Windows Vista 64-bit edition of Windows 7 Install the Exchange 2010 SP1 Hotfixes for Windows Server 2008 SP2 The following hotfixes are required for Windows Server 2008 SP2: Install the update described in Microsoft Knowledge Base article , AD RMS clients do not authenticate federated identity providers in Windows Server 2008 or in Windows Vista. Without this update, Active Directory Rights Management Services (AD RMS) features may stop working. Install the update described in Knowledge Base article , A.NET Framework 2.0- based Multi-AppDomain application stops responding when you run the application. Install the update described in Knowledge Base article , Two issues occur when you deploy an ASP.NET 2.0-based application on a server that is running IIS 7.0 or IIS 7.5 in Integrated mode. For more information, see these MSDN Code Gallery pages: For additional background information, see KB QFE for Sharepoint issues - Perf Counter fix & User Impersonation. For the available downloads, see KB QFE for Sharepoint issues - Perf Counter fix & User Impersonation. Install the update described in Knowledge Base article , FIX: ArgumentNullException exception error message when a.net Framework 2.0 SP2-based application tries to process a response with zero-length content to an asynchronous ASP.NET Web service request: "Value cannot be null". Install the update described in Knowledge Base article , RPC over HTTP clients cannot connect to the Windows Server 2008 RPC over HTTP servers that have RPC load balancing enabled. Install the update described in Knowledge Base article , An update is available to remove the application manifest expiry feature from AD RMS clients. Without this update, the AD RMS features may stop working. Install the update described in Knowledge Base article , An ASP.NET 2.0 hotfix rollup package is available for Windows 7 and for Windows Server 2008 R2. For more information, see these MSDN Code Gallery pages: For additional background information, see KB Win7 rollup package (PR for QFE ). For the available downloads, see KB Win7 rollup package (PR for QFE ). 80

81 Install the update described in Knowledge Base article , FIX: An application that is based on the Microsoft.NET Framework 2.0 Service Pack 2 and that invokes a Web service call asynchronously throws an exception on a computer that is running Windows 7. Install the Exchange 2010 SP1 Hotfixes for Windows Server 2008 R2 The following hotfixes are required for Windows Server 2008 R2: Install the update described in Knowledge Base article , An update is available to remove the application manifest expiry feature from AD RMS clients. Without this update, the AD RMS features may stop working. Install the update described in Knowledge Base article , A.NET Framework 2.0- based Multi-AppDomain application stops responding when you run the application. Install the update described in Knowledge Base article , An ASP.NET 2.0 hotfix rollup package is available for Windows 7 and for Windows Server 2008 R2. For more information, see these MSDN Code Gallery pages: For additional background information, see KB Win7 rollup package (PR for QFE ). For the available downloads, see KB Win7 rollup package (PR for QFE ). Install the update described in Knowledge Base article , FIX: An application that is based on the Microsoft.NET Framework 2.0 Service Pack 2 and that invokes a Web service call asynchronously throws an exception on a computer that is running Windows 7. Install the Exchange 2010 SP1 Hotfixes for Windows 7 and Windows Vista The following hotfixes are required for Windows 7 and Windows Vista computers where you install the Exchange Management Console Install the update described in Knowledge Base article , FIX: An application that is based on the Microsoft.NET Framework 2.0 Service Pack 2 and that invokes a Web service call asynchronously throws an exception on a computer that is running Windows 7. Install the update described in Knowledge Base article , An ASP.NET 2.0 hotfix rollup package is available for Windows 7 and for Windows Server 2008 R2. For more information, see these MSDN Code Gallery pages: For additional background information, see KB Win7 rollup package (PR for QFE ). For the available downloads, see KB Win7 rollup package (PR for QFE ). Install the Windows Server 2008 SP2 prerequisites 1. Install the Microsoft Filter Pack. For details, see: 2007 Office System Converter: Microsoft Filter Pack 81

82 2. Open an elevated command prompt, navigate to the Scripts folder on the Exchange 2010 installation media and use the following command to install the necessary operating system components: sc config NetTcpPortSharing start= auto ServerManagerCmd ip Exchange-Typical.xml -Restart Install the Exchange 2010 SP1 Hotfixes for Windows Server 2008 SP2 The following hotfix is required for Windows Server 2008 SP2 and must be installed after the operating system prerequisites have been installed: Install the hotfix described in Knowledge Base article , WCF services that are hosted by computers together with a NLB fail in.net Framework 3.5 SP1. For more information, see these MSDN Code Gallery pages: For additional background information, see KB WCF: Enable WebHeader settings on the RST/SCT. For the available downloads, see KB WCF: Enable WebHeader settings on the RST/SCT. After installing the preceding prerequisites and hotfix, and before installing Exchange 2010, we recommend that you install any critical or recommended updates from Microsoft Update. Install the Windows Server 2008 R2 prerequisites 1. Install the Microsoft Filter Pack. For details, see: 2007 Office System Converter: Microsoft Filter Pack 2. On the Start Menu, navigate to All Programs, then Accessories, then Windows PowerShell. Open an elevated Windows PowerShell console, and run the following command: Import-Module ServerManager 3. Use the Add-WindowsFeature cmdlet to install the necessary operating system components using the following command: Add-WindowsFeature NET-Framework,RSAT-ADDS,Web-Server,Web-Basic- Auth,Web-Windows-Auth,Web-Metabase,Web-Net-Ext,Web-Lgcy-Mgmt- Console,WAS-Process-Model,RSAT-Web-Server,Web-ISAPI-Ext,Web-Digest- Auth,Web-Dyn-Compression,NET-HTTP-Activation,RPC-Over-HTTP-Proxy - Restart 4. After the system has restarted, log on as an administrator, open an elevated Windows PowerShell console, and configure the Net.Tcp Port Sharing Service for Automatic startup by running the following command: Set-Service NetTcpPortSharing -StartupType Automatic 82

83 Install the Exchange 2010 SP1 Hotfixes for Windows Server 2008 R2 The following hotfix is required for Windows Server 2008 R2 and must be installed after the operating system prerequisites have been installed: Install the hotfix described in Knowledge Base article , WCF services that are hosted by computers together with a NLB fail in.net Framework 3.5 SP1. For more information, see these MSDN Code Gallery pages: For additional background information, see KB WCF: Enable WebHeader settings on the RST/SCT. For the available downloads, see KB WCF: Enable WebHeader settings on the RST/SCT. After installing the preceding prerequisites and hotfix, and before installing Exchange 2010, we recommend that you install any critical or recommended updates from Microsoft Update. Windows Management Framework Windows PowerShell V2.0 Windows Remote Management V2.0.NET Framework 3.5 SP1 Internet Information Services (IIS) Language Support An Exchange 2010 language pack contains the necessary resources for a supported Exchange language. Language packs can be installed during deployment of Exchange 2010 or after Exchange 2010 has been deployed. Client and server language packs come grouped into a single bundle containing both client and server resource and support files. You can automatically download the language packs when you are running Exchange Setup. Learn more at: Exchange 2010 Language Support Exchange Management Shell The Exchange Management Shell, built on Windows PowerShell technology, provides a powerful command-line interface for Exchange 2010 that enables automation of administrative tasks. With the Shell, you can manage every aspect of Exchange 2010; the Shell can perform every task that can be performed by the Exchange Management Console (EMC) and the Exchange Control Panel (ECP) in addition to tasks that can't be performed in those interfaces. In fact, when a task is performed in the EMC or the ECP, those interfaces use the Shell to perform the task. Learn more at: Overview of Exchange Management Shell 83

84 Exchange Management Console The Exchange Management Console (EMC) is a Microsoft Management Console (MMC) 3.0- based tool that provides you with a GUI to manage the configuration of your Exchange 2010 organization. You can also add the EMC snap-in to custom MMC-based tools. Learn more at: Exchange Management Console Understanding the Coexistence Server with Exchange 2007 When deploying coexistence, it's necessary to install a coexistence server in your existing Exchange organization. The coexistence server is an additional physical server configured with Exchange 2010 server roles that coordinates communication between your existing Exchange 2007 organization and the cloud-based organization. This communication includes message transport and messaging features between the on-premises and cloud-based organizations. Coexistence Server Roles The coexistence server requires the following Exchange 2010 server roles to be installed: Client Access server role The Client Access server role on the coexistence server provides essentially the same functionality provided by other Client Access servers in your Exchange 2007 organization with a few additions required for coexistence. All client connectivity for coexistence, including Outlook client access, Outlook Web App, and Outlook Anywhere goes through the Client Access server role on the coexistence server. Organization relationship features between the on-premises and cloud-based organizations, such as free/busy sharing, are also handled by the Client Access server role on the coexistence server. Learn more at: Understanding Client Access Hub Transport server role The Hub Transport server role on the coexistence server handles all mail flow between the on-premises and cloud-based Exchange organizations. If required, it can also be configured to handle message routing between the on-premises organization and the Internet. It helps to secure transport communication between the onpremises and cloud-based organizations, as well as handling transport rules, journaling policies, and message delivery to user mailboxes in a coexistence deployment. Learn more at: Overview of the Hub Transport Server Role Coexistence Server Functionality The coexistence server provides several important functions for your on-premises organization in a coexistence deployment: 84

85 Federation The coexistence server enables you to create a federation trust for your onpremises organization with the Microsoft Federation Gateway. The Microsoft Federation Gateway is a cloud-based service offered by Microsoft that acts as the trust broker between your on-premises organization and the cloud-based organization. Federation is a requirement for creating an organization relationship between the on-premises and the cloud-based organizations. Learn more at: Understanding Federation Organization relationships The coexistence server enables you to create organization relationships between the on-premises and cloud-based organizations. Organization relationships are required for many other services in a coexistence deployment, including calendar free/busy information sharing, message tracking, and mailbox moves between the on-premises and cloud-based organizations. Learn more at: Understanding Federated Delegation Message transport The coexistence server is responsible for message transport between the on-premises and cloud-based organizations in a coexistence deployment. Using Send and Receive connectors, it serves as the connection endpoint for incoming messages from the cloud-based organization. Learn more at: Understanding Transport Message transport security The coexistence server helps to secure message communication between the on-premises and cloud-based organizations by using the Domain Security functionality in Exchange Security can be increased by using mutual transport layer security authentication and encryption for message communications. Learn more at: Understanding Domain Security Outlook Web App The coexistence server supports configuring a single URL endpoint for external connections to on-premises and cloud-based mailboxes. For on-premises mailboxes, the coexistence server can be configured to automatically redirect user Outlook Web App requests to your Exchange 2007 mailbox server. For cloud-based organization mailboxes, the coexistence server can be configured to automatically display a link to the Outlook Web App endpoint on the cloud-based organization. Learn more at: Understanding Outlook Web App Coexistence Server Topology The coexistence server is deployed much like an Exchange 2010 server would be deployed to your existing Exchange 2007 organization. Using the Client Access and Hub Transport server roles, the coexistence server is responsible for many services that are similar to ones provided by your existing Exchange 2007 Client Access servers. The difference is that the coexistence server responsibilities are limited primarily to coexistence-related messaging between the on-premises and cloud-based organizations. The following table describes briefly the changes in services after deploying coexistence. 85

86 Service Before coexistence server deployment After coexistence server deployment Description Internal Message transport (inbound and outbound) Exchange 2007 Hub Transport server Exchange 2007 Hub Transport Server and Coexistence server The coexistence server handles message transport for communication between the on-premises and cloud-based organizations. Exchange 2007 Hub Transport servers handle message transport within your Exchange organization. External Message transport (inbound and outbound) Exchange 2007 Edge Transport server Exchange 2007 Edge Transport server The MX (mail exchange) record for the domain will remain pointed to the Exchange 2007 Edge Transport server. Outlook Web App public URL Exchange 2007 Client Access server Coexistence server The coexistence server redirects Outlook Web App requests to the publicly accessible endpoint on the Exchange 2007 server. Coexistence Server Software Service Pack 1 (SP1) for Exchange Server 2010 provides the base for coexistence functionality. You can use any Exchange 2010 SP1 media when installing the coexistence server. Download Exchange Server 2010 SP1 at: Exchange 2010 Service Pack 1 (SP1) Important: You don't need to provide an Exchange 2010 license key on the coexistence server during the Office 365 beta. During the beta, you can run the coexistence server in trial mode with no loss of functionality. 86

87 Understanding Edge Transport Servers with Coexistence The Edge Transport server role is typically deployed on a computer located in an Exchange organization's perimeter network and is designed to minimize the attack surface of the organization. Available in Exchange 2007 and later, the Edge Transport server role handles all Internet-facing mail flow, which provides SMTP relay and smart host services for the Exchange organization. Additional layers of message protection and security are provided by a series of agents that run on the Edge Transport server and act on messages as they're processed by the message transport components. These agents support the features that provide protection against viruses and spam and apply transport rules to control message flow. Learn more about Edge Transport server in Exchange 2007: Edge Transport Server Role: Overview Learn more about Edge Transport servers in Exchange 2010: Overview of the Edge Transport Server Role Edge Transport server in coexistence Exchange Online uses Microsoft Forefront Online Protection for Exchange (FOPE) instead of Edge Transport servers to provide SMTP relay and smart host services and manage the antimalware and anti-spam features for cloud-based organizations. This means that for message communications between your on-premises and cloud-based organizations, these services are handled differently in a coexistence environment than in a typical stand-alone on-premises Exchange organization. In both a coexistence and stand-alone Exchange environment, the on-premises edge transport server handles message protection and security for inbound and outbound mail routing to external organizations and recipients. However, the on-premises edge transport server is bypassed for message routing between the on-premises and cloud-based organizations in a coexistence environment. Instead, the on-premises coexistence server and the cloud-based FOPE service handle message routing between the two organizations. Additionally, the cloudbased FOPE service handles all message protection and security for messages between the onpremises and cloud-based organizations. Learn more about FOPE and Exchange Online: Shared Address Space with On-Premises Relay Scenario Edge Transport server configuration in coexistence Adding the coexistence server changes message routing configuration and the way that messages are processed within your Exchange organization in several ways: 87

88 1. The coexistence server is automatically included as an available Hub Transport server in your Exchange organization Since the coexistence server is configured with the Hub Transport server role and directly queries Active Directory, it will automatically assist other Hub Transport servers in your organization with routing all incoming messages to your onpremises mailbox servers. This means that from the Edge Transport server's perspective, the coexistence server is the equivalent of simply adding another Hub Transport server in the Exchange organization. The coexistence server will automatically assist in the routing of incoming messages from the Internet to on-premises recipient mailboxes, not just cloudbased recipients in your organization. This behavior is by design when you are using Edge Subscriptions to route Internet mail. 2. The coexistence server will assist with handling journaling and transport rules for your Exchange 2007 organization When the coexistence server is added to your existing Exchange organization, all existing journaling and transport rules are imported from your onpremises Hub and Edge Transport servers. This means that the coexistence server will apply these rules when processing messages just like any other Hub Transport server in your organization. However, if you update or add new journaling or transport rules in your organization after installing the coexistence server, you will need to manually update these rules on the coexistence server. The coexistence server won't automatically import changes to journaling or transport rules after it has been added to your Exchange organization. This is because of the way Transport rules are handled has significantly changed in Exchange Learn more about transport rules and journaling when adding an Exchange 2010 server to your Exchange 2007 organization: Upgrade from Exchange 2007 Transport 3. The coexistence server will assume your organization's EdgeSync synchronization duties Because Exchange 2010 is preferred for EdgeSync synchronization, the coexistence server will assume EdgeSync duties the next time a Hub Transport server selection occurs for EdgeSync synchronization in your organization. If you prefer that the coexistence server doesn't take over EdgeSync synchronization, you can disable the Microsoft Exchange EdgeSync service on the coexistence server. Learn more about Hub Transport server selection for EdgeSync: Understanding Edge Subscriptions Learn more about adding an Exchange 2010 Hub Transport server in an Exchange 2007 organization at Upgrade from Exchange 2007 Transport. Understanding IRM Coexistence Information Rights Management (IRM) helps you to protect against leakage of sensitive information by providing persistent online and offline protection of messages and attachments. Both Microsoft Exchange Server 2007, in your on-premises organization, and Exchange Online, in Office 365 for Enterprises, support IRM. There are, however, differences between the two implementations, and you must configure IRM in the cloud-based Exchange organization before cloud-based users can use it. 88

89 IRM uses Active Directory Rights Management Services (AD RMS), which is a component of Windows Server 2008 R2. AD RMS allows users to create rights-protected content, such as e- mail messages and attachments and then control how that content is used, and to whom it can be distributed. Users can specify templates that determine how content can be used. For example, a user may specify that an message can't be forwarded to other recipients or that information in the message can't be copied. Learn more about IRM in Exchange 2007 at: Understanding the AD RMS Prelicensing Agent Learn more about IRM in Exchange 2010 at: Understanding Information Rights Management Learn more about AD RMS at: Active Directory Rights Management Services Overview Differences between IRM in Exchange 2007 and Exchange Online Exchange Online is based on Exchange 2010, which includes several new IRM features. This means that the IRM functionality that's available in your on-premises Exchange 2007 organization is different than the functionality available in your cloud-based Exchange organization. The following table provides a summary of features and functionality available in each organization. Available IRM Features Feature Available in Exchange 2007 Available in Exchange Online Manual protection of messages in Outlook Manual protection of messages in Outlook Web App View IRM-protected messages in Outlook View IRM-protected messages in Outlook Web App Yes No Yes Yes (Internet Explorer with Rights Management add-in required) Yes Yes Yes Yes IRM Pre-licensing agent Yes Yes RMS Policy templates No Yes Transport decryption No Yes Journal report decryption No Yes Exchange Search and discovery decryption Automatic Outlook protection rules No No Yes Yes 89

90 Feature Available in Exchange 2007 Available in Exchange Online Automatic transport protection rules No Yes Learn more about these features at: Understanding Information Rights Management IRM in coexistence Exchange uses AD RMS servers in the Active Directory forest in which the Exchange server is installed. For your on-premises Exchange 2007 servers, the on-premises AD RMS server is used. For your cloud-based Exchange organization, AD RMS servers that are maintained within the Office 365 datacenters are used. The AD RMS configuration that each Exchange organization uses is independent of any other AD RMS deployment. AD RMS configuration, and therefore IRM configuration, isn't automatically replicated between your on-premises Exchange organization and the cloud-based Exchange organization. Any AD RMS templates that you've defined aren't automatically copied to the cloud-based organization. If you want the same AD RMS templates to be available in the cloud-based Exchange organization, you must manually export the templates from your on-premises organization and apply them to the cloud-based organization. See the IRM Configuration in coexistence section later in this topic. User experience The IRM configuration that's applied to a user depends on the client the user uses and the location of the user's mailbox. The following table shows the AD RMS server a user will use. Active AD RMS server Client On-premises mailbox Cloud-based mailbox Outlook 2007 or Outlook 210 On-premises AD RMS On-premises AD RMS Outlook Web App On-premises AD RMS Cloud-based AD RMS ActiveSync device On-premises AD RMS Cloud-based AD RMS It's possible that, depending on the AD RMS configuration you configure in your on-premises and cloud-based organizations, a user who uses Outlook 2007 and Outlook Web App may see different AD RMS templates. For this reason, we strongly recommend that you apply the same templates to both your on-premises and cloud-based organizations. There should be no difference in the IRM experience for Outlook client users, regardless of whether their mailbox is located in the on-premises or cloud-based organization. Outlook Web App users whose mailbox is located on an Exchange 2007 server can only open rights-protected messages after installing the Rights Management for Internet Explorer add-in. They can't reply to or create new rights-protected messages. 90

91 Outlook Web App users whose mailbox is located in the cloud can open rights protected messages without any additional software and can reply to, and create, new rights-protected messages. Server functionality On-premises Exchange 2007 servers use the AD RMS pre-licensing agent to decrypt rightsprotected messages so that users don't need to supply credentials when they open those messages. The on-premises Exchange 2007 server contacts the on-premises AD RMS server to check usage policies and rights, and to request authorization to decrypt the message. The cloud-based Exchange organization provides several additional IRM-related features that make use of cloud-based AD RMS. These features, such as journal report decryption, make the content of right-protected messages available to Exchange services for additional processing. For example, the decrypted contents of a journaled message can be saved, along with the original rights-protected message, to allow for easier discovery. Additionally, IRM templates can automatically be applied to messages using either Outlook protection rules or transport rules to ensure that messages adhere to organization policies regarding information protection. IRM configuration in coexistence As mentioned earlier in this topic, IRM in Exchange relies on AD RMS being deployed in the Active Directory forest in which the Exchange server resides. AD RMS configuration isn't automatically synchronized between the on-premises organization and the cloud. You must manually export the AD RMS configuration, known as a trusted publishing domain (TPD), from your on-premises AD RMS server, and import that configuration into the cloud-based Exchange organization. The TPD contains the AD RMS config, including templates, that the cloud-based Exchange organization needs in order to use IRM. Learn more at: AD RMS Trusted Publishing Domain Considerations In addition to applying your on-premises AD RMS configuration to the cloud-based Exchange organization, you must ensure that your AD RMS servers can be contacted by Outlook and ActiveSync clients outside of your on-premises network. You must do this if you want these clients to access rights-protected messages outside of your on-premises network. After you've configured your on-premises network and exported the TPD data, you need to configure the cloud-based Exchange organization by importing the TPD data and enabling IRM. Note: Any time you modify your on-premises AD RMS configuration, you must manually apply the new configuration in the cloud-based Exchange organization. To do so, export the TPD data from your on-premises AD RMS server and import it into the cloud-based Exchange organization. Learn more at: Configure IRM for coexistence 91

92 Understanding Identity Federation Identity federation provides a true single sign-on (SSO) experience for users to access both the on-premises and cloud-based organizations with a single user name and password. Additionally, identity federation allows administrators to easily control account policies for cloud-based organization mailboxes by using on-premises Active Directory management tools. Learn more at: Prepare for identity federation Identity Federation for Coexistence Establishing identity federation requires several steps to configure the trust relationship between the on-premises Active Directory Federation Services (AD FS) server and the Microsoft Federation Gateway. Listed below are the high-level components required to establish and configure this trust: Active Directory Federation Services AD FS provides the various end-points that the Microsoft Federation Gateway uses to redirect clients to the AD FS server for different types of authentication. AD FS must be installed on a separate physical server that is a part of your on-premises network organization. Microsoft Identity Federation PowerShell Module This module automates the configuration of the on-premises AD FS server and the Microsoft Federation Gateway to establish the trust. End-point and certificate data is gathered from AD FS and provided to the Microsoft Federation Gateway for your organizational domain. Although not a requirement for identity federation, installing Directory Synchronization (DirSync) in your organization is strongly recommended if you're planning to deploy identity federation. DirSync is used to synchronize the Active Directory account properties of your on-premises users with the cloud-based service. Identity federation requires that a cloud-based identity is available for the Microsoft Federation Gateway to match against a user's login request. By deploying DirSync in the on-premises organization, administrators can have new user accounts, contacts, and groups automatically replicated to the cloud-based organization and avoid problems with Microsoft Federation Gateway login redirection. Understanding Shared and Split SMTP Namespaces with Exchange 2007 You can configure either a shared or split SMTP namespace when you configure coexistence between your on-premises Exchange organization and the cloud-based organization. Shared SMTP Namespaces A shared SMTP namespace, which is also known as a shared domain or shared address space, enables you to use the same domain address with both an existing on-premises Exchange 92

93 organization and the cloud-based organization. A user with a mailbox in the cloud-based organization can have an address with the same domain as a user in the on-premises Exchange organization. For example, an on-premises user has an address of [email protected] and a cloud-based user has an address of [email protected]. When you configure coexistence between an on-premises Exchange organization and the cloudbased organization, a shared namespace is the default configuration. You choose the SMTP namespace that will be shared between the on-premises Exchange organization and the cloudbased organization when you add the chosen namespace to the cloud-based tenant as an accepted domain. The users in your on-premises Exchange organization and in the cloud-based organization will share that address domain. On-Premises Address Policy Configuration Most Exchange organizations have address policies that define the addresses that are applied to mailboxes and other recipients by default when they're created. The primary address domain is the domain all replies to a given recipient will be sent to. This approach is the same in coexistence organizations. In coexistence organizations, an additional address domain must be added to the address policies in the on-premises Exchange organization. This address domain is the SMTP namespace of the cloud-based organization. For on-premises mailboxes, this additional address isn't used. However, when a mailbox is created in, or moved to the cloud-based organization, the on-premises Exchange organization uses this SMTP namespace as the target delivery address for those mailboxes. The examples in this checklist use service.contoso.com as the SMTP address of the cloud-based organization. Important: You must not use the service tenant FQDN, for example, contoso.onmicrosoft.com, as the SMTP address of the cloud-based organization. Shared Namespace Message Routing With shared SMTP namespaces, your on-premises organization receives all addressed to the shared namespace, regardless of whether the recipient is in the on-premises organization or in the cloud-based organization. If you have an Exchange 2007 Edge Transport server configured, that server receives a message from the Internet. The Edge Transport server then sends the message to an on-premises Hub Transport server, which may be an Exchange 2007 server or the coexistence server. The Hub Transport server determines where to route the message, depending on the location of the recipient. This can be useful if you want to configure journaling, transport rules, anti-spam or antivirus policies that apply to all recipients in either organization. When an message is received, a Hub Transport server resolves the recipient address on the message to a recipient object. If the recipient object is an on-premises mailbox or distribution group, the message is delivered to the recipient. If the recipient object is a mail user that's associated with a mailbox in the cloud-based organization, Exchange reviews the target 93

94 delivery address of the mail user and redirects the message to the cloud-based organization. The message is passed to the coexistence server and is then delivered to the cloud-based organization and delivered to the cloud-based mailbox. See the following figure for an example of the message flow. Inbound mail flow with a shared namespace Learn more at: Understanding Transport Options Split SMTP Namespaces A split SMTP namespace is where your on-premises organization uses an SMTP namespace or domain that's different from the namespace used by the cloud-based tenant. Mailboxes in each organization will have addresses with different domains. For example, an on-premises user has an address of [email protected] while a cloud-based user has an address of [email protected]. As mentioned earlier, coexistence uses shared namespaces by default. If you want to use a split namespace, you must configure each mailbox manually. On-Premises Address Policy Configuration Most Exchange organizations have address policies that define the addresses that are applied to mailboxes and other recipients by default when they're created. The primary address domain is the domain all replies to a given recipient will be sent to. As with organizations that use a shared namespace, you must add an additional address domain to the address policy in the on-premises Exchange organization. This address domain is the SMTP namespace of the cloud-based organization. For on-premises mailboxes, this additional address isn't used. However, when a mailbox is created in, or moved to the cloud-based organization, the on-premises Exchange organization uses this SMTP namespace as the target delivery address for those mailboxes. Unlike organizations that use a shared namespace, you must manually remove the on-premises SMTP namespace and make the SMTP namespace of the cloud-based organization the primary SMTP namespace on the mailbox. 94

95 Split Namespace Message Routing With split SMTP namespaces, messages that are sent to the on-premises SMTP namespace are sent to the on-premises Exchange organization, and messages sent to the cloud-based SMTP namespace are sent to the cloud-based organization. Messages to the cloud-based organization are never routed through the on-premises organization, even if recipients from both organizations are addressed on the same message. See the following figure for an example of the message flow. Inbound mail flow with a split namespace Understanding Shared Free/Busy with Exchange 2007 Sharing free/busy (calendar availability) information between users located on-premises and in the cloud-based organization is one of the primary benefits of a coexistence deployment. Users in both organizations can view each other's calendars just as if they were located in the same physical organization. This makes scheduling meetings and resources easy and efficient. Several components in a coexistence deployment are required to enable the shared free/busy feature: Federated Trust Both the on-premises and cloud-based organization need to have a federation trust established with the Microsoft Federation Gateway. A federation trust is a one-to-one relationship with the Microsoft Federation Gateway that defines parameters for your Exchange organization. The gateway uses these parameters when acting as a trust broker between your on-premises and cloud-based organization to exchange free/busy information between organization users. By default, a federation trust with the gateway is automatically configured for your cloud-based organization when the account is created. Learn more at: Understanding Federated Delegation Organization Relationships Organization relationships need to be configured for both the on-premises and cloud-based organization. An organization relationship defines the level of free/busy information shared for an organization. 95

96 Learn more at: Create an Organization Relationship Availability Address Space The access methods and associated credentials used to exchange free/busy data between the coexistence server and other on-premises Client Access servers needs to be configured for your organization. Learn more at: Add-AvailabilityAddressSpace When deploying coexistence for your organization, configuring shared free/busy calendar access isn't a requirement in all scenarios. However, creating a federation trust with the Microsoft Federation Gateway and configuring an organization relationship for the on-premises and cloudbased organization are coexistence requirements. If you don't want to allow free/busy sharing between your organization users, you can configure the organization relationship access level accordingly. The coexistence features shown in the following table have a dependency on federation trusts and organization relationships. Messaging area Features client Message tracking MailTips Multi-mailbox search Transport Mailbox moves Secure intra-organization message delivery Understanding Transport Options with Exchange 2007 When you configure coexistence between an on-premises Exchange organization and a cloudbased organization, you need to decide how to route mail and also understand how your existence organization will be impacted. The route taken by inbound messages sent to recipients in the on-premises organization or cloud-based organization depends on whether you've chosen to use a shared or split namespace. The route taken by outbound messages sent from recipients in the on-premises organization or cloud-based organization depends on whether you've configured centralized mail control or decentralized mail control. Whether you choose shared or split namespaces, or centralized or decentralized mail control, messages sent between the on-premises organization and the cloud-based organization are configured to use Transport Layer Security (TLS) transport to help secure that communication. 96

97 Important: The cloud-based service must communicate directly with the on-premises coexistence server for secure communication to work correctly. The following section talks about what you need to think about as you add the coexistence server to your organization. Exchange 2010 Hub Transport in an Exchange 2007 organization You need to consider the impact of introducing an Exchange 2010 Hub Transport server into an existing Exchange 2007 organization when you install the coexistence server. Hub Transport in Exchange 2010 has new features that impact how mail routing and configuration are handled. Here are some of the following things you need to consider: Exchange 2007 service pack All of the Exchange 2007 servers in the site where you're installing the coexistence server must be running, at minimum, Exchange 2007 Service Pack 2 (SP2) Message routing The coexistence server is added to the routing topology of the existing Exchange 2007 organization. Messages sent to and from Exchange 2007 mailboxes are handled by the Exchange 2007 Hub Transport servers in the organization. Messages sent to and from the cloud-based organization are handled by the coexistence server. Messages can be routed directly between the coexistence server and the Exchange 2007 Edge Transport server, if one is configured. Transport and journal rules Any existing Exchange 2007 transport and journal rules are copied to the coexistence server when it's added to the Exchange 2007 organization. Transport and journal rules on Exchange 2007 and Exchange 2010 servers are stored differently and must be maintained separately. DSN messages Delivery status notification (DSN) messages are stored differently and must be maintained separately, similar to transport and journal rules. Message tracking The tracking tool you use to track messages depends on the originating and destination mailboxes. New additional functionality, such as moderated recipients and shadow redundancy, are only available on Exchange 2010 servers. This new functionality doesn't extend to Exchange 2007 servers. Learn more at: Upgrade from Exchange 2007 Transport The following sections talk about shared and split namespaces, centralized and decentralized mail control, and trusted communication between the on-premises and cloud-based organizations. 97

98 Shared and Split Namespaces When you choose to use a shared namespace, all recipients in the on-premises and cloud-based organizations share the same SMTP domain in their addresses. The mail exchanger (MX) record for this SMTP domain sends mail to the on-premises Exchange organization. When a message arrives at the on-premises Exchange organization for a recipient that resides in the cloud, the Edge Transport server determines whether the message is spam or is malicious and if not, forwards it to a Hub Transport server in your organization. The Hub Transport server it sends the message to can be either an existing Exchange 2007 Hub Transport server, or it could be the coexistence server. The Hub Transport server determines whether a mailbox is located on an on-premises Exchange server or in the cloud-based organization by checking the recipient type. If the recipient type is a mailbox, the Hub Transport server routes the message to the on-premises Exchange server that contains that mailbox. Note: If the Hub Transport server that performed the lookup is the coexistence server, the message is first routed to the Exchange 2007 Hub Transport server before delivery to the mailbox If the recipient type is a remote mailbox, which is a special type of mail user, the Hub Transport retrieves the remote routing address for that remote mailbox. The remote routing address for the mail user is the SMTP address of its associated mailbox in the cloud-based organization. The Hub Transport server readdresses the message with the SMTP address of the cloud-based mailbox. If the server that performed the lookup is an Exchange 2007 server, it sends the message to the coexistence server. The coexistence server then sends the message to the cloud-based organization. The examples in this checklist use service.contoso.com as the SMTP address of the cloud-based organization. Important: You must not use the service tenant FQDN, for example, contoso.onmicrosoft.com, as the SMTP address of the cloud-based organization. Note: For the best coexistence experience, we strongly recommend that you use a shared namespace. When you choose to use a split namespace, the addresses of recipients in the cloudbased organization are configured with an SMTP domain that's different from addresses of recipients in the on-premises organization. Messages sent to recipients in one organization are delivered directly to that organization. Learn more about shared and split namespaces at: Understanding Shared and Split SMTP Namespaces 98

99 Centralized and Decentralized Mail Control In addition to choosing how inbound messages addressed to recipients to your organizations are routed, you can also choose how outbound messages sent from cloud-based recipients are routed. The following describes the available options: Centralized mail control This option routes outbound messages sent from the cloud-based organization through your on-premises organization. Except for messages sent to other recipients in the same cloud-based organization, all messages sent from recipients in the cloud-based organization are sent through the on-premises organization. This enables you to apply compliance rules to these messages and any other processes or requirements that must be applied to all of your recipients, regardless of whether they're located in the cloudbased organization or the on-premises organization. Important: Your on-premises coexistence server must be accessible from the Internet for recipients in the cloud-based organization to send messages to the Internet. If your on-premises coexistence server is unavailable, messages sent from the cloud-based organization will queue until it's available again. Decentralized mail control This option routes outbound messages sent from the cloudbased organization directly to the Internet. Use this option if you don't need to apply any onpremises policies or other processing to messages that are sent from recipients in the cloudbased organization. Trusted Communication Regardless of whether you've selected shared or split namespaces, or centralized or decentralized mail control, all messages that are sent between recipients in your on-premises organization and the cloud-based organization are sent directly to and from either organization. As part of the configuration provided in the procedures in this checklist, each organization is configured to treat messages sent from the other organization as internal. This allows messages to bypass anti-spam settings and other services. To help protect recipients in both organizations, and to help ensure that messages sent between the organizations aren't intercepted and read, transport between both organizations is configured to use forced TLS transport using Secure Sockets Layer (SSL) certificates provided by a trusted third-party Certificate Authority (CA). When using forced TLS transport, the sending and receiving servers examine the certificate configured on the other server. The subject name, or one of the subject alternative names (SANs), configured on the certificates must match the fully qualified domain name (FQDN) that an administrator has explicitly specified on the other server. For example, if the cloud-based organization is configured to accept and secure messages sent from the mail2.contoso.com FQDN, the sending on-premises coexistence server must have an SSL certificate with mail2.contoso.com in either the subject name or SAN. If this requirement isn't met, the connection is refused. 99

100 Note: The FQDN used doesn't need to match the domain name of the recipients. The only requirement is that the FQDN in the certificate subject name or SAN must match the FQDN that the receiving or sending servers are configured to accept. Trusted communication between your on-premises organization and cloud-based organization requires that the on-premises server accepting the connection, called the TLS endpoint, be an Exchange 2010 server. In your on-premises organization, this is the coexistence server. If the TLS endpoint is a non-exchange 2010 server, the connection will fail. For this reason, you must configure the cloud-based organization to send mail directly to the coexistence server. Your existing Exchange 2007 Hub Transport or Edge Transport servers can't be the TLS endpoint for connections from the cloud-based organization. This requires that you provide an external IP address to the coexistence server and open port 25 on your firewall to the coexistence server. Learn more about SSL certificates and domain security at: Understanding Certificate Requirements, Understanding TLS Certificates Each of the following sections shows how mail flows, depending on the choices you've made. Select the section to see how mail flows for your choice. Shared namespace with centralized mail control When you configure your on-premises and cloud-based organization to use a shared namespace and to also use centralized mail control, all messages sent to and from recipients in both the onpremises organization and the cloud-based organization are sent through the on-premises organization. In the diagram below, which shows inbound messages sent to recipients in your organization, the following occurs: 1. An inbound message is sent from an Internet sender to the recipients [email protected] and [email protected]. Chris's mailbox is located on an Exchange 2007 server in the onpremises organization. David's mailbox is located in the cloud-based organization. 2. Because the recipients both have contoso.com addresses, and the MX record for contoso.com points to the on-premises Edge transport server, the message is delivered to the on-premises Edge Transport server. 3. The Edge Transport server selects a Hub Transport server in the on-premises organization to transfer the message to. The Edge Transport server can select either an Exchange 2007 Hub Transport server or it can select the coexistence server. 4. The message is delivered to a Hub Transport server which performs a lookup for each recipient using an on-premises global catalog server. Through the global catalog lookup, it determines that Chris's mailbox is located on the Exchange 2007 server while David's mailbox is located in the cloud and has a routing address of [email protected] 100

101 5. The Hub Transport server splits the message into two copies. One copy of the message is sent to the Exchange 2007 mailbox. If the coexistence server received the message and performed the lookup, Chris's message is first delivered to the Exchange 2007 Hub Transport before final delivery to her mailbox on the Exchange 2007 server. 6. The second copy is sent to the cloud-based organization. If the Exchange 2007 Hub Transport server received the message and performed the lookup, David's message is first delivered to the coexistence server. Then, the message is sent, over the Internet, through the send connector that's configured between the coexistence server and the Forefront Online Protection for Exchange (FOPE) service, which receives message sent to the cloud-based organization. 7. FOPE scans the message for viruses and then sends the message to the cloud-based organization where the message is delivered to David's mailbox. Inbound mail to a shared namespace via on-premises coexistence server In the diagram below, which shows outbound messages sent to the Internet, the following occurs: 1. Chris, who has a mailbox on the on-premises Exchange 2007 server, sends a message to an external Internet recipient, [email protected]. David, who has a mailbox in the cloud-based organization, sends a message to the external recipient [email protected]. Both Chris and David have a contoso.com reply address. 2. The Exchange 2007 mailbox server sends Chris's message to the Exchange 2007 Hub Transport server. The Hub Transport server sends the message to the Exchange 2007 Edge Transport server. 3. The cloud-based organization sends David's message to FOPE. 4. FOPE is configured to send all Internet-bound messages to the on-premises coexistence server, so the message is routed to the coexistence server. FOPE is configured to bypass the on-premises Exchange 2007 Edge Transport server. 5. The coexistence server sends the message to the Exchange 2007 Hub Transport server. 6. The Edge Transport server performs compliance, anti-virus, and any other processes configured by the administrator, on both Chris and David's messages. 7. The Edge Transport server looks up the MX record for cpandl.com and sends the messages to the cpandl.com mail servers located on the Internet. 101

102 Outbound mail from a shared namespace via on-premises coexistence server Shared namespace with decentralized mail control When you configure your on-premises and cloud-based organizations to use a shared namespace, but choose to use decentralized mail control, all inbound messages sent to recipients in either organization are sent through the on-premises organization. However, outbound messages sent from recipients in either organization are sent directly to the Internet. The cloud-based organization doesn't send messages to the Internet through the on-premises organization. In the diagram below, which shows inbound messages sent to recipients in your organization, the following occurs: 1. An inbound message is sent from an Internet sender to the recipients [email protected] and [email protected]. Chris's mailbox is located on an Exchange 2007 server in the onpremises organization. David's mailbox is located in the cloud-based organization. 2. Because the recipients both have contoso.com addresses, and the MX record for contoso.com points to the on-premises Edge transport server, the message is delivered to the on-premises Edge Transport server. 3. The Edge Transport server selects a Hub Transport server in the on-premises organization to transfer the message to. The Edge Transport server can select either an Exchange 2007 Hub Transport server or it can select the coexistence server. 4. The message is delivered to a Hub Transport server which performs a lookup for each recipient using an on-premises global catalog server. Through the global catalog lookup, it determines that Chris's mailbox is located on the Exchange 2007 server while David's mailbox is located in the cloud and has a routing address of [email protected]. 5. The Hub Transport server splits the message into two copies. One copy of the message is sent to the Exchange 2007 mailbox. If the coexistence server received the message and performed the lookup, Chris's message is first delivered to the Exchange 2007 Hub Transport before final delivery to her mailbox on the Exchange 2007 server. 6. The second copy is sent to the cloud-based organization. If the Exchange 2007 Hub Transport server received the message and performed the lookup, David's message is first delivered to the coexistence server. Then, the message is sent, over the Internet, through the 102

103 send connector that's configured between the coexistence server and the Forefront Online Protection for Exchange (FOPE) service, which receives message sent to the cloud-based organization. 7. FOPE scans the message for viruses and then sends the message to the cloud-based organization where the message is delivered to David's mailbox. Inbound mail to a shared namespace via on-premises coexistence server In the diagram below, which shows outbound messages sent to the Internet, the following occurs: 1. Chris, who has a mailbox on the on-premises Exchange 2007 server, sends a message to an external Internet recipient, [email protected]. David, who has a mailbox in the cloud-based organization, sends a message to the external recipient [email protected]. Both Chris and David have a contoso.com reply address. 2. The Exchange 2007 mailbox server sends Chris's message to the Exchange 2007 Hub Transport server. The Hub Transport server sends the message to the Exchange 2007 Edge Transport server. 3. The Edge Transport server performs compliance, anti-virus, and any other processes configured by the administrator, on Chris's message. 4. The Edge Transport server looks up the MX record for cpandl.com and sends the message to the cpandl.com mail servers located on the Internet. 5. The cloud-based organization sends David's message to FOPE. 6. FOPE is configured to send all Internet-bound messages directly to the Internet. FOPE looks up the MX record for cpandl.com. 7. FOPE delivers the message directly to the cpandl.com mail servers located on the Internet. Because the message never transits through the coexistence server, no on-premises processes are applied to it. 103

104 Outbound mail from a shared namespace via independent paths Split namespace with centralized mail control In the diagram below, which shows inbound messages sent to recipients in your organization, the following occurs: 1. An inbound message is sent from an Internet sender to the [email protected] and another message is sent to [email protected]. Chris's mailbox is located on an Exchange 2007 server in the on-premises organization. David's mailbox is located in the cloud-based organization. 2. Because the recipients have different address domains, the sending server sends each message to the organization that receives messages for each domain. The MX record for contoso.com points to the on-premises Edge Transport server while the MX record for service.contoso.com points to FOPE. 3. The Edge Transport server selects a Hub Transport server in the on-premises organization to transfer the message to. The Edge Transport server can select either an Exchange 2007 Hub Transport server or it can select the coexistence server. 4. The message is delivered to a Hub Transport server which performs a lookup for each recipient using an on-premises global catalog server. Through the global catalog lookup, it determines that Chris's mailbox is located on the Exchange 2007 server. 5. If the coexistence server received the message, it sends Chris's message to the Exchange 2007 Hub Transport server. The Hub Transport server delivers the message to Chris's mailbox on the Exchange 2007 server. 6. The message for David is sent to FOPE, which receives message sent to the cloud-based organization. 7. FOPE scans the message for viruses and then sends the message to the cloud-based organization where the message is delivered to David's mailbox. 104

105 Inbound mail to split namespaces via independent paths In the diagram below, which shows outbound messages sent to the Internet, the following occurs: 1. Chris, who has a mailbox on the on-premises Exchange 2007 server, sends a message to an external Internet recipient, [email protected]. David, who has a mailbox in the cloud-based organization, sends a message to the external recipient [email protected]. Chris has a reply address of [email protected] and David has a reply address of [email protected]. 2. The Exchange 2007 mailbox server sends Chris's message to the Exchange 2007 Hub Transport server. The Hub Transport server sends the message to the Exchange 2007 Edge Transport server. 3. The cloud-based organization sends David's message to FOPE. 4. FOPE is configured to send all Internet-bound messages to the on-premises coexistence server, so the message is routed to the coexistence server. FOPE is configured to bypass the on-premises Exchange 2007 Edge Transport server. 5. The coexistence server sends the message to the Exchange 2007 Hub Transport server. 6. The Edge Transport server performs compliance, anti-virus, and any other processes configured by the administrator, on both Chris and David's messages. 7. The Edge Transport server looks up the MX record for cpandl.com and sends the messages to the cpandl.com mail servers located on the Internet. Outbound mail from split namespaces via on-premises coexistence server 105

106 Split namespace with decentralized mail control In the diagram below, which shows inbound messages sent to recipients in your organization, the following occurs: 1. An inbound message is sent from an Internet sender to the and another message is sent to Chris's mailbox is located on an Exchange 2007 server in the on-premises organization. David's mailbox is located in the cloud-based organization. 2. Because the recipients have different address domains, the sending server sends each message to the organization that receives messages for each domain. The MX record for contoso.com points to the on-premises Edge Transport server while the MX record for service.contoso.com points to FOPE. 3. The Edge Transport server selects a Hub Transport server in the on-premises organization to transfer the message to. The Edge Transport server can select either an Exchange 2007 Hub Transport server or it can select the coexistence server. 4. The message is delivered to a Hub Transport server which performs a lookup for each recipient using an on-premises global catalog server. Through the global catalog lookup, it determines that Chris's mailbox is located on the Exchange 2007 server. 5. If the coexistence server received the message, it sends Chris's message to the Exchange 2007 Hub Transport server. The Hub Transport server delivers the message to Chris's mailbox on the Exchange 2007 server. 6. The message for David is sent to FOPE, which receives message sent to the cloud-based organization. 7. FOPE scans the message for viruses and then sends the message to the cloud-based organization where the message is delivered to David's mailbox. Inbound mail to split namespaces via independent paths In the diagram below, which shows outbound messages sent to the Internet, the following occurs: 1. Chris, who has a mailbox on the on-premises Exchange 2007 server, sends a message to an external Internet recipient, [email protected]. David, who has a mailbox in the cloud-based organization, sends a message to the external recipient [email protected]. Chris has a reply 106

107 address of and David has a reply address of [email protected]. 2. The Exchange 2007 mailbox server sends Chris's message to the Exchange 2007 Hub Transport server. The Hub Transport server sends the message to the Exchange 2007 Edge Transport server. 3. The Edge Transport server performs compliance, anti-virus, and any other processes configured by the administrator, on Chris's message. 4. The Edge Transport server looks up the MX record for cpandl.com and sends the message to the cpandl.com mail servers located on the Internet. 5. The cloud-based organization sends David's message to FOPE. 6. FOPE is configured to send all Internet-bound messages directly to the Internet. FOPE looks up the MX record for cpandl.com. 7. FOPE delivers the message directly to the cpandl.com mail servers located on the Internet. Because the message never transits through the coexistence server, no on-premises processes are applied to it. Outbound mail from split namespaces via independent paths 107