Nick Hadlee's Blog on SharePoint and Other Occasional Rants…


No Search Results for Contextual Scopes
July 24, 2011, 12:22 pm
Filed under: 2010, Search, Troubleshooting

Contextual scopes are a really useful way of performing searches that are restricted to a specific site or list. The “This Site: [Site Name]”, “This List: [List Name]” are the dead giveaways for a contextual scope (I even think you can get a folder context too “This Folder” but it alludes me most of the time).  What’s better is contextual scopes are auto-magically created and managed by SharePoint for you so you should pretty much just use them in my opinion.

You may come across a problem where SharePoint search works fine except for your contextual scopes. Your global search scopes all return results but for some strange reason the contextual scopes are empty…

I came across this problem a couple of times recently and the fix is really pretty simple – check your alternate access mapping (AAM) settings and make sure the host header that is specified in your default zone is the same url you have used in your search content source. Normally SharePoint kindly creates the entry in the content source whenever you create a web application but if you have changed around any AAM settings and these two things don’t match then your contextual results will be empty. Case Closed!



When an Index Server Can’t Stop ‘Stopping’
May 27, 2009, 11:10 pm
Filed under: Administration, SharePoint, SQL, Troubleshooting

Due to some erratic behavior with a farms index server it was necessary to uninstall the indexing role and then re-provision it. The problem was during the uninstall the index service got stuck in a stopping state. A quick check in the error logs pointed to the SQL server. The SQL server logs were a little more descriptive with a 17310 event and even included the words ‘fatal’:

Event Type:    Error
Event Source:    MSSQLSERVER
Event Category:    (2)
Event ID:    17310
Date:        M/dd/yyyy
Time:        h:mm:ss yy
User:        N/A
Computer:    xxxx
Description: A user request from the session with SPID XXX generated a fatal exception. SQLServer is terminating this session. Contact Product Support Services with the dump produced in the log directory.

I have found when troubleshooting Google can either be a savior or a massive run-around, usually it depends on the reliability of the source and how good your searching skills are. In this situation what appeared to be a Chernobyl-esq problem had been encountered by a few people and ensuring that service pack 2 was installed on the SQL Server was the recommended fix. After applying the service pack the SQL logs were clear and the index service was able to be uninstalled and re-provisioned.

Unresolved Questions

The biggest question in the aftermath was why was a production SQL server not running the latest service packs? Surely someone has neglected their duties?

The infrastructure guy responsible for the SQL server has an interesting theory, especially if you like the implausible, the current blame for this issue was the installation of the SQL business intelligence studio onto the server which downgraded the SQL dll’s back to the RTM version. This will make a interesting test and would represent a massive bug if it was the case. Has anyone come across this or something similar before? It wouldn’t be the first software bug and it won’t be the last…




%d bloggers like this: