1 Microsoft Online Services – status quo
Microsoft offers a variety of online services and new services are added by the minute. To stipulate cloud transition customers receive mega discounts on services, e.g. Office365 E3 / E5 plans, or online services are bundled with on premise use rights, e.g. Secure Productive Enterprise, to ease cloud transition. The way up to “cloud number nine” seems to be a smooth ride, or is there a risk of turbulence? Microsoft customers who are planning to migrate to Microsoft Online Services typically deal with the same challenges such as:
1. IT infrastructure and business critical applications are not cloud ready – no easy fix.
2. Requirements regarding data security and privacy are not clear and there is uncertainty regarding the safe guards in place with Microsoft Online Services – one could say that without security Microsoft would not offer online services in the first place so customers should put their trust in Microsoft.
3. Customers forget about a contingency plan in case of poor Internet connection or loss of connection to Microsoft Online Services – this problem can be handled by going through a proof of concept project and by setting service levels before moving to the cloud.
4. Customers have no transparency on the dependencies that exist between Microsoft Online Services and do not know how to operate Microsoft Online Services properly – better practices on how to reach “cloud number nine” are provided in the following chapters.
2 Office 365 tenant unique attributes and limitations
When creating a new Office 365 tenant the first step is to define the unique Office 365 domain. That always follows the same rule: custom-name.onmicrosoft.com. This initially defined domain remains unchangeable and will exist as long as the Office 365 services are used. Thus, it is highly recommended to choose a domain name that can exist for a long time and does not point towards a too specific information that might be subject to change. Users will see that internal domain name by accessing some of the cloud services: e.g. for SharePoint Online it will be “custom-name.sharepoint.com”. To adapt public domains to the Office 365 tenant, these domains must be associated with the tenant. A public domain can only be associated with one Office 365 tenant.
3 Office 365 users and licenses
No matter how users are granted access to an Office 365 tenant – either as “Cloud-only”-accounts or as “AD-Sync”-accounts that are originally created in the customers on premise Active directory – for using the services in a tenant a license is required. The license needs to be purchased first, either by entering a license-key coming from a Volume License Contract or by purchasing an individual license in the Office 365 online shop. One major challenge: if a user requires to access two or more Office 365 tenants, the user must be granted a license in each tenant. There is a limited capability of providing access to a user that has no license in an Office 365 tenant. If external sharing is turned on, the user can access shared documents within SharePoint Online or OneDrive for Business. Moreover, the user can access Skype for Business conferences.
Yet, the user cannot access other Office 365 functionalities associated with that tenant (no E-Mail, Planner, Delve…)
In summary: If legally associated companies share either domains or users and plan to work together, it is highly recommended to use a single Office 365 tenant for all of them. If a separation is required (e.g. IT-management roles, governing access to information…) it should be achieved by using the governance tools within an Office 365 tenant. For example, application-specific administrator roles, the constantly improving “Security & Compliance” features etc. Therefore, developing a concept analyzing the required roles and limitations and proofing that concept before creating the tenant structure is highly recommended.
4 Office 365 tenant AD association
If separately managed companies, owning their separated Active-directory-domains, plan to move to Office 365 they are not required to create individual Office 365 tenants. The reason for that is Azure-AD which is associated with each Office 365 tenant. After setting up a tenant, Azure-AD is automatically created and used for storing all user-specific information like user-name, password and attributes. This cloud-based directory service can be synchronized with on-premise Active Directory domain controllers. The synchronization needs to be initially created and will then regularly sync changes from the local directory to the cloud directory – and even vice-versa if required (for example: hybrid-mail-infrastructure). In earlier Azure AD implementations, only one domain-controller could be synchronized. But today this limit does not exist anymore and various domains and domain controllers can be connected.
Mirroring an on premise IT-management, company and domain structure with Microsoft Online Services is a challenge that many companies face today. Although there are various approaches to do that, the often used first approach (creating multiple Office 365 tenants) is typically the worst. Using few or only one Office 365 tenant and adapting the domain complexity with the synchronization capabilities of Azure AD will be the best solution in most cases. Nevertheless, if that is the right approach for the individual requirements needs to be analyzed and proofed.