Continuing my quest to explore how PowerShell can help SharePoint developers and administrators, this time I’ll take a look at a fairly uncommon scenario: inspecting and modifying a live SharePoint instance.

The case I was working on involved a known problematic scenario: a subweb converted into a site collection. The site collection was one where the users could create workspaces, and unfortunately, due to the problems from importing, the workspace creation failed.

The long-term solution is, of course, to fix the site collection, for example using Gary’s tools. However, installing packages on a production system is not something I like to do in an ad-hoc way, and as I understand it, STSADM extensions are installed by deploying WSP packages to SharePoint. As it happens, the server had PowerShell installed, so I decided to inspect the situation and see if I could do something less invasive.

The first step was to load the SharePoint assembly:

While the syntax may look weird, the semantics should be familiar to every .NET developer — this calls the static method LoadWithPartialName from the System.Reflection.Assembly class. The call loads the SharePoint assembly into the running PowerShell process, and provides us with the possibility to invoke the API. Now, before you go crazy with it, remember that you’ll have to be just as careful as you do when writing code that gets deployed to SharePoint.

That said, next I newed up an SPSite, grabbed a hold of its RootWeb and made sure we really were dealing with the situation described in Gary’s post:

PowerShell’s default behavior is to echo out the value of the statement — in this case, the result of reading the __PageLayouts property: ‘__inherit’, just as I expected. At this point I began to wonder what to do next — I hadn’t done anything drastic yet, but the possibility of a short-term fix was tempting. On one hand, the error message from trying to create the site referred to an erroneus ChromeMasterUrl in the site definition, which didn’t exactly seem related to the issue. On the other, visiting _layouts/AreaTemplateSettings.aspx did produce an XML parsing error, just as I expected.

After a moment of contemplating the possible consequences, I took a deep breath, and wrote:

with every intention to change it back if something went wrong. The first thing I tried next was to reload _layouts/AreaTemplateSettings.aspx, and wouldn’t you know it, the error message went away. Encouraged, I then proceeded to try creating a workspace again. After a moment of nail-biting, instead of the previous error, a functioning workspace appeared. Phew!

At that point, there wasn’t much else to do, except:

By now I’m convinced that having PowerShell available as a flavor of Read-Eval-Print-Loop for SharePoint administration is definitely a good thing. Just keep in mind that with great PowerShell comes great responsibility, and if you break something, you get to keep both pieces.

Popularity: 1% [?]