Stuff that could make a difference:

• For Incremental crawls (of regular SharePoint content)
  • Farm architecture
    • Is the indexer (and/or the target server) host separated or doing other tasks?  If it’s doing other tasks, you must take into account the kind of load it’s under and when that load is high and low.
    • Is the database host(s) scaled in a way that running crawls don’t impact user traffic?
    • What’s your “Indexer Performance” level set to?
    • How fast does your indexer crawl?  (i.e. items per hour or items per day)
  • Content
    • How many items are currently (or at the time of go-live) in your index?
    • How frequent does it change?
    • What kind of content is it?  Big pdfs and Word docs?  SharePoint lists and news posts only?
    • What’s the anticipated growth rate of the content?
    • Are there any documented requirements for search freshness?

• For Full crawls (of regular SharePoint content)
  • Pretty much the same stuff as above
  • Can you get away with doing incremental only?  (See this TechNet page in the “Reasons to do a full crawl” section for info about when you must use full crawls instead of incrementals.)

• For profile import
  • Number of exposed profiles
  • Configuration of Mysites and number of mapped properties
  • Can AD handle the load?
  • Is the SSP server doing other roles?
  • Profile freshness requirements

Real life example:

The my current client projecthas pretty fast servers, 14+ million items in index, 40,000 users, and 4 WFEs.  We would be doing incremental crawls only if we can get around a technical issue.  Full crawls take about 4 days. (a bit over 4 million items crawled per day)  Until the problem is fixed, we have been doing full crawls once a week but we really can’t keep it up.  Incremental crawls happen nightly and are most often done before the work day begins. (This is unless users used Explorer View to move or change millions of items the previous day.)

As for profile imports, since MySites are not exposed for all 40,000 users, profile imports happen very fast.  Incrementals happen in under 20 minutes and fulls finish in a couple hours on Sunday mornings.  However, this summer we will expose SP 2010 mysites for all 40,000 users with some fairly moderate custom mappings.  When that happens we will be putting into some serious tuning focus to make sure that it happens efficiently. 

Here and here are some good tuning tips for MOSS… most are probably relevant for SP 2010 also.  Also, the “Inside the Index and Search Engines: Microsoft Office SharePoint Server 2007” book has been pretty helpful.

Technorati Tags: consulting, MOSS, SharePoint, SharePoint Search

Out of the box, MOSS is set to run the profile sync timer job once every hour.  So I ran the following command to show me which content DBs haven’t been synced in the last day:

stsadm.exe -o sync -listolddatabases 1

On my vpc, it looks like this:

This looks helpful except for the fact that nobody knows what the GUID of their content DBs are.  On the client farm there some DBs with very old dates and I could tell something was wrong.  I needed to figure out what the names of the DBs with the old GUIDs are.  The easiest way to do that is to browse to Central Administration and mouse-over your content DBs.  Then you can eyeball the DB GUIDs in the status bar of your browser as it shows you the URL of the hyperlink.  It looks like this:

The GUID of the content DB you are pointing to starts after the “DatabaseID=%7B” in your status bar. Also take note that the “%2D” in the status bar refers to the hyphen character.  Now you know the GUID of that SharePoint Content Database.

I tried going back to the command-line to use stsadm to force it to sync.  To do that I just typed in:

stsadm.exe –o sync

I waited a while and even checked the timer job status in Central Admin and waited for it to say the Profile Sync job had completed successfully.  It turns out that this sync command only forces the “quick” version which does not go through the same job that that is scheduled for every hour.  I was disappointed to see that my content database did not get updated so now I used stsadm to wipe out my profile sync info for the databases with old data.  The following command will delete the profile sync data for databases that haven’t been synced in the last day:

stsadm.exe –o sync –deleteolddatabases

I was feeling good about myself at this point but after double-checking my work I learned that it STILL had not synced.  There was no getting around it, I had to look at the ULS logs.  When I poked around I found a line that kept showing up that alarmed me.  Referring to “SharePoint Portal Server User Profiles” the description portion of the error said something like “Aborting sweepsynch for guid instance {SomeGUID} due to null or non-online content database”.

This sounded familiar to me because I knew we had left some content databases in “offline” mode to prevent them from getting new site collections created in them (they’re already too big).  So when I looked back in Central Administration to see which databases were offline, it turned out to be every one of the ones that weren’t syncing the profiles.

This isn’t documented anywhere but it looks like content databases that are marked as “offline” in central administration will not get synced with profile sync jobs.  Once I turned them all back to “ready”, I had a very looooong running profile sync job after that and it was all clear from there on out.

Technorati Tags: command-line, MOSS, SharePoint, stsadm, WSS

Purpose:

The reason this is important is that some people are convinced that they have to uninstall SharePoint or even completely rebuild their box in order to start from scratch.  This is not so.

NOTE:: 

• This assumes you’ve backed up and kept everything you want to keep.
• The psconfig.exe command is located in the “%WINDIR%\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin” folder.
• this does not remove any custom code or other types of files from the 12 hive
• this procedure will keep the SharePoint patch and service pack level of the host so there’s no need to rerun hotfixes or anything

Procedure:

1. From the host that runs Central Admionistration, run this command psconfig.exe -cmd configdb -disconnect to disconnect Central Admin from your database.
2. Run this command: psconfig.exe -cmd adminvs -unprovision to unprovision the Central Administration site.
3. Delete all application pools and web sites from affected IIS servers.
4. Delete any SQL user databases related to SharePoint e.g. SharedServices*,SharePoint_AdminContent*,SharePoint_Config,WSS_Search

Edit: One thing this process does not account for is if there were any direct changes to existing files in the 12 hive of the SharePoint server. If built-in files (like images or templates) were modified from their original, they will stay the same after you’ve done the above process. In order to restore those modified files, you will need to either copy originals from another installation (risky and unwise) or uninstall/reinstall the SharePoint media from scratch.

Now you’re ready to run the Configuration Wizard just as if you had never set up a farm.

TechNet info on psconfig.exe

“I say we take off and nuke the site from orbit…  It’s the only way to be sure.“

  – Aliens

Technorati Tags: command-line, MOSS, psconfig, SharePoint, stsadm, WSS