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:

• Top three fixes to Group team sites
• How to apply the fixes
• What's next?

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.

Creating a .pnp provisioning template file

After my demo on the PnP screen cast where I showed a provisioning solution based on PowerShell and Azure web jobs, I’ve had some questions about how you go about creating the .pnp files we use for provisioning templates.

There are basically two options, and it’s quite easy. For full samples run Get-Help <command> –Examples on the command lets. If you want to use code instead of PowerShell, look at the PowerShell code in github and see how it’s all implemented.

Generate .pnp file from a site

Connect to the site, and then run:

PS:> Get-PnPProvisioningTemplate -Out template.pnp

By naming the output .pnp, you get a .pnp file instead of and .xml file.

Generate .pnp file from a template xml file

This works for both a single .xml file, or one referencing artifacts.

Make sure the .xml file and all artifacts are stored in a folder. Then run:

PS:> Convert-PnPFolderToProvisioningTemplate -Out template.pnp -Folder c:\temp

It’s important that the .pnp file has the same name as the .xml file inside the folder, due to convention when applying the template, as you can have multiple .xml files in a complete template referenced with <xi:include> statements.

SharePoint PnP Webcast – Provisioning with PnP PowerShell and Azure WebJobs

I had the pleasure of doing this web cast with Vesa Juvonen recently where I do a demo of how you can set up a pretty simple provisioning solution to let users order new team sites in SharePoint Online using an order list, and an azure web job to do the heavy lifting. A simple solutions with only two technical components, a SharePoint site and an Azure web job using PnP PowerShell.

The complete sample is located at the PnP repo (https://github.com/SharePoint/PnP-PowerShell/tree/master/Samples/Provisioning.SelfHostedWithAzureWebJob) and contains everything you need to get up and running.

PnP webcast post: https://dev.office.com/blogs/provisioning-with-pnp-powershell-and-azure-webjobs

I’m currently doing the same approach for Office 365 Groups with a customer, so watch out for a sample on this later as well.

How to rename the Title field in a list/library using PnP templates

Took me some testing to get this right, but turned out not that hard. You add a reference to the Title field with the out-of-box id fa564e0f-0c70-4ab9-b863-0177e6ddd247, and then change the display name. In the sample below I’m also using a reference to a language resource as I need support for four languages.

<pnp:ListInstance Title="My List" TemplateType="100" Url="Lists/MyList">
    <pnp:Fields>
        <Field ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Type="Text" Name="Title" StaticName="Title" DisplayName="{resource:MyList_MyTitle}" />
    </pnp:Fields>
</pnp:ListInstance>

Using custom actions to configure, brand and inject client side web parts into a Team Site

In my current project we have created a configuration based provisioning engine using CSOM to configure and brand SharePoint Team sites into what we call Group sites. The above picture is a screenshot of the console runner version of the tool, but we’re use the same templates in a custom site creation process as well. As we started this before the OfficePnP engine was made available it’s all custom built, but we have borrowed code from OfficePnP in the engine itself.

As an end user you will use a wizard on the intranet to fill out information about your new site, which in turns does a POST ajax query over to an WebAPI service on a random IIS server which does the actual site creation and configuration.