The release of SharePoint 2010 (both SharePoint Foundation and SharePoint Server) offers welcome support for Windows PowerShell. Of course it has always been technically possible to use PowerShell to manage SharePoint but that involved doing a lot of work yourself to call the .NET Framework and work directly with the SharePoint Object Model or Web Services. But now it’s official, and administrators get to use the power of PowerShell out of the box.
I'll show you the PowerShell implementation in SharePoint, the requirements for accessing it, and the possibilities it brings to the administration table. I assume that you have a general understanding of PowerShell 2.0 and its concepts.
Positioning STSADM and PowerShell
Before SharePoint 2010, the only command-line tool available to administer SharePoint was STSADM. STSADM still ships with SharePoint 2010 because some commands don't yet have direct PowerShell equivalents (e.g., enabling the developer dashboard), and you might still need it to support any management utilities you built that you want to continue to use against your 2010 deployment.
STSADM is itself an extensible command-line tool (182 commands were available out of the box with Microsoft Office SharePoint Server 2007—MOSS 2007) and has been put to good use in many deployments. Gary Lapointe (stsadm.blogspot.com) provides some great examples for not only extending STSADM but also building your own PowerShell cmdlets. That said, it's likely that PowerShell will ultimately be the sole command-line utility for management in the future, and STSADM will gracefully fade away as Microsoft focuses resources on a single tool that's used across multiple server applications.
PowerShell is more flexible than STSADM in its extension capabilities. It also performs far more efficiently, especially in the batch processing area, because, with STSADM, each operation has to physically invoke the STSADM executable.
Loading the SharePoint Cmdlets
The first step to using the SharePoint cmdlets is to fire up a shell and load the Microsoft.SharePoint.PowerShell snap-in. You can do this manually via the Add-PSSnapin cmdlets, but you don't actually have to, as the installation adds the SharePoint 2010 Management Shell shortcut, which does this for you, to the Start menu. If you choose to do it manually, the command behind the shortcut is
C:\Windows\System32\WindowsPowerShell\v1.0\
PowerShell.exe -NoExit " & ' C:\Program Files\
Common Files\ Microsoft Shared\Web Server
Extensions\14\CONFIG\ POWERSHELL\
Registration\\sharepoint.ps1 ' "
This launches a shell, which then invokes the sharepoint.ps1 script. Inside that script, the cmdlet Add-PsSnapin Microsoft.SharePoint.PowerShell is executed.
You'll find 531 cmdlets in the snap-in that you can use for your administrative delights (SharePoint Foundation 2010 adds “only” 244, so this gives you a good feel for the added features that are in SharePoint Server 2010). The number of cmdlets increases as you layer on other features such as Office Web Applications, FAST search, or PerformancePoint. To get a list of all the SharePoint cmdlets, simply execute the following:
PS> get-command
–Module Microsoft.SharePoint.PowerShell | ft name
You can see sample output from this command in Figure 1.
Permissions Required
The permissions for being able to execute SharePoint cmdlets are pretty strict—indeed, they essentially mean you have to be a server administrator and a SQL Server administrator. The requirements are as follows:
1. Your account must be assigned the SharePoint_Shell_Access role on any SQL Server databases against which PowerShell will be used, both configuration and content databases. Note that this role is nested into the db_owner role, which means you have full access to the database (and all site collections held within) to do whatever you like—intentionally or not!
2. Your account, or a group that you are a member of, must be a member of the WSS_ADMIN_WPG local group on all servers in the farm.
3. You must be a site collection administrator on any site collection that you will manage via PowerShell.
These are heavy requirements for using PowerShell and will come as a disappointment to those people who had envisioned being able to script the management of their own site collections. We can only hope that support will extend to this scenario in the future. Indeed, if SharePoint follows what Microsoft has done with Exchange in this area, we should expect that role-based access control will be embedded into PowerShell so that users can perform only those actions allowable with their normal permissions to the site collection.
The cmdlet Add-SPShellAdmin can be used to grant the user the correct SQL Server roles and to add the user to the WSS_ADMIN_WPG group on all servers. You can use Add-SPShellAdmin to provide access to those cmdlets that touch the configuration database (such as Set-SPFarmConfig), and content databases, by providing the -Database parameter. For example, the following commands grant the user DOMAIN\KLAAHS shell access to the content database called WSS_Content:
$db = get-SPContentDatabase WSS_Content
Add-SPShellAdmin –Username DOMAIN\KLAAHS
-database $db
Accessing Cmdlets Remotely
PowerShell 2.0 supports remote execution (leveraging Windows Remote Management), which lets you execute cmdlets without having to physically log on to your SharePoint servers. Instead, you can run a local PowerShell on your workstation and execute commands remotely against your SharePoint servers.