European Sharepoint Hosting Blog

SharePoint 2010 Foundation problems encountered when doing a quick spin-up of a test instance.

• Search service wouldn’t start
• Performing a search returned the error “Your search cannot be completed because this site is not assigned to an indexer”

To allow the search service to start the credentials assigned to the service were changed from Local Service to Local System.

To fix the “not assigned to indexer” error use Central Administration.

Navigate to “Manage content databases.”

Make sure you have the correct web application selected and click on the content database.

Scroll down and find the Search Server section and select the search server from the drop-down.

I recently had a requirement from my client to have the following functionality in SharePoint 2010:
a) The Search Core Results web part displaying sorted in Alpha order
b) The Search Core results part should just show sites (not documents) that the current user has access to.

Requirement b) was simple – you can set the keywords on the Core Search Web Part to just display sites (using the “contentclass:STS_Site” keyword in the “Fixed Keyword Query” property – and the part would default to showing a list of sites the current user has access to (via the normal SharePoint 2010 security trimming functionality).

However, the first requirement was a little bit trickier. The default Core Search Web part only provides for 2 search sort options – by date and by relevance (which is the default).

To fix this, the XSLT which defines the search results needs to be changed. This XSLT is specific to the instance of the web part – modifying it won’t affect the normal search functionality of your site.

To modify the XSLT for the search results web part, you need to first uncheck the “Use Location Visualization” checkbox. The XSLT that opens is around 700 lines long and has a lot of different XSL templates defined within it. To sort the search results by alpha order, you need to use an xsl-sort call within the main apply-templates call.

Some sites such as http://kwizcom.blogspot.com/2008/11/how-to-change-moss-search-retults-sort.html have a simple suggestion – but this would not work as the “select node is missing” on the “apply-templates directive. You need to provide a valid parent to allow for sorting. The fix was to change the empty apply-templates node in the default search XSL:

<xsl:apply-templates />

to the following:

<xsl:apply-templates select="All_Results/Result">
<!-- The xsl-sort needs operate upon a single field - it doesn't work if the sort has to evaluate child nodes-->
<xsl:sort select="title" />
</xsl:apply-templates>

Note that I didn’t require the other elements in the Search XML (the TotalResults and the NumberOfResults nodes), so this solution may not work in your scenario. This list can then act as a facility for cross-site collection navigation (which is not available out of the box in SharePoint 2010)

Another limitation of this approach is that it will only work on a non-paged resultset – which is a pretty major limitation! In our scenario (for Phase 1 of our provisioning solution), it was acceptable for our customer to increase the page size to avoid any pagination from occurring. Your mileage may vary.

Other solution options are:

1. Scripting – Using jQuery to do a search call and sorting and paging the results yourself
2. Server side – with your own custom web part that also does the paging for you – using the SPGridView or inheriting from

Microsoft.Office.Server.Search.WebControls.CoreResultsWebPart

Phase 2 of our project will use a combination of Server Side customization (as described at http://msdn.microsoft.com/en-us/gg620579) by extending the CoreResultsWebPart
and the jQuery approach above for easy inline searching of accessible site collections.

This post will show you how to provision Site Columns that uses Managed Metadata in SharePoint 2010. Managed Metadata is one of the new and exciting features of SharePoint Server 2010. It allows you to centrally manage metadata terms and keywords. Creating Managed Metadata columns using the SharePoint web interface is a simple task but the problem is that it does not allow you to move your Site Columns from one farm to another that easily. The reason is that these Site Columns definitions contains references to the unique IDs of the terms in the current Managed Metadata Service Application (MMS).

Exporting Site Columns

If you export a Managed Metadata Column and a Content Type using it to Visual Studio (SharePoint Designer > Export > Visual Studio Import, you know the drill) then you end up with definitions like below.

The Site Column is based on the TaxonomyFieldType and contains a Customization element which contains an array of properties (I’ve omitted most of them here). These properties contains IDs of the Managed Metadata group, term store and service application. Since these are unique for each MMS this definition cannot be provisioned to another farm (for instance from dev to stage, stage to prod etc).

Field
    Type="TaxonomyFieldType"
    DisplayName="Custom (web)"
    List="Lists/TaxonomyHiddenList"
    WebId="~sitecollection"
    ShowField="Term1033"
    Required="FALSE"
    EnforceUniqueValues="FALSE"
    Group="_Custom"
    ID="{fce6a8e2-23e8-49c2-9bad-a534555296bb}"
    SourceID="{5e68c9eb-5efe-4bcc-b8db-93d38d797fbe}"
    StaticName="__Custom"
    Name="__Custom"
    Overwrite="TRUE">
    <Default />
    <Customization>
        <ArrayOfProperty>
            <Property>
                <Name>SspId</Name>
                <Value
                    xmlns:q1="http://www.w3.org/2001/XMLSchema"
                    p4:type="q1:string"
                    xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">b98dd270-8577-4db8-99e1-b9e894624fdb
                </Value>
            </Property>
            <Property>
                <Name>GroupId</Name>
            </Property>
            <Property>
                <Name>TermSetId</Name>
                <Value
                    xmlns:q2="http://www.w3.org/2001/XMLSchema"
                    p4:type="q2:string"
                    xmlns:p4="http://www.w3.org/2001/XMLSchema
instance">b7ae10cd-6c7c-4386-a1f2-7abec8e759e1
                </Value>
            </Property>
            <Property>
                <Name>AnchorId</Name>
                <Value
                    xmlns:q3="http://www.w3.org/2001/XMLSchema"
                    p4:type="q3:string"
                    xmlns:p4="http://www.w3.org/2001/XMLSchema-instance">00000000-0000-0000-0000-000000000000
                </Value>
            </Property>
            ...
        </ArrayOfProperty>
    </Customization>
</Field>

And if you examine the XML further you will also notice that a second field is defined for this Site Column. This field is of the type Note and is hidden.

<Field Type="Note" DisplayName="__Custom_0" StaticName="__CustomTaxHTField0" Name="__CustomTaxHTField0"
    ID="{a6eae615-9835-4b75-97bf-d4e7a938b892}" ShowInViewForms="FALSE" Required="FALSE"     Hidden="TRUE" CanToggleHidden="TRUE"
    SourceID="{5e68c9eb-5efe-4bcc-b8db-93d38d797fbe}" Overwrite="TRUE" />

A lot of XML but quite useless for reuse…

So how do I do then?

To provision the Site Columns and Content Types without these hardcoded Guids and IDs you basically have two options:

1. Create an event receiver (or similar) that creates the Site Columns and Content Types programmatically
2. A combination of declarative and the programmatic approach above

I prefer the second approach and I will show you how to do it (the first one can quite easily be done based on the code that will follow).

First you need to create a new SharePoint 2010 project in Visual Studio 2010, create a new Empty SharePoint project. Then add a new Content Type SharePoint Project Item (SPI) to the project and inherit it from the Item content type. Then add a new XML file to the SPI and name it Fields.xml. This elements manifest will contain the Site Column definition, but in order to make it into a manifest file you need to select the file and press F4 to edit the properties of the file. Change the Deplyment Type from NoDeployment to ElementManifest. Your solution should look like the image to the right. Also make sure to set the feature to be scoped to Site (Site Collection) level – we’re talking about deploying Site Columns and Content Types here.

Then it is time to write the declarative part (i.e. the XML). You need to add a new Field element of the type TaxonomyFieldType (or TaxonomyFieldTypeMulti). Configure it as follows or as it suits your needs. Notice that I have set the ShowField attribute to Term1033, this is needed by the MMS to select the correct term value.

xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
  <Field ID="{749DA0D1-4649-4C25-871B-05F0C07221FC}"
    Type="TaxonomyFieldType"
    DisplayName="Home Country"
    ShowField="Term1033"
    Required="TRUE"
    EnforceUniqueValues="FALSE"
    Group="_Custom"
    StaticName="HomeCountry"
    Name="HomeCountry"
     />
</Elements>

To add this field to the content type there is no rocket science, just do as you normally do:

<FieldRef ID="{749DA0D1-4649-4C25-871B-05F0C07221FC}" Name="HomeCountry"/>

That’s all that you can do declarative. If this would be deployed a field would be created of the type Managed Metadata but you have to manually connect it to the MMS.

Now we have to dig into some programming to connect the field to the MMS. This is done in an Event Receiver for the feature. Right-click the feature and select Add Event Receiver. Uncomment the FeatureActivated method and implement it as follows:

public override void FeatureActivated(SPFeatureReceiverProperties properties) {
    SPSite site = properties.Feature.Parent as SPSite;
    Guid fieldId = new Guid("{749DA0D1-4649-4C25-871B-05F0C07221FC}");
    if (site.RootWeb.Fields.Contains(fieldId)) {
        TaxonomySession session = new TaxonomySession(site);

        if (session.TermStores.Count != 0) {
            var termStore = session.TermStores["Managed Metadata Service"];
            var group = termStore.Groups.GetByName("Wictors Group");
            var termSet = group.TermSets["Countries"];

            TaxonomyField field = site.RootWeb.Fields[fieldId] as TaxonomyField;

            // Connect to MMS
            field.SspId = termSet.TermStore.Id;
            field.TermSetId = termSet.Id;
            field.TargetTemplate = string.Empty;
            field.AnchorId = Guid.Empty;
            field.Update();
        }
    }
}

This method will first check if the field has been deployed. The field is retrieved using the Guid of the Field, defined in the XML. Once that is confirmed that the field exists a TaxonomySession object is acquired using the SPSite object. The TaxonomySession object is declared in the Microsoft.SharePoint.Taxonomy assembly – so you have to add a reference to that assembly first. To connect the field to the MMS you need to retrieve the Term Store, Group and Term Set. All this is done using the names of them as defined in the MMS. The image to the right shows how the MMS looks like that this code is connecting the field to. It is very likely that you have the same structure of the MMS in your different environments – if not you have to come up with a more configurable way

Note the GetByName method used above is a custom extension that looks like this:

public static Group GetByName(this GroupCollection groupCollection, string name) {
    if (String.IsNullOrEmpty(name)) {
        throw new ArgumentException("Not a valid group name", "name");
    }
    foreach (var group in groupCollection) {
        if (group.Name == name) {
            return group;
        }
    }
    throw new ArgumentOutOfRangeException("name", name, "Could not find the group");
}

Once you have a hold on the taxonomy objects then it is time to convert the Field to a TaxonomyField object. This object is then configured with a set of properties. Specifically the ID of the Term Store and Term Set is set. Finally the field is updated to reflect the changes.

The Result!

That’s it. All you now have to do is deploy it and test it out.

The Problem

Web templates allows you to specify which features to activate by customising the onet.xml file. Usually developers will pick the nearest one or more site definition’s onet.xml they want to use – copy the WebFeatures and SiteFeatures (which is totally acceptable). For example, for a publishing site I may use the CMSPUBLISHING onet.xml which you can find at:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\SiteTemplates\SPS\XML\onet.xml

But what about if your web application is subscribed to a content type hub and you are expecting those published content types to come down to your new site created using the web template?

If you check your site (provisioned using a web template) settings, you will not find the ‘Content Type Publishing’ setting under Site Collection Administration. This is the place where you will see the content types consumed by the site (from the content type hub).

Below is a screenshot of this setting:

The highlighted option will not be available if you used a web template.

What is missing?

SharePoint feature staples a hidden feature to enable this functionality on sites. As you may guessed already, this feature stapling works when you create a site from the default site templates available, but not when you create a site from a web template. As a matter of fact, web templates do not support feature stapling!

All we need to do now is include this hidden site feature in our web template’s onet.xml!

The Solution

This hidden feature is TaxonomyFeatureStapler which can be found at:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\TaxonomyFeatureStapler

Hang on, if you look at the feature elements file (TaxonomySitesToStaple.xml), it actually associates another feature. This feature is TaxonomyFieldAdded which can be found at:

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES\TaxonomyFieldAdded

So, this is the feature we are interested in. Now we can add this feature in the SiteFeatures element (as this is a site feature & farm scoped web template)

[ TaxonomyFieldAdded feature GUID: 73EF14B1-13A9-416b-A9B5-ECECA2B0604C ]

If the web template is site scoped, you may need to activate this feature from a web scoped feature as SiteFeatures element don’t get parsed o a site scoped web template.

Now your site provisioned by a web template will be able to consume the content types published from its content type hub.

n this article I demonstrating how to make a consistent UI in SharePoint 2010 in various mobile browsers.

My mates often ask me why we need to use mobile devices with SharePoint. Through this article I am just providing a sample where I am showing why we are slowly moving to mobile devices from PCs. While giving a demo on “SharePoint on mobile” to the client I found the following things:

• Client wants everything in their hand, which means on mobiles (because of a busy schedule there is no time to open a laptop/system) .
• Client doesn’t want to compromise with UI.
• Application should be simple and easy to use.
• Application should be scalable and easy to extend in the future.

Out of all four, the following three are already provided by SharePoint. SharePoint is lacking somewhat in the first point.  But as I said we developers can do anything so here we can provide a solution for “We will bind the SharePoint without breaking SharePoint Rules”.

I am using the Safari browser for the demonstration because through the Safari browser we can check the application in various browsers. To do this we need to follow the steps below:
1. Open the Safari browser. Click on Preferences:

2. Click on the Advanced tab; check “Show Develop menu in menu bar” then close.

3. Go to Developer menu bar,

Now open the SharePoint site in the Safari browser after selecting User agent as Mobile browsers e.g. “Mobile Safari 4.1-iPhone”. The SharePoint site will look like below:

The actual site will look like the following if you open the same site in IE browser:

As I said, the client always wants the same UI so our next target is to make the same UI as it is in a normal PC browser.

Follow the steps below to do that :
1. Go to “Run”, enter “C:\inetpub\wwwroot\wss\VirtualDirectories”; select your site port number e.g. Port:2255, then my comple path should be like “C:\inetpub\wwwroot\wss\VirtualDirectories\2255\App_Browsers”. Open the “Compact.Browser” file in Notepad.

2. The browser.compact file helps you in finding a browser before loading the sharepoint site in the browser. Open the file in Notepad and Find “<userAgent match=”iPhone” />”.

It will look like the following:

<!-- iPhone Safari Browser -->
    <!-- sample UA "Mozilla/5.0 (iPhone; U; CPU iPhone OS 2_0 like Mac OS X; ja-jp) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1 Mobile/5A345  Safari/525.20" -->
    <browser parentID="AppleSafari">
        <identification>
            <userAgent match="iPhone" />
            <userAgent match="Mobile" />�
        </identification>
        <capabilities>
            <capability value="true" />
            <capability value="true" />
            <capability value="1500" />
            <capability value="true" />
            <capability value="true" />
            <capability  value="true" />
        </capabilities>
    </browser>

3. Change “<capability    value=”true” />” to “<capability   value=”false” />”. 

4. Save, reset and refresh the Safari browser. The SharePoint site will look like the following:

5. That’s all. We are done with our requirement.

Hope you like this article and the beginning where you can show your SharePoint on a mobile browser as well.