Cumulative updates packaging changed for SharePoint 2010

while browsing the updates page on Technet I found:

The packaging of cumulative updates changed as of August 31, 2011. The following packages are provided for cumulative updates:
• SharePoint Foundation 2010
• SharePoint Foundation 2010 + SharePoint Server 2010
• SharePoint Foundation 2010 + SharePoint Server 2010 + Project Server 2010
As a result of the new packaging, it is no longer necessary to install the SharePoint Foundation cumulative update and then install the SharePoint Server cumulative update.


Getting rid of “Could not find stored procedure ‘dbo.Search_GetRecentStats'” error

another one of those errors that can appear in your ULS logs which can easily be solved. This error also logs events in the Application eventlog with ID 6398 and 5586.

I found the solution to this issue on the SharePoint forum here

This happens when you have the Usage and Health Data Collection Service Application installed. This service application creates a database just for logging. Apparently the Search Service was trying to make entries in that database and couldn’t.

The solution to this issue is to enable the Usage Data Collection, which is not enabled by default when you create the Usage and Health Data Collection Service Application .

To enable the Usage Data Collection navigate to Central Admin\Application Management\Service Applications\Manage service applications. Once there highlight the WSS_UsageApplication (or whatever name you gave the service application)and select manage from the ribbon. Under Usage Data Collection check the box. Under Health Data Collection check the Enable health data collection box. Hit OK and the errors will be gone.

Change Locale of Site Variation Label in MOSS

Since some time, my customer had a nasty issue for which I did not see a solution at first. My customer is running its Intranet for years now on MOSS and uses a customized Publishing Portal with Site Variations in 3 languages, English, Dutch and French. The only problem with these Site variations is that the source Variation Label was created with the wrong Locale setting. The variation label was created with a name EN, language English (United States) , but with locale Dutch (Belgium) instead of English (United states).

Now when the hierachy was created, the subsite EN was created with the wrong locale. No problem there because you can change the locale of that particular subsite in the Site Settings – Regional Settings.

The problem my customer was facing is that clients targeting the root site collection and thus the Variation root site, where redirected to the wrong subsite if their browser had the locale Dutch (Belgium) defined. These client all ended up on the EN subsite instead of the Variation NL that was created with locale Dutch (Belgium).

The solution for this problem is to change the Locale in the Variation Labels in the root site. Unfortunately you cannot modify this value once the Variation Label is created (the field is greyed out). A possible solution would be to delete the Variation Label and recreate it. Because of the fact that this was the corporate intranet with lots of content on it, I did not feel very comfortable deleting the Variation Label, because this means you would have to delete the subsite as well before being able to recreate the Variation Label after which yould have to restore the subsite’s contents, etc. Furthermore the Variations system in MOSS is already very fragile and this would certainly break some other things.

Now after searching for a while and snooping around in the content database, I found out that these labels are stored in a hidden list in the Root site called, you’ll never guess, … “Variation Labels”. Now my trick for accessing this a hidden list by just typing the URL like Labels/AllItems.aspx did not work.

Powershell to the rescue!

I was able to access the list and change the locale value for the specific Variation Label with the following set of powershell commands:

#First Load SharePoint

#Connect to SPSite object
$site = New-Object Microsoft.SharePoint.SPSite("")

#Connect to root SPWeb
$web = $site.AllWebs |where -FilterScript { $_.Url -eq ""}

#Connect to Variation Labels list
$list = $web.Lists |where -FilterScript { $_.Title -eq "Variation Labels"}

#Get the List item for the Variation Label
$listitem = $list.Items |where -FilterScript { $_.Title -eq "EN"}

#Check the Value

#Modify the value to English (United States)
$listitem["Locale"] = 1033

#Dispose of objects

Now if you ever need to chaneg the locale value, then this script will help you out. The only thing you need to find out is the value for your specific language. What I did to find out the specific value was to create a new Variation Label on my test environment with teh locale I wanted and fetched that value with the exact same commands.

SharePoint 2010 Knowledgde articles

So you took the step of installing your first SharePoint 2010 server or farm. You install the server, but not everything goes smoothly or doesn’t work as expected. What’s next? Well, a good place to start is to use the knowledge base that Microsoft tools use, such as the System Center Operations Center (SCOM) Knowledge articles. These are the articles that typically show up in SCOM, provided that you have installed the SharePoint 2010 Management pack,  if it has encountered an error on your SharePoint installation or farm.

The knowledge articles can be found at

Thanks to Neil Hodgkinson (@Nellymo) for providing this tip and link on Twitter

Unable to edit Document Library Column: Unknown Error

It has been a while since my last post and since then, I encountered some interesting issues, worth writing about. This one amazed me.
One of our users complained that he was unable to edit a standard choice field that he just created in a document library. Whenever he tried to edit the filed he got the dreadfull “Unknown Error” from SharePoint.
A little research and some adjusting of diagnostics logging when reproducing the error, showed the following error in the ULS logs:

Application error when access /_layouts/FldEdit.aspx, Error=Object reference not set to an instance of an object.  
at Microsoft.SharePoint.ApplicationPages.BasicFieldEditPage.get_ContentTypeId()    
at ASP._layouts_fldedit_aspx.__Render__control433(HtmlTextWriter __w, Control parameterContainer)    
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)    
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)    
at System.Web.UI.HtmlControls.HtmlContainerControl.Render(HtmlTextWriter writer)    
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)    
at System.Web.UI.Control.RenderChildrenInternal(HtmlTextWriter writer, ICollection children)    
at Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase.RenderChildren(HtmlTextWriter writer)    
at System.Web.UI.Page.Render(HtmlTextWriter writer)    
at Microsoft.SharePoint.WebControls.UnsecuredLayoutsPageBase.Render(HtmlTextWriter writer)    
at System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint)

Exception Type: System.NullReferenceException  Exception Message: Object reference not set to an instance of an object.

Now this error does not say much, so I started to look for it in blogs. Now it turns out that someone had faced the exact same issue with oddly enough the exact same name of the column causing the issue. My user had called the column ‘doctype’ . According to the blog post, the name doctype is a reserved word in SharePoint and strangely enough SharePoint does allow you to create a column with that name, but then you will no longer be able to edit it again.

As suggested in that post, I was also able to delete the column using SharePoint Manager 2007 (

My source:




Saving Document to SharePoint using Office 2003 resets choice metadata fields to default values

I was recently facing an issue as described in

Recap from original post:


  • A custom “Master Document” content type inherits from Document
  • The “Master Document” content type has five additional choice fields
  • There are five custom “Document Template” content types that inherit from the “Master Document” content type
  • Each of the “Document Template” content types uses a different Word document template (.dot) file
  • Each of the “Document Template” content types have been added to a document library


  1. I click on a document in the library
  2. Document opens up in Word 2003 for me to edit
  3. I make some changes and save
  4. A box pops up called “Web File Properties”. The window contains all of my custom metadata properties and the ContentType field. The ContentType field is set correctly to the current content type. The other fields are reset to their default values. This same window can apparently be opened by going to File -> Properties

This window by itself would be fine except for two reasons:

  • It includes the ContentType column
  • All of my custom metadata properties are visible but are reset to their default values instead of whatever values were previously selected. This means, every time the user wants to save the document, they have to remember what properties were tagged and set them back.


  1. Can I disable this Web File Properties box?
  2. If no… can I get the fields that show up to be populated to their correct values?
  3. If no… is there a way to disable my fields from displaying in this window?
  4. If no… is this a SharePoint page that I can modify?

***Edit with some more information***

It looks like this only happens in Office 2003 and looks like it affects Choice fields. If I create the same column as a Lookup field, it seems to work.

Edit again

Looks like if the lookup field is a multi-select field then it will not show up in the Web File Properties box at all (single select lookups still work).

edit 10/14/2009

Link to the KB Article mentioned below by Brenda:

My Solution:

Of Course the suggested hotfix, which in fact is the June Cumulative Update for WSS did not fix my issue, but I did find a solution at the end.

What really happens when you call the Web File Properties box is that your client will download 3 javascript files from the server:  bform.js, core.js and init.js. You can check this by by opening up the document library causing the issue and clearing your temporary internet files at that time. When you now call the Web File Properties in Word 2003 through File –> Properties, you will notice these 3 script files being downloadin in your temprary internet files folder.

On the SharePoint front-end servers, you can find these files in the 12-hive\Template\Layouts\<LCID> folders, where you have  to replace <LCID> with your language codes installed (1033, English; 1043, Dutch; …. you get the picture, right?)

So the problem is most likely caused by one of those javascript files. Now we have had the issue since we had installed SP2 and the June Cumulative Update. So I decided to restore these 3 script files and play aroun with these files for a while.

As it happens, my problem went away by replacing the bform.js file with a pre-SP2 version and clearing my

So if your issue does not get resolved by the suggested method of Microsoft, which is installing the latest Cumulative Update, then try restoring a previous version of this file and remember that you will need to clear this file from your client’s Temporary Internet Folder to force a download of the latest version from the server.