Underscores: SharePoint 2010 Search Worst Enemy or Just a Lesson in Futility

This is a really interesting topic.  I'm hoping that I get some feedback on this blog post based on others experience with SharePoint Search.

At a customer site, we have been troubleshooting a search problem where users were not getting any search results from within a site or a list/library, even when you could clearly see the name of the document contained within it.  We are confident that the Search Service is properly configured (because it is working fine on other sites within the farm) and we confirmed that it is running regular incremental crawls.

The more we dug into the issue, we discovered that it appeared that it had something to do with underscores in the name.  It was quickly apparent that any file under a folder that had an underscore, would not show up in the search results.  This made us question how Microsoft designed their search (why would names with underscores be ruled out?), so we created two test site collections (one created with an underscore in the site name and a second without) so we could test out the search in the following 3 scenarios:

1. Create a Document Library with an underscore in the name (underscore_library)
2. Create a Document Library with no underscore (regularlibrary)
3. Create a Document Library with a space in the name (space library)

Within each of those document libraries, we created 3 folders:

1. Folder with an underscore in the name (underscore_folder)
2. Folder with no underscore (folder1)
3. Folder with a space in the name (space folder)

And within each of those folders, we created two test documents:

1. Document with an underscore in the name (document_1)
2. Document with no underscore (document1)

We then ran a full crawl and searched at the site level for a keyword contained within the document.

Wouldn't you know... all our search results showed up?  But we thought it was a problem with the underscores, how could this be???

Ok, we thought, maybe it's one of those things that just needs to get kicked once in a while.. you know... Have you tried turning it OFF and back ON again?

So we decided to run a full crawl on the content source for the user's sites and just like that, all search results then showed up!  I was both elated and disappointed at the same time.  I was happy because the user's search results were now being displayed (and we could mark this ticket closed).. but I was disappointed because this blog post that I had been writing (and the effort to create test site collections) was for naught.

Even though this did the trick for the issue at hand, the question then becomes, what event or change happened to the site and/or the content that would cause it to not get picked up in the incremental?  We did experience a SAN crash last year (after this data was originally created) and this caused us to have corrupted databases that needed to be repaired, but we were not sure this was the reason these files were not getting picked up by the index.  We were at a loss, but I guess sometimes you just have to accept that a "reboot" will often times fix weird Microsoft problems like this and just move on.  No sense burning off a bunch of brain cells to figure every little thing out.  It works - you're a hero - now move along.

I'm always open to ideas, suggestions or perhaps your own experience with similar funky search issues like this one.  I decided to still post this to hopefully remind everyone that sometimes the best solution is the easiest.

If you want to learn more about planning for crawling and federation in SharePoint 2010, we referred to this technet article: http://technet.microsoft.com/en-us/library/cc262926.aspx

Until next time... stay thirsty my friends!

SharePoint 2010 Search Issue: No Search Results for Users in a One-way Trust Domain Scenario

I just wanted to write a quick blog post about an issue we experienced this week in our enterprise SharePoint 2010 environment while it was still fresh in my head.

Even though our search service is configured properly and successfully crawling all the necessary content sources, we were getting complaints from our end-users that they were not getting any search results.  I could performed the same search query they were on the same site and I would get all the results.  So why is this happening?

Well, this is the point in time where all good SharePoint admins reach in their toolbox and pull out the biggest hammer they can find.  That's right, we did a Google search (or Bing if you're not into the whole brevity thing).

Anyway, we stumbled on THIS blog from Matt Stratton dated June 1, 2010.  He explains how to configure SharePoint 2010 Search in a one-way trust scenario.  This described our environment to a "T".

So we dug a  little more.... Then we found this article: http://support.microsoft.com/kb/2344518

EUREKA!

Once we ran the script and performed a full crawl, these users tested their sites again and search was working correctly.  They received results from their site search and everyone in the kingdom was happy.

The End!

How To Extract a Farm Solution from SharePoint 2010

I found this useful today.  I need to decompile a solution that was created by someone else and globally deployed to our production farm.  I did not have the original .wsp file, so I had to extract it from SharePoint using these 3 lines of code:

$farm = Get-SPFarm
$file = $farm.Solutions.Item("global.deploy.solution.wsp").SolutionFile
$file.SaveAs("c:\temp\global.deploy.solution.wsp")

Note that in order to run this command, you need to be a member of the Farm Administrators group and have permission to the configuration database.

Migrating a Single Sub-Site from a MOSS 2007 Farm to an existing SharePoint 2010 Farm

I was recently tasked to migrate a single sub-site from a degraded MOSS 2007 farm to an existing SharePoint 2010 farm.  The existing MOSS 2007 sub-site is contained within a single content database, in a single site collection with over 2500 other sub-sites.  The task was to migrate just the one single sub-site, so here are the steps I took to accomplish this move, using the Database Attach method.

1. Create a new content database in the MOSS 2007 farm.  This was accomplished through SharePoint 3.0 central Administration.  It's a pretty straight-forward process.  I did this so I had a clean database to move that only had the data I needed.
2. Create a new site collection in the new content database within MOSS 2007.  Again, a straight-forward process using SharePoint 3.0 Central Administration.  I mimicked the managed path that I wanted to use in the SharePoint 2010 environment.
3. Open Command Prompt and change directory to %COMMONPROGRAMFILES%\Microsoft shared\web server extensions\12\bin, then run the following STSADM command to export the content of the site:
   stsadm -o export -url <Old Site URL> -filename <export file name.cab> -includeusersecurity -versions 4 (to include all versions)
   More information about stsadm export/import can be found HERE
   

   It's important to make sure you have enough available disk space for the backup files.  You can verify the size of the site by opening it up in SharePoint Designer (2007 in this case) and clicking Site > Reports > Site Summary

   
   

   If you get an error during the export process (Error: Unknown compression type in a cabinet folder), it means you have insufficient disk space available.  Please keep in mind that it will write temp files to the C drive, so make sure you have at least 2-3x the total storage needed, or save the back up files to a different drive to split off the load.


4. Once the content has been exported, use the following STSADM command to import the content of the site to the new site collection on the new content database:
   stsadm -o import -url <New Site URL> -filename <export file name.cab> -includeusersecurity

At this point, we have isolated just the content we need into a new MOSS 2007 content database, which will make the move much easier than it was before we started.  If you run into any problems with the above steps, make sure the account you are using has the necessary permissions.  

Before we create a backup of the 2007 content database and move it to the new 2010 farm, we will need to run the Pre Upgrade Check and fix any issues reported before moving on to the next step:
stsadm -o preupgradecheck

Once the database is ready, it's time to create a backup the database and copy it over to the new SQL instance:

1. Open Microsoft SQL Server Management Studio for the 2007 instance. Right-click on the content database and select Tasks > Backup...
2. Enter the Backup Name, select Destination, and click OK to start.
3. Copy this backup file to the SharePoint 2010 SQL server.

After the database is in the new environment, restore, test and mount the database to SharePoint 2010:

1. Restore the SharePoint 2007 backup to SharePoint 2010 SQL Server. Open Microsoft SQL Server Management Studio. Right-click on Databases and select Restore Database...
2. Enter the new database name, making sure that you don't overwrite the original content database. Select the Source and click OK to start.  If the database is showing "offline", be sure to bring it online before moving to the next step.
3. Next, test the database against the existing SharePoint 2010 web application.  If there are any errors, make sure to correct them before mounting the SP2007 content database.
   Test-SPContentDatabase -Name <DatabaseName> -WebApplication <URL>
4. If there are no errors (or the errors have been fixed), use the Mount-SPContentDatabase cmdlet. This cmdlet also upgrades the SP2007 content to SP2010.
   Mount-SPContentDatabase <ContentDb> -WebApplication http://SiteNameIf the database was moved from a different environment, you may need to change the site collection administrators in order to see the Site Settings menu
5. Verifiy the data is moved properly and perform visual upgrade.