Using Index Server with FrontPage 2000

Using Index Server with FrontPage 2000

Last month, I showed you how to build a custom Microsoft Index Server catalog for a Web domain; add to the catalog directories that are outside that Web domain and exclude directories that are in the domain; and modify query.asp, a sample search page that comes with Index Server, to search the domain using your new catalog. This month, I conclude this series by showing you how to use an Index Server catalog with Microsoft FrontPage 2000.

Index Server vs. the FrontPage WAIS Search Engine
First, let's review some differences between Index Server and the FrontPage Wide Area Information Server (WAIS) search engine. If you install Index Server on the server machine, FrontPage will try to use Index Server by default, but you must create the catalogs for the virtual domains on the server machine. If you don't create a catalog for each virtual domain, either the Web content author will receive an error or the user will get search results from the wrong Web site. (For details about these errors, see the Microsoft articles "Configuring FrontPage 2000 to Search Using Index Server" at http://support.microsoft.com/support/ kb/articles/q203/7/96.asp and "Search Returns Results From Wrong Web" at http://support.microsoft.com/support/ kb/articles/q214/8/35.asp.) In contrast, the FrontPage WAIS search engine automatically creates and updates a catalog in each FrontPage subweb when it does a Recalculate Hyperlinks operation.

If you've installed Index Server on the server machine and you want to use the FrontPage WAIS search engine on one or more FrontPage-enabled virtual domains, you must change the FrontPage configuration in the Registry (for details, see "Index Server and the FrontPage WAIS Search Engine," June 2000). The virtual root and every subweb in the domain will then use the WAIS search engine. You can't mix Index Server and WAIS in a single domain, but if you have many virtual domains in a server machine, some can use Index Server and others can use WAIS.

Remember that when you use the WAIS search engine, FrontPage creates a separate catalog for each subweb in a virtual domain. So, you can't use one search page to search the entire domain if the virtual domain has subwebs. However, Index Server can search the entire virtual domain, the current Web, or a single directory in the domain. Index Server can also exclude from a search any directory or virtual directory that you added to the catalog.

The WAIS search engine indexes only Web content, .html files, and text files. Index Server can also index Microsoft Office documents, such as from Microsoft Word and Microsoft Excel. In fact, Index Server can index any document for which it has a filter.

Using Index Server with a FrontPage Web Domain
Of course, to use an Index Server catalog with FrontPage 2000, you need to install Index Server on the server machine. Index Server 1.1 comes in the Microsoft Windows NT 4.0 Option Pack, and the documentation is installed with the other Option Pack documentation.

Preparing. Before you begin, back up your server, including the metabase. Then, from the IIS snap-in in Microsoft Management Console (MMC), select a FrontPage-enabled virtual domain. If you create a new virtual domain, start the domain and make sure you've configured the FrontPage Server Extensions for it. (To check the server extensions, right-click the virtual domain in the IIS snap-in and select Task. To configure the FrontPage Server Extensions for the site, select the Configure Server Extensions task and follow the wizard's steps.)

You also need to check the Home Directory tab in the Web domain's Properties dialog box to ensure that you've selected the Index this directory check box. If the check box is cleared and you select it, the Inheritance Overrides dialog box, which Figure 1 shows, will appear. The directories listed in the Child Nodes window are private FrontPage directories. Notice that their names all start with an underscore. FrontPage automatically excludes the listed directories from the index, which saves you a lot of time and trouble. As I explained in "Creating a Catalog and Search Page for a Web Domain," August 2000, setting these exclusions manually in the IIS snap-in is tedious and problematic. If FrontPage didn't automatically exclude the directories, you would have to set the exclusions manually for each Web and subweb.

Using excluded directories and private data. If you store your forms results in a directory you've marked to be indexed, the forms results contents will show up in search results. However, if you don't store the forms results in a readable format, such as HTML or formatted text, users will see messy, unformatted data instead of a nicely formatted presentation.

Being able to exclude directories from the index is handy when you need to protect information from showing up in a search index. For example, I store information from private user-submitted FrontPage forms in the _private directory, thus preventing the user requests from showing up in a search results page. But if you (or the Web content author) want to make your forms results databases searchable, you need to save them in a directory that isn't marked for exclusion. Remember that although Index Server can search many types of documents, WAIS can search only .html and text files. Therefore, you must save your searchable forms text database in HTML or text format if you use WAIS.

When might you want to make the forms results searchable? You'll probably find frequent occasions in which you'd like to be able to search forms results. For example, I recently set up a series of FrontPage discussion groups as self-serve classified ad pages. Because the FrontPage forms processor lets you save forms results to both .html and text files, I can use either Index Server or the WAIS search engine to search the results. Visitors can use the search form to find just the articles or items in the discussion group they're interested in without having to scroll through the entire discussion group—or in this case, reams of unrelated classified ads. To let users search only one part of the Web site—the classified ads—I need to have a search page that searches only the directory I store the discussion forum in. (I show you later how to set up a FrontPage search page for this type of search.) FrontPage 2000 lets you store information that users enter in forms in a Microsoft Access database. If you're using Microsoft Site Server 3.0 or 2.0, you can index the database and let visitors search it. For details, see Tim Huckaby, "Implementing Site Server Search Database Catalogs," July 2000.

Creating your catalog. Before you create your catalogs, prepare the directories in which you want to store the catalogs. You should keep catalogs in their own directories on the server machine, not in subdirectories or virtual subdirectories under the virtual domain.To create a catalog, select the Index Server Manager from the Option Pack program group in your Start menu to open MMC, then run the Ciadmin.msc Index Server Services (ISS) snap-in. (If you need more information about how to create a catalog and how Index Server works, see "The Basics of Index Server," July 2000, and "Creating a Catalog and Search Page for a Web Domain," August 2000.)

Right-click Index Server on Local Machine, and select Stop to stop Index Server. Then, right-click Index Server on Local Machine and select New, Catalog. Follow the steps in the Add Catalog Wizard. Finally, right-click Index Server on Local Machine and select Start to restart Index Server.

Now, you can set the new catalog to track a virtual domain. By default, the catalog indexes the default domain on the Web server. To index the default domain, right-click the new catalog and select Properties. Click the Web tab, and select the Track Virtual Roots check box. From the Virtual Server drop-down menu, select the virtual domain that you want the catalog to track. Finally, save your changes, close MMC, then reopen it to refresh the data. Make sure the MMC version of the catalog agrees with your version before you proceed.

Reinitializing the FrontPage search component to use the Index Server catalog. From the IIS snap-in, right-click the virtual Web, select Task, then choose Recalculate Web from the list. Alternatively, you can use the FrontPage client to open the Web that uses the catalog. To put your FrontPage-generated search pages to work, choose Recalculate Hyperlinks from the Tools menu.

The Payoff: FrontPage Search Forms and Results
Last month, I went into the Active Server Pages (ASP) code for the Index Server search forms. Remember that the Content Index (CI) parameters can be difficult to track down and get right. FrontPage uses a prepackaged Search form that does all this work for you. Content authors can simply select a few check boxes to get search results; authors don't need to do any scripting.

To create a search page, open the Web site in FrontPage, then choose File, New, Page to display the FrontPage-supplied page templates. Select the Search Page template. FrontPage will create a new page that includes all the Web site defaults (e.g., the Web theme, shared borders) and a FrontPage search form, which Figure 2 shows.

The FrontPage editor shows a dotted line around the form on the Web page. To view the results page properties and the default CI parameter properties, right-click inside the form and select Search Form Properties. Figure 3 shows the Search Results tab with the available scope (i.e., the directories included in the search) and display information options. If you look at the search page's HTML source, you'll see that the parameters you set on the Search Form Properties window are translated into variable names similar to those in last month's ASP scripted search form.

How the Scope Works
The Scope default (i.e., This web in Figure 3) is the current FrontPage Web default, which is the current Web. If the current Web is the virtual root, its children are part of its scope, so results from the search page are returned from all nonexcluded and unprotected subdirectories and Web sites under the virtual root. If the current Web is a subweb in a virtual domain, then results from the search page are returned only for that subweb.

If you select the Entire website scope, all nonexcluded and unprotected subdirectories, virtual directories, and subwebs will be included in the search. In WAIS, All is the default scope, and it's limited to the current Web. In Index Server, All includes all the nonexcluded directories in the virtual domain, starting at the domain's virtual root and including all the subwebs that the user has permissions to search.

You can also specify a particular directory for the search. To limit a user search to a specific subweb or directory other than the Web that contains the search page, simply type the name of the directory (without a slash or backslash). For example, if the search page resides in the virtual root zeus.ideva and I wanted to specify a search on subweb zeus.ideva/classads, I would type classads in the Directory text field, as Figure 4 shows. (I used this process to create a search page that searched only the forms results from the classified ads I created with the FrontPage Discussion Group Wizard.)

You can have FrontPage return search results from any virtual directory in the virtual domain. Just enter the virtual directory's name (as it appears in the IIS snap-in) in the Directory text box in the Search Form Properties dialog box. Make sure you've included the virtual directory in your ISS catalog and that you've selected the Index this directory check box on the virtual directory's Properties dialog box in the IIS snap-in.

About Security and Protected Webs
If a subweb in the virtual domain requires you to log on, then no search results will be returned from that subweb to any search page that resides outside the protected subweb. If you log on to the protected Web, you can use a search page that resides in that protected Web. If you create a search page inside a protected Web site or subweb, search results are returned from inside the protected Web site; if you select the Entire website option, the results page will include results from the rest of the domain as well.

I've gotten Index Server's sample ASP search forms to work reliably only on sites that allow Anonymous access. (See Brett Hill, "IIS Informant," July 2000, for information about Index Server security and this problem.) So, keep that in mind as you create and configure the virtual domain. The WAIS search engine works fine on secured sites.

The Search Results
As I've explained, you set up the search results page in the Search Form Properties dialog box. However, you can't control how the results appear on the results page. FrontPage adds all the selections you make in the Search Form Properties dialog box's Additional information to display in the search results list area to the table in the results page. The example results page in Figure 5 shows all the selections. (The Hit Count field records how many times the search text appears in the document; this field has nothing to do with the number of visitors.)

If an Office document populates the row, data will appear only in the Author, Comments, and Subject columns. Index Server takes these fields from the Office document Properties sheet. I haven't discovered a way to make the HTML documents' metatag information show up in these fields.

This results page isn't nearly as fancy or flexible as the Index Server ASP sample search page in last month's column. FrontPage's results page doesn't use the more advanced CI functions. To get more sophisticated search capabilities or results displays that include abstracts and highlighted hits, you can modify and add one of the Index Server sample search pages to the FrontPage Web.

Troubleshooting Catalogs
If you've installed Index Server on your server, you'll need to either create catalogs for the virtual domains in your server or edit the Registry so that some or all of the virtual domains in the server use the FrontPage WAIS search engine. Most of my Web-hosting customers are happy with one or the other of these two search engines and with the FrontPage-generated search and results pages. Users generate their own pages and don't need to wait for me to do something on the server. My corporate Internet and intranet customers are moving more and more toward Site Server search. If you're having trouble creating catalogs, see Table 1 for a couple of common Index Server problems and their solutions.