Inserting a SharePoint Web Part Generates an Internal Server Error (500)

One of my clients recently reported some strange behaviour by their SharePoint 2007 publishing site.

Inserting a web part would sometimes generate an internal server error (status code 500). You’ll notice the word “sometimes” which really isn’t something you want to hear when trying to diagnose SharePoint problems 🙂

Anyway, it turned out that the described behaviour is entirely reproducible as it is only in certain web part zones that the problem occurs – but it will always happen in those particular zones if a web part is attempted to be inserted.

So, what is the pattern? Have a look at the highlighted part of this screenshot:

The screenshot is in fact the Insert Web Part pop-up window. The key to solving the problem is in the ZoneDisplayName part of the querystring. It contains an escaped extended character, in this case the Danish letter “ø”, because the name of the zone is “Højre kolonne” (Right column).

The error does not occur when a web part is inserted into a zone with a name that doesn’t contain extended characters, such as “Venstre kolonne” (Left column).

The solution

Realising the SharePoint server lives behind an ISA Server I knew where to look first. The easiest way to bypass the ISA is to log into the SharePoint server with Remote Desktop, fire up a browser and try to insert a web part in the same zone. So that’s what I did.

Boom. No problems, the web part could be inserted.

The good news is that the problem can be alleviated by making a few changes to the ISA configuration. See this KB for more info: http://support.microsoft.com/kb/940248.

Solution: Accessing SharePoint Site or WebApp via Code Returns Null

A colleague of mine recently developed a timer job for SharePoint. The job worked fine on his developer and test machines but when he tried to activate it in the pre-production environment things went downhill.

An exception was thrown as soon as the timer job attempted to access the web application to add the timer job, ie. in this line of code:

SPContext.Current.Site.WebApplication.JobDefinitions.Add(timerJob)

The exception thrown was the good old “Object reference not set to an instance of an object” and further investigation showed that SPContext returned Null. Accessing the web application by referencing it directly (eg. SPWebApplication wA = SPWebApplication.Lookup(new Uri(http://site)); ) did not make a difference.

Coincidentally, the following error showed up in the event log: “Error in the site data web service”. This error mostly surfaces when SharePoint search chokes in a 32 bit environment due to large lists or inefficient use of memory capacity (heap fragmentation).

The solution

Restarting the below-mentioned services (net start/stop) fixed the problems for us:

net stop "Office SharePoint Server Search"
net start "Office SharePoint Server Search"
net stop "Windows SharePoint Services Search"
net start "Windows SharePoint Services Search"
net stop "Windows SharePoint Services Administration"
net start "Windows SharePoint Services Administration"
net stop "Windows SharePoint Services Timer"
net start "Windows SharePoint Services Timer"
iisreset /noforce

Source: Technet.

Crawl Problem with Multiple Value Lookup Fields Acknowledged by Microsoft

Last year we at PeopleNet ran into a problem when using lists with many columns, i.e. around 1600!

Indexing such a list would almost always fail with a timeout or out of memory error in the log, even though SharePoint is supposed to be able to handle at least 2000 columns without performance issues.

We corresponded back and forth with a Microsoft support engineer about the problem and it turned out that lists with many multiple value lookup fields will bring the SQL Server to its knees fairly quickly.

Microsoft has recently released a KB article in relation to this, however, it doesn’t specifically single out multiple value lookup fields as the culprit, although they almost always are.

Access Denied When Trying to Create a New Page on a Publishing Site

From time to time you may encounter that a user on a publishing site is denied access to creating pages, even if the Create Page link in the Site Actions menu hasn’t been security trimmed.

This is probably due to the user not having read access to the the master page gallery.

 

Solution

To remedy the problem, go to Site Actions > Site Settings > Modify All Site Settings > Master Page and Page Layouts. This takes you to the master page gallery.

Now go to Settings > Document Library Settings > Permissions for this Document Library and give the user (or the group he belongs to) read permission.

 

Developing Workflows Not Possible on 64-Bit SharePoint

As most companies are moving to the 64-bit platform of Windows Server and MOSS, more SharePoint developers are adopting this as their main dev environment.

However, if you plan to develop SharePoint workflows in Visual Studio 2008 on your new 64-bit box, you’re going to be disappointed.

Upon creating a new workflow in VS, an “Object reference not set to an instance of an object”-error pops up:

 

 

You can still get to the next step in the process where you have to chose the site which will be used to debug the workflow. Here too, you will be faced with an error:

 

 

The solution

Well, there isn’t any. Not right now anyway.

The only thing you can do is to continue developing in your old 32-bit environment and then move your WSP to the 64-bit box for installation.

All this is not a bug per se, rather, it’s down to Microsoft’s lack of resources in their dev team:

 
(source)

Hmm…

Item.Update() vs. Item.SystemUpdate() – Post Service Pack 1

Many of you have probably encountered the problem where a workflow triggers itself several times because the code carries out one or more Item.Update() commands. This can be extremely annoying because running extra workflows can be taxing on the server – even if you make sure that the extra workflows don’t make any changes to the element.

Then, you may have discovered Item.SystemUpdate() which in theory should rid the list of the all the extra instances of workflows because it doesn’t trigger an update event and thus flies under the radar of the workflow engine.

This seemed to work just fine for a while. Lately, however, it seems that SystemUpdate() has startet triggering events just like a normal Update().

 

Post Service Pack 1?

I found that many of my workflows now started behaving differently, i.e. they began triggering multiple instances of workflows.

It took me a while to realise that it probably was a “bug fix” in SharePoint SP1 that was causing the problem.

A glance at the documentation for SystemUpdate() reveals that events are indeed triggered:

There is no mention of SP1 but I assume that this was when the changes were made.

 

Solution

This is bad news for many developers but obviously a design decision at Microsoft so things probably won’t be changed back to the way they were.

From now on you have to make sure that your workflows only make changes to elements when needed. I.e. you need to only use Update() and SystemUpdate() when they are really needed and thereby minimise the number of redundant workflow cycles.

Alternatively, you could look into programming your own event handlers to obtain more granular control of when events are triggered. I may explore this subject in a future post.

Script Error in RTF Editor – Work-around

If you have worked with a localised version of SharePoint you may have encountered the annoying RTF editor script error.

Basically, the problem renders all instances of the RTF editor unusable, across the MOSS installation due to a common javascript error.

 

Symptoms

Every time a user opens an RTF editor and starts typing, a JavaScript error is fired, making typing almost impossible. This problem seems to be present in only some installations of SharePoint with regional language packs installed.

Here’s a screenshot of a Danish RTF editor with the script error:

The screenshot is from an English MOSS server with  the Danish language pack installed.

As annoying as the script error may be, it’s even more aggrevating that the error doesn’t occur on all servers with this exact setup. This means you can’t predict if a server is going to have this problem, purely based on the configuration.

 

Cause

The problem seems to be caused by bad code in one or more of the JavaScript files in the LAYOUTS folder. As you may know, the LAYOUTS folder is common for all sites on the MOSS server, i.e. all folders named _layouts is mapped to C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\LAYOUTS.

I can only speculate about how this can happen, but perhaps some versions (but not all) of the language packs include faulty JavaScript files. This could explain why this problem doesn’t occur on all MOSS servers with language packs.

 

Solution

Microsoft hasn’t released any fixes to counter this problem and there is no indication as to when or, indeed, if this will happen.

Obviously, my client needed a fix ASAP and this is what I came up with:

First, I installed Fiddler HTTP Debugger to determine which JavaScript files load when the RTF editor is launched.

Fiddler came up with the following list of files:

Note that 1030 directory is where the Danish files are located (1033 is English).

I now had a fairly good idea of where the bug was located but I didn’t have the patience to go through all that JavaScript code! Instead I copied the above 7 files from a healthy MOSS server (with Danish language pack) – and lo and behold – everything worked just fine.

My money is on HtmlEditor.js as the most likely culprit but I haven’t checked up on this.