Windows PowerShell is a command-line scripting tool that provides an administrator full access to applicable application programming interfaces (APIs), along with the ability to unlock the capability to interact directly with SharePoint 2010 Products to manipulate Web applications, site collections, sites, lists and much more. In addition, the administrator has the ability to script cmdlets (pronounced "command-lets"), which makes for an improved experience from past product versions.
Windows PowerShell 2.0 is a pre-requisite for installing SharePoint 2010 Products. It will be installed, if necessary, when you run the Microsoft SharePoint Products Preparation Tool. By default, Windows PowerShell is located at the following path: <%SystemRoot%>\System32\WindowsPowerShell\v1.0\PowerShell.exe.
Windows PowerShell 2.0 includes the following new features.
Remoting
Windows PowerShell 2.0 lets you run commands on one or many remote
computers with a single Windows PowerShell command. You can run
individual commands, or you can create a persistent connection
(a session) to run a series of related commands. You can also start a
session with a remote computer so that the commands you type run
directly on the remote computer.
The remoting features of Windows PowerShell are built on Windows
Remote Management (WinRM). WinRM is the Microsoft implementation of
the WS-Management protocol, a standard SOAP-based, firewall-compatible
communications protocol.
The remote computers must have Windows PowerShell 2.0, the Microsoft .NET
Framework 2.0, and the WinRM service. Remote commands are supported
on all operating systems that can run Windows PowerShell. The
current user must have permission to run commands on the remote
computers.
To support remoting, the Invoke-Command, Enter-PSSession, and
Exit-PSSession cmdlets have been added, along with other cmdlets
that contain the PSSession noun. These cmdlets let you create and manage
persistent connections.
The ComputerName parameter has also been added to several cmdlets,
including the Get-Process, Get-Service, and Get-Eventlog cmdlets. This
parameter allows you to get information about remote computers.
These cmdlets use .NET Framework methods to get their data,
so they do not rely on Windows PowerShell remoting. They do not require
any new programs or configuration.
Background Jobs
Background jobs are commands that run asynchronously. When you run a
background job, the command prompt returns immediately, even if the
command is still running. You can use the background job feature to run a
complex command in the background so that you can use your session for
other work while the command runs.
You can run a background job on a local or remote computer and then save
the results on the local or remote computer. To run a job remotely, use
the Invoke-Command cmdlet.
Windows PowerShell includes a set of cmdlets that contain the Job noun
(the Job cmdlets). Use these cmdlets for creating, starting, managing,
and deleting background jobs and for getting the results of a background
job. To get a list of the job cmdlets, type the following command:
get-command *-job
Script Debugger
Windows PowerShell 2.0 includes a cmdlet-based debugger for scripts and
functions. The debugger is supported by a fully documented public API
that you can use to build your own debugger or to customize or extend
the debugger.
The debugger cmdlets let you set breakpoints on lines, columns,
variables, and commands. These cmdlets let you manage the breakpoints
and display the call stack. You can create conditional breakpoints and
specify custom actions at a breakpoint, such as running diagnostic and
logging scripts.
When you reach a breakpoint, Windows PowerShell suspends execution
and starts the debugger. The debugger includes a set of custom commands
that let you step through the code. You can also run standard Windows
PowerShell commands to display the values of variables, and you can use
cmdlets to investigate the results.
Data Section
Scripts designed for Windows PowerShell 2.0 can have one or more
DATA sections that isolate the data from the script logic. The data in
the new DATA section is restricted to a specified subset of the Windows
PowerShell scripting language.
In Windows PowerShell 2.0, the DATA section is used to support
script internationalization. You can use the DATA section to isolate
and identify user message strings that will be translated into
multiple user interface languages.
Script Internationalization
Windows PowerShell 2.0 script internationalization features allow you
to better serve users throughout the world. Script internationalization
enables scripts and functions to display messages and Help text to users
in multiple languages.
The script internationalization features query the operating system user
interface culture ($PsUICulture) during execution and then import the
appropriate translated text strings so you can display them to the user.
The Data section lets you store text strings separate from code so that
they are easily identified. A new cmdlet, ConvertFrom-StringData,
converts text strings into dictionary-like hash tables to facilitate
translation.
WMI Cmdlets
The Windows Management Instrumentation (WMI) functionality of
Windows PowerShell 2.0 is improved with the addition of the following
cmdlets:
- Remove-WmiObject
- Set-WmiInstance
- Invoke-WmiMethod
New parameters have been added to the Get-WmiObject cmdlet. All the WMI
cmdlets now support the following parameters:
- EnableAllPrivileges
- Impersonation
- Authentication
- Authority
These new parameters give you more refined control over the security
configuration of your WMI operations without requiring you to work
directly with the types in the .NET Framework Class Library.
For a list of WMI cmdlets, type the following command:
get-help *wmi*
To get help for each cmdlet, type get-help followed by the cmdlet name.
The Get-WinEvent Cmdlet
The Get-WinEvent cmdlet gets events from Event Viewer logs and from
Event Tracing for Windows (ETW) event log files on local and remote
computers. It can get events from classic event logs and from the
Windows Event Logs that were introduced in Windows Vista.
You can use Get-WinEvent to get the objects that represent event logs, event
log providers, and the events in the logs. Get-WinEvent lets you combine
events from different sources in a single command. It supports
advanced queries in XML Path Language (XPath), XML, and hash table
format.
Get-WinEvent requires Windows Vista or Windows Server 2008 and the
Microsoft .NET Framework 3.5.
The Out-Gridview Cmdlet
The Out-GridView cmdlet displays the results of other commands in an
interactive table in which you can search, sort, group, and filter the
results. For example, you can send the results of a Get-Process,
Get-WmiObject, Get-WinEvent, or Get-Eventlog command to Out-GridView and
then use the table features to examine the data.
help out-gridview -full
The Add-Type Cmdlet
The Add-Type cmdlet lets you add .NET Framework types to
Windows PowerShell from the source code of another .NET Framework
language.
Add-Type compiles the source code that creates the types and generates
assemblies that contain the new .NET Framework types. Then, you can use
the .NET Framework types in Windows PowerShell commands along with the
standard object types provided by the .NET Framework.
You can also use Add-Type to load assemblies into your session so that
you can use the types in the assemblies in Windows PowerShell.
Add-Type allows you develop new .NET Framework types, to
use .NET Framework types in C# libraries, and to access Win32 APIs.
Event Notification
Windows PowerShell 2.0 introduces event notification. Users can register
and subscribe to events, such as Windows PowerShell events, WMI events,
or .NET Framework events. And, users can listen, forward, and act on
management and system events both synchronously and asynchronously.
Developers can write applications that use the event architecture
to receive notification about state changes. Users can write
scripts that subscribe to various events and that react to the content.
Windows PowerShell provides cmdlets that create new events, get
events and event subscriptions, register and unregister events,
wait for events, and delete events. For more information about these
cmdlets, type the following command:
get-command *-event
Modules
Windows PowerShell modules let you divide and organize your
Windows PowerShell scripts into independent, self-contained,
reusable units. Code from a module executes in its own context,
so it does not add to, conflict with, or overwrite the variables,
functions, aliases, and other resources in the session.
You can write, distribute, combine, share, and reuse modules to build
simple scripts and complex applications.
Windows PowerShell 2.0 includes cmdlets to add, get, and remove modules
and to export module members. For more information about the cmdlets
that are related to modules, type the following command:
get-command *-module*
Transactions
Windows PowerShell 2.0 includes support for transactions. Transactions
let you undo an entire series of operations. Transactions are available
only for operations that support transactions. They are designed for
applications that require atomicity, consistency, isolation, and
recoverability, like databases and message queuing.
Cmdlets and providers that support transactions have a new
UseTransaction parameter. To start an operation within a transaction,
use the Start-Transaction cmdlet. Then, when you use the cmdlets that
perform the operation, use the UseTransaction parameter of each cmdlet
when you want the command to be part of a transaction.
If any command in the transaction fails at any point, use the
Rollback-Transaction cmdlet to undo all the commands in the transaction.
If all the commands succeed, use the Commit-Transaction cmdlet to make
the command actions permanent.
Windows PowerShell 2.0 includes cmdlets to start, use, commit, and roll
back transactions. For information about these cmdlets, type the
following command:
get-command *transaction*
Accessing Windows PowerShell for SharePoint 2010 Products
After installing SharePoint 2010 Products, the applicable Windows PowerShell cmdlets are available by using the SharePoint 2010 Management Shell, or by using the Windows PowerShell console. With the management shell, you can manage every aspect of SharePoint 2010 Products. You can create new site collections, Web applications, user accounts, service applications, proxies, and more. The commands from the management shell output SharePoint objects based on the Microsoft .NET Platform. These objects can be applied as input to subsequent commands or stored in local variables for later use.
With the management shell, you do not have to register the snap-in that contains the cmdlets. Registration of the Microsoft.SharePoint.PowerShell.dll module for SharePoint 2010 cmdlets is automatic, as a result of the line Add-PSSnapin Microsoft.SharePoint.PowerShell in the SharePoint.ps1 file located in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Config\PowerShell\Registration. If you choose to use the Windows PowerShell console, you must register this snap-in manually.
Whether you are using the management shell or the Windows PowerShell console, you can also load additional snap-ins. For more information, see Customizing Profiles (http://go.microsoft.com/fwlink/?LinkId=183166).
To access the SharePoint 2010 Management Shell
1.On the Start menu, click All Programs.
2.Click Microsoft SharePoint 2010 Products.
3.Click SharePoint 2010 Management Shell.
The SharePoint 2010 Management Shell and the Windows PowerShell console also differ in the use of the ReuseThread option, which defines how the threading model is used. The management shell's use is defined by this line, {Host.Runspace.ThreadOptions = "ReuseThread"}, which is in the SharePoint.ps1 file. For more information, see PS Thread Options (http://go.microsoft.com/fwlink/?LinkId=183145).
Permissions
Before you can use the management shell and the Windows PowerShell cmdlets, verify that you meet the following minimum requirements:
If you do not have membership in the SharePoint_Shell_Access role or WSS_Admin_WPG local group, use the Add-SPShellAdmin cmdlet. When the Add-SPShellAdmin cmdlet is used, the user is added to the WSS_Admin_WPG group in all front-end Web servers and is added to the SharePoint_Shell_Access role. If the target database does not have a SharePoint_Shell_Access role, the role is automatically created. Once the Add-SPShellAdmin cmdlet has been run, the user can run SharePoint 2010 Windows PowerShell cmdlets in a multiple-server farm environment.
When you run the Add-SPShellAdmin cmdlet to add a user to the SharePoint_Shell_Access role, you must have the following security permissions:
* Securityadmin server role access on the SQL instance and the db_owner role in a database.
* Administrative permission on the local computer.
Typically, the person that will use the Add-SPShellAdmin cmdlet must be associated with the user account that was used for Setup.
You must run the Add-SPShellAdmin cmdlet for all databases to which you want to grant access. If no database is specified, the farm configuration database is used. If you do specify a database, the farm content database will be included in addition to the farm configuration database you specify.
To see a list of all of the *SPShellAdmin cmdlets, from a Windows PowerShell command prompt, type Get-Command -Noun SPShellAdmin.
Scripts and execution policies
Although you can use Windows PowerShell to perform a single administrative task, the real benefit of using Windows PowerShell cmdlets is the ability to use a script to automate a series of tasks. A script is a plain text file that contains one or more Windows PowerShell commands. Windows PowerShell scripts have a .ps1 file name extension.
When using a script, be aware that the minimum required execution policy for SharePoint 2010 Products is RemoteSigned, while the default policy for Windows PowerShell is Restricted. If the policy is left as Restricted, the SharePoint 2010 Management Shell will change the policy for Windows PowerShell to RemoteSigned. This means the SharePoint 2010 Management Shell must be launched with elevated administrative permission by selecting Run as administrator. This change will apply to all Windows PowerShell sessions.
Windows PowerShell 2.0 is a pre-requisite for installing SharePoint 2010 Products. It will be installed, if necessary, when you run the Microsoft SharePoint Products Preparation Tool. By default, Windows PowerShell is located at the following path: <%SystemRoot%>\System32\WindowsPowerShell\v1.0\PowerShell.exe.
Windows PowerShell 2.0 includes the following new features.
Remoting
Windows PowerShell 2.0 lets you run commands on one or many remote
computers with a single Windows PowerShell command. You can run
individual commands, or you can create a persistent connection
(a session) to run a series of related commands. You can also start a
session with a remote computer so that the commands you type run
directly on the remote computer.
The remoting features of Windows PowerShell are built on Windows
Remote Management (WinRM). WinRM is the Microsoft implementation of
the WS-Management protocol, a standard SOAP-based, firewall-compatible
communications protocol.
The remote computers must have Windows PowerShell 2.0, the Microsoft .NET
Framework 2.0, and the WinRM service. Remote commands are supported
on all operating systems that can run Windows PowerShell. The
current user must have permission to run commands on the remote
computers.
To support remoting, the Invoke-Command, Enter-PSSession, and
Exit-PSSession cmdlets have been added, along with other cmdlets
that contain the PSSession noun. These cmdlets let you create and manage
persistent connections.
The ComputerName parameter has also been added to several cmdlets,
including the Get-Process, Get-Service, and Get-Eventlog cmdlets. This
parameter allows you to get information about remote computers.
These cmdlets use .NET Framework methods to get their data,
so they do not rely on Windows PowerShell remoting. They do not require
any new programs or configuration.
Background Jobs
Background jobs are commands that run asynchronously. When you run a
background job, the command prompt returns immediately, even if the
command is still running. You can use the background job feature to run a
complex command in the background so that you can use your session for
other work while the command runs.
You can run a background job on a local or remote computer and then save
the results on the local or remote computer. To run a job remotely, use
the Invoke-Command cmdlet.
Windows PowerShell includes a set of cmdlets that contain the Job noun
(the Job cmdlets). Use these cmdlets for creating, starting, managing,
and deleting background jobs and for getting the results of a background
job. To get a list of the job cmdlets, type the following command:
get-command *-job
Script Debugger
Windows PowerShell 2.0 includes a cmdlet-based debugger for scripts and
functions. The debugger is supported by a fully documented public API
that you can use to build your own debugger or to customize or extend
the debugger.
The debugger cmdlets let you set breakpoints on lines, columns,
variables, and commands. These cmdlets let you manage the breakpoints
and display the call stack. You can create conditional breakpoints and
specify custom actions at a breakpoint, such as running diagnostic and
logging scripts.
When you reach a breakpoint, Windows PowerShell suspends execution
and starts the debugger. The debugger includes a set of custom commands
that let you step through the code. You can also run standard Windows
PowerShell commands to display the values of variables, and you can use
cmdlets to investigate the results.
Data Section
Scripts designed for Windows PowerShell 2.0 can have one or more
DATA sections that isolate the data from the script logic. The data in
the new DATA section is restricted to a specified subset of the Windows
PowerShell scripting language.
In Windows PowerShell 2.0, the DATA section is used to support
script internationalization. You can use the DATA section to isolate
and identify user message strings that will be translated into
multiple user interface languages.
Script Internationalization
Windows PowerShell 2.0 script internationalization features allow you
to better serve users throughout the world. Script internationalization
enables scripts and functions to display messages and Help text to users
in multiple languages.
The script internationalization features query the operating system user
interface culture ($PsUICulture) during execution and then import the
appropriate translated text strings so you can display them to the user.
The Data section lets you store text strings separate from code so that
they are easily identified. A new cmdlet, ConvertFrom-StringData,
converts text strings into dictionary-like hash tables to facilitate
translation.
WMI Cmdlets
The Windows Management Instrumentation (WMI) functionality of
Windows PowerShell 2.0 is improved with the addition of the following
cmdlets:
- Remove-WmiObject
- Set-WmiInstance
- Invoke-WmiMethod
New parameters have been added to the Get-WmiObject cmdlet. All the WMI
cmdlets now support the following parameters:
- EnableAllPrivileges
- Impersonation
- Authentication
- Authority
These new parameters give you more refined control over the security
configuration of your WMI operations without requiring you to work
directly with the types in the .NET Framework Class Library.
For a list of WMI cmdlets, type the following command:
get-help *wmi*
To get help for each cmdlet, type get-help followed by the cmdlet name.
The Get-WinEvent Cmdlet
The Get-WinEvent cmdlet gets events from Event Viewer logs and from
Event Tracing for Windows (ETW) event log files on local and remote
computers. It can get events from classic event logs and from the
Windows Event Logs that were introduced in Windows Vista.
You can use Get-WinEvent to get the objects that represent event logs, event
log providers, and the events in the logs. Get-WinEvent lets you combine
events from different sources in a single command. It supports
advanced queries in XML Path Language (XPath), XML, and hash table
format.
Get-WinEvent requires Windows Vista or Windows Server 2008 and the
Microsoft .NET Framework 3.5.
The Out-Gridview Cmdlet
The Out-GridView cmdlet displays the results of other commands in an
interactive table in which you can search, sort, group, and filter the
results. For example, you can send the results of a Get-Process,
Get-WmiObject, Get-WinEvent, or Get-Eventlog command to Out-GridView and
then use the table features to examine the data.
help out-gridview -full
The Add-Type Cmdlet
The Add-Type cmdlet lets you add .NET Framework types to
Windows PowerShell from the source code of another .NET Framework
language.
Add-Type compiles the source code that creates the types and generates
assemblies that contain the new .NET Framework types. Then, you can use
the .NET Framework types in Windows PowerShell commands along with the
standard object types provided by the .NET Framework.
You can also use Add-Type to load assemblies into your session so that
you can use the types in the assemblies in Windows PowerShell.
Add-Type allows you develop new .NET Framework types, to
use .NET Framework types in C# libraries, and to access Win32 APIs.
Event Notification
Windows PowerShell 2.0 introduces event notification. Users can register
and subscribe to events, such as Windows PowerShell events, WMI events,
or .NET Framework events. And, users can listen, forward, and act on
management and system events both synchronously and asynchronously.
Developers can write applications that use the event architecture
to receive notification about state changes. Users can write
scripts that subscribe to various events and that react to the content.
Windows PowerShell provides cmdlets that create new events, get
events and event subscriptions, register and unregister events,
wait for events, and delete events. For more information about these
cmdlets, type the following command:
get-command *-event
Modules
Windows PowerShell modules let you divide and organize your
Windows PowerShell scripts into independent, self-contained,
reusable units. Code from a module executes in its own context,
so it does not add to, conflict with, or overwrite the variables,
functions, aliases, and other resources in the session.
You can write, distribute, combine, share, and reuse modules to build
simple scripts and complex applications.
Windows PowerShell 2.0 includes cmdlets to add, get, and remove modules
and to export module members. For more information about the cmdlets
that are related to modules, type the following command:
get-command *-module*
Transactions
Windows PowerShell 2.0 includes support for transactions. Transactions
let you undo an entire series of operations. Transactions are available
only for operations that support transactions. They are designed for
applications that require atomicity, consistency, isolation, and
recoverability, like databases and message queuing.
Cmdlets and providers that support transactions have a new
UseTransaction parameter. To start an operation within a transaction,
use the Start-Transaction cmdlet. Then, when you use the cmdlets that
perform the operation, use the UseTransaction parameter of each cmdlet
when you want the command to be part of a transaction.
If any command in the transaction fails at any point, use the
Rollback-Transaction cmdlet to undo all the commands in the transaction.
If all the commands succeed, use the Commit-Transaction cmdlet to make
the command actions permanent.
Windows PowerShell 2.0 includes cmdlets to start, use, commit, and roll
back transactions. For information about these cmdlets, type the
following command:
get-command *transaction*
Accessing Windows PowerShell for SharePoint 2010 Products
After installing SharePoint 2010 Products, the applicable Windows PowerShell cmdlets are available by using the SharePoint 2010 Management Shell, or by using the Windows PowerShell console. With the management shell, you can manage every aspect of SharePoint 2010 Products. You can create new site collections, Web applications, user accounts, service applications, proxies, and more. The commands from the management shell output SharePoint objects based on the Microsoft .NET Platform. These objects can be applied as input to subsequent commands or stored in local variables for later use.
With the management shell, you do not have to register the snap-in that contains the cmdlets. Registration of the Microsoft.SharePoint.PowerShell.dll module for SharePoint 2010 cmdlets is automatic, as a result of the line Add-PSSnapin Microsoft.SharePoint.PowerShell in the SharePoint.ps1 file located in %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\14\Config\PowerShell\Registration. If you choose to use the Windows PowerShell console, you must register this snap-in manually.
Whether you are using the management shell or the Windows PowerShell console, you can also load additional snap-ins. For more information, see Customizing Profiles (http://go.microsoft.com/fwlink/?LinkId=183166).
To access the SharePoint 2010 Management Shell
1.On the Start menu, click All Programs.
2.Click Microsoft SharePoint 2010 Products.
3.Click SharePoint 2010 Management Shell.
The SharePoint 2010 Management Shell and the Windows PowerShell console also differ in the use of the ReuseThread option, which defines how the threading model is used. The management shell's use is defined by this line, {Host.Runspace.ThreadOptions = "ReuseThread"}, which is in the SharePoint.ps1 file. For more information, see PS Thread Options (http://go.microsoft.com/fwlink/?LinkId=183145).
Permissions
Before you can use the management shell and the Windows PowerShell cmdlets, verify that you meet the following minimum requirements:
If you do not have membership in the SharePoint_Shell_Access role or WSS_Admin_WPG local group, use the Add-SPShellAdmin cmdlet. When the Add-SPShellAdmin cmdlet is used, the user is added to the WSS_Admin_WPG group in all front-end Web servers and is added to the SharePoint_Shell_Access role. If the target database does not have a SharePoint_Shell_Access role, the role is automatically created. Once the Add-SPShellAdmin cmdlet has been run, the user can run SharePoint 2010 Windows PowerShell cmdlets in a multiple-server farm environment.
When you run the Add-SPShellAdmin cmdlet to add a user to the SharePoint_Shell_Access role, you must have the following security permissions:
* Securityadmin server role access on the SQL instance and the db_owner role in a database.
* Administrative permission on the local computer.
Typically, the person that will use the Add-SPShellAdmin cmdlet must be associated with the user account that was used for Setup.
You must run the Add-SPShellAdmin cmdlet for all databases to which you want to grant access. If no database is specified, the farm configuration database is used. If you do specify a database, the farm content database will be included in addition to the farm configuration database you specify.
To see a list of all of the *SPShellAdmin cmdlets, from a Windows PowerShell command prompt, type Get-Command -Noun SPShellAdmin.
Scripts and execution policies
Although you can use Windows PowerShell to perform a single administrative task, the real benefit of using Windows PowerShell cmdlets is the ability to use a script to automate a series of tasks. A script is a plain text file that contains one or more Windows PowerShell commands. Windows PowerShell scripts have a .ps1 file name extension.
When using a script, be aware that the minimum required execution policy for SharePoint 2010 Products is RemoteSigned, while the default policy for Windows PowerShell is Restricted. If the policy is left as Restricted, the SharePoint 2010 Management Shell will change the policy for Windows PowerShell to RemoteSigned. This means the SharePoint 2010 Management Shell must be launched with elevated administrative permission by selecting Run as administrator. This change will apply to all Windows PowerShell sessions.
Posts
