Export (0) Print
Expand All

Deployment planning tips for Office 365

 

Applies to: Office 365 Enterprise

Topic Last Modified: 2014-10-29

Summary: Provides information on the Setup Assistant app, and other tips for network readiness, directory cleanup, migrating email data, and hybrid deployments.

The best way to prepare your company to move to Office 365 is by running the checks provided by the Setup Assistant app. After you install the app, it will check the configuration of your existing environment and make recommendations for how to best move to Office 365. Setup Assistant also verifies the configuration settings in your environment to make sure you’re ready to start deployment and to alert you to changes that may need to be made.

You can also review Top Deployment Considerations to help plan and prepare for your deployment of Office 365.

Setup Assistant is available to assist you with automated discovery and readiness checks related to Office 365 deployments. To use the full features of the Setup Assistant you first have to sign-in on a domain-joined computer at your organization and then install a click-once app. This only needs to be a domain-joined computer if your company uses a domain. You can then use the app to review recommended deployment steps and discover what’s installed in your organization to determine your deployment readiness.

You can also use Setup Assistant to manually select the deployment options for your Office 365 experience by opting not to install the app and by manually picking the features you want to use. In this case Setup Assistant will give you a list of step-by-step tasks that will help you create the Office 365 experience you chose.

See Use Setup Assistant to determine Office 365 readiness for instructions on how to use the app.

The following resources can provide additional help with deployment questions and tasks.

Office 365 Community

The Office 365 Community site posts the latest developments and information related to Office 365. It includes a discussion area where site members post questions and answers. You can also access the Blogs, Forum, and Wiki pages from this site.

IDFix

You can also use the IDFix Tool to perform discovery and remediation of identity objects and their attributes in an on-premises Active Directory environment in preparation for migration to Office 365. IdFix is specifically intended for the Active Directory administrators responsible for DirSync with the Office 365 service.

Exchange Server Deployment Assistant

The 2010 Exchange Server Deployment Assistant provides detailed guidance for the hybrid deployment scenario from the on-premises Exchange environment to Exchange Online.

The Exchange 2013 Deployment Assistant provides detailed guidance for the hybrid deployment scenario from the on-premises Exchange environment to Exchange Online.

Microsoft Assessment and Planning Toolkit

The Microsoft Assessment and Planning (MAP) toolkit generates detailed readiness assessment for migration to cloud-based services such as Office 365 for enterprises.

Lync Online Adoption and Training KitThe

Lync Online Adoption and Training Kit includes resources to help your users become productive more quickly.

MOSDAL (Microsoft cloud services Diagnostics and Logging) Support Toolkit The MOSDAL Support Toolkit collects system, network, service-based application configuration and logging data along with performing network diagnostics. The toolkit can be used for a variety Office 365 troubleshooting issues.

When planning your Office 365 deployment, you’ll come across a number of technologies, features, and functions that make Office 365 a unique service. As you go through the process of determining your requirements, try to keep things simple. Just because there is a technology, feature, or function doesn’t mean it’s required or even important for you to deploy it.

Consider the following while planning your deployment:

  • When determining your migration approach, what are the “must-have” requirements and what are “nice-to-have” options?

    • Do you need all legacy email migrated?

    • Can you skip migrating email, create empty mailboxes, and then move everyone to their new mailboxes in a few days or will you need more time?

    • Do you need a hybrid configuration? If so, what type and for how long?

    • Do you want to manage Exchange Online from on-premises? This is important because it requires the installation of at least one Exchange Server to run the tools.

    • Do you require Active Directory synchronization or is it easier to manage user identities only in the cloud?

When you sign up for an Microsoft Office 365 for enterprises trial subscription, an online subscription will be created for you, which contains all the Office 365 services and settings that you plan to use. This tenant can be deleted when you test the service. When you’re ready, you’ll need to create a new production tenant when you are ready to deploy Office 365 in your organization.

However, many users create a trial tenant for testing purposes, and then use this same tenant for production. This provides the most benefit because all configuration tasks needed to migrate and use Office 365 will already be in place and tested. The downside is that you’ll have to once more test against your production environment, sync your production domains, users, groups, and contacts if you plan to use directory synchronization.

If you plan to use your trial tenant for production, be sure to choose a name for the tenant that is different from your planned production tenant name. It’s a common mistake to use a company name for the trial. The name of the tenant appears in Lync invites and SharePoint Online, but Microsoft does not currently have tools to rename a tenant or migrate data from one tenant to another. If you change your mind later, you have to create a new tenant and manually move your data and settings.

For example, you may want to name your tenant differently when setting up trial account as opposed to a production account.

NoteNote:
If you have more than 50,000 user objects in your directory, contact Microsoft Support before signing up for a production tenant.

If possible, we recommend that you run a proof-of-concept deployment with your tenant. After the tenant is ready, you can begin planning for the features you want to use with the service. For smaller organizations, you may choose to manage the users and all other settings by using the Office 365 portal. If this is the case, you may start creating users and mailboxes directly through the Admin page and begin setting up client computers to connect.

If you choose a more advanced configuration where users’ accounts are synced from your Active Directory, or you want to set up coexistence and advanced migration tools, you need to plan and prepare for the setup of the following:

  • Directory synchronization: Synchronizes your Active Directory user and group information to the tenant. This allows for a unified global address list to be shared between your Office 365 tenant and your on-premises email environment. It’s also required for more advanced features such as Active Directory Federation Services (AD FS) 2.0. Directory synchronization also allows you to manage your account information in your on-premises Active Directory by using your existing Active Directory management tools.

  • AD FS 2.0: Allows you to authenticate Office 365 users against your own Active Directory so they can use their existing on-premise Active Directory account and password to connect to the service.

Your organization must plan in advance for configuration of internal and external DNS records, as well as the testing efforts to make sure that name resolution is functioning properly. Your organization should also plan to provide the appropriate Internet bandwidth for the services you select when migrating data to Office 365.

It is also important to be aware that Office 365 requires specific ports and protocols to be accessible to support the use of online services and migration tools Third-party Secure Socket Layer (SSL) certificate use is required to secure your organization’s Office 365 deployment. These items can cause concern or misunderstanding that frequently cause customer support issues:

  • Filtering based on domain names and not by IP address

  • Network support translation (NAT) support in Office 365

For more information about network readiness, see the Plan networking and naming services for Office 365 section of the deployment guide.

Successful directory synchronization between your on-premises Active Directory environment directory and Office 365 requires that your on-premises directory objects and attributes be properly prepared. If you plan to source (provision) your user objects from your on-premises Active Directory (by using directory synchronization) to Office 365, make sure you understand the customer Active Directory requirements for Office 365 and run the checks available in the setup assistant described in Use Setup Assistant to determine Office 365 readiness. This helps you prepare your Active Directory for interaction with Exchange Online, SharePoint Online, Lync Online, AD FS 2.0, and directory synchronization. Be sure to remediate all issues before deploying and activating directory synchronization.

If you’re planning to use single sign-on (SSO) with Office 365, you have to determine a few things in advance:

  • Register the domain you plan to use for SSO in Office 365. If this is a trial or test tenant and you are using test accounts, use a test domain such as testcontoso.com but not test.contoso.com.

    For example, if this is a tenant that you plan to use for production, use the domain you plan to use in production, such as contoso.com.

  • Ensure the users you plan on enabling for SSO have the previously mentioned setup domain as their user principal name (UPN) suffix.

NoteNote:
Before changing a user’s existing UPN, ensure the user has no certificates in Active Directory that are based on the old UPN. Any encrypted items with the certificate (email, files, and so on) cannot be decrypted afterwards.

For more information, see Prepare for single sign-on with Office 365.

Plan ahead for any desktop upgrades and new software requirements; these items can affect your deployment plans.

You’ll need to deploy Office applications and any associated updates to all the end users who plan to use the services with the client applications. Determine who will drive this process, and include them in migration planning meetings for proper timing of the desktop updates with regard to mailbox migrations.

Consider the following:

  • What products and updates need to be deployed?

  • How will any updates and products be packaged and deployed to the computers?

  • Can you verify whether a computer has been updated?

  • Is compatibility testing required for line-of-business apps before rollout?

  • Many Office 365 services can be accessed by using a web browser.

  • Are clients able to connect through the firewall to all services?

To ensure that you are compliant with Office 365 from a desktop perspective, review Plan for client computers and mobile devices that connect to Office 365..

When assessing how Office 365 will meet your business requirements, your organization should take an inventory of your line-of-business applications and determine which messaging or collaboration components, if any, will need to integrate with Office 365 service offerings. In some cases, your organization may need to make changes to the application or custom code to ensure that it functions properly with Office 365 service offerings.

The following interfaces are available to your organization to provide application integration with Office 365:

  • Windows PowerShell for user identity and account provisioning: Provides your organization the ability to programmatically complete almost all the user management tasks in the Microsoft cloud services portal.

  • Windows PowerShell for Exchange Online: Provides the ability to complete tasks in the Exchange Management Console by using Windows PowerShell.

  • Exchange Web Services for Exchange Online: Provides the capability to complete many tasks that the Outlook client is able to do programmatically.

  • SMTP Relay: Exchange Online can be used as a Simple Mail Transfer Protocol (SMTP) delivery service to relay email messages that are sent from line-of-business applications.

  • SharePoint Web Services: Provides methods and services that are accessible through client applications such as Silverlight and ECMAScript. For more information about SharePoint web services and the SharePoint client object model, see SharePoint Online: An Overview for Developers.

For example, server-side Exchange applications are applications that use Server protocols to access the Exchange Server management tools or mailboxes, such as WebDAV, CDO, Exchange Web Services, or Server MAPI. In Office 365, only Exchange Web Services and client-side MAPI (used in Outlook) are possible protocols to access a mailbox or Exchange features, such as free/busy information.

If there are currently any applications that use protocols like WebDAV or CDO, these applications will either have to stay on an on-premises server, thereby extending the co-existence phase beyond the duration of the migration, or be replaced with an application that uses Exchange Web Services. Common server-side applications include the following:

  • Mobile device synchronization services, such as Research in Motion (RIM®) and BlackBerry® Enterprise Server

  • Inbound and outbound FAX solutions

  • Message scanning, hygiene solutions

  • Data leakage protection solutions

  • Mail routing extensions

If any of these solutions are in place, you can work with a partner to find the right replacement strategy before you begin your deployment.

For more information, see the Exchange Online Plan for Exchange Online application compatibility section of this article.

If your organization has established specific messaging or collaboration workflows, you should assess what affect your migration to Office 365 may have on those workflows. You may need to modify or re-create specific document and messaging workflows with the introduction of the Office 365 service offerings. It’s important to involve each workflow’s stakeholders in assessing what’s affected in Office 365.They can then plan and prepare for any changes during the deployment process.

Office 365 supports mailbox migration from the following environments:

  • On-premises Exchange Server environments

  • Hosted Exchange environments

  • IMAP4 servers

  • Some third-party platforms

Before you begin migrating mailboxes to Office 365, you should consider the following to help make your migration more efficient:

  • Use the Exchange Server Deployment Assistant tool to plan your migration. The Exchange Server Deployment Assistant tool has questions about your on-premises Exchange environment. Depending on your answers, it then generates very detailed, step-by-step instructions about how to deploy the coexistence infrastructure. This tool is maintained by the Exchange product group through Service Packs and documentation changes.

  • Run a pilot migration with a subset of users. Identify a limited set of users to pilot your migration process. For example, select no more than 10 percent of your production user base or up to 500 users. The pilot should help you determine your overall migration approach. The pilot group should include a representative sampling of all departments, software, and devices in your organization. Be sure that the accounts are non-critical; their mail flow and access could be affected for up to several days. Also, consider grouping pilot users into batches. This can help you correctly analyze server capability and network throughput before the deployment. This assists in root-cause analysis of server-based issues. You’ll also need to create a process for how you’ll handle adding, removing, and changing users during the migration and validate / evolve this process during the pilot.

  • Identify helpful tools that can help you with the migration process. Understand all the features of the tools., Ensure that all the tools are functioning properly before the migration. Make sure that all appropriate components are in place for your third-party migration tools.

    NoteNote:
    We recommend the Exchange Web Services protocol for mail migration to Office 365. It generally performs better than MAPI. This is important because many third-party vendors don’t support Exchange Web Services, which is preferred for cloud migration performance.
  • Reduce mailbox sizes to speed up migrations. There are specific tasks you can ask your users to perform prior to the deployment that help reduce the time it takes to migrate their mailboxes.

  • Decide how best to support legacy mail systems, if you plan to set up email coexistence for a long period of time.

    Understand message-size limits and how they are affected during migration. For more information, see Exchange Online Service Description. Clean up and perform maintenance on source mail system. Mailboxes that are corrupted affect migration performance.

    Understand migration performance and the factors that affect it. Review the Factors that affect Exchange Online migration performance section of the deployment guide to better understand the issues that affect a migration to Office 365. The guide also presents best practices for improving migration performance.

For organizations that will have a large number of Office 365 users, migration of user mailboxes to Office 365 must occur over an extended period with selected groups of users migrated at different times. You need to create these migration groups. The guiding rule is to create them so that migration has the least impact on users.

When creating your groups, be aware that Office 365 supports migration of delegates. We recommend that mailbox migration of delegates and managers occurs at the same time. For example, the mailboxes for an executive and their administrative assistant should be migrated together. Mailboxes and any delegates must be located on the same Exchange Server infrastructure (both of them with Office 365 or with on-premises Exchange Server) for the highest fidelity and best end-user experience.

For more information, see Prepare groups of users for migration to Office 365.

When you deploy SSO, all users with mailboxes in the cloud use their existing on-premises Active Directory credentials to access both cloud and on-premises resources.

You can do this by installing an AD FS 2.0 server or servers in your on-premises organization. The AD FS 2.0 server federates to the Office 365 service in the cloud to provide delegated access for your on-premises identities to specific Office 365 and Exchange Online resources in your cloud-based domain namespace.

The advantage of SSO is that users don’t need to learn a new credential management scheme. In addition to the user benefits, there are many benefits for administrators:

  • Policy control: The administrator can control account policies through Active Directory, which gives the administrator the ability to manage password policies, workstation restrictions, lock-out controls, and more, without having to perform additional tasks in the cloud.

  • Access control: The administrator can restrict access to Office 365 so that the services can be accessed through the corporate environment, through online servers, or both.

  • Reduced support calls: Forgotten passwords are a common source of support calls in all companies. If users have fewer passwords to remember, they are less likely to forget them.

  • Security: User identities and information are protected because all the servers and services used in SSO are mastered and controlled on-premises.

  • Support for strong authentication: You can use strong authentication, also called two-factor authentication, with Office 365. However, if you use strong authentication, you must use SSO.

Before you deploy SSO in a hybrid environment, review the following requirements:

  • SSO with AD FS 2.0 requires on-premises Active Directory.

  • SSO requires that you install and run the Azure Active Directory Sync tool.

    See Directory Sync tool installation instructions for more information.

  • If you plan to migrate all mailboxes to the cloud and set up SSO, you can’t deploy AD FS 2.0 or directory synchronization before you run a cutover Exchange Server migration in the Exchange Control Panel. You can, however, run a staged Exchange Server migration after you deploy AD FS 2.0 and directory synchronization.

When configuring a hybrid deployment, you must configure certificates. You must purchase certificates from a trusted third-party certificate authentication. Many services, such as AD FS 2.0, Exchange Server 2010 federation, Exchange Server 2010 services, and Exchange Server, each require certificates. Depending on your organization, you may decide to do one of the following:

  • Use a third-party certificate that's used by all services across multiple servers.

  • Use a third-party certificate for each server that provides services.

Choosing to use the same certificate for all services or to dedicate a certificate for each service depends on your organization and the service you're implementing. Here are some things to consider about each option:

  • Third-party certificate across multiple servers: Third-party certificates that are used by services across multiple servers may be slightly less expensive to obtain, but they may complicate renewal and replacement. You need to replace the certificate on every server where that certificate is installed.

  • Third-party certificate for each server: Using a dedicated certificate for each server that hosts services allows you to configure the certificate specifically for the services on that server. If you need to replace the certificate or renew it, you only need to replace it on the server where the services are installed. Other servers aren't affected.

We recommend that you use a dedicated third-party certificate for the AD FS 2.0 server, another certificate for the Exchange services on your hybrid servers, and if needed, a certificate on your Exchange server. The on-premises federated trust configured as part of federated delegation uses a self-signed certificate by default. Unless you have specific requirements, there's no need to use a third-party certificate with the federation trust configured as part of federated delegation.

The services that are installed on a single server may require that you configure multiple fully qualified domain names (FQDNs) for the server. Purchase a certificate that allows for the required number of FQDNs. Certificates consistent of the subject (or principal), name, and one or more subject alternative names (SANs). The subject name is the FQDN that the certificate is issued to. SANs are additional FQDNs that can be added to a certificate in addition to the subject name. If you need a certificate to support five FQDNs, purchase a certificate that allows for five domains to be added to the certificate—one subject name and four SANs.

If you are using multiple primary SMTP domains like contoso.com, fabrikam.com, and so on, and plan on using hybrid coexistence, you have to create SAN records for each of the domain’s Autodiscover record on the certificate for the hybrid coexistence server. Otherwise the hybrid setup wizard, free-busy lookup, and calendar sharing doesn’t work between the domains.

For more information, see Prepare for single sign-on with Office 365.

Support preparation and end user training is an extremely important part of any migration project as it directly impacts your end user satisfaction and the success of the project. Training of the help desk staff and your end users should therefore be part of your Office 365 planning from the beginning. As you pilot and configure the service, critical information such as common support issues and client configuration steps should be captured. Input from your support staff will also shape your migration processes.

When planning how you want to train your users and support desk staff, you should consider the following items:

  • Have you changed and amended your provisioning or de-provisioning processes to accommodate the common provisioning scenarios in your company? Here are some examples:

    • Creating user accounts and assigning licenses when new employees join the company.

    • Disabling user accounts when employees take an extended leave of absences.

    • Retaining employee data for more than 30 days when an employee leaves the company.

    • Changing a user’s name, phone number, or department.

    • Updating user license information for existing employees when you change their subscription type, such as updating licensing information or adding services to an existing user account.

  • Are users familiar with the Office client applications? Do you need to provide training for this?

  • Do you plan to train users on how to access the Office 365 portal and web browser versions of the applications such as Outlook Web App?

  • How do you plan to train your service desk on the service features?

  • How will the administration of Office 365 be integrated into your current help desk and administration processes? For example, password changes, user account provisioning, and de-provisioning.

  • Who will be responsible for documenting training instructions for the end users? Capturing screen shots and configuration steps during the pilot will reveal things specific to your environment and add value to your documentation.

  • What communications will you be sending to your users before, during, and after migration to the service?

  • Posters, quick-start guides, and cube notes are commonly used to raise awareness and advertise how the service will benefit users. Generating excitement makes it easy to recruit expert users that will be willing to help others.

Exchange Online doesn’t support customer usage scenarios of public folders. If you are using Exchange public folders, there are special considerations for migrating to Office 365. This document about how to Migrate from Exchange Public Folders to Microsoft Office 365 outlines these considerations, discusses the most common public folder scenarios, how they are represented in Office 365 services, and some guidance on how to handle and approach a replacement. This document also provides the information you need to decide whether Office 365 is a good match for you, based on your current public folder usage. It’s important that all public folders are remediated and migrated to a different solution before migration starts. It’s not possible to easily provide full-featured public folder access to a user that has already been migrated to the cloud.

The most common public folder scenarios that are usually used in organizations and require replacements prior to migrating to Office 365 are:

  • Data archiving

  • Sharing contacts and calendars information

 
Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft