Summit 7 Team Blogs

SharePoint 2010 Administrators must be sensitive with FAST Search For SharePoint

Case Sensitive, that is.
After years of working on Microsoft products, it is easy to develop a routine of ignoring case especially with names. Some PowerShell commandlets are forcing us to remember that there really is a difference between uppercase and lowercase.
For SharePoint 2010 administrators who are planning to use FAST Search for SharePoint 2010(FS4SP), my advice is LEARN QUICKLY!
SharePoint is rarely case sensitive especially in the Central Admin UI. I can’t think of any instance where a name is case sensitive. FS4SP almost always is case sensitive probably because the original product was not developed on Windows operating system.
Last week, a case sensitive name bit me big time.
The default content collection for FS4SP is named “sp”. When creating the FAST Content Search Service Application (SSA), I entered the content collection name as “SP”. SharePoint was blithely happy. FS4SP did not recognize the name. As a result, the event log messages insisted that the “SP” content collection could not be resolved. No crawls worked. I would confirm the name on the FS3SP server using PowerShell but the lowercase “sp” just did not register with me.
Finally, Leo Souza from the FAST training team reminded me that FS4SP was case sensitive even with names. Now the fun begins.
Going back to Central Administration to the properties of the FAST Content SSA, I change “SP” to “SP”. Guess what, since SharePoint is not familiar with case sensitivity in names, the UI does not recognize the change as a change. There is no difference in the UI between “SP and “sp” so no change is initiated when I click OK. Leo had warned me about this too, but that did not seem reasonable.
So, I changed the content collection name to “DW” which was totally wrong but at least was recognized as a change. Then, after manually starting a crawl and seeing the event log error message that could not resolve “DW”, I changed the name from “DW” to “sp” and magically crawls worked fine.
Unfortunately, somewhere in the configuration, I had also used “SP” in a SharePoint PowerShell command, so occasionally an error message would appear in the event logs complaining about the name. So I deleted the FAST Content SSA and recreated correctly.
Since the FAST Content SSA is only a connector for FS4SP, nothing on my FAST side was impacted and I had only configured a couple of Content Sources on the SharePoint connector.
However, I am now a SharePoint architect who is very sensitive about case in all cases!