INTRODUCTION TO WINDOWS POWERSHELL

In general, there is no requirement to use PowerShell to administer SharePoint. The vast majority of standard configuration options are exposed in the Central Administration UI. However, more advanced features, such as partitioning service applications for multi-tenancy, creating SharePoint databases without GUIDs, as well as automating common repetitive tasks, is where PowerShell begins to really shine. Plus, once you start using PowerShell you’ll wonder how you ever got along without it.

For example, creating multiple collections through Central Administration can be a time-consuming process, one at a time. However, you might find yourself in a situation where site collections in your development environment need to be reproduced in your production environment. With a little knowledge of PowerShell and the SharePoint cmdlets, you can generate a comma-separated list (.csv file) of all the site collections and supporting information in the development environment using the Get-SPSite and the Export-CSV cmdlets, and then use PowerShell’s Import-CSV cmdlet with the New-SPSite cmdlet in the production environment to recreate them with a single push of the Enter key. This same process using Central Admin would potentially take a tremendous amount of time and likely result in you spraining your mousing finger. No one likes that.

MICROSOFT SHAREPOINT 2013 MANAGEMENT SHELL AND OTHER HOSTS

PowerShell has been a staple of the Windows Server operating system since it came standard in Windows 2008. Windows 2008 R2 began including PowerShell version 2, which was great for SharePoint 2010 because it relied on PowerShell version 2 as a minimum. However, SharePoint 2013 requires PowerShell version 3. If you are installing SharePoint 2013 on Windows 2008 R2, the prerequisite installer will attempt to install version 3, unless Windows Management Framework 3.0 has already been installed. Thankfully, PowerShell version 3 has been included as the standard for Windows Server 2012, which simplifies things a bit if you are using the latest and greatest software available to SharePoint 2013.

Microsoft SharePoint 2013 Management Shell

The Microsoft SharePoint 2013 Management Shell, shown in Figure 1, is the out-of-the-box SharePoint command-line interface. True, it’s not much to look at. As a matter of fact, it looks a lot like the standard cmd.exe command-line interface. However, it’s a cleverly disguised PowerShell console, with the SharePoint commands registered and ready for use. Open the SharePoint 2013 Management Shell and PowerShell at the same time. If you squint, you might see that they look pretty similar. The only obvious difference is that the SharePoint Management Shell has a black background, whereas the standard PowerShell background is blue. They may look similar, but only the Management Shell will run the SharePoint commands without further configuration.

FIGURE 1

For example, if you run a very basic SharePoint command in both consoles, such as Get-SPSite, the Management Shell will happily return a list of site collections, whereas the PowerShell console won’t have a clue what you want it to do and it will make its displeasure very evident.

In other words, the SharePoint 2013 Management Shell is just the PowerShell .exe with a command-line parameter that points to a PSC1 file or a console file. The PSC1 file tells the PowerShell host to register the SharePoint commands. One other minor difference is that it also has a title bar that says SharePoint 2013 Management Shell, but otherwise the Management Shell is all PowerShell. If you’ve learned anything about PowerShell by working with other products such as Exchange or Windows, it all works here too.

Using Other Windows PowerShell Hosts

The Management Shell is the only host that is pre-configured to run SharePoint commands, but it is not the only host that an administrator can use. Two common hosts are available to administrators with Windows PowerShell version 3: the standard Windows PowerShell console and the Windows PowerShell Integrated Scripting Environment (ISE), shown in Figure 2. Administrators can also use any of the third-party PowerShell hosts available free or for purchase. Many of these boast a rich graphical user interface, although the rest of this chapter sticks with the Management Shell because it is most often used by administrators, but not telling you how to configure these other hosts would be like ordering a build-it-yourself bed only to find out you got all the parts but only half of the instructions.

FIGURE 2

We will be adding commands to the PowerShell ISE host, which provides a multiline editor with breakpoints and other help for scripting. Adding commands to other third-party hosts is similar, though you might need to consult their specific documentation if you run into any issues.

The ISE is installed with Windows Server 2008 R2 and Windows Server 2012 but it is not activated by default. To activate the ISE, use the Add Feature dialog of the Server Manager. Figure 3 shows the Server Manager’s Add Feature dialog with the ISE feature checked.

FIGURE 3

To register the SharePoint PowerShell commands with ISE, you must be working locally on a SharePoint 2013 server. The SharePoint 2013 PowerShell commands do not work from remote workstations.

If you find yourself in the standard PowerShell console, or one of the many PowerShell hosts available, and need SharePoint cmdlet functionality, you can use the Add-PSSnapin PowerShell command to register the SharePoint PowerShell cmdlets:

Add-PSSnapIn Microsoft.SharePoint.PowerShell

Add-PSSnapIn is a PowerShell command that registers add-on modules with the PowerShell console. The Microsoft.SharePoint.PowerShell snap-in contains the registration information for the SharePoint cmdlets.

This will get you started. To verify that the SharePoint 2013 commands are available in ISE, simply run a SharePoint command such as Get-SPSite. ISE should respond with a list of site collections in the farm. Note one tiny issue: You are required to add the Microsoft.SharePoint.PowerShell snap-in every time you start the host. To avoid this, you can run the command to add the snap-in to your profile, which will run each time you start a host.

You can locate your profile by typing $Profile into the command line, which will return the path to your profile. $Profile is a variable containing the current user’s profile location. The profile location may be different for each host. The ISE profile is different from the PowerShell profile, so commands for the ISE user’s profile will not interfere with other PowerShell hosts. If the profile exists already, you can use the following command to open it:

Notepad $Profile

If the profile exists, Notepad will open it. If the profile does not exist but the directory exists, Notepad will prompt you to create a new file. Add the Add-PSSnapin command with the Microsoft.SharePoint.PowerShell value into your ISE profile and save it. You need to restart ISE to read in the profile changes. When you need a command, variable, or function to persist between sessions, you can use the profile.

If you are authoring scripts to execute SharePoint cmdlets, it is a good idea to always start your scripts by loading the SharePoint snap-in with the Add-PSSnapin command because the script may be executed in a standard PowerShell console, or third-party host, at some point in the future. This ensures the script will always be able to run in any PowerShell host on a SharePoint server. The Get-PSSnapin command in the IF statement below checks to see if the snap-in is loaded. The –EA parameter is short for ErrorAction, and the “SilentlyContinue” suppresses errors that occur if the snap-in is already loaded. If the Get-PSSnapin command does not return a value, then the Add-PSSnapin is executed to load the SharePoint snap-in. More code could be added to check to see if a snap-in is even registered on the server, or to display text output based on the outcomes of the IF statement below, but that is beyond the scope of this book:

If((Get-PSSnapin Microsoft.SharePoint.PowerShell –EA SilentlyContinue) –eq 
$null){Add-PSSnapin Microsoft.SharePoint.PowerShell}