SharePoint Online, Groups, Regional Settings, and Pacific Time

SharePointGroups

The Odd Case of Office 365 Groups and Pacific SharePoint Sites

For whatever reason, Office 365 Groups love to create SharePoint sites with the time zone set to Pacific Daylight Time (UTC -8 hours). It’s probably a historical legacy of some decision about provisioning taken years ago, but today, all my sites created in a Western Europe tenant, proudly display Redmond-centric times. This is fine for people in Microsoft but not so good for users elsewhere in the world.

The problem existed since Microsoft launched Office 365 Groups in November 2014. The increasing number of SharePoint sites created by Office 365 Groups (and Teams) has led to nice growth in SharePoint usage, which is a good thing.

Manual Updates are Never Good

You can always update these settings by accessing the Regional Settings of a site (Figure 1). However, given that Teams and Office 365 Groups create many of the new SharePoint Online sites and their owners are usually people with little SharePoint expertise, it is best if the settings are correct from the start. In addition, as MVP Marc D Anderson notes in a blog post, finding and resetting regional settings for multiple sites is tedious. In short, a royal pain.

SPO Site Regional Settings
Figure 1: Site regional settings (image credit: Tony Redmond)

When regional settings are set correctly, the SharePoint browser interface displays creation and modification dates for documents in local time rather than Pacific time. That’s the biggest advantage gained through this exercise.

Teams Makes SharePoint Easier

The only justification I can see for leaving the time zone fixated on Redmond is that most people who use Teams don’t use the browser interface to interact with SharePoint. Teams presents “Files” instead, a simplified interface that is easier to use. People who use Office 365 Groups often focus on email conversations rather than SharePoint, but if they access the document libraries belonging to Groups, they get the full SharePoint browser experience.

SharePoint Site Scripts Deliver an Answer

The answer, at least for new sites, comes in the April 2018 release of SharePoint site scripts, which includes the ability to set default regional settings. A Microsoft example of how to configure regional settings is available in GitHub. Make sure that you download and install the latest version of the SharePoint Online PowerShell module before trying to use these commands.

The steps to set default regional settings are straightforward. First, create a JSON-formatted input file holding the settings that you want to use. In this example, I select GMT as the default time zone, that we use the 24-hour format instead of 12-hour format, and that Ireland is the default country (locale id or LCID). Examples of other locale ids are 1069 (Spain) 5129 (New Zealand), and 1035 (Finland). A full list of local ids is available online.

{
"$schema": "schema.json",
"actions": [
      {
       "verb": "setRegionalSettings",
       "timeZone": 2, /* Greenwich Mean Time */
       "locale": 6153, /* Ireland */
       "sortOrder": 25, /* Default */
       "hourFormat": "24"
      }
   ],
      "bindata": { },
"version": 1
}

Save the JSON data to a file. Then connect to SharePoint Online with PowerShell and execute the following command to retrieve the settings from the clipboard and load them into a variable ($SiteScript in this case).

$SiteScript = (Get-Content "C:\Temp\RegionalSettings.json" -Raw | Add-SPOSiteScript -Title "Set Ireland Regional Values" -Description "Sets locale, time zone, and hour setting for Ireland")

Now run the Add-SPOSiteDesign cmdlet to load the settings as default regional values. The documentation for all the cmdlets mentioned here is online.

Add-SPOSiteDesign -Title "Set Ireland Regional Values" -WebTemplate "64" -SiteScripts $SiteScript -Description "Applies Ireland regional settings" -IsDefault

To test that the change is effective, create a new team or group and examine the regional settings for the site that Office 365 provisions. Open the site with SharePoint, select Site Contents, then Site Settings, and then Regional settings. The locale and time zone settings should be the values set in the script.

Updating a Site Design

If you make a mistake, you can update the site design with the Set-SPOSiteDesign cmdlet or remove the site design and start over. Run the Get-SPOSiteDesign cmdlet to return a list of site designs in the tenant and note the identifier (Id) for the design you want to remove. Then run the Remove-SPOSiteDesign cmdlet to remove it.

Get-SPOSiteDesign

Id                  : f466a1da-e2a2-4107-b558-35954ad199de
Title               : Default
WebTemplate         : 64
SiteScriptIds       : {9e287dd9-b2b1-4ceb-8649-998f43b24c1d}
Description         : Applies Ireland regional settings
PreviewImageUrl     :
PreviewImageAltText :
IsDefault           : True
Version             : 1

Remove-SPOSiteDesign -Identity f466a1da-e2a2-4107-b558-35954ad199de

Old Sites are Not Updated

Setting default regional settings for new sites with a site script does not update regional settings for existing sites. If you want those sites to use the correct time zone and locale, you must update their settings manually or programmatically.

You can access regional settings through PowerShell using the SharePoint Client-Side Object Model (CSOM) and several examples of how to do this are posted online.

CSOM is great, but it can be pernickety. Instead, here’s an approach using the Invoke-SPOSiteDesign cmdlet to apply a site design to an existing site (suggested by Steven Collier). Some older groups might not have provisioned SharePoint yet (if they were never used), which is why we filter to only try to update sites that we know exist.

$SitesUpdated = 0
DesignID = "11c2efae-d0eb-4eb9-af71-4f4f5c5c6db8"
$Groups = (Get-UnifiedGroup | ? {$_.SharePointSiteUrl -ne $Null} | Select SharePointSiteUrl, DisplayName, Alias)
ForEach ($G in $Groups) {
     Try {
          Write-Host "Processing" $G.SharePointSiteUrl "for group" $G.DisplayName
          Invoke-SPOSiteDesign -Identity $DesignID -WebUrl $G.SharePointSiteURL -ErrorAction Stop
          $SitesUpdated++
          Set-UnifiedGroup -Identity $G.Alias -CustomAttribute13 "Site Design Updated" }
    Catch {
          Write-Host "Problem Processing" $G.SharePointSiteURL }
}
Write-Host $SitesUpdated "sites updated successfully. You need to check the following and update them manually"
Get-UnifiedGroup -Filter {CustomAttribute13 -eq $Null} | Sort DisplayName | Format-Table DisplayName, SharePointSiteURL

The script failed to update some sites, possibly for some obscure SharePoint reason. For instance, in some cases, site settings missed regional settings. These sites deserve more investigation when I have time.

Will Office 365 Users Notice Pacific Times?

You might think that you’ve tolerated sites with incorrect regional settings for nearly four years now, so it’s not really a problem. And you could be right. I’m not sure that being picky about regional settings will make a heap of difference to the average Office 365 user. But attention to detail is good and that’s why I am happy that Microsoft has finally solved the problem of how to make sure that new sites are provisioned properly.

Follow Tony on Twitter @12Knocksinna.

Want to know more about how to manage Office 365? Find what you need to know in “Office 365 for IT Pros”, the most comprehensive eBook covering all aspects of Office 365. Available in PDF and EPUB formats (suitable for iBooks) or for Amazon Kindle.