SharePoint 2010 PerformancePoint Services : Using Windows PowerShell and Cmdlets (part 1) - Cmdlets Available Out of the Box

STSADM, the command-line tool for managing SharePoint, is still included in SharePoint 2010 and retains SharePoint 2007 functionality. However, STSADM is being phased out, which means that none of the new SharePoint 2010 functions can be accessed by STSADM. However, all functions that are new to SharePoint 2010 are available through PowerShell. Because PPS is a new addition to SharePoint 2010, no supported features are available to manage PPS through STSADM.

Launching PowerShell

PowerShell can be launched using the Start menu on any server machine in the farm. It is located under the Microsoft SharePoint 2010 Products folder and is named SharePoint 2010 Management Shell. Launching from this location automatically loads SharePoint PowerShell objects and cmdlets.

If you create a script that is intended to run without the need to launch PowerShell from the SharePoint folder on the Start menu, this command loads all required SharePoint objects into the current PowerShell window or script:

Add-PsSnapin Microsoft.SharePoint.PowerShell

Cmdlet Reference

PPS cmdlets are the command-line style mechanism available to query information or to modify settings on various PPS system-level objects. PPS cmdlets are designed to integrate with the SharePoint cmdlet functionality. Cmdlets are divided into nouns and verbs. Nouns are types of objects to interact with, whereas verbs describe how to interact with types of objects. In addition, parameters are available for most objects depending on how you want to interact with an object. Nouns, verbs, and parameters are always combined in the following syntax:

 Verb-Noun -ParameterName1 ParameterValue1 -ParameterName2 ParameterValue2

These are the generally available verbs that can be used when working with PPS objects:

• New

• Remove

• Get

• Set

These are the nouns that are implemented by PPS:

• SPPerformancePointServiceApplication

• SPPerformancePointServiceApplicationProxy

• SPPerformancePointServiceApplicationTrustedLocation

• SPPerformancePointSecureDataValues

For example, to create a new service application, you would call the New verb with the SPPerformancePointServiceApplication noun. The syntax would look like this:

 New-SPPerformancePointServiceApplication -Name "MyFirstApplication" –AppPool "PPS
 App Pool" New-SPIisWebServiceApplicationPool

					  

This section summarizes the cmdlets that are available out of the box. These tables describe the parameters for each cmdlet.

The cmdlet in Table 1 creates a new PPS Service application with the specified parameters.

-Administrators {"domain\admin1","domain\admin2"}

The cmdlet in Table 2 retrieves an existing PPS service application with the specified parameters.

This cmdlet in Table 3 changes the settings of an existing PPS service application.

There are a number of values that are applicable to most of the New, Get, and Set SPPerformancePointServiceApplication cmdlets. These shared values can be used by all the cmdlets discussed earlier. The shared values control various settings, most of which are available to set in the Shared Service Administrative user interface.

For example, if you want to pass a parameter to disable all comments on scorecards when creating a new PPS shared service application, all you need is this cmdlet with the CommentsDisabled shared value:

New-SPPerformancePointServiceApplication -name "MyFirstServiceApplication"
-CommentsDisabled true

This same syntax also works with the Set-SPPerformancePointServiceApplication cmdlet:

Set-SPPerformancePointServiceApplication -name "MyFirstServiceApplication"
 -CommentsDisabled true

For retrieving the current value of this setting with the Get-SPPerformancePointServiceApplication cmdlet, you need to use this syntax:

(Get-SPPerformancePointServiceApplication –identity
"MyFirstServiceApplication").CommentsDisabled

Table 4 describes the shared values you can use with cmdlets.

Whenever you create a service application, best practice is to create a service application proxy to go with it. These go together like peanut butter and jelly; both are needed for each to work.

Table 5 describes a cmdlet that creates a new proxy for an existing service application.

The cmdlet in Table 6 is used to remove service application proxies when they are no longer needed. Just like with creation, best practice is to delete the proxy at the same time you delete the service application.

The cmdlet in Table 7 adds a new entry to the trusted data source or trusted content locations.

The cmdlet in Table 8 retrieves all trusted locations set for a specific service application.

The cmdlet in Table 9 removes a single entry as a trusted location.

Clear-SPPerformancePointServiceApplicationTrustedLocation

The cmdlet in Table 10 removes all trusted locations, including data source and content that have been set previously for a specific service application.

The cmdlet in Table 11 retrieves the status of the secure store target application and the name of the unattended service account.

The cmdlet in Table 12 sets the Unattended Service Account credentials.