The focus of this book has been mostly on compliance, configuration, and security. My editors suggested that I place this chapter at the beginning, but I wanted the migration information near the end. The reason is a simple one, I wanted to explain the why, and discuss how the security landscape is changing. You need this information to understand what you need to do to make sure you are configuring your office 365 correctly. However, some of you may not have decided to move to Office 365 and I wanted to give you a roadmap on how to move you company to Office 365. It may seem challenging, but the steps are easy. This chapter is your roadmap to Office 365.
The focus of this chapter is to provide you with guidance on how to migrate to Office 365. At the end of this chapter, you will have a fully functional Office 365 solution, and you can configure the security services using the techniques discussed in earlier chapters.
Purchasing Office 365
Office 365 plans are designed for different target markets and are organized into suites. Microsoft has set up suites for different styles of companies, based on business needs. In the early days, these suites had fixed configurations that were difficult to change. This has changed considerably. You can now mix different suites and Office 365 plans to reflect your business needs. For example, if you want to purchase a direct-dial number for Microsoft Teams (aka Skype for Business), you add the phone system (included in Office 365 E5) option to your subscription (or upgrade to a different suite that has a domestic calling option). Subscription upgrades and downgrades are common. It is recommended that you work with a CSP to handle these requests. Most cloud partners make the change for you as a courtesy if the cloud partner is added as a subscription advisor (or partner of record) on the account. When you decide to move your IT services—mail, phone, or local file storage—from your current supplier to Office 365, this is referred to as migration or onboarding.
There are two methods used to move to Office 365: cutover migration and federation migration. Each of these approaches has its pros and cons. In cutover migrations (you move mail to office 365 immediately, then bring over historic mail after email is on Office 365), the end user typically loses the Outlook cache of e-mail addresses (users typically call these contacts, but they are not contacts) and local tasks/categories on older versions of Office. Cutover migrations create a new Outlook profile, and the local address cache is not migrated. Federation migrations maintain the same user profile, and moving the mailbox to Office 365 requires an Exchange Server mailbox move (called a federated move). The method you use depends on your business requirements and how fast you want to move to Office 365. Cutover migration is fast: you “cut over” your mail services to Office 365 from the old service at a specific point in time. Federation is a stage migration, or a slower, nonintrusive migration. If you are on a POP or IMAP server (such as Google or One on One), you will be using a cutover migration. Typically, we see federation migrations when there is an on-premise Exchange Server (Exchange Server version 2010 or later) and the number of users is greater than 50. The reason for the 50-user limit is cost. The cost of moving 50 users is close to the cost of setting up a federation move, in other words, the cost break-even point. Fewer than 50 users, and it’s less expensive for the cutover. More than 50 users, a federation move is less expensive than a cutover migration.
Note
Cutover migrations are typically used when environments have fewer than 50 users and there is not an Exchange Server deployed. There are different ways to complete a federation move. The federation approach depends on the Exchange Server deployment. Keep in mind that if you have users on Exchange 2003 or earlier, you can only use a cutover migration. Exchange 2007 requires an Exchange Server 2013 deployment for federation moves. Exchange DAG deployments are exceptions to these recommendations.
Once you have made your selection to either federation or cutover, the next decision is how to integrate the user accounts into Office 365. If you have chosen a federation approach, you need to use the Azure Active Directory Connector (AD Connect) to link your on-site Windows Active Directory instance to Office 365. If you do not have an Active Directory instance, then you manually input the user accounts in Office 365 or use a third-party migration tool. There are multiple tools on the market for cutover migration. Two common tools are BitTitan’s MigrationWiz ( www.bittitan.com ) and the SkyKick migration tool ( www.skykick.com ). Each tool has different capabilities and features, so it is best that you look at the tools and decide which one makes sense for your migration.
The focus of this chapter is to provide a “how to” approach in moving your business to the cloud, using our 14-step migration process. We will highlight when you must make the decision for migration, and we have a special section for federation moves.
Note
Cutover migration is a manual process, and there is an impact on users during the migration process. Federation migration will move the users’ mailboxes with no impact to the users.
It no longer matters what type of Office 365 plan you have; all the Office 365 suites have Exchange mail services that can support migrations. The Office 365 Business version allows you to mix and match the subscription based on the roles in the organization. Individuals who have a requirement for more mail storage and document storage have enterprise plans. Those with fewer storage requirements have different plans with more limited storage requirements. If you have fewer than 300 users, you can use the small business plans intermixed with the enterprise plans. If you have more than 300 users, you can only use the enterprise subscription plans.
Note
Office 365 also has not-for-profit and education plans. These two special plans allow you to deploy enterprise subscriptions in large numbers at $0. Check with your cloud solution provider on the options. The $0 plans are equivalent to the $8 E1/E2 subscription.
Note
You must have control over your DNS server. If you do not have control over your DNS server, you cannot move to the cloud or the process will be very time-consuming.
Exchange
Teams (Skype for Business and Phone Systems Option)
SharePoint (Team Site)
OneDrive for Business
Compliance Management
Azure AD
Bing Places for Business
Configuring Office 365
How do you plan to deploy the clients?
How do you plan to move historical e-mail to Microsoft Online services?
- 1.
Purchase your Office 365 services.
- 2.
Validate your domains to Microsoft and add DNS records.
- 3.
Configure Teams (Skype for Business).
- 4.
Configure Yammer for Office 365 (optional).
- 5.
Link Office 365 into Azure Active Directory and EMS.
- 6.
Load users, install the Azure Active Directory Connector (AD Connect), and assign a license.
- 7.
Deploy the Hybrid Configuration Wizard for Exchange Federation (optional).
- 8.
Adjust the mail flow (coexistence).
- 9.
Manually install PowerShell (optional).
- 10.
Migrate e-mail.
- 11.
Finalize all DNS records.
- 12.
Configure mobile services (using EMS/Intune).
- 13.
Configure automated devices (copiers, scanners, fax servers).
- 14.
Clean up.
The first step in any process is one of commitment. With Office 365, you need to sign up for a trial subscription. If you are migrating to Office 365, any subscription will work that contains Exchange e-mail services, however any azure services will require a paid subscription. This chapter is about migrating or moving your e-mail services from one provider to Office 365.
Step 1: Purchase Your Office 365 Services
Step 2: Validate Your Domains to Microsoft and Add DNS Records
Enter the domain you want to use (GetOffice365security in this example) and click Next. If you do not have a domain, you can buy one from a third-party reseller. Office 365 examines your domain and provides you with an automated way to set up your domain. If Office 365 detects that the domain you want to verify is on GoDaddy, it prompts you to use an automatic configuration of the domain and DNS records.
Office 365 looks up your DNS information and recommends a record to enter for domain validation. In some cases, you may be prompted to enter a wizard. We recommend that you do not use the wizard, unless you are setting up a new Office 365 account and have no plans to migrate any e-mail into the Office 365 service.
Note
Use the wizards only if you plan to immediately use Office 365. The wizards configure your domain and move/point your mail records to Office 365. If your mail records are changed to Office 365, your existing mail on the third-party hosting service may be deleted. We use the wizards only if this is a new e-mail domain that has never been used.
After you have configured the domain for validation, if the domain does not verify, use MxToolbox ( www.mxtoolbox.com ) to verify that the TXT records have propagated. Once the TXT records show up in MxToolbox, you can validate the domain in Office 365. In Figure 7-17, we verified the record on MxToolbox. The purpose was to check whether the changed record in the DNS had replicated to the other World Wide Web DNS servers. These records also replicate to Office 365.
Once you have the record in the MxToolbox, then select “I’ll manage my own DNS” in Office 365. If the domain verifies correctly, you are provided with an acknowledgment that your domain is valid (see Figure 7-18). If the record does not verify, you will not be able to add the domain to Office 365.
Note
Usually adding the TXT records takes 5 to 10 minutes before the domain is verified. If the domain has not validated, check the values to make sure you have entered the information correctly. If the domain is validated in another Office 365 account, you cannot validate a second domain until the original domain name is removed.
Unless you are cutting over e-mail (at this instant), do not change your MX, TXT (SPF), or Autodiscover DNS records. These records are changed when you are ready to receive e-mail services on Office 365.
Configure all other DNS records, such as Teams (Skype for Business) and other CNAME records (only add theses records if the records are not being used).
In this example (see Figure 7-19), we do not have an existing service, so we will configure all the records for Office 365.
Note
If you cut over to Office 365 and change all the records, mail will flow through Office 365. If you have an existing Exchange server, you want to leave the Autodiscover, TXT (SPF), and the MX records pointing to the old mail service.
When we validated the domain earlier, we are letting Office 365 know how you are planning to use the domain that you just validated. Once you have added the DNS records, select verify to check the records for errors (see Figure 7-20). After you click Verify (on the bottom of the “Update DNS records” page), the changes you have made in the DNS registrar are validated. If there are errors, then correct the errors and click Verify again. Repeat the process until all checkmarks are green.
Note
You never want to transfer your DNS to a third party for hosting services. Always maintain the ownership separate from the hosting service. In this case, our domain DNS is at the Network Solutions registrar.
- CNAME (alias or canonical name) records. These records are used to provide standard names to other Microsoft web services for Office 365. We will be adding the following:
lyncdiscover
sip
msoid
enterpriseregistration
enterpriseenrollment
SRV (service record) records. These records specify information about available services. SRV records are used by Teams to coordinate the flow of information between Office 365 services.
At this point, you are completed with the setup as far as you can proceed, or you have completed adding all the records required for a cutover migration to Office 365. To return to the Office 365 admin center, click the nine-square grid (in the upper-left corner next to the Office 365 logo). The other DNS records that have an X next to them will be entered when you start the cutover migration for Office 365.
Note
Do not change your DNS MX, Autodiscover, or SPF-TXT records. When you change your MX records, you stop the mail flow to your existing e-mail server. If you change Autodiscover, the Outlook clients cease to work with your current e-mail server.
You should only have three red Xs on the MX, Autodiscover, and SPF-TXT records. All other records should have green check marks. If you have red Xs on records other than the three described, then correct those problems.
Note
The Office 365 automatic DNS wizard configures the DNS server and assumes that you are completing a cutover migration and you have loaded the user accounts into Office 365. If you are not planning to move to Office 365 at this instant, do not use the automatic configuration tool. Once you move the mail records to Office 365, mail will be received on Office 365, not your existing mail server.
The next step is to add users and assign licenses. We have found that it is better to complete the domain configuration (with the exception of changing the MX records) and add users after you have validated the domain.
Note
Unless you are setting up a new Office 365 account, it is best to set up users after you complete the configuration. If you choose to add users, follow the bulk user instructions. The wizard is designed for new users to 365, not for the migration of existing accounts.
Step 3: Configure Skype for Business (S4B ) for Teams
The public instant messaging interface allows you to communicate within your intranet with other Office 365 organizations that have federated with Office 365 and Live Messenger. Public IM connectivity is supported with Skype.
In the Teams & Skype control panel, click “Org-wide settings” and then “External access.” Enable “External Access,” and select “User can communicate with external Skype users.” This action enables these services. On is the recommended setting for both services. The default is off (disabled). After you have made the two selections, click Save.
Note
Office 365 users can talk to Skype users via a Skype handle (or Microsoft Live ID). To communicate with Skype users, Skype for Business must add Skype users as a “contact” in their Skype for Business client. If the Skype user is not listed as a contact, you cannot connect with them.
Step 4: (Optional) Configure Yammer Enterprise for Office 365
Step 5: Link Office 365 into Azure Active Directory and EMS
The underlining Microsoft cloud that holds all of this together is called Azure. Office 365 user management takes place in Azure. As the owner of the Office 365 organization, you need to manually link Azure to Office 365. This is not automatic, but it is key to managing the security in your business.
Why is this linking of EMS and Azure important? The answer is a simple one. We need to add Microsoft security services to our tenant (to prevent data breaches), and we need to have access to the Azure AD Connect (so we can link our on-premises Active Directory to Office 365). If you are not using the Azure AD Connect in your migration to Office 365, then you do not need to worry about this step. However, the Azure security services are extremely important to the health and well-being of your Office 365 tenant.
Before you set up the Azure link to Office 365, contact your Microsoft Partner and request a trial subscription for the Enterprise Mobility + Security suite (request one from https://www.kamind.com/support-center/ ) and request an Azure $100 consumption subscription account (consumption accounts are discussed later in this chapter).
Note
You need to contact a Microsoft Partner for a 25-user trial subscription to the Enterprise Mobility suite (see Figure 7-27).
Once you have received the trial subscription for the Enterprise Mobility suite, verify that you have the subscriptions assigned to your account. To verify the subscriptions, go to the admin center, click Billing, and then click Licenses (see Figure 7-27). Assign a license of EMS/E5 + Office 365/E3 to the admin account you are using to manage the subscription.
The Azure interface will launch into the Azure Active Directory interface. This is the interface where you will manage the user’s security and identity (discussed earlier). The Azure Active Directory admin center is used to manage the user account properties and capabilities. In our case, we need access to the Azure Active Directory center to download and configure the Azure Active Directory Connector to link our Office 365 services to on-premises Active Directory.
Note
If you are not using the on-premise Active Directory Connector, you will manually load the user accounts into Office 365. Loading users will be discussed in more detail in step 6.
Step 6: Load Users, Install Azure Active Directory Connector, and Assign Licenses
At this point, you are ready to load users, but before you start, you have a decision to make on the migration approach for loading users into Office 365. There are two ways to load users in Office 365. You can use Active Directory (via the Azure AD Connect tool) and Exchange Federation (hybrid) or manually bulk-load the user accounts from a spreadsheet. The direction you choose is based on your business needs. Azure Active Directory sync is required in hybrid migrations but is optional in cutover migrations. If you choose to use a hybrid migration, your data must be migrated using Exchange Federation or cutover migration, which uses Microsoft migration tools. Third-party tools such as MigrationWiz, User Activation, or DeploymentPro are used for cutover migration.
Note
Be careful which migration approach you choose. If there is an Exchange Server on-site and you use Azure AD Connect to load user accounts in Office 365, a user mailbox will not be created. This is because the Azure AD Connect tool detects that there is an on-site Exchange server and will not allow you to create two mailboxes, and it requires you to use the Microsoft migration tool.
You can use the Azure AD Connect in all migration approaches. The decision is based on three factors: whether you using Exchange Server, whether you have an Active Directory configuration, and whether the e-mail services are on Exchange Server. Answering these questions provides you with the different migration options described here:
On Exchange Server 2010 or later, you can use a federated move and will need to use the Azure AD Connect and using the Hybrid Configuration Wizard.
For Active Directory and no Exchange server federation, you must manually load the accounts, then connect Azure AD Connect to sync Office 365 user accounts.
For e-mail services not on Exchange Server, then you will use cutover migration and AD Connect to load accounts if you have an Active Directory.
Cutover migration
Federation migration (or hybrid)
Cutover Migration
Cutover migration is when the accounts have already been created on Office 365. The mail records (MX records) are “cut over” from the old mail servers and pointed to the new Office 365 mail servers. The end user loses their profile unless third-party migration tools are used. These third-party tools (such as BitTitan DeploymentPro) mitigate the issues associated with a new Outlook profile. Old e-mail either can be migrated before the cutover event (users have two mailboxes) or can be migrated after the cutover. If you are coming from an older Exchange 2003 server (or any POP/IMAP or other hosted Exchange service), you will use cutover migration.
- 1.
Load user accounts into Office 365.
- 2.
Deploy the Azure Active Directory Connector, sync passwords/users accounts, and perform a soft match (if you have an Active Directory).
- 3.
Use BitTitan’s migration tool to copy user e-mails to Office 365.
Federation Migration
If you have deployed Exchange Server in your organization (2010 or later), you want to seriously look at using a federation move. Federation moves are simple to do and require work to clean up your Active Directory, but they benefit your users. When a federation move takes place, the end user will receive a notification to close Outlook with the message the “Administrator has made a change.” Once the end user closes Outlook and reopens it, they have been moved to Office 365. This is a good user experience with little impact to the user.
- 1.
Deploy the Azure Active Directory Connector and sync passwords/users accounts.
- 2.
Deploy the federation Hybrid Configuration Wizard.
- 3.
Validate the Office 365 mail flow connector.
- 4.
Use the remote move mail migration wizard.
The process is straightforward, with minor issues in deployment. Typical deployment issues revolve around public folders and Exchange Server configuration and external spam filters. As an example, if you are running an Exchange 2007 data availability group (DAG), then the migration becomes complex. Another case is with a large number of public folders. Public folders can be migrated but are in a proxy model for Outlook only (and not OWA), until the public folders have been cut over to Office 365. Finally are the third-party spam filters. These always cause migration problems.
A hybridmigration is a combination of Active Directory synchronization and Exchange federation. A hybrid migration does not require Active Directory Federation Services (ADFS) and is composed of deploying Active Directory synchronization and Exchange Federation (linking the on-site Exchange Server to the cloud). The reason you would use a hybrid migration is to move users to Office 365 to maintain a user’s Outlook profile and make the migration 100 percent transparent to the user. This approach allows you to use a staged migration. The hybrid model leverages the Exchange server mailbox move function. When an Exchange administrator implements a mailbox move, all the user sees is a message that the user needs to log out and log back in to Outlook when the mailbox move is completed.
Cutover or Hybrid: Which One?
At this point, you need to decide. If you choose to use cutover as a migration option and want to use your Active Directory, there is a process that you need to follow in moving users to Office 365 (described shortly). If you want to use hybrid migration (and are running Exchange 2007), you need to deploy Exchange 2013/2016 and use Exchange 2013/2016 servers to move mailboxes to Office 365.
Once you have decided on the migration direction (cutover or hybrid), the work follows the process outlined earlier. There are no technical limits on the number of users you can deploy. If you are using cutover, there is no partial deployment groups (or test groups). If you want a test group, use a federation move.
If you are using a federation move, you can deploy in groups based on departments or other criteria. The deployment group size is a function of the capabilities of the support organization. Technically, you should not have any additional support calls because you had a good business process for deployment. However, users will call you anyway because they do not like change, so your support team will need to manage the change.
There are Three Methods to Load Users
Add each user (see the “Onboarding Users” section later in this chapter). This method is appropriate for a few users or a test group.
Bulk-add users using a specially formatted CSV spreadsheet with the user information. Use the Bulk Import option to load the information into Office 365.
Enable Azure Active Directory synchronized users for access to Office 365.
Pick your method to load users into Office 365. Once you have selected your method (manual or using directory synchronization), you are ready to begin moving user data to Office 365. If you choose directory synchronization, you are restricted to using Microsoft migration tools (if you have an Exchange server in your Active Directory). After you have selected your user-loading approach, then you can begin the mail migration process.
Cutover migration may need to have the user accounts reloaded before the Azure Active Directory Connector is installed. On cutover migrations, the on-premise Active Directory instance may not be cleaned from the old Exchange Server instance. If this is the case, you will need to manually load the user account to Office 365 and then perform a soft match with AD Connect.
Onboarding Users (Cutover Migration Only)
Bulk-Load Users Through Azure AD Connect
AD Connect links your on-premises Active Directory to Office 365. This allows you to import existing e-mail addresses, contacts, and distribution lists into Office 365 through a process called directory synchronization . When you install AD Connect, you select the directory from Active Directory to sync with Office 365. This is a simple process. If the user AD object is in the sync directory, it is replicated to Office 365. You need to be careful when you use AD Connect. If you have an on-premises Exchange Server instance and you are planning not to use a federation move and want to link AD, load the users into Office 365 (bulk import) and then set up AD Connect and soft match the Office 365 user accounts to the Active Directory. This will allow you to use a tool like the migration wizard and move users to Office 365 as a cutover migration.
Manually Bulk-Load Users
There are two ways to manually load users: using the Office 365 graphical user interface or using the bulk-load process. The GUI is great for maintenance and a small number of user accounts, but it is not an effective tool for loading many user accounts. The process that we use is to bulk-add users.
Log in as an administrator at http://portal.office.com and then click Active Users. Then click More and Import multiple users. This will launch the import wizard (see Figure 7-33). Follow the import process to load the users from the CSV file to Office 365.
The first step is to build and then select the CSV file with the appropriate users to be added. Download a blank CSV file to get the format. You can open this file in Excel (be sure to save it as a CSV file, without extra lines or columns) or edit it with the text editor.
Installing the Azure AD Connect
If you are running an Azure Active Directory and you want to link the user account into Office 365 (regardless if you are running a hybrid or cutover migration), you will need to follow the steps to install the AD Connect software.
If you have an Active Directory environment (log in to a Windows server) and you are not running a small business server, using Azure AD Connect to load users into Office 365 is simple. It gives you a single-password login to Office 365. The caveat on this is the Exchange configuration. If you cannot use Exchange Federation as a method to move mailboxes to Office 365, you need to manually load user accounts into Office 365 before you install the Azure Active Directory Connect tool.
An Office 365 global admin account (like [email protected])
A local AD enterprise admin account (like [email protected])
A Windows Server 2012R2 or a later server that is domain joined
Before you begin the configuration of the Active Directory integration, please verify that you have created these user accounts and have a server available to deploy the Active Directory integration tool.
Note
The Office 365 Active Directory synchronization tool (DirSync) has been replaced with Azure Active Directory Connect (AD Connect). Microsoft merged the different versions of the directory synchronization tool into one. The Azure AD Connect tool is downloaded from Azure. If you plan to use Azure Active Directory Connect, you need to complete step 3 and integrate Office 365 into Azure. This integration requires that you have purchased a license.
- 1.
Set the UPN to the routable Internet name in the on-premises Active Directory. (In your domain controller, start Active Directory Domains and Trust, select Properties, and enter an alternate UPN).
- 2.
Run the IdFix tool to correct any issues with the on-site Active Directory. (Download IdFix DirSync Error Remediation Tool from www.microsoft.com .)
Once you have completed the installation of the Azure AD Connect service, your on-site user accounts will appear in Office 365 (as synced users) and in the Azure Active Directory on the Users and Groups tab.
Note
Once you’ve installed AD Connect, those accounts can be managed from the on-premise Active Directory or Azure Active Directory. A password reset requires the Azure AD Write Back feature. This feature is available if you have deployed either Azure Premium or Enterprise Mobility + Security (EMS).
License Assignment
If you selected Active Directory Sync, you do not need to assign licenses until you begin the migration. Directory-synchronized objects from the on-site Active Directory appear as disabled users in Office 365, and no mailbox is created. Once the user object is created in Office 365, you can manually assign licenses or bulk-assign them with PowerShell. If you selected manual loading, you need to purchase licenses to create the mailbox for the user. It is not possible to load a disabled user in Office 365.
If you do not see a mailbox created from an Active Directory Synced user (after you assigned a license), this is because Active Directory thinks that there is an Exchange Server instance installed in your AD. If this happens and there is no Exchange Server instance, you need stop syncing and delete the user accounts from Office 365 (and the delete all users in the deleted users folder) using PowerShell. Once this is completed, create the user in Office 365, assign a license, and then resync the user account for the on-premises AD. The AD Connect tool should soft match the user and set the user as a synced user.
Note
If you’re planning to allow passwords again (which you should do), you must assign an Enterprise Mobility + Security license to the user account.
Step 7: (Optional) Deploy the Hybrid Configuration Wizard for Exchange Federation for staged migrations
The simplest way to migrate to Office 365 is to use the Exchange Server federation wizard. This wizard can be installed on any server. What this wizard does is to create the necessary connections to migrate to Office 365 using your existing Exchange Server instance. The federation wizard works only with Exchange Server 2010 or later. If you have a federation migration, make sure you look at the Microsoft Exchange Assistant planning guide. This guide will walk you through the process of setting up an exchange server for migration (see https://docs.microsoft.com/en-us/exchange/exchange-deployment-assistant ). The federation Hybrid Configuration Wizard completes the following steps for deployment:
- 1.
Detects the Exchange Server installation
- 2.
Links the Office 365 credentials and the AD credentials
- 3.
Validates the credentials and DNS (using federation token)
- 4.
Configures the federation organization and enables the MRS service
- 5.
Builds the send and receive connectors for Exchange and Office 365
- 6.
Validates the on-premises and Office 365 configurations
Once you have completed the download, start the wizard and begin the installation process (see Figure 7-38). The wizard will find out where the Exchange Server instance is located and will automatically configure all footed services. That is why it is important that you are logging into the systems with the correct credentials. We recommend you use the credentials for the Active Directory Connector installation. The dynamic account will be modified with the correct security extensions to make this work.
The Hybrid Configuration Wizard will need the Office 365 global admin account (use the same account that was used for the Azure Active Directory Connector, as well as the account for access to the Exchange Server instance (such as the adminsycn account). During the process you will be required to provide a TXT record for the federation token to validate the hybrid configuration for Office 365. The federation token is a GUID that needs to be inserted as the primary domain DNS as a TXT attribute. This TXT attribute is read by Office 365 and used to encrypt the data in transit.
- 1.
Validate the Office 365 send connector to the on-site Exchange Server instance.
- 2.
Add the IP address for the on-site Exchange Server instance to bypass the Office 365 spam filter.
- 3.
Adjust the Office 365 Exchange retention tags.
- 4.
Adjust the mail flow (set Office 365 as the internal relay).
Connector Validation
Bypass the Spam Filter
- 1.
Select “mail flow” and then “rules” and then select “Bypass spam filtering” from the drop-down.
- 2.
Enter the IP address for the new rule (do not use domain names).
- 3.
Save the rule.
- 4.
Set the rule’s priority to 0.
At this point you are almost ready to move the mail. The final step is the adjustment of the mail flow to allow an internal relay to the other e-mail accounts that have not migrated to Office 365.
Step 8: Adjust the Mail Flow (Coexistence)
There have been many different strategies on mail flow. Looking at the Internet rules, you can have only one authoritative domain and many different relays. If you are completing a hybrid migration (or a test group migration with forwarders), you will need to adjust the Office 365 domain connector to allow mail to flow from Office 365 to the authoritative domain until you cut over to Office 65.
- 1.
Select Office 365 as an admin.
- 2.
Select “admin centers.”
- 3.
Select Exchange.
- 4.
Select “mail flow” and then select “accepted domains.”
Select the domain and change the record to “Internal relay domain.” The domain type is set to “Internal relay” until all the users have been migrated. When the user migration has been completed, the domain changes to Hosted, and the MX records change to point to Office 365.
The changes that you make for internal relay (see Figure 7-41) are also the changes that you would need if you were running a coexistence strategy with Office 365 and a third-party mail service. Test groups and coexistence are rarely used unless you have a massive migration from Google services to Office 365. I have used this strategy on many occasions when migrating user accounts to Office 365. The strategy is to allow e-mail to flow to Office 365 and Google so users can move their services over to Office 365. In this case, Google is the primary tool for MX records; it is set to be Authoritative, and Office 365 is set to internal relay. Once the e-mail accounts have been moved, then the mail records are pointed to Office 365, and the Google service is shut down.
Note
If you have an on-site Exchange server and you want to create a test group, you will need to manually configure the desktop clients to bypass the on-site Exchange server. It is not clean and requires you to edit the registry. Test groups will not work in Office 2016.
Internal Relay Mail Flow (and Test Groups)
E-mail that is sent to one of these new Office 365 e-mail accounts from outside Office 365 or from other Office 365 tenants will not be received until your MX records are configured and verified by Office 365.
Any e-mail sent from one of these new accounts will be routed to your other new accounts. (E-mail to outside addresses will route as expected.)
Only load users who are using Office 365 (during test or evaluation).
If you are using both the Office 365 service and an on-site Exchange server, you need to set your e-mail domain type to Internal. You should have e-mail for these Office 365 users forwarded from the on-site Exchange Server to the Office 365 e-mail accounts using the “long” address of user@<domain>.onmicrosoft.com.
Coexistence E-mail Flow
When you initially purchase Office 365, one of the items created is the subdomain yourdomain.onmicrosoft.com. This is a valid e-mail domain and is the “long” e-mail address. You can send e-mail to <user>@<yourdomain.onmicrosoft.com>, and your e-mail will be delivered into your e-mail box. When you validate a domain and add a user account, the user account is created with two e-mail addresses: <user>@<yourdomain.onmicrosoft.com> and <user>@<yourdomain.com.
E-mail is forwarded from the on-premise domain or other hosted e-mail address to your Office 365 “long” address (i.e., @yourdomain.onmicrosoft.com).
When e-mail is sent from inside Office 365, it looks to see whether the e-mail needs to be delivered to a migrated user (i.e., @yourdomain.com). If not, the e-mail is forwarded to the real e-mail domain (via the DNS MX records).
Note
After you have moved all users to Office 365 and changed the DNS to the MX records, point to Office 365 and change the domain from Internal Relay to Authoritative. At this point, your e-mail is 100 percent on Office 365.
Once you have moved all the e-mail addresses to Office 365, the MX records are changed to point to Office 365. When the MX records are changed, coexistence mode is completed, and you have implemented your cutover migration, or you have completed the hybrid or a cutover migration. That is all that is really needed to move users to Office 365 for mail flow.
Note
Exchange Server instances may be problematic. You cannot ignore these instances or turn the power off. At the bare minimum, you will need to add a mail forwarder for each user to send mail to the long address of <user>@<domain>.onmicrosoft.com. The preferred way is to convert the users to a mail-enabled user or delete the user mailboxes from the Exchange server and uninstall the Exchange server. If you are running Small Business Server (SBSS, then your only option is a forwarder).
Test Groups (or Simple Coexistence)
This is an iterative coexistence migration. Cutover migration will happen at the point that all users are moved to the cloud. Simple coexistence is used to train IT staff and to build experience using Office 365. In simple coexistence, a “test group” of users is migrated to Office 365, and those users who migrate do not have access to the Global Address list and shared calendars of the other users who have not migrated. E-mail for converted users is forwarded from the on-premises or hosted e-mail server to their “long” e-mail address (discussed shortly) in the cloud. The iterative approach requires that only a portion of the users are loaded in step 6 and that the domain type is set to Internal Relay.
Note
Do not use simple coexistence unless you have no other option. There is no sharing of calendars, contacts, or other information with users who are not on Office 365. The users who are migrated are an island. It is much better to use a cutover migration. Everything just works better.
Step 9: (Optional) Manually Install PowerShell
Typically, we recommend that if your organization has more than 20 accounts, you may find it more convenient to use PowerShell. This is a command interface in Office 365. In Chapter 8, we offer additional troubleshooting steps and configuration options (such as shared mailboxes) using PowerShell. The account that you will use for PowerShell management is the global administrator user account. Users without global administrative privileges will not be able to use this feature.
Once you have Office 365 PowerShell libraries installed, you can access the PowerShell admin center on https://docs.microsoft.com and download different PowerShell modules for Office 365 located at https://docs.microsoft.com/en-us/powershell .
You have completed the base PowerShell setup; now use the preceding command to validate the installation. If the command does not work, you have installed the PowerShell GUI incorrectly, there is a lack of permissions, or you have not installed the desktop connector for Office 365. Using PowerShell requires administrative privileges.
Step 10: Migrate E-mail
We have completed a lot of work to lay the groundwork for migrating e-mail to Office 365. At this point, we are using either a cutover migration or a hybrid migration. Earlier, in step 6, our method of loading users defines the toolset you should use for copying e-mail to Office 365 (this moving of e-mail is called migration). Depending on the method you selected, you can use Microsoft tools or external tools. The key decision factor in the toolset you use is based on Azure Active Directory Connect (AAD Sync Connect) integration. If you use AAD Sync Connect and there is an on-premises Exchange Server, you are required to use Microsoft migration tools or Exchange Federation. There are cases where you can use AAD Sync Connect (with an on-site Exchange server) and external tools, but we recommend you consult a Microsoft Partner if you use this approach.
E-mail Migration
E-mail migration is nothing more than copying the e-mail from the old mail server to the new mail server. The mail is not destroyed in the process. You are just copying the e-mail messages (and other mailbox information) to Office 365. There are different approaches to moving the e-mail to Office 365 (see Figure 7-45). Depending upon the approach you are using for migration, you may choose to cut over the mail records before you move e-mail or you may move e-mail and then cut over records. The decision is based more on the source of the mail server and the size of the organization. There is no hard-and-fast rule on the migration of e-mail, with one exception: if you are running some type of coexistence (such as a stage migration), then place a mail forwarder (to the “long” name) in the older mail system before you start the migration. Once the MX records are moved, there is no need to add a forwarder.
Note
Our policy on e-mail migration is to move at least the first 200 e-mail messages for each user (one to two weeks’ worth), along with the contacts, calendars, and folder structure, into the new mailbox. The older e-mails can come later. We use MigrationWiz to move historical e-mail as our first choice.
Different Migration Methods
Description | Pros | Cons |
---|---|---|
PST migration | Simple | E-mail addresses are not complete. Requires upload to hosted service or execution at a workstation. Network bandwidth (copy up, and copy down). |
MigrationWiz | Simple | Costs $12 per mailbox to migrate. |
Exchange 2007/2010/2013 | License | Requires Azure Active Directory Connect and Exchange Federation. Exchange 2007 requires adding Exchange Server 2013 for a remote mailbox move. |
If you are using a federation mail move (see more later in this chapter), you can use the wizard to pull the mailbox from the on-premises server to Office 365. This also allows you an easy way to preload users (sync them) to Office 365 so you can have a gradual cut over.
Note
If you want to use MigrationWiz ( www.bittitan.com ) in your migration, please see the MigrationWiz section later in this chapter. Typically, we use MigrationWiz and DeploymentPro for our cutover migrations.
Exchange Server: Mailbox Changes
When you use the Microsoft migration tools, what the Microsoft tools do at the end of the data sync step is to convert the mailbox from an Exchange mailbox to mail-enabled users. What is really happening is that the Exchange mailbox is converted to a contact, and the existing mailbox is placed in a disabled state. When e-mail is received by the on-premise Exchange Server, the server looks up the contact and sends the e-mail to the destination. The contact for the user of the on-site Exchange Server contains the Office 365 long address (user@company.onmicrosoft.com).
If you are using a third-party migration tool such as MigrationWiz, you need to manually convert the Exchange mailboxes to mail-enabled users. Microsoft Support has published a set of conversion scripts for Exchange Server 2007 and 2010. These scripts convert a migrated Exchange server mailbox to mail-enabled users. If you are running SBS server and decide to keep the SBS server around, you will need to add a mail forwarder to the Exchange server.
Note
If you have used a cutover migration before you install clients and you have an on-premise Exchange server, you need to remove the Exchange service control point (e.g., the CAS Autodiscover record from Exchange Server 2007, 2010, and 2013 by running the following commands. They do the following: (1) retrieve the CAS server identity <name> and (2) set the CAS server Autodiscover record to $NULL.
(1) Get-ClientAccessServer
(2) Set-ClientAccessServer -Identity "<name>" – AutoDiscoverServiceInternalUri $NULL
In some cases, you may also need to remove the Autodiscover record from the Exchange server service control point. Run the command Get-OutlookProvider (to retrieve the Autodiscovery records and set certprincipalName to $null) using the command set-OutlookProvider.
After you have run these commands, the Outlook clients use the DNS Autodiscover records to look up the Office 365 Exchange Server. If you do not remove the Exchange Server CAS role, the Outlook client will bypass the Autodiscover record lookup and connect to the old Exchange Server instance.
Step 11: Finalize All DNS records
At this point, we are done with the mail migrations and are ready to set the mail flow to Office 365. If you chose to cut over all users at one time (cutover migration), the Office 365 Global Address List (GAL) contains all the new user accounts. This limited GAL also applies to sharing calendars and free-busy status. If you choose to move users in groups (simple coexistence), the GAL will only contain those users who have been moved.
Cutover migration: All users are loaded, MX and Autodiscover records are changed, and Office 365 receives all e-mail.
Test group (nonhybrid): Some users are loaded. E-mail is forwarded from on-premises servers to Office 365 (temporary). This is not recommended.
Hybrid coexistence: Exchange Server and Office 365 operate in tandem.
The hybrid coexistence migration is a complex migration and is beyond the scope of the chapter. Earlier In step 7, I showed you were you would add the hybrid connector for a federation migration. This is detailed in the Microsoft Exchange Assistant planning guide (see https://docs.microsoft.com/en-us/exchange/exchange-deployment-assistant ). Once you have moved the mail to Office 365, the process of moving MX record (and TXT and autodiscover) to Office 365 in a federation move is the same, you move the records at the end of the migration. If you are using Public folders, you move the public folders at the end of the migration after all users have been moved. (public folder migration is beyond the scope of this chapter).
Cutover Migration and Hybrid
At this point all users mailboxes have been moved to Office 365. If you have public folders, you have move them as well, and no other records are left. This is also a 100 percent conversion, and you are ready to change the final MX records and cutover to Office 365. Cutover means that you have loaded up the users and you point the e-mail records to Office 365 servers. All historical e-mail is brought over in a post-migration process.
Note
If you have completed loading the users, you can change the DNS records to point to Office 365 services. To determine records that need to change, log in to Office 365 as an administrator, select the domain, and run the Find and Fix Issues operation to show the broken DNS records. Make the changes and you are done with your migration.
Step 12: Configure the Desktop and Mobile Devices
There are different philosophies on when to configure these services. However, unless you want to manually configure these services, you cannot add them until you have changed the MX and Autodiscover records. Desktop services (Outlook) use the Autodiscover record and the Active Directory service control point record to find the exchange server. The mobile device (on older versions of IOS and android software), may need to have the account deleted, then reentered. On the new devices, the configuration is automatic. The newer mobile devices will have a delay, then resync mailbox to Office 365.
Configure Desktop Services
Mobile Device Configuration
Step 13: Configure the External Devices
The sending device must have a domain name that is verified in the Office 365 tenant.
Sending “on behalf” of someone means you need to create a dedicated “user” in Office 365 and your SMTP relay device will need to log in as that user and have permission to send on your behalf. You must grant send as to this user to access all internal mailboxes. This is completed in the exchange admin center (see Chapter 8)
Your static IP address of the on-premise firewall (where the e-mail is being relayed from) must be registered as a connector in Office 365.
The external IP address that is sending to Office 365 (acting as your relay) must be added as a transport rule with the “bypass” spam filter option.
Step 14: Clean Up
The cleanup operation depends on the type of mail system you have migrated to Office 365. If you are using a hosted e-mail system or a non-Exchange e-mail system, you need to contact the software supplier to determine whether there is any special process needed to remove the third-party mail server. Unless the e-mail server is integrated into Microsoft local Active Directory, there is usually no shutdown sequence. The server must be removed from Active Directory.
An Exchange Server must be decommissioned to remove it from your local environment. To remove the Exchange Server, you simply uninstall the server. It seems simple, but to uninstall the server, you need to remove all users and delete the public folders and the attached mail database. To remove an Exchange Server, run the setup wizard and remove the services. This is an iterative process. The wizard walks you through the steps and reboots the server until the Exchange Server instance is uninstalled.
Note
Do not power off the Exchange Server instance once you have migrated to Office 365. Exchange Server must be uninstalled from the Exchange Server setup media. You must uninstall the Exchange Server software.
Final Check List
- 1.
If you have a desktop version of Office 2010/2013/2016 or 2019, upgrade to the Office 365 subscription version.
- 2.
- 3.
Verify that your Office 365 domain is set to Authoritative (see Figure 7-41) and is not shared for e-mail. (This will be set only if you have run a test group.)
- 4.
Verify that you have placed a local DNS record in your on-premises DNS server. You will need to add an Autodiscover cname to your internal DNS that points to autodiscover.outlook.com.
- 5.If you have an on-premise Exchange Server instance and you have migrated to Office 365, set the Autodiscover record to $NULL with the following command. (Note that once it’s set, local clients cannot autodiscover the local Exchange Server instance.)Set-ClientAccessServer -Identity "<name>" –AutoDiscoverServiceInternalUri $NULL
- 6.Extend the 15-day delete hold time to a 30-day delete hold time. Run the PowerShell command.
- a.
Extend the 30-day delete for a mailbox:
Set-mailbox [email protected] –retaindeleteditemsfor 30
- b.
Extend the 30-day delete for the organization:
Get-mailbox | Set-mailbox –retaindeleteditemsfor 30
- a.
- 7.Enable the audit logs on all users’ mailboxes. The default logs are kept for 30 days, and this can be extended to multiple years.#Enable Audit LoggingGet-Mailbox -ResultSize Unlimited -Filter {RecipientTypeDetails -eq "UserMailbox" -or RecipientTypeDetails -eq "SharedMailbox" -or RecipientTypeDetails -eq "RoomMailbox" -or RecipientTypeDetails -eq "DiscoveryMailbox"}| Set-Mailbox -AuditEnabled $true -AuditLogAgeLimit 365 -AuditOwner Create,HardDelete,MailboxLogin,MoveToDeletedItems,SoftDelete,Update#Check StatusGet-Mailbox -ResultSize Unlimited | Select Name, UserPrincipalName, AuditEnabled, AuditLogAgeLimit | Out-Gridview
- 8.
Log into the Office 365 admin center, and select the Security & Compliance Center. Under Search & Investigation, select “audit log search” and “enable audit log recording”.
- 9.
The default retention policies are not enabled until the archive is enabled. If you enable the archive on a user mailbox, the retention polices begin to execute. For example, the default retention policy is two years. When the retention policy executes, e-mail is deleted. If you do not want your e-mail to be deleted or moved to an archive, remove the tag in the Exchange admin center, under “Compliance Management” and “Retention tags”.
- 10.
Remove any other retention tags you do not want to use in the retention policy.
- 11.
Verify that you have enabled Yammer on your subscription. To enable Yammer, expand the admin center, and then select Yammer. The service should auto-activate and show a green check mark
- 12.
Log in to the OneDrive admin center and set the retention to 1,530 days for deleted files.
- 13.
In the OneDrive administration center, reduce the OneDrive sharing (in the OneDrive admin center) to “Existing External users” to control sharing until you understand the sharing features.
Test Group or Staged Migration
In the early cloud days, there was a lot of work with test groups to train the IT staff. Now test groups are not really used except in unique situations. There are two ways to use test groups: doing a hybrid migration or deploying a few test mailboxes to test processes and then discarding the test group when you move to production. Test groups are nothing more than a stage migration. Stage migrations take a lot of work and should be used only for a limited time and for a small number of users. When we discuss test groups, we mean we are using those users to test our deployment processes. A test group is nothing more than placing a group of users on a different mail server that is separate from the existing organization. A test group does not have access to a common calendar or a common address list (unless a hybrid deployment). It is for these reasons that you want to use test groups for a limited time and with a definite set of objectives. A stage migration is nothing more than a test group.
Note
If the user accounts are POP or IMAP, stage migration is a viable option because there are no common shared resources (like calendars and address lists).
Outlook Client Autodiscover Record Changes
If you are using a test group with an on-premise Exchange Server instance (no hybrid, no Exchange Federation), you will encounter two problems: Autodiscover (for Outlook clients) and the presence of Exchange Server in Active Directory. The workarounds are manual, and you need to edit the registry to enable the clients to find the Office 365 mail server. Once you have deployed, you need to remove these “enhancements” to eliminate a future support problem when using Office 365. If you choose to manually configure Outlook, you still need to make these changes since Outlook will verify the connection via Autodiscover every time it is started.
- 1.Add the Autodiscover record in the host file, located at <drive:>windows/systems32/drivers/etc.
- a.
Ping autodiscover.outlook.com.
- b.
Add the Autodiscover record with the address discovered earlier.
- c.
Open a command prompt and enter ping Autodiscover. This should display the IP address you just entered.
- a.
- 2.
Add the two Autodiscover records: Autodiscover and Autodiscover.<yourdomain.com>.
- 3.Add the registry fixes to ignore the Exchange Server service control point. The registry entries required to be modified for the clients are listed shortly (see https://support.microsoft.com/en-us/kb/2612922 ).
- a.
Navigate to the following registry key that corresponds to your version of Office (12.0 is Office 2007; 15.0 is Office 2013):
HKEY_CURRENT_USERSoftwareMicrosoftOffice12.0OutlookAutoDiscover
- b.
Set the following registry names and values. Type in the names that are in the quotes when you create the registry entries:
"PreferLocalXML"=dword:1"ExcludeHttpRedirect"=dword:0"ExcludeHttpsAutodiscoverDomain"=dword:1"ExcludeHttpsRootDomain"=dword:1"ExcludeScpLookup"=dword:1"ExcludeSrvLookup"=dword:1"ExcludeSrvRecord"=dword:1
- a.
- 4.
In the Windows 10 control panel, select the Mail application, then configure the Outlook profile to prompt for a profile.
- 5.
If there is an existing Exchange Server instance, you need to manually configure the Outlook client. Outlook clients (Mac and PCs) require an Autodiscover record. Office 2016 and later cannot be manually configured.
- 6.
Start the Outlook client and create a new profile. In some cases, the client may not start up correctly the first time. Close Outlook and start again.
DNS Troubleshooting
One of the problems associated with the DNS records is figuring out who is managing them. In some cases, this may be a web developer who is no longer in business. You may also have it registered with an e-mail address that you no longer use (or can remember). If you cannot access the DNS server, how do you find the records?
Onboarding E-mail
After you have loaded the user account to Office 365, you need to copy the e-mail from the current mail servers to Office 365. There are different ways to do this, depending on the method you used for loading users. As an example, if you have an on-premises Exchange Server instance and you enabled DirSync, your only option is to use the Microsoft migration tools. If you do not have an existing Exchange Server instance, you can use different migration tools to move mail to Office 365. The three methods discussed here are PST migration, third-party tool migration, and the Microsoft Office 365 migration tools.
PST Mail Migration to Office 365
PST migration consists of importing the existing PST files into your Office 365 mailbox. A PST export/import is performed at each user’s workstation, with data from their version of Outlook. PST migrations are the simplest but should be used as a last resort. When you migrate PST data, you need to export the old mailbox at the root and import the data into Office 365 at the root. If the PST data already exists, then import the data at the level that you want to see the data in Office 365.
Note
If you start a PST migration, you need to complete it. There is no real error checking on data imports or duplicates. If you stop and restart a PST migration, you have duplicate data.
Typical user data in a PST contains all the information in the mailbox, including e-mails, folders and subfolders, calendars, and contacts. To install the calendar and contacts into Office 365, you can either manually copy them over to Office 365 (drag and drop) or overlay the Office 365 calendar and contact information using export and import data commands, specifying the root inbox. Next we cover the two options for this command.
Export Outlook 2010, 2013, or 2016 Mailbox Information
- 1.
Start Outlook (Outlook 2010 or 2013/2016). Use your on-premises Exchange Server Outlook profile (probably your default profile) for the export of PST mailbox information (see Figure 7-52).
- 2.
In Outlook 2013/2016, click File ➤ Open ➤ Import (this includes file export as well).
- 3.
Select “Export to a file” and then Outlook Data File (.pst), as shown in Figure 7-53.
- 4.
Select the mail location to export (normally, you want to select the very top item, the mailbox account) and the export options. Enter a filename and select “Replace duplicates with items exported” (see Figure 7-54).
- 5.
Once you have exported the documents, write down the location where the PST file is located. The next step is to import the PST file.
Import Outlook 2010, 2013, or 2016 Mailbox Information
- 1.
Exit Outlook.
- 2.
Sign in to the user’s Office 365 account.
- 3.
Start Outlook either with a new profile or with the user’s Office 365 profile. (We normally call the new profile O365 to distinguish it.)
- 4.
In Outlook 2010 (or 2013/2016), click File ➤ Open ➤ Import.
- 5.
Select Import from another program or file.
- 6.
Select Outlook Data File (.pst), or it may be Personal Folder File (.pst), as shown in Figure 7-55.
- 7.
Browse to the file to be imported (the one you exported earlier). Select “Do not import duplicates.” You want to import the PST folder into the same structure as the export. As an example, if you export the PST file as the root mailbox, you need to import it as a root mailbox (shown in Figure 7-56). You may import the e-mail account to a lower level (for example, if you are importing several e-mail accounts into one e-mail account).
The import process uploads the Outlook PST data to the Microsoft Office 365 Exchange Server. Your data will then be replicated down to your Outlook 2010. It is best that you import data using a high-speed data link since the data will travel twice: up to Office 365 and back down to your Outlook local cache.
Migrating E-mail with BitTitan’s MigrationWiz
There are three different migration tools that BitTitan offers: MigrationWiz, DeploymentPro, and User Activation. MigrationWiz is used to move mailboxes to/from Office 365. DeploymentPro is a tool configures the user’s Outlook (configures the desktop, the move task, the Outlook cache, etc.) to a new Outlook profile linked to Office 365. User Activation is an end-user tool that integrates MigrationWiz and DeploymentPro for a hands-off migration to Office 365. The tool that you use depends on the migration approach. If you are looking for an automated migration and you have fewer than 25 users, then user activation is the best way to proceed. If you are using any type of SBS server (that has a local Exchange Server), you need to use either User Activation or DeploymentPro/MigrationWiz. These tools patch around the SBS service control point on the desktop. Keep in mind that any time there is an Exchange Server instance, you need to uninstall Exchange Server at the end of the migration.
Note
There are two approaches to using BitTitan’s tools: using a manual migration approach via MigrationWiz and DeploymentPro or using the User Activation automated tool. If you are migrating a small number of mailboxes, using MigrationWiz or User Activation saves time on the migration. The approach that we are describing here is a manual approach using MigrationWiz.
The migration approach we use is a combination of MigrationWiz and DeploymentPro. If there is an SBS server, we always use DeploymentPro. DeploymentPro configures the desktop and moves the SBS Exchange Server to the side. When we migrate larger accounts of more than 200 or 400 users, it depends on the migration strategy. In some cases, we use a combination of tools, and in others, we use Exchange Federation; it just depends on what you are trying to achieve.
Note
If you are using MigrationWiz with DeploymentPro and you want to upgrade the desktop before you install clients, you need to remove the service control point (e.g., CAS Autodiscover record from the Exchange Server (2007 and 2010) by running the following commands: (1) to retrieve the CAS server identity <name> and (2) to set the CAS server Autodiscover record to $NULL.
(1) Get-ClientAccessServer
(2) Set-ClientAccessServer -Identity "<name>" –AutoDiscoverServiceInternalUri $NULL
After you have run these commands, the Outlook clients use the DNS Autodiscover records to look up the Office 365 Exchange Server instance.
Using MigrationWiz
- 1.
Log in to www.bittian.com and create a migration account. Confirm your account and select MigrationWiz (see Figure 7-58).
- 2.
Verify that Exchange Server 2007/2010 is set to basic authentication.
- 3.
Configure the permission for the admin user mailbox on Exchange Server.
- 4.
Build the migration project and enter the admin credentials.
- 5.
Load the user for migration.
- 6.
Purchase licenses for migration.
- 7.
(Optional) Select DeploymentPro for desktop configuration changes and send out the Configuration tool.
- 8.
Start the mailbox migration.
- 9.
Retry migration errors.
- 10.
If you are using DeploymentPro, select “cutover” (either manual or scheduled) and cut over the MX records. The migration is completed.
Using BitTitan tools is a simple process to move mail from an existing service to Office 365 or to use the upload tool to configure and upload the PSTs. Gone are the days where you must import a PST directly into Office 365 (yes, you can do that, and we still do for IMAP migration to pick up calendars and contacts). But in general, if you use the automated tools, life is simpler.
Note
If you are uploading an old PST, it is best to attach the PST to Outlook and then export and create a new PST from the old PST. This will correct the errors in the PST.
Microsoft Mail Migration
- 1.
Select Office 365 in the admin center, then select Exchange Admin center.
- 2.
Select recipients, then select migration.
- 3.
Select the "+" drop down to see the migration types
- 4.
You will see the screen shown in Figure 7-59. Select Migrate to Exchange Online. When a mailbox is migrated, the on-premises mailbox is converted to a mail-enabled unit.
Your options with the Office 365 tool are limited to Exchange Server 2007 and 2010 and IMAP. POP mail is problematic, since POP e-mail has just e-mail and no folders. Typically, if you are using POP mail, you will most likely use a PST export/import because the POP e-mail is stored locally. We always recommend that you use MigrationWiz as the first option. It is simpler to use. In this example, we are going to use IMAP to import mail from a non–Exchange Server instance, and we need to build a CSV file for the usernames and passwords. To import using IMAP, select the IMAP option (see Figure 7-60).
Note
If you do not have a third-party certificate, do not use the Microsoft mail migration tool; use BitTitan’s MigrationWiz.
After you have started the migrations, the next step is to install PowerShell. In some cases, you may need to install PowerShell early on if you have any problems with domain validation. In most instances, you will use PowerShell under the guidance of the Office 365 support staff.
Configuring Azure AD Connect
- 1.
Create two new accounts, OnPremSync and OnLineSync. The OnPremSync account needs to be an enterprise admin account, and the OnLineSync account needs to be a global admin account. We create two different accounts because we do not allow the Cloud account (online sync) to be added to the local AD. Likewise we do not allow the onPrem account to be added to the Azure ad. We isolate the accounts for security.
- 2.
Enable Azure AD Connect and download the software to the domain controller (log in to https://portal.azure.com and select Azure AD Connect).
- 3.
Install the software using the OnPremSync account. When you install the software, open a command prompt and run as an administrator, then execute the AD Connect download).
- 4.
Configure AD Connect.
- 5.
Check the status of AD Connect in Azure AD Connect Health (see Figure 7-63).
There are multiple ways to download AD Connect. All the approaches use the same download link at https://downloads.microsoft.com .
The one area where everyone makes a mistake is not to install the service as an admin (see Figure 7-64) or to log into the system and install using a different account than the OnPremSycn account. The installation process will set up permissions for the account that will be using the service (and the one that installs it (make it the same account). This is extremely important to avoid future problems.
Note
Do not sync the two accounts created. OnPremSync is unique to onPrem, and OnlineSync is used online with no license.
The process to install AD Connect is a two-step process. First you install the connector (run as an administrator or through a command as an administrator), select all the default settings, and leave the sync off. The second step is to start the installed tool and change the configuration. As this point you modify the configuration and set the default settings for your environment. After you run the tool the second time, you fully sync the settings to Office 365. See Figure 7-65 to begin the install of AD Connect (remember to run this tool from an admin prompt and in Figure 7-66, select Express when you start the installation.
Note
Do not sync after running the tool the first time. This will sync the entire AD organizational unit (OU) to Office 365. When you sync, you only want to sync those OU’s that are user accounts to Office 365.
Password writeback
Password hash synchronization
Exchange hybrid deployment
OU filtering (so you only sync those accounts that are required)
Just select the AD Connect installed tool on the desktop, and rerun the wizard, select the configuration option, and set the additional parameters required for your operation. The AD Connect tool is linked to Azure, so Microsoft will manage the tool updates. If you do have any alerts on using the tool, make sure you look at the passwords again (remember we use different password for sync admin and sync online accounts). This is usually the problem that users run into in troubleshooting AD Connect issues.
Hybrid Migration with Exchange 2007
In our migration, we talked about the ways to move from the on-premises Exchange Server to Office 365 and turning off your on-premises Exchange Server. There is another option available to all Office 365 users, and that is to run the Exchange Server admin console locally on your Active Directory. Microsoft provides Exchange Server at no charge, if you do not have any mailboxes installed on Exchange Server 2013. If you want to take advantage of this offer (and you are running the Enterprise Office 365 plans), all you need to do is log in to https://configure.office.com/Scenario.aspx?sid13 and verify your eligibility (see Figure 7-72).
Deploying the Hybrid Configuration Wizard to support Exchange Server 2007 federation move
The Hybrid Configuration Wizard does not need to be deployed on an Exchange Server instance. However, you need to be running Exchange Server 2010 or later. If you are running Exchange Server 2007, then you need to deploy Exchange Server 2013, change the mail flow, and then deploy the Hybrid Configuration Wizard. Exchange 2007 does not support the remote mail move capabilities required to migrate to Office 365. However, Exchange Server 2013 does support them. By joining an Exchange Server 2013 server into an Exchange Server 2007 infrastructure, you can no use the hybrid mail move. To deploy an Exchange Server 2013 server in an Exchange Server 2007 organization, visit the Microsoft Exchange Server Deployment Assistant (see Figure 7-73). Look at the Exchange deployment assistance on upgrading to Exchange Server 2013, and follow that process. Once the upgrade is completed (and the mail flow is running through the Exchange Server 2016 or 2019), you can deploy the Hybrid Configuration Wizard that we discussed earlier in the chapter.
Note
A hybrid migration is a complex migration. If you choose to use a hybrid migration, then follow these additional steps: review the Exchange Server Deployment Assistant (search for this in the search engine), deploy Azure AD Connect on the domain controller, and deploy the Exchange Hybrid Configuration Wizard to move data. If you are using Exchange 2007, you will need to add an Exchange 2013 server into your environment to move to Office 365.
Summary
The focus of this chapter was to migrate to Office 365. Granted this is purpoly out of sequence. In the earlier chapters we talked about security and now migration. This was to help you make the decision on migration to Office 365. There are different ways you can move your business to Office 365; the techniques depend on the size of your organization. Typically, small organizations use cutover migration, and larger organizations use federation migration. Now that you have migrated to Office 365., lets configure the Office 365 and Azure security services to protect what we just deployed.
Reference Links
Office 365 seems simple, but it is complex. There are many different areas to retrieve information about how to migrate to Office 365. The following are the important links for migration.