Sharepoint 2013 : Working with PowerShell (part 1) - PowerShell Basics

Loading the SharePoint Cmdlets

Microsoft has provided a number of SharePoint-specific Cmdlets, so you can easily manipulate SharePoint objects (applications, site collections, sites, lists, etc.) via PowerShell. These Cmdlets are available to you via a DLL plug-in, which you must enable in a regular Windows PowerShell window. If you launch the SharePoint Management Shell, the shell preloads the SharePoint Cmdlets for you. Type the following commands into your PowerShell window to see if you have the SharePoint Cmdlets loaded:

Get-PSSnapin -Registered | Where-Object { $_.Name -eq "Microsoft.SharePoint.PowerShell" }

The preceding command executes a PowerShell Cmdlet to get all registered snap-in objects, which you then pipe to another built-in Cmdlet, called Where-Object, to filter the list to a specific snap-in for SharePoint. If the SharePoint snap-in is loaded, you should see details about the registered snap-in object. If the preceding command produces no output, you can register the snap-in with the following:

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

After adding the snap-in, re-run the script to check for the registered snap-in, and you should see details of the snap-in.

PowerShell Syntax

Once you start using PowerShell frequently, you will understand the terminology and syntax for PowerShell Cmdlets and script notation. PowerShell Cmdlets assume the syntax verb-prefix noun. The verb always indicates the action on the Cmdlet, and PowerShell supports the verb standards, listed in Table 1.

The prefix in a Cmdlet is usually a two-letter qualifier that identifies the technology; for example, PS identifies PowerShell, AD identifies Active Directory, and SP identifies SharePoint. Finally, the noun is the affected object or resource; for example, Get-SPSite calls the SharePoint Cmdlet to “get” a new SharePoint “site” object.

Exploring SharePoint Cmdlets

As I mentioned in the earlier sections, SharePoint provides a number of Cmdlets, enabling you to interface with SharePoint and configure your farm. What do you do if you want to see a list of these Cmdlets? In using STSADM, you could provide the –o parameter to see a list of operations. Fortunately, PowerShell has a nice built-in Cmdlet called Get-Command.

Executing the Get-Command Cmdlet with no parameters will list every single available Cmdlet in PowerShell—yes, all of them! Passing the –Noun parameter to the Get-Command Cmdlet allows you to filter the list by a given noun name. If you cast your memory back to the previous section, you may remember that I mentioned standard syntax includes a noun prefix to identify the technology. SharePoint prefixes all nouns with “SP,” so you can easily get a list of all SharePoint Cmdlets as follows:

Get-Command –Noun SP*

The previous command uses a wildcard character, which tells the Get-Command Cmdlet to return any Cmdlets that start with “SP” and end with any other string of characters. There is still a large number of Cmdlets listed just for SharePoint operations; the following command tells us exactly how many (my install lists over 770):

(Get-Command –Noun SP*).Count

I think you need to narrow down the list; the Get-Command Cmdlet allows you to search for specific words in the noun. For example, if you wanted to list all the Cmdlets that deal with subsites (SPWeb) objects, you would use the following syntax:

Get-Command –Noun SPWeb

Figure 2 shows a much smaller (and manageable) list of Cmdlets. You can use the same trick to find all Cmdlets for site collection control—using the SPSite noun, rather than SPWeb.

Getting Help

Getting a list of PowerShell Cmdlets is good, but knowing more about a specific Cmdlet is better. PowerShell includes another built-in Cmdlet to get help for a specific Cmdlet: Get-Help. The Get-Help Cmdlet provides details about Cmdlets, providers, aliases, functions, and scripts. The following line demonstrates how to execute the Get-Help Cmdlet to get help about the Get-SPWeb Cmdlet:

Get-Help Get-SPWeb

Figure 3 shows a screenshot of the Get-Help Cmdlet used with the Get-SPWeb Cmdlet as a parameter. As you can see, the Get-Help Cmdlet displays the name, a synopsis, syntax, and description of the Cmdlet passed as argument. The syntax information is probably most important because it details the various arguments for the Cmdlet.

The Get-Help Cmdlet includes parameters to get information that is more detailed on a Cmdlet. Passing the –Examples parameter will return various examples to demonstrate the use of the Cmdlet. Passing the –Detailed parameter will give more detail beyond the basic information, and passing the –Full parameter will provide the complete help file for a Cmdlet. Try out the Get-Help Cmdlet on a number of well-known Cmdlets as well as some you have not encountered to get a good understanding of available help information.

The –Parameter argument is helpful in conjunction with the Get-Help Cmdlet because it provides details about a given parameter. Typically, when introduced to a new Cmdlet, you would use the Get-Help Cmdlet to get the syntax of available parameters and then provide the –Parameter argument to get details on a specific parameter for a Cmdlet. You can pass a * as the name to the –Parameter argument to get detailed information on all parameters supported by a Cmdlet.

Aliases

An alias is a shortcut for lengthy Cmdlets. For example, typing the lengthy Cmdlet named Get-SPBrowserCustomerExperienceImprovementProgram might get annoying quickly. By creating an alias for the Cmdlet, you can then use the alias in place of the full-length Cmdlet. Of course, I deliberately chose a Cmdlet name that stood out as long, but the likelihood of needing to get the browser customer experience program too often is small. However, this example does demonstrate that some PowerShell Cmdlets can get quite long.

The following example demonstrates how to create an alias, called web, for the Get-SPWeb Cmdlet:

Set-Alias –Name web –Value Get-SPWeb

You can then get the alias value with the following line:

Get-Alias web

To use the alias, simply replace the full name of the Cmdlet with the alias, complete with required parameters, as follows:

web http://sp2013

Pipelines

Pipelines, in my opinion, really set PowerShell apart from standard command-line operations in Windows. Pipelines allow passing of output information from one PowerShell script or Cmdlet to another. PowerShell deals with objects rather than strings, and this becomes apparent when using pipelines.

The following Cmdlet lists all SPList objects within the root web of a site collection:

(Get-SPSite http://sp2013).RootWeb.Lists

Looking at the preceding command, you see that I use parentheses around the Get-SPSite Cmdlet and then access the RootWeb property and Lists collection. This further illustrates the fact that PowerShell uses objects—the Get-SPSite Cmdlet returns a SPSite object, which has a property called RootWeb. Now, back to our discussion about pipelines.

If you execute the preceding command, you will get back pages of unhelpful information as PowerShell displays every SPList object returned from the Lists collection. By default, PowerShell displays all information about an object if you do not specify the property or method associated with the object.

The following modified example shows the same command piping the output to the ForEach Cmdlet. The ForEach Cmdlet iterates a collection and allows you to control fine-grained operation on each object in the collection.

(Get-SPSite http://sp2013).RootWeb.Lists | ForEach-Object { $_.Title }

The preceding command pipes the results to the ForEach Cmdlet, which iterates the collection and executes the commands in the curly braces. When working with Cmdlets that iterate over collections or filter collections, the special syntax $_ denotes the current object in the iteration. The preceding command outputs the title of each list in the collection.