SharePoint Thoughts - Maurice Prather [MCM, MVP]

Using PowerShell to create new sites based on site-scoped WebTemplates

Tue, 11 Oct 2011 04:32:00 GMT

WebTemplates are definitely a powerful new construct in our SharePoint 2010 toolbox. WebTemplates definitely come in handy as they can be deployed as sandbox-compatible features.

Creating a site based on a web template is pretty straightforward via the UI. Basically it just shows up as another site template option. As a user creating a site, you’d never the know the difference between a farm-scoped or site-scoped WebTemplate. However, if you want to use PowerShell, you will notice that your PS scripts will take on a slightly different shape based on how the WebTemplate is scoped.

If the WebTemplate is deployed as a farm-scoped feature, then you can easily use New-SPWeb in the following manner:

new-spweb $url –template “{GUID}#WebTemplateName”

where GUID represents the parent feature ID.

If the WebTemplate is deployed as a site-scoped feature, then your PowerShell needs to be adjusted. Otherwise, if you attempt to use new-spweb, you’ll get the following error message: Template is not found and is not applied. This effectively means the cmdlet could not locate a farm-level template to apply to the new site.

For example...

There are two ways to circumvent this problem:

Once the site is created, call ApplyWebTemplate
Before the site created, grab a reference to the appropriate WebTemplate and provide it as a value to the SPWebCollection.Add method on the parent site.

Examples

Calling ApplyWebTemplate

$url = "http://sitecollection/site1"

$w = new-spweb $url

$w.ApplyWebTemplate("{GUID}#WebTemplateName")

Calling SPWebCollection.Add

$url = "http://sitecollection"

$w = get-spweb $url

$template = $w.GetAvailableWebTemplates(1033) | ? { $_.name -eq "{GUID}#WebTemplateName" }

$w.Webs.Add("site1", "sample site 1", "sample description", 1033, $template, $false, $false)

The difference between the two methods basically boils down to the language selection for the new site. With the simple call to ApplyWebTemplate, the new site uses the same language as the parent. By grabbing the reference to the web template beforehand, you have more control.

-Maurice

SharePoint Conference 2011 Wrap Up

Fri, 07 Oct 2011 18:23:33 GMT

This year’s SharePoint Conference was probably one of the most interesting conferences that Microsoft has hosted in the past few years. The attendance was solid and presentations covered the spectrum from 101 fundamentals over all the way over to nitty-gritty details.

Monday morning I had a chance to present on managing the Sandboxed Code Service (SP376). I was a little skeptical that we’d fill a room with 700 seats, but I was very pleasantly surprised to see the room fill up before we switched on the microphone. There were a ton of good questions afterwards as well. Thanks to everyone who attended and posted all the great messages on Twitter. If you have any questions I was unable to answer, please feel free to reach out.

The conference was also a great chance to run into folks. I saw many old friends – some that I haven’t seen literally in years – as well as many clients and former Critical Path Training admin and dev students. It’s always amazing to see the positive energy!

The Aptillon team also had record number of presentations at the conference. We had 7 presentations by 6 different teammates. As a company partner, that is definitely very cool stat however the nicer fact is that we had a chance to hang out. Since we’re spread out all over the US and constantly on the go, it’s rare to have more than 2 people in the same room at the same time.

There was also a record number of Microsoft Certified Masters from across the globe at the conference. How cool is that? I remember the days when Spence and I were the only MCMs who weren’t employed by Microsoft. :) MSL also announced a new certification – Microsoft Certified Architect. It’s really nice to see program growing!

Great conversations all around. New projects, new ideas, confirmation of design decisions... chatting about the sandbox, helping folks get a better perspectives on PowerPivot and it’s amazing potential, the cloud, getting out of the sandbox (aka azure), Windows Phone 7, watching cloud-servicing applications such as Sharevolution hit their stride, building new partnerships... truly exciting stuff!

-Maurice

Regex for Wiki Page regions

Tue, 27 Sep 2011 20:09:00 GMT

In an earlier post, I briefly touched on the value of creating your own InsertWebPartIntoWikiPage method. Part 1 – solved. Now comes Part 2 – where am I injecting my web part?

That’s a valid question that is easily answered whenever you’re using the SharePoint wiki page editing tools within the browser. The tools allow users to basically pick a spot in the rendered text, click on Add Web Part, and you are done. The tools know how to safely inject your web part without forming bad html under the hood.

From a programmatic sense, this is much harder because we don’t get the “smarts” of knowing where to insert the web part markup. Most users that try to use InsertWebPartIntoWikiPage invariably fail the first few times because they forget to account for the fact that they are injecting web part markup into an html blob and therefore need to properly account for well-formedness (is that a word?).

The net result is that folks will create code that looks like…

InsertWebPartIntoWikiPage (file, webpart, randomValueKeepFingersCrossedNothingBreaks)

The validity of the resulting HTML becomes something like rolling the dice at the casino. Most folks can start with an empty page and count the number of characters to the first legitimate location where web part markup can be injected. However, once the page is created and populated, all bets are off and IWPIWP becomes more of a hindrance than an aid but it doesn’t have to be that way.

Wouldn’t it be nice to be able to readily determine where the valid injection points are located? Sure! The answer comes in the form of good old fashioned regular expressions.

If you’re like me, you’ve got a nice little regex library for most any html operation (tag stripping, tag collection, validation, etc). Well, here’s one more that you can add to the list… a regex to safely identify the your Wiki page regions!

This little regex allows you to easily determine how many regions are in your Wiki page and, more importantly, where they begin and end. The regex groups the valid editable regions with the name “InnerHtml”. They represent the blue-bordered regions whenever you are editing a wiki page in the browser (as shown below).

In it’s simplest form, you can now inject your web parts in the right places without destroying your existing HTML. For example, in the following clip, we add a web part at the start of the second region in the page.

Done! Page is updated with my web part in the right place and it all just works.

The really nice thing is that since we’re only identifying the HTML within the region, we can easily use the regex to update the text as needed in the region of my choice.

Here’s another example where we identify a region and then replace it with new text.

What other tricks can you come up with? How about identifying the web parts that exist in the page? How about placing the new web parts in mid-stream w/o breaking the existing HTML structure? All possible with regex, especially now that we’ve clearly identified the InnerHtml of your regions!

You got to love the power of regular expressions because with a little ingenuity you can solve each one of those problems.

-Maurice

Fixing the HTML that InsertWebPartIntoWikiPage generates

Tue, 09 Aug 2011 08:34:02 GMT

Buried deep in the recess of the WebPartPages class, there is a static method that belongs to the WikiEditPage class and its sole purpose is to allow you to insert WebParts into a wiki page.

The static method Microsoft.SharePoint.WebPartPages.WikiEditPage.InsertWebPartIntoWikiPage basically takes 3 parameters – the file, the webpart, and the text position of where you want to inject the web part.

All is fine and dandy except for one thing – the html that is produced by the method is invalid. The method basically injects the html shown on the slide below.

Take special note of the next to last <div> tag.

Self-closing tag results in broken wiki page!

<div style='display:none' id="vid_{0}"/>

The tag as written is self-closing. Unfortunately, when the text is processed by SharePoint’s parser, the self-closing notation is not recognized as valid html and the parser leaves this tag open. This results in a very broken wiki page because the closing </div> does not exist for the segment of html that was just injected into the page. Take a look at the image below – 3 start tags but only 2 end tags.

The fix is pretty easy. Create your own version of InsertWebPartIntoWikiPage!

All you need to do is change that next to last div tag from one that uses the self-closing notation over to one that properly uses an end tag.

Once you do this, your html segment will look like...

Nice and clean with the right number of start and end tags. More importantly, your wiki page will work as expected.

Later this week, I’ll show you a really cool way to use regex to control the location of the web parts that you’re trying to add to the wiki page.

-Maurice

Reference Post: Regex for Wiki Page regions

Options to using Import/Export

Fri, 05 Aug 2011 22:15:53 GMT

Earlier today, Todd Klindt and I had a brief twitter chat. Basically, he ran into some problems with a site that had been run through the wringer with Import/Export. Todd asked a really good question for which the answer requires a little more space than twitter allows. :)

For those that are relatively new to SharePoint, they don’t often times don’t get a chance to learn what works or what needs to be avoided until it’s too late. Let’s take a brief look at the history of this feature set so that if you’re new to SharePoint, you’ll know where some issues may pop up.

Import/Export is one of those features that needs to be used with caution. Why? Well, we have to go back to RTM of 2007 when the world was first introduced to Import/Export (aka PRIME). It was a very broken toolset. Fast forward a year or so, then the Infrastructure Updates for 2007 was released. This was a special set of fixes designed to repair the underlying Import/Export engine. The IU made the feature set much more usable; however, there were a core set of things Import/Export still could not do. To the average SharePoint administrator, this basically means Import/Export is NOT a full fidelity solution for backing up and moving data. Again fast forward to 2010 RTM. Import/export is still pretty much unchanged.

At the site (aka web) level, Import/Export is without a doubt a very problematic feature. Import/export does not offer full fidelity data export. Thus, at the site level, you’re somewhat gambling with your data. Sometimes it will work and other times it may not. There are a lot of threads all over the place that help us see that Import/Export-ed sites tends to have weird and random behaviors. As an administrator, the last thing I want to do is chase down problems with restored data.

Thought to ponder: Did you ever wonder why 2010’s SP1 added site Recycle Bin functionality?

Is Import/Export really that unreliable? The answer is generally yes. However, we definitely need to give Import/Export some credit.

At the list and item level, Import/Export can actually go the full cycle.

The more granular you are (i.e. items), the easier it is for Import/Export to actually work as we expect it to. Using Import/Export to move items is what is known as “cherry picking”. It works and that leads us to the one of the possible options to Todd’s question...

“What (are the) other options for breaking up a site collection?”

Generally speaking you need to migrate your data. You’ll either need to ...

explore using Import/Export at the item level or
work with a custom solution (written in C# or PowerShell) that extracts the data locally and pushes it to a new destination.

Migration is not nearly as simple as just clicking on the Central Admin ui to export a site, then repositioning it. However, it’s the only way you be assured that all the data you care about is where it needs to be and that your site is fully functional.

Should you build or buy the tools to migrate your data? It depends on your needs, skills, and timeframes. There are lot of good tools – from free to pay. PowerShell and custom code are definitely viable options.

Migration does take a little more planning but it inevitably makes for a much nicer end result. It’s a great way to reduce clutter (e.g. no need to migrate stuff that doesn’t matter!) and you can rest easier when the process is done. It’s worth calling out that with any migration plan, though, you should incorporate a testing strategy. Testing will validate that your migration technique will successfully meet your requirements.

Happy migrations!

-Maurice