SharePoint Sharpener

Obsessively Sharpening SharePoint

Archive for the ‘Configuration’ Category

Quick Fix: Remove Libraries, Lists From ToC

with 8 comments


I usually strive to first and foremost use SharePoint’s out of the box functionality to fulfil clients’ needs. Custom solutions with managed code, controlled deployment etc. are all well and good but sometimes you can get by with some simple frontend-configuration. This approach, if done right, enables clients to easier maintain and further enhance their SharePoint site once it’s up and running and the expensive SharePoint consultants have left the building.

Small adjustments can often be done with CSS or JavaScript/jQuery without remote desktop access to the server park. I know some hard core devs out there will oppose to making more or less unmanaged changes using something that hasn’t been pushed through a compiler. But like it or not, we need to get used to working within the constraints of Office 365 and SharePoint in the cloud. More about that in a later article.

Anyway, let’s skip the politics and get to the point of this post.


The problem

When you insert a standard Table of Contents web part it looks something like this:


And if you’re like most of my clients, you want it to look like this:


I.e. more “site mappy” without links to lists, document libraries and discussions.


The solution

This is the quick fix and therefore we’ll use client-side JavaScript to hide the unwanted nodes in the ToC.

First, create a library in the site to hold custom scripts. Why not call it “scripts”?



For easy editing, open the the new library in explorer view and create a text file, like so:



Open the text file in your favourite editor and paste the following JavaScript:

   1: <script language="JavaScript" type="text/javascript">

   2: // This script removes lists, libraries and discussions from Table of Contents

   3: // PeopleNet,

   4: var links = document.body.getElementsByTagName("a");

   5: for(ii=0; ii<links.length; ii++)

   6: {

   7:     if(links[ii].outerHTML.indexOf("BaseType") != -1 && 

   8:       links[ii].parentNode.parentNode.parentNode.parentNode.className == "level-section")

   9:     {

  10:         links[ii] = "none";

  11:     }

  12: }

  13: </script>


Save the file and go back to the SharePoint page where you placed the ToC web part. Below the ToC insert a Content Editor Web Part.

Back in the old days (i.e. SharePoint 2007) you’d edit JavaScript directly in the web part. This is still possible but it’s really quirky to work with. Instead, in the web part’s properties, point to the text file you created earlier:



This approach makes it so much easier to edit the JavaScript in a proper editor instead of in a SharePoint pop-up.

Click OK and save the page. The unwanted nodes are now hidden.



I’m fully aware of the implications of the above approach with regards to solution management, client-side performance and so on, but every solution needs to be seen in the context of the need it fulfils. And sometimes the above approach hits the mark.

And remember, the Table of Contents web part is just one of site navigation options in SharePoint.


Written by Thomas Sondergaard

September 27, 2011 at 10:44 pm

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

leave a comment »

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:

Screenshot: 500 Internal server error

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:

Written by Thomas Sondergaard

March 30, 2011 at 2:12 pm

Crawl Problem with Multiple Value Lookup Fields Acknowledged by Microsoft

leave a comment »

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.

Written by Thomas Sondergaard

August 13, 2009 at 7:39 am

Hardening Your MOSS 2007 WCM Application

with 4 comments

This is a re-post of a still relevant post from my old blog at

Today Last year at the SharePoint Conference in Berlin, Ben Robb of cScape Ltd gave a talk about configuring internet-facing web sites running MOSS 2007/WCM.

He brought up some interesting points about securing the application against unauthorised content editing and attacks from hackers.

Make sure your installation check list contains a least the following items:

1. Enable firewalls and standard network security
Fairly standard stuff, but necessary all the same.

2. Disable SMTP and incoming mail
In essence, you shouldn’t be running services on the server that aren’t necessary for MOSS. Also, close any ports that MOSS doesn’t need.

3. Secure the Central Administration site
Surprisingly, it is very common to leave this entry point wide open. The admin site should be accessible only via an SSL connection .

4. Use lockdown mode
Use this stsadm command to activate lockdown mode:
stsadm –o activatefeature –url <url> -filename ViewFormPagesLockdown\feature.xml
Read more about ViewFormPagesLockdown.

5. Restricted reader role
The anonymous user should have a restricted reader role which only enables viewing of pages, documents and images.

6. Policies
Constrain the maximum access per web application and deny all write access via http://sitename:80.

7. Content deployment
Use different servers for authoring and the actual internet-facing web application. Content generated on the authoring server (typically within the intranet) should be pushed out to the public site using scheduled content deployment jobs.

To many administrators the above bullets merely point out the obvious and do feel free to leave comments if you have any additions to the list.

Thanks to Ben Robb for providing 99% of the info for this post.

Written by Thomas Sondergaard

February 18, 2009 at 9:54 am

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

with 7 comments

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.



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.


Permissions: Master Page Gallery

Written by Thomas Sondergaard

February 6, 2009 at 2:05 pm

Enabling Anonymous Access on an Internet-Facing MOSS Portal

with 3 comments

If you are using the publishing features of SharePoint on an internet-facing portal, you probably need to enable anonymous access.

It’s a quick two-step process:


A. Edit Authentication Providers

  1. Go to Central Administration and then Application Management.
  2. Under SharePoint Web Application Management click Web application list.
  3. Select the web application on which you want to enable anonymous access.
  4. Under Application Security select Authentication providers.
  5. Click the zone you want edit (probably Default).
  6. Check the box Enable anonymous access and click Save:



B. Enable Anonymous Access at Site Collection Level

  1. Go back to your site and go to Site Settings – at site collection level.
  2. Under Users and Permissions click Advanced permissions.
  3. In the Settings drop-down menu select Anonymous Access.
  4. Click Entire Web site (or whatever applies to your setup) and click OK:



Remember, hardening your internet-facing MOSS installation is essential to shield your portal against intruders.

Written by Thomas Sondergaard

August 28, 2008 at 11:39 am

ViewFormPagesLockDown Does not Kick In

with 3 comments

Hardening your internet-facing MOSS installation is essential to avoid attacks. Check out Microsoft’s excellent guide which takes you through most of the steps required to shield your portal against intruders.

However, if your portal wasn’t born as a publishing portal, all anonymous users will have access to AllItems.aspx, DispForm.aspx and other pages that you probably don’t want outside users to see. For instance, you may have created a newsletter signup web part which posts data to a list (using elevation). In time, the list fills up with more or less sensitive information about your newsletter subscribers and you probably don’t want this information to end up in the wrong hands.

Unfortunately, it is quite easy for someone with just a litte SharePoint experience to guess the path to e.g. the AllItems.aspx page of a SharePoint list:


And if your portal is not locked down, all list items will be there for the taking.



Stsadm comes to the rescue yet again. To activate the lockdown, simply run this stsadm command:

stsadm -o activatefeature -url <site collection url> -filename ViewFormPagesLockDown\feature.xml

If you get the “Operation completed successfully”-message, you’re in business.

Well, almost…


The final step

You’ll probably find that the new feature still hasn’t kicked in. Fear not, you simply need to deactivate and reactivate anonymous access on the portal.

Written by Thomas Sondergaard

August 28, 2008 at 9:59 am