Tech Ed EMEA 2008 IT – Day 1 reflections

Today has been interesting. Rik and I started the day doing the sightseeing we had time for. The Gaudi cathedral had been particularly recommended, so with limited time at our disposal, that’s what we decided to see. We arrived at the gate just as it opened, and were in within a few minutes. The cathedral is very, very impressive, though there is an awful lot of construction work going on at the moment. It is an amazing structure, with a very impressive sense of light and space inside:


Following the trip to the cathedral, we headed back towards the convention centre to get lunch and to try to get into the main auditorium for the keynote early enough to get a good seat. I was glad that we made the effort as we managed to get seats near the front tucked off to one side. Here’s our view of the stage, and the auditorium once it had nearly filled:

IMG_2901 IMG_2908

The keynote by Brad Anderson was interesting, with a number of announcements and some very useful demos. I was particularly impressed with the drive towards virtualisation, and the available and forthcoming tools to help you manage the resulting data centre. There was a live migration demo using Server 2008 R2 which demonstrated a live move of a virtual machine from one host to another with no interruption of service. In addition, Gemini was demonstrated; a self service BI offering allowing anyone within the organisation to view and manipulate data from sources such as SQL Server. The most impressive part of the demonstration as far as I was concerned was the ease (and speed!) with which the data could be published to SharePoint for consumption within the business:


Also mentioned were items such as Cross Platform Extensions for SCOM allowing monitoring and management of non-Microsoft systems and server Application Virtualisation allowing the separation of the server OS and the server application allowing each to be managed (and patched) separately – all very interesting! A number of announcements were also made, for example System Center Operations Manager 2007 R2 Beta will be available for download at the end of November.

From there it was off to the first session; Planning and Operations Tools for SharePoint which provided some useful pointers and allowed the possibility of some feedback to the managers of the solution accelerators programme.

After the sessions this afternoon, Rik and I spent some time wandering around the Ask The Expert area generally asking awkward questions of most of the people we could find.

All in all it’s been a very useful first day.

SharePoint Federated Search

One of the new features introduced with the recent SharePoint Infrastructure Update are the Enterprise Search Features that were shipped with Search Server 2008 and Search Server 2008 Express, that were not included in the original release of SharePoint 2007.  This includes some Search core platform performance updates, a unified administration dashboard and Federated Search.  The latter of these updates is the one I’d like to discuss briefly here.

SharePoint always had the facility to allow you to index external sources of data (e.g. an external web site), however the new Federated Search capability of SharePoint 2007 also allows you to include sites that use the OpenSearch 1.0/1.1 standard.  The Federated Results web part allows you to display the results in a separate section of your search results page.

To make sue of the Federated Search capabilities, you need to add Federated Locations, then add the Federated Search web part to the search results page and modify the settings of the web part.  The web part is typically added to the SharePoint search results page to provide extra sections at the right-hand-side of the page showing results from the Federated Locations.

I won’t go through the steps to set up a Federated Location here, as there is a Microsoft video which describes the process very well.  Note however that you can modify the look and feel of the returned results from within the Add Federated Location page by modifying the XML shown on the page and that you can restrict the use of the Federated Location you are setting up to specific sites within your farm.  You can also pass credentials to the Federated Location if you need to do so.

Microsoft have also provided an online gallery of pre-configured Federated Search Connectors (Locations) at  There is a link to this gallery at the top of the Manage Federated Locations page within the Search Administration area of the SSP on your farm. By default, Microsoft provide the following Federated Locations installed with the Infrastructure update:

  • Internet Search Results (Live Search)
  • Internet Search Suggestions (Live Search)
  • Local Search (unscoped local search index)

The following Federated Locations are available (as at 1st August 2008) from the online gallery:

  • News
  • Yahoo News
  • Wired
  • The Register
  • MSDN
  • Technet
  • Wikipedia
  • Encyclopedia Britannica
  • Yahoo
  • Flickr
  • Yahoo Images
  • YouTube
  • PodScope
  • Technorati
  • Google Blog Search

These are available for download and import directly from the online gallery; just follow the instructions at the bottom of the page!

Once you have the Federated Locations you wish to use set up, the Federated Results web part needs to be added to your search results page.  Navigate to your search results page and add the Federated Results web part the a web part zone on the page as you would any other web part. To change the Federated Locations the web part uses, modify the shared web part and drop down the listbox at the top of the settings; this contains the items in your Federated Locations list.

Using these settings, you can

also modify the number of results that are returned, the number of characters displayed in the summary and URL, whether to return results asynchronously, whether to show the loading image (a miniature version if the standard SharePoint ‘processing’ animation) etc.  As usual you can also target the web part via the Audience controls.

We use the TechNet and MSDN Locations provided on the online gallery, and very useful we find them too!

Deployment of Digital Signature ActiveX control from within SharePoint fails

I’ve recently been investigating a rather curious problem we’ve been experiencing with deployment of the Digital Signature ActiveX Control from SharePoint 2007 to browsers.

First a little background: A number of workflows we’ve developed recently make use of the capability of InfoPath forms to incorporate sections that can be digitally signed. In general these forms are developed in InfoPath 2007, and are served from a MOSS 2007 farm into a browser window for the user. The forms are developed on a PC which has UK-English language and locale settings and are served from installations of MOSS 2007 which are typically configured for UK-English as well.

The first time a user sees a form with the capability to be digitally signed displayed in their browser window, assuming the Digital Signature Control is not already installed on their computer, they are asked whether they would like to install it:


Clicking yes, opens another window which presents them with a license agreement to read through and agree to. Checking the ‘I agree…’ checkbox and clicking the ‘Next’ button:


… results in nothing further happening. All rather curious.

After the usual investigation for such things (check the event log; nothing, check the MOSS logs; again nothing, turn on trace logging; again nothing), followed by discussion with the SharePoint support team and some Fiddler traces, we worked out that the Digital Signature Control installer ( could not be found on the SharePoint farm at the expected location of _layouts/2057/ (2057 being the LCID for EN-UK). Indeed, when we looked for C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\TEMPLATE\LAYOUTS\2057 the folder didn’t exist!

We tried installing the MOSS 2007 language pack, which made no difference.

As a workaround, I created the 2057 folder under _layouts and copied the file from the 1033 (LCID for EN-US) folder into it. This appeared to cure the problem and the Control installed succesfully.

At this point, the issue was escalated to the US InfoPath team. This morning the InfoPath team came back with their confirmation that this is indeed a bug with InfoPath and that it is not limited to UK-English, but at this time they do not have a complete list of the languages that it does affect.

They also confirmed that the workaround listed above is a reasonable solution at the moment.

When I hear that a Microsoft solution to this issue has been provided, I’ll let you know!

Creating Custom Content Types for SharePoint using Visual Studio (or Notepad) and a few other tools…

There are a number of ways of generating Custom Content Types for SharePoint, some more difficult than others.  One of the easiest ways is to create your own using the SharePoint GUI interface via a web browser, however while a nice ‘point and click’ approach, there is no easy way to extract the resultant custom columns and content types for use on another farm.

At the other end of the spectrum, you can hand code the required XML from scratch and generate the features for installation.  This has the advantage that you can re-use the features you generate, but the fairly obvious disadvantage of having to hand-craft XML for use in the features.

There are also a couple of ‘middle of the road’ approaches, one of which I’m going to comment upon, the other of which is what I am going to briefly discuss here.

The first ‘middle of the road’ approach uses the Codeplex SharePoint 2007 Content Type Viewer, details of the use of which can be found at – I do however have a problem with the approach outlined and I’ll explain why:

The Content Types Viewer is a very useful utility that allows you to extract information about content types from a running instance of SharePoint, even those created via the GUI.  The utility provides you with the Fields (columns), the FieldRefs (for specifying in the content type) and the schema for the content type.

Using it in the way described in the above link, the user would copy the Fields data from the Content Types Viewer and generate a feature to install these fields, then create a content type feature containing the information from the FieldsRefs.

The problem I have with this approach is that none of the information from the schema is used within the content type.  I’ll give and example as to why this is bad:

  • Create a custom content type; it doesn’t matter what columns this contains as long as it contains at least one column that is a choice.  Fill in a number of choices for this column.
  • Create a list associated with your custom content type.
  • Extract the fields and content type using the Content Types Viewer as instructed.
  • Copy the fields and content type features to another farm, install and activate them.
  • Recreate your list using the GUI on your new farm and associate it with your content type.
  • Try to create a new entry in the list.
  • You should see that the choice column(s) you contain no data!

The reason this happens is that the choice information you supplied for your custom content type is contained within the schema for that content type.

To rectify the situation, do the following:

  • Save the list on your original farm as a template (.stp).
  • Copy this template to your new farm and upload it into the list template gallery.
  • Create a new instance of your list from the template.
  • Try to create a new entry in the list and your content type magically now contains the choice data you input on the original farm.

This happens because the schema information is contained within the list template file created on the original farm.  You can test this hypothesis by extracting the manifest.xml from the .stp file you created and looking at it – you should see your choices listed within <CHOICE></CHOICE> XML fields.

While this works quite happily if you only ever want to transplant your custom content type/list combination to another farm, however if anyone creates a list from scratch and associates it with the custom content type on the new farm the list will not be able to function properly.

A better approach is to use the Content Types Viewer, but also include the required information from the schema.  While this involves a little more than ‘cut and paste’ from the Content Types Viewer, it does at least provide a complete content type for transplant to another farm.

Most of the information from the schema should be transplanted into the Fields feature, with the content type feature remaining the same.  A number of fields from the schema should not be transplanted as these cause errors when attempting to install/activate the feature.  These include:

  • Version
  • Customization
  • Aggregation

A few notes:

  • Generally you should use SourceID= in your fields feature.
  • There may be problems associated with referencing other fields for (for example) a calculation field as these typically utilise a GUID to identify the column you wish to extract data from.  If you are referencing columns within the same content type, you can simply use the column name and dispense with the GUID.  If you wish to access information from another list you have a problem as the GUID for the list will be generated dynamically when the list is created.  If you wish to do this you need to create the lists you wish to reference first and extract the list IDs for use in your feature.  An alternative (in particular if you wish to wrap your features up into a SharePoint Solution) is to write a feature receiver to dynamically add the appropriate columns with the correct GUIDs to your feature at activation.

I aim to discuss creating field and content type feature creating in more detail in a future post.