Plan a Microsoft 365 Implementation
Plan Migration of Users and Data
The course is part of these learning paths
Microsoft 365 represents a combination of Office 365, Windows 10 and Enterprise Mobility offerings – providing the most complete set of SaaS technologies that Microsoft has to offer. With Microsoft 365, organizations can deploy a complete solution encompassing both devices and applications, along with applying security and compliance policies to protect the entire suite.
This course will help you as you plan your migration of users and data to Microsoft 365, including planning your identity and authentication solution, and the on-premises infrastructure needed to support your migration. We’ll also help you understand and identify your business requirements and use cases, to help drive your decision-making process when planning to transition your infrastructure to the Microsoft cloud. We’ll spend some time focusing on networking and discuss some of the networking decisions that need to be made to ensure an optimal migration experience, as well as the best experience for your users after migration.
This course will also help you to identify which data needs to be migrated to the cloud, and what the best migration method will be based on your scenario – we’re also going to cover the different types of user identities, how your users will authenticate, and how that’s going to affect your migration planning.
In addition to talking about these different components, we’re also going to run through a few demos – showing you some of the practical steps involved, along with some tips and tricks we’ve picked up along the way.
By the end of this course, you should be able to:
- Plan a Microsoft 365 Implementation, including the supporting infrastructure
- Plan your identity and authentication solution, both on-premises and in the cloud
- Identify your users, data, and mailboxes to be migrated to Microsoft 365
- Plan the migration of your groups and user data to Microsoft 365
This course is intended for people who:
- Want to become a Microsoft 365 administrator
- Are preparing to take the Microsoft’s MS-100 exam
To get the most from this course, you should have a general understanding of networking & server administration as well as IT fundamentals such as DNS, Active Directory and PowerShell.
The identity type that you choose is ultimately going to determine the authentication method you use to log into Microsoft 365, and the infrastructure required to support it. Cloud authentication is where your users log in and authenticate directly against Microsoft services in Office 365. This is the default behavior for both cloud identities and synchronized identities.
Cloud identities, of course, have no on-premises servers, so there's nothing required for either identity or authentication. Synchronized identities do require a server for a synchronization as we've mentioned already. But that DirSync server does not by default also provide authentication. When you configure AAD Connect with default settings, all your authentication also happens in the cloud. Even when AAD Connect is providing seamless SSO, that authentication is still happening as Microsoft services and not your AAD Connect server. That's the primary different between managed and federated identities.
Managed or synchronized identities authenticate in the cloud and federated back on premises. AAD Connect with pass-through authentication changes your authentication flow to come back to the PTA agents installed on your server. When a user types in a username and password in the Office 365 Portal, that authentication is passed back to your domain controllers on premises, which authenticates the user or not, and passes the response back to Office 365 as a token. Once Office 365 receives this token, the user's logged in as normal and continues to their email or whatever they've logged into. Note that having PTA configured means that you need to ensure that your PTA agents are highly available. If your servers are down, your users will not be able to log into Office 365. So you need to make sure that you consider this when planning out your authentication type. Like PTA, authentication for federated users will go through your ADFS servers, and your users will authenticate against your domain controllers.
With a federated sign in experience, as soon as a user types their user name into the Office 365 portal, they'll be redirected to your ADFS server where they'll type their passwords in and again authenticate against your on-premises infrastructure. Unlike PTA however, ADFS requires a much greater infrastructure deployment in order to be highly available and secure. ADFS typically requires at least two federation servers, two proxy servers, and your directory synchronization as well. With federated authentication, if your servers go down or you lose network connectivity, none of your users can authenticate to Office 365 services. When deploying ADFS, you'll need to ensure that you account for your business requirements and your tolerance for downtime in an outage.
If you have very little tolerance for downtime, you might need to consider stretching an ADFS farm between data centers to ensure that if one data center goes down, your users can still authenticate against the ADFS servers in a different location.
Jeremy Dahl is a Senior Technology Consultant who has spent the last 8 years focusing on Microsoft 365 technologies and has been an Office 365 MVP for the last 6 years. Jeremy is a self-proclaimed cloud addict who architects technology solutions that combine cloud technologies with on-premises solutions, allowing organizations to make the most of their existing infrastructure while still taking full advantage of the agility and scalability of what the cloud has to offer.
Jeremy can be found blogging about Microsoft 365 technologies on his website, masterandcmdr.com, and evangelizing the Microsoft cloud on Twitter.