Today’s episode of SharePoint Blank is going to be unlike any post that’s appeared in this space previously. You see, many the time I’ve gone into “the mailbag” to pluck a question that allows me to kick off an investigation into learning (and sharing) the answer to the question that had been posed. Today, however, I’d like to hand the reins over to a friend to tell his own tale of a SharePoint mystery he’d tripped across… and how he went on to solve that mystery.

A couple of months ago, my friend Bryon Jordan, an IT Analyst/Project Manager in Louisville, KY, dropped me an email letting me know that his organization was deploying SharePoint, and he was seeking some recommended resources to help get up to speed on the platform. Well, the other day, I heard from Bryon again, and this time he wanted to share an excellent nugget of SharePoint information that he’d discovered. I thought that Bryon’s discovery (and his telling of it) made for such a great SharePoint story that I wished the discovery had been my own so that I could blog it here … and then I realized, hey, it’s my blog, so if I want to invite a friend to share his own SharePoint Blank-esque tale of discovery in this space, there’s nothing stopping me from doing so, right? And so, without further ado, I’m going to get out of Bryon’s way now and let him bring the knowledge…

“I had an interesting SharePoint 2007 experience that I finally solved and thought I’d share it with you.  It may be old hat to you now, but it took a lot of investigating for me to solve it. It’s funny how no amount of reading ever prepares you as well as rolling up your sleeves and getting your hands dirty.

We are creating folders for patients using a six-digit number (HIPAA requirements to keep patient confidentiality). Each document in the folder begins with the same number, thus folder 123456 has any number of documents with names that begin “123456,” as well as other identifiers to give it a unique name.

When I did a search for certain patients (based on their unique identifier), however, information pertaining to other patients also popped up in the search.

For the following example, I’ve used two fictional patient numbers to illustrate the issue.

Patient ID 159763 would show six documents in the search results when there were supposed to only be five (not including the parent folder). There was an extra document, belonging to patient ID 311789, popping up in the search results that did not have that number in it at all, although, for some reason, the properties reflected 159763 in the search.

It turns out that SharePoint indexes a lot more than the file name.

After some research, I went into the DB and started doing queries to see if I could find something in the data that triggered the search to display this other patient’s document.

This was my query hitting the views in the SharePoint DB that turned up all sorts of information:

select top 20 docs.Leafname, docstreams.* from docs
INNER JOIN docstreams ON docs.ID = docstreams.ID
WHERE docs.LeafName Like ‘311789%’ order leafname

As it turns out, the size of the other patient’s document that was showing up has a value of 159763 in the field docstreams.size.  At least now I know why we have a handful of these unexpectedly popping up throughout our search results.

Better yet, I was able to find a solution for our dilemma.

In Central Administration, go to Shared Services -> Search Settings and then click on Metadata Property Mappings.

Scroll down to the “Size” property and click the right-hand column that links to its mapping.

There is a check box on the bottom right-hand side of the screen named Include values for this property in the search index.

You want to uncheck this.  Once you’ve done  so, the change apparently takes effect once you re-crawl.”