Typical issue with regional settings for a multinational company in Office 365

Reading Time: 5 minutes

In this article, I’d like to talk about a typical problem facing multinational companies by releasing a new SharePoint site or Microsoft Teams in several countries.
To be more precise, the problem in this scenario is the time zone.
When a new SharePoint site (Team or Communication) or MS Teams are created (Team site created with Ms Teams), is used the default time zone.
I’d like to remember that, the SharePoint admin can set the default time zone in the new admin center portal:
https://<your-tenant>-admin.sharepoint.com/_layouts/15/online/AdminHome.aspx#/settings

O365 SharePoint Default Time Zone | Giuliano De Luca

Problem in multinational companies

Now imagine that a company based in Italy across self-service provisioning, release a new Microsoft Team for users which work in the New York subsidiary.
The Ms Teams created or rather the SharePoint site created will get by default the time zone defined in the admin portal.
The colleagues of New York will work on documents in a classic document library with dates (created, modified, published….) based on the time zone “(UTC+01:00) Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna” generating confusion.
This issue will push the owner/responsible of the SharePoint site to change manually the time zone, which of course is not really comfortable:

Regional Settings | Giuliano De Luca
SharePoint Admin default Time Zone

Automating the process: Azure Functions to the rescue

The goal here is to provide to the user a service already configured and ready to go.
It’s just necessary to add in the provisioning process a small piece of automatism, allowing to deploy the SharePoint site with the right time zone preferred by the end user.
This is the perfect use case for an Azure Function, but before to go forward with this solution, let’s do a preamble.
As far as I know, we have several possibilities to set up the time zone of a SharePoint site, via CSOM (impersonating the SharePoint Admin), via Site Design & Site Script or JSOM.
In this scenario, I have considered the first two.
Site Design & Site Script is the modern approach to customize a SharePoint site in terms of themes and artifacts.
However if you want to cover all scenarios, you have to create each script for each time zone.
This it means 112 (different time zones available in SharePoint) Site Script & Site Design to create, which is technically possible, but not so comfortable from my opinion.

My Choice: CSOM

In this scenario, I find more useful the use of CSOM.
The next step will be to create a C# Azure Function by installing CSOM of course.
In my solution, I created two functions, one in order to get the list of time zones available in SharePoint, the second to modify the time zone of an existing SharePoint site.
Now there is a potential side effect with my choice.
In order to change the time zone of a SharePoint site via CSOM, I need the SharePoint admin privileges.
You probably already know that in the App Settings of an Azure Function you can define the variables.
The problem here is despite the value of a variable is not immediately displayed you can easily click on it to show the content:

App Settings | Giuliano De Luca
Application Settings Variables

Storing the SharePoint admin password in the Application Settings means to make visible this important secret also to other potential users.

Keep your secrets safe: Azure Key Vault

I’ll use an Azure Key Vault to store the SharePoint admin password.
The Azure Key Vault is the perfect place where you can save secrets, because all data (passwords, connection strings….) there, are encrypted, please take a look here to go deeper.
The cool part of that is to read the secret located in the Azure Key Vault across a recently announced feature, without any line of code.
In fact using a specific syntax in the value field of a variable is possible to read the secret, like this way:

@Microsoft.KeyVault(SecretUri=secret_uri_with_version)

In my case I’m able to read the SharePoint admin password from my Azure Function as below:

App Settings Azure Key Vault | Giuliano De Luca
Reading the Key Vault secret from App Settings

Now another important step to define, is that I want to set a policy in my Key Vault that permit to read the secret only to my Azure Function and nobody else.
Before to do that I have to assign an identity to my Azure Function.
You can easily to do this by clicking in the platform feature:

Azure Function Identity | Giuliano De Luca
Creating an identity for the Azure Function

Finally, the Azure Function has an identity in the Azure Active Directory.
Now I can add this identity in the trusted resources in the access policy of my Key Vault:

Adding the Azure Function Identity in the Azure Key Vault Access Policy

You have to wait a while until this configuration is completed.
Using your preferred HTTP client tool you are able to test your Azure Function, below you can find the responses for my case across Insomnia:

GET Time Zones | Giuliano De Luca
GET Time Zones
GET Time Zones | Giuliano De Luca
POST Time Zone

I can include this small piece of automatism in my self-service provisioning process.
The user requests a new MS Teams, for example, selecting a preferred time zone, this latter is created (Microsoft Graph API, PnP……..) and after that, the Function is called to set the time zone according to the user selection.
The complete demo is here:

DEMO | Giuliano De Luca
Demo

You can find the source code of the Azure Function here:

https://github.com/giuleon/O365TimeZones