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.

Introduction to model

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.

  1. Provider hosted app is deployed to SharePoint with app part. App part is installed to same context where the user profile service is running, so that personal site location can be resolved by the social API. When user accesses the page with app part from provider hosted app, we also load the context of the provider hosted app and execute the page in browser.
  2. Actual code is running in IIS as application and in page code behind, we use SharePoint 2013 Social API to resolve the user’s personal my site or we could also create it.
  3. Actual branding can be applied using theming or custom master pages. Themes are more recommended approach with planned backwards compatibility in future, since master pages will have more significant impact from maintenance perspective. Themes are more cost friendly and provide nice capabilities for branding changes. We don’t recommend too highly customized personal sites, but if those are required, you can upload and apply custom master page to your personal site as well.
  4. When user moves to personal my site side, we can see the applied branding.

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.


Analyses of the required code

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.


Demonstration of the branding handling for personal sites (SkyDrive Pro)

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 and it will work in all locations… and end user will love the awesome capabilities of SharePoint, like always.



Few useful links and recourses