Update - 2007-09-20 - Blog now has project attached temporarily until it's added into the SPI solution on Codeplex.
Purpose
Provide a User Interface to administer Sharepoint content using PowerShell.
Background
I received an email recently of some interesting downloads on CodePlex relating to Sharepoint. One that caught my attention was a developer tool called Sharepoint Inspector (SPI), created by Gaetan Bouveret.
SPI is a tool to inspect a Sharepoint farm by drilling down into the various objects and then viewing their properties through reflection. There are other tools out there that do basically the same thing but a) the ones I know of are closed source (meaning I can't mess them up!) and b) Gaetan has devoted quite a lot of effort and started to add functionality to manage certain components within a farm, like activating features, querying site data and managing solutions to name a few.
A tool like this is really a must for all Sharepoint developers and even administrators (In our environment we only have WSSv3 deployed so we don't even get that OOTB MOSS manager tool which provides some management features).
So that's the first operand within the title explained, onto the second… PowerShell.
I've been using PowerShell, a run down and tutorials to get started using it with SP is available here, to do more and more Sharepoint tasks from things as massive as migrating from STS v1 to WSS v3, to little one off's like resetting a bunch of site's themes to creating play sites based off Active Directory user details.
Both operands on the stack, time to push() the operator (post-fix notation).
I thought it would be great if you could select a Sharepoint site from a tree view of your farm and then run a PowerShell script to perform a task on what's selected.
And reducing the contents of the stack brings us to a…
Solution
I've extended Gaetan's SPI to include the ability to execute PowerShell scripts while making available to script writers the current state of SPI, exposed via the class SharepointReferences.
So what this means is you can now drill down to an object and right click to select "PowerShell Actions" which will give you a listing of any available scripts that are defined in a user defined directory.
Each PowerShell script needs an accompanying definition file which is a simple xml file, as an example here is the schema for the Export Web script:
<?xml version="1.0" encoding="utf-8"?>
<PowerShellCommand>
<Name>Export Web and child Webs</Name>
<Command>.\Scripts\ExportWeb.ps1 "$($($spRef.currentSite).id)" "$($($spRef.currentWeb).id)"</Command>
<Category>Backup</Category>
<Scope>Web</Scope>
</PowerShellCommand>
The only thing that needs explaining is the Command element. This element takes the PowerShell command that is to be executed, which calls your script and passes any required parameters.
In order to obtain the parameter values I've defined within a PowerShell runspace a variable called $spRef. This is a reference to the SharepointReferences instance defined in SPI which exposes all of the currently selected Sharepoint objects.
This means that if you wanted the ID property of the currently selected SPWeb object you would type: "$($($spRef.currentSite).id)". This command is then executed in a PowerShell runspace using a technique called Variable Expansion.
I've now been using this method of administration for a little while and so far it's quite handy. I've written some simple import/export scripts which allows an admin to right-click on a SPWeb and export it and its subsites to file, then click on a different location in the Sharepoint farm and right-click import (replace site or import as subsite) the last exported web. It's a time saver when you have requests coming in ad-hoc.
I've asked Gaetan to incorporate it into the original project, so hopefully he we get on this soon so that other people can use this feature. I will update on the status of this shortly.
Tom.
Posted
09-20-2007 4:45 PM
by
Tom.Shirley