Business Optimization: Azure Powered SharePoint Site Provisioning

Do you have a Hybrid SharePoint environment, utilizing both SharePoint Online and SharePoint on-premises? Do you have a process for self-service site provisioning? Are you looking to optimize your SharePoint administration? Have you heard of Office PnP?
Hopefully the answer to most of those questions is yes. Office PnP is community driven open source project where Microsoft and external community members are sharing their learning’s around implementation practices for Office 365 and SharePoint on-premises (add-in model). This is work done by the community for the community without any actual full time people. Currently, the program is facilitated by Microsoft, but they already have a number of contributors from the community – including us here at Perficient.
One of those patterns is for self-service site provisioning in a hybrid SharePoint environment. Full disclosure here, we did not develop this pattern. Vesa Juvonen is the primary author of this solution and you can find his blog here. If you’ve been to any of the recent conferences or have seen PnP in action, you’ve likely seen Vesa’s name – he’s one of the primary contributors.
Our team has worked on a number of variations of the provisioning framework. There is a pattern for PowerShell deployment, one for console applications, and others using CSOM and workflow. Each organization is different and therefore may require a different pattern. For purposes of this blog post, I am going to specifically talk about the Azure model.
The Azure approach is preferred because it reduces the amount of customization required in your on-premises SharePoint environment. We can host the business logic and end user forms in Azure, with no dependency on SharePoint. We can take advantage of Azure Storage Queues, Web Jobs, and the Service Bus Relay Service to power this solution.
So let’s have a look at the architecture. By design, Vesa’s pattern is rather simple.

1. Actual form to request site collections is hosted in Microsoft Azure as provider hosted app
2. Request for site collection creation are added to Azure storage queue for asynchronous processing
3. Azure WebJob is automatically called for new items in the queue which checks the target environment and starts executing the right route
4. Site collections targeted to be created to cloud are created directly by the WebJob using app only token access
5. If request is for on-premises, request is passed to Azure Service Bus which has on-premises service connected to it. This means that the on-premises code is executed and the on-premises site collection creation can be started
6. Site collections are created based on the business and functional requirements to on-premises

The IT Leader's Guide to Multicloud Readiness

This guide provides practical key insights and important factors to consider to make informed decisions in your multicloud journey.

Download the Guide

At Perficient, we have developed a slightly more advanced solution that adds an approval workflow. Most of our enterprise customers want some level of control with the site creation process. So, we have extended this pattern to utilize a SharePoint List to manage the requests and approvals, rather than using the Azure Storage Queue.
Our pattern looks like this –

1. Actual form to request site collections is hosted in Microsoft Azure as provider hosted app
2. Request for site collection creation are added to SharePoint List for approval
3. Azure WebJob watches the SP List for approval
4. Site collections are created in the appropriate environment
   1. Cloud sites are created directly by the WebJob using app only token access
   2. If request is for on-premises, request is passed to Azure Service Bus which has on-premises service connected to it

Notice that you do not need to setup any app model infrastructure in SharePoint on-premises.  We can use directly dedicated service account to perform the needed operations in the on-premises which means that there’s no need for addition infrastructure or any app model related security configurations.
Using the Azure Service Bus Relay also means our on-premises SharePoint does not need to have a public facing DNS endpoint. By using the service on-premises, we will open up two directional and secure communication channel from on-premises to Azure, which is also used to receive messages from the Azure to on-premises. This is fully secured channel where we only exposed end points which are needed for the business requirements. In this particular case, only exposed end point is method to request site creation where we pass in the needed elements what end user filled in to the form.
As with any custom solution, this is only one possible example. We have implemented this model for 10+ enterprise customers and each has varied slightly. It is important when evaluating solutions from Office PnP that your requirements are considered and these patterns should not be thought of as complete solutions.
If you would like more information or help in designing your hybrid solution, contact us at Perficient!