This is as much for me as for anybody else, but I hope visitors to this page find it useful.

Obviously, you can always try SharePoint’s standard verbose logging, but I’ve never found that to be terribly useful for search.

Debugging the Crawler

You might consider trying to use Fiddler2, the same way you would with SharePoint 2010. SharePoint Blues has a good overview on how to turn this on. The steps for 2013 will obviously be different.

Debugging Pipeline Stages

No entries yet…

Debugging Custom Pipeline Stages

No entries yet, but since they’re web services you can write on your own, debugging them shouldn’t be intractable.

Debugging the Index

There’s an interesting post on the MSDN forums that is worth a read. It indicates there is no more FIXML, and that the index is stored in a binary format. Microsoft is apparently creating a tool to inspect the index but who knows how long that might take.

Debugging Queries

SP2013 Search Tool

There’s a query tool written by somebody at Microsoft which looks quite handy and is compatible with SharePoint Online as well. Ideal when you can’t login to the server. You can get it from CodePlex. This looks very similar to the MossMan query tool in SharePoint 2013.

Use it when:

You can’t directly login to the server.

You want to see what the index knows about a specific document.

What it won’t tell you:

What specifically the query server sent back to a specific query submitted via the browser.

Developer Dashboard

There’s a suggestion in this deck by Agnes Molnar (SharePoint MVP) that you can use the developer dashboard, but there’s no more detail than that. Looks promising though, at least in a pre-production environment.

Debugging Search with SharePoint Online

•  Look at the SP2013 Search Tool mentioned under Debugging Queries

There’s a defect whereby your search results in SharePoint will not have document icons if you’re using FAST for SharePoint.

This will happen to you, whenever you’re using a Document Library created from a custom Document Library template (i.e. Type != 101).

Why this happens

The problem is that the contentclass of documents from custom libraries indexed by FAST in is not compatible with the way the Core Results Web Part determines which icon to display. Under normal circumstances, FAST allocates documents a contentclass of STS_ListItem_DocumentLibrary and when search results are returned to the Core Results Web Part as an xml document, our document is accompanied by an imageurl element which points to an icon within the layouts folder (i.e.  /_layouts/images/icdocx.png).

When using a custom document library, let’s say with a type of 15000, the contentclass will be STS_ListItem_15000 and the Core Results Web Part will be returned an imageurl element of /_layouts/images/STS_ListItem16.gif.

This has been accepted as a bug by the product team. Unfortunately, So far as I know, it is not likely to be resolved in either upcoming hotfixes or Service Pack 1 (I have no visibility of any future CUs or Service Packs). The Microsoft-recommended workaround is to create a Custom Pipeline Extension whereby library items that have a contentclass of STS_ListIem_<a number> are converted to STS_ListItem_DocumentLibrary.

I’m checking into whether I can post some PSS-provided sample code for the pipeline extension, but until then, visit this page on MSDN to get instructions on how to create one.

Update 21 Sept 2012:  Baastian Kortenbout has provided code which addresses the issue. This can be downloaded here: FS4SP2010PipeLineExtensionIconFixer. I make no guarantees about the code, you assume all risks and responsibility should you chose to use it in any way, blah blah blah.

• 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!

With FAST for SharePoint being so new, it’s difficult to know how to work with the product when it comes to debugging. There are many different questions:

• What does it know about document x?
• What is FAST returning to my SharePoint server?
• What is the rank of a certain document?
• What is SharePoint asking FAST?
• Why aren’t User Contexts working? Are User Contexts working?

For all of these questions, the QRServer is an invaluable tool.

What is the QR Server?

The Query Result (QR) Server, is a way to speak with FAST directly, without worrying about SharePoint. It’s a web site, accessible only to users logged in to the FAST server that allows users to fire queries into FAST and see the resulting XML. This is important because it allows users to rule-out (or in) SharePoint as the culprit for broken searches.

By default, the QR Server respects content security rules, so using different accounts on the QR Server will give you different results.

How do I find my QR Server?

You access the QR Server via a web-browser. The url to type is http://<fastservername>:<basePortNumber+280>/. So let’s say the ever popular contoso.com is served by a FAST server with the name http://fsContoso1.controso.com using the default base port number of 13000. In that case you’d need to navigate to http://fsContoso1.controso.com:13280.

The QR Server is ONLY accessible directly from a FAST server, so you must Remote Desktop onto the server to use it. From there, you find your base port number by looking at the hostconfiguration.xml in the < FASTInstallLocation>/etc/ folder

The FAST Query Game

Debugging queries in a production or UAT environment is a serious pain. This technique was taught to me by a FAST Ninja (thanks Torstein!) and is a bit bizarre. It involves running a query from SharePoint and then extracting the data passed to FAST out of a log file and manually resubmitting the query on the FAST server, all within 15 seconds.

This approach is necessary because along with your query, SharePoint sends FAST  a user authorization token that is only valid for a short period of time.

Preparation:

• You must be logged into the FAST server
• Open Windows Explorer and navigate to <FASTInstallLocation>/var/logs/querylogs/. Find the most recently modified file.
• Open a copy of NotePad (or your favourite text editor)
• On the FAST server, open a web browser and navigate to the QR Server.
  • Search for the term “test”
• Anywhere
  • Open a web browser and navigate to the SharePoint search UI.
• At this stage you will have 1x Notepad, 1x Windows Explorer, 2x Web browsers

The rules:

• You must execute your queries from the SharePoint server, via the UI
• You have 15 seconds to complete the following process… or you die… probably.

STEP 1: On your SharePoint FAST Search Centre, execute your query

STEP 2: Quickly switch to the FAST server and into the the FAST log folder. Open the most recent log file in Notepad and navigate to the bottom, making sure Word Wrap is on.

STEP 3: Take the last url in the file

You will need to grab the url from the  querystring, taking everything after “search?” until the HTTP/1.1 text. In a production environment this can span multiple lines and be tricky to select within the 15 second limit. This is usually the part where I run out of time.

STEP 4: On the QR Server, paste the querystring into the location noted below

STEP 5: Hit “go”, “enter” or whatever to start your search and see the results FAST sent back to SharePoint

If you run out of time, you’ll see the same QUERYTRANSFORMS elements, but nothing else.

Interpreting the results

Following a successful round of the FAST Debugging game, you can investigate the results. I can’t possibly describe each element, but at a high-level:

• QUERYTRANSFORMS à Describes what was submitted through SharePoint. Refiner selections, user contexts, sorting selections will all appear here.
• NAVIGATION à Indicate what refinement data is being sent back to the server. Useful when the number of displayed refiners seems incorrect.
• RESULTSET à Includes all the search hits from the current “page”, including the value of every managed property (i.e. attributes of a document that FAST gives special treatment). While it doesn’t give you a way to interrogate every crawled property you also get to look at the rank of a document
• PAGENAVIGATION à If you work in Collaboration you’re smart enough to figure this out.

I’ll talk more about interpreting the results in my next post, but for now, I hope this helps.

Cheers!

Neil

**Note: this post it limited in scope to the Single Sharepoint VM environment, anything more complicated is frankly beyond my feeble server administration skills.

If you try to install AD and DNS onto a Sharepoint VM after having already installed Sharepoint you run into a range of problems. The first time I tried to fix the problem I fried my environment and had to revert to a snapshot.

First, install AD and DNS as you normally would. Here’s a link to the guide I used.

At this point if you try to hit your Central Administration site or any other Sharepoint site, you’ll get a Service Unavailable message on any page you hit.

I tried the following to bring up something, anything Sharepoint:

• Hitting my server via the computer name (http://phoenix:5555)
• Hitting my server via the IP address (192.168.0.2:5555)
• Hitting my server via localhost (http://localhost:5555)
• Hitting my server via the fully qualified domain name (http://phoenix.kmtests.local:5555/)

None of these works, and if I wasn’t getting the Service Unavailable message, I was getting one that said:

Under Construction

The site you are trying to view does not currently have a default page. It may be in the process of being upgraded and configured.

Looking at the server logs, you see two errors:

Application Log Screenshot

System Log screenshot

Aha! Adding a domain to the mix changes all the user accounts so that your old accounts need to be reconfigured. This is easily done by going into IIS Manager and updating the Identities of all of the app pools to reflect the new, domain enabled accounts.

i.e. servername\MossServiceAcct becomes domainName\MossServiceAcct

Having reconfigured the app pools, trying to hit the server again give you a message that says

The current identity (domainName\MossServiceAcct) does not have write access to ‘c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files’.

You can resolve this easily by navigating to that location and by granting write access to the folder in question (you will need to do this for each unique service account which hits the Temporary ASP.NET Files folder).

Central Admin will loads, but hold on cowboy/girl, you won’t be able to get to any of the pages on the Operations or Application Management tabs.

Some or all identity references could not be translated.   at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)

Will it never end?

Ultimately I followed the process outlined on two specific web pages (retyping them would be silly)

• WSS & SharePoint Server 2007 Password Change via STSADM by Joel Oleson
• How to change service accounts and service account passwords in SharePoint Server 2007 and in Windows SharePoint Services 3.0

Following Joel’s tips I got 100% of the way, but the other page a good reference anyways. I found that there were so many passwords to re-enter that I missed a couple (specifically the stsadm -o editssp command) but got there in the end.

Good luck, it’s a painful process, but a possible one. Just be careful and meticulous and you should be okay.

I found this to be a total pain to figure out how to fix, but once done, the solution is actually very simple.

My setup:

Most people doing Sharepoint development will be doing so in a proper networked environment (setup by a proper network admin).   In which case this article is unlikely to apply to you and this article, can probably point you in the right direction (hint: you need to set your web.config proxy settings).

I am running a Sharepoint development environment at my house, using VMWare, with a minimal win2k3 setup.  I’m not a server admin and I’m conscious hits to performance so the environment is very lightweight.  No Domain Controller, no Active Directory.  I’m a developer not a sysadmin.

The problem:

Unfortunately, Sharepoint cares not for my developing ways and when I tried adding an RSS webpart to a Sharepoint page got the following on-screen error:

An unexpected error occured processing your request. Check the logs for details and correct the problem.

Crapola.  First I thought dodgy rss.

Nope.

Then I thought, the IIS account doesn’t have web access.

Nope.

So then I looked at the million and one “Sharepoint rss proxy” articles on Google  to no avail.  They all want you to make changes to the defaultProxy entry in your Sharepoint’s web.config.

Nope.

The cause:

For some reason, if you don’t have a proxy setup, Sharepoint throws it’s toys out the pram and won’t work.  It won’t even try to make a network call (I checked using WireShark).  Even when I tried to tell the defaultProxy entry to bypass all addresses, it ignored me.

The solution:

Setup your own proxy.  It’s actually very simple (trust me I hate server admin stuff)

• disable Windows firewall (should have a firewall on your host anyways)
• I then followed the instructions on support.microsoft.com as best I could under the “Installing the Routing and Remote Access Service” heading.
• Then magically my rss webparts worked

Also important is to make sure you use a proper RSSViewer part instead of a RSSAggregatorWebPart (added manually).  The only difference I can see is in the configuration xml, but the latter continued to break even after my changes.

Hopefully this doesn’t up some insane hole in my firewall.

Hope that helps.