Async site collection provisioning with app model for on-prem and Office 365 Dedicated
Few months back I wrote about the exact details on enabling the site collection provisioning in the on-premises using app model. This is follow up for that blog post showing asynchronous way to implement this for your end users. This technique was mentioned as the recommended design approach also in the original blog post. This is exact same model and code which works with the current Office 365 Dedicated platform and since we did record this sample for the Dedicated customers, we also wanted to share this additional video publicly.
Notice that Office 365 Dedicated platform has differences compared to the standard Office 365 MT platform. If you are looking for information on how to do this in normal Office 365, check this follow up post for more information specifically for normal Office 365 MT. Logical design is the same for both sides, but actual infrastructure and the used code is slightly different. Check more details on the specific differences for the Dedicated platform from the dedicated pages in TechNet from article “Tenant Admin Permission and Site Provisioning Solution Support”.
Here’s the logical design for the architecture, which we now also provide as downloadable sample from the Office 365 developer Patterns and Practices project.
- When new site collection is needed, users can go to self service site collection form for filling the needed metadata for the upcoming site collection.
- Request of the new site collection is stored to specific list located for example in root site collection of the web application or tenant (if in Office365)
- You can associate separate approval workflow to the submissions if that’s needed simply by using out of the box approval workflow model or just as well you could create new workflow for more complex scenarios using SharePoint designer or any other means
- Approved requests are processed by remote timer job, which is configured to check the requests from the specific list. There are multiple ways to schedule the needed code for this, like using worker process or web job in Microsoft Azure. In on-premises you could run this as scheduled windows task or execute it from PowerShell as needed.
- Note. for high availability purposes you’d simply have “in progress” stamp in the list for marking the items which are taken into processes by scheduled tasks from different servers running the remote timer job. This way you have high availability for request processing even in on-premises with two servers running the remote timer job.
- Actual provisioning of the site collections is performed based on the stored data in the list using CSOM.
- When site provisioning is completed, notification is sent for the requestor using email. You can also for example show the latest newly created site collections in front page of the intranet, if that’s what business is looking for as a additional capability with the email… or push notifications to social feeds. Whatever is needed.
Notice. Steps 1-3 are obviously optional and only required if you want to provide self service site collection creation capability for your end users.
What about branding and other needed elements for the site?
This is where you simply use the CSOM code to upload the needed elements like theme files, css or logo to the site and apply them as part of this provisioning process before the end users are accessing the site. You can also include any other needed customizations like content types, document libraries and other lists using CSOM. We do not recommend usage of web templates or site templates as part of these provisioning models no longer. They are supported, but they will cause long term maintenance challenges, which means additional costs. We are working on more details on this to MSDN soon.
Here’s how sites will look like when the provided code example is executed. Notice also that we don’t intentionally use custom master pages on this one since it’s collaboration sites where typically this level of branding is enough and usage of custom master pages have also maintenance challenges (more specifics coming later).
Note. I opened up this discussion slightly more in the sibling post targeted for Office 365, but the web template usage guidance mentioned there applies for on-premises as well.
Show me how it works
Here’s the video which we shared also for our Office 365 Dedicated customers recently. This shows how the sample code works and points out other details on the provisioning process.
Office 365 Developer Patterns and Practices
Techniques showed in this blog post are part of the Provisioning.OnPrem.Async sample in the Office 365 Developer Patterns and Practices guidance, which contains more than 50 projects demonstrating different patterns and practices related on the app model development. Check the details directly from the GitHub project at https://aka.ms/OfficeDevPnP. Please join us on sharing patterns and practices for the community.
“From the community for the community” – “Sharing is caring”
Comments
Anonymous
August 28, 2014
Another great tutorial. Can this pattern work in a normal office 365 environment? Which part of the code would need to be changed?Anonymous
August 28, 2014
The comment has been removedAnonymous
August 28, 2014
nothing urgent - i look forward to the next post. thanks!Anonymous
August 28, 2014
This is nice for newly created sites, but I am more interested in the scenarios where we have hundreds of existing sites and need to make changes (add, change, remove) to some of the shared/common arifacts (content types, fields, branding, etc). So when we need to add new content types, branding, etc, it would be appropriate to get a list of all site collections and queue them up to have the updates processed to them. I've not looked, but is there a way to get a list of all site collections (in a given tenant) using CSOM? I guess we could use Search and filter on contentclass:"STS_Site"...As tenant admin, do you automatically have permissions on each site collection?Anonymous
August 28, 2014
Good question Brian, this would be indeed scenario where we would just simple loop through the sites and apply the needed changes one by one. If you have 200.000 site collections that could take a while depending on the type o the customizations or change, but key point with the app model is that this change or update would NOT cause any downtime, meaning that even though update could take a while, it would not have any impact on end users. You could indeed use search to get list of all sites and then scan them through. You can also set account to have the needed permission on the site collections. Using search to get all site collections is showed in the following Patterns and Practices sample - github.com/.../Core.SiteEnumeration I'll also write the update model hopefully pretty near future to provide some additional insights on that.