Step 1: Purchase Your Office 365 Services

There are different ways to purchase your subscription, either from the Web or through a URL supplied to you from your Microsoft Partner. As shown in Figure 7-5, you can set up a 25-user trial at https://www.kamind.com/contact-us/ and request a trial subscription. You can also purchase a 1 user subscription form our website select the Office 365 floating web page (lower-right corner). Once the web page loads, select Try Office 365 to launch the 25-user trial subscription.

Once you have requested the business premium trial subscription, you will receive a link in your email account. Click on the Business Premium Trial subscription link (see Figure 7-6), you need to enter your company information (see Figure 7-7). After you have done this, enter an administrator name and domain (see Figure 7-8). You can request any trial subscription form our website. In this example, we used a small business subscription called Business Premium.

Once you have selected “Text me” or “Call me,” enter the verification code and create your account (see Figure 7-9). When your account is created, the screen should look like what’s shown in Figure 7-10.

Figure 7-11 shows that the account has been created.

Step 2: Validate Your Domains to Microsoft and Add DNS Records

After you have created the subscription, the next step is to validate the domain. Validating the domain proves to Microsoft that you own the domain in Office 365. Sign in at http://portal.office.com using the account that you created in step 1. Click the Admin icon (or select the nine-block grid in the upper-left corner to select Admin). You will be at the Office 365 dashboard. On the left side, click “Show more,” then Setup, then Domains, and then “+ Add domain” to start the process of adding your domain to the Microsoft Online environment (see Figure 7-12).

Office 365 requires you to prove that you own the domain you are using. Figure 7-13 explains DNS and outlines the process of Office 365 configuration. Click Next.

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.

The Office 365 domain wizard prompts you to select the service for verification. If you are going to cut over to Office 365 (move all mail services immediately to Office 365), then use the wizard. If you are not planning to use Office 365 this instant, then click “Step-by-step instructions” and manually configure your DNS service (see Figure 7-14); then click Verify.

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.

To manually add the domain verification record, follow the directions on the screen. Sign in to your domain registrar and add the TXT record as specified on this screen. Figure 7-15 shows a GoDaddy TXT record, and Figure 7-16 shows a TXT record at Network Solutions for the domain getoffice365security.com. The process is the same for all domain verification.

Each domain supplier has different tools and processes to add a domain record. You can only add domain records if the domain is managed by the domain supplier. In the GoDaddy case, the name servers are at GoDaddy, so we are adding records to the GoDaddy servers. This is also the case for Network Solutions.

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.

In this example, we are looking for the TXT record that we inserted into our DNS earlier. On MxToolbox, we enter the command txt:getwindowsintunenow.biz. When the record shows up (see Figure 7-17) in MX toolbox, we can verify the DNS record in Office 365 and validate the domain. The domain should validate within an hour. If it does not validate, you need to submit a ticket to Microsoft Online Services or contact a Microsoft Partner to help resolve the issue.

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.

The Office 365 wizards are useful if you are creating an Office 365 account and a new domain for the first time; if this is the case, then select “Set up my online services for me (Recommend).” Any business that has an existing e-mail service will use the option “I’ll manage my own DNS records.” We will walk you through the next steps of adding and validating the DNS records.

In this example (see Figure 7-19), we do not have an existing service, so we will configure all the records for Office 365.

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.

After the records are added, you verify the records. If the records are entered correctly, they validate with a green check mark. If the records are incorrect, there is a red X. The mail records show up with a red X. After you have made the changes in the DNS (only change the records that were highlighted), then click Verify and complete the wizard. The wizard indicates errors in the records that you have not changed. If all the records are correct (making a cutover migration), then you will see a screen like Figure 7-21.

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.

At any time you can add additional DNS records. If Office 365 finds a mismatch of the DNS records (with the records that it expects), Office 365 will display the “Complete setup” message (see Figure 7-22). Click “Complete setup” to fix the DNS issues. Office 365 will display the records that need to be added. If Office 365 determines that some of your DNS entries are valid, these valid entries will have green check marks. If there are errors, there are red Xs. Fix the errors until you have green check marks. You may run into a situation where the DNS server cannot be fixed because your provider will not support the advanced DNS records. In that case, you will need to move your DNS to a different provider. Once the records have been validated, you can change the primary domain to the user account domain and add the necessary users to the account.

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.

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.

Step 3: Configure Skype for Business (S4B ) for Teams

When your Office 365 site is created, Teams is ready to operate within your intranet. As an administrator, you need to decide whether you want to open Teams communications to external users and allow instant messaging. Microsoft calls this federating the domain. To enable these services, log in to the Office 365 admin center and select Skype for Business below the Admin menu (see Figure 7-23). If you have purchased or enabled the trial for Skype for Business calling, there are additional licenses that are assigned to your subscription. Configuration of the phone service is completed after you have migrated your users to Office 365.

The Teams “domain federation” allows your intranet to interact with other Office 365 customers and non–Office 365 e-mail addresses that support Microsoft Federation services. For example, domain federation allows your users to see the presence of external vendors (see Figure 7-24). At this point, we are not going to configure Teams/Skype voice or dial-in conferencing. These services require that the user accounts be loaded into Office 365.

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.

Step 4: (Optional) Configure Yammer Enterprise for Office 365

After the Office 365 domain is verified, the next step is to configure Yammer so that all users have access to the Yammer network. To configure Yammer, log in to Office 365 (see Figure 7-25), and select the admin center and then Yammer. The next step is to enable the verified domain as your Yammer domain.

Once you have selected Yammer, Yammer prompts you for your domain for integration to Office 365. Select the verified domain that you entered earlier and then activate. In Figure 7-26, we use the verified domain kamindit.net.

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).

The process of linking to Azure is a simple one; you need to pick the primary global admin account (usually the first account when the subscription is created) and link that user account to Azure as a management account. Once you complete this task, this account becomes the Azure services administration account. In our case, the account we are using is [email protected]. The Azure services administration account manages all Azure activity. It is the primary billing account for all Azure services and is used to assign other Azure services to user accounts. Once you selected this account, inform your Microsoft CSP partner to assign the Azure consumption services to this account. The Azure consumption account is not needed for the migration but is needed for the advanced security services discussed in previous chapters.

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 process of assigning the licenses is straightforward. To get started, make sure you are logged in to Office 365 with the global admin account you are using to manage your Office 365 Azure services. In the admin center, select Active Users, double-click the selected user account (in our case this is [email protected]), and edit licenses. Once you complete this step, assign the licenses Office 365 E5 and EMS E5 to the account (see Figure 7-28). Then you can move forward and link the Office 365 tenant to the Azure management services. Once you have assigned the licenses, you now must link the services into Azure. Click Azure AD under the “Admin centers” menu (see Figure 7-29).

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.

In Figure 7-30, I highlighted the option Sync with Windows Server AD. This is the link you will use to install the Azure AD connector on your domain controller (if you are linking accounts from Office 365 to Azure). Do not select this option now until we complete step 6. If you have an on-premise Active Directory and you have an Exchange Server instance, you must decide the type of migration you will be using, either a federated move or a cutover migration.

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.

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:

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.

You want to be careful with using Active Directory synchronization. AD synchronization will disallow the creation of mailboxes in Office 365 if there is an on-site Exchange Server. To get around this, you need to manually load users into Office 365 and then enable Active Directory synchronization. This approach bypasses the AD synchronization checks and forces Active Directory synchronization to “soft match” the Office 365 accounts with the on-premises Active Directory. The result is that you have an Office 365 mailbox ready for migration and password synchronization with the on-site Active Directory—and a destination mailbox created in Office 365. Figure 7-31 shows a flow chart summarizing the two migration options.

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)

There are three ways to load users: Azure Active Directory synchronization, the Office 365 graphical user interface, or the bulk-load process. The GUI is great for maintenance and small numbers of user accounts (see Figure 7-32), but it is not an effective tool for loading many user accounts. If you choose to use directory sync and you have an on-premises Exchange server, you need to use the Office 365 migration tools.

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.

We recommend you use the optional fields and enter all the data possible. If you are accurate at this step, it significantly reduces the amount of work necessary to manually fix user profiles. After you have built the CSV file, click Browse and load the file.

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.

To integrate your local AD and Microsoft cloud, you need to have the following:

• 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.

To download the Active Directory tool (refer to step 5, shown in Figure 7-30) and click Sync with Windows Server AD (see Figure 7-34). Select the Federation option, the domain (in our case Getoffice365security.com) and to download the Azure AD connector (see Figure 7-35). Install the software using the Sync Admin account on your domain controller.

After you have installed the Azure Active Directory Connector, you will need to make some changes in your local AD. Office 365 and Azure require that the domain account be Internet routable. Traditionally, AD accounts were installed with a local extension (and were not Internet routable). You will need to change the UPN and make additional changes in Active Directory to make sure the user accounts show up in Office 365. The steps to accomplish this are outlined here:

1. 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. 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 .)

    

After you have installed the Azure AD Connect software, select Azure AD Connect Health (see Figure 7-36), and validate the Azure Active Directory Connect health. You should see the services fully deployed. If you see any errors, you need to remediate them.

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).

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:

The federation wizard is easy to install. Once you have set up the Azure Active Directory Connector with Office 365, all you need to do is log in to Office 365 and click “Admin center,” then “Exchange admin,” and then “hybrid” (see Figure 7-37) . The latest version of the wizard will be downloaded and installed on the server. We recommend that you log in with the credentials that you are using for the AD Connect.

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.

After these four steps are completed, you are ready to perform a mailbox move to Office 365.

Connector Validation

Once you complete the wizard, go to Office 365 and the Exchange admin center, select “mail flow” and then “connectors.” Select the outbound connector to Office 366. On the right side (see Figure 7-39), select “Validate this connector.” If the connector fails for any reason, you need to troubleshoot the failure. Typical failures happen when you have a third-party spam filters that do not permit the Office 365 address to send messages to the on-site Exchange Server instance. If the validation fails, debug the issue. Usually the validation fails because the firewall will strip off the TLS on the email form Office 365. In this case, set up an IP address (not in DNS), that goes directly to the exchange server and bypass the firewall scanning. Once this is in lace and validated, then enter the external IP addresses of Office 365 servers to restrict access only to email coming from Office 365. You must validate the connector before you can move any mail.

Bypass the Spam Filter

The final configuration (besides the adjustment for mail flow) of the connectors to set up the spam filter to bypass all e-mails that come from a specific IP address. The on-premise Exchange Server instance has an IP address that it uses to send mail out to the public net. You will need to retrieve this address and add a bypass for the spam filter in Office 365 in the transport rules (see Figure 7-40). To add the rule, do the following:

1. 1.

   Select “mail flow” and then “rules” and then select “Bypass spam filtering” from the drop-down.

    
2. 2.

   Enter the IP address for the new rule (do not use domain names).

    
3. 3.

   Save the rule.

    
4. 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.

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.

Internal Relay Mail Flow (and Test Groups)

An internal relay mail flow uses a combination of forwarders from the on-site server to Office 365. The on-site server uses onmicrosoft.com as the forwarding address (see Figure 7-42). This approach works and is useful for testing, but it is not a recommended practice. Test groups are not integrated into the on-premise Exchange server.

When you add users to Office 365, these users have an active e-mail address. This means the following:

• 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.)

We recommend you configure mail routing as follows:

• 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.

Step 9: (Optional) Manually Install PowerShell

PowerShell allows you to configure Office 365 features via a command line. This step is an optional step, and it depends on whether you need the capability for your management of Office 365. The simplest way to install the latest version of PowerShell is to go to https://docs.microsoft.com/en-us/office365/enterprise/powershell/connect-to-office-365-powershell . This installation will provide you with the basic features necessary to use PowerShell for Office 365 (Figure 7-43).

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 .

The result of running these commands should be like what’s shown in Figure 7-44.

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.

There are four tools that you can use for e-mail migration: PST export/import, third-party external tools (such as MigrationWiz), the Microsoft Office 365 migration tool, and moving mailboxes with Exchange Federation. Each tool has its fans and critics (see Table 7-1).

Table 7-1

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.

There are different deployment methods that you can use depending on how your data is kept. As an example, if you have been using POP mail and all your data is stored in PSTs, then you can only use a PST migration. There are no other options. If your mail is stored on a web server (such as on an Exchange server), you can use the other tools for mailbox migration. We use MigrationWiz ( www.bittitan.com ) tools and use the Microsoft internal migration tool as a backup. If you have chosen to use Exchange Federation, you can only use the Exchange mailbox move for synced accounts. Public folders can be moved with MigrationWiz tools. We discuss the process for each of these approaches later in this chapter in the “Onboarding E-mail” section. The onboarding process is like what’s shown in Figure 7-46. If you are using AD Connect (see Figure 7-47), user accounts in Office 365 are synced from AD and are not entered manually.

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.

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.

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).

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

Depending upon the subscription (see Figure 7-48), the user will need to log into Office 365 and download the Office Professional Plus software (located under the gear icon and Office 365 settings). The installation process can be managed by any end user. All that is needed is to log into prtoal.office.com and download the new software.

Mobile Device Configuration

Office 365 supports different mobile devices. The software can be installed at any time and is user-driven (see Figure 7-49). To install the Office apps on your smartphone, go to the Office 365 web site, log in, select the Software option under Office 365 settings, and install. You will receive a link in the e-mail on where you can download the information to your smartphone and configure the mobile device. The mobile software is also located in the iOS and Android store. This screen is mostly for legacy devices and configuration that do not have a mobile device management configuration.

Step 13: Configure the External Devices

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.

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.

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.

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

Follow these steps on exporting the PST data into Outlook. If you already have your PST files as an archive, refer to the import. When you export Outlook information into a PST for import into Office 365, you must export the root mailbox.

1. 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. 2.

   In Outlook 2013/2016, click File ➤ Open ➤ Import (this includes file export as well).

    

1. 3.

   Select “Export to a file” and then Outlook Data File (.pst), as shown in Figure 7-53.

    

1. 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).

    

1. 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

Follow these steps to import your exported PST e-mail data into your Office 365 e-mail account. This is done by loading the existing mailbox on top of the Office 365 mailbox.

1. 1.

   Exit Outlook.

    
2. 2.

   Sign in to the user’s Office 365 account.

    
3. 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. 4.

   In Outlook 2010 (or 2013/2016), click File ➤ Open ➤ Import.

    
5. 5.

   Select Import from another program or file.

    
6. 6.

   Select Outlook Data File (.pst), or it may be Personal Folder File (.pst), as shown in Figure 7-55.

    

1. 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

MigrationWiz ( www.migrationwiz.com ) is the tool (see Figure 7-57) that is used for most migrations from either on-premise or another hosted provider to Office 365. The tool is easy to use and allows thousands of mailboxes to move simultaneously.

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.

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.

Using MigrationWiz

In step 9 (earlier in this chapter), we chose a cutover migration. The easiest way to look at a migration is to use a hypothetical situation. In this example, there are ten mailboxes and a Windows server running Exchange. The migration tools that we will use are MigrationWiz and DeploymentPro. MigrationWiz moves the data, and DeploymentPro configures the desktop and sets the default profile. The migration steps using these tools are as follows:

1. 1.

   Log in to www.bittian.com and create a migration account. Confirm your account and select MigrationWiz (see Figure 7-58).

    
2. 2.

   Verify that Exchange Server 2007/2010 is set to basic authentication.

    
3. 3.

   Configure the permission for the admin user mailbox on Exchange Server.

    
4. 4.

   Build the migration project and enter the admin credentials.

    
5. 5.

   Load the user for migration.

    
6. 6.

   Purchase licenses for migration.

    
7. 7.

   (Optional) Select DeploymentPro for desktop configuration changes and send out the Configuration tool.

    
8. 8.

   Start the mailbox migration.

    
9. 9.

   Retry migration errors.

    
10. 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

MigrationWiz is a third-party tool that you can use to migrate to Office 365. However, there is also the Microsoft Office 365 migration tool. You can use this tool for cutover migration and for Exchange Federation moves to Office 365. The tool is straightforward to use, and you can move user mailboxes to Office 365 or move them back to the on-premises Exchange Server instance.

1. 1.

   Select Office 365 in the admin center, then select Exchange Admin center.

    
2. 2.

   Select recipients, then select migration.

    
3. 3.

   Select the "+" drop down to see the migration types

    
4. 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).

Provide the credentials to import the user accounts into Office 365, and create a CSV file to load the users from the source server into Office 365 (see Figure 7-61). The wizard assumes that the e-mail address of the source server is the destination e-mail address on Office 365. You need to be a global administrator to use this tool.

After you have clicked Run, Office 365 monitors the status and sends you an e-mail when the migration is completed. It lists the batch status (see Figure 7-62).

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

Configuring AD Connect is straightforward. The hardest part is the installation of the software on the server and connecting this to Office 365. There are different philosophies for the installation of AD Connect. In our case what we do is the following:

1. 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. 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. 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. 4.

   Configure AD Connect.

    
5. 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.

Select the Express installation (Figure 7-67) and enter the accounts created for management in Figure 7-68. Unless you have a federated move with exchange server, leave federation off (Figure 7-69).

At this point the base configuration is completed. We do not enable auto sync because we need to configure the on-premise Active Directory sync and the optional features for the AD Connect tool. The next steps are to run AD Connect a second time and set up the optional features. Typically, you set the following:

• 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.

Microsoft is continuously expanding the capabilities of AD Connect. It is expected that Azure directory services will be integrated into the AD Connect tool (See Figure 7-70). After you have completed the installation, you may have additional configurations to complete. Complete the configuration if prompted (see Figure 7-71).

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).

This is important because to use a federation move, you need to be running Exchange 2010 or later. To federate a 2007 server, we deploy Exchange Server 2013 as a mail migration server (requires an Enterprise E3 or E5 license).

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.

It is highly recommended that you contact a Microsoft Partner to assist you in this process. Hybrid migration is just a different step in the migration process. Exchange Server needs to be up-to-date with all service packs, or the hybrid migration will fail. Once you have compelled the migration, then upgrade the Exchange 2013 server to Exchange Server 2019.

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.