| Subcribe via RSS

SharePoint navigation: Quick launch vs. Navigation

Januar 7th, 2011 | 1 Comment | Posted in SharePoint

In this article I’ll write about some notes on how quick launch configuration differences between publishing and collaboration sites in SharePoint 2010.

If you navigate to the site settings the “Look and Feel” section you will see that there are different options available between collaboration and publishing sites.

Look and feel options of a publishing site (enterprise wiki):

Look and feel options of a collaboration site (team site):

On collaboration sites there is a link named “Quick launch” and on publishing sites there a link named “Navigation”.

The “Quick launch” configuration on collaboration sites is straight forward; you can add headings and links and modify the order.

Many users report to us that they would like to open links in new windows what seems not to be possible in team sites. Well it is, I’ll come back on this at the end of this post.

Now let’s have a look at the navigation option on publishing sites.

First of all, it looks totally different but we have a lot more options here. We can inherit navigation from above and we can configure both the global and the current navigation.

In addition it is possible to open links in a new window:

If the collaboration site is a sub site of a publishing site it inherits the configuration tool from above and offers the same tool like the publishing site. If we want to make the publishing navigation features available in a collaboration site collection, we just have to activate the publishing infrastructure feature on the site collection.

Wiki vs. Documents

November 9th, 2010 | 3 Comments | Posted in Office, SharePoint

Since SharePoint 2010 has been released half a year ago, lots of people start talking about the new cool wiki features it brought with it. Some people seem trying to use the wiki features whereever possible not thinking about the drawbacks. Documents seem to be old-fashioned, they’re not enterprise 2.0… 

Indeed, it is true that the SharePoint 2010 wiki feature are a lot better that the prior version and they combine very well with the also new social features like tagging, rating and the news feed.

In my opinion document are not old fashioned and I don’t think that a wiki always is a good tool to store data in. Maybe I’m one of the last guys who think documents are cool, especially now in SharePoint 2010! So check out my pros for document and wiki features in SharePoint 2010:

Documents can be send (E-Mail or fax) or printed as a whole. A wiki consists of linked pages that cannot be printed or send.

Documents can be read and edited offline/remote. Even nowadays offline people are guilted as homeless people, you cannot do that with a wiki.

Documents are a standardized storage medium. The wiki produces some kind of HTML that would pass no W3 standard verification.

The editor for documents named Word 2010 is the best document editor on this planet at the moment. No web based wiki WYSIWYG content editor can top that, even not the SharePoint 2010 rich content editor.

Documents can switch their file format as desired. A wiki cannot really do that.

Even documents can be edited by multiple persons simultaneous, a wiki is better in this because it consists of lots of pages. I’m not sure how well this works if two people try to edit the same wiki page at once.

A wiki can be combined with tagging and rating very well and a lot better than documents. You can tag or rate documents only as a whole while you can do that with each wiki page.

A wiki can be enriched by rich media like videos. It is possible to place videos within documents but they’re not really made for this.

My last point mentions search. A search is never better that the structure of the crawled information. This is important for both wiki and documents so I have no winner in this point.


I tried to find some strong arguments pro documents and pro wiki to make you think a while when you have to make the choice next time. If you think there are more reasons pro wiki or pro document, please leave me a comment on this.

Things to keep in mind when testing a custom or 3rd party design for SharePoint

Oktober 23rd, 2010 | No Comments | Posted in Branding, SharePoint
Some weeks ago I got a custom SharePoint design for testing. The design was implemented using a custom master page, some css files and an Office Theme file (thmx). At the first glance, the design looked great. So I decided to deploy it and show the design to colleagues. After some more testing it turned out that the design looked a bit different on nearly every browser and in each browser something different didn’t work properly.
Here’s a list of bugs that occured in the custom design I tested. It might help you to test your own custom or 3rd party design:

Scrolling behavior

The scrolling behavior depends on the ribbon tab. Sometimes the ribbon is scrolls with the content and sometimes it stays on top of the screen. Some master page or css modifications can change this behavior.

Wiki bracket features

There’s a wiki feature that lets you pick a page when you enter two brackets “[[“. Some master page modifications can break this feature, eg. modifying the element id “s4-workspace” into something else. Reason for this is a java script function that is looking for the element “s4-workspace”. If this element cannot be found, an exception pops up.

Wiki page history feature

The page history feature allows you to compare the current page version with previous versions. You also can restore previous versions. Some master page modifications can break this feature. In our case this feature broke if there were more than 1 version.

Colorings of texts

The theming enging is a nice and powerful but tricky feature. Be careful with making changes to the css files. Some texts might change their color if a theme is applied.

Silverlight mouse click positions

We added some silverlight components to SharePoint. Using Firefox version < 3.6.x the mouse click didn’t happen under the mouse cursor. The click event was raised about 200 pixels to the upper left.

Visibility of controls

Modifications to the master page or css file may result in the disapprearance of controls like the search box.

Different site templates

Different site templates use different master pages. Some of these do not support modifying them in the site collection settigs. Use a custom feature or the SharePoint designer in that case.
  • Enterprise wiki
  • Team site
  • My site
  • Enterprise search center

Different browsers

We found behavior differences between the following browsers:
  • Internet Explorer 7
  • Internet Explorer 8
  • Internet Explorer 9 beta
  • Firefox 3.5.x
  • Firefox 3.6.x
  • Iron/Chrome
  • Safari for Mac
  • Safari for Windows
So be prepared and keep these aspects in mind if you create your own SharePoint design or buy a 3rd party one.

Type not registered as safe error in a sandbox solution

Oktober 14th, 2010 | 1 Comment | Posted in Sandbox, SharePoint

In my case this error occured after renaming the web part class or modifying the namespace.

I found the SafeControl entry in the hidden file SharePointProjectItem.spdata located in the same directory as my web part class:

    <SafeControl Name="SafeControlEntry1" 
    TypeName="*" IsSafe="true" 
    IsSafeAgainstScript="false" />

So if you rename a web part or modify the namespace have a look at the following checklist:

  • Check namespace in .cs file
  • Check class name in .cs file
  • Check namespace and class name in .webpart file
  • Check namespace in the hidden .spdata file

Accessing field values in a sandbox solution

Oktober 14th, 2010 | No Comments | Posted in Sandbox, SharePoint, Uncategorized

In my case I tried to read a field value of type LinkFieldValue. The field type is defined in the assembly Microsoft.SharePoint.Publishing. I read the field value using this line of code:

var fieldValue = item["MyFieldName"] as LinkFieldValue;

This works pretty fine in a console test application or in a farm solution. In a sandbox solution the following error will occur:

Type ‘Microsoft.SharePoint.Publishing.Fields.LinkFieldValue’ in Assembly ‘Microsoft.SharePoint.Publishing, Version=, Culture=neutral, PublicKeyToken=71e9bce111e9429c’ is not marked as serializable.

It took me some time to solve this:

string value = item.GetFormattedValue("MyFieldName");
LinkFieldValue fieldValue = new LinkFieldValue(value);

It’s not a beautiful piece of code but it works.

How SharePoint extensions can block your upgrade path

Juli 2nd, 2010 | No Comments | Posted in SharePoint

SharePoint extensions are a risky factor when upgrading a SharePoint farm to a new version, e.g. From SharePoint 2007 to 2010. Every SharePoint extension has a potential to no longer function in the new version.

In my opinion a good upgrade strategy is this:

  1. Uninstall all extensions from your existing farm
  2. Upgrade the farm to the next version
  3. Upgrade each solution and reinstall it

The point here is that some solutions might not be able to be upgraded because the vendor does no longer support it or your last SharePoint developer has left the company as the new SharePoint version was released. If this is the case, your site might no longer work with the new SharePoint version.

If your site breaks in the new SharePoint version depends on the kind of extension you use. A site will continue to work if you cannot upgrade a web part solution. But here are some kinds of solutions that cause content to be not accessible when the solution is not upgradable:

  • Custom field definitions
  • Custom site definitions
  • Custom list definitions

I recommend avoiding these kinds of solutions if possible and using site or web templates instead of definitions and using list templates instead of list definitions.

If you have any opinion on this please feel free to comment on this.

SharePoint List vs. Database and Excel

Oktober 30th, 2009 | No Comments | Posted in SharePoint

Yesterday I had a discussion with my colleague about SharePoint lists. Some people use SharePoint to store documents and manage tasks. List data is often stored in Excel files within SharePoint like phone numbers or birthday lists.

We asked us: What would be the best place to store about five linked lists with a few hundred items. We didn’t come up with a final decision because of personal opinions so I tried to find some facts I can make my decision on.

SharePoint List Benefits

When you create a SharePoint List you get a couple of features a Database for example does not deliver:

  • User interface that allows you to edit, filter, sort, group the data
  • Ability to search
  • Security management on list level and item level
  • Integration with other lists and libraries
  • Recycle bin
  • Multiple users can edit data simultaneously
  • Rich text support
  • SharePoint alerts
  • RSS
  • Select data from other systems using BDC lookup columns

SharePoint List Limitations

Electronical processing of data

Automatic processing and modifying data within SharePoint lists using Event Receiver, Workflows oder Web Services is much more difficult and slower that using Excel or Databases.

Accessing the data from an external system

SharePoint lists cannot be accessed from systems outside of SharePoint very easily. You will have to fight security and the web services of SharePoint. If this is the case a dedicated database might be the best option even if you have to create a user interface for the data management. With SharePoint 2010 it looks like this will become veery easy without coding.

Complex relations between tables

Relations between SharePoint lists is something I try to avoid if there is some potential that things might grow.


I still am not sure where to store 5 linked lists with a few hundred items. But I do see lots of reasons to use SharePoint lists.

I will add more facts while the discussion goes on. If you have any suggestions, feel free to add your comments.

SharePoint Performance Checklist

September 7th, 2009 | 1 Comment | Posted in SharePoint

I’ve made lots of performance tunings during the last weeks and figured out that this can be a weird, long and complex task. On the one hand there are many built-in mechanism that can be configured and on the other hand there are lots of things you shound pay attention to when you develop your own web parts.

I’ve assmebled a little checklist you can walk through. I do not cover everything in detail but I’ve linked a couple of online posts and articles where you can start reading if you need more information on specific tasks.


Limit global Navigation & Permission breaks

If you have a collaboration site collection with individual permissions on each website or at list level then your navigation controls can slow down your sharepoint performance. SharePoint has to check your permissions for each item listed in the navigation controls what can be very time consuming. Because the global navigation is placed on every web site this impacts your whole site collection.

So if you have lots of permission breaks either limit the items displayed by the navigation controls and eleminate the default navigation treeview or implement your custom navigation provider using caching mechanisms and activate object caching.


Activate Blob Cache

The blob cache can be used to reduce the round trips between the WFE and the database server. If activated, all images stored within the site collection are cached on the hard disk of the WFE server. The blob cache can only be configured within the web.config of each web application.

Another big point of the blob cache ist the max-age attribute. It tells the browser not to request that image again for a given period of time. So you can use this attribute to reduce the requests between the browser and the WFE.

In the web.config file search for the <BlobCache …> section and set it to the following example:

<BlobCache location="C:\blobCache" path="\.(gif|jpg|png|css|js)$" maxSize="10" max-age="86400" enabled="true"/>

Now the cache is enabled and the files with the defined extensions are stored on WFE hard disk and the browser will not rerequest them for about 24 hours.

Selvagan posted a great article about the blob cache.

Tip: Store the cached files on a different hard disk as the web server to maximize the I/O throughput.

If you want to clear the blob cache on all WFE servers at once you need this codeplex solution.


Activate Output Cache

Output caching enables SharePoint to cache HTML markup of Web Parts or complete web pages. This makes sense most if you have a publishing page with anonymous access enabled. If you enable output caching on a site with authenticated users the output is cached for each user individually. This can become a memory issue.

Read more in the output caching secion of this MSDN article.


Activate Object Cache

SharePoint can cache objects like navigation elements and Cross-list query results. This should be activated on every SharePoint site. Microsoft has posted an article on how to activate and configure the object cache.


Indexing of columns

If you have large list views that are ordered or filtered you should place an index on those list columns where you set the filter on. An index can also increase the performance if you have a lookup field with many items in the lookup list.

Have a look at this Microsoft article on managing lists and libraries with many items and read the Microsoft White Paper: Working with large lists in Office SharePoint Server 2007.

Andreas Grabner wrote an article on how list column indexing works under the hood.


Be careful using the Content Query Web Part

If you use the Content Query Web Part to collect data from large lists or from your whole site collection you have to be knowing what’s happening in detail. You can increase CQWP performance using object cache and implementing your own CQWP. Ranjan Banerji wrote a great article on content query web part performance.


Use Warmup Timer Job

If you restart your server for maintenance or reset your IIS during a solution deployment all your web applications are shut down. Now, when the first user requests your website it takes up to a couple of minutes until the web application is reloaded and caches are filled. It would be nice if theres someone who takes a browser and calls every website before the first user does.

Joel Oleson wrote a post about a script that acts like that “someone” and triggers all websites of your site.

Andrew Connell write a post on how to implement the script as a timer job. You can download the timer job from msdn.


Watch your crawler

A misconfigured crawler can push your server cpu usage to 100%  from dusk till dawn. This can happen very quickly if you have an intranet website with lots of members creating new content and uploading tons of documents. Then the crawl duration is growing very quickly.

For example if you scheduled your crawler to run every 30 minutes and the crawl duration is longer than 30 minutes your server is crawling all the day. So you should check the crawl log periodically. If your crawl duration becomes too long you have to reconfigure your crawl schedule and crawl your content only once every two hours. If your search index may not be out of date for more than 30 minuts you have to add more search server to the farm.

Patrick Thisseghem wrote a great book about the SharePoint search and indexing engine: Inside the Index and Search Engines: Microsoft Office SharePoint Server 2007


Use tools to measure site request performance

Use tools like Fiddler, YSlow and Firebug to find out whats going on between the browser and your SharePoint server.  Find out if there are long waiting times, too many server requests or ineffective java scripts slowing down your website. Use these tools to check if blob caching works.

SharePoint works best if used with Microsoft Internet Explorer but I love the Firefox plugins YSlow and Firebug because they are very easy to use, detailed and give lots of hints if your performance is bad.


Measure your Web Part performance

Every custom web part can slow down your SharePoint website. The SharePoint API often performes not as expected and this can impact your Web Part performance. Use the Stopwatch class in your web part to measure critical code parts and write the results into the web part. Implement a Web Part property to switch on/off the stopwatch results.

There are developers out there saying perfomance measures should be part of productive code and rather be made using unit tests or console applications. Those developers are basically right but might have never been to the wild west of SharePoint. A Web Part lives within a SharePoint site and no unit test or console application can simulate that so you have to use your productive web part to make performance tests.

Tags: , , , , ,

What to do if SharePoint throws “500 Internal Server Error”?

Mai 28th, 2009 | No Comments | Posted in SharePoint

Yesterday we added a new server to the SharePoint farm. When calling a site over that new server we got an 500 Internal Server Error. There was no entry in the EventLog and even no information in the server log files. We wer trying lots of things but nothing got better. So what could we do to get more information?

We changed the diagnostics logging level from Unexpected to Verbose:

Diagnostics Logging Level

(Central Administration > Operations > Diagnistic Logging)

Then we recalled the website and finally got an error in the log files:

"Cannot make a cache safe URL for "init.js", file not found.
Please verify that the file exists under the layouts directory."

The file is part of every language pack so in our case we did not install a language pack on the new server that is used by the site.

Although this is a simple option to get more error information it’s forgotten or overseen very often.

Tags: , , ,

SharePoint Groups vs. Active Directory Groups

Mai 19th, 2009 | 9 Comments | Posted in SharePoint

I’ve discussed this topic quite often during the last months. After those discussions I figured out that its more a question when to use what kind of group rather than what kind is better than the other. In this post I just write down some advantages and disadvantages of the group types and let you choose what kind fits better for your needs.

SharePoint Group Active Directory Group
plus Members of this group can be added/removed from within SharePoint. The permission to add or remove users from the group can be delegated to SharePoint users. plus Members of this group can be managed within Active Directory. Only Active Directory administrators have the permission to modify group memberships.
plus Members of this group can be visible to users. minus Members of this group are not visible to users.
minus Cannot contain another SharePoint group as member. plus Can contain another Active Directory Group.
plus Must have a unique name on site collection level. The name is the unique identifier of the group. minus Can cause serious problems in lage scale scenarios: A user might only be a member of 1024 Active Directory groups (recoursively). If this number is reached the user is no longer able to log on to Windows.
Read the Microsoft documentation for more information.
plus Can contain SharePoint users that do not exist in the Active Directory.
Tags: , , ,