Nikolas Charlebois-Laprade - Beginning PowerShell for SharePoint 2016: A Guide for Administrators, Developers, and DevOps Engineers

(1)

(2)

In IT organizations it is common to find a clear distinction between the developers and the administrators. Developers create new modules and functionalities for systems, and administrators are responsible for implementing and deploying them to production environments. Administrators are also normally in charge of configuring and maintaining the environments where these solutions have been deployed. In many cases, developers create solutions without really grasping what their solution will imply for configuration. They give the administrators the instructions to implement their product, and off they go. Even in the SharePoint world, this is often the case.

Weve worked in several IT organizations that have been dealing with the technology, and weve seen many cases in which administrators have to perform hours of manual intervention to configure solutions properly across all sites in a SharePoint environment. To give you a concrete example, think of a typical scenario in which a development team creates a new web part that needs to be added to all existing webs in an environment. What if the environment includes 10,000 web pages spread across multiple site collections? To think that someone is going to go through each of these and manually add the web part is pure craziness. This type of situation highlights the need for a solution that would let the administrators responsible for implementing solutions automate tasks in a repeatable fashion.

Before PowerShell was available, we had to create .exe applications using .NET console applications or .NET windows applications, or even develop extra ASP.NET pages or web parts to apply what is needed to the SharePoint farm. When PowerShell came around, near the end of SharePoint 2007s life, it was like a revelation. Now, we could have the same repetitive configuration tasks being executed against the server, but they were no longer contained in these black boxes that were the console applications. They were now stored as plain-text PowerShell scripts that administrators could open to peek at the logic they contained. For the record, PowerShell scripts are stored as .ps1 files and can be edited using any text editor software. We personally use Notepad++ for all our scripts, but there are some other good free alternatives that offer advanced features such as the automatic completion of command names after a few characters to help speed the writing process. The problem, however, was that if you didnt know your way around the .NET programming world, chances were that you would be totally lost in the code. SharePoint 2007 did not provide any PowerShell methods to interact with its components. You had to load the SharePoint assemblies into your PowerShell sessions and interact with the .NET objects directly. It was basically the same as writing your code in Visual Studio.

SharePoint 2010 then came to the rescue. It offered what we can call shortcut methods, or cmdlets (pronounced command-lets), that allowed users to interact with various SharePoint artifacts in a very straightforward and easy way. For example, assume that you are trying to get the title of a specific SharePoint web in your environment. In the SharePoint 2007 world, this had to be achieved using the something similar to the following lines of PowerShell:

Using PowerShell with SharePoint, the same operation can now be achieved using the following two lines of PowerShell:

This new way of using PowerShell to interact with SharePoint not only made scripts simpler, it also made them more readable. Administrators wanting to write scripts no longer had to know the SharePoint object model inside-out in order to build powerful PowerShell scripts (although it definitively helped).

PowerShell is not just for administrators, however. Complex scripts might still require some level of programming skill in order to be completed. In many organizations, developers are still responsible for writing the PowerShell scripts for maintenance tasks. This is an interesting paradigm, because it forces them to be aware of how the administration modules of SharePoint actually work. If you want to have a PowerShell script developed for your organization that automates the creation of hundreds of crawled properties for your SharePoint search engine, the developer writing the script will need to understand the various search administrative components to develop the script. This means that, on one end of the spectrum, we need administrators to start understanding some high-level programming concepts and understand the SharePoint object model to some level, and, on the other end, we have developers who need to be more open-minded about the administration aspect and learn how to configure the administrative components of SharePoint properly. Figure illustrates this concept.

Throughout this book, we will cover material that in a traditional mind-set would be specific to SharePoint administrators, such as timer jobs, health monitors, and backups, but we will also touch on topics that developers would normally be more familiar with, such as lists and list items. In writing this book, our goal was to try to bring traditional SharePoint developers to learn more about the administration aspect of the product, and for administrators to learn more about how the various artifacts are organized in the SharePoint object model. Therefore, by the time you finish reading this book, we hope to bring you out of your comfort zone by opening your horizons and making you understand the possibilities to bring as many developers and administrators on par with regard to their SharePoint skillsets.

Microsofts latest scripting language, PowerShell, was first released in the Fall of 2006, just a few months before the release of SharePoint 2007. Because of the parallel development schedule for the two products, SharePoint 2007 never really had any integration points with PowerShell. You could interact with your environment using PowerShell and by making direct calls to objects inside the SharePoint assemblies, but that was never really publicized or even recommended by Microsoft as an official way of managing your systems. SharePoint administrators had to manage their environments using a legacy command-line tool called Stsadm that was first introduced with the original release of SharePoint, then called SharePoint Team Sites (STS).