Office 365 is simple to configure, as long as you have a plan in place that answers two questions:
-
1.
How do you plan to deploy the clients?
-
2.
How do you plan to move historical e-mail to Microsoft Online services?
-
a.
The simplest migration is a Cut Over Migration
-
b.
The middle choice is Simple Coexistence
-
c.
The most complex is Hybrid Coexistence
If you are planning to use Directory Synchronization (DirSync), please review Chapter 11 before you proceed further. The Directory Synchronization tool copies the user accounts from the on-site Active Directory and creates the accounts in Office 365. If you use the Directory Synchronization approach, you cannot manually add accounts. The process that we are describing below is a manual process for the creation of accounts.
This section describes a 10-step plan that you can complete in an evening or over a number of days. If you are using Directory Synchronization (DirSync) or Single Sign On (ADFS) then read Chapter 11 before proceeding.
-
1.
Validate your domain(s) to Microsoft
-
2.
Add additional Domain Name Service (DNS) Information
-
3.
Configure Lync
-
4.
Install PowerShell
-
5.
Load users and assign licenses
-
6.
Migrate e-mail
-
7.
Set mail flow
-
8.
Configure mobile services
-
9.
Configure external devices (copiers, scanners)
-
10.
Clean up
Note
Are you using Single Sign-on? If you are planning to implement Single Sign-on with Active Directory Federation Services (ADFS), see Chapter 11 before you enable Single Sign-On or Directory Synchronization.
Step 1: Validate Your Domain(s) to Microsoft
This step is required to show Microsoft that you control your domain name. Log in as an administrator (or your original SUPER ADMIN/ROOT account). You can sign in at
office.microsoft.com
or
http://portal.microsoftonline.com
. Click “Admin” (at the right next to your name). You are at the Office 365 Dashboard. On the left-hand side (See Figure 4-5), select “domains,” then select “Add a domain” to start the process of adding your domain to the Microsoft Online environment.
Click on “Specify a domain name and confirm ownership” (see Figure 4-6). In Figure 4-7, enter your Domain Name (getoffice365now.biz in this example) and click “next”. Office 365 will show Domain Confirmation information. Click Next.
Office 365 will examine your domain and provide you an automated way to set up your domain. In Figure 4-7, Office 365 detected that the domain we want to verify is on Go Daddy, so it has promoted us to use an automatic configuration of the domain and DNS records.
The Office 365 Domain Wizard will prompt you to select the service for verification. We normally select “general instructions.” However, you can pick the service, and the Office 365 service will provide instructions on verification of that domain to that service (Figure 4-8).
Once you select the DNS provider (or general instructions in our case), you can choose which method used to “verify” your domain (Figure 4-9). Normally you can use the TXT record method. Follow the directions on the screen: sign in to your Domain Registrar and add the TXT (or MX) record as specified on this screen. Figure 4-10 shows a Go Daddy TXT record and Figure 4-11 shows a TXT records at Network Solutions.
Note
Typically it takes about 15 minutes for your changes to take effect. However, it can take up to 72 hours for the record that you created to propagate through the DNS system.
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 Go Daddy case, the name servers are at Go Daddy, so we are adding records in the Go Daddy servers. This is also the case for Network Solutions.
After you have configured the domain for validation, if the domain does not verify, use
http://www.mxtoolbox.com
to verify that the TXT records have propagated. Once the TXT records show up in
mxtoolbox.com
, you can validate the domain in Office 365. In Figure 4-11 we verify the record on
mxtoolbox.com
. The purpose is to check to see if the changed record in the DNS has replicated to the other World Wide Web DNS servers. These records will also replicate to Office 365. In our example, we are looking for the TXT record that we inserted into our DNS earlier. At MX toolbox we enter the command “txt:kamind.biz”. When the record shows up (see Figure 4-12), we can verify the DNS record in Office 365 and validate the domain. After the domain shows up on mxtoolbox, it should validate within an hour. If it does not validate, you will need to submit a ticket to Microsoft Online Services or contact a partner to help resolve the issue.
Once you have the record in the MX toolbox, then select “verify” in Office 365 (see Figure 4-12). If the domain verifies correctly, you will be provided with an acknowledgement that your domain is valid (Figure 4-13).
The next step (according to Microsoft) 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 defined the domain Intune. After you click “finish” in Figure 4-13 , select “assign users,” then select the radio button “I do not want to assign users right now" – Figure 4-14).
After you select Next, select the domain purpose (Figure 4-15) - item #3 – to set domain intent.
Specifying the domain services is an important step (Figure 4-16). You are letting Office 365 know how you are planning to use the domain that you just validated. Normally you will choose Exchange Online. You will choose Lync Online if you have Lync in your plan (E1 or above) and you have set up this domain with the correct SRV records.
Note
“SharePoint Online” actually refers to the public facing web site that is included in Office 365 Plan E1 or above.
After you complete the configuration of the domain intent, you will have an option to automatically configure Office 365 (and skip Step 2). Automatic configuration (Figure 4-17) only works if you are using a cutover migration. The MX records are changed using the automatic setup. We recommend the manual setup (see Step 2).
Step 2: Add Additional Domain Name Service (DNS) Information
After your domain has been validated, it is time to add additional DNS information. You have chosen to bypass automatic setup, and manually set up the records. You need to add all of the records listed in Figure 4-18. In this step you are adding DNS records as follows:
-
CNAME (alias or canonical name) records. These records are used to provide standard names to other Microsoft web services forOffice 365. You will be adding:
-
SPF (sender policy framework) record (a TXT @ record with text “v=spf1
include:outlook.com
∼all”). This record is part of an e-mail validation system designed to help prevent e-mail spoofing and phishing. This record will help prevent your outgoing e-mail from being considered “spam.”
-
SRV (service record) records. These records specify information about available services. SRV records are used by Microsoft Lync Online to coordinate the flow of information between Office 365 services.
Depending upon the services you are supporting, you may need to delete the older DNS records.
Note
Do NOT change your DNS MX records or Autodiscover records at this time. When you change your MX records, you will stop the mail flow to your existing e-mail server. When you change Autodiscover, the Outlook clients will go directly to Office 365 for e-mail. We will change mail flow in Step 6 after we have added the users.
Do not add the MX or e-mail Autodiscover records to your DNS - do this in Step 6.
After you have added the rest of the DNS records you will need to validate these records. Select the domain (see Figure 4-19), then select “troubleshoot.” On the next screen select “more than 72 hours” then “next” to verify the DNS records. If your DNS is valid, all check marks will be green. If there are errors there will be red Xs. Fix the errors until you have green check marks. You may run into a situation where the DNS cannot be fixed. If this is the case, you will need to move your DNS to a new 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.
Note
If you are using Windows Intune, you will need to add the CNAME “enterpriseenrollment” to your DNS. See Chapter 7.
Use the trouble shooting tools to correct the DNS problems. Always select more than 72 hours, so the automated tool provides useful information (see Figure 4-20). If you have red check marks, then correct those problems. The only red check marks you should have are for the mail records.
Note
The Office 365 automatic DNS tool will build the complete DNS records to match the Office 365 suggested configuration. This only works if you have loaded all of the users in step 2. The automated tool will set your MX record to Office 365. If you are using any other migration than a pure cut over, your mail flow will stop. We recommend that you load users as a manual process. If you have Active Directory (and Exchange 2007 or later) use Directory Sync to move your user objects.
Step 3: Configure Lync
When your Office 365 site is created, Lync is ready to operate within your intranet. As an administrator you need to decide if you want to open up Lync communications, federate the domain, and allow public instant messaging.
Lync “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 4-21).
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. At this time AOL and Yahoo messengers are not supported.
To enable these services, in the main admin dashboard, select “Lync” (figure 4-20), then select “organization settings” and the link “Manage Settings in the Lync Admin Center.”
In the Lync Control Panel (Figure 4-23) select “external communications.” Enable “Public IM,” and set “on except for blocked domains.” This action enables these services. “Enabled” is the recommended setting for both services. The default is off (disable).
Step 4: Install PowerShell
Earlier we briefly discussed PowerShell and the capabilities that it provides to you. This step is an optional step and it depends if you need the capability for your management of Office 365. The simplest way to install the latest version of PowerShell is to select Single Sign-on (see Figure 4-24) option.
Select step 3, “Install PowerShell” (See Figure 4-25). The PowerShell installation will verify the updates required to support the Windows Azure PowerShell. You are welcome to review step 1 and 2. However, the only option we are interested in is the installation of PowerShell on your desktop systems. Select the correct version (32 bit or 64 bit) for your system.
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 have offered 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 install Office 365 PowerShell, launch the PowerShell module and enter the following commands:
Set-ExecutionPolicy RemoteSigned
$LiveCred = Get-Credential
Import-module msonline
Connect-MSOLService – Credential $LiveCred – Verbose
Get-MsolGroup
The results of running theses commands should be similar to Figure 4-26.
You have completed the base PowerShell setup, now use the above command to validate the installation. If the command above does not work, you have either 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 5: Load Users and Assign Licenses
We are ready to start loading or enabling users into Office 365. As part of the loading user process, we have decided that we will either push the software out to the clients (using Windows Intune deployment), or we will request that the clients download the new software from the Office 365 site. If you are using a test group, you will repeat this step until you are ready for production. Test groups are iterative; by this we mean that you will add additional users to the test group as you reach the production decision point. If the organization is small, you will cut over to Office 365. If the organization is large, then run the test group and resolve deployment issues.
The purpose of the test group is to validate deployment. Once you have validated the business goals of the test group, you will continue your Office 365 migration. Step 5 (and some follow-on steps) can be repeated until you are ready to cut over to production (see Figure 4-27).
Let’s review what we have completed at this point:
-
1.
The domain(s) that we want to use have been validated.
-
2.
Lync DNS has been configured.
-
3.
We have collected our users, security groups, test groups, etc. (see Deployment Options).
-
4.
If we are using DirSync, the disabled user accounts are loaded in Office 365.
-
5.
We have communicated with the test groups that are being deployed (scheduled).
-
6.
We have pushed out software to the clients or we have instructed users how to download the applications themselves.
Now we load/enable the first batch, or nth batch users into Office 365. There is no technical limit on how many users we can deploy. The deployment group size is a function of support, and how many support calls that you wish to tender, or to avoid because you had a good business process for deployment.
Note
If you choose to use directory Synchronization for loading users’ accounts (and the appropriate migration method), you configure the service at this point. See Chapter 11 for the steps to configure Directory Synchronization.
THERE ARE THREE METHODS TO LOAD USERS
-
1.
Add each user (See “Onboarding Users” later in this chapter). This method is appropriate for a few users or a test group.
-
2.
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. (See “Onboarding Users” later in this chapter).
-
3.
Enable Directory Synchronized users for access to Office 365 (See “Onboarding Users” later in this chapter).
Pick your method to load users to 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 use Microsoft Migration tools (if you have an exchange server in your Active Directory). After you have selected your loading-user approach, then you can begin the mail migration process.
Note
The different user loading processes are described later in this chapter, in the “Onbarding Users” section.
License Assignment
If you selected DirSync (option 3 above), 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 users object is in Office 365, you can manually assign licenses or bulk assign them with PowerShell. If you selected manual loading (option 1 or 2), you need to purchase licenses to create the mailbox for the user. It is not possible to load users as a disabled user in Office 365, if you use a manual process (option 1 or 2).
Note
If you are using a test group, Step 5 through 8 will be repeated in the test group evaluation. After you completed the test group, return back to Step 5 to begin the deployment of Office 365.
Step 6: Migrate E-mail
In Step 5, our method of loading users defines the toolset we 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 Directory Sync integration (see Figure 4-28). If you use Directory Sync (DirSync), and there is an on-premises exchange server, you are required to use Microsoft migration tools. There are cases where you can use Microsoft DirSync and external tools, but we recommend that you consult a Microsoft partner if you use this approach.
Test Group or Staged Migration
Test groups are nothing more than a stage migration. Stage migrations take a lot of work and should only be used for a limited time and for a small number of users. When we discuss test groups, 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 will not have access to a common calendar or a common address list. It is for these two reasons that you want to use test groups for a very limited time 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 calendar and address lists).
Client Configuration Changes for Test Group
If you are using a test group with an on-premises Exchange Server, you will encounter two problems: AutoDiscover (for outlook client) and the presence of the Exchange Server in the Active Directory. There are only manual workarounds 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 in using Office 365. If you choose to manually configure outlook, you will still need to make these changes, since outlook will verify the connection via autodisocver everytime itis started.
These are the client steps required to support a test group if there is an on-premises exchange server:
-
1.
Add the Autodiscover record in the host file, located at <drive:>windows/systems32/drivers/etc
-
a.
Ping
Auotdiscover.outlook.com
.
-
b.
Add the record “autodiscover” with the address discovered above.
-
c.
Open up a command prompt and enter “ping autodiscover.” This should display the IP address you just entered.
-
2.
Add the registry fixes to ignore the Exchange server – Service Control Point. The registry entries required to be modified for the clients are listed below (see Microsoft KB article – 2612922).
-
a.
Navigate to the following registry key: HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover
-
b.
Set the following values for the Value Names listed below:
"PreferLocalXML"=dword:1
"ExcludeHttpRedirect"=dword:0
"ExcludeHttpsAutodiscoverDomain"=dword:1
"ExcludeHttpsRootDomain"=dword:1
"ExcludeScpLookup"=dword:1
"ExcludeSrvLookup"=dword:1
"ExcludeSrvRecord"=dword:1
Test Group Mail Flow
Mail flow in a test group uses a combination of forwarders from the on-site server to Office 365. The on-site server will use the
onmicrosoft.com
as the forwarding address (see Figure 4-29). This approach works, and is useful for testing, but not a recommend practice. Test groups are not integrated into the on-premises exchange server.
When you add the users to Office 365 these users have an active e-mail address. This means that:
-
1.
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.
-
2.
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 that you configure mail routing as follows:
-
1.
Only load users that are using Office 365 (during test or evaluation).
-
2.
If you are using both the Office 365 service and an on-site Exchange Server you need to set your email 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 user@<domain>.onmicrosoft.com.
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. We are just copying the e-mail messages (and other mailbox information) over to Office 365. There are different approaches to moving the e-mail to Office 365. Depending upon the approach you are using for migration, you may choose to “cut over the mail records before you move e-mail” or move e-mail, then cut over records. Typically the decision is based more on the source of the mail server and the size of the organization. There is no hard or 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 (1 – 2 weeks), along with the contacts, calendars and folder structure into the new mailbox. The older e-mails can come later. We use Migration Wiz to move historical e-mail as our first choice in tools.
There are four tools that you can use for e-mail migration. These are PST export/import, Third Party external tools (such as Migration Wiz), the Microsoft Office 365 Migration Tool, or moving mailboxes with Exchange Federation. Each tool has its fans and critics (see Table 4-1).
Table 4-1. Different Migration Methods
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 of your data is stored in PST, then you can only use a PST migration. There are no other options. If you mail is stored on a web server (such as on an Exchange Server), you can use the other tools for mailbox migration. We typically use Migration Wiz then use the Microsoft internal migration tool as a backup. If you have chosen to use Exchange Federation, you can only use the mailbox move for DirSync’ed accounts.
Note
To see the different steps in the migration, see section “Onboarding E-mail” later in this chapter.
We discuss the process for each of these approaches later in this chapter under “Onboarding E-mail.” The onboarding process will be similar to Figure 4-30.
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 a 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-premises 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).
Step 7: Set Mail Flow
At this point we are ready to set the mail flow based on our migration strategy. If you chose to cut over all users at one time (Cut over Migration), the Office 365 Global Address List (GAL) will contain all of 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 that have been moved.
In our planning discussion, there are three possible migration plans:
-
1.
Cutover Migration: All users are loaded, MX and Auto Discover records are changed and Office 365 receives all e-mail.
-
2.
Simple Coexistence: Some users are loaded; e-mail is forwarded from on-premises servers to Office 365 (temporary).
-
3.
Hybrid Coexistence: On premises and Office 365 operate in tandem.
The Hybrid Coexistence migration is a complex migration and is addressed in Chapter 11. Hybrid Coexistence requires an IT migration specialist assist you in the migration to Office 365. The other two methods are described below.
Cutover Migration
This is also called a 100% conversion. 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. This is the most common and simplest e-mail migration.
Note
If you have completed loading the users, you can change the DNS records to point to Office 365 services. These MX records are described in Figure 4-12.
Simple Coexistence
This is an iterative 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 are migrated to Office 365, and those users that 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 below) in the cloud. The iterative approach requires that only a portion of the users are loaded in Step 5, and the Domain Type is set to “Internal Relay” (see Figure 4-31).
To set the mail flow, you need to access the Exchange control panel access. To access the Exchange control panel select the following:
-
1.
Select “Office 365 in the admin center.
-
2.
Select “service settings.”
-
3.
Select “Mail option,” then select “don’t see what you are looking for… ,” and the “Manage Additional settings in the exchange admin center.”
The Domain Type is set to “Internal relay” (see Figure 4-31) until all of the users have been migrated. When the user migration has been completed, the domain is changed to “Hosted” and the MX records are changed to point to Office 365.
Note
If the domain is not set to Internal Relay, e-mail will not be forwarded from Office 365 to the on-premises mail server.
Coexistence E-mail Flow
When you initially purchase Office 365, one of the items created is the sub-domain “
yourdomain.onmicrosoft.com
.” This is a valid e-mail domain, and is the “long” e-mail address. You can 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
.
Simple coexistence works as follows:
-
E-mail is forwarded from the on-premises 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, Office 365 looks to see if 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 of the users into Office 365 and changed the DNS so the MX records point to Office 365, change the domain from “Internal Relay” to “Authoritative” (see Figure 4-29). At this point your e-mail is 100% on Office 365.
Once you have moved all of the e-mail addresses to Office 365, the MX records are changed to point to Office 365 (see Step 2). When the MX records are changed, coexistence mode is completed, and you have implemented your cutover migration. That is all that is really needed to move users to Office 365 for mail flow.
Step 8: Configure Desktop and Mobile devices
The desktop configuration for mobile devices and user desktop is in Chapter 2: Using Office 365 and Windows Intune. 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 auto discover records. Desktop services (outlook) require the auto discover record to be changed. Most mobile devices use the MX record to find the Office 365 mail server.
Configure desktop services
Depending upon the subscription (see Figure 4-32), the user will need to log into Office 365 and download the Office professional Plus software (located under the gear and “office 365 settings”) after you log into Office 365.
The installation process can be managed by any end user. The workstation setup guide is contained in Chapter 2. We designed chapter 2 to contain all of the Office 365 end user configuration in one location.
Mobile Device Configuration
The Office 365 supports different mobile devices. The software can be installed at any time, and is user driven (See Figure 4-33). To install the Office apps on your smart phone, go to the Office 365 web site, login, 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.
Complete information for end users to configure the device is in Chapter 2.
Step 9: Configure External Devices
External devices need to be configured (if there are any devices on your network). There are different ways that you can configure your devices to send e-mail to Office 365, either directly or through a SMTP server in your network. Chapter 10 has detailed instructions on device configuration for Office 365.
Step 10: Cleanup
The cleanup operation depends on what mail systems 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 if 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, usually there is no shut down sequence. This is not the case with an Exchange Server. An Exchange Server must be decommissioned to remove it from your local environment. To remove the Exchange Server, you simply uninstall the server. Seems simple, but to uninstall the server, you need to remove all users and delete public folders. The uninstallation wizard will walk you through the steps until the Exchange Server is removed; it is uninstalled.
Note
Do not power off the Exchange server once you have migrated to Office 365. The Exchange server must be uninstalled from the Exchange Server setup media. You must uninstall the Exchange Server software.