April 26, 2015 Leave a comment
April was OneDrive for Business month at TriState SharePoint. ODFB or OD4B, depending on your preference, is the corporate user’s, cloud storage solution available as part of Office 365 SharePoint (Sites) or as a stand-alone product. This is not to be confused with the OneDrive Personal you get as part of your Microsoft Account.
For my part of the discussion, I focused on the development hooks available for ODFB. This blog post describes the information presented in the meeting I pulled this information from available resources on MSDN, dev.office.com, and Microsoft Virtual Academy. I link to these sources in the content of the blog and don’t repeat the specifics here. You can check out the links for the greater details.
I grouped these into 3 possible options, Provision, Customize, Develop.
Much like a MySite in SharePoint, ODFB is not created by default. It is only instantiated when a user navigates to the site for the first time. This can cause a slight delay while it is being created. In one-off situations, the wait is not terrible. If you are launch a new site to you user community, you may want to create those sites ahead of time and save unnecessary calls to the service desk. Scripts are available in CSOM and PowerShell. Both languages follow the same pattern.
- Connect to the SharePoint instance.
- Get a collection of users
- Connect to the User Profile object
- Create ODFB instance. The collection of users should be less than 200 per batch. There is a TechNet article describing the full process with the PowerShell code..
What is the first thing everyone wants to do with their SharePoint environments? Make them not look like SharePoint.. While you can change the masterpage, this is not the recommended practice. However, there are ways to change the appearance and content of the ODFB site.
First, why would you want to do this? You may want to change the colors used on the ODFB site. Maybe add a background image or do other things that make the ODFB site look more like the rest of your custom tenant sites. All of this is possible with the patterns described here. One other reason is for governance. There may be content you want to make sure is included with each ODFB site. This could be Sales Contract templates for the Field Sales Team or just standard policy documentation. These patterns can also be used to check and confirm that the content remains included on the user’s ODFB site.
There are three design patterns available for enabling these changes. They are App Part Model, Scheduled Job Model and the Pre-create Model. All of these patterns are described in more detail in this post. I’ll briefly summarize here.
App Part Model
You cannot deploy applications directly into the ODFB site like you can on a team site. One method of getting around this is to create an app part that sits on an Office 365 page that is common to your users, like the home page of your intranet site. When the home page loads, the app part runs and calls a provider hosted app so it can create an entry in a queue for the user with the information needing to change on the ODFB site. A scheduled job looks at the queue and checks for work and performs the customizations described in the entry. This model is needed as the process can be long running and would not be a good idea to run in the provider hosted app directly. There is a great solution included in the Patterns and Practices repository on the OfficeDev GitHub. It is complex, as it is a complete solution included console apps to apply and reset the customizations. There is also a channel 9 video walking through the project.
A scheduled job is nothing more than some code, usually an executable, like a console application, that gets executed on a recurring basis by some process. In SharePoint, these would be Timer Jobs, which we are not available in Office 365. As a an IT Pro, you might think of these as Windows Scheduler Jobs that run on a server. In Azure, the equivalent is a WebJob. The webjob runs within an Azure website and will run an executable on a defined interval. Regardless of how you architect it, the executable portion of the scheduled job runs code that queries Office 365 for new ODFB sites. When it finds them, it applies the customizations defined in the code. The potential limitation with this approach is that people may get to the site prior to the customization being applied as search does take time to populate with the new sites.
I mentioned the provisioning options available in the first part of this post. It is possible to include the code for customizing the ODFB site at the time it is created. This provides a simple way of getting the sites and the customizations applied from the start. Unlike the other two models, creating site for additional users and resetting user changes is not easily handled in this model.
As for the actual project sample, I stepped through lab project associated with the Microsoft Virtual Academy course, Deep Dive: Integrate Office 365 APIs in Your Web Apps. Section 3 focuses on ODFB integration and includes a lab in which you build a web site that includes a page showing the file in the user’s ODFB. The code for this lab is available here. If you clone this repo, move the project to a local folder and open it from there. The folder names are too long in the repo and they prevent Nuget from updating the packages. Even with that move, I still had issues with the OWIN package. I had to remove it and it’s dependencies using uninstall-package command and then reinstall again. This was a little troubling but it did solve my build issues.
That’s all for the recap. Ping me on twitter or leave a comment if you have any questions.