Using PowerShell for SharePoint 2010 administration seems to be very fashionable these days. It’s faster and more powerful than STSADM, and is now the de facto standard for administration across the latest server products from Microsoft. Whilst I’m not going to quote a clichéd line about power and responsibility, I figured that it would be worth closing my VM’s SharePoint 2010 management shell for a few minutes and coming back down to earth for a level headed look at PowerShell, with some perspective on anticipated “real world” usage.
The basics – why should you care?
To start with, it’s probably worth going over a few PowerShell basics. If you are unfamiliar with Windows PowerShell in the context of SharePoint, I highly recommend you check out ““, by . In short:
- It will likely replace STSADM in the next version of SharePoint.
- Its available in SharePoint 2010 in addition to STSADM.
- It is more powerful than STSADM as it operates at the OM level – meaning that in addition to the functionality offered by STSADM, PowerShell includes functionality such as looping and piping that allows you to get administrative tasks done quicker.
- PowerShell is not unique to SharePoint – it can also be used for Windows and SQL Server administration.
Real world usage – my opinion
To give a little “real world” perspective on PowerShell, I imagine that it will most commonly be used for:
- Situations where options can only be configured with PowerShell, and not through the UI (e.g. granular recovery).
- Large scale, repetitive administrative tasks that will be significantly sped up through scripting.
Whilst it’s tempting to think that PowerShell will be the preferred tool to use to make production changes when compared to the UI, I think it’s worth remembering that the cmdlets available through the tool are very powerful, and are subject to error given the command line nature of the tool. By error, I don’t necessarily mean typographical errors – PowerShell supports tab completion for both cmdlet names and parameters, and in any case will return an error (in bright red text) if a typo is made. No, I’m talking about semantic (logic) errors – as an example, . These types of errors will not be picked up by PowerShell and your command will run without any complaints. Think run time as opposed to compilation errors in the world of development.
My opinion is that access to the SharePoint 2010 PowerShell snap-in will need to be granted with great care, and any commands that are not of a read only nature will likely need to be researched and tested in a pre-production environment before running on live.
Example: Mounting a content database using Windows PowerShell – do your homework!
Let’s take a look at the Mount-SPContentDatabase PowerShell cmdlet as an example – this is a powerful command that can be used as part of a DB attach or hybrid upgrade from SharePoint 2007 to drastically speed up the process of upgrading content databases. Rather than simply upgrading one DB at a time (as is the case with an in-place upgrade), multiple management shell windows can be opened to upgrade your databases simultaneously. This allows for improved resource utilisation, making the SQL server the only bottleneck. As you will see in the example below, however, it certainly pays to do your homework prior to running the command.
As with any PowerShell cmdlet, you can use Get-Help to learn a little more about Mount-SPContentDatabase as shown below:
In this case, we learn that databases that using the cmdlet will cause any databases using an older version of SharePoint to be upgraded. Also note the “Remarks” section, which tells us that we can use the “-examples” parameter to view examples of the cmdlet in action. Let’s give that a go with get-help Mount-SPContentDatabase -examples:
As shown, an example is shown which should help us get to grips with using the cmdlet. However, it does leave a few unanswered questions. What does “existing” mean? Does the DB need to be attached in SQL prior to running the command? Can I mount a content database from any version of Sharepoint, or just an earlier build of SharePoint 2010? In this case, we will have to do a little more research to determine how to use the cmdlet; I’ll save you the time though:
- The Test-SPContentDatabase cmdlet should be run prior to Mount-SPContentDatabase to identify any issues prior to adding the content database.
- The database must be attached in SQL.
- The account you are using must have sufficient privileges to access the content database.
- You can upgrade content databases as long as they meet the usual prerequisites (e.g. no orphans, SharePoint 2007 SP2 or later) – use the PreUpgradeCheck shipped in MOSS SP2 to check specifics.
Wow – that first bullet is a big gotcha! There was no mention of the Test-SPContentDatabase cmdlet when we used Get-Help for Mount-SPContentDatabase, but having done our homework it turns out that running Test-SPContentDatabase is effectively a best practise. Additionally, there are numerous other requirements that were not mentioned previously (rectifying issues found by the PreUpgradeCheck STSADM command for MOSS SP2 content database can be a big job in itself). The lesson here is to ensure you thoroughly research and test PowerShell cmdlets prior to running them on your live SharePoint 2010 environment.
You can read more about upgrading to SharePoint 2010 in either or .
- SharePoint administrators should start using PowerShell in place of STSADM due to improved speed, flexibility and future support. However…
- …access to the SharePoint 2010 Management Shell should be carefully planned due to the power it provides.
- PowerShell cmdlets and scripts require testing and research prior to usage in production.
- The Get-Help cmdlet can be useful in aiding understanding of a particular command – but should not be relied upon in isolation.
I hope that gives you some idea of the numerous benefits that PowerShell provides for SharePoint 2010 administrators, as well as some potential issues that can be encountered without proper research and testing.