This project is read-only.

One of the challenges with the SharePoint 2013 App pattern are certain limitations compared to the server side code. These will be gradually obviously addressed with the upcoming releases to ensure that the normal enterprise scenarios can be also implemented using the SP App world. One example of these limitations is the lack of site collection creation capabilities in on-premises deployments.

Office365 or SP Online supports creation of site collections remotely using specific online extensions to the CSOM (part of the Windows PowerShell for SharePoint Online package), but this set of functionalities is not available for on-premises (or Office365-Dedicated) currently. This is really powerful capability which is well demonstrated by Richard diZerega in his blog post called Self-Service Site Provisioning using Apps for SharePoint 2013.

It’s however pretty common that we need custom self service site collection creation capabilities also for on-premises, so that we can provide enterprise ready end user experience to requesting new site collections with needed customizations and branding. This blog post explains how this can be achieved using the same SP App provider hosted patterns like in cloud. Reference code is also available for download.


How to address this gap in on-premises?

There’s actually pretty simple solution for this – let’s expose the needed capability as custom extension point until the gap is addressed natively in the product. This can be achieved pretty easily by deploying custom WCF end point to the SharePoint farm, which is exposing the needed server side self service site collection API to be used externally as well.

Architecture design

In high level our architecture will look as follows. We have three specific phases.


  1. Actual site collection creation UI is hosted by the provider hosted app or the requests are stored in agreed location
  2. Provider hosted app will process the request and will provision site collection based on the given values
    • Site collection provisioning is done using custom WCF end point which provider hosted app is calling with given parameters
  3. Additional configuration will be applied to the site collection using normal CSOM and oAuth techniques
    • Can include custom themes, master pages, elements and layouts… whatever is needed based on business requirements

This pattern can be easily extended as needed to support additional capabilities. Here’s a architecture for real world implementation where also AD and FIM integration was included to the process.

  1. End users select the template and provide other needed attributes for the site collection
    • Request is stored to specific list in the SharePoint
  2. Provider hosted application is responsible of creating the needed AD groups which will be associated to the site collection as default groups
  3. FIM synchronizes created AD groups for delegation of group management to site collection owners
  4. Synchronized AD groups are associated to the site collection by the provider hosted app
  5. Actual creation of the site collection using extension WCF end point
  6. Modifications are applied using CSOM and/or REST interfaces
    • This also means that when site collection creation is natively supported in CSOM, we can quickly just replace the needed code in step 5 and all other code will be remain intact
  7. Email is sent to the requester when whole process is completed
So you’d be still adding farm solution to your farm?

Yes and that might seem silly at fist, but there’s a clear difference comparing to the more classic approaches where we deploy the whole functionality as farm solution. Key difference is that with this solution we ONLY expose additional APIs which are not available by default, but we don’t actually provide any real UI or other customizations which we would have to maintain in SharePoint side.

Key point is to evaluate how often you actually need to change the exposed API set, compared on the UI or other customizations related on the provisioning? – not that often most likely, which means that we can concentrate on maintaining the code in provider hosted app side, rather than on the SharePoint side. This means less service breaks and more robust development opportunities without compromising the whole SharePoint farm.

It’s also important to notice that this is just a temporary solution until needed capabilities are available natively remotely. Since we will implement all other needed customizations using the App pattern as well, we can easily replace the site collection creation with native API, when that’s available.

Why would you use SP Apps in on-premises?

This is pretty common question which I thought to address slightly. Obviously it’s completely up to you to use the app pattern or not in on-premises. In general this is however the roadmap of the product and we are gradually moving to this direction also in on-premises. Many of our enterprise customers are looking into using App pattern also in on-premises to keep the deployment compliant with the cloud practices, so that they can easily move to the cloud, if decided to do so.

On big advantage also for on-premises is that when we utilize the App pattern, we don’t have to perform as frequent maintenance breaks as classically with the farm solutions. It means that all the customizations are running outside of the SharePoint or as un-ghosted elements and therefore customization changes will only impact the app platform, not actual SharePoint services, like accessing critical documents from collaboration sites. We also more precisely maintain or update only specific apps, without impacting the other services. This provides us clear benefits and will make the whole ALM process much more agile and dynamic.

There are lot of opinions on this one which are definitely all more than justified. When we design customization architectures for the customers, these things are not black or white. It all depends on the business requirements, including short and long term roadmap for the particular deployment.

Video recording of the demo code

In this video I’ll quickly walk through the provide example code which includes the WCF end point and the provider hosted app for actually requesting the site collections.




Few useful links and resources related on this blog post.

C#, Development practices, SharePoint 2013, SP Apps

Last edited Jan 3, 2014 at 8:54 AM by EROL, version 1