Adding Person or Group data to List Instance in CAML

Here’s a quick gem from the comments on MSDN for Field Element (List -Definition).

…to set the value of a “Person or Group” field if the ID of the user is not known, …use the value “-1;#<domain>\<username>”.

This is useful in the scenario that you want to pre-populate a List Instance with data for a ‘Person or Group’ field (Type=”User” in CAML). 

The numeric component of the field’s value is the ID of the user within the UserInfo list within SharePoint and this value will change for the same user in different environments (for example development, test and production).  By setting this to ‘-1’, SharePoint will resolve the specified fully qualified domain name of the user against the UserInfo list for the current environment.

Thanks to Rudolph de Wet for the advice.

Central Administration Navigation in 2010

Working on a migration project has given me apple opportunity to use the revised Central Administration web site provided by SharePoint 2010. Unfortunately I’d have to conclude that in some respects it represents a retrograde step, especially in terms the usability of the site navigation.

The problem is that the navigation is not always updated based upon the context of the page you are viewing, in many cases leaving you with no option but to return to the home page and navigate through several pages to get back to your original context.

This is perhaps best illustrated with one of the more commonly used Service Applications, the User Profile Service Application. Here we are, happily browsing the User Profile Service Application:

Clicking on the Manage User Profiles link takes us to the Manage User Profiles page:

So far, so good you might say.

However, should you wish to return to the User Profile Service Application page you can’t using the navigation provided by the Central Administation site. The site breadcrumbs offer only one choice, to return to the Central Administration home page, and the Quick Launch links are entirely static. This is very frustrating.

I thought I had a cunning workaround for this issue; after all Central Administration is a SharePoint Foundation site and we can edit the Quick Launch ourselves to add-in commonly used links as we would any other site?

Unfortunately, this isn’t the case and no matter what you add to the Central Administration’s Quick Launch navigation configuration none of the links are ever displayed in the Quick Launch navigation bar.

So for now I’m reduced to using browser bookmarks to navigate between Service Applications.

Interestingly this isn’t the case for the administration of Timer Jobs which provides a context-based menu located above the main Quick Launch navigation:

I don’t know why this wasn’t implemented for other areas of the Central Administration site. If it had been, it would make the site a lot easier to use.

MOSS Search Issues related to User Profile for Service Account

Hopefully this may prove a sanity saver for anyone else who encounters this issue…

When executing a crawl from Search Administration, the crawl log shows the following error:

The protocol handler cannot be found. Check that the handler has been installed.

Within Event Viewer management console, the Application log had the following Warning:

The start address cannot be crawled.

Context: Application 'SharedServices', Catalog 'Portal_Content'

Details:
The protocol handler cannot be found. Check that the handler has been installed. (0x80040d1a)

This prevents any crawling of SharePoint content and no amount of starting and stopping the Office SharePoint Server Search service will fix the problem.

…and this Error:

The gatherer service cannot be initialized.

Details:
The Temp folder is on a drive that is full or is inaccessible. Free up space on the drive or verify that you have write permission on the Temp folder. (0x80070660)


On starting the Office SharePoint Server Search service, the same error was noted:

Windows cannot log you on because your profile cannot be loaded. Check that you are connected to the network, and that your network is functioning correctly.

DETAIL - The system cannot find the file specified.

What happened was that the local User Profile of the service account identity used for the Office SharePoint Server Search had somehow become invalid.

A possible cause for invalid master page error

Another one for to save my sanity… and yours hopefully.

If you are updating the master page URL through managed code then you might experience the issue where the master page is applied successfully but on the Site Master Page Setting page you encounter the following errors:

• The site master page setting currently applied to this site is invalid. Please select a new master page and apply it
• The system master page setting currently applied to this site is invalid. Please select a new master page and apply it

When the page loads it attempts to match the currently applied master page with a value from the list of master pages in the Master Page Gallery in order to indicate the selected master page in the drop list:

This match is case-sensitive therefore you must ensure that when the MasterUrl and CustomMasterUrl values are updated using the object model that you use the exact name for the master page as it appears in the Master Page Gallery.

Don’t include a plus (+) sign in filenames for files uploaded to SharePoint

This one is for my own sanity as much as for anyone else’s benefit: don’t include a plus sign (+) in filenames for files uploaded to a SharePoint document library.

The + character is permitted in a filename within Windows, and SharePoint will permit the file to be uploaded, however when the file is accessed the + is not escaped within the URL and an HTTP 404: File Not Found will be displayed.

Further to this, Tim Jones provides an excellent solution (and discussion leading up to his solution) on how to strip invalid characters from files when uploading to SharePoint.

Custom Master Page and My Sites

My Sites are often branded with a custom master page, using feature stapling to apply the customisations. The SharePoint Team Blog contains a good description of how to do this.

However, there is a gotcha with updating the MasterUrl and CustomMasterUrl properties of the My Site. The default value for these properties gives the full path to the master page catalogue and default.master page: /personal/user/_catalogs/masterpage/default.master

Therefore rather than replace the entire path when setting the master page simply replace the string “default.master” with your chosen custom master page:

var masterPageUrl = web.MasterUrl.ToLower();
masterPageUrl = masterPageUrl.Replace("default.master", "mycustom.master");
web.MasterUrl = masterPageUrl; 

Add Web Server role before installing SharePoint

The Web Server role should be added to the server prior to installing SharePoint otherwise slipstreamed updates are not deployed correctly on Windows 2008 R2.

Background

Having followed the instructions listed on TechNet for a Windows 2008 deployment using a slipstreamed installation source, the following error was encountered when attempting to create a Publishing site collection:

The Office SharePoint Server Standard Web application features feature must be activated at the web application level before this feature can be activated.

Looking at the version number reported by Central Administration and that shown for Microsoft.SharePoint.Portal.dll it was clear that the SP2 update had not been correctly applied; the dll was reporting the original version number whereas Central Administration reported the correct version number for SP2.

This was confirmed when running the stand-alone SP2 update packages; the update package for WSS 3.0 claimed that the update had already been applied but the Office SharePoint Server update package did not detect that SP2 had already been applied. Re-applying the SP2 update for Office SharePoint Server fixed the problem quoted above.

To prevent this from happening in the first place, add the Web Server role before installing SharePoint and the updates will be applied correctly.

For more information refer to the answer given in this TechNet post: Error trying to activate Publishing Infrastructure

SharePoint Database Sizing – a request for information

When planning a deployment, one of the fundamental issues that needs to be addressed is providing sufficient capacity to accommodate the anticipated growth of the SharePoint environment. Microsoft provides some detail on best practices for capacity planning and management for SharePoint, mostly focussed on content or search database sizing and the effect upon performance.

Information on the size of SharePoint configuration databases is however decidedly thin on the ground. The second of the TechNet articles linked above lists the configuration database as being around 1.5 GB in size and states that the “configuration database will generally not grow past this size” although this is “not a hard limit”.

So this begs the question: just how large can the configuration database get? And how about the other supporting databases such as the Central Admininstration (SharePoint_AdminContent) and SSP database (SharedServices1_DB)?

And for the answer to this I’m turning to you good readers. Please vote to indicate the size of your configuration and other supporting databases so that we can all benefit from being better able to plan for the growth of SharePoint. If you have some interesting findings you’d like to share, please leave a comment.

Consuming Filter Web Parts with a Web Part containing a User Control

When wrapping an ASP.NET User Control in a web part, the user control is usually loaded in the CreateChildControls() method as shown below:

protected override void CreateChildControls()
{
  if (!_error)
  {
    try
    {
       base.CreateChildControls();

       // Your code here...
       MyWebUserControl myControl = 
         (MyWebUserControl)Page.LoadControl("~/_controltemplates/MyWebPart/MyWebUserControl.ascx");
       myControl.DataProperty = SomeProcessing();
       this.Controls.Add(myControl);
    }
    catch (Exception ex)
    {
       HandleException(ex);
    }
  }
}

Unfortunately this causes a problem when the embedded user control is to consume filter values coming from a web part connection because connections are evaluated after the CreateChildControls() method is executed. In the example above, when the SomeProcessing() method is executed no filter connections will have been created and therefore no filter values are available.

Therefore a mechanism is required to access the filter values later in the web part life cycle, perform filtering and update the user control with the filtered data.

The most obvious solution is to simply move the loading of the user control until after the connection has been created, for example in the OnPreRender() event handler. However this seems a little too ‘hacky’ to me. If anyone has a better suggestion please leave a comment below.

Notes

1. Steven Van de Crean lists the order of execution for the ASP.NET web part in this blog post.

Cross-Site Collection Query, Almost

This is a tale of getting close to one of SharePoint’s holy grails but not quite…

Site collections are the most scalable SharePoint container and they offer lots of advantages over building site heirarchies with layers of sub-sites. However information in one site collection can’t be made visible to another site collection using out-of-the-box SharePoint components. This is a major inconvenience when trying to aggregate content on a portal for example.

Solution (almost)

The solution evolves from first using the SPSiteDataQuery class to run a query upon each site collection and then aggregating the results.

The example below queries all Calendar lists for events within a date range:

// for each site collection
var currentApp = SPContext.Current.Site.WebApplication;
foreach (SPSite site in currentApp.Sites)
{
  var query = new SPSiteDataQuery()
  { 
    RowLimit = 100,
    Lists = @"<Lists ServerTemplate='106' />",
    Webs = "<Webs Scope='SiteCollection' />",
    Query =
        String.Format(
        @"<Where>
            <And>
              <Geq>
                <FieldRef Name='EventDate' />
                <Value Type='DateTime'>{0}</Value>
              </Geq>
              <Leq>
                <FieldRef Name='EndDate' />
                <Value Type='DateTime'>{1}</Value>
              </Leq>
            </And>
          </Where>",
          startDate.ToString("yyyy-MM-dd"), endDate.ToString("yyyy-MM-dd")),
    ViewFields =
        "<FieldRef Name='Title' />
         <FieldRef Name='ID' />
         <FieldRef Name='EventDate' />
         <FieldRef Name='EndDate' />
         <FieldRef Name='Location' />
         <FieldRef Name='Description' />
         <FieldRef Name='fAllDayEvent' />
         <FieldRef Name='fRecurrence' />
         <FieldRef Name='FileRef' />"
  };
  var results = site.RootWeb.GetSiteData(query);

  // aggregate the results
  ...
}

This will work, however it clearly doesn’t scale well as it will query many sites and webs each time it is run.

The next step was to consider the CrossListQueryCache class which provides the ability to cache the results. In reality, apart from introducing the cache, this class doesn’t do much more than wrap the SPSiteDataQuery class and the call to SPWeb.GetSiteData().

Continuing the same example, swap out the SPSiteDataQuery with:

var query = new CrossListQueryInfo
  {
    UseCache = true,
    RowLimit = 100,
    Lists = @"<Lists ServerTemplate='106' />",
    Webs = "<Webs Scope='SiteCollection' />",
    Query =
        String.Format(
        @"<Where>
            <And>
              <Geq>
                <FieldRef Name='EventDate' />
                <Value Type='DateTime'>{0}</Value>
              </Geq>
              <Leq>
                <FieldRef Name='EndDate' />
                <Value Type='DateTime'>{1}</Value>
              </Leq>
            </And>
          </Where>",
          startDate.ToString("yyyy-MM-dd"), endDate.ToString("yyyy-MM-dd")),
    ViewFields =
        "<FieldRef Name='Title' />
         <FieldRef Name='ID' />
         <FieldRef Name='EventDate' />
         <FieldRef Name='EndDate' />
         <FieldRef Name='Location' />
         <FieldRef Name='Description' />
         <FieldRef Name='fAllDayEvent' />
         <FieldRef Name='fRecurrence' />
         <FieldRef Name='FileRef' />"
  };

var cache = new CrossListQueryCache(query);
var results = cache.GetSiteData(site, site.RootWeb.ServerRelativeUrl);

Unfortunately attempting to use the cache for each site collection query causes problems – any attempt to query a site collection beyond the current one results in a error:

There is no Web named "/sites/WebSite". 

This is due to the way that CrossListQueryCache class is written – as revealed by examining Microsoft.SharePoint.Publishing with .NET Reflector. During the execution of the GetSiteData method, a call is made to the getWeb method of the ContentByQueryWebPart:

using (SPWeb web = ContentByQueryWebPart.getWeb(webUrl))
{
    return this.GetSiteData(web);
}

So when the cached query is executed it uses the getWeb method to get the reference to the SPWeb object to run the query against. The problem is that this method uses the context of the calling code, via SPContext, to open the web site specified by the URL:

internal static SPWeb getWeb(string webUrl)
{
    SPSite site = SPContext.Current.Site;
    SPWeb web = null;
    web = site.OpenWeb(webUrl);
    bool isRootWeb = web.IsRootWeb;
    return web;
}

Thus, even though the caller has passed through the correct SPSite to use when opening the SPWeb against which the query is to be run, the CrossListQueryCache ignores this and instead uses the context of the caller.

Close but no cigar…

The net result is that a cross-site collection query is possible using SPSiteDataQuery but clearly this could have a serious performance impact with querying multiple site collections and sub-sites. It would be nice to be able to have the query results cached however this doesn’t seem possible using CrossSiteQueryCache.

It’s somewhat infuriating that a relatively simple change to the CrossListQueryCache class would enable cached cross-site collection queries.