Plan for Office 365 Workload Deployment
Plan Office 365 Applications Deployment
The course is part of this learning path
This Planning Office 365 Workloads and Applications course will teach you how to plan for Office 365 workload deployments and hybrid solutions. You will learn how to identify hybrid requirements for Exchange and SharePoint hybrid solutions, and how to plan connectivity and data flow for Office 365 services, including Exchange Online, SharePoint Online, and Teams. You’ll learn how to plan migration strategies for Exchange, SharePoint, and Teams, and how to determine the best strategies.
Later in the course, you will learn how to plan Office 365 application deployments and how to plan application updates. You’ll also learn about the different update channels and when to use each.
- How to plan for Office 365 workload deployments
- How to plan for migrations and hybrid solutions
- How to plan for Office 365 application deployments
- IT professionals who are interested in obtaining an Microsoft 365 certification
- Those tasked with planning Office 365 deployments and migrations
- A decent understanding of Office 365 workloads, including Exchange Online, SharePoint Online, and Teams
On your screen you can see what a typical cutover migration looks like. Essentially it's broken up into three pillars, so to speak. You'll have administrator tasks that have to be performed in exchange server on prem, you'll have administrator tasks that have to happen in Office 365, and then you'll have administrator tasks that have to happen in the domain registrar.
The on prem tasks include communicating with changes to end users, preparing on prem servers, and later on, decommissioning exchange servers if necessary. The administrator tasks that happen in Office 365 and in the domain registrar, include verifying your email domain with your registrar, creating empty mail enabled security groups in Office 365, connecting Office 365 to your email system, migrating mailboxes, verifying the migration, and then in the domain registrar, you would begin configuring email routing to Office 365 via MX changes. You would then verify email routing in your Office 365 environment, and then delete the cutover migration batches that you created during the migration. Of course you'd have to complete post-migration tasks, and then send a welcome letter to your users congratulating them that they've been migrated to Office 365.
What you see on your screen here is what a typical staged migration would look like. Again, you have tasks that need to be completed on prem, in Office 365, and in your domain registrar. You can see here that you would typically run synchronization on prem to get your users into Office 365, you would then create a CSV file that lists the users that are going to be migrated, you'd run the stage migration batch, check the migration reports, make sure all email, contacts, and counter items are migrated, you then convert mailboxes as necessary, confirm users in your initial batch can connect to exchange online, and then begin the process of migrating additional batches of users. You'd continue to run stage migration batches for those additional users, and resolve any issues that occur during those migrations. As migration batches complete successfully, you delete those migration batches. You then confirm that all users can connect to exchange online from Outlook, perform any post migration tasks in the Office 365 tenant, and then do the same thing in the on prem environment.
The IMAP migration table here shows you what a typical IMAP migration would look like. You can see here the tasks are broken up into tasks that need to be completed in the IMAP email system, tasks that need to be completed in Office 365, and then tasks that need to be completed with the domain registrar. Generally speaking what you would do with an IMAP migration, is add users to your Office 365 tenant, and assign them their licenses. You'd then prepare the IMAP email server, and get whatever information you need to access the IMAP mailboxes. You'd let your users know that this migration is coming, and then you'd set up admin credentials or reset user passwords, so you can access their mailboxes. Once you have access to the mailboxes via IMAP, you'd create a list of mailboxes that you wanna migrate, you'd use a CSV file to do this. You'd then connect Office 365 to your current IMAP email system, and then you'd migrate mailboxes verifying the migration. Once you've completed the migrations, you optimize any email settings that are required, and then you configure your domain to begin routing email to Office 365 by changing your MX records in your domain registrar. At this point, you'd verify routing of email, and then you'd stop synchronizing your IMAP users to Office 365. At this point you could send a welcome letter to your users, informing them that the migration is complete. I know, it sounds easy, right?
Now what you see on your screen here is a diagram of what a typical exchange hybrid looks like. Essentially the way this works is that you synchronize your on prem active directory users into Office 365 or Azure active directory. Once your users are synchronized into Azure active directory, and by extension Office 365, you would deploy and run the hybrid configuration wizard, and establish connectivity between your on prem environment and Office 365, or Exchange Online. With that connectivity in place, you could then move mailboxes from the on prem environment to Office 365 via the normal exchange admin center that you're so used to. And you could also move those users back to the on prem environment from Office 365 if necessary. Once the hybrid's in place, if you plan to use it for a migration, you'd simply move all of your user's mailboxes to Office 365, and then from there you'd manage your users.
So now that you know about the high level differences between the different migration strategies, let's talk about those strategies and how they relate to different versions of Exchange, or different versions of email systems in general.
About the Author
Tom is a 25+ year veteran of the IT industry, having worked in environments as large as 40k seats and as small as 50 seats. Throughout the course of a long an interesting career, he has built an in-depth skillset that spans numerous IT disciplines. Tom has designed and architected small, large, and global IT solutions.
In addition to the Cloud Platform and Infrastructure MCSE certification, Tom also carries several other Microsoft certifications. His ability to see things from a strategic perspective allows Tom to architect solutions that closely align with business needs.
In his spare time, Tom enjoys camping, fishing, and playing poker.