MOSS - This List not returning Search Results

Symptoms:

You can't search lists or libraries in MOSS 2007. Or some older lists return results but nothing new. Essentially "This List:" doesn't return results while searching, but "This Site:" does return results.

There are a couple of possibilities here for the cause and I've read some ridiculous theories on this. Most of them point as your SSP being corrupt and you need to create it. Or you've corrupted your databases and need to restore them.

Really the first place I thought to check was Authentication. I found that there 2 different types of content in Sharepoint / MOSS 2007. Long story short, you can search the .aspx pages, separately from List and Library items. I've found this to be reflected in your indexes also.

What actually triggered this for me was resetting SPN's for Sharepoint. I found that some of the SPN's were throwing errors on the Domain controllers so I deleted and recreated them. In another case I changed from Kerberos to NTLM authentication to resolve some immediate issues but didn't update my search service account.


Fixing "This List" search issues:

1) Login to your SSP
2) Under Search, select Search Settings.

You will see the following:

Indexing status: "if you're in error it will probably say something other than IDLE"
Items in index: "# of items"
Errors in log: "# of errors"
Content sources: "Local Office SharePoint Server sites"
Crawl rules: "will be different depending on what you've defined"
Default content access account: "Should be a Domain account
Managed properties: Default is 130 defined properties
Search alerts status: "Alert status"
Propagation status: Idle

3) Click on on "Manage Crawl Rules"
Note: You should have the URL of your Site configured here.
4) Click on the URL of the site with the issue(s).
5) Select "Include all items in this path" and check Crawl complex URLs (URLs that contain a question mark (?)).
6) Then select "Specify a different content access account"
7) Enter in the Search User account and password.
8) Use the Breadcrumb and select "Search Settings".
9) Click on "Content Sources and Crawl Schedules".
10) Select your content source ("Local Office SharePoint Server Sites" is the default).
11) Make sure that the URL for your SharePoint site is listed in the "Type Start Address Below" box.
12) Under Crawl Settings, select "Crawl everything under the hostname for each start address".
13) Then set your crawl schedules. Usually you do a Full Crawl outside of your business day and hourly for your incremental crawls.
14) Check the box for "Start Full Crawl"

You can monitory the status of the crawl at the "Search Settings" page. Depending on how much content you have, will determine how long it will take to index. Also it will go through and delete old indexes for deleted content at the sametime. This will add time for the full crawl to complete.

Checking in Files / Removing Locks in TFS

I've found this to be an issue on multiple occasions. Essentially you're using Team Foundation Server with Visual Studio and a member of your team leaves with code checked out or locked.

There are a couple of ways to fix this but the easiest I've found is with TF.exe. If you have Visual Studio installed and priviledges you can use this tool to fix you problem.

Note: You can find the TF.exe tool in:

C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\TF.exe (VS2005)

or

C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\TF.exe (VS2008)


Get a list of workspaces for a user:

tf workspaces /owner:UserName /server:ServerName

eg. if my user name was JDoe and my TFS web server name MyTFS then the command would be:

tf workspaces /owner:JDoe /server:MyTFS

Note: Use the Host Name of the server you're attaching to. If you have a multiple server configuration, you need to use the Server Name of the web server where your TFS client connects to. Don't use the host header (if applicable) or the http address and you don't need to use the Fully Qualified Domain Name (FQDN).

To remove a workspace for a user, you need to know the workspace and the username. The default workspace name is their development machine name. Occassionally developers have multiple machines, maybe a laptop and a desktop for development. It's not uncommon to have multiple workspaces associated to the same usere.

Delete a workspace for user:

tf workspace /delete /server:ServerName "workspace";"workspaceusername"

eg. if my username was JDoe and my workspace was JDoe2003, and my TFS web server was MyTFS, the command would be:

tf workspace /delete server:MyTFS JDoe2003;JDoe



Get a list of directories in a workspace for a user and display the GUI (Graphical User Interface):

tf workspace "workspacename";"workspaceusername" /server:ServerName

eg. if my user name was JDoe and my TFS web server name MyTFS then the command would be:

tf workspace JDoe2003;JDoe /server:MyTFS

Publishing InfoPath Forms - Updating Content Type Failed

Scenario: You've published and InfoPath form to a Sharepoint Form Library. You edit the template, save and attempt to publish again and receive the following message - "Updating Content Type Failed"

I've done some researching on this and found a couple of issues. The most common response is that if you remove some columns for your InfoPath List, it will magically work. What I've discovered for this ready why this actually works is because you're falling within the Timeout window. What you're actually doing by removing columns is shrinking the Infopath form from being too large and the web service that is uploading the template is completing inside of 30 seconds.

I don't have a solution for this issue yet, but I am actively working on it. InfoPath is used to capture information and my work around is to reduce the information displayed. That's not accept for me or my business.

I'll post more when I something more concrete. I'm actively exploring optimizing the Infopath form, column types and even increasing the web service timeout to larger than 30 seconds.

UPDATE:

I've found some other work arounds to help with this situation. If you create a new form library, you should not have any issue publishing the form for the first time. You will be able to add all of your columns and publish the complete form. I suspect there is something corrupt with the form library which is causing Infopath to have issues. I'm not sure if it's SharePoint Designer related but I haven't ruled it out.

Separately I've found that most form libraries with issues on publishing form templates, all seem to have multiple files in the library and many different files that are unlinked from the current template. I haven't tested if linking all the files back to the current form template will resolve the issue or not, but it was something I noticed when recreating the form library.


UPDATE #2:

I've done some more investigating and found something interesting. There's not a "hard limit" to the number of columns in a List, but more a limit to the number column types you can have in a list. The interesting part is that there is technically a hard limit on the number of columns and once that limit is reached, MOSS on the back end will create a new row with the same cap. The end user will still continue to see a single giant list.

Here's the breakdown of what you can have in a list can have:
64 Single line of text and Choice (drop-down menu or radio buttons)
31 Multiple lines of text and/or Choice (check boxes (allow multiple sections))
32 Number and currency
32 Hyperlink
16 Date and time
16 Lookup 16 Yes/No
8 Calculated

Note: The number of shared data types are not 64 Single Line of Text and 64 Choice. It's actually 64 total of a combination of either data type.

So we now have a new question:

Does your InfoPath form has more than 199 columns, or has your InfoPath form surpassed the column type limit?