Partilhar via

Provisioning site collections using SP App in on-premises

  • Artigo

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.

&nsbp;

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.

image

  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.

image

  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.

References

Few useful links and resources related on this blog post.

Comments

  • Anonymous
    January 13, 2014
    Do you see anyting wrong with using Auto-hosted apps instead of provider hosted apps? It can be an obstacle that customer need to pay a subscription to yet another service, as suggested in this pattern.

  • Anonymous
    January 13, 2014
    Hi Anders, challenge for on-premises is that the Auto-hosted apps are only support with Office365 at least for now, so we cannot use them in on-premises deployments. Technically you could actually implement the needed capabilities also using SP hosted app, that would mean just clever JavaScript development with few adjustments on the WCF end point. Using provider hosted in on-premises does indeed require additional hardware, but that's for the benefit of the SharePoint. This has been often the reason why at least most of my enterprise customers have seen this as valid option. You could also use any existing .NET environment, which are also pretty common in on-premises, since you don't need to have dedicated servers for the provider hosted apps. This is more or less balancing between the operational impact compared with the increased costs with additional hardware.

  • Anonymous
    February 03, 2014
    How would add provider hosted app from the Corporate Catalog to the newly created site?  

  • Anonymous
    February 06, 2014
    Hi Justin, Corporate catalog is one site collection in the tenant (or web application in on-premises), so you don't have to care about that durign actual site creation. As long as the app file is located in the catalog, you will have your app available in the site as well.

  • Anonymous
    February 13, 2014
    Thanks for the reply.  The app is available after site creation process but it doesn't include the app part.  The app part is only available on the catalog site collection or adding the app manually.

  • Anonymous
    February 13, 2014
    Hi Justin, that's correct. You can use the "app stapling" to get the apps available cross the sites, but app parts are not supported for this centrally deployed app model currently. There's also no native CSOM way to inject or approve app to be added to the site automatically. Depending on the scenario, you can however access the provider hosted app for example simply by using link in the master page or in the content without necessarily the need to adding the app to the site as such. It all depends again on the exact scenario details.

  • Anonymous
    April 03, 2014
    Is the On-premise remote site collection creation released yet? Or do I have to use Custom WCF service like in your Contoso.Services.SiteManager example? If not yet released, can you tell when the release could happen?

  • Anonymous
    April 03, 2014
    Hi Mika, on-premises support for site collection remote creation is currently (early April) still only available if you use multi-tenant features. Real support is coming in upcoming CUs, but can't comment directly on the schedule, since functionalities can be still postponed if there's any findings in testing. Will be sharing any news immediately as blog post, when available.

  • Anonymous
    May 12, 2014
    For remote provisioning, has any create a template (xml) and code to runs that template? All remote provisioning example that I have seen are just code examples. It is easy but not very flexible way to create a "template". To me it look's like lot of coding to create flexible remote provisioning template. It would be cool if I could use "Save site as template" and use that wsp in remote provisioning.

  • Anonymous
    May 12, 2014
    The comment has been removed

  • Anonymous
    May 22, 2014
    Hi Vesa, Great post! I originally come from a Multi-Tenant environment, but now I work in a Dedicated Environment. From my understanding you cannot access admin services in the dedicated space. So does your example here address that and will allow site collection creation in the dedicated space or do I need to create my own "admin services"? Thanks.

  • Anonymous
    May 22, 2014
    Hi Brandom, Dedicated is indeed slightly different and the classic model with them was to similar as in here, meaning that you deployed custom WCF end point to the farm, which was full trust code. We are however in the transition of the Dedicated service, meaning that support of the full trust code will be dropped from that service as well. There will be native CSOM support for on-premises / Dedicated for creating new site collections. We are right now working on getting requirements and configuration verified and will obviously share the results for the community when details and updates are available. Depending on your project schedule, you might want to reach out to the MSO Dedicated engineering using the customer MS contacts for asking details.

  • Anonymous
    May 22, 2014
    Hi Vesa, Thanks for your quick response. We are upgrading from 2010 to 2013 and we have a deadline of July. We currently have a webpart and timerjob that is doing the site collection creation. It is a buggy solution that I want to replace with the CAM. So what I see in your example code will work for dedicated correct?

  • Anonymous
    May 23, 2014
    Hi Brandon, we are using this exact code or adaptation of it with few existing SharePoint Online Dedicated customers in SP2013 environment. So this is completely valid approach until the real CSOM support is available.

  • Anonymous
    May 28, 2014
    Thank you so much.