SharePoint 2013: InfoPath client forms may open twice [Oct15CU bug]

December 16, 2015 - 20:47, by Steven Van de Craen - 2 Comments


After a recent Patch Night one of my customers had pulled in SharePoint updates along with Windows Updates and people started complaining about changed behavior

  1. PDF files no longer immediately open in the browser. Instead the PDF client (Adobe Reader) opens up and provides rich integration with options to check-out and such
  2. InfoPath client forms would open twice; meaning the form opens when clicking the link, but also an extra dialog appears to open the form. Users click this and receive messages about the form already being locked (by themselves!)

Hello little bug

We traced it to core.js (and core.debug.js) having a modified date of “15/09/2015 14:45” where functionality to provide “Acrobat Pro X integration” was introduced.

The function OpenDocWithClient is called in two different locations but the return value is ignored. This makes the page refresh that occurs when clicking the InfoPath form link execute more than desired.

Here’s the original (bugged) and modified (fixed by me) versions:

Original (bugged) core.js image

As you can see I added the “return” keyword for the function call, so the event cancelling can continue to bubble up.

For the minified version (core.js) you’ll have to do some digging but if you look for static strings you can find the function call. I think it was “m()” in my case.

Here ya go

You can download this archive which contains both my original and modified versions. If you modify your environment you have to update all web front ends and users will have to clear the browser cache, but no iisreset is required.

Note that later patches may overwrite the system files again and undo your manual changes.

End credits

This bug is introduced with the October 2015 updates, including the full Cumulative Update package. We escalated the case to Microsoft and they confirmed the issue and our workaround. It will probably remain present in the upcoming Cumulative Updates (November, December, …) because it’s not wide-spread and also the PG needs to fit it in into their schedule.

Issue creating subsites when a built-in field is modified

June 30, 2014 - 14:26, by Steven Van de Craen - 10 Comments

One of our site collections in a migration to SharePoint 2013 experienced an issue with creating sub sites:

Sorry, something went wrong
The URL 'SitePages/Home.aspx' is invalid.  It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web.

Drilling down in the ULS logs we noticed these:

System.Runtime.InteropServices.COMException: <nativehr>0x81020030</nativehr><nativestack></nativestack>The URL 'SitePages/Home.aspx' is invalid.  It may refer to a nonexistent file or folder, or refer to a valid file or folder that is not in the current Web., StackTrace:  
at Microsoft.SharePoint.SPListItem.AddOrUpdateItem(Boolean bAdd, Boolean bSystem, Boolean bPreserveItemVersion, Boolean bNoVersion, Boolean bMigration, Boolean bPublish, Boolean bCheckOut, Boolean bCheckin, Guid newGuidOnAdd, Int32& ulID, Object& objAttachmentNames, Object& objAttachmentContents, Boolean suppressAfterEvents, String filename, Boolean bPreserveItemUIVersion)   
at Microsoft.SharePoint.SPListItem.UpdateInternal(Boolean bSystem, Boolean bPreserveItemVersion, Guid newGuidOnAdd, Boolean bMigration, Boolean bPublish, Boolean bNoVersion, Boolean bCheckOut, Boolean bCheckin, Boolean suppressAfterEvents, String filename, Boolean bPreserveItemUIVersion)   
at Microsoft.SharePoint.Utilities.SPUtility.ProvisionWikiPageHomePage(SPFile wikiPage)   
at Microsoft.SharePoint.Utilities.SPUtility.EnsureWikiPageHomePage(SPWeb web, ProvisionWikiPage provisionWikiPage)   
at Microsoft.SharePoint.SPWikiPageHomePageFeatureReceiver.FeatureActivated(SPFeatureReceiverProperties properties)   
at Microsoft.SharePoint.SPFeature.DoActivationCallout(Boolean fActivate, Boolean fForce)   
at Microsoft.SharePoint.SPFeature.Activate(SPSite siteParent, SPWeb webParent, SPFeaturePropertyCollection props, SPFeatureActivateFlags activateFlags, Boolean fForce)

System.Data.SqlClient.SqlException (0x80131904): Parameter '@tp_Author' was supplied multiple times.   
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)   
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)   
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)   
at System.Data.SqlClient.SqlDataReader.TryHasMoreRows(Boolean& moreRows)   
at System.Data.SqlClient.SqlDataReader.TryReadInternal(Boolean setTimeout, Boolean& more)   
at System.Data.SqlClient.SqlDataReader.TryNextResult(Boolean& more)   
at System.Data.SqlClient.SqlDataReader.NextResult()   
at Microsoft.SharePoint.SPSqlClient.ExecuteQueryInternal(Boolean retryfordeadlock)   
at Microsoft.SharePoint.SPSqlClient.ExecuteQuery(Boolean retryfordeadlock)  ClientConnectionId:1237a76d-2050-4ad5-82cd-cc9610f95061

The tp_Author gave an entry point into troubleshooting this issue. A quick loop through the fields on the web and then looking for ColName="tp_Author" revealed only the out of the box “Author” field being present. But it was modified at some point in history because the Group was different and there was a Version attribute present.

One can quickly test this behaviour on a clean new site collection and updating the field with powershell:

$w = Get-SPWeb http://intranet
$f = $w.Fields.GetFieldByInternalName("Author")

The schema xml will look as follows:

<Field ID="{1df5e554-ec7e-46a6-901d-d85a3881cb18}" Name="Author" SourceID="" StaticName="Author" Group="_Hidden" ColName="tp_Author" RowOrdinal="0" Type="User" List="UserInfo" DisplayName="Created By" Sealed="FALSE" ReadOnly="TRUE" Version="1" />

And also it will now be impossible to create any sites in the site collection (exception is the ‘blank’ site but it has the same issues once you activate the “Wiki page home page” feature and edit/save a page).


Luckily the product team has provided a method named Microsoft.SharePoint.SPField.RevertCustomizations() that will undo the changes and restore the site creation functionality.


SharePoint Information Management Policy: Invalid field name.

December 12, 2012 - 17:11, by Steven Van de Craen - 6 Comments

One of our projects makes use of Information Management Policies in SharePoint Server. We were programmatically adding these policies to Content Types, but for some reason this didn’t work when we migrated the application to SharePoint 2010.


We receive the following error:

System.ArgumentException: Invalid field name. {b0227f1a-b179-4d45-855b-a18f03706bcb} http://intranet 
   at Microsoft.SharePoint.SPFieldCollection.GetFieldById(Guid fieldId, Boolean bThrowException)
   at Microsoft.SharePoint.SPFieldCollection.get_Item(Guid id)
   at Microsoft.Office.RecordsManagement.InformationPolicy.Policy.EnsurePolicyFields(SPContentType ct)
   at Microsoft.Office.RecordsManagement.InformationPolicy.Policy.CreatePolicy(SPContentType ct, Policy globalPolicy)
   at VNTG.Initialisation.AddVersionLabelToContentType(SPContentType ctype)

If you dig deeper on that Field ID you quickly find that it’s the _dlc_Exempt field, one of the system fields for Policies.

At first we manually added them to our Content Types, but that didn’t feel right. It fixes the issue and allows you to work with the Content Type, but as soon as you start adding them to document libraries you’ll see strange things appearing. Fields are listed twice or missing in the List Content Type view, etc.


No need to manually start adding hidden system fields to your content types, just enable the “SharePoint Server Standard Site Collection features” feature on the Site Collection.

Follow Up - Programmatically approving a workflow

June 28, 2011 - 09:10, by Steven Van de Craen - 8 Comments

In my previous post “SharePoint 2010: Programmatically Approving/Rejecting Workflow” I mentioned the possibility of an issue when programmatically altering a workflow task. I have been testing it on several SharePoint 2010 farms with different parameters (different patch level, etc).


Set up

A simple SharePoint Designer 2010 workflow with the “Start Approval Process” action published to a document library. You start the workflow and a task is created for the approver.

The Approver is set to another test user, but all my code and script runs as the administrator (and thus System Account). Makes no difference though.

Note: when running the workflow multiple times (for testing), make sure to delete all tasks that are linked to your item. Or adapt the code below to not just take the first task in the collection…

Issue experienced

You alter the workflow task using a Visual Studio Console Application or Windows Application with the following (or similar code):

1 string url = "http://intranet/Shared Documents/Instructions.txt"; 2 using (SPSite site = new SPSite(url)) 3 { 4 SPWeb web = site.RootWeb; 5 SPListItem item = web.GetFile(url).Item; 6 SPWorkflowTask task = item.Tasks[0]; 7 8 Hashtable ht = new Hashtable(); 9 ht["TaskStatus"] = "Approved"; 10 11 SPWorkflowTask.AlterTask(task, ht, false); 12 }

After the code has run successfully you don’t see anything happen in the workflow status page. On some occasions you get “Due to heavy load, the latest workflow operation has been queued. It will attempt to resume at a later time” which could mean that the timer job hasn’t completed successfully yet. This message may or may not disappear for you.

Also, when trying to do a second alteration to the workflow task (by code or in the UI) you get “This task is currently locked by a running workflow and cannot be edited”.

So somehow your action was registered but not executed…

PowerShell to the rescue

Terminate the workflow (because it really hangs and there’s not much you can do with it) and kick off a new one.

Now open the SharePoint 2010 Management Shell (PowerShell) and run the following (or similar code):

$s = Get-SPSite("http://intranet")
$w = $s.RootWeb
$i = $w.GetFile("
http://intranet/Shared Documents/Instructions.txt").Item
$t = $i.Tasks[0]
$ht = new-object Hashtable
$ht["TaskStatus"] = "Approved"
[Microsoft.SharePoint.Workflow.SPWorkflowTask]::AlterTask($t, $ht, $false)

This WILL work and correctly finish the approval cycle in any of my tested environments.


You can really test this over and over and over; it will work in PowerShell but not in the Visual Studio 2010 application. I have tested Release versus Debug, in and out Visual Studio, etc.

Solution (July 2, 2011)

The big difference in both techniques is that the PowerShell remains open and isn’t disposing any objects. This allowed the workflow engine to complete the task.

Option #1
1 SPWorkflowTask.AlterTask(task, ht, true);

From MSDN:

“If true is passed as the argument to fSynchronous, this method waits up to 30 seconds to determine whether the attempted update was accepted by the workflow schedule as valid. The method then returns true if the update was accepted and not rolled back, or false if the update was not accepted. If false is passed as the argument to fSynchronous, this method always returns true.”


I have found this working most of the times, however some test runs still experienced the issue. Perhaps my test environment isn’t powerful enough or the action takes just a little too long to kick in ?

Option #2

Using the code below I learned it took about 21 seconds for the task to complete:

1 int i = 1; 2 while (!(bool)item.Tasks[taskId]["Completed"]) 3 { 4 Console.Clear(); 5 Console.Write("" + i + " " + task["Completed"]); 6 Thread.Sleep(1000); 7 i++; 8 }

That should give ‘option #1’ suffice time to complete the task, but still it didn’t in all occasions. If you’re experiencing this you could write up your own delay either as replacement to, or in combination with ‘option #1’.

1 SPWorkflowTask.AlterTask(task, ht, true); 2 // Additional delay 3 while (!(bool)item.Tasks[taskId]["Completed"]) 4 { 5 Thread.Sleep(1000); 6 }


Big kudos to my colleagues Tom De Wilde and Timmy Gilissen for helping me out !!

Troubleshooting issues with DispForm, EditForm and NewForm

March 11, 2011 - 18:17, by Steven Van de Craen - 5 Comments

Each SharePoint List can be altered with a custom DispForm.aspx, EditForm.aspx and NewForm.aspx to display, edit or create list items and metadata. This post is about restoring them to a working point.

Botched Forms

So one of these forms are edited to a loss state or deleted altogether. If this is the case it will have some tangible effects on the List display:

DispForm botched

The above screen shows a botched Display Form where the Item Url shows http://moss/?ID=1

Behind the scene

All three forms are based on the same template {SharePointRoot}\TEMPLATE\Pages\form.aspx and have a List Form Web Part in the “Main” WebPartZone with specific settings to connect to the list and which function they have. Also, the ID property of the List Form Web Part must match the value of the __WebPartId attribute.

SharePoint 2007

SharePoint 2010
SP 2007 NewForm SP 2010 NewForm


In a perfect world you can reset the edited form to the Site Definition or restore the it from the Recycle Bin, however this is often not the case.

Here’s a quick reference to the Microsoft.SharePoint.PAGETYPE enum:

Member name



Not used. Value= -1.


Default view. Value=0.


Normal view. Value=1.


File dialog box view. Value=2.


View, including both default view and normal view. Value=3.


Display form for list items. Value=4.


Display form for a file dialog box. Value=5.


Edit form for list items. Value=6.


Edit form for a file dialog box. Value=7.


New form for list items. Value=8.


New form for a file dialog box. Value=9.


Solution form. Value=10.


Not used. Value=11.


I’ve highlighted the three related to this matter (applies to both SharePoint 2007 and SharePoint 2010).


1. It’s easiest if you take a corresponding form from another SharePoint List in the site and export it (SharePoint Designer) or just copy it to a text editor. This way, most of the settings of the List Form Web Part are already correct

2. Generate a new GUID and fill that in for the __WebPartId and <ID> properties of the List Form Web Part markup. It has to be the same GUID but the formatting is different. See the above screens for samples

3. Update the <ListName> property with the List ID you’re targeting

4. Verify all other properties of the List Form Web Part and save the file as either DispForm.aspx, EditForm.aspx or NewForm.aspx

5. Import (SharePoint Designer) the page (or paste contents from the text editor)


I had a botched list in SharePoint 2007 and I wrote a Console Application for it. It takes the markup for a Form and I’ve replaced some values with placeholders already. It connects to the List and replaces the placeholders with real values, then it saves the file to SharePoint.

1 string listUrl = "http://moss/Lists/Sample List"; 2 using (SPSite site = new SPSite(listUrl)) 3 { 4 using (SPWeb web = site.OpenWeb()) 5 { 6 SPList list = web.GetList(listUrl); 7 RestoreListForm(list, PAGETYPE.PAGE_DISPLAYFORM); 8 //RestoreListForm(list, PAGETYPE.PAGE_EDITFORM); 9 //RestoreListForm(list, PAGETYPE.PAGE_NEWFORM); 10 } 11 }
1 private static void RestoreListForm(SPList list, PAGETYPE ptype) 2 { 3 SPWeb web = list.ParentWeb; 4 5 // Create Form File 6 string formFilename = null; 7 SPControlMode formMode = SPControlMode.Invalid; 8 SPFileCollection files = list.RootFolder.Files; 9 Guid wpId = Guid.NewGuid(); 10 CalcFormInfo(ptype, out formFilename, out formMode); 11 12 byte[] formContents = Encoding.ASCII.GetBytes(String.Format(pagecontent, list.Title, list.ID.ToString("B"), formMode, (int)ptype, wpId.ToString("B"), String.Concat("g_", wpId.ToString("D").Replace("-", "_")).ToLower())); 13 14 try 15 { 16 if (files[formFilename].Exists) 17 files[formFilename].Delete(); 18 } 19 catch { } 20 21 SPFile formFile = files.Add(formFilename, formContents, true); 22 } 23 24 private static void CalcFormInfo(PAGETYPE type, out string fileName, out SPControlMode mode) 25 { 26 switch (type) 27 { 28 case PAGETYPE.PAGE_DISPLAYFORM: 29 fileName = "DispForm.aspx"; 30 mode = SPControlMode.Display; 31 break; 32 case PAGETYPE.PAGE_EDITFORM: 33 fileName = "EditForm.aspx"; 34 mode = SPControlMode.Edit; 35 break; 36 case PAGETYPE.PAGE_NEWFORM: 37 fileName = "NewForm.aspx"; 38 mode = SPControlMode.New; 39 break; 40 default: 41 fileName = null; 42 mode = SPControlMode.Invalid; 43 break; 44 } 45 }

Find the complete code here: Program.cs. Note that there’s a different page markup and additional properties for SharePoint 2010 and the code needs to be adapted to that.

There’s no magic in the code above, just automating some of the manual steps in a quick fix script.


As a general practice, don’t directly modify the default forms, rather create copies or blank forms and update the List or Content Type Settings (through SharePoint Designer or programmatically) to point to your custom forms.

List Settings

Content Type Settings

If you do have a botched list, hopefully the above information can be of help.

SharePoint 2010: Increase debugging time by configuring Health Monitoring

February 6, 2011 - 17:51, by Steven Van de Craen - 3 Comments

If you’re developing for SharePoint 2010 the Application Pool has a setting called Ping Maximum Response Time with a default value of 90 seconds. In effect, this means that debugging your Web Part, Page, etc. in SharePoint 2010 will only work for 90 seconds and then you get this:

Debugger terminated by IIS

You can increase the value of Ping Maximum Response Time in the Application Pool Settings in IIS:

AppPool Ping Settings

You can also increase the value for future Application Pools via Set Application Pool Defaults (see Actions menu):

Set Application Pool Defaults

SharePoint 2010: User cannot be found after using stsadm migrateuser

September 7, 2010 - 20:18, by Steven Van de Craen - 0 Comments

I’m wrapping up a SharePoint 2007 to 2010 migration with custom development including programmatically copying files and folders, custom Event Receivers, Web Parts, etc.

Since the new setup uses a new AD domain, user accounts were mapped to new accounts and migrated using stsadm –o migrateuser.

After this we noticed errors like “User cannot be found”.

A bit of investigation showed that the ‘migrateuser’ operation didn’t update SPFile.Author or SPFile.ModifiedBy and querying those properties would throw the above exception.

A look at the ItemXml confirmed this:

<z:row xmlns:z="#RowsetSchema" ows_FileLeafRef="3;#sample.pdf" ows_Modified_x0020_By="OLDDOMAIN\olduser" ows_Created_x0020_By="OLDDOMAIN\olduser" ows_File_x0020_Type="pdf" ows_ID="3" ows_Created="2010-06-28 15:20:48" ows_Author="133;#New User" ows_Modified="2010-09-07 18:41:07" ows_Editor="1073741823;#System Account" ows_File_x0020_Size="3;#1035567" ... />


I didn’t want to script an update to all files (because that would trigger Event Receivers) so I avoided querying those properties directly and instead created an extension method to get those values through the SPListItem:

SPFieldUserValue fuv = new SPFieldUserValue(item.Web, (String)item["Author"]);
return fuv.User;

Scripting an update

There were a lot of Event Receivers in the custom solution so I didn’t take this path, mainly because I noticed in SharePoint 2010 the SPListItem.SystemUpdate() method will also trigger Event Receivers. Here’s a blog post on it: 

This is different from SharePoint 2007 as far as I recall. Feel free to comment on this.

Other mentions

This blog post by Keith Richie mentions a solution for SPWeb.Author:


Be sure to take this into consideration !

Office 2007 document templates and Content Types in SharePoint – lessons learned

January 29, 2010 - 15:09, by Steven Van de Craen - 1 Comments

A while ago I stumbled upon a serious design limitation regarding Content Types and centralized document templates. What then followed was a series of testing, phone calls with Microsoft, finding alternative solutions and deep dive into Office Open XML.

Request from the customer

“We want to use MOSS 2007 to create a collaboration site per project for our 400+ projects. These collaboration sites all use the same Content Types and document templates. We want to centrally manage those document templates so that we don’t need to make the same change 400+ times.”


Due to sizing we architected a solution with a dozen of Site Collections that would each hold a collection of project sites. We ‘Feature’-ized our Content Types and Site Columns so that they could quickly be activated on all Site Collections and used by the child sites. Document templates would be stored in a central document library and we would link to them in the Content Types on the project sites.

First issue

Linking to document templates really doesn’t play well with the Document Information Panel (DIP). I have blogged about this here:

Centralizing Document Templates in a library- Document Information Panel shows incorrect properties


We proposed a solution where the document templates in the central library would be pushed to the Content Type resource folder on site level. The code to perform the push would have to connect to the Site Collections, copy the template to the resource folder (http://sitecollectionurl/_cts/contenttypename) and link template and Content Type together.

When a Site Content Type is associated with a List it will be a List Content Type inheriting from the Site Content Type and the document template will be copied to the List Content Type resource folder (http://sitecollectionurl/listurl/Forms/contenttypename).

Second issue

Did I tell you that the column values (metadata) have different values based on the project site ? So when a project site is created we automatically update the List Content Type Column default value with the values for that specific project site. Unfortunately this is not supported when working with Office 2007 file formats because they only react on changes to the Site Column.

Consider the following scenario:

1) Set up a document library with a Content Type that has a text column with a default value
2) Upload a new .doc or .docx as Content Type template
TEST 1) Create a new document:
        .DOC:  the DIP will contain the text column with the default value
        .DOCX: the DIP will contain the text column with the default value
3) In SharePoint, modify the default value of the text column
TEST 2) Create a new document:
        .DOC:  the DIP will contain the text column with the updated default value
        .DOCX: the DIP will contain the text column with the original default value

Microsoft confirmed that this is by design.

Third issue

When designing our document templates with Content Controls mapped to our SharePoint fields we didn’t know that internally in the DOCX file it uses a GUID for mapping the Content Control with the SharePoint Metadata XML. For fields (Site Columns) created in the UI or through API this is the SPWeb.ID of where they were created. For fields created declaratively through Features this is the SPList.ID of where their Content Type is associated to.

So some things to notice

  • Creating a single document template with Content Controls mapped to your declaratively added Fields cannot be used in two different Document Libraries because the Content Controls lose the connection with Field (because the ID of the List is different and not updated in the Content Control)
    • The solution here is to create your fields in the UI or through the API (this could be in a Feature Activating event)
  • Copying a document template across Site Collections means different Web ID’s so it also affects fields created in the UI or the API


In the end we wrote some wrapper classes for Office 2007 file formats using System.IO.Packaging that would manipulate our document templates once they were copied over to a different Site Collection. We also rewrote our Features to create our Fields through the API (SPWeb.Fields.AddFieldAsXml()).

  1. Remove the SharePoint Metadata XML so that association of the Content Type to a List it would be regenerated automagically
  2. Loop through every Content Control and find to which Field they were mapped using information in it’s XPath. Then we would update the GUID’s in the Content Control to match the SPWeb.ID

Next time I’ll definitely take these design limitations into account. Lessons learned I’d say !

IE8 on Win7 RC: issues with OWA 2007

July 22, 2009 - 20:48, by Steven Van de Craen - 0 Comments

I would have preferred if Win7 RTM came sooner so that I could avoid migrating from Beta to RC and then from RC to RTM but no point to keep on whining about it :) So I decided to install the 64 bit issue of Windows 7 Release Candidate. I love how smooth those Win7 installs are. Very little interaction is required and the system correctly detects and installs my hardware.

Once up and running I logged in into my Outlook Web Access (Exchange 2007) and noticed a lot of flickering and errors in javascript files. Here’s an example:

Exception Details
Date: Wed Jul 22 20:41:09 UTC+0200 2009
Message: Unspecified error.
Line: 181

Tried the compatibility mode, tried the no-addons approach, no luck. However then I noticed there was another link in the Start Menu for Internet Explorer that read “Internet Explorer (64-bit)”. I tried it and poof: OWA behaved as a perfect citizen ! Joy !

Content and Structure Reports troubleshooting

June 29, 2009 - 21:30, by Steven Van de Craen - 1 Comments

If you have MOSS 2007 than you get the Site Manager for advanced management and with it the “Content and Structure Reports” (http://<server>/Reports List).

You can easily display the results of a report through the Site Actions menu. You can also add custom reports since the underlying technology is SPSiteDataQuery and the syntax to use is CAML. For an overview see Vince’s blog post.

If you have issues displaying results then remember you can use the Diagnostic Logs feature in SharePoint to troubleshoot. If there’s an issue the default logging level will pick up the Unexpected entry, but if you need additional info you can configure the logging level in Central Administration. You will need to be looking into the “Site Management” event category.

For example; if you portal has more than 1000 lists then by default the Reports won’t return any results. Use the logs to diagnose the issue:

06/29/2009 20:17:40.34     w3wp.exe (0x0960)                           0x0A3C    CMS                               Site Management                   622h    Unexpected    SMReportsData GetQueryResults - Query Execution threw SPException: The query cannot be completed because the number of lists in the query exceeded the allowable limit. For better results, limit the scope of the query to the current site or list or use a custom column index to help reduce the number of lists.    
06/29/2009 20:17:40.34     w3wp.exe (0x0960)                           0x0A3C    CMS                               Site Management                   6oz4    Medium      SmtPerf: SMDataSource.PopulateQueryResultsDataSet(SHAREPOINT\system) - Elapsed time= 00:00:00.0500720    
06/29/2009 20:17:40.34     w3wp.exe (0x0960)                           0x0A3C    CMS                               Site Management                   6oz4    Medium      SmtPerf: SmtMainPage.OnPreRenderComplete - accumulated(SHAREPOINT\system) - Elapsed time= 00:00:00.1802592

You can override the Lists settings by editing each report item and specifying the CAML List Type as follows: <Lists MaxListLimit=”0” />

(Make sure not to misspell the attribute: info)

Note that this does have a performance impact on your environment: Additional performance and capacity planning factors

Good luck !

 Next >>