SQL Connection string

Example:

Server=;Database=;User Id=;Password=;

DFWP vs XLV web part

Whenever SPD 2010 is used to display data on a page from anywhere outside of SharePoint (XML files, databases, web services), the DFWP displays that data.


The XLV is used for list or library data. However, this web part is unable to allow form functionality, which would let the user manipulate the list data. 

So the DFWP is utilized when a form capability is required for a SharePoint list or library.

Unlike XLV, after DFWP is deployed to the SharePoint page, it can only be customized further using SD2010

Batch file: STSADM backup for MOSS

@SET stsadm="c:\program files\common files\microsoft shared\web server extensions\12\bin\stsadm.exe"

@SET DIR=D:\Backups\

@SET Log=D:\Backups\Backup_VSSR.txt

Echo Backing up- VSSR>>%LOG%

%stsadm% -o backup -url "http://servername/" -filename "%DIR%VSSR.bak" -backupthreads 5 >>%LOG%

time /t >>%LOG%

Pause

è Save as .bat

UNC path

A UNC path describes the location of a volume, directory, or file.

The format for a UNC path is \\server\volume\directory\file and is not case-sensitive. For example:

\\Shared1_svr\Shared1\WGroups\Network\Orders.xls

PowerShell - AD for SP2010

Can't remember where I got this from but it's useful:

When creating SharePoint test environments, one of the prerequisites is to have the necessary SharePoint service accounts. The powershell script below will enable you to create the AD accounts and ready for use when configuring the SharePoint farm. These accounts relate to SharePoint farm configuration, web application pool accounts, service application accounts, search service and content access accounts, user profile synchronisation accounts and object cache accounts. By all means you can modify the values to suit your requirements.

# Get the logged-on user's domain in DN form
$mydom = (get-addomain).distinguishedname

# Specify the OU we want to create the users in
$ouName = "SP Service Accounts"

# Build the full DN of the target OU
$oudn = "OU=$ouname,$mydom"

# Check if the target OU exists. If not, create it.
$OU = get-adorganizationalunit -Filter { name -eq $ouname }
if($OU -eq $null)
{New-ADOrganizationalUnit -Name $OUName -Path $mydom}
else
{write-host "The OU" $ou "already exists."}

# Create users
New-ADUser –Name "SP_Farm" –SamAccountName "SP_Farm" –DisplayName "SP_Farm" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_ServiceApp" –SamAccountName "SP_ServiceApp" –DisplayName "SP_ServiceApp" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_Portal" –SamAccountName "SP_Portal" –DisplayName "SP_Portal" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_MySites" –SamAccountName "SP_MySites" –DisplayName "SP_MySites" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_Search" –SamAccountName "SP_Search" –DisplayName "SP_Search" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_SearchAccess" –SamAccountName "SP_SearchAccess" –DisplayName "SP_SearchAccess" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_UPSync" –SamAccountName "SP_UPSync" –DisplayName "SP_UPSync" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_SuperUser" –SamAccountName "SP_SuperUser" –DisplayName "SP_SuperUser" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru
New-ADUser –Name "SP_SuperReader" –SamAccountName "SP_SuperReader" –DisplayName "SP_SuperReader" `
-Path $oudn –Enabled $true –ChangePasswordAtLogon $false `
-AccountPassword (ConvertTo-SecureString "pass@w0rd" -AsPlainText -force) -PassThru

#End

Optimize SQL FOR SP2010

• Respect software boundaries & limits, review the support article and read the maintenance whitepaper
• Use PowerShell to create your farm, the farm configuration wizard is bad
• Dedicate a SQL instance to SharePoint
• Differentiate between & prioritize your disks: tempdb, logs, search, other
• Align all partitions correctly (1024K)  and format SQL partitions with the right cluster size (64K)
• Test your SQL disks before using them with sqlio
• Only install the features you need (database engine & maintenance tools at minimum)
• Use a domain user for service account
• Enable instant file initialization
• Configure maximum memory
• Fill factor to 80
• MAXDOP to 1
• Consider multiple data files for your content databases
• Tune autogrowth to a fixed number
• Presize your data & log files
• Use SQL aliases to connect SharePoint to SQL
• Check database integrity weekly with dbcc checkdb
• Learn about index fragmentation, how SharePoint deals with it and what you need to do manually
• Don’t shrink databases unless you’re very sure (causes fragmentation)
• Autoshrink is pure evil, never activate it – certainly not with SharePoint
• Learn about the full & simple recovery models and take a look at how logging & recovery works
• In full recovery model you always need to take log backups or your log file will grow indefinitely  – no matter how many full backups you run

MOSS upgrade issue - SPAdmin service cannot start

Cannot start service SPAdmin on Computer

Cannot start service "SPAdmin" on computer after running SharePoint Product and Technologies Wizard

Step 1
On the machine where psconfig failed to start the SPAdmin service run:
%commonprogramfiles%\Microsoft Shared\Web Server Extensions\12\BIN\psconfig -cmd upgrade -inplace b2b -wait -force
Step 2
Modify the service timeout values in the Registry:
HKLM\SYSTEM\CurrentControlSet\Control add/modify DWORD value ServicesPipeTimeout to 60000 (60 seconds)
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control add/modify STRING value WaitToKillServiceTimeout to 120000 (120 seconds)

http://blogs.technet.com/b/wbaer/archive/2007/10/15/kb934525-troubleshooting.aspx

sample SharePoint site quotas

Level 0 = 500MB (Warning 450MB)

Level 1 = 1GB (Warning 900MB)

Level 2 = 2.5GB (Warning 2.4Gb)

Level 3 = 5GB (Warning 4.9Gb)

Level 4 = 7.5 GB (Warning 7.4Gb)

Level 5 = 10GB (Warning 9.75Gb)

How to customize the new,edit and display list forms with InfoPath

·         Open list in SPD

·         List settings à Design forms in IP

·         Design the form and Quick Publish

·         Newifs.aspx, editifs.aspx and displayifs.aspx are created

·         Set defaults

Advantages of doing creating list forms with IP:

·         Add validation

·         Add conditional formatting

·         Can surface IP forms on any SP page using IP web part

SHAREPOINT INDEXING PERFORMANCE TUNING TIPS

Introduction

This document is intended to highlight possible causes of poor indexing performance on SharePoint 2007 farms as well as provide some options/recommendations for further tuning

Overview

Crawl Architecture

Content Host - This is the server that hosts/stores the content that the indexer is crawling. For example, if a content source crawls a SharePoint site, the content host would be the web front end server that hosts the site.

MSDMN.EXE - When a crawl is running, this process is visible in the task manager on the indexer. This process is called the "Search Daemon”. When a crawl is started, this process is responsible for connecting to the content host (using the protocol handler and I-Filter), requesting content from the content host and crawling the content. The Search Daemon has the biggest impact on the indexer in terms of resource utilization.

MSSearch.exe - Once the MSDMN.EXE process is done crawling the content, it passes the crawled content on to MSSearch.exe (this process also runs on the indexer, visible in the task manager during a crawl). MSSearch.exe does two things. It writes the crawled content on to the disk of the indexer and it also passes the metadata properties of documents that are discovered during the crawl to the backend database. Unlike the crawled content index, which gets stored on the physical disk of the indexer, crawled metadata properties are stored in the database.

SQL Server (Search Database) - The search database stores information such as information about the current status of the crawls, metadata properties of documents/list items that are discovered during the crawl

There are a number of reasons why crawls could be taking longer than expected.

The "Content Host" is responding slowly to the indexer's requests for content

The indexer has to request content from the content host to crawl the content. If the host is responding slowly, no matter how strong the indexer is, the crawl will run slow.
Collect performance counter data from the indexer. Performance data should be collected for at least 10% of estimated crawl duration.
Monitor the following performance counters:

·    \\Office Server Search Gatherer\ Threads Accessing Network

·    \\Office Server Search Gatherer\ Idle Threads

The "Threads Accessing Network" counter shows the number of threads on the indexer that are waiting on the content host to return the requested content. A consistently high value of this counter indicates that the crawl is starved by a "hungry host".

The database server is too busy and is slow in responding

The indexer also uses the database during the indexing process. If the database server becomes too slow to respond, crawl durations will suffer. To see if the crawl is starved by a slow or busy database server use the following performance counters

·    \\Office Server Search Archival Plugin\Active Docs in First Queue

·    \\Office Server Search Archival Plugin\Active Docs in Second Queue

Once MSDMN.EXE is done crawling content, it passes this to MSSearch.exe, which then writes the index on disk and inserts the metadata properties into the database.

MSSearch.exe queues all the documents whose metadata properties need to be inserted into the database.

Consistently high values of these two counters will indicate that MSSearch.exe has requested the metadata properties to be inserted into the database, but the requests are just sitting in the queue because the database is too busy. Ideally, you see the number of documents in first queue increasing and then dropping to 0 at regular intervals of time (every few minutes)

TuningTuningIf there are consistently high values of the above mentioned two performance counters and if the database server is dedicated to MOSS - consider optimization at the application level such as blob cache

There is a hardware bottleneck

On the indexer monitor the performance counter \\Process\%Processor Time (msdmn.exe the selected instance). 
If msdmn.exe consistently at high CPU utilization, consider changing the indexer performance from "Maximum" to "Partially Reduced"  If there are other bottlenecks (memory, disk etc.), analyze performance data to get to a conclusion. This article explains how you can determine potential bottlenecks on your server

SQL bottlenecks:

Number of connections

See Central Administration > Operations > Services on Server > Office SharePoint Server Search Service Settings

Start with a crawler impact rule to “request 64 documents at a time” in order to maximize the number of threads the crawler can use to index content, with the ultimate goal of increasing the crawl speed.

Resources usage on the indexer, dedicated front-end and search database boxes should be monitored, and in case the crawler generates too much activity, the crawler impact rule should be tuned by decreasing the parallelism.

·         Reduced: Total number of threads = number of processors, Max Threads/host = number of processors

·         PartlyReduced: Total number of threads = 4 times the number of processors , Max Threads/host = 16 times the number of processors

·         Maximum: Total number of threads = 4 times the number of processors , Max Threads/host = 16 times the number of processors (threads are created at HIGH priority)

NOTE: It is a good idea to open Perfmon and look at the gatherer stats while indexing. There is a statistic called Performance Level and this reflects the actual level that the indexer is running at where 5 = max and 3 = reduced. Even if you set everything to max the indexer may decide to run at reduced

Fine tune the gatherer

An aspect of the crawling process is then the filtering daemons use up to much memory (mssdmn.exe) they get automatically terminated and restarted. There is of course a windup time when this happens and can slow down your crawling. The default setting is pretty low (around 100M) so is easy to trip when filter large files. You can and should increase the memory allocation by adjusting the following registry keys (this will require a service restart for the changes to take effect).

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager

·         FolderHighPriority: Represents the number of high priority folders that can be processed at one time.  If this is too high then the cache in the daemons will constantly be running out of space.  If this is too low then the crawl will be throttled waiting for more items to process.

·         FilterProcessMemoryQuota: Represents how much memory can be consumed by the search daemon process before it gets killed by the crawler. The OOB default has been chosen based on 4 GB of memory on the indexer. If the customer has higher RAM, they can increase this value to cache more data during the crawl.

·         DedicatedFilterProcessMemoryQuota: Same as for FilterProcessMemoryQuota except this is the size of the single-threaded daemons.

As an example, if the indexer box is 64-bit with 16 GB of RAM, the following values have been tested successfully:

FolderHighPriority: set to 500

FilterProcessMemoryQuota: set to 208857600

DedicatedFilterProcessMemoryQuota: set to 208857600

Configure multiple Content sources

Review the information architecture of the content to be indexed.

Identify one subset of content where most of the changes happen (“fresh” content), and another subset that is mostly static (archived or older content).

Configuring more than one content source to target the “fresh” content areas separately from the “static” areas will provide more flexibility for crawl scheduling.

Multiple content sources will also mitigate the impact of a long running operation of the crawler (like a full crawl) in terms of latency for fresh content to appear in search results, - can selectively activate the crawling on the desired content sources only, postponing less important crawling activities to off-peak hours, etc

Overlapping Crawls

SharePoint gives priority to the first running crawl so that if you already are indexing one system it will hold up the indexing of a second and increase crawl times.

• Solution: Schedule your crawl times so there is no overlap. Full crawls will take the longest so run those exclusively.

PDF I-Filter Issues

The Adobe PDF I-Filter can only filter one file at a time and that will slow crawls down, and has a high reject rate for new PDFs

• Solution: Use a retail PDF filter e.g. Foxit

Bad File Retries

There is a setting in the registry that controls the number of times a file is retried on error. This will severely slow down incremental crawls as the default is 100. This retry count can be adjusted by this key:

• HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office Server\12.0\Search\Global\Gathering Manager: set DeleteOnErrorInterval = 4 Decimal

General Architecture Issues

Ensure that you have at least 2 Gig of free memory available before your crawl even starts and that you have at least 2 real processors available.

If you execute a full crawl that overlaps with normal business hours it could have an adverse effect on SharePoint users if the crawl server is used for other services such as query or WFE roles. Central Admin on the app server will be impacted and if the query role wasn't moved to the WFE's then the search center results page will also perform badly during crawl operations (even an incremental crawl could have this impact if a lot of content had changed since the last crawl).
Run 64bit OS

Configure BLOB caching

http://www.directsharepoint.com/2012/03/configure-blob-cache-for-sharepoint.html

Review the AV policy

You should exclude certain folders from being scanned. If you do not exclude these folders, you can experience many unexpected issues

Folders that may have to be excluded from antivirus scanning for SharePoint Server 2007

http://support.microsoft.com/kb/952167?wa=wsignin1.0#appliesto

You may have to configure the antivirus software to exclude the "Drive:\Program Files\Microsoft Office Servers" folder from antivirus scanning for SharePoint Server 2007. If you do not want to exclude the whole "Microsoft Office Servers" folder from antivirus scanning, you can exclude only the following folders:

·         Drive:\Program Files\Microsoft Office Servers\12.0\Data. (This folder is used for the indexing process. If the Index files are configured to reside in a different folder, you also have to exclude that location.)

·         Drive:\Program Files\Microsoft Office Servers\12.0\Logs

·         Drive:\Program Files\Microsoft Office Servers\12.0\Bin

·         Any location you choose to store Disk-based BLOB cache. For example: C:\blobcache. For more information on BLOB cache, see: http://office.microsoft.com/en-us/sharepoint-server-help/configure-disk-based-cache-settings-HA010176284.aspx

(http://office.microsoft.com/en-us/sharepoint-server-help/configure-disk-based-cache-settings-HA010176284.aspx)

Note If you have Microsoft Office SharePoint Server 2007, these folders should be excluded in addition to the folders listed in the WSS 3.0 section below

Note  When you install SharePoint Server 2007 or when you apply a hotfix to an existing installation of SharePoint Server 2007, you may have to disable the real-time option of the antivirus program. Or, you may have to exclude the Drive:\Windows\Temp folder from antivirus scanning if it is required.

Folders that may have to be excluded from antivirus scanning for Windows SharePoint Services 3.0

You may have to configure the antivirus software to exclude the following folders and subfolders from antivirus scanning.

Note The Drive placeholder represents the drive letter in which you have installed Windows SharePoint Services 3.0 or SharePoint Server 2007. Typically, this drive letter is C.

·         Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions

If you do not want to exclude the whole "Web Server Extensions" folder from antivirus scanning, you can exclude only the following two folders:

o    Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Logs

o    Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Data\Applications

Note The Applications folder must be excluded only if the computer is running the Windows SharePoint Services Search service. If the folder that contains the index file is located in some other location, you must also exclude that folder.

·         Drive:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files

Note If you are running a 64-bit version of Windows, you should also include the following directory:

o    Drive:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files

·         Drive:\Documents and Settings\All Users\Application Data\Microsoft\SharePoint\Config

·         Drive:\Windows\Temp\WebTempDir

Note The WebTempDir folder is a replacement for the FrontPageTempDir folder.

·         Drive\Documents and Settings\the account that the search service is running as\Local Settings\Temp\

·         With 64Bit 2008 Server and Product Version this will be Drive\Users\the account the search service is running as\Local\Temp\

Note The search account creates a folder in the "gthrsvc Temp" folder to which it periodically needs to write.

·         Drive:\WINDOWS\system32\LogFiles

·         With 64 Bit 2008 Server and Product Version this will be Drive:\Windows\Syswow64\LogFiles

Note If you use a specific account for SharePoint services or application pools identities, you may also have to exclude the following folders:

o    Drive:\Documents and Settings\ServiceAccount\Local Settings\Application Data

o    With 64 Bit 2008 Server and Product Version this will be Drive:\Users\ServiceAccount\Local

o    Drive:\Documents and Settings\ServiceAccount\Local Settings\Temp

o    With 64 Bit 2008 Server and Product Version this will be Drive:\Users\ServiceAccount\Local\Temp

·         Drive:\Documents and Settings\Default User\Local Settings\Temp

·         With 64 Bit 2008 Server and Product Version this will be Drive:\Users\Default\AppData\Local\Temp

SQL Server configuration

Plan the SQL Server configuration in order to scale to large numbers of items in the index (5m+).

Partition on dedicated separate arrays and assign 1-1 for:

o   Indexes for SharedServices1_search db

o   Temp and system databases/tables

o   transaction log for SharedServices1_search db

o   Table content for SharedServices1_search 

Split the Search database tables on two different filegroups

Host the corresponding files on different sets of disks, to keep the crawl and query loads segregated and minimize I/O contention.

See details in “SQL File groups and Search” on the Enterprise Search blog at http://blogs.msdn.com/enterprisesearch/archive/2008/09/16/sql-file-groups-and-search.aspx.

Note however that it makes no sense to split the tables if you are not able to physically host the two filegroups on different sets of disks.

Schedule regular defragmentation of the Search database.

The following query can be used on SQL Server 2005 or higher to obtain all the indexes with a fragmentation level higher than 10%:

USE

DECLARE @currentDdbId int

SELECT @currentDdbId = DB_ID()

SELECT DISTINCT

      i.name,

st.avg_fragmentation_in_percent

FROM sys.dm_db_index_physical_stats (@currentDdbId, NULL, NULL , NULL, 'SAMPLED') st

INNER JOIN sys.indexes AS i

ON st.object_id = i.object_id

WHERE st.avg_fragmentation_in_percent > 10

Indexes resulting from the above query should be defragmented.

Rebuild the indexes on the SharedSevice1_search_db database - especially the indexes on MSSDocProps table

See also “Database Maintenance for Microsoft SharePoint Products and Technologies” at http://go.microsoft.com/fwlink/?LinkId=111531&clcid=0x409 and “SQL Index defrag and maintenance tasks for Search” on the Enterprise Search Blog at http://blogs.msdn.com/enterprisesearch/archive/2008/09/02/sql-index-defrag-and-maintenance-tasks-for-search.aspx.

Configure the appropriate SQL Maintenance Plans

SQL Server maintenance plans should be configured with the following guidelines:

Search Database

·         Check Database integrity using the ‘DBCC CHECKDB WITH PHYSICAL_ONLY’ syntax to reduce the overhead of the command. This should be run on a weekly basis during off-peak hours. Any error returned from DBCC should be analyzed and solved proactively. The full ‘DBCC CHECKDB’ command should be ran with a lower frequency (e.g. once per month) to provide deeper analysis.

·         Do not shrink the Search database.

·         Index defragmentation should be executed following the recommendation above.

Content Databases

·         Check Database Integrity

·         Include indexes

·         Shrink Database

·         Shrink database when it goes beyond: maximum expected size of your content database + 20%

·         Amount of free space to remain after shrink: 10%

·         Return freed space to operating system

·         Reorganize Index

·         Compact large objects

·         Change free space per page percentage to: 70%

·         Maintenance Cleanup Task

See also “Database Maintenance for Microsoft SharePoint Products and Technologies” at http://go.microsoft.com/fwlink/?LinkId=111531&clcid=0x409 and “SQL Index defrag and maintenance tasks for Search” on the Enterprise Search Blog at http://blogs.msdn.com/enterprisesearch/archive/2008/09/02/sql-index-defrag-and-maintenance-tasks-for-search.aspx.

Pre-size databases

Avoid the auto-growth behavior for content databases by pre-setting the size to the maximum expected size (ALTER DATABASE … MODIFY FILE … SIZE property). Configure the autogrowth values to a fixed percentage (e.g. 10%) instead of a fixed space.

Conclusion

Establish a baseline for crawl performance. Schedule crawls such that the number of crawls running at the same time does not exceed the "healthy baseline".
To maintain an enterprise environment where SharePoint is a business critical application, the correct hardware needs to be in place

Links

http://blogs.msdn.com/b/tehnoonr/archive/2009/09/12/moss-2007-long-running-search-crawls.aspx

http://technet.microsoft.com/en-us/library/cc262574.aspx (Estimate performance and capacity requirements for search environments)

http://technet.microsoft.com/en-us/library/cc850696.aspx (Best practices for Search in Office SharePoint Server)

http://technet.microsoft.com/en-us/library/cc298801.aspx 

http://blogs.msdn.com/b/agazzeri/archive/2009/04/16/sharepoint-server-2007-10-suggestions-for-a-reliable-low-latency-search-deployment.aspx

http://technet.microsoft.com/en-us/library/cc261720.aspx

http://blogs.msdn.com/enterprisesearch/archive/2008/05/09/creating-crawl-schedules-and-starvation-how-to-detect-it-and-minimize-it.aspx

Appendix – When to do a Full Crawl

Reasons to do a full crawl

Reasons for a search services administrator to do a full crawl include:

·      One or more hotfix or service pack was installed on servers in the farm. See the instructions for the hotfix or service pack for more information.

·      An SSP administrator added a new managed property.

·      To re-index ASPX pages on Windows SharePoint Services 3.0 or Office SharePoint Server 2007 sites.

Note:

The crawler cannot discover when ASPX pages on Windows SharePoint Services 3.0 or Office SharePoint Server 2007 sites have changed. Because of this, incremental crawls do not re-index views or home pages when individual list items are deleted. We recommend that you periodically do full crawls of sites that contain ASPX files to ensure that these pages are re-indexed.

·      To detect security changes that were made on a file share after the last full crawl of the file share.

·      To resolve consecutive incremental crawl failures. In rare cases, if an incremental crawl fails one hundred consecutive times at any level in a repository, the index server removes the affected content from the index.

·      Crawl rules have been added, deleted, or modified.

·      To repair a corrupted index.

·      The search services administrator has created one or more server name mappings.

·      The account assigned to the default content access account or crawl rule has changed.

The system does a full crawl even when an incremental crawl is requested under the following circumstances:

·      An SSP administrator stopped the previous crawl.

·      A content database was restored from backup.

Note:

If you are running the Infrastructure Update for Microsoft Office Servers, you can use the restore operation of the stsadm command-line tool to change whether a content database restore causes a full crawl.

·      A farm administrator has detached and reattached a content database.

·      A full crawl of the site has never been done.

·      The change log does not contain entries for the addresses that are being crawled. Without entries in the change log for the items being crawled, incremental crawls cannot occur.

·      The account assigned to the default content access account or crawl rule has changed.

·      To repair a corrupted index.

Depending upon the severity of the corruption, the system might attempt to perform a full crawl if corruption is detected in the index