• QR Server debugging queries >> Use this to inspect queries coming from SharePoint to FAST.
• FFD Dumper for inspecting crawled properties >> Use this to inspect crawled properties
• MossMan FAST Query tool >> A handy little tool which allows you to build queries yourself, and interrogate FAST. Useful when writing custom FAST control.
• FASTSearch2010.chm >> A downloadable MSDN reference which holds a ton of PowerShell commands that relate to configuring FAST
• Information Worker Demo VM >> Downloadable VM from Microsoft that is setup and ready to use. Comes with FAST 4 SharePoint preconfigured
• PowerGui >> IDE for working with PowerShell. Invaluable if you’re working with PowerShell for a longer period of time.
• FAST Query Logger >> A new tool which makes working with the QR Server significantly easier.

Previously I blogged about the QR Server, my first port of call whenever I need to debug FAST. At that stage I ask the question “What does FAST know about this document?” and the QR Server is the best place to start looking.

Sometimes, the information in the QR Server isn’t enough to figure out what’s going wrong. If that’s the case, my next question is usually “What is FAST told about this document?”

As part of this process it is critical to understand the difference between Crawled & Managed Properties.

A Crawled Property is something that is fed into the FAST document processing engine. It may or may not decide to index and keep what it finds. If the information it does is not ignored it will end up in the Full Text index, a Managed Property, or both. Crawled Properties à What FAST is told, Managed Properties à What FAST knows and has decided to keep.

While the QR Server is for managed properties, you use a tool called FFDDumper to inspect crawled properties.

The debugging process for using the FFDDumper goes like this:

1. Enable the FFDDumper & reset your document processors
2. Mark an individual document for being re-crawled
3. Start an incremental crawl
4. Inspect the generated FFD files
5. Turn off the FFDDumper and reset your document processors

Enabling the FFDDump

There is a file in your FAST installation folder called optionalprocessing.xml (found under %FASTSEARCH%\etc\config_data\DocumentProcessor\). This file is for configuring optional processing pipelines (duh!).

Find the element that looks like the one below and set it to yes.

<processor name=”FFDDumper” active=”yes” />

THIS WILL SLOW DOWN YOUR SERVER AND GOBBLE DISK SPACE! Use this for temporary debugging only, and really, only use it for incremental crawls or else the sheer volume of data will make it very difficult to find what you want.

Reset your processing pipelines from the FAST PowerShell console with a

> psctrl reset

Marking a document for re-crawl

In SharePoint navigate to your FAST Content Service Application and mark a single document for a re-crawl. Alternatively, make a small change to a document (make sure the document is published).

Kick off an incremental crawl by going to the context menu of your Content Source.

Inspecting the generated FFD Files

If you navigate to %FASTSEARCH%\data\ffd you’ll find one or more folders. Go to the newest folder and look inside. There should be a few .ffd files, one of which will contain the ssic of your document (you can get this from the QR server).

Each line from the FFDDumper will look something like the following:

The format of each line includes:

• Length of property identifier & name
• Property identifier (may be a GUID)
• Property name
• Variant Type
• Length of the property value (often preceded by an ‘s’)
• The property value

Only lines with GUIDs are available to be mapped into Managed Properties. Lines without GUIDs are internal to FAST and are not accessible. If you look at the screenshot below, the unfortunate implication is that you can’t write your own pipeline extension to run against the raw crawled data.

Reset the FFDDump

Once you’re done, reset the FFD Dump to its regular configuration

<processor name=”FFDDumper” active=”no” />

Finally, run a psctrl reset to load the updated settings of optionalprocessing.xml

I’ve recently created a new SharePoint site collection but was missing the FAST features out of the Site Collection Settings. I had a site collection within the same Web Application where the features were present and so was very confused. I already had added myself to the FASTSearchAdministrators and the FASTSearchKeywordAdministrators groups on my FAST server which can also keep the FAST options hidden, and besides, I already had them visible elsewhere.

There were no obvious features to activate within the Site Collection features, and I had standard, enterprise & publishing features enabled. Noting the url of one of the pages in the working site collection I tried loading it up in the broken one. For example:

• site/workingSC/_layouts/contextualkeywordmanagement.aspx
• site/brokenSC/_layouts/contextualkeywordmanagement.aspx

At this point I got the standard SharePoint error popup with the message FAST Search site collection features are not activated. Pretty obvious what’s going on, the feature isn’t activated and there’ s no obvious way to do so via the UI.

Finding the Feature GUID

Digging through the API using Reflector reveals this method which any reasonable developer can infer will give you the error message above.

private static void ValidatePremiumSiteCollectionFeature()
{
   if (SPContext.Current.Site.Features[new Guid(SearchAdminConstants.FAST_SITE_ADMIN_FEATURE_ID)] == null)
   {
     ReportError(StringResourceManager.GetString(LocStringId.FSAdmin_Fast_Site_Admin_Feature_Not_Activated));
   }
}

A little more use of Reflector gets you the GUID for the FAST Site Admin Feature (5EAC763D-FBF5-4d6f-A76B-EDED7DD7B0A5).

Armed with this guid you can get the Feature definition. You don’t need it, but it’s interesting regardless (I’ve never seen this available via the UI).

Get-SPFeature | ? { $_.id -eq “5EAC763D-FBF5-4d6f-A76B-EDED7DD7B0A5″ }

DisplayName                    Id                                       Scope                         
-----------                    --                                       -----                         
SearchExtensions               5eac763d-fbf5-4d6f-a76b-eded7dd7b0a5     Site

From here, if you want to add the feature to a site collection simply run the following PowerShell

$siteWithNoFastFeatures = get-SPSite http://mysite/noFAST
$siteWithNoFastFeatures.Features.Add(“5EAC763D-FBF5-4d6f-A76B-EDED7DD7B0A5″)

Ever got this helpful message when trying to configure the user profile to use a termset?

There was a problem retrieving data for this field. Updating values in this field is disabled temporarily. You can still update values in other fields.

Love it!

There are lots of potential causes for this. Earlier today I found that my problem was caused by an issue outlined on Donal Colon’s blog.

Here’s my setup:

• Managed metadata started, configured and running as the only MM Service in my farm
• MM service was associated with all web apps
• User profile service was configured correctly (I could do profile syncing) and could even associate fields with a Managed Metadata term.

However, with all these things, I wasn’t feeling any User Profile / Managed Metadata love. This was potentially a big problem as I have a client delivery counting on User Contexts in Search (depending upon said UP/MM love).

Enter Donal Colon.

His post suggests that if you don’t tick the default storage location for keywords when you have TWO MM services then you can get problems like the one I encountered. He also highlighted that having two MM services conflicting can cause a problem.

Well, I only had one Managed Metadata service, but if you don’t have this  box ticked, then you aren’t getting any terms in your User Profile Service either.

Thanks Donal!

Most of the examples of using dialogs in SharePoint refer to calling other pages, effectively creating a popup iframe. This approach is both useful and reasonably well documented (Charlie Holland’s blog has the best examples I’ve seen to date).

<script>

	function ShowDialog()
	{
		var options = {
			url: 'http://www.google.com',
			autoSize:true,
			allowMaximize:true,
			title: 'Test dialog',
			showClose: true,
		};
		var dialog = SP.UI.ModalDialog.showModalDialog(options);
	}

</script>

<a href="javascript:ShowDialog()">Boo</a>

What isn’t well documented is using SharePoint modal dialogs to render dynamically generated html. When you call SP.UI.ModalDialog.ShowModalDialog you need to pass in a SP.UI.DialogOptions object. Charlie kindly posted the list onto MSDN, but with regards to passing in html it’s incorrect. It seems to indicate that raw html can be passed in.

<script>

	function ShowDialog()
	{
		var htmlString = 'hello world';

		var options = {
			html: htmlString,
			autoSize:true,
			allowMaximize:true,
			title: 'Test dialog',
			showClose: true,
		};

		var dialog = SP.UI.ModalDialog.showModalDialog(options);
	}

</script>

<a href="javascript:ShowDialog()">Boo</a>

However if you try this you’ll just get an error like this:

Message: Object doesn't support this property or method
Line: 2
Char: 18225
Code: 0
URI: http:///_layouts/sp.ui.dialog.js?rev=IuXtJ2CrScK6oX4zOTTy%2BA%3D%3D

This is because the string that gets passed in is evaluated for nodeType (if you want to check for yourself, see around line 764 in SP.UI.Dialog.debug.js, there is a function that the html string is passed into with a definition that looks like $13_0: function($p0).

What this means is that you have to pass in a DOM element.

 

<script>

	function ShowDialog()
	{
		var htmlElement = document.createElement('p');

		var helloWorldNode = document.createTextNode('Hello world!');
		htmlElement.appendChild(helloWorldNode);

		var options = {
			html: htmlElement,
			autoSize:true,
			allowMaximize:true,
			title: 'Test dialog',
			showClose: true,
		};

		var dialog = SP.UI.ModalDialog.showModalDialog(options);
	}

</script>

<a href="javascript:ShowDialog()">Boo</a>

Do that, and you’ll get your dynamic-html dialog!

In SharePoint 2010 default masterpage (v4.master) has delivered Breadcrumbs in a new, and I think confusing, way.

SharePoint 2010 Breadcrumb

From my perspective, this approach is difficult to use because it is hidden from the user. Once you know about it the breadcrumb is easier to find, but its nowhere near as usable as a traditional breadcrumb.

Smashing Magazine offers a range of alternatives you can consider in implementing your own breadcrumb which are worth considering if you want to create a fully-customised master page.

However, want if you want a breadcrumb of the same style as SP2007?

What if you want to revert the 2010 breadcrumb into the style of the 2007 breadcrumb? Well it turns out that the v3 masterpage(the 2007-style masterpage that runs on SharePoint 2010 to allow companies to avoid a visual upgrade) runs the old-school masterpage.

If you dive into the v3 masterpage (default.master) you can see the following snippet to in place of the breadcrumbs.

<asp:SiteMapPath SiteMapProvider=”SPContentMapProvider” id=”ContentMap”  SkipLinkText=”” RenderCurrentNodeAsLink=”true”  NodeStyle-CssClass=”ms-sitemapdirectional” runat=”server”/>

As it turns out, if you paste that snippet into the v4 masterpage it will work perfectly.

Update: Turns out it won’t work perfectly, but its pretty good. There are a number of circumstances (i.e. site settings page) where it falls short, but for most users its better than nothing. To have a perfect breadcrumb, unfortunately you’ll need to open up visual studio.