Background Information:
This article will dig deeper into the internals of PowerShell for SharePoint. It describes how SharePoint specific Cmdlets are defined and provides you with information to extend the default set of PowerShell Cmdlets that are made available by default to SharePoint administrators on a given SharePoint server. I will give an overview of how the various cmdlets and assemblies are defined in the SharePoint internal files, as well as give a quick overview of what these files contain. This article will be using a local SharePoint 2010 environment I have setup for demo purposes, but note that this also applies entirely to any SharePoint 2013 environment as well.
PowerShell Registration Folder:
With every SharePoint installation, comes a specific folder under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\ called the Hive. The hive normally contains all physical media files required by the SharePoint product to run properly on the server. A hive folder is always named by the version of the major Office release associated with it. For example, SharePoint 2007, which was associated with the 12th version of Microsoft Office (Office 2007) has a folder called the 12 Hive. For SharePoint 2010, Microsoft decided to jump over number 13 because of bad luck and had a folder called the 14 Hive, and one called the 15 Hive for SharePoint 2013. As mentionned above, in this article we will be using SharePoint 2010 as our base platform, therefore we will be looking at files under the 14 Hive (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\).
Figure 1 – Folders contained within the 14 Hive
What we are particularly interested in, is the PowerShell configuration folder found under [Hive]\CONFIG\POWERSHELL. This folder contains various subfolders that each serve a specific purpose. The one we are going to be covering with this article is the Registration folder which contains a list of various XML files that declare the available SharePoint Cmdlets we can use in our PowerShell sessions. By default, whenever you load the Microsoft.SharePoint.PowerShell snapin in a PowerShell console, all of the Cmdlets contained within the XML files in the Registration folder are loaded into the current PowerShell session. Figure 2 below shows the default XML files that will be registered for SharePoint 2010 SP2.
Figure 2 – Files under the PowerShell Registration folder in a SharePoint installation
We can see, by the name of the files, that the Cmdlets are divided into various functional files. The core file we are interested in is the one that contains all the Cmdlets definition for Windows SharePoint Services (WSS). WSS used to be the name of SharePoint Foundation in versions prior to SharePoint 2010 and it contains the core of all SharePoint Server operations. Thesecond node contained in that XML file are used to declare the assembly used to retrieve the logic behind the Cmdlets that are declared in the current file. For the Windows SharePoint Services XML file, the assembly is the core SharePoint one Microsoft.SharePoint.PowerShell. This assembly is actually registered in something we developer geeks refer to as the GAC, the Global Assembly Cache. Assemblies that are registered in the GAC can be accessed by Strong name only, meaning that we don’t have to specify their full local paht on disk in order to register them in memory. Figure 3 below shows the node, from the WSS XML file that makes a call out to the Microsoft.SharePoint.PowerShell assembly.
Figure 3 – PowerShell XML Registration file registering the Microsoft.SharePoint.PowerShell assembly
If we were to take a look at another PowerShell XML Registration file, OfficeServerCmdlets.xml for example, we would see that we are actually calling out to a different assembly, the Microsoft.Office.Server assembly.
Taking a closer look at that file, we realize that it is simply made up of the same type of tags over and over again. Figure 4 below shows the declaration node for the Get-SPSite Cmdlet we all know and love.
Figure 4 – Get-SPSite declaration from the Windows SharePoint Services PowerShell XML Registration file
What this tells us is that the Get-SPSite PowerShell cmdlet, when called upon, internally makes a call to the SPCmdletGetSite class inside of the Microsoft.SharePoint.PowerShell assembly. It also provides a link to a second related XML file that contains help related information describing what the cmdlet is actually about.
Adding your Own PowerShell Cmdlets to Extend SharePoint:
As part of the SPPoSh project, my goal had always been to have it plug in seemlessly into an existing SharePoint installation and have it extend the out-of-the-box cmdlet in a way that is almost transparent to the users. In order to achieve this, I had to develop my own PowerShell XML Registration file and have it call upon custom classes I had developped in the SPPoSh assembly. In order for you to be able to automatically register new custom PowerShell cmdlets, you’ll need to add your own custom PowerShell XML Registration file into the Registration folder of your SharePoint installation. By simply adding the file in the folder, PowerShell will take care of picking it up upon loading the SharePoint snapins in a PowerShell session. For SPPoSh what I did was create a new file from scratch and named it SPPoShCmdlets.xml. For the purpose of this article, I will keep the content of this file to a minimum and will pretend like we are only declaring the SPPoSh specific Get-SPList cmdlet. Figure 5 shows the content of what my file would look like.
