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

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:


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:

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:

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:


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

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:

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:

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

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:


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



De Luca, G. (2019). Typical issue with regional settings for a multinational company in Office 365. Available at: https://delucagiuliano.com/typical-issue-with-regional-settings-for-a-multinational-company-in-office-365/#.XJigbSj7SUk [Accessed:  25th March 2019].

Share this on...

Rate this Post: