Tuesday, September 6, 2016

Different Approaches to SharePoint Site Templates

SharePoint site templates have really been gnawing on my brain lately. I feel like there's a dozen different approaches out there. I wanted to know not only what works best for us as developers, but more importantly, what's the best solution for our clients. I called a meeting of Rightpoint's SharePoint tribal elders and we talked about the different approaches to site templates and identified what works best. This blog is a summary of that discussion.

How Did We Get to This Point?

Code-based sandboxed solutions and full-trust code solutions are a dying breed. Depending on requirements, we can use old-school site templates in the solutions gallery but sometimes those templates require some TLC (tender loving configuration) before they can be used. And candidly, managing site templates in the solutions gallery has always been tedious and exhausting.

Here are some of the solutions that get rid of some of those pain points. I've rated these a score of level to implement from 1-10 with 10 being the most challenging.

Console App

Type a source URL and a target URL and you're done. Sound easy? It kind of is, but it requires creating a console application. But thankfully the Patterns and Practices (PnP) community has a pretty much turnkey solution. Essentially the app uses PnP and takes an existing site and turn it into a provisioning template via PnP's GetProvisioningTemplate method.

Site templates can be a hot mess of XML. They easily get to thousands of lines of XML and can be difficult to manage. The GetProvisioningTemplate method allows you to specify what you want to extract from the template. So if you only want columns, content types, list instances, and search configuration, you can do specify that and leave all of the other stuff behind. If you want the whole kit and caboodle, you can get that too.

Once you have your site's XML, you can then apply it to another site using ApplyProvisioningTemplate. PnP is pretty smart enough in the sense that if it sees that an object, say a column, already exists it'll apply any updates and continue with the rest of the provisioning process.

Are you a PowerShell jockey or console application averse? You can do this in PowerShell using Get-SPOProvisioningTemplate and ApplySPOProvisioningTemplate.

The drawback to this approach, is that this places more administration on someone. I doubt you'll want to give the app to anyone, but a positive of this approach is it can lead to more governance in the sense that only certain users can create sites.

Level of Effort: 5

Getting a console app up and running - assuming your site template is already configured too - shouldn't take more than a day or two. I scored this a five because while the code is pretty straight forward, it's a behavior change to do this via the console.





Provider-Hosted App

Do you like provisioning SharePoint sites through the GUI? Do you long for writing more event receivers? Then if so, a provider-hosted app might be the way to go.

There's a few variations to this approach:

1. End-Users provisioning "features" to a subsite, on-the-fly, by adding an App in Catalog

2. Administrators provisioning custom "site templates" through an Admin Provisioning App

First, let's talk about provisioning sites on-the-fly through the App Catalog. We have used this mostly for allowing end-users to spin up their own subsite and then decide what kind of subsite features they would like added. For instance, a user can decide if they want to add a subsite to be a department, community, or team site look and feel. After creating the site with regular UI, all the user needs to do is navigate to Site Contents add the appropriate app to the site, then follow the on screen prompts which will leverage a provider-hosted app to provision features and output any errors/validation messages if any.

PnP can still be used in this approach or you can use the client-side object model. You can do whatever you're more comfortable with, but I'd recommend using PnP as it's becoming more of a standard than not at this point. If end users or power users are the ones creating sites in your organization, this might be the approach to pursue. I say that because the experience is familiar and there's no need to create a ticket or contact someone to create a site.

The second approach, is to create a app for administrators to provision site collections via a dedicated infrastructure site which leverages a Provider Hosted App. Creating Site Collections is more resource and time intensive so if you use this approach, it may be best to offload the work to an Azure Web Job which is constantly monitoring a queue to look for new site collections to provision. All this infrastructure is available with PnP by default, it is just a matter of setting it up, fine-tuning your template, and testing.

Level of Effort: 7

The site provisioning part is easy and the code is pretty straight forward, but if you're new to Azure there will be a little bit of a learning curve.




Migration Tool

This is a different approach from the previous solutions in that in does not involve code. If your organization doesn't have SharePoint developer resources or may be constrained by a budget, SharePoint migration tools are a viable option for provisioning sites.

This approach requires creating a source site with all the configurations you want and have the migration tool apply said configurations to a target site. Most migration tools allow you to get very specific about which object you migrate to a site. So if you want to update only a content type, you can do so. If you want to push new pages and branding assets, you can do that as well. The only caveat is that sometimes migration tools can be fickle. While this approach may not require code, updates to a template that are to be applied should be tested in a non-production environment as though they are actually code.

The drawback to this approach is that usually migration tools are kept in the hands of system administrators, so creating a site and apply the template via migration may require someone opening a ticket. Additionally, if your template involves workflows - no matter what product they're developed with - things might get interesting.

Level of Effort: 2

This is by far the easiest and quickest solution. However, depending on the size of your organization it may not be scalable or sustainable. Additionally, the level of effort may depend on which migration tool you use and your comfort with provisioning new sites or site collections using said tool

No matter which of these solutions works best for you, I really believe the days of provisioning a SharePoint site through the browser are over. Let's say goodbye to the pains of managing site templates the old school way, and come correct with some new approaches to this old problem.