Please upgrade your web browser now. Internet Explorer 6 is no longer supported.
Thinking Web Solutions?
We create smart, fun, functional websites that make your web a better place.

Archive for tag: SharePoint

FREE Master Page for SharePoint Foundation 2010

Just released - a FREE Master Page for SharePoint Foundation 2010!

Download now from »

We created this Master Page to help  designers / developers get a head start on integration projects, or for anyone wanting a clean, simple look and feel for their SharePoint Foundation 2010 installation.

Free SharePoint Foundation 2010 Master Page

Layout: Floating width 90%
Supported Browsers: Firefox, IE 7+
Integration: Collaboration Sites, Meeting Sites, Calendar, Search

Master Pages for SharePoint 2010

Fresh off the press: 3 new Master Pages for SharePoint 2010! We have just launched SharePoint Master Pages (a sister site to SharePoint Themes).

SharePoint Master Pages is dedicated to branding SharePoint 2010, with masterpages built for both SharePoint Server and Foundation.

sharepoint masterpages

We are starting from small beginnings but have quite a few plans for the future... In the coming months we plan to roll out more Master Pages, Page Layouts, some SharePoint 2010 branding resources and freebies.

Our focus is on creating high quality branding resources for SharePoint at a price point that makes sense. Much of what can currently be found for sale are either poorly designed or lack the thourough integration of items such as the calendar, wiki, and my sites. We are hoping to fill this gap and solve a few of your SharePoint branding headaches.

So check the site out, buy a Master Page and check back later for some more quality stock!

Introducing - A new store for SharePoint Themes

Today we are doing a soft launch of our new store for SharePoint Themes.


Creating SharePoint themes is fairly complicated unless you have a pretty deep understanding of the many thousands of core SharePoint CSS classes. I commonly see quotes of over $5000 for one theme!

We are hoping to fill a market gap at a better price point, and solve a few of your SharePoint branding headaches.

SEO: How does SharePoint measure up?

While many SharePoint'ers are over in Vegas eagerly awaiting the start of the 2009 SharePoint Conference, the rest of back in reality enduring the hardships of plain old SharePoint 2007...

Over the past couple of years, the number of SharePoint built websites has grown significantly. But how do all of these sites stack up from a technical SEO perspective? Lets have a look using the new IIS 7.0 SEO Toolkit to analyze our site:

Here is the output after running the tool over our website:


OK cool, lots of errors! Now what do they mean and what can we do about it?

1. The page contains multiple canonical formats
This means that there are multiple addresses that can be used to access the pages of our website. For example, take the home page; we could browse to this page in the following ways: (capitalization) (no www)

The effect of this is that search engines will potentially spread the ranking over the different URLs rather than aggregating it for the one page. Now search engines are fairly clever and it should work out that there is only one page to rank. Not taking any chances here is a method you can use to fix this (IIS 7 only).

2. The page contains unnecessary redirects
This is because of the infamous 302 rewrite issue.When you type a URL like, SharePoint will perform a 302 (temporary) redirect to This is not ideal as search engines are not as keen on following 302 redirects, they prefer 301s (permanent). There is no ideal way of fixing this but here are a couple of options:
- Use IIS7 redirect rules
- Using an HTTPModule

3. The description is missing (Not SharePoint specific)
This is really obvious, we are missing the meta description tag. The meta description tag is normally used for your search engine result page (SERP) listing and is a key factor in determining relevancy. While we are on the topic, don't bother with the meta keywords tag. The big search engines have been ignoring this since about 2002.

4. The page contains broken hyperlinks (Not SharePoint specific)
Another obvious content issue. Broken hyperlinks are said by some to affect page rankings. In theory search engines will favour sites and pages that have relevant, up-to-date content and broken links are sign of poorly maintained page. This is tough to keep a handle on with blogs that have large amounts of outgoing links, but there are tools available that can help.

5. through to 7. are not SharePoint specific issues and there are heaps of great resources around that address these so I won't cover that here.

8. The URL is linked using different casing
As mentioned in item 1, search engines are case sensitive. In an ideal world all of your urls and all the links to them would be lowercase, with dashes used to separate words. The navigation controls in SharePoint always redirect to a first letter capitalized 'Pages' and what is worse is the tendency for URL's to occasionlly be loaded in upper case. A technique to address this issue is discussed in this blog post.

9. & 10. are not SharePoint specific

11. The page contains a large amount of script code
SharePoint does have a habit of including an awful lot of additional javascript. However I do think it's a little bit unfair for it to be reported in this case as I have removed most of it. Plenty of the javascript that gets loaded is only needed for authenticated authors and the associated rich editing controls. There are a few simple techniques to remove this and doing so can give you a great performance boost.

12. This page contains invalid markup
It's pretty commonly known that SharePoint isn't exactly standards friendly. Search engines will have an easier time processing the contents of your page if it is easily parsable. Now this doesn't mean that it has to be XHTML 1.1 Strict compliant. It just means that all the tags are closed and are not mismatched, which is a lot easier to achieve than XHTML standards. As WCAG 2.0 has the same requirements you can use a WCAG 2.0 validator to test this.

One other thing that does not seem to covered by the IIS SEO Toolkit:

13. There is no XML sitemap defined
An XML sitemap tells the search engine where are all the pages you want crawled are, it is not made to be human readable. For a quick and easy way to get this setup check Waldek's sitemap generator.

Note that this was done on a slightly older version of the site, and a few of these issues have already been fixed.

The SEO tool is still in Beta and seems to be a little over zealous in the number of issues it reports, but it is already providing some really useful results.
Of course, nothing beats having really great original content that naturally generates healthy back links. Fixing these technical issues is really just a way of maximising that hard work and there is certainly nothing wrong with that!

SharePoint Search for Public Websites

Configuring search on a public facing Web Content Management (WCM) site is quite a different task compared with your typical SharePoint intranet. Searching over internal content largely works out of the box; setting up a few content sources and basic scopes is usually enough to satisfy most users.

With a public website we want a simpler more 'bing/google' like search experience. The method of search is a basic search keyword phrase input and the power of the search resides in the indexing of content. We do not want to rely on a user's ability to construct complicated search terms. Everybody can use it, and use it effectively.

What follows from here is a basic guide for setting up SharePoint search on an anonymously accessed SharePoint publishing site. This assumes a bit of experience configuring search, but if you don't take a look at this TechNet webcast on installing and configuring search in SharePoint Server 2007.

Creating Scopes

Creating scopes is the most important step in configuring public search. There are usually a number of resource files such as CSS, JavaScript, XSL and images as well as objects like user profiles that you wouldn't want showing up in your search results. However we do want to be able to search over all of our document libraries, inlcuding aspx pages. So our first step is to create a scope that will return all pages and documents which we can create like this:


A search using this scope will return anything that is in the content source "Local Office SharePoint Server sites" AND (the content is a publishing page OR the content is a document). Note the brackets used in this statement.

As you can see the rule behaviour is being used to create logical conditions. The logic of the rules can be applied as follows:

  • Include = OR
  • Require = AND
  • Exclude = AND NOT

The 'contentclass' property specifies what type the indexed item is and will be automatically available for any content item in SharePoint. The two types that we are usually concerned with in a public site are:

  • STS_ListItem_850 (Publishing Pages)
  • STS_ListItem_DocumentLibrary (Documents)

Check out this post from Dan Attis for a complete list of contentclass values.


I would recommend against allowing list items in your search scopes. The basic reason for this is that to view a list item you need to browse to the display form (/Forms/DispForm.aspx). Problem is this should be locked down by the Form Lock down feature. Unfortunately it is common for lists to be used to store content for your public web site; for example when using WSS collaboration features such as blogs, wikis and discussion lists. At the end of the day the collaboration and publishing features in SharePoint don't play very nicely together. When making design decisions for a SharePoint based solution and the question comes up - "Should we put this content in a simple list or create aspx pages?", you should consider whether you want the content to be searchable or not.

Scope Examples

What if we wanted to create a scope that returned everything under a specific web? In this example I have added folder rule that will include all results in or beneath the 'about-us' site:


What if we had a shared server environment that hosted multiple websites? In this example I have added a domain rule so that any results for my site will be returned:


If you don't know how to create scopes than have look at this help page from microsoft office online.


When indexing document libraries make sure that the documents are of a file type known to SharePoint, otherwise SharePoint will crawl the document as a list item and use the form display page rather than the actual document itself. Check out the filter pack from Microsoft if you want to add additional file types.

Creating a Simple, Deployable Layout

Armed with our public search scopes we already have enough information to return the right results. The next step is to create a simple search page to display search results.

When you create a search centre using the out-of-the-box search site template, you get a whole bunch of features that just aren't that well suited to a public facing scenario (RSS Feeds, Alerts, Advanced Search). My recommendation is to take a light weight minimal approach - why use a whole search centre when a single results page will do it? Creating a single page layout that is part of an easily deployable SharePoint solution is often the cleanest way to go.

Web Parts

Web Part zones often cause issues when it comes to repeatable deployment and they add additional HTML bloat. If you are wanting the simplest HTML output possible then web part zones should be avoided.When it comes down to it we only really need a page layout with a few basic web parts - SearchBoxEx, CoreResultsWebPart and the SearchPagingWebPart.

Here is an example of using the CoreResultsWebPart in a search page layout without web part zone.

<Search:CoreResultsWebPart runat="server"
Scope="All Pages and Documents"
<root xmlns:xsi="">
<Column Name="WorkId"/>
<Column Name="Rank"/>
<Column Name="Title"/>
<Column Name="HitHighlightedProperties"/>
<Column Name="Size"/>
<Column Name="Path"/>
<Column Name="Description"/>
<Column Name="PictureThumbnailURL"/>
<Column Name="SiteName"/>
<Column Name="CollapsingStatus"/>
<Column Name="HitHighlightedSummary"/>
<Column Name="ContentClass"/>
<Column Name="IsDocument"/>
<Column Name="Write"/>
<Column Name="Author"/>
<Column Name="ContentType"/>

The other web parts can be added to the page layout in the same way.


Make sure search.js is inlcuded in a custom search page layout as it is needed for logging search statistics:

<asp:Content ContentPlaceHolderID="PlaceHolderAdditionalPageHead" runat="server">
<SharePoint:ScriptLink ID="ScriptLink1" name="search.js" runat="server"/>

Additional Branding Considerations

The majority of the branding is quite easy due to the core search results web part using an XSL transformation to style the results. Unfortunately the other web parts will require tedious battling with overriding of SharePoint's CSS properties. Not ideal but you can still get it looking pretty decent if you know what you are doing.

For full control of the HTML structure and styling you would need to create a bespoke solution that used the search SQL Syntax API that comes with MOSS. This is also the only solution if you require some advanced sorting or filtering functionality. This isn't overly difficult, but it's a tough one to explain to the business owner that is forking out for SharePoint.

So what about advanced search? I think we'll leave that one for another day.

I hope this post gives you a few ideas and some "best practices" on you can go about creating a decent search solution for you public SharePoint website.

Good luck!

Recent Improvements to STSADM backup

Recently there have been a few key improvements to the STSADM backup command which I have found to make life a lot easier (and safer!).

After installing Service Pack 2 and running the backup command you will notice a few subtle, but important changes:

Previously it was a best practice to set the site being backed up to read only using the setsitelock command. This is something that I am guessing 95% of people never did. And who can blame them as it wasn't made terribly obvious. Fortunately the backup command now automatically sets this and lazy admins can have peace of mind.

The April CU also provided an important update to how backup and restore works, particularly with publishing sites. In SharePoint, the actual page layout aspx files are stored with some hardcoded metadata which includes the url of the site they belong to. Previously when performing a backup & restore to different farms with different URLs this could cause issues. Import/Export does not have this problem as the page layouts are recreated in the target site. The backup command has now been updated to fix this issue and this method of migrating content between farms is now supported. Note that the  June CU is now available and supersedes the April CU.

So why would you want to use backup/restore over import/export to migrate content anyway?

If you commonly use the SPSiteDataQuery class, ContentQuery webpart or the DataView webpart you rely on GUID references to lists for query commands. By default, import/export assigns new GUIDS to any lists that are migrated which will upset the queries that rely on them. Using backup/restore was an easy way to avoid this issue.

Of course it was fairly easy to write some import code using the object model and retain the GUID values. And if you still want to use import/export that is the way to go.

One week till the NZ SharePoint Conference!

There is excatly one week to go until the NZ SharePoint Community conference in Wellington starts. There are still a few tickets remaining at the super bargain price of $500 so you should get one now!


My session on SharePoint and NZ Web Standards is on the Thursday at 4.15pm in Chamber Room 1 and I'm really looking forward to it!

Installation accounts for a dev/test server

I don't particularly enjoy installing SharePoint, I've done it a million times and really it's quite a boring process. When I do end up having to install it, I generally use a simple 4 account method:

  1. Admin (SPAdmin) - Used for installation and administration of SharePoint
  2. App Pool (SPAppPool) - all web apps except central admin run with this account as their identity
  3. Services (SPService) - App pool account for central admin and the SSP service account
  4. Search (SPSearch) - Used for all search services

Generally I'm installing SharePoint for my own dev/test purposes, so this suits just fine. I think it is also fine for small scale installations or instances when the admin in charge of account creation isn't interested in creating 8+ accounts. To be honest I think a lot of the time using the 8+ accounts is a tad overkill, and people are just blindly following 'best practices' without applying them to their specific environment. But being more of a dev type than an infrastructure type I don't feel qualified to formally make that recommendation.

Even for a development server it is really important to have some separation of accounts. It is in your best interest to simulate a production scenario as best you can. Take for example if you were to use the SharePoint admin account as an application pool identity. You may have permissions to do things on your dev server (in code) that will probably have issues in a production scenario.

Tip for naming columns and lists in SharePoint

When developing against lists, column names with spaces can be rather annoying. Internally SharePoint encodes spaces with the characters '_x0020_'. This isn't the end of the world but is a bit of a pain when writing code that uses the column names. Over the past few months I have found that I got into the habit of always creating columns without the space, and then renaming them.

As an example if I wanted to create a column named 'Account Number' I would first name it 'AccountNumber'. The internal name is set only once and is based on what the column is called when it is created. After the initial creation I can then safely rename the column with the space and still reference it as 'AccountNumber'.

I have developed the same habit for naming lists. With lists I think it is even more important to not have spaces as you end up with urls that look like this: http://site/lists/my%20task%20list/allitems.aspx. This is not particularly nice to look at and may even cause problems for some search engines. This is also makes it hard to read the URL and ends up as a bit of an accessiblity negative.

You can use the exact same technique as described for naming columns.

Only develop web parts when you have to

Sales, marketing, project managers and even IT managers always seem to latch onto the concept of building a web part to provide custom functionality in SharePoint. I'm always being asked to create a web part for various tasks which just complicates things. In reality 95% of the time a web control will do the job just fine, or better yet a user control.

A web part usually dictates that you will be dynamically creating controls at runtime or writing HTML tags in managed code. Both of these techniques are pretty horrible and provide no separation between logic and presentation. There are many examples of this on CodePlex.

A user control has a few key advantages over web parts:

  • Easier development
    User controls provide a design time surface and allows easier HTML integration

  • Easier deployment
    There are less steps required to make a user control available in a SharePoint site

  • Less unwanted HTML
    Web parts and the web part framework include additional HTML bloat that decreases accessibility

That said there are a few good reasons why you would want to build a web part:

  • Reusability
    If the component is going to be used in multiple pages with different configurations

  • Admin control
    Web part properties provide a convenient way for admins to manage settings

  • Collaboration
    Where users or content authors want to be able to add web parts to their own pages

If you decide that you do need a web part, I would still advocate using a user control. You can either use something like SmartPart, or preferably just embed it yourself as it's a very simple task. By embedding a user control to a web part in a 1-1 relationship, you have the opportunity to use web part properties as well as providing the best user experience.

The same theory can be applied to field controls. Another option when creating web parts is to use XSLT to control the display. I believe this is a great approach as it provides good separation between logic and presentation, makes it easier for integrators and promotes accessible HTML.

I guess web parts just sound cooler?