SPUpdatedConcurrencyException While Installing SharePoint 2010 Service Pack 1

After installing SharePoint 2010 Service Pack 1 for SharePoint Server, the SharePoint Products and Technologies Configuration Wizard (either from GUI or using PowerShell) may fail throwing the following exception.

An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown. Additional exception information: An update conflict has occurred, and you must re-try this action. The object SPUpgradeSession Name=Upgrade -20110924-194525-15 was updated by DOMAIN\ACCOUNT, in the PSCONFIG (7240) process, on machine SERVER. View the tracing log for more information about the conflict.

Total number of configuration settings run: 3

Total number of successful configuration settings: 2

Total number of unsuccessful configuration settings: 1

Successfully stopped the configuration of SharePoint Products.

Configuration of SharePoint Products failed. Configuration must be performed before you use SharePoint Products. For further details, see the diagnostic log located at [LOCATION OF LOG] and the application event log.

This KB article describes the cause and and solution for this issue. The suggested solution is to clear Windows SharePoint Services configuration cache. Unfortunately, this may not work in most of the cases. If it doesn’t work, there is another workaround. This is by setting the ‘command-line-upgrade-running’ configuration property to ‘No’ and running Configuration Wizard again. Entire steps are given below.

  1. Open command prompt as administrator.
  2. Type in the command: stsadm -o setproperty -pn command-line-upgrade-running -pv No
  3. Restart IIS and SP Timer
  4. Run configuration wizard: psconfig -cmd upgrade -inplace b2b -wait –force

The entire steps has to be done in all the web and app servers.

Incorrect search result title for PDF documents in SharePoint 2010 search

Recently we ran into an issue similar to what described in this post but with PDF documents. The SharePoint metadata “Title” is empty for these documents but the search results show some random text (which does not even present in the document) instead of document name. We have already implemented the fix for Word 2007 title issue described in the above mentioned post. On further investigating, it’s found that this behavior is due to the document’s internal property “Title” (not the document library metadata column “Title”). This title is set while generating the PDF files from a PDF creator/editor software. If SharePoint metadata “Title” is empty for the document, SharePoint crawler will consider the document’s internal property “Title” for the search result title. This can be verified by downloading the documents having incorrect title in search results and navigating to File > Properties after opening it in Adobe Reader. You can find the “Title” property is set to the text which is displayed in search results as title. So, I guess, the crawler considers text for search result title in the order of SharePoint metadata “Title”, document specific property “Title” and then file name if the first two are empty. I haven’t found a fix or workaround to change this order. The best option would be encouraging users to make good use of SharePoint metadata while sharing/collaborating on documents. Populating the SharePoint metadata associated with documents (especially “title”) will improve visibility of these documents in search.

Hibernate Option Missing in Windows 7 Start Menu

This could be because “Allow hybrid sleep” option is set to true. In order to change the setting,

  1. Open Power Options UI (Control Panel > Hardware and Sound > Power Options)
  2. Click on “Change plan settings” link against preferred power plan
  3. Click on Change advanced power settings link in “Edit Plan Settings” screen
  4. Expand the item “Sleep” and then sub item “Allow hybrid sleep”
  5. If the Setting is “On” then click on it and change to “Off”

Once this option is set, you can see “Hibernate” option is back in the start menu.

 

Programmatically Accessing SharePoint List XML Data in C# Code

SharePoint list data can be accessed in custom applications in C# without using SharePoint Object Model or Web Services. The list data can be retrieved as XML using a specific URL to the list (even using a web browser). This is described in this post. This URL can be requested from within the custom code to get the XML. The problem while creating an XMLReader object using the above URL is, it cannot authenticate the user (or application pool identity) into the SharePoint site unless anonymous authentication is enabled in the SharePoint site (which is false in most of the SharePoint implementations). A work around for this problem is to use HTTPWebRequest object to make a request to the list URL and to parse the response stream. Following is an example which takes app pool identity to authenticated into SharePoint site and to get the list data as XML.


String myURL = "<your site URL>/_vti_bin/owssvr.dll?Cmd=Display&List={List GUID}&XMLDATA=TRUE";
HttpWebRequest myRequest = (HttpWebRequest)WebRequest.Create(myURL);
myRequest.Credentials = CredentialCache.DefaultCredentials;
HttpWebResponse myResponse = (HttpWebResponse)myRequest.GetResponse();
Encoding enc = System.Text.Encoding.GetEncoding(0);
StreamReader reader = new StreamReader(myResponse.GetResponseStream(), enc);
string result = reader.ReadToEnd();

The string “result” can be used to create an XML document.

If you are unable to use custom app pools for your web application (older versions of IIS) you can create a NetworkCredentail object to specify custom credentials. In order to do that, replace the line


myRequest.Credentials = CredentialCache.DefaultCredentials;

with the following block.


CredentialCache credCache = new CredentialCache();
credCache.Add(new Uri(myURL), "NTLM", new NetworkCredential("<user name>", "<password>", "<domain>"));
myRequest.Credentials = credCache;

SharePoint List Data as XML

Getting data as XML from a SharePoint List or Library is very helpful when we need to use the data in a custom application (developed using a programming language like C#) or in InfoPath forms. The data from a SharePoint list can be retrieved in XML format by using the following URL:

<your site URL>/_vti_bin/owssvr.dll?Cmd=Display&List={<list GUID>}&XMLDATA=TRUE

You can mention different parameters like “Query”, “FilterField” etc. for specifying columns to be retrieved and for filtering the quantity of data being retrieved. An example for these parameter options is below:

<your site URL>/_vti_bin/owssvr.dll?Cmd=Display&List={<list GUID>}&&XMLDATA=TRUE&Query=<column name>&FilterField1=<column name>&FilterValue1=<value>

The FilterFiled and FilterValue in pairs like FilterField1=<>&FilterValue1=<> and FilterField2=<>&FilterValue2=<> and such.

“System.InvalidProgramException: Common Language Runtime detected an invalid program” while rendering Data View Web Parts

On a busy Tuesday, users of our SharePoint 2010 farm started receiving the following error on a web part page.

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator.

The web part page was Post.aspx page in a Blog site. We’ve modified XSLT of the web part displaying the post (title and body) in order to change the default blog picture (date view calendar) to poster’s profile picture.

The error message from ULS log was,

Error while executing web part: System.InvalidProgramException: Common Language Runtime detected an invalid program.   
at Execute(XmlQueryRuntime )   
at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer, Boolean closeWriter)   
at System.Xml.Xsl.XmlILCommand.Execute(IXPathNavigable contextDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter results)   
at System.Xml.Xsl.XslCompiledTransform.Transform(IXPathNavigable input, XsltArgumentList arguments, XmlWriter results)   
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.ExecuteTransform(XslCompiledTransform xslCompiledTransform, XsltArgumentList xmlArguments, Boolean bDeferExecuteTransform)   
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)

It looks like a random issue with SharePoint 2010 List View/Data View web parts whose XSLT has been customized. Restarting IIS on the web front end server resolved the issue. Hope Microsoft’s fixed the issue in SP1.