Chapter 10. Preparing an on-premises environment to connect to Exchange Online

The Exchange Online component of Office 365 supports cloud-only deployments; hybrid coexistence; and staged, cutover, and hybrid migration paths. Before configuring your existing Exchange on-premises environment to connect to Office 365, plan to take a step back to evaluate the current state of your Exchange organization. Ensuring that you meet all the prerequisites prior to undergoing coexistence or migration steps will help save time and reduce the risk of failure.

Exchange Online deployment concepts

If you are familiar with Exchange on-premises, you might already have a good basis for understanding how Exchange Online works. Just as Exchange on-premises uses an Active Directory environment to store attributes and properties for configuration and recipient objects, Exchange Online also stores its configuration information in Active Directory. In the case of Exchange Online, the Active Directory component is Azure Active Directory, a multitenant directory service designed to scale to billions of objects.

Recipients

Exchange Online has many types of recipients, and all of them have some relationship to an underlying Active Directory object. Mailboxes, contacts, and distribution groups build on a corresponding Active Directory object by adding Exchange-specific attributes (mail, proxyAddress, and mailNickname are a few examples) and exposing them to the Exchange interfaces.

For more information about the various object types used in Exchange Online (and Office 365 in general) and how to interact with them, see Chapter 11, “Understanding the Office 365 Resource Types.”

Mail routing

Similar to Exchange on-premises, Exchange Online uses the concept of connectors to manage mail flow. You can scope connectors to send traffic for one or more domains on a specific route or receive from one or more hosts by using a specific configuration. In Exchange on-premises, you designate connectors as either Send Connectors (which control outgoing mail flow from a server) or Receive Connectors (which control incoming mail to a server). In Exchange Online, the analogous connectors are Outbound (Send) and Inbound (Receive) and are labeled from the perspective of the Office 365 tenant.

In addition to connectors, Exchange Online also enables you to define connection filters to allow or block connections from specific IP addresses or ranges as well as transport rules to filter or modify inbound and outbound traffic further.

When establishing mail flow with a foreign system (Exchange Online or an external messaging environment), you might configure one or more connectors and filters to control the mail flow.

For more advanced mail flow configurations and scenarios, see “Mail flow best practices for Exchange Online and Office 365 (overview)” at https://technet.microsoft.com/en-us/library/jj937232(v=exchg.150).aspx.

Autodiscover

Autodiscover is the process that Microsoft Outlook uses to determine the location of a user’s mailbox. Autodiscover can be configured to use one or more methods, including looking for specific DNS records or service connection points (SCPs) in Active Directory.

Autodiscover is also used as part of the free/busy lookup process whereby a user’s calendar is queried to check availability for meeting requests. In previous versions of Exchange, it was not necessary to configure Autodiscover to configure Outlook. However, Office 365 requires the use of Autodiscover to configure mailboxes correctly.

Depending on your configuration and business requirements, you can configure Autodiscover differently than the recommended records in the Office 365 portal. In hybrid configurations, you should configure Autodiscover DNS records to point to the on-premises mail system because Exchange on-premises can redirect requests to Office 365 but not vice versa. When all mailboxes are migrated, you can choose to update your Autodiscover records to point to Office 365.

Each Outlook client goes through a predefined Autodiscover lookup order:

1. Service connection point The class service connection point is defined in the Active Directory schema. SCP objects published in Active Directory contain information that clients can use to bind to a particular service or host offering a service. Exchange Service Connection Point objects are created under the CN=Autodiscover,CN=Protocols,CN=<Exchange Server>,CN=Servers,CN=Exchange Administrative Group,CN=Administrative Groups,CN=<Exchange Organization>,CN=Microsfot Exchange,CN=Services container. The value in the serviceBindingInformation attribute is configured as https://<Exchange Server FQDN>/autodiscover/autodiscover.xml.
2. HTTPS root domain query When Outlook is running on a machine that is not joined to an Active Directory domain, the client constructs a URL based on the domain portion of the user’s email address. For example, if your email address is [email protected] and you are attempting to configure Outlook on a computer that is not domain-joined, it attempts to query the Autodiscover service at https://cohovineyardandwinery.com/autodiscover/autodiscover.xml.
3. HTTPS Autodiscover domain query If the previous queries don’t return the location of an Autodiscover service, Outlook uses the domain portion of the user’s email address to try a new URL. Using the previous domain as an example, Outlook tries https://autodiscover.cohovineyardandwinery.com/autodiscover/autodiscover.xml. This is the default Autodiscover record format that appears on the Office 365 Domains configuration page.
4. HTTP redirect method If an HTTPS Autodiscover domain query fails, Outlook retries the same URL, using HTTP instead of HTTPS.
5. SRV record query The next method Outlook uses to locate a user’s mailbox is by querying DNS for a service locator (SRV) record, using a predefined format. The record is configured as _autodiscover._tcp.domain.com, with the host name pointing to the Exchange server hosting the Autodiscover service and the port value configured as 443.
6. Local XML Outlook can also be configured to use a local XML file, which requires manually creating an autodiscover.xml file and modifying the local computer’s registry to point to the path of the XML file.
7. Cached URL Introduced in Outlook 2013, if all other discovery methods fail, Outlook attempts to use the location of the last Autodiscover service that it used (if a profile had successfully been configured before).

You can use Group Policy or modify the registry to disable specific Autodiscover methods. For more information, see https://support.microsoft.com/en-us/help/2612922/how-to-control-outlook-autodiscover-by-using-group-policy.

Migration and coexistence methodologies

When planning a coexistence with or migration to Exchange Online, you will want to consider both your long-term and short-term goals in addition to your current Active Directory, Exchange, desktop configuration, and network topologies. Depending on your business requirements and environment, you might be able to choose one or more of these migration coexistence strategies.

• Cutover migration If your on-premises environment is running Exchange 2003, Exchange 2007, Exchange 2010, or Exchange 2013, and you have fewer than 2,000 mailboxes, you can use a cutover migration. Due to the nature of a cutover, you have to migrate everyone together. Although 2,000 mailboxes is the maximum number of users that can be migrated with this method, it’s more realistic to limit it to environments with 150 mailboxes or fewer.
• Staged migration If your on-premises environment is running Exchange 2003 or Exchange 2007 and you have more than 150 mailboxes, you can run a staged migration. Staged migrations require the use of Azure Active Directory Connect (AAD Connect).
• Express migration If your on-premises environment is running Exchange 2010, Exchange 2013, or Exchange 2016, you don’t plan to use any directory synchronization technologies to migrate your users, and don’t need to maintain the ability to look up free/busy status between Office 365 and on-premises users, you can use an express migration. Express migrations can also be referred to as minimal hybrid migrations.
• Hybrid migration If your on-premises environment is running Exchange 2010, Exchange 2013, or Exchange 2016, you can use a hybrid migration. You can also use hybrid migrations in Exchange 2003 or Exchange 2007 environments if you deploy an Exchange 2010 or Exchange 2013 server. Hybrid migrations support the idea of online mailbox migrations if mailboxes are hosted on Exchange 2007 or later servers, meaning that the user’s mailbox stays mounted and online until the moment of cutover, and then the user’s Outlook profile can be redirected to Office 365. If mailboxes are hosted on Exchange 2003, the mailbox is locked and unavailable until the migration for that mailbox is completed. Public folders hosted on Exchange 2003 must be migrated to Exchange 2007 before hybrid coexistence or migration can be performed.
• IMAP migration If your source environment is running a version of Exchange prior to 2003 or a foreign email system, you can use an IMAP migration. IMAP migrations are typically unable to migrate calendar and contacts. Most organizations that need to perform migrations from non-Microsoft or hosted platforms work with a partner that specializes in migrations or uses third-party tools.

You can find more information about choosing migration methods in Chapter 12, “Mailbox Migration Types.” If you know you are going to perform a hybrid configuration for either mailbox migration or long-term coexistence, see Chapter 13, “Exchange Online Hybrid.”

Planning considerations

From the planning perspective, you’ll need to analyze each of the types of recipients you want to migrate as well as transport rules, business requirements, and your existing environment.

Exchange and Active Directory on-premises environment

At the core of your migration planning will be your existing Exchange and Active Directory environments. To ensure a smooth coexistence or deployment, make sure you spend time reviewing your current environments.

Active Directory versions and configuration

The minimum requirement for configuring AAD Connect is that your Active Directory is upgraded to at least Windows Server 2003 forest functional level. If you are planning to use the password writeback feature of AAD Connect, your domain controllers must be running Windows Server 2008 or later with current updates.

Autodiscover

A properly configured Autodiscover service is necessary for access to Office 365. In addition, if you are going to configure hybrid coexistence for public folders, on-premises Autodiscover is necessary so that the Public Folder proxy mailboxes can locate the on-premises Exchange Public Folder tree.

In topologies with mixed versions of Exchange, the Autodiscover service should be configured to point to the latest version of Exchange.

Certificates

Confirm that a third-party certificate has been installed and configured correctly and is used in publishing Exchange services, including Exchange Control Panel (ECP), Exchange Web Services (EWS), Offline Address Book (OAB), and Outlook Web App (OWA). Occasionally, the certificate file that has been installed might seem to be fine but causes problems with the hybrid configuration setup. To check your certificate, run the following cmdlet in the on-premises Exchange Management Shell against the thumbprint of the certificate that you use for hybrid configuration, as shown in Figure 10-1.

Get-ExchangeCertificate -ThumbPrint <thumbprint> | Format-List
HasPrivateKey,IsSelfSigned,RootCAType,Status

Figure 10-1 Exchange certificate details

Exchange versions, service packs, cumulative updates, and rollups

Prior to starting a migration or hybrid configuration, verify that the most recent Exchange service packs, cumulative updates, and rollups are applied. This is especially important for Exchange hybrid deployments, because the Hybrid Configuration Wizard implements features and connectors in the Exchange environment and performs compatibility tests. For every version of Exchange Server supported in a hybrid topology, the servers must be at N-2 current (current version and up to two previous versions of cumulative updates or rollups) to be successfully configured.

Your organization’s long-term management strategy should dictate which version of Exchange you deploy for Exchange Online coexistence or migration. For example, if you decide to transition to a purely cloud-based environment or have an existing Exchange 2003 deployment, you might choose to do the bare minimum to transition to Office 365. You can use the following information in Table 10-1 to help determine which versions of Exchange are supported for your environment.

Table 10-1 Exchange support matrix

On-premises environment	Exchange 2016–based hybrid deployment	Exchange 2013–based hybrid deployment	Exchange 2010–based hybrid deployment
Exchange 2016	Supported	Not supported	Not supported
Exchange 2013	Supported	Supported	Not supported
Exchange 2010	Supported	Supported	Supported
Exchange 2007	Not supported	Supported	Supported
Exchange 2003	Not supported	Not supported	Supported

You can find information about Exchange updates at https://technet.microsoft.com/en-us/library/hh135098(v=exchg.150).aspx.

Exchange Best Practices Analyzer

Depending on your version of Exchange, the Best Practices Analyzer might be included or available as a separate download. Run the Exchange Best Practices Analyzer to identify potential configuration issues. The Exchange Best Practices Analyzer can make recommendations for memory or logging configurations, identify databases that haven’t been backed up in a long time or network or storage drivers that are out of date, or point out other less favorable configurations.

For Exchange 2003, the most current Best Practices Analyzer is available at https://www.microsoft.com/en-us/download/details.aspx?id=22485. Starting with Exchange 2007, the Best Practices Analyzer is included in the product.

IDFix

Microsoft provides the IDFix tool to help identify and resolve common directory attribute errors in your on-premises Active Directory and Exchange environments. Common issues might include invalid characters in the UserPrincipalName (UPN) or mailNickname attributes or instances when two or more users have been configured with the same SMTP proxy address.

There are certain error conditions that it can’t detect yet, such as identifying when a user and a group might share the same SMTP address. These errors are frequently discovered when you synchronize your environment to Office 365 with AAD Connect. IDFix can identify when user objects have UPNs that have non-public, top-level domains (TLDs) but cannot identify whether you have UPNs or proxy addresses that have not been configured in your Office 365 tenant.

If you begin receiving errors such as duplicate proxy addresses during synchronization by AAD Connect, you can use the script at https://gallery.technet.microsoft.com/Find-Duplicate-Values-in-6b012059 to identify the conflicting objects. The script identifies all instances of the conflicting address across all object types.

SSL offloading

Some organizations might configure Secure Sockets Layer (SSL) offloading, using one or more network devices to terminate the SSL connections. This is frequently configured in large organizations that have deployed server farms so that administrative teams don’t have to manage certificates across many servers. Although SSL offloading is supported for Outlook Web App traffic as well as for some other Exchange Web Services calls, it is not supported for Mailbox Replication Service (MRS) traffic. MRS is used for the mailbox migrations to and from Office 365 and expects end-to-end SSL encryption of the traffic. If your organization uses SSL offloading, you will most likely need to configure a separate virtual IP (VIP) interface for the servers used for hybrid mailbox moves.

Windows updates

An often-overlooked basic environment check is to make sure your servers are up to date with both Windows and Exchange updates. Updates can include performance, security, or feature enhancements that your migration or coexistence environment needs to function optimally.

Recipients

From a coexistence or migration perspective, some objects might be fully migrated, whereas others might be only synchronized. Depending on your long-term business and technology objectives, you might have a deployment that has objects directly managed in Office 365, objects that are managed on-premises, or both.

For example, you might decide after your migration is done that you just want to manage objects in the cloud, and you disable directory synchronization and decommission Exchange from your on-premises environment; you might continue to manage your Active Directory objects on-premises, synchronize them to Office 365, and manage Exchange features through either the Office 365 and Exchange admin centers or through Windows PowerShell; or you might even choose to migrate some objects to Office 365 for full cloud management but keep other objects on-premises.

Contacts

A contact is a mail-enabled recipient that is used to provide visibility in the global address list for an external recipient. Contacts can represent foreign users, resources, or distribution groups. Contacts can be synchronized from your on-premises directory to Office 365 and managed on-premises, or they can be created in Office 365 as stand-alone objects.

Mailboxes

The mailbox object, whether user, shared, or resource, is a data storage object that will exist in either the on-premises environment or Office 365. In deployments with synchronized identity, the Exchange properties for a mailbox might be configured in the on-premises environment and synchronized through AAD Connect to Office 365, or they might be managed directly in Office 365.

Relationship between mail-enabled users and mailboxes

If you are new to Exchange or have never migrated objects between Exchange organizations, you might have noticed that objects in synchronized environments can appear differently, depending on which interface you’re using.

When you synchronize on-premises users who have mailboxes to Office 365, it’s important to understand the relationship between the on-premises and cloud objects. From the Active Directory perspective, the on-premises user’s objectGuid value is converted to a base64 string value and stored as the ImmutableID on the object’s corresponding Azure Active Directory object.

The relationship between the on-premises objectGuid and the cloud ImmutableID values can be expressed this way, as shown in Figure 10-2:

[system.convert]::ToBase64String(objectGuid).ToByteArray()

Figure 10-2 Active Directory objectGuid and Office 365 ImmutableID

From the Exchange perspective, every on-premises mailbox user who is synchronized is represented by a mail-enabled user in Exchange Online. The primary differences are that mail-enabled users have the idea of a targetAddress (a type of forwarding address) and values for msExchRecipientTypeDetails and msExchRecipientDisplayType that tell Exchange it’s only a mail-enabled object, whereas mailbox users do not have a targetAddress value and instead have a value for homeMDB. Mailbox users have a value in msExchRecipientTypeDetails and msExchRecipientDisplayType that indicates that they are mailboxes.

Prior to migration, when you look at a mailbox user from Exchange on-premises, they are seen as a local mailbox user. That same user, when viewed from the perspective of Exchange Online, is displayed as MailUser. When you view a migrated user from Exchange on-premises, their Recipient Display Type indicates they are a MailUser, and their Recipient Type Details indicates they are a Remote Mailbox User (a subtype of MailUser). When looking at migrated users from Exchange Online, they appear as Mailbox User.

Message sizes and attachments

If you are migrating from an Exchange on-premises environment to Office 365, using either a cutover or hybrid migration, you can migrate messages that are up to 150 MB each. However, if you are migrating using IMAP or Exchange Web Services (third-party tools typically use Exchange Web Services), the maximum message size that can be migrated is 35 MB. Depending on your migration strategy and how your users communicate, you might want to evaluate your mailboxes for large attachments so you can notify users that those objects will not migrate successfully.

Accepted domains and addressing

Accepted domains are the domains over which your organization claims ownership. Although you can add any domains you like to your on-premises Exchange organization, you may only add and confirm domains in your Office 365 environment for which you can prove ownership through DNS record registration. You can synchronize users and contacts with any email addresses to Office 365, but you can only migrate mailboxes for users that have verified domains in your tenant. If you have a mailbox that has proxy addresses for domains that are not confirmed in your tenant, the migration will fail. As part of a migration process, make sure your Office 365 tenant has all the domains added to it that your environment uses.

Any domains not matching must be removed from mailboxes prior to migration. The script at https://gallery.technet.microsoft.com/exchange/Remove-Exchange-Proxy-eb5be217 can help you remove addresses from objects.

To migrate mailboxes to Office 365 and enable successful Autodiscover and cross-premises mail routing, mailboxes need to have a proxy address matching <tenant>.mail.onmicrosoft.com. Mailboxes without a tenant proxy address will fail migration.

One of the tasks that the Hybrid Configuration Wizard performs is adding the tenant mail routing domain to all the email address templates that contain domains selected in the hybrid setup. In Exchange 2010, this can cause a large address book update to occur that has unexpected results if you have many email address templates or have manually configured primary SMTP addresses for users and have not set the EmailAddressPolicyEnabled attribute to False for those users. To avoid the automatic address book rebuild during Hybrid Configuration Wizard, you might want to update your email address templates beforehand. If you have many templates, this can be a daunting task. You can use the script at https://gallery.technet.microsoft.com/exchange/Bulk-or-Selectively-Update-be06b784 to bulk update your email address templates.

The corollary to that is that if you have users with EmailAddressPolicyEnabled set to False, those users will not get the tenant proxy address stamped on them and thus fail mailbox migration. You can use the script at https://gallery.technet.microsoft.com/exchange/Add-Office-365-Tenant-93391e4c to stamp mailboxes with the necessary tenant proxy address, or add an Out-To-AD rule to AAD Connect to update users automatically. You can use the script at https://gallery.technet.microsoft.com/exchange/Create-an-AAD-Connect-Rule-45ea6591 to modify AAD Connect to perform this function.

Mail-enabled users

Your organization might have on-premises security principals that have been configured as mail-enabled users. Mail-enabled users are not the same as mailbox users, because they do not have local mailbox storage in your organization. You can think about a mail-enabled user as a combination of both a security principal (user) and a contact—the result being a user who might have logon privileges to your network and a display entry in the global address list.

By default, mail-enabled users are synchronized to Office 365. If you have a mail-enabled user with a value in msExchMailboxGuid that is synchronized to Office 365, the object will be flagged as a mailbox awaiting migration in Office 365.

Groups

Groups, quite simply, are collections of mail-enabled objects—whether they are mailboxes, mail-enabled users, contacts, or other distribution groups.

When synchronized from an on-premises environment, most group properties can only be managed from the on-premises environment. Some organizations are accustomed to managing distribution groups through the Outlook interface, giving end-users the ability to add or remove group members as they need to without assistance from the service desk.

As far as considerations go, this is important to decide on. If groups are mastered on-premises and synchronized to Office 365, then Office 365 users will be unable to use Outlook to manage group membership. To continue to enable users to manage distribution groups through Outlook, groups must be re-created in Office 365, which can pose problems for mail-enabled security groups that are used as both distribution lists for mail recipients and a mechanism for granting permissions to network resources on-premises.

In these instances, you might need to make a break between the security and distribution list functions, create a script to copy members from one group to another on a regular basis (so that the group membership is the same between both cloud and on-premises), or manage two groups separately. If you choose to maintain separate groups, you can filter those particular groups from being synchronized.

Dynamic distribution groups

Although dynamic distribution groups are supported in Office 365, they are only supported when they are created directly in Office 365. On-premises dynamic distribution groups cannot be synchronized to Office 365.

If you have dynamic distribution groups on-premises that you want to show up in Office 365, you can create a mail-enabled contact in Office 365 to provide global address list visibility for the group or convert the dynamic group to a static group and manage it as a normal group.

Office 365 Groups

Office 365 groups (also known as modern or unified groups) are a new type of group object in Office 365 and do not exist in the on-premises versions of Exchange. If your organization decides to use Office 365 groups, they will exist only in-cloud.

A feature in AAD Connect enables you to write a mail-enabled object back on-premises to provide global address list visibility to on-premises users for these objects. Object writeback is discussed in detail in Chapter 4, “Directory Synchronization Basics,” and Chapter 5, “Installing Azure AD Connect.”

Permissions and delegation

Part of the email migration planning exercise is determining the migration schedule. Although it’s important to map out the schedule from the perspective of end-user communication, it’s also important for another reason: permissions and delegation. It’s critical to make an effort to move delegators and delegates together because not all the permissions work cross-premises. Although full mailbox access permissions should work, on-premises users won’t be able to exercise certain rights (such as Send-As) against cloud mailboxes and vice versa.

Typically, users are delegated rights to other mailboxes or resources in their own work group or department, so that might be one way to attempt to organize and map out migration groups to preserve permissions and mailbox access.

Public folders

Depending on how long your on-premises Exchange organization has existed, you might have public folders (either older or modern). You can migrate both types of public folders to Office 365. However, just like mailbox migrations, there are several things to check prior to migration, such as folder uniqueness and proper attribute validation.

The standard IDFix tool does not detect mail-enabled public folders. If you are planning to migrate a significant number of mail-enabled public folders, you might find it helpful to validate that they don’t have any invalid characters or improperly formatted SMTP addresses. You can use the script at https://gallery.technet.microsoft.com/IDFix-for-Public-Folders-341522d6 to help identify potential problems with your mail-enabled public folders.

Mail routing

Mail routing between on-premises and cloud environments is a crucial component of a migration or coexistence. It is important to ensure that the servers designated for hybrid transport can send to and receive from Exchange Online.

Data loss prevention

Office 365 offers data loss protection features that are integrated with Exchange Online protection. Data loss prevention templates can be implemented to scan for sensitive data types such as Social Security numbers or credit cards and perform block, notify, redirect, or encrypt actions on those messages.

In addition, your organization might have an existing investment in data loss prevention technologies that meets specific requirements, and you might need to configure Office 365 to route outbound mail through that environment. If that is a requirement, you will most likely use a centralized mail transport configuration, criteria-based routing transport rules, or a combination. For more information about centralized mail transport, see Chapter 13.

Message encryption

Your organization might have a requirement to encrypt messages sent to particular recipients or that contain certain types of data. In these instances, you might need to configure forced-TLS connectors or enable Office 365 message encryption settings. For more information about Office 365 message encryption, see Chapter 14.

Message hygiene

Most organizations have some sort of message hygiene (anti-spam, anti-malware, heuristic analysis) products or services configured, either on-premises or hosted by a service provider. Depending on your organization’s configuration and investment in those technologies, you might wish to continue using them or transition fully to Exchange Online Protection (EOP).

Although it is possible to configure multiple products for message hygiene in succession, it is not recommended. Exchange Online Protection uses, among other technologies and algorithms, IP reputation to determine whether a sending system is safe. Chaining multiple filtering products can have an adverse effect on the ability of EOP to provide the highest level of service.

Instead, you might consider cataloging rules and filters in your existing system and prepare to configure similar rules and filters in Exchange Online Protection.

Networking

When planning a migration of a core service such as messaging to an external system, consider how you will connect to that system both during the migration process and as you transition to operational management.

Bandwidth

One of the core questions surrounding network requirements is discovering how much bandwidth your users will consume post-migration. You can use a tool such as the Exchange Client Network Bandwidth Calculator to help estimate your bandwidth based on client profile and location or time zone data.

You can download the calculator from https://gallery.technet.microsoft.com/Exchange-Client-Network-8af1bf00.

Firewall

For mailbox migrations, free/busy lookups, Autodiscover, and mail transport to work correctly between on-premises and cloud environments, you must work with network administrators to enable the necessary communications.

From the perspective of the Exchange servers configured with hybrid connectivity, you need to ensure communication on port 25 inbound and outbound for mail transport; port 443 inbound for Autodiscover, Mailbox Replication Service, and free/busy; and ports 80 and 443 outbound for Exchange Federation and Certificate Revocation List checking.

For a complete list of hybrid endpoints, please refer to “Office 365 URLs and IP address ranges” at https://support.office.com/en-us/article/Office-365-URLs-and-IP-address-ranges-8548a211-3fe7-47cb-abb1-355ea5aa88a2.

Load balancing

Many large organizations use either software or hardware load balancers as part of a solution to provide highly available access to services. Load balancers can be configured to work with Office 365. However, there are several things to consider, depending on the version of Exchange that is being used for hybrid transport and mailbox migration.

SSL offloading, termination, or bridging is not supported for Mailbox Replication Service traffic. In addition, for configuring hybrid migration endpoints, it is recommended that you create one-to-one Network Address Translation (NAT) addresses for each server used for mailbox migrations. This provides the most granular method to manage mailbox migration endpoints.

Several hardware and software vendors have whitepapers and guides to assist in configuring their load balancers to work with Exchange. You can find resources for Exchange 2010-qualified load balancers at https://technet.microsoft.com/en-us/office/dn756394.

Proxy

Microsoft recommends that you bypass proxy environments for Office 365. If your outbound traffic uses proxies, you might experience performance problems or service connection problems when attempting to use Office 365 services.

Proxy services are typically used either to perform web-filtering requests (to ensure users’ traffic conforms to the organization’s acceptable usage policy) or to provide caching and accelerate performance for frequently accessed resources. All traffic between on-premises and Office 365 endpoints is encrypted by SSL, so most proxy implementations are unable to view or cache the traffic (without sophisticated man-in-the-middle or SSL bridging capabilities).

For further information about how Office 365 works with proxies and methods of deploying proxy automatic configuration scripts to workstations, please see https://blogs.technet.microsoft.com/undocumentedfeatures/tag/proxy-automatic-configuration/.

DNS

Many tasks performed in Office 365 require you to configure specific DNS records to enable or complete service enablement.

Autodiscover

Autodiscover is the service whereby clients (whether they are desktop, web, or mobile clients or remote Exchange systems) locate Exchange resources. For most Office 365 deployments, Autodiscover is configured through a DNS CNAME record that points to either the on-premises Exchange organization (prior to migration) or Office 365 (post-migration).

Domain verification records

To make a domain available to use in Office 365, you must add it and then confirm ownership with a DNS TXT record. You can find more information about how to configure DNS TXT verification records in Chapter 1, “Office 365 Deployment Milestones.”

Microsoft Federation Gateway

When configuring Exchange on-premises to share free/busy information with Exchange Online or other Exchange on-premises organizations or as part of the Hybrid Configuration Wizard, you must confirm ownership of your Exchange organization for the Microsoft Federation Gateway. You can generate the DNS verification record prior to running the Hybrid Configuration Wizard to streamline the process.

For more information about configuring DNS records for the Microsoft Federation Gateway, see Chapter 13.

MX record

The Mail eXchanger (MX) record tells mail transport agents where to route mail. Prior to migration, your MX record points to either your on-premises mail gateway or, perhaps, a hosted mail gateway service that provides antivirus and antispam services.

Post-migration, it’s recommended that you update your MX record to point to Exchange Online Protection.

SPF, DKIM, and DMARC records

These records help prove the authenticity and authority of sending email systems. Although they are not required, it is recommended that you configure them.

In addition, if you are already using them in your environment, plan to include Office 365 services to ensure that recipients can continue to receive your mail.

For more information about configuring DKIM, see Chapter 7, “Inside the Security & Compliance Center: Alerting, Threat Management, and Reporting.” For information about configuring SPF, DKIM, and DMARC in Office 365, see https://technet.microsoft.com/en-us/library/mt734386(v=exchg.150).aspx.

Network security appliances

In addition to firewalls and proxies, many organizations deploy network security appliances that inspect traffic, looking for suspicious activity. You can deploy intrusion detection systems (IDSs) and intrusion protection systems (IPSs) to monitor, alert, and take action on network traffic based on rules and activity profiles.

In some instances, these can slow or stop the flow of migration activities. Two such features of security appliances that can cause considerable delay or troubleshooting activities are flood mitigation and exfiltration protection. The exact terminology might vary, depending on the vendor, but the features restrict or deny the continued outbound data flow from your on-premises servers to Office 365, detecting the continuous stream of traffic to an off-premises destination as anomalous activity that might indicate data compromise or theft.

If your organization has deployed these types of devices, you will want to exclude traffic between the hybrid migration endpoints and Office 365 from any policies that interrupt the flow of migrating data.

Things that don’t migrate

Although the directory synchronization and hybrid migration process have become increasingly complete, there are still things that don’t translate between environments and, if you are using third-party tools to migrate from hosted or older systems, you’ll need to capture parameters and attributes in the source environment that did not make it to the target system.

Access protocol configuration

Certain mailbox parameters, such as what access protocols are allowed, are not migrated in hybrid or third-party migrations. If you are using CASMailbox settings to control access to ActiveSync, POP3, IMAP, or Exchange Web Services, you will find that those settings do not persist between on-premises and cloud environments.

Calendar processing information

Calendar processing is the set of rules that is typically applied to shared and resource mailboxes, such as automatic booking, delegates, and scheduling horizons. These settings are not migrated in either hybrid migrations or third-party migrations.

You can build your own method to export and import these properties or use a script such as at https://gallery.technet.microsoft.com/Export-and-Import-Calendar-123866af to capture and reapply those configurations.

Forwarding addresses

If you have mailboxes configured with forwarding addresses (ForwardingAddress or ForwardingSmtpAddress), those values are not maintained in either hybrid or third-party migrations.

You can use the script at https://gallery.technet.microsoft.com/exchange/Forwarding-Address-Import-5b3ead8e to export the data from your on-premises environment and re-apply it to cloud objects post-migration.

Retention tags and policies

Retention policy tags and retention policies are not synchronized or transferred between environments automatically. If you are using Exchange retention policy tags on-premises and wish to continue using them in Office 365, you must export them from your on-premises environment and import them to Office 365 before migrating mailboxes.

The scripts Export-RetentionTags.ps1 and Import-RetentionTags.ps1 are available in %EXCHANGEINSTALLDIR%Scripts.

You can find more information about exporting and importing retention policy tags at https://technet.microsoft.com/en-us/library/jj907307(v=exchg.150).aspx.

Transport rules and configurations

Transport rules and configurations are not migrated between environments. Depending on your organization, these might or might not be necessary. Many organizations, when migrating to Office 365, take the opportunity to create new rules. However, if your organization has a high degree of customization, you might find it helpful to transfer those settings and then remove what is unnecessary.

In addition, if you are in a position to need to migrate to a new Office 365 tenant, you might need to export and import transport rules as well.

You can use a script such as you can find at https://gallery.technet.microsoft.com/exchange/Migrate-EOP-Settings-9d480325 to help with this task—either from on-premises to cloud or between cloud organizations.

Additional tools

In addition to the tools and scripts mentioned in this chapter, Microsoft provides planning, deployment, and troubleshooting tools to help you plan and complete your migration.

Remote Connectivity Analyzer

The Exchange Remote Connectivity Analyzer is a web-based tool that can be used to troubleshoot Autodiscover, free/busy, and mail flow issues and works with both Office 365 and Exchange on-premises deployments.

You can access the tool at https://testconnectivity.microsoft.com.

Exchange Server Deployment Assistant

The Exchange Deployment Assistant is a web-based tool you can use to determine which components you need to install and steps to follow to complete a hybrid migration. The Exchange Deployment Assistant is available from https://technet.microsoft.com/en-us/office/dn756393.

Summary

This chapter focused on preparing your on-premises Exchange environment for an Office 365 migration plan for how to transition services to Office 365. Not all services you use on-premises might have a direct translation to a service offered in Office 365, and you might need to update third-party applications or processes to adopt Office 365 fully.