Thursday, May 18, 2017

Three reasons why you should take control of Office 365 Groups creation

Office 365 Groups are here to stay and I’ve gotten to love them more and more, and for the past six months this is primarily what we at Puzzlepart are rolling out with our customers. If you’ve followed some of my work recently you know that I do a lot of work on provisioning solutions. Not as is a lot of code, but help organizations figuring out business needs and orchestrating them programmatically.

A provisioning solution is the code and logic which creates the pieces of for example an Office 365 Group. Instead of having Microsoft do everything, we add custom business logic on top of the default parts to solve other business needs.

In this post:

You can very well run with the out of the box ways to create new Office 365 Groups, but our customers often experience this to be lacking in many ways – as they want more metadata and governance around the groups themselves. Especially on the associated team site.


By creating an alternative self-service solution, for example based off a SharePoint list, you get more control. Below I’ll list my top three reasons why you might want to take control over the Office 365 Groups creation, and I’ll follow up with what has to be in place to make this work.

1. Language and locale

As Marc Anderson also have pointed out, the default regional settings for an Office 365 Team site sets the time zone to UTC-0800, Microsoft HQ time. For us Europeans we also like to have 24h time, and setting the week to start on Monday instead of Sunday. To get the date and time right, setting this correct surely helps – which is why we have regional settings in the first place.


By default all possible O365 languages are also enabled on the site, and we usually limit this to just the orgs primary language, in this case English.


2. Access control for Public groups should not be that public

By default Everyone who is not an explicit member of a public Office 365 Group has contributor or edit rights on the team site. The obvious default would be read-only rights –so let’s move them already. This allows everyone to view and read all the content, but not changing it by mistake.


3. Branding

Never underestimate the power of how something looks, and as you can see my team site has gotten a random branding using red as the accent color (read my post about the random funky modern colors). What if it could follow the tenant branding instead? Or maybe you want different colors to signify what kind of content is stored in that site – internal projects, external projects etc.


In this tenant I have chosen a dark green (#004012)    as the accent color. By using the SharePoint Palette Tool, I created a composed look based on the tenant accent color and the output file from the palette tool.


Once the composed look is applied to the site it harmonize a lot better with the tenant branding, but you still need to change the Group logo to make it look perfect.


And this is the site with a logo!


Currently setting the logo in a background process propose some challenges, but it’s doable if you want – and I expect the gaps to be filled within not too long. Also, there is no way to set the color for other workloads of an Office 365 Group, but it tries to pick colors from the logo is my experience.


How to apply the fixes

I’m applying the color scheme and locale settings via an Office PnP provisioning template similar to this, where demo.spcolor was saved from the SharePoint Palette Tool:

<?xml version="1.0"?>
  <pnp:Preferences Generator="OfficeDevPnP.Core, Version=2.12.1702.0, Culture=neutral, PublicKeyToken=3751622786b357c2" />
    <pnp:ProvisioningTemplate ID="TEMPLATE-INNOVATION-MADCOW" Version="1" BaseSiteTemplate="GROUP#0">
      <pnp:ComposedLook Name="MADCOW Branding" ColorFile="{sitecollection}/_catalogs/Theme/15/demo.spcolor" BackgroundFile="" FontFile="" Version="0" />
      <pnp:RegionalSettings AdjustHijriDays="0" AlternateCalendarType="None" CalendarType="Gregorian" Collation="25" FirstDayOfWeek="Monday" FirstWeekOfYear="2" LocaleId="2057" ShowWeeks="false" Time24="true" TimeZone="4" WorkDayEndHour="5:00PM" WorkDays="62" WorkDayStartHour="8:00AM" />
        <pnp:SupportedUILanguage LCID="1033" />
        <pnp:File Folder="_catalogs/Theme/15" Overwrite="true" Src="demo.spcolor" />

In order to apply the provisioning template to a Group site you need to enable scripting on the site. You can do this using the PnP commandlets:

Set-PnPTenantSite -Url -NoScriptSite:$false

and then apply the template to the site with:

Apply-PnPProvisioningTemplate -Path .\fixit.xml Apply-PnPProvisioningTemplate -Path .\demo.xml

Moving the Everyone (except external) group from members to visitors can be achieved with the following PnP PowerShell:

# Move everyone (except external) to read-only
$everyoneIdent = "c:0-.f|rolemanager|spo-grid-all-users/97338831-a72f-45f5-8838-54555099a146"
$membersGroup = Get-PnPGroup -AssociatedMemberGroup
Remove-PnPUserFromGroup -LoginName $everyoneIdent -Identity $membersGroup -ErrorAction SilentlyContinue
if ($?) {
    $visitorsGroup = Get-PnPGroup -AssociatedVisitorGroup
    Add-PnPUserToGroup -LoginName $everyoneIdent -Identity $visitorsGroup

What’s next?

Out of the box Office 365 Groups provide a lot of value, but often you have business or governance processes which has to be taken into account.

If you found all of this interesting it’s time to get hold of your favorite developer and start cranking. You also might want to implement naming conventions, lock down creation from the default UI, or have an option when ordering the Group to enable/disable invitation of external members on a Group by Group basis.

Happy Grouping!