Summary: Learn how to use Windows PowerShell to inventory objects in your SharePoint environment and to script updates.
Microsoft Scripting Guy, Ed Wilson, is here. Raymond Mitchell is our guest blogger today. Here is a little bit about Raymond.
Raymond has worked in IT since 1999, and he has worked with every version of SharePoint since its release as SharePoint Team Services. He has spent the last eight years consulting on all things SharePoint. He helped start the Minnesota SharePoint User Group, and he coordinated it for seven years. He has spoken at a number of other user groups and SharePoint Saturday events. Raymond wrote a Wrox Blox about the Data View Web Part and contributed two chapters on the BCS to SharePoint 2010 Six-in-One. He also blogs under the alias IWKID about information worker technologies, including SharePoint and Office. He currently works as a SharePoint consultant at SharePoint911.
As a SharePoint administrator, it is only a matter of time until someone asks, “How many sites do we have? How many lists? How many of these web parts?” There are lots of variations of these questions, but essentially someone is asking you to inventory objects in your SharePoint environment. If you’ve had any experience with database-backed applications, you might be tempted to run to the SharePoint content databases and start running queries, but those databases are strictly off-limits in SharePoint. Luckily we have Windows PowerShell to help us out!
Before we jump into scenarios, let’s make a few assumptions:
- We’re running Windows PowerShell scripts on the SharePoint Server
- We’re running SharePoint 2010 and leveraging the SharePoint Management Shell
It is not that our scenario requires these assumptions, but for brevity, we are keeping things simple.
Finding SharePoint sites
To get started, let us take a look at the first question: “How many sites do we have?” Unfortunately this question is not as straightforward as it sounds. The following table shows that in SharePoint, there are three separate objects that could easily be confused with “sites.”
Object |
Relationship |
Object Model Class |
Web Application |
Can span multiple IIS sites |
|
Site Collection |
Web Applications can contain multiple site collections |
|
Web |
Each site collection typically contains multiple webs (a RootWeb and its sub webs) |
In this example, we will assume that they are asking about how many webs, so we will first get the Web Application object, and then count the webs for each site collection. The following image illustrates how to accomplish this task. (This code has been uploaded to the Script Center Repository.)
Because we are using SharePoint 2010 and the 2010 Management Shell (which is preloaded with the Microsoft.SharePoint.PowerShell snap-in), we can leverage cmdlets like Get-SPWebApplication which makes life considerably easier.
Inventorying SharePoint lists
Next, let us take a look at how many lists we have. Again this question might not be as straightforward as it sounds. In SharePoint, there are two main content containers that could be included in this inventory: Lists and Libraries.
Object |
Description |
Object Model Class |
List |
Contains list data |
|
Library |
Contains documents |
By checking a list’s BaseType property, we can filter out any Document Libraries and return only the count of lists (we could also filter on the BaseTemplate to filter on specific List types such as Announcements or Tasks). Because we are dealing with more objects, in this example we are going to work with a single site collection to reduce our performance impact on the server. The following image illustrates this technique.
Of course, it would be better to see where the lists exist. To do this requires a bit more work as shown in the following image. (This code can be found in the Script Center Repository.)
Finding specific web parts
Great! Now we know where our lists are! In our final scenario, we will take a look at finding specific web parts in a site. In this example, we will keep things simple and assume that the web parts are stored on the homepage of a site (known as the WelcomePage). We will limit our inventory to a single site collection, and we will look for Content Editor Web Parts. This technique is shown in the following image.
Again, just knowing how many items is not usually the end of the story. In this case, let us suppose that we want to remove all of the Content Editor Web Parts from the site. We will need to update the script to first inventory the web parts (the important things are their web pages and IDs), and then we’ll go back and delete them one at a time (because we can’t update the collection as we’re looping through).
Another interesting hiccup occurs when we try to open the website that contains the page. The Get-SPWeb and Get-SPSite cmdlets are not as forgiving as the constructors for these classes, so if we pass in a URL for a page within the site, it will not return the object for us. Instead, I’m using New-Object to create an SPSite object, rather than the cmdlet (by the way, this is how you had to do it when you were working with SharePoint prior to the Management Shell). Here is the code for removing the web parts. (This code can be found in the Script Center Repository also.)
In summary, we have explored how to inventory webs, lists, and web parts in our SharePoint site. We have also shown how you can work with classes from the SharePoint Object Model to extend your inventory scripts to make updates across your environment.
The value of Windows PowerShell to SharePoint administrators extends far beyond the cmdlets that ship with SharePoint 2010 and options like Backup and Restore. Windows PowerShell gives administrators the ability to rapidly inventory and update their environments.
~Raymond
Thank you, Raymond, for a great Windows PowerShell and SharePoint blog post. Join us tomorrow for more cool Windows PowerShell stuff.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.
Ed Wilson, Microsoft Scripting Guy
0 comments