Microsoft Office 365: Make a Smooth Move to the Cloud
There are myriad factors to consider when migrating your users to the cloud, but the Microsoft Office 365 environment helps ease the path.
Brien Posey
The transition to the cloud is not one to be taken lightly. There’s little question that organizations will be able to save money moving to Microsoft Office 365, but the planning and processes involved in transitioning from an established infrastructure to a cloud environment is a major undertaking.
Microsoft is encouraging organizations of all sizes to begin migrating operations to the cloud when Microsoft Office 365 becomes available, and is doing its best to help smooth the process. Microsoft Office 365 is made up of cloud versions of Microsoft Exchange Server 2010, SharePoint 2010 and Microsoft Lync Server. Some Office 365 subscriptions will also include access to Microsoft Office Professional Plus, as well as the Microsoft Office Web Apps.
With so many different products in the Microsoft Office 365 Suite, comprehensively covering the migration process is a challenge. Instead, let’s look at how you’ll perform some common tasks in the new Microsoft Office 365 environment, and start thinking about some issues you’re likely to encounter during the transition.
Domain Names
One lingering question is how the transition to Microsoft Office 365 will affect an organization’s domain names. Exchange, SharePoint and Lync are clearly all dependent on Active Directory. The manner in which your domain names are affected depends on whether you choose to maintain an on-premises Active Directory and whether you decide to use identity federation.
If you want to continue hosting Active Directory, but don’t want the hassle of implementing identity federation, then you can have Microsoft Office 365 handle domain names through a process called partial redelegation. Your organization retains ownership of the domain name, but certain functions such as e-mail and Web hosting are redirected to Microsoft Office 365 servers.
Microsoft makes the process of redelegating a domain for use with Microsoft Office 365 fairly painless. The Microsoft Office 365 administrative console lets you add a domain name (see Figure 1).
.jpg "Figure 1 You can add your existing domain names to Microsoft Office 365")
Figure 1 You can add your existing domain names to Microsoft Office 365
Before you can add a domain to Microsoft Office 365, you’ll have to prove you own the domain name by providing the sign-in credentials for either the domain registrar or host.
Users and Groups
Working with users and groups within a Microsoft Office 365 environment takes some acclimatization. Rather than exposing the Active Directory Users and Computers console, Microsoft provides you with the interface (see Figure 2).
.jpg "Figure 2 The administrative console contains a mechanism for creating and managing user accounts.")
Figure 2 The administrative console contains a mechanism for creating and managing user accounts
Microsoft gives you several options for managing user accounts. If you already have an Active Directory environment, your best bet will probably be Active Directory synchronization. This establishes a relationship between your local Active Directory and the Microsoft Office 365 cloud. You can continue using your existing Active Directory infrastructure and all the Active Directory management tools.
The most important thing you need to know about Active Directory synchronization is that the process only works one way. The contents of your Active Directory are copied to the cloud, but changes made to the cloud are not replicated to your local Active Directory. Although it’s technically possible to make changes to the user accounts through the cloud interface, those changes are never replicated to the local Active Directory and will eventually be overwritten by the synchronization process.
Another option for managing user accounts is to use identity federation. The basic idea behind identity federation is that you retain control of your own Active Directory environment. By implementing version 2.0 of the Active Directory Federation Service, you can let users log into the cloud using their normal Active Directory credentials.
If you’re going to be performing Active Directory synchronization, Microsoft strongly recommends you first enable identity federation. If you want to use Active Directory synchronization, but choose not to enable identity federation, you must redelegate your domain in the manner described earlier.
Start in the Cloud
It’s worth noting that having a local Active Directory deployment is not a prerequisite to using Microsoft Office 365. Likewise, you can also have an on-premises deployment to move everything to the cloud, as long as you’re not running any on-premises applications (other than the ones included in Microsoft Office 365) that require access to Active Directory.
The administrative interface lets you create user accounts directly within the Microsoft Office 365 environment; however, don’t do this if you’re performing directory synchronization. Although you can create user accounts one at a time through a Web-based wizard, the administrative console also lets you create user accounts in bulk by populating a CSV file with user account information and then importing that file. You can see that the administrative console provides an option to either download a blank CSV file or a sample CSV file (see Figure 3).
.jpg "Figure 3 You can create user accounts in bulk by adding the user information to a CSV file.")
Figure 3 You can create user accounts in bulk by adding the user information to a CSV file
Migrate Existing Users
Just as Microsoft Office 365 lets you create new user accounts in the cloud, you can also migrate existing users. Microsoft Office 365 includes Exchange Server 2010. Even though mailbox data is stored on a mailbox server, the mailbox itself is an Active Directory attribute. As such, migrating a user account also means migrating the user’s mailbox.
Migrations are not an all-or-nothing proposition. You can create coexistence scenarios in which you have users with on-premises Exchange mailboxes, while other users’ mailboxes exist in the cloud.
With that said, user migrations to Microsoft Office 365 are treated as mailbox migrations. Coexistence aside, Microsoft Office 365 supports two types of mailbox migrations. You can perform an Internet Message Access Protocol (IMAP) migration or an on-premises Exchange migration.
IMAP Migrations
You’d use an IMAP migration when you need to migrate mailbox data from either a non-Exchange mail system or from Exchange 5.5 or Exchange 2000. The actual migration process is relatively simple, but it can require quite a bit of preparation work.
Before you can perform an IMAP migration, you’ll have to create Exchange mailboxes for all the users whose mailbox data you’ll be migrating. You’ll also have to create a CSV file with the e-mail address, user name and password for each mailbox that you’ll be migrating. Once you’ve assembled the required information, you can use the E-Mail Migration option in Outlook Web App to perform the actual migration (see Figure 4).
.jpg "Figure 4 E-mail migrations are done through Outlook Web App.")
Figure 4 E-mail migrations are done through Outlook Web App
At the moment, Microsoft Office 365 is still in beta testing and there’s some ambiguity regarding the number of users you can effectively migrate. The E-Mail Migration interface indicates you must have fewer than 1,000 mailboxes, but the documentation indicates that you can perform large-scale migrations by migrating mailboxes in batches. The documentation suggests that you limit each batch to 2,500 mailboxes.
Exchange Server Migrations
As was the case with the IMAP migration, an Exchange migration moves mailbox data to the cloud. The migration process moves messages, contacts and distribution groups.
There are two different types of Exchange migrations. A simple migration moves all the Exchange mailboxes at once. A staged migration migrates a subset of the mailboxes. You’d use a staged migration in coexistence scenarios.
The first step in performing a simple migration is to specify the migration type. You can choose to perform an Exchange 2007 and later migration or an Exchange 2003 and later migration (see Figure 5). The only real difference between the two is that the Exchange 2007 option uses the Autodiscover service to automatically detect your connection settings. The Exchange 2003 option requires that you manually specify your connection settings.
.jpg "Figure 5 The Exchange 2007 option uses the Autodiscover option to detect your connection settings.")
Figure 5 The Exchange 2007 option uses the Autodiscover option to detect your connection settings
As you can imagine, the migration process can take some time to complete. This is especially true if you have a lot of mailboxes or particularly large mailboxes (Microsoft Office 365 has a 25GB mailbox quota). Microsoft Office 365 uses two different synchronization methods to keep the mailboxes in sync during the migration.
During the initial synchronization, the mailbox data is first copied to the cloud. After that, Exchange performs an incremental synchronization once every 24 hours. The incremental synchronization copies any new mailbox data to the cloud.
After all of the mailboxes have been migrated, Exchange sends you an e-mail letting you know the migration has been completed. This message contains two attachments. One of these attachments is a file named MigrationErrors.csv. This lists any mailboxes that failed to migrate. The other attachment is named MigrationStatistics.csv. This contains information about the number of items that were migrated.
More importantly, however, the MailboxStatistics.csv file contains a temporary password for each user. The user will have to use this password when they log into the cloud, and then reset the password.
At this point, you can redirect the Mail Exchange record on the organization’s DNS server to point to the cloud server. This will cause messages to go directly to the cloud server. The migration completes with a final synchronization and confirmation e-mail message. Then you and your users are computing in the cloud.
.jpg "Brien Posey")
Brien Posey, MVP, is a freelance technical author with thousands of articles and dozens of books to his credit. You can visit his Web site at brienposey.com.