Viewpoint : Troubleshooting

SharePoint 2007 Search Administration: Scheduling and the UI

Jeremy Williams — Fri, 19 Feb 2010 17:40:00 GMT

As an SSP administrator, one can control and tweak the many aspects of SharePoint Search. One piece of the puzzle an admin can configure is a content source. For the uninitiated, a content source is simply a location where SharePoint Search is going to go out and look for files. Some examples of content sources could be all of your SharePoint sites, a file share, or even your public website. When configuring a content source, an administrator must choose how often that source will be crawled.

There are two types of crawls, a full crawl and an incremental crawl. While there is an (almost) infinite number of schedules one could set up for their content source, I often see a full crawl happening relatively infrequently (once a week or month, depending on content size), and incremental crawls happening quite frequently (every 5-60 minutes). Why? Let’s say a user uploads a file to SharePoint and tells their buddy, “Hey, I just uploaded the document about Client ABC to SharePoint, go check it out!” Their buddy (since he doesn’t know where the file is located) goes right to his trusty SharePoint search box and searches for “Client ABC”. If an incremental crawl hasn’t run since the file was uploaded, then it won’t appear in the results. This in turn makes for frustrated users, and an all around ‘bad’ SharePoint experience [but alas, I digress..]

Back to the point, when scheduling an incremental crawl, here’s a fairly typical starting point (picture below):

Everything seems to make sense in there, except for the last two text boxes. One way to interpret that section is, “Repeat the incremental crawl every 15 minutes and allow it to run for 1440 minutes”. Based on this interpretation, one may be lead to believe that an incremental crawl could start and run as long as 1440 minutes (that’s 1 full day). Well, as an SSP admin, I would hate for there to (potentially) be 1 crawl each day, so I’m going to change that 1440 to 20. Great, I’ve got crawl set up and my users should always be able to find their files (relatively) quickly, right?

Sadly, the answer is No. That text is actually interpreted as, “Repeat the incremental crawl every 15 minutes, and continue crawling every 15 minutes for 1440 minutes.” So, in my example above, the text becomes, “Repeat the incremental crawl every 15 minutes continue crawling every 15 minutes for 20 minutes.” This will yield you exactly 2 incremental crawls everyday, one around midnight, and the other around 12:15…After that, you’ll have to wait until midnight rolls around again.

For some users, this might have been a “duh” type of post because they interpreted the text and control in the manner Microsoft intended. However, other users may have incorrectly interpreted the text/controls as my example pointed out…

MySites and Quotas: The Nuances

Jeremy Williams — Tue, 16 Feb 2010 17:15:00 GMT

Site Quotas in SharePoint 2007 are a great tool, but they can sometimes be misunderstood. One of the most common confusions with quotas comes with their interaction with MySites. MySites (IMHO) are a great feature of SharePoint 2007, and are only getting better in SharePoint 2010. However, the adoption of MySites in many organizations is organic and unplanned. Right around the time that MySites near critical mass, the desire to wrap some additional governance around the sites crops up. Arguably, one of the most obvious governance tools for MySites is a Site Quota. So the governance committee decides on some thresholds and passes the implementation down to their Farm Administrators…

Let’s put on our ‘Farm Administrator’ hat…

I need to enforce a Personal Site quota on my users, so I’ll just set up the thresholds on the Personal Site quota template, and apply that to MySites. After that, everyone now has that quota, right? Wrong!

Okay, so that didn’t work and now I’m getting yelled at because users are uploading their personal photo and music collections to their MySites, thereby eating up all the space on our SAN. Since editing the quota template didn’t do the trick, let’s go ahead and create a new template and apply that to MySites. Alright, now everyone has that quota right? Wrong Again! [Aside: Remember, you can always block certain file extensions from ever being uploaded to SharePoint in Central Administration.]

Darn it SharePoint, you’re really raining on my parade, what am I doing wrong?!?!

Like many really annoying problems, this boils down to semantics…Quotas are called ‘Quota Templates’ for a reason, they are a template, and act just like a site template would. After applying a template, if I make a change to the template, all new sites using the template will take the new values; but the old sites will remain static. Here’s a laundry list of nuances, and a quick demo/proof of this behavior:

To reliably change the quotas of MySites, don’t create a new template, you’ll just want to edit the Personal Site Template. I’m not saying that you can’t create your own templates, but why work harder if you can work smarter?
Quotas act like site templates; they’re a snapshot…So if I make site A when personal site quota = 10/8; then I change the quota to 50/40 and create site B, site B quota = 50/40, site A quota = 10/8
Don’t always rely on Central Admin to tell you the truth about site quotas and what a particular collection’s quota is; instead use the stsadm –o enumsites command. Screen-cap below:

- Administrator was a manually set quota
- Test1 was using the initial Personal Site Template Quota
- Then I changed the Personal Site Template Quota, did an iisreset for good measure, and made test2’s MySite.
- So Test 1 and Test 2 used the same template, however they have different values since the template was different during each site’s respective build-time.

At the end of the day, the best approach is to properly plan for MySites and enact a reasonable quota template right from the beginning. If that isn’t an option, you can customize (or search for other’s customizations/extension) stsadm.exe to iterate through MySites and manually apply your new template.

Fixing SharePoint Search that is down due to error 1000

Jeremy Williams — Wed, 13 Jan 2010 20:53:00 GMT

Situation: A SharePoint server experienced some really nasty search errors (error #1000, 5214, 6398, 6482, 7888, 10036). The most annoying of all these (and one I hadn’t seen before was the error 1000, shown below). A quick internet search turns up a number of blog posts and threads regarding general SharePoint search troubleshooting (ranging in recommendations from the classic multi-threaded IIS issue w/available hotfix, to full-blown SharePoint reinstall). At the end of it all, it seems that a hybrid approach helped me to solve the issue.

[Screenshot clipped to protect the innocent (servers)J].

Solution (In the form of those old pick-your-own adventure books): The short of it is that SharePoint was pretty busted up by search; and I’m (unfortunately) still unsure what caused it to blow up. As always, before you start really messing with Central Administration, be sure that you have a good SQL backup of your SharePoint content. I cannot stress this enough, if you don’t have a backup, you’re asking for trouble. Alright, now that the necessary disclaimer is out of the way, the solution involved the following steps:

1. Ensure your install user account has full access to SQL (takes some permission issues out of the equation).

2. Attempt to stop then restart Office SharePoint Server search (net stop osearch, net stop osearch in a command prompt).

a. Did that fix the issue? If yes, go out and buy a ‘That was easy!’ button

b. If it didn’t fix it, Continue to 3 (Unless you’ve been here already, then go to 5).

3. Restart the SharePoint Server box/boxes; if you’re really paranoid, you’d want to restart SQL too.

4. Repeat step 2.

5. Okay, things are bad, but there’s still hope. Read On!

6. Run the SharePoint Configuration wizard; leave the farm attached. (Basically, we just want SharePoint to ‘repair’ any of its configurations that may have been corrupted). When the configuration wizard finishes, run an iisrest for good measure.

a. Did that fix the issue? If yes, be thankful you aren’t like the other guys having to read on...

b. If that didn’t fix it, don’t give up yet; there are still a few more things we can try, read on to 7.

7. Wow, SharePoint is really broken here. Before we bring out the big guns, let’s try running that configuration wizard again. This time, you’re going to detach your server from the farm. You will lose all of your configuration settings, so before you click the ‘Destroy’ button, be sure you’re comfortable rebuilding SharePoint’s configuration. Detach SharePoint from the farm and restart your MOSS box. Once the server comes back up, you’ll want to run the Configuration Wizard again (it will look just like a new SharePoint install). Remember, all your old configuration databases are still on SQL’s file system, so you’ll either have to remove/rename the old files or rename your new configuration databases.

a. Once you get a new SSP spun up, does search work? If yes, see 8a.

b. Didn’t work? Let’s go for broke in step 8.

8. You’re going to repair your SharePoint installation now. Detach SharePoint from the farm again (instructions in step 7, but don’t reattach this time). Go to Control PanelàAdd/Remove Programs (<=Server 2003) OR Programs and Features (>=Server 2008). Find the SharePoint line item and select the ‘Repair’ option. This is (effectively) going to reinstall your SharePoint bits and bytes. Once the repair has finished, go ahead and reattach and reattach your farm’s major content databases. Set up the new SSP and verify that SharePoint search is now functioning.

a. If yes, I recommend a congratulatory beverage.

b. Still nothing? Check out the ‘Things to look for…Antivirus’ below.

Things to look for…Antivirus

If these steps still don’t fix search, take a look at the antivirus running on your SharePoint box. Certain AV products don’t ‘play nice’ with SharePoint, especially if the AV product isnt’ specifically designed for servers like SharePoint. If you happen to discover some antivirus that isn’t SharePoint specific, see this Microsoft article for paths that you should exclude from the A/V scan: http://support.microsoft.com/kb/952167

Once you’ve done that, try a restart and go through the troubleshooting steps again.