I have recently presented “SharePoint Online ramp-up for SharePoint On-Premises professionals” session at the SharePoint Saturday Chicago Suburbs and promised attendees an articles of detailed walk through of what are my best practices for initial Office 365 tenant signup process and administrative security configuration for Office 365 and SharePoint Online.
Setting up SharePoint Online tenant with the best practices starts as soon as you sign up for Office 365 tenant. There are various settings one should be aware of while signing up for Office 365 tenant which would decide how SharePoint Online sites are configured.
In this article, we will walk through what one should be aware of while signing up Office 365 tenant and how it can impact SharePoint Online configuration.
Determines the Physical Location of SharePoint Online Data Center
Many of my customers asked me where does my tenant gets created. My response would be it’s in nearest data center from which region you sign up for tenant. E.g. If I am provisioning Office 365 site from Chicago-land area, tenant will be provisioned in Chicago or nearest Microsoft data center. Every employee in my organization regardless of their geographical location whether in North America or Europe will access data from Chicago data center.
The reason this is very important while signing up for Office 365 tenant is country or region can’t be changed after you sing up for the tenant. There are various reasons why Microsoft configures tenant in local data centers and mostly it’s related to compliance policies and country laws (where data can’t live outside of their geographical location). If you read carefully, Microsoft does provide this warning while signing up for the tenant – After sign up is completed, the setting for country or region is locked so you can’t change it later. The location you choose determines: The services that you can use, the taxes and billing currency for your country or region, and the closest data center.
Yet again, it is important to remember that Office 365 doesn’t support geographically distributed tenants, tenant gets created only in first nearest data center from where tenant signed up.
Determines the URL Structure of SharePoint Online Intranet Sites
URL structure for SharePoint Online sites are based on base domain name/tenant name and it can’t be changed afterwards e.g. if your company name is “yourdomain”, URL would be – https://yourdomain.sharepoint.com. Also, Vanity URLs are not supported for SharePoint Online private site collections for Intranet Sites. It is important to communicate with customers/clients/stakeholders on the SharePoint Online URL limitations for Intranet sites and its dependency on the tenant name. Additionally, It is important to note that you can register domain and apply Vanity URLs to your SharePoint Online public web sites. e.g. https://www.yourdomain.com
Here are the default sites & site collections provisioned after initial Office 365 and SharePoint Online tenant signup.
- Intranet – https://yourdomain.sharepoint.com
- Search – https://yourdomain.sharepoint.com/search
- Content Type Hub – https://yourdomain.sharepoint.com/sites/contenttypehub
- My Site Host – https://yourdomain-my.sharepoint.com
- Public Facing Site – https://yourdomain-public.sharepoint.com
- Administration Site – https://yourdomain-admin.sharepoint.com
Plan to Generalize First Signup Account User ID & It must be Cloud ID
Although this is optional, one of my best practices is to generalize the first tenant administrative account. Usually first account have global administrator role with all the workload licenses & administrative privileges. Although this is not typical service account, it is always best practice to define administrative account with generic name. Having generalizing first account allows organizations to change contact email address & passwords to other administrators in case of employee departure.
As I have mentioned earlier, this is optional step. Although I haven’t verified, you can always create new administrative account with Global Administrator privilege and remove first account used during initial tenant signup. I personally don’t feel tenant is tied to or gets in unstable state, if initial account is removed from the tenant. Please don’t take my word on this and validate if you ever need to cleanup first tenant signed up account. Additionally, if you ever cleanup initial tenant administrative account, always replace it with Cloud ID and never replace it with account synced from on-premises AD. This would allow organizations to access Office 365 tenant even if on-premises AD or ADFS are down.
Hope this helps to understand the implication of initial signup process for SharePoint Online tenant.