Provisioning SharePoint configuration from templates is very convenient, but works only on Windows. What if the Office 365 CLI supported PnP Provisioning Templates?
Structured and repeatable provisioning of SharePoint configuration
The true power of SharePoint are its rich customization capabilities. Organizations across the world tailor SharePoint to their needs to work more efficiently and effectively.
Many configuration settings can be changed directly in SharePoint's web interface. If you however, need to apply many changes, you have to apply them consistently to many sites or want to test them first before deploying to your production tenant, you will very likely automate provisioning your configuration. It will not only save you time in the long run, but will also help you avoid hard to track and nearly impossible to reproduce human errors due to missed configuration steps.
Automate provisioning SharePoint configuration using the PnP Provisioning Engine
A few years ago, the SharePoint Patterns and Practices team started working on a solution, that organizations could use, to provision their SharePoint configuration in a structured and repeatable way. Fast-forward to today, the PnP Provisioning Engine is the defacto standard for provisioning SharePoint configuration both online and on-premises. Being continuously developed by the SharePoint PnP team and the community, it covers a multitude of SharePoint configuration options. In fact, some of the biggest organizations in the world who use SharePoint, use the PnP Provisioning Engine every day to create sites and configure SharePoint to their specific needs.
Using XML-based templates, you can describe the configuration that you want to provision to SharePoint. The PnP Provisioning Engine parses your template and configures SharePoint accordingly. It's very convenient that provisioning templates are XML-based. They're self-documenting and if you need a more user-friendly document, you could use XSLT. And because they describe the final configuration state rather than the configuration steps that take you there, you can easily see how each template will configure SharePoint.
The PnP Provisioning Engine is a part of the PnP Core Component, which thousands of developers all over the world use to simplify communicating with SharePoint. But this powerful dependency comes with a price. Similarly to the SharePoint Client-Side Object Model (CSOM) and the PnP Core Component, the PnP Provisioning Engine works only on Windows.
Microsoft on any platform
For a while now, we've been able to use .NET on platforms other than Windows. Earlier this week, we've seen the general availability of PowerShell Core which also works on any platform. It all is a part of a bigger shift within Microsoft, to support as broad group of users as possible. No matter if you're working on Windows, macOS or Linux, you can use Microsoft products efficiently. But some things are hard to change.
The SharePoint Client-Side Object Model dates back quite a few years. It turns out, that it has a few dependencies that don't work beyond Windows. So to have CSOM available cross-platform, would mean refactoring it. We're yet to see if this will ever happen. Meanwhile, a group of users working on operating systems other than Windows is left with nothing but the option to run a Windows virtual machine.
"...manage anything from anywhere"
For a while now I've been working on the macOS. Regularly I'd found myself booting up a VM to be able to work with the latest features Microsoft deployed to Office 365. Finally, late last year I decided to build a command-line interface that I could use to manage Office 365 and its settings without having to use a VM. What started with a solution to a problem I was experiencing every day, became a community-driven project under the SharePoint PnP umbrella.
Since then, the Office 365 CLI has been steadily expanding, covering more features every day. SharePoint offers very broad configuration capabilities, and we have still a long way to go to be anywhere near the SharePoint Online Management Shell and PnP PowerShell available on Windows. If you think of the whole Office 365, we have even further to go. But we're getting there, one command at a time, and so far we had some great community support from Velin Georgiev, Andrew Connell, Robert Schouten, Daniel Laskewitz and many others who have been using the Office 365 CLI and providing us with feedback.
Recently, Jeffrey Snover, who architects PowerShell, said:
"What we're doing with PowerShell Core is we're hitting the refresh button," Snover told us. "We're keeping all the things that were great and we have the courage to leave behind the things that don't bring us to where we want to be. And where we want to be is a tool that allows companies to manage anything from anywhere."
"[...] manage anything from anywhere.", like Office 365 and SharePoint on a macOS, and you can do that today already with the Office 365 CLI, in PowerShell Core if you prefer.
SharePoint provisioning on any platform
One of the most used capabilities of PnP PowerShell is the PnP Provisioning Engine. Using a single cmdlet, developers and administrators can provision everything from a single list item, to hundreds of highly-customized sites. That's pretty powerful, if you ask me. But it's possible only on Windows. What if, you could provision configuration from PnP Provisioning Templates using the Office 365 CLI?
The PnP Provisioning Engine is a very powerful and complete solution, and it's not trivial to rebuild it from scratch to have it work on any platform. There are a lot of technical nuances in the engine, such as tokens, logic for handling dependencies between the different elements or support for extensions handling custom processing, not to manage the sheer coverage of SharePoint configuration it's capabable of provisioning. It's not my intention to rebuild the whole engine, but what if with a little effort, we could have the Office 365 CLI provision SharePoint configuration for us?
What you see above is a proof of concept of how the Office 365 CLI could handle provisioning. It's driven by commands available in the CLI, so the more commands are added to the CLI, the more elements can be provisioned from a template. This approach has some limitations comparing to the sophisticated logic available in the PnP Provisioning Engine, but perhaps it's good enough. I know, that it would save me some time, typing multiple commands and is definitely something that I would use myself.
What about you, if the Office 365 CLI supported provisioning configuration from PnP Provisioning Templates, would you care?