Deploying Office 365 in Production: Part 2

Deploying Office 365 in Production: Part 2
Microsoft Office365 9/15/2018 Deploying Office 365 in Production: Part 2 October 2013 © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Session Overview

Session Overview This session details the steps and actions required when expanding a pilot Office 365 environment into a production deployment. Unlike on-premises implementations, IT professionals can scale out their Office 365 tenants with ease. However, with added scale, it is important to start to automate user provisioning, add a production domain and set up the desired workloads.

Your onboarding path

Optimized path Exchange 2007 Pilot
Source Pilot Deploy Enhance Cloud ID PST Connected account Self service Migration PST import tool IMAP migration Admin Driven Pilot users use the service in about an hour Start with a clean mailbox or with their own data

Optimized path Exchange 2007 Deploy Cloud identity
Source Pilot Deploy Enhance Self service PST Migration Shared namespace PST import tool IMAP migration Admin driven Deploy quickly using cloud identity Option to expedite with use of a new or shared namespace with limited GAL

Optimized path Exchange 2007 Deploy Synchronized identity
Source Pilot Deploy Enhance Shared namespace Synchronized ID with password sync Admin driven Staged migration Migration Use the service within days post migration of mail data with full GAL

Source Pilot Deploy Enhance Enhance Admin driven Hybrid migration Hybrid servers Migration Use the service within weeks post-introduction of hybrid servers Complete GAL availability

Source Pilot Deploy Enhance Federated ID Self Service Migration Staged migration Admin driven Hybrid migration Users can start using the service within weeks post-introduction of hybrid servers, full GAL, and SSO post-data move

Optimized path Exchange 2007 Recap
Pilot service in about an hour Deployment options to meet your requirements Leverage staged migration for IT led migration Optionally enhance service over time Decision points Identity type Namespace Migration and coexistence approach Authentication requirements

Optimized path Exchange 2010 Pilot
Source Pilot Deploy Enhance Cloud ID PST Connected account Self service Migration PST import tool IMAP migration Admin Driven Pilot users use the service in about an hour Start with a clean mailbox or with their own data

Optimized path Exchange 2010 Deploy Cloud identity
Source Pilot Deploy Enhance PST import tool IMAP migration Admin driven Shared namespace Migration Users can start using the service within hours to days post-data migration depending on requirements of new or shared namespace with limited GAL

Source Pilot Deploy Enhance Shared namespace Self service Migration Synchronized ID with password sync Admin driven Hybrid migration Users can start using the service within days post-introduction of SP3 or later with Hybrid Configuration Wizard (HCW), full GAL, post-data move

Optimized path Exchange 2010 Enhance Synchronized identity
Source Pilot Deploy Enhance Enhance Federated ID Self service Migration Admin driven Hybrid migration Users can start using the service within days post-introduction of SP3 or later with HCW, full GAL, and introduction of SSO, post-data move

Optimized path Exchange 2010 Recap
Pilot service in about an hour Deployment options to meet your requirements Leverage hybrid Exchange for IT led migration Optionally enhance service over time Decision points Identity type Namespace Migration and coexistence approach Hybrid use Authentication requirements

Convert Pilot to Paid Subscription

Introducing production licenses
Purchasing directly in the Admin Portal Activation - Purchasing via Volume Licensing New Online Services Customers Office 365 Trial Customers

Activation Email – Sign In vs Sign Up Options
New Online Services Customer When a new online services customer purchases Office 365 for Enterprises via their Enterprise Agreement (EA), and has never participated in an Office 365 Trial, they should use the Sign Up option from the link in the activation . Office 365 Trial Customer If a trial customer choses to retain their Office 365 trial data, settings, and their existing onmicrosoft.com domain during their transition from trial to a paid subscription, they will need to choose Sign In. Choosing this option will allow the customer to transition their trial subscription over to the licensed production subscription.

Activation- Step-by-step (New Online Service)
Customer clicks “Sign Up” via activation Customer creates and activates a new account profile Customer adds New Online Service ID Customer receives acknowledgment

Activation- Step-by-step (O365 Trial)
Microsoft or Partner enters VL order Customer clicks “Sign In” on activation Customer signs in & provides existing account subscription info Customer receives provisioning confirmation

Setup your Vanity Domain

Add and Verify a Domain Logon to the Portal Select domains
Select Add Domain Start Step 1 and specify domain name Select preferred instructions Add verification DNS record Verify domain Complete domain configuration Walkthrough of adding a Managed Domain using the Microsoft Online Portal

Key Deployment Considerations

Verify domains Add all SMTP domains as verified domains before synchronizing Cannot be removed until all synchronized objects are no longer using the domain as a proxy address or UPN Plan UPN suffix Verify on-premises user objects have a value (not null) for UPN suffix and that it is correct The default routing domain (e.g. contoso.onmicrosoft.com) is used for Office 365 UPN suffix if the on-premises UPN suffix does not contain a verified + public routable DNS domain (e.g. cannot use *.local) Note: we recommend SMTP == UPN

Complete Active Directory cleanup work before implementing DirSync -> consider using ID Fix Especially if importing data from a 3rd party LDAP directory into Active Directory Enable Dirsync ahead of deploying it on-premises Plan ahead for DirSync quota increase Could become a deployment blocker. Don’t wait until 11th hour to request. Enable Directory Synchronization ahead of DirSync server deployment (activation can take up to 24 hours to complete) Unless you don’t want to use DirSync at all Understand how “soft match” works Consider Exchange schema extensions for non-Exchange AD environments ID Fix : (current version 1.05)

Installing and Configuring DirSync

Prepare and Download DirSync
In MOP, select users and groups | DirSync Set up Activate Directory Synchronization (can take up to 24h to propagate) Form DirSync server Download DirSync Logon to the Portal Select Users and groups and then activate DirSync Select Users and Groups and click Set up Active Directory synchronization Activate Directory Synchronization Wait (up to 24 hours) for Dirsync enablement Review all documentation, follow the implementation steps, and download DirSync Walkthrough of adding a Managed Domain using the Microsoft Online Portal

Install DirSync Logon to DirSync server and run setup
Follow setup wizard When finished, option to start the configuration wizard Walkthrough of the simple 5-step DirSync setup wizard Must be admin on the local machine to install DirSync Default setup installs DirSync code along with FIM engine and SQL Express 2008

Configure DirSync Run configuration wizard Provide O365admin creds
Provide AD admin creds If Exchange hybrid, configure “write-back” Password sync option Create configuration When finished, option to run synchronization Walkthrough of the simple 6-step DirSync configuration wizard Must provide credentials – enterprise admin credentials for local AD, global or user admin credentials for O365 tenant Enterprise admin creds does not became service account and is not used in any way during ongoing DirSync operation Tenant creds used by DirSync cannot be a federated account Tenant creds are used during ongoing DirSync operation; thus, may want to configure with non-expiring password

Start Moving the Rest of your Users

IMAP Migration

IMAP Migration Prepare for IMAP Migration
Create a CSVs for IMAP Migration Create IMAP Migration Endpoint Create IMAP Migration Batch Start IMAP Migration Batch Configure MX Record Pointing to Office 365 Delete IMAP Migration Batches Slide Objectives: IMAP migration process Talking Points: Here the big difference that we can repeat the 2 orange steps until all users are migrated, then change MX record. And the users can be migrated in groups – not all-at-once like at cutover migration. More Information:

IMAP Migration Process
Prepare for IMAP Migration Configure IMAP server to accept connections from Office 365 (port TCP/143 or TCP/993) Add and verify domain in Office 365 Create users and mailboxes in Office > Manual/Bulk/DirSync Best practices Reconfigure MX record TTL to 15 mins Create a dedicated migration admin user Add permissions to the migration admin If not possible: collect user passwords Slide Objectives: Articulate the differences when preparing IMAP migration Talking Points: In an IMAP migration the Cloud will connect to the on-premise server using IMAP connection. Hence you need to make sure MS cloud can connecto to your server. This might need some firewall adjustments, especially if your IMAP server was not visible from outside previously. Imap can work without encryption; however highly recommended to publish and use the secure IMAP port (TCP/993). This migration will not create the user accounts automatically, you need to take care of this task. You may add the users manually (one-by-one) or import them from a CSV file, or use DirSync. Whatever method is used, you should add your domain previously. From the best practices session I want to highlight the question of the user passwords. If your server can be configured to use only one dedicated account to download the s, then you can use a dedicated migration admin account. If this is not possible – for example you are using a hosted IMAP server and you don’t have administrative access to that server – then you need to collect the user passwords. More Information:

IMAP Migration Process
Create IMAP Migration Batch Start IMAP Migration Batch User list is defined in CSV files Multiple migration batches CSV file limits: 50,000 rows, max 10 MB Best practices Keep CSV files at secure location Newly arriving s land where MX record points to - no redirection Client software reconfiguration (pointing to ExO) Slide Objectives: Explain the usage of CSV files Talking Points: IMAP migration can be done in batches. You might test the migration with a small amount of test users, and then continue with the 1st group of production users, and so on. The CSV files contain the address of the target mailbox, the user account used to logon to the IMAP server and the password. Although the CSV file can contain up to user names, the best practice is moving the users in smaller (and more controllable) groups. As best practice please keep these CSV files at a secure location as it contains user paswords. As previously this initial sync can be started anytime – it won’t affect the users. We will perform incremental syncs too which will replicate the newly arrived s too. The big switch happens when you redirect the MX record to O365; and instruct the users to logon to O365.

Demo IMAP Migration

Staged Migration

Staged Migration Process
Prepare for Staged Migration Create a CSV File for Staged Migration Batch Create Migration End-Point Create a Staged Migration Batch Start a Staged Migration Batch Convert On-Premise Mailboxes to Mail-Enabled Users Delete Staged Migration Batch Complete Post-Migration Tasks Slide Objectives: Staged migration process flow. Talking Points: The orange steps can be repeated here – users can be migrated in groups. Staged migration can be a longer project – it can last even for a couple of months. More Information:

Prepare for Staged Migration Add and verify domain in Office 365 Implement DirSync DirSync will create mail-enabled accounts Available in M or E plans (or Exchange Online plan) Configure Outlook Anywhere Exchange 2003 and 2007 is supported Best practices You can optionally deactivate DirSync after migration Use Hybrid for Exchange 2010 and 2013 Slide Objectives: Explaing the preparation tasks for a staged migration Talking Points: When preparing a staged migration we will start again be adding the domain to the O365 and verifying it. The staged migration needs DirSync so we also need to enable and implement DirSync as it will create the user objects in O365 based on the on-premise users in your AD. Let me add here a comment that after the migration you can deactivate DirSync if you want. Or you keep it running – it’s your choice. The reason why we must do this: DirSync will make changes on the migrated user accounts in the on-premise AD during the migration. We will use Outlook Anywhere, so RPC over HTTPS should be configured the very same way as in a cutover scenario. If it was already implemented then we don’t have to do anything here. Please note that staged migration is supported with Exchange 2003 and 2007 – for newer Exchange versions you need to implement a hybrid deployment, or a cutover migration. More Information:

Create a CSV File for Staged Migration Batch Create Migration End-Point Multiple batches - defined in CSV files Create a migration admin account Create the migration endpoint in Office 365 Test endpoint using ExRCA Best practices Move the workgroups together Cross-premise sharing is not available (Delegates, shared calendars, rooms) Each CSV file can contain max.1,000 users Slide Objectives: Explain how we define the migration groups Talking Points: In a staged migration we move the users in groups (called batches). These are defined by CSV files. As previously we need to create a migration administrator account which is capable to read out data from the user mailboxes. When we define the migration endpoint on the Exchange Online portal, this account need to be defined, along with the server name and the number of simultaneous mailbox moves. As best practice we migrate the workgroups together to minimize the chances of a cross-premise sharing situation. This happens for example when the boss and his assistant is moved in separate batches. This would break the delegate access to the mailbox. More Information:

Start a Staged Migration Batch Start the batch by uploading CSV file Best practices Users start with empty mailboxes filling in Example scenario: Start the migration at 18:00 Mailboxes will be synced during the night Reconfigure Outlook profiles Allow Outlook sync during the night Slide Objectives: Explain how a batch will work Talking Points: After you defined/created a batch by uploading the CSV you can automatically or manually start the batch. (Also suspend/continue options are available) As soon you start the batch a user will have a new mailbox, and replication will happen later – we need some time until the mailbox fills up. When users create new outlook profile, they _might_ se an empty mailbox (if they are too quick) My best practice: Migration at night Migration at weekends You can see here an example for a nightly migration – one night should be enough to migrate GB = mailboxes depending on the mailbox size. More Information: In owerall this is nearly the same as with cutover. We need to touch the user’s workstations to configure the new Outlook profile.

Convert On-Premise Mailboxes to Mail-Enabled Users Simple Coexistence s still arrive On-Premise Forwarded if mailbox is migrated Office 365: mail-enabled users converted to mailboxes On-Premise: DirSync set the targetAddress property Best practices Check if sync was finished without errors Convert the on-premises mailboxes of the migrated users to mail-enabled users Slide Objectives: Explain how the incoming s find the right mailbox Talking Points: This is a big change compared to cutover and IMAP. Here we have no replication process. All s will still arrive onpremise (MX points there) and we will forward these to the cloud if the recipient is hosted there. Before the batch was started, the User in Cloud created by DirSync was mail enabled only. When we start the batch, the mailbox will be created for the O365 user, and in the on-prem AD the DirSync will set the TargetAddress parameter. This will be responsible for the redirection. (You can see it even from the Exchange management console) After the batch was finished, the best practice is to convert the on-prem user(mailbox) to mail-enabled user > so Outlook will autodiscover his cloud mailbox and connect to it. More Information: After a migration batch has finished running and you’ve verified that all mailboxes in the batch are successfully migrated and the initial synchronization of mailbox items to Exchange Online is complete, it’s recommended that you convert the on-premises mailboxes in the migration batch to mail-enabled users. Why? After a staged Exchange migration, a user has an on-premises mailbox and an Exchange Online mailbox. Because mail sent to the user’s on-premises mailbox is forwarded to their Exchange Online mailbox after migration, users need to connect to their Exchange Online mailboxes to access their . But if a person uses Outlook to open their mailbox, the Autodiscover service still tries to connect to the on-premises mailbox. After you convert on-premises mailboxes to mail-enabled users, the Autodiscover service uses a mail-enabled user to connect Outlook to the Exchange Online mailbox after the user creates a new Outlook profile. Another important reason to convert on-premises mailboxes to mail-enabled users is to retain proxy addresses from the Exchange Online mailboxes by copying proxy addresses to the mail-enabled users. This lets you manage cloud-based users from your on-premises organization by using Active Directory. Also, if you decide to decommission your on-premises Exchange organization after all mailboxes are migrated to Exchange Online, the proxy addresses you’ve copied to the mail-enabled users will remain in your on-premises Active Directory. More details about converting MBX to MEU and scripts: Exchange 2003: Exchange 2007:

Delete Staged Migration Batch No need for incremental sync Outlook will rebuild the OST cache Best practices Instruct users to use Office 365 mailbox Cross-premise sharing is not allowed Slide Objectives: Finishing steps for migrating a user group Talking Points: There is no incremental sync – see the previous slide. Outlook will rebuild the OST cache – just like in previous migrations. Also you need to distribute the passwords for the users. (download the report from the sent by O365 about the migration) Users should not use the on-prem mailbox, because newly sent s are not replicated up again after the sync was done! Migrate workgroups together – a cloud user is not able to share his calendar with an on-prem user. More Information:

Complete Post-Migration Tasks Reconfigure MX record Decommission on-premises Exchange* Assign licenses to Office 365 users Best practices Staged migration is not a long-term solution Migration can span up to some months Slide Objectives: Finishing steps after all users are migrated Talking Points: MX record will point to O365 as well as the autodiscover. Uninstall the on-premise exchange (and do a backup before!) You can keep it running for a longer period if you want, but no one will use it, neither s will be sent through. DirSync can be deactivated after the sync – users will be managed in O365 if you do so. Hybrid infrastructure is the long term solution (Exchange 2010 and 2013) More Information:

Demo Staged Migration Demo IMAP migration

Deploy Office 365 Pro Plus

Two ways to deploy (A) Have users install Office directly from the Office 365 portal (B) Download the Office software to your local network and then deploy Office to your users See for more information on IT Admin tools for click-to-run configuration

Which way to deploy? Are users local admins on their computers?
If not, can’t use the portal Download/on-premises option gives more control: Where on the network Office is installed from How Office is updated after it is installed Which computers Office is installed on Which users, if any, get the 64-bit edition of Office Which languages are available to install Portal = less administrative setup, more self-service, less control Additional resources on Pro Plus admin lead configuration:

Setup Devices

Mobile Device Configuration
Phone and tablet applications and configuration From the Office 365 admin portal :

Questions?

9/15/2018 © 2013 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION. © 2012 Microsoft Corporation. All rights reserved. Microsoft, Windows, and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.

Additional resources Office 365 troubleshooter: /en- us/tools/troubleshooting.aspx

Deploying Office 365 in Production: Part 2

Similar presentations

Presentation on theme: "Deploying Office 365 in Production: Part 2"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Deploying Office 365 in Production: Part 2

Similar presentations

Presentation on theme: "Deploying Office 365 in Production: Part 2"— Presentation transcript:

Similar presentations

About project

Feedback