Deployment of Microsoft 365 Enterprise with existing infrastructure

Many organizations have exisiting networking, identity, and other components or Microsoft on-premises products and cloud-based services. This article steps through each phase of the deployment of Microsoft 365 Enterprise so you can quickly determine how to adapt or change your existing infrastructure.

Before you can exit each phase, you must examine its exit criteria, which is a set of required conditions that you must meet and optional conditions to consider. Exit criteria for each phase ensures that your on-premises and cloud infrastructure and resulting end-to-end configuration meets the requirements for a Microsoft 365 Enterprise deployment.

Note

FastTrack is an ongoing and repeatable benefit—available as part of your subscription—that is delivered by Microsoft engineers to help you move to the cloud at your own pace. FastTrack also gives you access to qualified partners for additional services, as needed. With over 40,000 customers enabled to date, FastTrack helps maximize ROI, accelerate deployment, and increase adoption across your organization. See FastTrack for Microsoft 365.

Exit criteria for networking (phase 1)

Step through the following required and optional conditions for the networking infrastructure for Microsoft 365 Enterprise.

Required: Your Internet bandwidth is sufficient for Microsoft’s cloud services

The Internet bandwidth for your central office and branch offices can handle daily access to cloud resources, peak usage, and future growth. If your Internet bandwidth isn’t sufficient, the performance of your connectivity and the productivity of your staff might suffer, especially during peak periods of processing.

If needed, Step 1 can help you with this requirement.

Required: Your local offices have local Internet name resolution

You configured each local office with Internet access through a local ISP whose DNS servers use a local public IP address that identifies their location on the Internet. This ensures the best possible performance for users who access Office 365 and Intune.

If you don’t use a local ISP for each branch office, performance can suffer because network traffic must traverse an organization’s backbone or data requests are serviced by remote front-end servers.

How to test

Use a tool or web site from a device in that office to determine the public IP address that the proxy server is using. For example, use the What Is My IP Address web page. This public IP address assigned by your ISP should be geographically local. It should not be from a public IP address range for a central office or from a cloud-based network security vendor.

If needed, Step 2 can help you with this requirement.

Optional: Your network perimeter devices perform minimal processing of Office 365 traffic

You configured your network perimeter devices—such as proxy servers, firewalls, and SSL inspection devices— to use Office 365 endpoints (URLs and IP address ranges) and to minimally process traffic from Office 365.

If you haven’t done this, your perimeter devices perform unnecessary processing and Office 365 performance will suffer, causing delays for users of cloud-based services.

How to test

Use the logging tools on your network perimeter devices to ensure that traffic to Office 365 destinations isn’t being inspected, decrypted, or otherwise hindered.

If needed, Step 3 can help you with this option.

Optional: A plan to manage ongoing changes in Office 365 endpoints is in place

Your IT department has a plan to update endpoints—both URLs to Office 365 services and IP address ranges—for your network perimeter devices that perform minimal processing traffic to and from Office 365.

If you don’t have a plan in place, connectivity can be interrupted when IP addresses are moved from one service to another or are no longer in use by a service. Additionally, traffic to new servers of an exisiting service that aren’t configured as new endpoints can cause your traffic to be sent to a distant front-end server, resulting in non-optimal performance.

If needed, Step 4 can help you with this option.

Optional: Your clients and Office 365 applications are configured for optimal performance

You have optimized the Transmssion Control Protocol (TCP) settings on your client devices and for Exchange Online, Skype for Business Online, SharePoint Online, and Project Online services.

If needed, Step 5 can help you with this option.

Exit criteria for identity (phase 2)

Step through the following required and optional conditions for the identity infrastructure for Microsoft 365 Enterprise.

Also see Prerequisites for additional recommendations on identity infrastructure.

Required: All users, groups, and group memberships have been created

You've created user accounts and groups so that:

  • Employees in your organization and the vendors, contractors, and partners that work for or with your organization have a corresponding user account in Azure Active Directory (AD).
  • Azure AD groups and their members contain user accounts and other groups for various purposes, such as the provisioning of security settings for Microsoft cloud services, automatic licensing, and other uses.

If needed, Step 1 can help you meet this requirement.

Required: Users and groups are synchronized with Azure AD

If you have an existing on-premises identity provider, such as Windows Server Active Directory (AD), you have used Azure AD Connect to synchronize user accounts and groups from your on-premises identity provider to your Azure AD tenant.

With directory synchronization, your users can sign in to Office 365 and other Microsoft cloud services using the same credentials that they use to sign in to their computers and access on-premises resources.

If needed, Step 2 can help you meet this requirement.

If you skip this requirement, you’ll have two sets of user accounts and groups:

  • User accounts and groups that exist in your on-premises identity provider
  • User accounts and groups that exist in your Azure AD tenant

In this state, the two sets of user accounts and groups must be manually maintained by both IT administrators and users. This will inevitably lead to unsynchronized accounts, their passwords, and groups.

How to test

To verify that authentication with on-premises credentials works correctly, sign in to the Office 365 portal with your on-premises credentials.

To verify that directory synchronization is working correctly, do the following:

  1. Create a new test group in Windows Server AD.
  2. Wait for the synchronization time.
  3. Check your Azure AD tenant to verify that the new test group name appears.

Required: Your global administrator accounts are protected

You've protected your Office 365 global administrator accounts to avoid compromising credentials that can lead to breaches of an Office 365 subscription.

If you skip this requirement, your global administrator accounts can be susceptible to attack and compromise, allowing an attacker to gain system-wide access to your data for harvesting, destruction, or ransom.

If needed, Step 5 can help you meet this requirement.

How to test

Use these steps to verify that You've protected your global administrator accounts:

  1. Run the following Azure AD V2 command at the PowerShell command prompt. You should see only the list of dedicated global administrator accounts. Get-AzureADDirectoryRole | where { $_.DisplayName -eq "Company Administrator" } | Get-AzureADDirectoryRoleMember | Ft DisplayName
  2. Sign in to Office 365 using each of the accounts from step 1. Each sign in must require multi-factor authentication and the strongest form of secondary authentication available in your organization.

Note

See Connect to Office 365 PowerShell for instructions on installing the Azure AD V2 PowerShell module and signing in to Office 365.

Optional: The Office 365 sign-in screen is personalized for your organization

You've used Add company branding to your sign-in and Access Panel pages to add your organization’s branding to the Office 365 sign-in page.

If you skip this option, your users will see a generic Office 365 sign-in screen and might not be confident that they’re signing into your organization’s site.

If needed, Step 3 can help you with this option.

How to test

Sign in to the Office 365 portal with your user account name and multi-factor authentication. You should see your custom branding elements on the sign-in page.

Optional: Multi-factor authentication is enabled for your users

You used Plan for multi-factor authentication for Office 365 Deployments and Set up multi-factor authentication for Office 365 users to enable multifactor authentication (MFA) for your user accounts.

If you skip this option, your user accounts are vulnerable to credential compromise by cyber attackers. If a user account’s password is compromised, all the resources and capabilities of the account, such as administrator roles, are available to the attacker. This allows the attacker to copy, destroy, or hold for ransom internal documents and other data.

If needed, Step 7 can help you with this option.

How to test

  1. Create a test user account in the Office 365 Admin portal and assign them a license.
  2. Configure multi-factor authentication for the test user account with the additional verification method that you are using for actual user accounts, such as sending a message to your phone.
  3. Sign in to the Office 365 or Azure portal with the test user account.
  4. Verify that MFA prompts you for the additional verification information and results in a successful authentication.
  5. Delete the test user account.

Optional: Directory synchronization is monitored

You've used Azure AD Connect Health with sync (for password synchronization) or Using Azure AD Connect Health with AD FS (for federated authentication) and have deployed Azure AD Connect Health, which involves:

  • Installing the Azure AD Connect Health agent on each of your on-premises identity servers.
  • Using the Azure AD Connect Health portal to monitor the state of the ongoing synchronization.

If you skip this option, you can more accurately assess the state of your cloud-based identity infrastructure.

If needed, Step 4 can help you with this option.

How to test

The Azure AD Connect Health portal shows the current and correct state of your on-premises identity servers and the ongoing synchronization.

Optional: Remote users have secure access

You've used the information at How to provide secure remote access to on-premises apps to deploy the Azure AD Application Proxy, which involves:

  • Configuring an instance of the Application Proxy Service in Azure to transfer web traffic between users on the Internet and a server running the Application Proxy Connector.
  • Configuring the Application Proxy Connector on an Internet-facing server to transfer web traffic between Application Proxy Service in Azure and on-premises web-based applications.

If you skip this option, your remote or roaming employees and vendors, contractor, and partners will not be able to use Azure AD Application Proxy to access on-premises, web-based applications. They must use a more traditional remote access method such as virtual private networks.

If needed, Step 16 can help you with this option.

How to test

A user can remotely access on-premises web-based applications using the Azure AD Application Proxy and their Azure AD user credentials.

Optional: Users can reset their own passwords

You've used Azure AD self-service password reset rapid deployment to configure password reset for your users.

If you don’t meet this condition, users will be dependent on user account administrators to reset their passwords, resulting in additional IT administration overhead.

If needed, Step 10 can help you with this option.

How to test

  1. Create a test user account with an initial password.
  2. Use the steps in Let users reset their own passwords in Office 365 to reset the password on the test user account.
  3. Sign out and then sign in to the test user account using the reset password.
  4. Delete the test user account.

Optional: Password writeback is enabled for your users

You've used the instructions in Azure AD SSPR with password writeback to enable password writeback for the Azure AD tenant of your Microsoft 365 Enterprise subscription.

If you skip this option, users who aren’t connected to your on-premises network must reset or unlock their Windows Server AD passwords through an IT administrator.

If needed, Step 9 can help you with this option.

Note

Password writeback is required to fully utilize Azure AD Identity Protection features, such as requiring users to change their on-premises passwords when Azure AD has detected a high risk of account compromise.

How to test

You test password writeback by changing your password in Office 365. You should be able to use your account and new password to access on-premises Windows Sever AD resources.

  1. Create a test user account in your on-premises Windows Server AD, allow directory synchronization to occur, and then grant it an Office 365 license in the Office 365 admin portal.
  2. From a remote computer that is joined to your on-premises Windows Server AD domain, sign in to the computer and the Office 365 portal using the credentials of the test user account.
  3. Select Settings > Office 365 settings > Password > Change password.
  4. Type the current password, type a new password, and then confirm it.
  5. Sign out of the Office 365 portal and the remote computer and then sign in to the computer using the test user account and its new password. This proves that you were able to change the password of an on-premises Windows Server AD user account using the Azure AD tenant.

Optional: Users can sign in using single sign-in

You enabled Azure AD Connect: Seamless Single Sign-On for your organization to simplify how users sign in to cloud-based applications, such as Office 365.

If you skip this option, your users might be prompted to provide credentials when they access additional applications that use Azure AD.

If needed, Step 8 can help you with this option.

Group-based licensing to automatically assign and remove licenses to user accounts based on group membership

You enabled group-based licensing for the appropriate Azure AD security groups so that licenses for both Office 365 and EMS are automatically assigned or removed.

If you skip this option, you must manually:

  • Assign licenses to new users whom you intend to have access to Office 365 and EMS.
  • Remove licenses from users who are no longer with your organization or do not have access to Office 365 and EMS.

If needed, Step 11 can help you with this option.

How to test

  1. Create a test security group in Azure AD with the Azure portal and configure group-based licensing to assign Office 365 and EMS licenses.
  2. Create a test user account in Azure AD and add it to the test security group.
  3. Examine the properties of the user account in the Office 365 admin portal to ensure that it was assigned the Office 365 and EMS licenses.
  4. Remove the test user account from the test security group.
  5. Examine the properties of the user account to ensure that it no longer has the Office 365 and EMS licenses assigned.
  6. Delete the test security group and the test user account.

Dynamic group membership settings automatically add user accounts to groups based on user account attributes

You've determined the set of Azure AD dynamic groups and used the instructions in Attribute-based dynamic group membership in Azure Active Directory to create the groups and the rules that determine the set of user account attributes and values for group membership.

If you skip this option, group membership must be done manually as new accounts are added or as user account attributes change over time. For example, if someone moves from the Sales department to the Accounting department, you must:

  • Update the value of the Department attribute for that user account.
  • Manually remove them from the Sales group.
  • Manually add them to the Accounting group.

If the Sales and Accounting groups were dynamic, you would only have to change the user account’s Department value.

If needed, Step 12 can help you with this option.

How to test

  1. Create a test dynamic group in Azure AD with the Azure portal and configure a rule for the Department equals “test1”.
  2. Create a test user account in Azure AD and set the Department property to “test1”.
  3. Examine the properties of the user account to ensure that it was made a member of the test dynamic group.
  4. Change the value of the Department property for the test user account to “test2”.
  5. Examine the properties of the user account to ensure that it is no longer a member of the test dynamic group.
  6. Delete the test dynamic group and the test user account.

Optional: Self-service group management is enabled for specific Azure AD security and Office 365 groups

You've determined which groups are appropriate for self-service management, instructed their owners on group management workflow and responsibilities, and set up self-service management in Azure AD for those groups.

If you skip this option, all Azure AD group management tasks must be done by IT administrators.

If needed, Step 14 can help you with this option.

How to test

  1. Create a test user account in Azure AD with the Azure portal.
  2. Sign-in as with the test user account and create a test Azure AD security group.
  3. Sign out and then sign-in with your IT administrator account.
  4. Configure the test security group for self-service management for the test user account.
  5. Sign out and then sign-in with your test user account.
  6. Use the Azure portal to add members to the test security group.
  7. Delete the test security group and the test user account.

Optional: You've enabled Azure AD Identity Protection to protect against credential compromise

You've enabled Azure AD Identity Protection to:

  • Address potential identity vulnerabilities.
  • Detect possible credential compromise attempts.
  • Investigate and address ongoing suspicious identity incidents.

If you skip this option, you won’t be able to detect or automatically thwart credential compromise attempts or investigate identity-related security incidents. This potentially leaves your organization vulnerable to a successful credential compromise and the resulting threat to your organization’s sensitive data.

If needed, Step 15 can help you with this option.

Optional: You've set up Privileged Identity Management to support on-demand assignment of the global administrator role

You've used the instructions in Configure Azure AD Privileged Identity Management to enable PIM in your Azure AD tenant and configured your global administrator accounts as eligible admins.

You've also used the recommendations in Securing privileged access for hybrid and cloud deployments in Azure AD to develop a roadmap that secures privileged access against cyber attackers.

If you skip this option, your global administrator accounts are subject to ongoing online attack and, if compromised, can allow an attacker to harvest, destroy, or hold your sensitive information for ransom.

If needed, Step 6 can help you with this option.

Exit criteria for Office 365 ProPlus (phase 4)

Step through the following required and optional conditions for the Office 365 ProPlus infrastructure for Microsoft 365 Enterprise.

Assessment of infrastructure and environment is complete, including:

  • Client device details
  • Deployment tools
  • Office 365 licensing and accounts
  • Network capability
  • Application compatibility

Deployment plan is complete, including:

  • How to deploy Office 365 ProPlus
  • How to manage updates to Office 365 ProPlus
  • Whether to deploy and install from a local source on your network or from the cloud
  • Which client devices get which update channels
  • Installation packages defined
  • All client devices assigned to deployment groups
  • Which Office applications, architectures, and languages go to which client devices

Deployment of Office 365 ProPlus is complete, including:

  • All client devices have Office 365 ProPlus installed
  • All client devices are in the appropriate update channel and are receiving updates
  • All client devices have the appropriate languages installed or available

Exit criteria for information protection (phase 6)

Step through the following required and optional conditions for the information protection infrastructure for Microsoft 365 Enterprise.

Required: Security and information protection levels for your organization are defined

You've planned for and determined the security levels that your organization needs. These levels define a minimum level of security and additional levels for increasingly sensitive information and their required data security.

At a minimum, you are using three levels of information protection:

  • Baseline
  • Sensitive
  • Highly regulated

If needed, Step 1 can help you meet this requirement.

Required: Conditional access policies are configured

You've used the information in these articles to create the set of recommended conditional access policies:

You've configured these policies and applied them to the three recommended security levels or their equivalents in your organization.

If needed, Step 2 can help you meet this requirement.

Required: Increased security for Office 365 is configured

You've configured the following settings for increased security based on the information in Configure your Office 365 tenant for increased security:

  • Threat management policies in the Office 365 Security & Compliance Center
  • Additional Exchange Online tenant-wide settings
  • Tenant-wide sharing policies in SharePoint admin center
  • Settings in Azure Active Directory

You've also enabled Office 365 Advanced Threat Protection (ATP).

If needed, Step 4 can help you meet this requirement.

Optional: Classification is configured across your environment

You've worked with your legal and compliance teams to develop an appropriate classification and labeling scheme for your organization’s data, which can include the following:

  • Sensitive data types
  • Office 365 labels
  • Azure Information Protection labels

If needed, Step 3 can help you meet this requirement.