Over the years, SharePoint has evolved a lot and the powerful tool we know today has undergone some serious developments. SharePoint developers working on configuration of the platform for specific needs have seen solutions to their design needs improvement too. However, it’s not always clear exactly which to use and when, so this post will look at some of the solutions out there and explore how they can be implemented.
A gradual evolution
Back in SharePoint 2003, the only way to change all SharePoint configuration options was using the command-line tool “stsadm”. It came with the inherent drawback that it did not support object oriented programming, the options were quite limited and it only worked when run from the SharePoint server itself.
The server side object model to configure the farm was introduced in SharePoint 2007, but PowerShell integration was quite limited. Furthermore, the server side object model still required the code to be run on the SharePoint servers.
This changed in SharePoint 2010 with the introduction of the client side object model. Using this new model it is possible to run code against the SharePoint object model straight from the client. Under water the code was transformed into web service calls, but from the developer’s point of view he could write code similar to server side code.
When SharePoint Online / Office 365 was released, only a small subset of the server side object model was available in the client object model (as Chris O’Brien described in his article 774 vs 30 Cmdlets). Over time Microsoft has fixed this and added a lot of new functions to the client API’s, and now it is a good replacement for the server side object model.
As useful as these updates are, it can be somewhat difficult to understand how they all work. To clear this up, we’ll be looking at three top tips for using the SharePoint Online client object model with PowerShell.
1. TechNet: Start here when you are looking for documentation
The most experienced SharePoint developers will remember the days when there was absolutely no official documentation on the SharePoint 2007 Object Model. Things are very different now: Microsoft has released a lot of documentation about their API’s, including a dedicated area on TechNet about Windows PowerShell for SharePoint Online. It is a great starting point to read about this topic, and it includes the entire list of available cmdlets.
Of course you can also just use the built in help and intellisense of the PowerShell ISE to explore all the available cmdlets after you have set up your environment.
Another great starting point to turn to when looking for documentation is the Office Dev Center. It provides links to tutorials, training videos, upcoming events, code samples and so on. The link to the Office 365 roadmap is also promoted on the front page – have a look there to see upcoming changes for Office 365. Microsoft is implementing new changes very rapidly, so don’t let these new changes come as a surprise!
2. Office 365 Developer Patterns and Practices
Although many open source libraries are available on the internet, there is only one that has the official blessing from Microsoft:The Office 365 Developer Patterns and Practices which I already talked about previously.
A popular example is branding. There is a lot of discussion about how to apply branding in Office 365, as custom master pages and page layouts are discouraged. The library contains many examples of how to apply custom branding without having to change master pages and/or page layouts.
A component worth a special mention: The OfficeDev PnP PowerShell Cmdlets authored by Erwin van Hunen. Erwin extended the existing SharePoint Online PowerShell cmdlets extensively to fill the gaps and ease the process of managing your SharePoint Online tenant through PowerShell with plenty of helper and provisioning cmdlets.
In general OfficeDev PnP helps to make sure that developers and administrators do the correct things and build reliable future proof solutions. On top, it also improves efficiency. Code examples enable developers to build solutions much faster without having to reinvent the wheel.
3. Blogs: A lot of people have solved problems you will encounter
Trust us, you will encounter problems when you start using the Client Object Model. You are not alone! For example, authentication with OAuth 2.0 can be quite complicated. Every implementation of OAuth 2.0 can be different as it has not quite been standardized yet. This blog post by Matthias Leibman gives a good overview of using OAuth 2.0 with the Office 365 API.
A lot of other blog posts have been written on common issues while using the Office 365 API. So let me give you a head start by pointing out some interesting reads: Soeren Nielsen, Chris O’Brien and Vadim Gremyachev are worth reading!
CSOM and PowerShell do not guarantee better Code Quality
Get Started Now
I hope all of this gives you enough confidence to start using PowerShell and the Client Object Model to write code against SharePoint Online. It can be a little intimidating at first, given the complexity of the work required. However, spare a thought for developers back in 2003 – in the beginning it was no fun at all with only a couple of cmdlets available. Nonetheless, we’ve seen things improve a lot since then and the tools available now really do make the work a lot easier. And, of course, the API is still evolving and new functionality is added regularly, so we expect that it will become better and better!