Some of the main topics in this chapter are

• Index Server overview
  
  
• Creating a query
  
  
• Index Server architecture and administration
  
  
• Content Replication System (CRS) overview
  
  
• CRS network architecture
  
  
• CRS maintenance

This chapter introduces you to two relatively new members of the Microsoft BackOffice family. Index Server works hand-in-hand with Internet Information Server (IIS) by building indexes of the content published by IIS. Queries, both simple and advanced, can then be created by simply filling out a form with your Web browser. IIS processes the contents of the form, searches for matching content. The results are sorted, formatted, and returned to the user.

The Content Replication System (CRS) provides an important capability: copying Web content from one server to another. There are many reasons why this is necessary in a typical corporate intranet or professional Web site. These reasons are outlined, and the features that CRS provides are explored. In addition, this chapter provides the key planning concepts and network architecture of CRS. The procedures for testing, monitoring, and maintaining CRS are also provided.

An Index Server Overview

Index Server provides content indexing for both IIS and Peer Web Services (PWS), the Web server component provided by Windows NT Workstation. After it has been installed and configured, it will automatically maintain up-to-date indexes of the content that is stored on a Web server. Index Server is largely self maintaining. There are no complicated maintenance procedures, and the product is designed to run unattended 24 hours a day, seven days a week. As new content is added to the Web server, it automatically updates its indexes in an incremental fashion by incorporating any new entries required without having to reindex all content on the Web server.

Index Server will not index only Hypertext Markup Language (HTML) Web pages but also documents created with Microsoft Office products. It is capable of "seeing" the contents of the following types of documents:

• Microsoft Word
  
  
• Microsoft Excel
  
  
• Microsoft PowerPoint
  
  
• HTML
  
  
• Plain (ASCII) text

In addition, it will index binary files based on their ActiveX properties, but, of course, it cannot scan the contents of such files. Other document types can be indexed by creating custom document filters, but the standard filters included with the product do not support them.

The resulting index that is created is based not only on keywords in the text but also on the Microsoft Office properties (summary and custom) or ActiveX properties of the file or document. All Microsoft Office document formats include a number of standard properties, such as Title, Subject, Author, Category, and Keywords. In general, the properties of a Microsoft Office document can be viewed by selecting File, Properties. In addition to the standard properties for a document, users can add custom properties.

Several sample query forms are provided that can be used to search for content that contains a particular keyword or phrase. This sample query shows only the most rudimentary form of searching that is available. Custom query forms can be created that make it easy for users to formulate complex queries. These queries can perform searches by using document properties, including custom properties tailored to specific applications, if desired.

Index Server Architecture

Index Server is designed to run virtually maintenance free. Unless you need to create filters for custom document types, you might never need to worry about the underlying processes that make this product work. At some time, however, something might go wrong that requires troubleshooting, and an understanding of the way indexes are created and queries are resolved can be useful. In addition, you might simply be curious about how content and property-based indexing is accomplished. An overview is presented here with additional details provided in the following sections. Some details are suppressed for clarity. See the product documentation for full details on all processes.

The process begins when a document is added to an indexed directory on a server. A scanning process recognizes that a new file has been added and invokes another process called CiDaemon. The document is analyzed and then filtered by using an appropriate filter dynamic-link library (DLL) and a word-breaker DLL. (Index Server handles multiple languages and uses different language-dependent rules to determine what to index.) The filtering process identifies keywords and properties extracted out of the document and added to the random-access memory (RAM) resident word lists. These word lists are subsequently incorporated into shadow indexes, which are eventually incorporated into the master index.

At some time, a user will open a query form and submit a query to the Index Server engine. The query is processed by using information from the query form and a special type of file called an Internet data query file (which carries an .idq extension). The query is processed, and the returned results are formatted as a Hypertext Markup Language (HTML) page with the aid of another type of file called an HTML extension file (.htx file). The results are presented to the user's Web browser for display.

By creating custom query forms or custom .idq and .htx files, the query process and the format of the results can be tailored to suit particular needs. The default forms and files are suitable for general purpose indexing and reporting.

Queries

Anyone who has spent time "surfing" the World Wide Web has probably had an opportunity to use one of the search engines. These professionally run sites provide sophisticated searching capabilities based on the same type of indexing possible with Index Server. Search engines, such as Yahoo!, Lycos, WebCrawler, and AltaVista, provide content indexes at thousands of Web sites on the Internet. Often, after a Web site is found with one of these large search engines, you still need to find a particular page or document of interest.

Web sites that have a local search engine capability make it much easier to find exactly the subject matter you are after. You can use Index Server to provide such a search capability for both public Web sites and intranet sites that you manage. As the amount of subject matter that you include in your site grows, this capability will quickly become a necessity rather than a nice extra feature.

If you have used a public search engine or have other database experience, you already have a good idea what queries are all about. Information is entered into a form specifying what you are interested in finding. This form is then submitted to the Index Server engine for processing. The queries must be expressed in a query language that has many powerful features. Index Server's query language supports the following capabilities:

• Boolean operators (AND, OR, and NOT) can be used. For example, robot AND human finds documents with both words; robot OR human finds documents with either word.
  
  
• The proximity operator (NEAR) can be used to specify that two search items must appear in the same area of the document. For example, fiscal NEAR responsibility should find documents that address fiscal responsibility, even if the explicit phrase does not appear in the document.
  
  
• Queries are case-insensitive. For example, Robot, ROBOT, and robot are all treated the same in a query.
  
  
• The wild card (*) can be used to match a variable number of arbitrary characters at the end of a word. For example, pre* matches prehistoric, prefix, preparation, prevention, and all other words beginning with pre. (This is an example of a query that probably needs to be refined to be useful.)
  
  
• An additional wild card operator (**) will find words based on the same stem word. For example, write** will match write, wrote, written, and writing. Note that although most of these words would match writ* (using the standard wild card), wrote would not. This operator is useful for matching words that change form as tense changes (fall versus fell, for example) and other similar situations that confound matching with the standard wild card.
  
  
• Punctuation (for example, period, comma, and semicolon) is ignored.
  
  
• Certain words are designated as noise words (for example, and, the, it) and are completely ignored. The list of noise words (which is in <systemroot>\system32\noise.enu for the English language by default) can be edited, if desired. Noise words, also called stop words, are never indexed and, therefore, will never result in a hit if included in a query.
  
  
• You can use noise words as part of a phrase by enclosing the phrase in quotation marks. The word and is both a noise word and a Boolean operator. If you want to search for the phrase salt and pepper, you should enclose the phrase in quotation marks ("salt and pepper"). Without the quotation marks, salt and pepper will match documents that have both words in them, but do not necessarily contain the phrase. Because noise words are not indexed, they can never be found unless they are part of a phrase.
  
  
• Free-text queries are supported. These are queries that ask a question in English (or some other language). To enter a free-text query, you must precede the query with the $contents operator. For example, the query $contents how do birds fly? will attempt to find documents that mention birds and flying.
  
  
• Queries based on properties take the form @property operator value. For example, to find all documents smaller than 4096 bytes, you would enter @size < 4096. See the product documentation for a list of supported property names.

This list provides the basics of forming queries that Index Server can resolve. It is possible to create custom forms that simplify the process of formulating queries for a particular subject matter area. This is especially desirable if the user community at your organization is unfamiliar with query processing. However, many sites will not need to customize the query process at all.

The mechanics of actually resolving the query involve the use of some special files. The original query is combined with information in an Internet data query (.idq) file. This file specifies how the query is to be processed. There are two possible sections in an .idq file: the names section and the query section. The names section is optional and is used only to define nonstandard column names that can be referred to in the query. This section is not needed for standard query processing. The query section is used to specify parameters used when the query is parameters in the .idq file are specified in a variable=value format. A variety of parameters is available to control the behavior of query processing. For example, the location of your catalog that contains all indexes created by Index Server is specified in a variable called CiCatalog. Another variable, CiMaxRecordsInResultSet, controls how much information can be returned as results. The variable CiColumns controls the columns returned in the results page and should match the columns referenced in the .htx file used to format the results.

HTML extension files (with a .htx extension) are used to format the results. These files are created by using HTML with conditional statements based on the variables defined and created in the .idq file used for the query being handled. Depending on your interest in customizing the query process, it can be enlightening to review the sample files provided to see how they are designed. The most basic query is handled with the following files, assuming that you have accepted all defaults during installation:

• c:\InetPub\wwwroot\samples\Search\query.htm This is the basic query form presented as a sample for you to test the use of Index Server. By default, it is not linked into any home page on your Web server. You must add a link to this page or connect to it by entering the URL directly into your browser (http://<servername>/samples/search/query.htm) if you want to use it.
  
  
• c:\InetPub\scripts\samples\Search\query.idq This is the Internet data query file that corresponds to the basic query form. You can read the comments provided, which describe the variables used and make suggestions for configuration changes that a Webmaster might make.
  
  
• c:\InetPub\wwwroot\samples\Search\query.htx This is the HTML extension file for the results returned by queries created with the two preceding files. This can also be customized to change the way the information is presented.

Now that you have been introduced to the query process, the action that occurs behind the scenes to index the content on your Web servers is described. The next few sections track the various actions that occur when new content is added to an indexed directory on your Web server, culminating in a set of entries in the master index.

Scanning

Indexing starts with a scanning process. By default, all virtual roots defined on your IIS server will be indexed. You can add virtual roots and include them in the indexing process as needed. You can also exclude virtual roots from indexing if you want. These virtual roots can be directories on the Web server machine itself or shared directories on other servers.

Windows NT supports automatic change notification and initiates the scanning process when new files are added to the server. Other file servers (for example, Windows 95 and Novell NetWare) do not support this feature and must wait for a periodic, scheduled scan to occur. A Registry entry (ForcedNetPathScanInterval), which can be configured by the administrator, controls the frequency of these scans.

Two types of scans are performed by Index Server: incremental scan and full scan. The first time a directory is scanned, a full scan of all contents is performed. Thereafter, only an incremental scan is necessary to accommodate the changes that have occurred. Occasionally, an additional full scan could be necessary. For example, after a server suffers a catastrophic failure, a full scan is needed. No administrator intervention is normally needed, even for this type of recovery operation. Index Server has been designed to recover from failures automatically unless an unusual circumstance should occur and go undetected (for example, Registry corruption). The administrator can force a full scan or an incremental scan at any time.

Filtering

After a directory has been scanned, a three-step filtering process takes place:

1. A filter DLL examines the document and extracts the text and properties that are accessible. For many binary files (that don't have a corresponding custom filter), only properties would be able to be extracted.

2. A second DLL, known as a word-breaker DLL, parses the text and any textual properties into words.

3. The resulting list of words is compared with the list of noise words, which are removed and discarded. The remaining words are processed and included in the index.

Filtering occurs under the direction of the CiDaemon process, which is spawned by the Index Server engine (see the following Note). It must analyze the list of documents that have been scanned and sent for indexing to determine which is the appropriate filter DLL and which is the appropriate word-breaker DLL. As previously mentioned, different filter DLLs and word-breaker DLLs are required to handle documents of different types and in different languages.

---

NOTE: Daemon is another name for a background process that runs without requiring user intervention. The term is most commonly used in UNIX environments. In a Windows NT environment, the term service has roughly the same meaning and is used much more frequently.

---

In addition to generating words to be merged, the filtering process also generates a characterization. This is a short summary of the item being indexed that can aid the user in deciding whether this is a document or file that is of interest. The Registry key GenerateCharacterization is set to 1 (by default). If this entry is set to 0, characterizations will not be generated.

Index Server is designed to be operational 24 hours a day, seven days a week. Therefore, it does most of its work in the background and attempts to work only when the server is idle. It also closes any documents that it is processing as quickly as possible if they are requested by another user or application. Filtering of that document will automatically be retried later.

---

CAUTION: If directories on shared network drives (on another server) are being indexed, the files opened by Index Server will not be quickly released when another user or process requests them. This feature (quickly releasing files needed elsewhere) is not available when indexing shared network drives. Therefore, the filtering process might temporarily hold a file lock on a document while it is being filtered. Use discretion when deciding which directories should be indexed.

---

To avoid interfering with other more urgent processes on a server, the CiDaemon process runs in the idle priority class by default. In other words, it filters documents only when there is no other work of a higher priority to perform. If you intend to use Index Server on a fairly busy computer, this could result in lengthy delays before documents are filtered and a subsequent backlog will occur. To increase the priority of the CiDaemon process--understanding that this might impact the throughput of other work on this server--you can set the ThreadPriorityFilter Registry key to THREAD_PRIORITY_NORMAL and the ThreadClassFilter to NORMAL_PRIORITY_CLASS.

---

CAUTION: Changing any of the Registry entries as described in this chapter, especially the priority level, should be approached with extreme care. Improperly editing the Registry can result in corruption of information and the need to reinstall the operating system and restore the most recent backup. This operation should be attempted only by experienced administrators and only after a current backup is made and the RDISK utility is run to create an updated repair disk.

---

When the filtering process is complete, the resulting word lists are merged, as described in the next section.

Merging and Index Creation

Indexes are used in many different computer applications. There are many different types of indexes for different purposes. The indexes that Index Server creates are designed for the purpose of rapidly resolving the search queries used when trying to locate documents or other content on Web servers. The words and properties that have been extracted during the filtering process by CiDaemon are merged into a permanent index stored on disk.

Because Index Server must operate in an environment in which many other activities are being performed (potentially) on the same machine concurrently with its operations--including the need to resolve queries based on the current content and indexes that already exist--a multistep process is used that culminates in a single, up-to-date index. Depending on the load placed on the server and the amount of new information being added, there are intermediate stages that result in a more complex state than a single index.

As already described, the filtering process results in word lists. These can be thought of as mini-indexes for a small collection of documents. They are stored in RAM as they await further processing. If a power loss occurs, these word lists are lost, but Index Server is designed to recover automatically from such an event. Because they exist in RAM, the creation of a word list is very fast.

Word lists are merged to form shadow indexes. These are stored on disk and will, therefore, survive a power loss. More than one shadow index can exist in the catalog, which is the directory containing all indexes for an Index Server. The process of merging word lists (and occasionally other shadow indexes) to form a shadow index is called a shadow merge. During the shadow merge process, additional compression is performed on the information stored in word lists to further optimize storage and retrieval.

A master merge is eventually performed to create the master index. During this process, all shadow indexes and the current master index are merged to create a new master index. At any given moment, there is only one master index. If the server has had an opportunity to "get caught up," then there will not be any shadow indexes or word lists--just the master index. In other words, if there is sufficient processing power and no new documents are added for a period of time, the natural progression of things will result in a single master index and no other index structures. As new documents are added, the process starts again. Index Server is capable of operating properly in any intermediate state but is most efficient when working with just the (complete) master index.

The total number of indexes on a very busy server can grow as high as 255. If the server is so busy that even more shadow indexes would be required, the server will fail, and some reconfiguration will be required to provide faster disk subsystems, additional CPU power, or other additional resources so that it can accommodate the load required. A master merge on a very active machine can be a complex and lengthy process. The automatic recovery capability of Index Server includes even this complex operation. System failure in the midst of a master merge operation is fully and automatically recoverable.

Installing and Using Index Server

Now that you know how Index Server operates, it is time to learn how to install and use this powerful tool. The following procedure assumes that you have already installed Windows NT Server and IIS. In addition, you should be logged on with administrative rights to the machine, which is set up as an Index Server. If you want to index the contents of other file servers or Web servers, you should define additional virtual directories on the IIS WWW service by using the Internet Service Manager. You can add virtual directories at a later time if you prefer. For more information about defining virtual directories, see Chapter 52, "Setting Up Internet Information Server."

To install Index Server:

1. Insert the appropriate CD or connect to a shared network directory containing the Index Server distribution file.

2. Launch the executable distribution file (is11enu.exe for the English language version).

3. A Welcome dialog box displays. Click Continue.

4. Another dialog box displays (see Figure 58.1), requesting the location (the full physical path) of the IIS scripts directory so that it can install Index Server sample scripts. By default, the directory is c:\InetPub\scripts. A virtual directory can also be used. Accept the default, or override it with your preferred location. Click Continue.

5. Another dialog box appears. Enter the location of the IIS virtual root. By default, this is c:\InetPub\wwwroot. Accept the default, or override it with your preferred location. Click Continue.

Fig. 58.1

This dialog box is used to specify the location of IIS scripts.

6. A final dialog box requests the location to store the Index Server catalog (the collection of indexes including the master index). By default, this is c:\ISIndex. Accept the default, or specify a location for the catalog to be stored. Click Continue.

7. A file copying progress bar appears. When all the files have been copied, you're informed that the process is complete, and the URL for the sample search page (also called a query form) is provided. By default, this is http://<servername>/Samples/Search/queryhit.htm. Index server has been successfully installed.

After you've installed Index Server, you naturally will be eager to test its functionality. If you already have an operational Web server with an interesting collection of content, all you need to do is wait. Index Server's operations are automatic, and the scanning, filtering, merging, and index creation process occurs without further intervention. Depending on the amount of content and the load placed on the server, you should allow anywhere from 10 minutes to several hours for the indexing process to produce useful results.

You can start by reviewing the online Index Server Guide. This is accessible by choosing Start, Program, Microsoft Index Server, Index Server Online Documentation (see Figure 58.2). Alternatively, you can connect to this Web page by manually entering the URL (http://<servername>/srchadm/help/default.htm by default).

Fig. 58.2

Index Server includes online documentation in HTML format.

When an appropriate period of time has elapsed, you're ready to try a search. Choose Start, Program, Microsoft Index Server, Index Server Sample Query Form (see Figure 58.3). This Web page is the sample query form discussed in the introduction to this chapter. It enables you to test the search capabilities of Index Server.

Fig. 58.3

The sample query form provided with Index Server is a working search page that can be used without modification or customized to meet specific needs.

To test your Index Server, follow these steps:

1. Open the sample query form, as described in the preceding paragraph.

2. Enter a keyword or phrase that you believe will result in a successful query result. Click Execute Query.

3. The results of your query are returned and displayed in your browser (see Figure 58.4). In addition to listing the documents or pages that matched, a characterization, or short summary of the document, is automatically generated.

4. Depending on the type of documents returned in your result set, the manner in which your browser is configured, and the software installed on your computer, you might be able to click a hyperlink in the results and directly open a matching document. In Figure 58.5, a Microsoft Word document is open in the browser window.

5. Choose Go, Back (or click the Back toolbar button) to reach the query results page. At the bottom of this page, you can click the New Query hyperlink to return to the query form (or, in this example, just click the Back button one more time).

6. You can continue refining your search by entering new queries until you find the document you want. Simply close your browser when you're finished.

Fig. 58.4

The results of a query are formatted in HTML and returned to your browser for display.

Fig. 58.5 If properly configured, Microsoft Internet Explorer (version 3.01 for Windows NT shown here) can host documents within its window, such as this Microsoft Word document.

You're now familiar with the main procedures for using Index Server. By design, it's easy to use and manage. With the growth of most Web sites, indexing is becoming a critical feature that is needed to help people find the information they need. Index Server fills this important role with a minimum of work on your part. The next section discusses another member of the BackOffice family called the Content Replication System.

The Content Replication System

Source control systems, used in the past to coordinate the orderly interaction of a group of programmers working together on a body of computer code, have been pressed into duty to manage Web content. These systems not only enable users to "check out" and "check in" files but also track revisions and even restore an older version if the latest becomes corrupted. Microsoft's SourceSafe is an example of this genre, and a white paper is available on the Microsoft Web site (http://www.microsoft.com/ssafe) describing the use of this product for Web content management.

A new entry in the Web management repertoire is the Microsoft Content Replication System (CRS). This product is designed to move Web content from one computer to another. There are a variety of scenarios in which the product can be used, and a number of methods are supported. This section describes how to set up CRS and walks you through a sample replication.

Although the product could be used to replicate arbitrary information, it's specifically engineered to be used in a Web server environment. For example, one option enables you to specify the content to be replicated by providing an URL.

Setting Up the Content Replication System

In this section, you learn how to install CRS on a server. If you intend to use the command-line interface exclusively, then any Windows NT server with sufficiently powerful components (processor, disk drive subsystem, and network interface) will suffice. CRS can be run on either Windows NT Server or Windows NT Workstation. Clearly, if the CRS system is also intended to act as a Web server (as opposed to just a staging server for information that is being moved), it must be running IIS.

Most people will want to take advantage of the CRS Web Administration tool, even if they occasionally use the command-line interface for auxiliary tasks or to confirm the status of a project. This tool is somewhat different from other BackOffice administration tools. It is Web browser-based, which a growing number of BackOffice products are adding, but this is still fairly new. Also, it uses a different style of buttons and controls than you might be used to if you manage other BackOffice products. You might also find it necessary to use the Refresh button to update the display more often with this tool than most others in the BackOffice administration suite, primarily because of its Web-based design. It is, however, relatively easy to learn and use.

---

NOTE: To use the Web Administration tool, you must install CRS on a Windows NT 4.0 system that has been configured to use the NTFS file system. To ensure security, the CRS Web Administration tool is not supported on disk drives configured with FAT partitions.

---

As with all BackOffice products, administrative tasks can be initiated from client computers connected to the server over the network. To run the CRS Web Administration tool on a client computer, you must be running either Microsoft Internet Explorer 3.01 (or later) or Netscape Navigator 3.0 (or later).

To administer CRS, you must be able to access the Web Administration tool through IIS. This is subject to IIS security restrictions as described in Chapter 52, "Setting Up Internet Information Server." In addition, you must be an administrator for the Windows NT system that runs CRS. You should also create a service account to run CRS services by using the User Manager for Domains utility.

To install CRS, follow these steps:

1. Insert the distribution media (usually a CD) into a drive on your Windows NT computer. Find the Setup program and launch it. You see the dialog box shown in Figure 58.6. Click OK.

Fig. 58.6

The InstallShield Self-extracting EXE dialog box begins the installation of CRS.

2. After an intermediate dialog box that requires no response (but simply updates you on the preparation process), you're presented with the Welcome dialog box for the Setup program. Click Next.

This is the Welcome dialog box for CRS.

3. A license agreement dialog box appears next. Carefully read the license, and click Yes to accept the license agreement. The next dialog box displays the names of any services that must be stopped to complete the installation (see Figure 58.7). Click Yes to stop the services and continue installing CRS.

Fig. 58.7

This dialog box lists the Web-related services that must be stopped before the installation process can continue.

4. A series of messages informing you about services being stopped follows, and then a Registration dialog box displays. Enter your name and company (if appropriate). Click Next.

5. You are prompted to select the directory in which you want CRS installed. Select the directory you want to use, or accept the default (which is automatically created), and click Next.

6. The Web Administration and Document Directory dialog box asks you for the virtual root on your Web server that will contain the Web Administration tool and online documentation (see Figure 58.8). Click Next.

Fig. 58.8

Use the Web Administration and Document Directory dialog box to select the location for the Web Administration tool and the product documentation.

7. You must now select the setup type, Typical or Custom. If you select Typical, the Setup program installs standard components without further input. If you select Custom, the dialog box shown in Figure 58.9 appears.

Fig. 58.9

Use the Select Components dialog box to customize your CRS installation.

8. You can select those elements of the system you want to install and can ensure that adequate disk space is available. When you're satisfied with your selections, click Next to reach the CRS Service Account dialog box (see Figure 58.10).

9. The service account establishes the security context that the CRS service will have during its execution. Select the account you created earlier (or switch to User Manager for Domains and quickly create the account). Click Next.

10. The Schedule Service Account dialog box appears. This is typically the same account used for the CRS service. Select an appropriate account, and click Next.

11. Select the folder to contain the CRS shortcut icons to start the Web Administration tool and review online documentation. Either select a folder or accept the default.

Fig. 58.10

Use the CRS Service Account dialog box to select the service account that will be used by CRS.

12. A confirmation dialog box gives you an opportunity to review all your choices. Click Next to begin the actual installation. When setup is complete, a final dialog box offers you an opportunity to view the CRS Start Page. Click Finish to complete setup and view the Start Page (see Figure 58.11).

Fig. 58.11

The CRS Start Page provides an introduction to CRS and links you to the Web Administration tool.

You're now ready to use CRS to move Web content on your network. This is described in the next section.

Using CRS to Move Web Content

Two interfaces can be used to control CRS. The first is a Web browser-based interface that uses JScript applications to create and monitor the status of projects. The second is a comprehensive command-line interface. Both of these interfaces are described in this section.

Remember that all replication events are managed as projects --no matter how complicated an architecture you want to create. These projects operate on pairs of servers, either pulling or pushing information from one server to the other. Even large replication architectures spanning global networks are based on this simple concept. In the next two sections, you'll learn how to create both push and pull projects, the basic ingredients for all replication scenarios.

It's a good idea to experiment with CRS in a lab environment before deploying it on your production servers. This is generally true of all BackOffice products but can be especially important with a product like CRS that is capable of moving very large amounts of information and consequently having a big impact on network bandwidth and server performance. When it comes time to implement CRS on your production environment, you should have a good idea what will happen, based on the tests you've performed. You want to know how long a typical operation will take, the best time of day to perform that operation, and the impact a replication project will have on active Web users.

Pull Projects. A pull project is designed to connect to a source URL and copy the content it finds there to a specified target directory on the server that is running the pull project. The server "pulls" the content from the source, hence the name.

You can either request that all content at the source be pulled or only a specified number of levels be copied. If you specify a limit of two levels, for example, the initial page (typically default.htm or index.htm, depending on how the server is configured) is copied, and the links on that page is followed. The content of the linked pages is copied, and the links contained in them is followed and copied. This is what is meant by two levels deep.

To create a pull project by using the Web Administration tool:

1. Launch the Web Administration tool. This can be done by using the icon from Start, Programs, or directly by entering the URL into your browser (http://servername/crs/admin/crs.pgi by default). This opens the CRS Web Administration tool's initial page (see Figure 58.12).

2. Click the Add Project link.

3. The Add Project dialog box appears (see Figure 58.13). Enter a name for the project, and select the type (Pull replication in this example). Click OK.

4. The Project Source/Target page appears (see Figure 58.14). Enter the Source URL from which content will be pulled; then enter the number of levels the replication should pull (the depth of links that it should follow). Click All to pull the entire Web site from that virtual root.

5. Enter the Target directory. This is the fully qualified path name on the local server (the server that's running this CRS project). You can optionally enter a username, password, and proxy server name if required to access the source server. Click Save, and then click the Projects link to return to the main Projects page. Click the Schedule link to reach the Schedule page.

Fig. 58.12

This figure depicts the first page of the Web Administration tool for CRS, a browser-based administration utility that enables you to manage servers, projects, routes, or configuration settings.

Fig. 58.13

The Add Project dialog box enables you to create a project and select the type of replication that you want to use.

6. Either select Replicate Automatically or click Add Schedule to add a specific scheduled date and time (see Figure 58.15).

7. Select the schedule for this project, and then click OK to return to the Schedule page.

8. Click the Email/Scripts link to reach the Email/Scripts page. E-mail notification can automatically be sent on success or failure of a replication event or every time the event executes. You can also run a script before the server receives any content on the server or after it's all received. This script can be used for notification, for routine maintenance chores, or other application-specific purposes. Click Save, and then click the Projects link again.

9. You now should see your project added to the list on the Projects page (see Figure 58.16). It should have a status of Idle. Click the Idle link.

Fig. 58.14

The Source/Target page specifies the source and destination for your project.

10. A Project Status dialog box displays (see Figure 58.17). This dialog box can be used to start a project immediately, regardless of any scheduled times already set for this project. Click Start if you want to test your new project. The State displayed on the dialog box is updated from Idle to Running to reflect the new status of the system.

11. Click OK when you're finished with this project. You can enter additional projects to monitor or exit the CRS Administration tool by choosing File, Close.

Push Projects. A push project operates in the reverse manner from a pull project. It's initiated on the source server and "pushes" content to one or more destination servers. In addition, a push project must be defined on both the source and destination servers, although only the source server is configured for a target (destination).

Fig. 58.16

The Projects page lists all active projects and shows their current status. You can remove a project by clicking the waste can icon to the left of the project's name.

Fig. 58.17

In addition to starting a project, the Project Status dialog box can be used to stop an executing project or to roll back (undo) the effects of an earlier replication.

To create a push project with the Web Administration tool:

1. Launch the Web Administration tool by using the icon from Start, Programs, or by directly entering the URL into your browser (http://servername/crs/admin/crs.pgi, by default). This opens the CRS Web Administration tool's initial page (refer to Figure 58.12).

2. Click the Add Project link to reach the Add Project dialog box.

3. Enter a name for the project, and select the type (Push replication in this example). Click OK.

4. The Project Source/Target page displays (see Figure 58.18). Enter the Project Directory from which content will be pushed and then select an option button to indicate which subdirectories (if any) should be copied with the main project directory. Click the Add Target link.

Fig. 58.18

The Source/Target page for a push project is used to specify the project directory to be replicated, select whether or not to include subdirectories, and add Targets (destinations) for the push event.

5. The Add Target dialog box displays (see Figure 58.19). Enter the name of the Target machine (for example, HQSRV2). You can also specify that a route (a predefined chain of linked servers) should be used as the target, but this is beyond the scope of this book. Click OK and then Save. You now can click the Projects link to return to the main Projects page.

6. You should now see your project added to the list on the Projects page. It should have a status of Idle.

7. To complete the configuration of the push replication project, you must repeat steps 2 and 3 on the target server. Click the Servers link and enter the name of the destination server in the Select Server dialog box. You're connected to the destination server, and any currently defined projects are displayed.

8. Click the Add Project link to reach the Add Project dialog box.

Fig. 58.19

Use the Add Target dialog box to specify the target of this replication event. Only one machine can be specified in a target, but multiple targets can be defined for the same project.

9. Enter the same project name that you used on the originating server and a project directory that will receive the replicated content--but you need not specify a target server because this server is the final destination.

10. Click Save and return to the Projects page to verify that the new project is visible.

11. You've now completed the configuration of the push project. To start the project, you should once again connect to the originating server, go to the Projects page, and click the Idle link to open the Project Status dialog box. Then click the Start button to start the project.

12. Click OK when you're finished with this project. You can enter additional projects to monitor, or exit the CRS Administration tool by choosing File, Close.

This brief introduction to the Content Replication System should give you a solid basis on which to build additional knowledge and experience with this new member of the Microsoft BackOffice family. This product is only in its first release and will undoubtedly continue to be enhanced with additional features and capabilities. With the growing use of the Web and the challenges inherent in managing the large volume of content necessary for a great Web site, the importance of this type of tool will increase.

---

© Copyright, Macmillan Computer Publishing. All rights reserved.