To transition a portal that uses Site Server 3 for searching to SharePoint Portal Server, ITG modified the URL on the page where users perform search queries to point to the SharePoint Portal Server computer dedicated to searching. For example:
First, the team modified the URL for searching on the primary corporate portal, MSWeb, to point to the SharePoint Portal Server computer. As expected, the load immediately increased from a few thousand queries per week to nearly 30,000 per day.
Next, the team modified the URL for searching on the Product Group Portal to point to the SharePoint Portal Server computer. This portal used the dashboard site included with SharePoint Portal Server for searching, instead of a custom ASP page. The team simply added a new Web Part to the search dashboard. This site handles about 2,000 searches per month.
The team continued this process for each of the major business portals across the corporate intranet. In addition to completing the transition to SharePoint Portal Server, ITG must continue to monitor performance for SharePoint Portal Server and to implement a disaster recovery plan that is compatible with SharePoint Portal Server. The next section reviews these steps.
Through effective monitoring, ITG has determined that this deployment meets performance expectations. ITG also captures monitoring data for trend analysis to predict future problems and fine-tune alert thresholds.
Although separate administration is possible, ITG administers Windows 2000 and SharePoint Portal Server together.
Server activity for SharePoint Portal Server generates performance data that Windows 2000 can track and log on the system. The data is described as a performance object and is typically named for the component generating the data. Every performance object provides counters that represent data on specific aspects of the object. ITG monitors standard Windows 2000 Advanced Server performance objects, along with several specific objects for SharePoint Portal Server. For example, to monitor MSSearch, select the performance object called Microsoft Gatherer and the Heartbeats counter.
The performance objects to monitor for enterprise search include:
The following table describes the counters that ITG routinely monitors.
Table 27.14 Monitoring Performance Objects
Performance object | Counter | Explanation |
---|---|---|
Microsoft Gatherer | Documents Filtered (and Rate) | Number of documents attempted to be crawled since the service started. |
| Documents Successfully Filtered (and Rate) | Number of documents successfully crawled since the service started. |
| Documents Delayed Retry | Non-0 means the Microsoft Web Storage System is having problems; by default, retries until cleared. |
| Reason to Back off | Non-0 means crawling is paused, because of high disk I/O, low memory, etc. |
| Server objects | Number of servers crawled. |
| Time outs | Too high means network |
|
| problems. |
| Adaptive Crawl Accepts | Documents accepted by |
|
| adaptive update. |
| Adaptive Crawl Error Samples | Documents accessed for error sampling. |
| Adaptive Crawl Errors | Documents that adaptive update incorrectly rejects. |
| Adaptive Crawl Excludes | Documents that adaptive update excludes. |
| Adaptive Crawl False Positives | Number of false positives that occur when the adaptive update has predicted that a document has changed when it has not. If this number is high, the adaptive update algorithm is not modeling the changes in the documents correctly. |
| Adaptive Crawl Total | Documents to which adaptive update logic was applied. |
Microsoft Gatherer Projects | Crawls In progress | Number of concurrent crawls. |
| Status Success (and Rate) | Number of documents successfully filtered for this workspace. |
| Status Error | Number of errors. |
| URLs in History | Number of URLs covered in all crawls. |
| Waiting Documents | Gatherer queue length—0 means idle. |
Microsoft Search | Failed Queries | Number of failed queries. |
| Successful Queries (and Rate) | Number of successful queries. |
Microsoft Search Indexer Catalogs | Merge progress 0- 100% | Non-100 means indexes are currently being merged—crawl can be paused during that time. |
| Number of Documents | Number of documents in the catalog included in the index. |
| Index Size | Size of the index in megabytes |
The backup and restore process represents the only substantial change in the operation of SharePoint Portal Server over Site Server 3. SharePoint Portal Server provides a built-in script for backing up the entire server with all the workspace and catalog information to an image file. You can then restore this image on another server.
ITG uses the MSDMBACK utility installed with SharePoint Portal Server to copy the backup files to disk each night, and then uses Windows 2000 Backup to back up those files to tape.
This output from MSDMBACK must be saved to a local drive.
Because Windows 2000 Backup attempts to lock the files while backing up, which prevents crawls from continuing, servers that host index workspaces must be set to exclude the following directory from the Windows 2000 backup:
operating_system_drive\Program Files\SharePoint Portal Server\Data\FTData\SharepointPortalServer
The MSDMBACK utility takes a snapshot of all necessary SharePoint Portal Server data directories as part of its backup.
Each night, ITG runs the backup process on each server that hosts an index workspace and the enterprise portal server. MSDMBACK is run, backing up the data to another partition according to the following steps:
cscript msdmback.vbs /b "path_to_backup_file_name"
where the path_to_backup_file_name parameter is the name of the backup file to be created.
The script/schedule task must be run under the context of an account that has administrator privileges on each server.
It is important to note that the backup process stores passwords for content sources in encrypted form in the backup image. The optional password used for the backup image (provided during backup) encrypts only the passwords. Use of the optional password does not encrypt the remainder of the backup image, including the documents and metadata. If the administrator loses the password that was used to create the backup image, and attempts to restore, the restoration succeeds, but the restored information for the content source access account is invalid. In addition, subsequent crawls of this content source may fail because of authentication failures.
The backup process also stores user name and password pairs that are used for content sources in encrypted registry files. The optional password provided during restoration decrypts only the user name and password pairs. If the administrator loses the password that was used to create the backup image, and then tries to restore the image, the restoration succeeds but leaves the user name and password pairs for content sources blank.
Organizations that want to make the transition from Site Server 3 to SharePoint Portal Server may find the approach taken by Microsoft's ITG group (outlined in the following list) to be helpful: