Edit: It seems Chris O’Brien has been thinking about the same problem, and has a good post about it.

Microsoft claim that Office 365 has PowerShell support. I had assumed that this meant that most, or at least many, of the PowerShell commands I can use in a normal farm would also be available in Office 365.

I was wildly, spectacularly wrong.

SharePoint has, normally, hundreds of PowerShell commands. Office 365 SharePoint has a few dozen. I had no idea the two APIs were so different. Want to get an SPWeb? Forget it. Saying that Office 365 has PowerShell support is disingenuous; a qualifier like “Very limited” is necessary.

But in a way, this makes sense, to me at least. You can call C# objects in PowerShell, which would include the Client Site Object Model (CSOM), and it always seemed to me that there was a bit of duplication in the C# and PowerShell APIs.

Okay, so I can use CSOM to talk to my Office 365 SharePoint instance and actually do useful things. This does mean you’re limited to doing what the CSOM API allows you to do, and some activities are a bit of a faff. Others aren’t possible – for example, configuring the Metadata Navigation features on a list.

To me, though, this then raises a further question – why would I bother with PowerShell? I need to understand the C# client side object model anyway, and I’m always going to have Visual Studio to hand – I can quite happily live with the ‘compile’ phase of using C# code for the easier writing and debugging of the code. Hell, I’ll do it to avoid all the $ symbols. And all this is to automate the deployment of a particular configuration of a site to a number of site collections – it’s pretty much use a few times, then throw away.

Over the next few posts I’ll examine performing some of these activities in CSOM.

Edit: Brought this post forward after seeing Chris’