Boolean property based search scopes - FAST Search

In my SharePoint list I have a column of type Yes/No. The requirement is to create the scope based on this column. It was quite easy when you have the SharePoint 2010 search. But once I move to FAST Search, this scope was not working.

I followed all steps as suggested in technet for creation of scope.
1. Create the managed property of type boolean on (FAST Search Server)
2. Map the crawled property to above managed property
3. Run Full crawl
4. Create the managed property of boolean type on Server schema with the same name as in step 1.
5. Create the scope based on the property rule i.e. propertyname = TRUE

However this doesn't work. Glad to find out the workaround or trick for this problem.

You should create the Server schema managed property of type TEXT instead of Boolean. Now your scope works.

When you create the scope with the boolean type property and pass TRUE or YES value it get converted to 1. Similarly for FALSE or NO it will be 0. For example:- propertyname = TRUE is convered to propertyname = 1. When you use this scope the FAST query server fails to treat 1 as TRUE and hence you won't get any results.

Instead if you create the scope with text type properyname then the scope rule will be saved as propertyname = TRUE.  Now the FAST query server treats correctly and hence you get results.

SharePoint and wWWHomePage property

SharePoint has the user profile property "Public Site Redirect" which gets the value imported from the wWWHomePage in Active Directory. This property is set when user selects the default my site.

When user creates/visits his my site he gets a popup message asking to save the current site as default my site. On clicking yes, this is updated in the registry and wWWHomePage field in AD. This works only if the user is using the Office 2007 and below. For users having Office 2010 it doesn't work. Office 2010 updates the registry but not AD. Microsoft has dropped this feature in Office 2010.

Read this blog for details:-  http://trevermoore.com/author/treverm/

Control the contents to be indexed/crawled

In SharePoint, one can control what contents on the page needs to be indexed, should the links on the page to be crawled or not. Use the HTML <META > tag to tell the indexer whether you want to crawl the page contents or not.  You can also direct the indexer whether you want to crawl the links on the page or not.

For example:- <META name= "robots" content= "noindex, nofollow" > tells the indexer not to crawl the contents and don't crawl the links on the page.
Similarly <META name= "robots" content= "index, nofollow" > means crawl the contents but ignore the links on the page. 
<META name= "robots" content= "noindex, follow" > means don't crawl the contents but crawl the page contents whose links are present on this page.

By default the indexer will treat as content="index,follow" if nothing is specified as above.

You can further control the specific contents on the page to be crawled or not.  This can be achieved using the "noindex" class for the <div> tag.  Any content within the <div class="noindex" >
tags will not be crawled.  This is simlar to "noindex, nofollow" i.e. no contents will be crawled within that div tag and no links will be followed.

For example:-
<div class="noindex">
Contents in this div tag will not be crawled
This link will not be crawled too
</div>


But there is an exception to this.  The
<div class="noindex">
will not work in the nested div tags. 

For example:-
<div class="noindex">
<div>

Contents of this tag will be crawled as it is inside the child tag.
This link be crawled too
</div>
</div>

Document Information Panel was unable to load

Last week I was working on an strange issue. Some of the users were getting "The Document Information Panel was unable to load. The document will continue to open. For more information, contact your system administrator." when ever they try to open the office document from an WSS 3.0 site.

On analysing found one column in the library had flower braces {} in its description. Replacing the {} with () dissappered the error message.

Removing user from site using PowerShell

Remove-SPUser command is used to remove user from the site.


Remove-SPUser $useraccount -web $web -confirm:$false;

People Search and Bets Bets web part

Search Best Bets web part works only when it is added on the content search results page(results.aspx). This web part doesn't work when it is added on the people search results page(peopleresults.aspx). There are few other web parts whose behaviour changes based on which page layout it is added to in the search center.

Search Action Links web part is one of them. When it is added on the content search results page the sort options are different compared to when it is added on people search results page. On content search results page it give sort by Relevance and Modified date. Where as when it is on the people search results page it shows the sort by Default, Name and Social Distance.

Another major difference in web part's behaviour is of Refinement Panel web part (SharePoint 2010). Even if you add the People Refinement Panel web part on the content search results page, it behaves as normal refinement panel web part. This is same even after changing the Filter Category Definition of the web part.

Adding user to a site using PowerShell

Started exploring the PowerShell commands on SharePoint 2010.

New-SPUser command is used to add user to the site.

Below script gets the .csv file as input parameter which contains the URL, domain account, permission level.

AddUsers.PS1
-----------------------------------------
param(
[String]$InputFile = ""
)

$SitesList = Import-CSV $InputFile;

ForEach ($s in $SitesList)
{
$web = Get-SPWeb -identity $s.URL;

New-SPUser $s.Useraccount -web $web -PermissionLevel $s.Permission -confirm:$false;

$web.Dispose();
}

"Complete";
-----------------------


Sites.csv
----------
URL,Useraccount,Permission
http://test.com/sites/xyz,domain\user1,Contribute
-----------

To run the command
PS> AddUsers.PS1 -InputFile Sites.csv

Image distortion on MOSS People Search page

Recently I came across this issue where the images on the people search results page get distorted.   Image was getting strecthed vertically and only part of the image was displayed horizantally.  Images were not getting resized to 75*75 px as designed.

On analyzing, found that People Search Core Results web part is designed to display the people's my profile image in 75*75 px size.  The web part contains the javascript function resizeProfileImage('img_id') which resizes the image.  This javascript is set to trigger in 1 ms once the profile image is displayed.  When there is large images this function will get triggerred before the image is loaded and hence causing the distortion. 

To overcome this issue, I increased the trigger time of the above function to 2 sec i.e. window.setTimeout("resizeProfileImage('img_id')", 2000) .  With this change issue didn't occurred again.  However later I added the Faceted Search web part on the page, which was taking some time to compile the facets and due to this image distortion issue appearred again.  This time I used different approach and added the below javascript to the page using a content editor web part and this resolved the image distortion issue permenenetly.
----------------------

<script>
function fnResizeNew()
{
var fields,i;
fields = document.getElementsByTagName('IMG');
for( i = 0; i < fields.length; i ++ )
{
var imgid = fields[i].getAttribute('id');
if(imgid.indexOf("CSR_IMG_") != -1)
{
resizeProfileImage(imgid);
}
}
}

_spBodyOnLoadFunctionNames.push("fnResizeNew");


</script>
------------------

Welcome to my blog

It took me a long time to start my own blog.  All these days I was reading other's blog.  Blogs are treasures of knowledge.  When I need help on technical issues I did the search on Google to see any blog has solution to my problem.  And most of the time I got the answers.  Its time for me to start blogging my experience.  I'll not keep this as pure technical one and wish I keep my blog updated frequently. 

Its better late than never. :)