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

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.

**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.

Have you ever had to re-attach a Sharepoint workflow after it has been removed?

It is impossible via the browser (from what I can see) and via designer it is far from obvious how to accomplish this. What you need to do is open the workflow in Sharepoint Designer, click “Finish” and the workflow will re-attach itself. Not very obvious, but it works.

Unfortunately there is no way to associate a workflow with another list unless you open the various workflow xml files change the list guids inside.

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.

According to play.com, the N97 is due to be released March 31 and looks to be priced at £479.99.  Now, it’s most likely that play.com have merely put down the last date of Q1 in hope that it will arrive by then, but I can live with that.

It’s also good to know the full retail price is £20 less than the 8gb iPhone 3G and £120 less than the 16gb iPhone 3G.

I’m definitely looking forward to seeing this phone.

Update Jan 26: Looks like Nokia has come out and stated that March 31 IS NOT the official release date.

Out of the box, if you use a list-bound dataview as part of a Sharepoint Site Template, you’ll get a grumpy message when creating a new site

“Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Windows SharePoint Services-compatible HTML editor such as Microsoft Office SharePoint Designer. If the problem persists, contact your Web server administrator.”

How helpful.

The issue is the dataview has a hard-coded reference to the list guid on the original site. To resolve this, simply wrap curly braces “{” and “}” around all instances of the guid. This tells Sharepoint to refer to the newly created list when deploying the site template.

Granted this seems like a bug, but it works.

There should be 6 or 7 references to the listID in any dataview. Just hunt through the code and you should find it fairly easily.

Just heard a great song from the Black Tories called Ghost in the Machine which was played during the into of the most recent podcast from the Canucks Outsider.  You can download it from their website…. and if you like it, buy their album.  One of the best songs I’ve heard all year. 

AJAX-Enabled Web-Parts: solving the problem of changing Client IDs One of the most challenging aspects of building SharePoint-enabled web parts is using JavaScript to interact with specific controls. As a consequence of how SharePoint renders controls with id’s in Sharepoint WebParts, it’s near impossible to write clean JavaScript. From a maintenance perspective I HATE using server-side code to render JavaScript. It’s inelegant and reeks of a lack of forethought. Yuck yuck yuck. It’s like sweeping dust under the rug. Wherever possible, webpart-specific javascript should be held within a single .js file (stored in the 12Hive). The problem is that Sharepoint alters a control’s ID during the page rendering process. So, a label with the ID “label1” might become “ctl00_label1”. The naming process is entirely unpredictable. This makes interacting with a specific DIV, INPUT or any other html element very difficult because you can’t predict the rendered IDs during development. This is especially problematic if you’re looking to host several instances of a webpart on a single page. One really terrible way of dealing with this is to render the html yourself by adding literal controls ala

LiteralControl l = new LiteralControl();
l.text = '
blah
';
this.Controls.Add(l);

This is a terrible approach which is severely limiting and unnecessary. To tackle the problem I’ve devised the following solution which revolves around creating a Javascript class to accompany the web part:

• create properties to store the dynamically generated IDs of every html component to wish to interact with
• create pointers to every html component you wish to interact with
• create an init function. As input you pass the clientID of the webpart AND the id’s of every component you wish to interact with.

• this function will store the id’s using the properties
• this function will also attach the pointers to their respective objects
• this function should also attach any eventhandlers
• create any supporting functions (i.e. webservice calls, webservice receivers)

This approach embraces the absence of reliable identification info. It is also sympathetic to having multiple copies of a webpart on the same page. Here’s what the javascript might look like

function UpdatingLabelWebPart() 
{ 

	var me = this;	//required to reference the object at runtime  
	this.clientID = null;	//ids 
	this.labelID = null; 
	this.buttonID = null;
	this.label = null;	//controls 
	this.button = null;
	this.register = function (clientID, labelID, buttonID) 
	{ 
		me.clientID = clientID; //init the id 
		me.labelID = labelID;
		me.buttonID = buttonID;
		me.attachToButton();
	}  
	
	this.attachToButton = function() 
	{ 
		//if the controls haven't loaded yet 
		if (document.getElementById(me.buttonID) == null || document.getElementById(me.labelID) == null) 
		{ 
			setTimeout(me.attachToButton, 50);
		} 
		else 
		{ 
			//register the controls 
			me.label = document.getElementById(me.labelID);
			me.button = document.getElementById(me.buttonID);
			//attach any events button.AttachEvent("click", me.buttonClicked);
		} 
	}  
	
	this.buttonClicked = function(sender, args) 
	{ 
		me.label.innerHTML = "Hello World";
	} 
}   
 

This approach lets you have multiple instances of the same AJAX-enabled webpart and saves you the hassle of having to write annoying javascript (having to write me.label is hardly a chore).

I came across an annoying problem when playing with the ASP.NET Ajax extensions earlier today.  I was trying to call a script-enabled web-service but kept getting a javascript error telling me my service was undefined.  It’s been a month or so since I’ve used MS Ajax and needed a refresher.

Some background:

• My project namespace is ajaxTest
• My webservice class is helloTest
• My webservice function is helloWorld

I enabled the web service using the [System.Web.Script.Services.ScriptService()] attribute

I put the script manager code block in place and included a reference to the service.

<asp:ScriptManager ID=”ScriptManager1″ runat=”server”>
<Services>
<asp:ServiceReference Path=”helloTest.asmx” />
</Services>
</asp:ScriptManager>

I then created some javascript to call the web service

function testScriptService()
{
var tmp = helloTest.helloWorld(onResult, onTimeout, onError);
}

It was at this point I received the “helloTest is undefined” message.

A quick search on google revealed two websites which helped me.  The first had the right answer (in my situation).  Strangely, the second website had a slightly different solution which seems to have helped a number of people, but I was unable to figure out why (I didn’t work for me).

So, the solution that worked:

You need to fully qualify the javascript with the namespace of your webservice.

Namespace.Class.Function >> ajaxTest.helloTest.helloWorld

The solution which didn’t work for me but has worked for others is to use the following structure:

Namespace.Services.Class.Function >> ajaxTest.Services.helloTest.helloWorld

No idea why the difference, but hey.

Credit where credit’s due, thanks to Omen’s blog and Ryan at Solutek.