Windows PowerShell for SharePoint 2013 learning roadmap

SharePoint 2013

We are in the process of combining the SharePoint Server 2013 and SharePoint Server 2016 content into a single content set. We appreciate your patience while we reorganize things. See the Applies To tag at the top of each article to find out which version of SharePoint an article applies to.


Applies to: SharePoint Foundation 2013, SharePoint Server 2013

Topic Last Modified: 2016-12-16

Summary:Use this learning roadmap to understand Windows PowerShell for SharePoint 2013.

SharePoint 2013 makes it easy for people to work together. SharePoint 2013 enables you and your employees to set up web sites to share information with others, manage documents from start to finish, and publish reports to help everyone make informed decisions. Windows PowerShell in SharePoint 2013 lets an administrator automate tasks with SharePoint web applications, site collections, sites, lists, and more and provides a command-line alternative to configuring SharePoint 2013 through Central Administration.

If you are new to Windows PowerShell in SharePoint 2013, this article can help you identify what you need to learn to understand how to build expertise for Windows PowerShell in SharePoint 2013. It includes prerequisite articles that explain Windows PowerShell fundamentals. You have to understand the prerequisite technologies first. Windows PowerShell in SharePoint 2013 assumes that you understand basic concepts. Afterwards, you can start to learn about Windows PowerShell in SharePoint 2013 with the resources in the Level 100 (introductory), 200 (intermediate), and 300 (advanced) sections.

Learning Roadmap Banner

We recommend that you read the articles in the order listed.

This section contains links to articles and books that contain background information that will help you understand how Windows PowerShell in SharePoint 2013 works.

  • Step 1: Learn about the basics of Windows PowerShell.

    Before you start to use Windows PowerShell to automate tasks in SharePoint 2013, you have to understand the terms, concepts, and the use of objects to complete tasks. To understand why one would use Windows PowerShell and definition of terms, see Getting Started with Windows PowerShell

    Your goal is to understand the use, concept, terms, and role of Windows PowerShell.

  • Step 2: Learn the permission requirements for Windows PowerShell in SharePoint 2013.

    See Use Windows PowerShell to administer SharePoint 2013.

    Before you run a Windows PowerShell for SharePoint cmdlet, you have to understand the minimum required permissions. Membership in the Farm administrators group or being the Farm Administrator to the SharePoint farm is not sufficient permission to run SharePoint cmdlets. If you don't have required permissions, you might receive the following error message: "The local farm is not accessible."

    Your goal is to understand the permissions that are required to run a Windows PowerShell for SharePoint cmdlets.

The following resources contain introductory information about Windows PowerShell in SharePoint 2013

  • Learn about the Get-Command cmdlet.

    See Get-Command

    One of the first cmdlets (pronounced, command-lets) that you want to learn to use is the Get-Command cmdlet. Think of this cmdlet as the command inventory. It displays all the cmdlets that are available in the current Windows PowerShell session. The construct of a cmdlet is Verb-Noun object. Verbs are action-oriented words, such as Add, Get, Set, Update, for example. Nouns describe what command to act on, such as SPSite or SPUser. Notice that all nouns for SharePoint 2013 begin with "SP."

    The following table shows examples of how verbs and nouns combine to create cmdlet names:











    To display a list of all available Windows PowerShell cmdlets, you can use the Get-Command cmdlet. The result will display Windows PowerShell core cmdlets and SharePoint 2013 cmdlets. To only display a list of all SharePoint 2013 cmdlets, from the Windows PowerShell Command Prompt window, use the -Noun parameter together with "SP" and the wildcard character (*). The resulting syntax would be displayed as follows:

    Get-Command -noun SP*

    Conversely, you can use the -Verb parameter to display cmdlets that begin with a specific verb, for example, "Get", the syntax would look this this:

    Get-Command -Verb get

    Your goal is to display a list of all available Windows PowerShell cmdlets for SharePoint 2013, by noun or by verb.

  • Step 2: Learn about the Get-Help cmdlet..

    See Get-Help

    This cmdlet displays help information for any Windows PowerShell cmdlet. . It has three levels of display: Normal, Detailed, and Full.

    For example, if you want to display complete help for the Get-SPSite cmdlet, from the Windows PowerShell Command Prompt, type the following syntax:

    Get-Help Get-SPSite -Full

    To show examples only for the Get-SPSite cmdlet, type the following syntax:

    Get-Help Get-SPSite -Examples

    For an interactive tool and guide that helps you learn Windows PowerShell syntax, see Windows PowerShell Command Builder Tool

    Your goal is to understand how to obtain and use help for Windows PowerShell cmdlets for command syntax or for examples.

The following resources contain intermediate information about Windows PowerShell in SharePoint 2013.

  • Step 1: Learn about the pipeline.

    See about_Pipelines

    Simply put, the concept of the pipeline passes one object of a command to another. The result of the first command is an input for the next command. For more information, see Piping and the Pipeline

    For example, you might want to display SharePoint services that are running on your computer. Use Get-Service cmdlet to display all available services. This result will serve as input for the second command, the Where-Object cmdlet, where you'll filter to show SharePoint services. The result is a sorted list of SharePoint services. From a Windows PowerShell Command Prompt, type the following syntax:

    Get-Service | Where-Object {$_.DisplayName -like "Sharep*"}

    The result should resemble the following:







    SharePoint Server Search 15



    SharePoint Administration



    SharePoint Search Host Controller



    SharePoint Timer Service



    SharePoint Tracing Service



    SharePoint User Code Host



    SharePoint VSS Writer

    Your goal is to understand the concept of a pipeline, why you use it, and when to use it.

  • Step 2: Learn about parameter sets.

    See Parameter Sets Information

    Parameter sets provide multiple ways to use the same command. Parameter sets are mutually exclusive. You can't combine parameters from different parameter sets.

    For example, the Get-SPSite cmdlet has four different ways that it can be used. The multiple lines of syntax make it a parameter set. Each takes a different parameter set.

    Here is the syntax for the Get-SPSite cmdlet:

    Get-SPSite [-AssignmentCollection <SPAssignmentCollection>] [-CompatibilityLevel <Int32>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WebApplication <SPWebApplicationPipeBind>] [-WhatIf [<SwitchParameter>]]

    Get-SPSite [-Identity] <SPSitePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-CompatibilityLevel <Int32>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-Regex <SwitchParameter>] [-WhatIf [<SwitchParameter>]]

    Get-SPSite -ContentDatabase <SPContentDatabasePipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-CompatibilityLevel <Int32>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WhatIf [<SwitchParameter>]]

    Get-SPSite -SiteSubscription <SPSiteSubscriptionPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-CompatibilityLevel <Int32>] [-Confirm [<SwitchParameter>]] [-Filter <ScriptBlock>] [-Limit <String>] [-WhatIf [<SwitchParameter>]]

    In this syntax, the parameter that makes each parameter set unique is bold. If you decide to use the WebApplication parameter, then you can only use the parameters from the first parameter set. You can't use the Regex parameter from the second parameter set. If you use parameters from different sets, you receive the following error message: "Parameter set cannot be resolved".

    Your goal is to understand and use parameter sets correctly.

  • Step 3: Learn about the Get-Member cmdlet

    See Get-Member

    To display a list of all the methods and properties that are associated with any cmdlet, use the Get-Member cmdlet.

    For example, you might want to know the web application, zone, and owner information for each site collections in your farm. The default output of the Get-SPSite cmdlet displays none of these properties. To complete this task, you could go to the SharePoint Central Administration website and see the web application, zone and owner information that is defined for each site collection. If you have hundreds or thousands of site collections, this could take some time. The Get-Member cmdlet displays all of the properties and methods of a cmdlet. So, using piping and the following simple lines of syntax is more efficient than using the SharePoint Central Administration website.

    First, determine whether web application, zone, and owner properties are available by typing this syntax:

    Get-SPSite | Get-Member

    You will see the owner, webapplication, and zone properties are available.

    Next use the Format-List cmdlet and pipe the properties that you want to display by typing the following syntax:

    Get-SPSite | Format-List owner, webapplication, zone

    Another way to use the Get-Member cmdlet is to use variables that store values. The variable will be used to display quota level information for each site collection in the SharePoint farm. For more information about variables, see about_Variables.

    We'll use a variable, $a, to store the results of every site collection in the farm, and then we'll use the properties that Get-Member cmdlet returns. This example displays quota-level information for each site collection.

    First, set a variable that will contain the result of each site collection.


    Next, use the variable and any property that the Get-Member cmdlet returned to perform an action. This example uses the Quota property to display the quota levels.


    We could have easily used the Secondary Contact property to display the secondary contacts for each site collection in the farm or the Owner property to return the owner of each site collection. Hopefully you can see the power of the Get-Member cmdlet.

    Your goal is to understand how to display and use the properties and methods of a cmdlet by using the Get-Member, Format-List cmdlets, and variables.

  • Step 4: Learn about aliasing

    See about_Aliases.

    Sometimes you use cmdlet names that are long or repeatedly use the same cmdlet. In these cases, you might want to use aliasing. Simply put, an alias is another name that is assigned to a cmdlet, function, or script. If a cmdlet does not have an alias, you can use the Set-Alias cmdlet to create or change an alias for an existing cmdlet, script or function. To display a list of default aliases within Windows PowerShell, use the Get-Alias cmdlet.

    The Get-Alias cmdlet is a good start, but what if you want to find an alias that belongs to a specific cmdlet? You can use the Get-Alias cmdlet and the Where-Object cmdlet to filter a set of results to achieve this goal.

    This example returns a list of aliases with the Add noun. From a Windows PowerShell Command Prompt, type the following syntax:

    Get-Alias | Where-object {$_.Definition -like "add*"}


    CommandType Name Definition







    If a certain SharePoint cmdlet does not have an alias, you can use the Set-Alias cmdlet to create an alias. The following example creates the "gsp" alias for the Get-SPSite cmdlet.

    Set-Alias gsp Get-SPSite

    Now when you type the following syntax from the Windows PowerShell command prompt, all of the site collections in your farm are displayed:

    By default, no aliases are defined for any SharePoint 2013 cmdlet. You must create an alias for each SharePoint cmdlet that you want to use. After you create a list of custom aliases, you must guarantee that they are saved. By default, custom aliases are stored in the current active Windows PowerShell session. After you close the session, all custom aliases are lost.

    To save custom aliases, use of the following options:

    1. Use the Export-Alias cmdlet to export the aliases to a file, and then use the Import-Alias cmdlet to import the file to your Windows PowerShell session.

    2. Add the Set-Alias cmdlet to your Windows PowerShell profile.

    For more information about how to save custom aliases to your Windows PowerShell session by using the Export-Alias, Import-Alias, or Set-Alias cmdlets, see the "Keeping Aliases Around" section in Windows PowerShell Aliases.

    Your goal is to understand when to use aliasing, how to create aliases, and how to save them across Windows PowerShell sessions.

The following resources contain advanced information about Windows PowerShell in SharePoint 2013.

  • Step 1: Learn about scripting.

    See the "Scripts and execution policy" section of Use Windows PowerShell to administer SharePoint 2013.

    Levels 100 and 200 demonstrate how to run a single command, a series of commands, and a series of commands that are piped to complete a task. But what if you want to update a certain property for several thousand site collections in a SharePoint farm or you want to create 10,000 users? Although you could use the SharePoint Central Administration website to complete this task, it would take you days if not weeks. Windows PowerShell scripting enables you to complete these tasks in minutes or even seconds.

    Scripting is an automated way to complete a series of commands. A script is a text file that contains one or more Windows PowerShell commands. Windows PowerShell scripts have a .ps1 file name extension. Before you can run a script, you must understand the concept of execution policies. For more information, see about_Execution_Policies.

    No one, not even the original owner of the script, can run a script until the execution policy level is changed from Restricted to another level. The Restricted policy is the default policy for Windows PowerShell. However, the minimum required execution policy for SharePoint 2013 is RemoteSigned.

    To understand scripting concepts, see Running Windows PowerShell scripts.

    To view and download sample scripts for SharePoint 2010 and 2013, see Script Gallery

    Your goal is to understand the permission that is required to run scripts and how to execute a script file.

Your feedback is valuable and welcome! Please rate this content by using the Did you find this helpful section at the bottom of the article, or send your comments and suggestions to SharePoint IT Documentation Feedback ( The author will review your comments and use them to help improve this documentation. Your e-mail address won't be saved or used for any other purposes.