With SharePoint 2010, PowerShell replaces STSADM as the preferred administrative shell for SharePoint. STSADM will remain for backwards compatibility purposes, but there are many reasons to make the switch to PowerShell. First, there are nearly 500 SharePoint related cmdlets available out-of-the-box which cover all of the functionality available through STSADM plus much more. Second, it is much easier to write complex scripts in PowerShell than it is in DOS batch files. Third, for scenarios that are too complicated for scripting, custom PowerShell cmdlets are easier to write than STSADM extensions. Fourth, according to Microsoft, the SharePoint cmdlets are more efficient than their STSADM equivalents. Fifth, PowerShell supports remote command execution.
There is a bit of a learning curve involved in becoming a skilled PowerShell user, but there is a lot you can do now to get ready for the 2010 release.
1) Get familiar with PowerShell basics
Learn the basic syntax for calling a cmdlet. Cmdlets will form the backbone of all your PowerShell scripts.
Cmdlets can be chained together via the pipeline. The results of each cmdlet are passed to the subsequent cmdlet in the chain. Cmdlet chains can be used to perform all kinds of useful tasks. The results of the final cmdlet are piped to the console.
In the examples above, I use a few of the most useful built-in cmdlets (Where-Object and Foreach-Object) to filter and loop objects in the pipeline. These cmdlets are frequently used and, therefore, warrant aliases that shorten the syntax for their use. The alias for Where-Object is ? and for Foreach-Object is %.
2) Study the list of SharePoint related cmdlets
To utilize the SharePoint related cmdlets, enter a PowerShell session by using the SharePoint 4.0 Management Console option on the Start menu. This will ensure that the SharePoint PowerShell snapin is added to your session.
I’ve briefly shown the Get-SPSite and New-SPWeb cmdlets above. However, these are just two of the nearly five-hundred SharePoint cmdlets that are available. To see the complete list SharePoint related cmdlets, run the following command:
Get-Command -noun SP*
This will return a list of all cmdlets in which the noun portion of the cmdlet name starts with SP.
You can then further explore the individual cmdlets using the Get-Help cmdlet. This cmdlet takes a command name as a parameter and returns detailed help information about the command.
3) Write a custom cmdlet that works with the SharePoint object model
PowerShell scripting is extremely powerful and will allow you to accomplish a lot without ever writing compiled code. However, some tasks will be easier or more efficient if compiled into a cmdlet. Writing a custom cmdlet is extremely easy and should be achievable by anyone who is moderately proficient with .NET development. To get started, check out this blog post, How to Write Custom PowerShell
Cmdlet, that gives a detailed explanation of how to write a deploy your own cmdlet.
Once you know the basics, you can create your own cmdlet classes that leverage the SharePoint object model to automate your administrative tasks. You can also check out Gary Lapointe’s SharePoint Blog for some useful SharePoint cmdlets that you can use and additional examples of how to write you own.
4) Upgrade to PowerShell 2.0 to utilize remoting
Windows Management Framework RC, including PowerShell 2.0, is available now. Check out my post on how to set up your environment to support PowerShell remoting to get started using this great new feature today.
Using PowerShell 2.0 to Execute STSADM Commands Remotely
In version 2.0, PowerShell includes the capability to execute commands on remote computers via the WinRM service. WinRM is Microsoft’s implementation of the WS-Management protocol. We recently took advantage of this capability to automate SharePoint solution upgrades to our integration environment from our build server.
This can be accomplished in four easy steps:
1) Upgrade both the client machine (build server) and the server machine (a web front-end in the integration farm) to use PowerShell 2.0 by installing the Windows Management Framework RC.
2) Run the Enable-PSRemoting cmdlet on both machines to setup WinRM
3) Create a PowerShell script to execute your desired command remotely using the Invoke-Command cmdlet
The script above will allow you to specify the remote server name at run-time and assumes that the identity executing the script has administrator rights on both the client and server machines.
4) Update your MSBuild targets to include a step to copy WSPs to the integration environment and execute your PowerShell script
This target does the following:
- Copy WSP files to the drop location
- Copy CAB files to the drop location
- Copy WSP files to a file share on the integration server
- Set the PowerShell script execution policy to "RemoteSigned" to allow script execution on the client machine
Execute the script to run STSADM on the server machine
