The first post in this series covered the basics of PowerShell including variables, loops, and decisions. It also introduced a few scripts I’ve used over the last several weeks. In this post, we’ll discuss how to use PowerShell in a SharePoint farm, some of the more useful capabilities (especially to developers), and a few more scripts that I’ve written to bring the topics covered together.

Integrating PowerShell With SharePoint

PowerShell has been natively supported in SharePoint since SharePoint Foundation 2010 and SharePoint Server 2010. When SharePoint is installed, in addition to the Product Configuration Wizard and Central Administration shortcuts, a shortcut for the SharePoint Management Shell is available. This application is a PowerShell console with a blue background and the SharePoint Snap-in loaded. The PowerShell Snap-in is a PowerShell version 1 object that, when loaded, makes additional functions (or cmdlets) available to call in the current PowerShell session. To do this, simply execute the following:

Add-PSSnapin "Microsoft.SharePoint.PowerShell"

This will allow you to access the SharePoint cmdlets in any PowerShell session. It’s also important to run the PowerShell or SharePoint Management Shell console as administrator as the logged-in user may only have limited access to the SharePoint farm.

SharePoint Object Manipulation

The SharePoint PowerShell Snap-in grants deep access to the farm. Most objects on the platform can be manipulated through PowerShell. Service Applications can be created and managed this way. In fact, many administrators create the farm and associated Service Applications through PowerShell because it grants more configuration options than the various wizards in the UI. One such improvement is naming databases without a GUID attached to it. (Farm and Service Applications will be covered more in depth in the next post in this series.)

It’s possible to create almost every object in SharePoint, from a Web Application to a List Item, in PowerShell. In SharePoint 2013, the introduction of Host Named Site Collections actually require PowerShell involvement because these types of Site Collections cannot be created through the UI.

Creating and manipulating Sites, Lists and List Items are fairly similar to each other. However, you might be asking why it really matters when you have the UI or C#.

First, this may just be needed for a “one-off” task such as building a site structure in your development environment and you don’t want to wait on the UI to process clicks. Second, maybe you just need to generate a large quantity of items based off of some text or CSV file. PowerShell gives you direct access to do this without having to load a solution into the farm.

Let’s take a real world example: I had a solution that deployed lists and disabled list deletion if it contained items. The solution was still in testing, but I had added items. Solution retraction wouldn’t delete the lists, so when I redeployed, the lists wouldn’t rebuild. Instead of changing the code, I simply accessed the list in PowerShell, changed the AllowDeletion property to “true” and deleted the list. It’s a simple solution that kept me from having to comment out code and hope that I would uncomment it when it came time to deploy the completed project.

Another useful tool for SharePoint development, the Developer Dashboard (which got a hefty upgrade in SharePoint 2013), must be enabled via PowerShell. The Developer Dashboard provides information on page and page object loads, thus allowing you to understand where there are opportunities to optimize the page or web parts.

Finally, solution deployment is done with PowerShell. Adding a solution to the farm must be done, but deploying the solution and activating features are commonly done this way as well. Since many administrators prefer this method, it’s best to create a deployment script both for your development environment and for production, staging, and any other shared environment. This will also typically make your administrator(s) happy as it’s one less thing for them to do on deployment nights. The following is a simple example of solution deployment and feature activation:

Deactivating features and retracting solutions can also be done and the following example illustrates this point.

MSDN provides a complete list of every SharePoint 2010 and SharePoint 2013 cmdlet. There’s quite a few in each version and there’s a lot of power available through these commands.

More Useful Scripts

In my first post, I provided a few scripts that I used recently that may be of some use. I have a couple more that I’ve been using on a recent project to make early development and testing easier. The function name and a description are provided, but the actual code is located in my CodePlex project: Useful PowerShell Cmdlets.

Delete-ListsByCreatedDate

The project I’m working on has several lists that are deployed. I had started deleting them by hand in the UI, but quickly grew tired of that method. I wrote this script to delete lists created on a certain date. I chose the created date because there weren’t any other identifying properties common among all the lists. Also, it becomes easy to reuse the command if I deploy the solution and lists multiple times in the same day.

Delete-ColumnsByInternalNamePrefix

In the same project, I use several Site Columns to populate columns in the lists mentioned above. In fact, there are more than 30 Site Columns. I add a prefix to the internal names of the columns as a way to create unique names. This function looks through the site’s fields and deletes each column that uses said prefix.

Conclusion

PowerShell is a great tool for SharePoint management. In some cases, it’s a required tool, such as Host Named Site Collections and adding solutions. In other cases, it might just be the quickest way to create or manipulate artifacts in the environment whether it’s production or your development environment. In the final installment of this series, we’ll look at a complete virtual machine setup of a SharePoint 2013 development environment.