Remote provisioning is model, where we use the SharePoint App model to customize or provision SharePoint sites or elements to sites. This pattern was briefly explained in my previous post, where personal site customization was also mentioned as one of the options. Check more details on the model from following post.
[Updated on 9th of September with link to download the video for offline viewing]
In this post, we’ll concentrate on actual details on how the personal my site (SkyDrive Pro) branding can be changed on on-premises or in Office365 using remote provisioning model. Pattern provides us capability to change the branding elements in the sites without need to deploy any customizations to SharePoint in farm level. Lack of the need to manipulate customizations in farm level is obviously beneficial from operation and maintenance perspective. One of the key benefits also on this model is that we can use exact same approach in both on-premises and in Office365, which has positive impact on our development efforts and we don’t have to consider different patterns based on used platform.
I’m briefly going to explain the model with video on demonstrating the required code and approach. You can also download example code, which is provide hosted SP app for modifying the personal site user experience. As always, these demos are more a proof of concept code than ready to be used in production, so please use it as reference, but don’t install that directly to your environment.
Like with previous SharePoint versions, personal sites (or my sites) consists actually from two different core pieces. These are the my site host and the actual personal site, which are both their own site collections. My site host is one site collect, which has most of the dynamic capabilities from end user perspective, like social feeds and user profile edit. All the capabilities on my site host are dynamic in that sense that shown content is dependent on who is actually accessing the page. Personal site is then actually separate site collection to manage the storage requirements independently per user, since by separating personal my site to own site collection, SharePoint can use normal quota templates to manage the storage and individual site collections can be assign to different databases in SQL Server level.
Personal site creation works in a way that when user first accesses the my site host site, actual personal site (SkyDrive Pro) creation is scheduled as timer job task. Actual site collection creation will be done then by a separate timer job running in web application level, based on these queued requests from end users.
SharePoint 2013 includes new Social CSOM API, which can be used to provision the personal my site or also to access the personal my site remotely, which is actually the key for changing the branding elements in the site. By using this API set, you can built a pretty simple provider hosted application, which will actually modify personal sites or SkyDrive Pro experience based on company branding. After code has been written, it’s just ensuring that it’s executed for the users properly, by placing app part to for example public my site host page or just as well you could place the same app part to front page of the intranet, to ensure that branding is applied or updated when end users access the SharePoint.
Let’s open up the numbers one by one.
Key benefits of the model is that all customizations and code is actually running out side of the SharePoint context and therefore we can easily modify and change that based on changing requirements without impacting the other SharePoint functionalities. Even personal sites could be still created, but they just would not be branded, if for some reason our provider hosted application would not be available.
This pattern is providing us finally alternative approach compared to the classic my site or personal site customization options using feature stapling, meaning that we can finally move forward from the model which Steve Peschka originally explained in SharePoint blog back in 2007.
Required code is actually pretty simple due the exposed user profile API set. We essentially use the client side API to get our hands to root web of the personal site root web and start applying required changes. Key part is following few lines, which we can use for resolving the instance to personal SkyDrive Pro site collection.
// Get user profile
ProfileLoader loader = Microsoft.SharePoint.Client.UserProfiles.ProfileLoader.GetProfileLoader(clientContext);
UserProfile profile = loader.GetUserProfile(); ;
Microsoft.SharePoint.Client.Site personalSite = profile.PersonalSite;
After above lines, it’s just matter of actually applying theme or uploading required artefacts to the site collection, like master pages and css files. Social API can be also used to actually create the personal my sites in the context of the user. This would be beneficial in cases where you’d like to completely override the personal site creation process, but since we can however automate the branding elements to be be applied to my sites for example from front page of the intranet, there’s would really not be a exact need to do so.
In this video, we’ll demonstrate the code usage in practice. Demo has been done using on-premises SharePoint farm, but same code actually also works as such with Office365.
Video is available for download from my SkyDrive if needed for offline purposes.
SharePoint 2013 provides the new Social CSOM APIs, which enables us pretty interesting capabilities also from personal site branding perspective. Like mentioned previously in this post, key benefit of this pattern is the fact that you can use the same code structure or approach in both on-premises and in Office365. Approach is pretty different compared to traditional farm or full trust solutions, but this way we don’t actually need to install any feature framework features to SharePoint servers and even if we would update our code, there would not be any downtime or other issues caused by solution package deployments.
Cloud application model or SP Apps pattern provides interesting alternatives with clear benefits compared to the old patterns. Approaches are dramatically different than what they used to be in previous versions, but like always with IT, end result counts and if we can achieve similar end results from end user perspective, with smaller footprint on the actual SharePoint farm, all parties will win. Business owners will love the availability increase for SharePoint services, IT administrators will love that there’s no code deployed to their farm, developers will love the fact that they can write the same once for asp.net and it will work in all locations… and end user will love the awesome capabilities of SharePoint, like always.
Few useful links and recourses