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.

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.