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.

This is a re-post of a still relevant post from my old blog at SharePointBlogs.com:

—

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.

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.

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.

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.

ViewFormPagesLockDown

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.

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.