Tips and Troubleshooting

This section presents tips for mapping custom metadata and key steps to help resolve issues you may encounter.

Propagating an Index across Servers

When propagating an index across multiple servers, you must create and run the content source and script on the server dedicated to creating and updating indexes. You must create the document profile and any SharePoint Portal Server custom properties on both the server dedicated to indexes and the server dedicated to searching.

Flushing the Cache

Iterative modifications to the mappings that you define can result in perceived failures. The majority of perceived problems are the result of not flushing the cache between iterative changes to the property mapping information. To prevent these issues, ensure that you stop and start the MSSearch and MSExchangeIS services before each full index update.

Overwriting Site Path Rules

To keep the previous sample code as simple and illustrative as possible, no code is included to check for a matching preexisting site path entry and to delete the entry if it exists. You must do this manually or augment the sample code to perform such a check and delete each time it runs. If you do so, delete and recreate the site path rule. Do not attempt to edit the rule.

The included PropMap.wsf script performs this checking and deletes any such rule before creating a new one.

To view site path rules:

1. In the workspace, open the Management folder, and then open the Content Sources folder.
2. Double-click Additional Settings.
3. On the Rules tab, click Site Paths.

Creating Site Path Rules

When possible, have only one site path rule per content source. Site path restrictions match in top-down order. If the URL of a document matches a site path rule that is not associated with the property mapping, the properties are not mapped and remain empty. It is the site path rule that determines whether mapping takes place. SharePoint Portal Server uses the content source entry only to determine how to do the mapping.

Viewing Custom Properties for Site Server Documents

Office documents managed by Site Server are usually tagged with custom properties. You cannot view these custom properties in Office, nor can you view them with the PROPDUMP utility. However, the ENUMALL utility can view these custom properties. For more information about these utilities, see Appendix B, For More Information.

Using both FILTDUMP and IFILTTST, the Site Server custom properties are generated from HTML files but not from Office documents. For more information about these utilities, see Appendix B. This is because the Office IFilter does not directly generate the properties, instead indicating to the calling code that it should use IPropertyStorage to retrieve these additional properties.

Use the following attributes with IFILTTST: IFILTER_INIT_APPLY_INDEX_ATTRIBUTES and IFILTER_INIT_APPLY_OTHER_ATTRIBUTES. IFILTTST does not support the IFILTER_INIT_APPLY_CRAWL_ATTRIBUTES value.

Using Namespaces

Although the properties embedded in HTML and Office documents have no namespace qualifiers, namespaces are prepended to them during the file crawl. Your property mapping arrays must consider this.

All HTML properties emerge from the crawl with the namespace prefix "urn:schemas.microsoft.com:htmlinfo:metainfo:", for which PKMCDO provides the constant cdostrNS_HtmlMetaInfo.

If the file source being crawled represents documents maintained by Microsoft Site Server version 3, all .stub files (which are HTML files with embedded redirect statements) also generate properties with this namespace.

If Site Server is managing an Office document, Site Server stamps its own properties into the document as a separate property set in OLE structured storage. The properties stamped into the file by the tag tool in Site Server include the previously mentioned cdostrNS_HtmlMetaInfo namespace prepended to them, even though they are not HTML documents but are Office documents crawled by Site Server.

Any other Office document properties are prepended with the namespace "urn:schemas-microsoft-com:office:office", for which PKMCDO provides the constant cdostrNS_Office. This is the same namespace prepended to all properties that you create by using the Add Document Profile Wizard in SharePoint Portal Server. The character "#" is appended to the namespace when followed by a property name.

Avoiding Custom Mappings to the Description

You should avoid custom mappings to the Description property unless you are crawling only HTML files. The Description property, specifically urn:schemas-microsoft-com:office:office#Description, is derived differently depending on the document type. While mapping the <META> tag of your choice to Description works for HTML files (including Active Server Pages [ASP] files), it does not work for Office documents. For Office documents, the Description field always comes from the embedded Comments property, no matter what you specify in the property map.

Using Many-to-One Mappings

A content source can contain several types of files, and you can find the same target property in different places, with different property names, depending on the source document. Because of this, it is possible to have multiple source properties mapped to the same target property. On a per-document basis, the first property for which SharePoint Portal Server encounters a non-blank value is the one mapped into the target property.

Overriding the Content Source's Target Content Class on a Per-File Basis

If you map a source property, typed as a string, to the target property DAV:contentclass, that property mapping takes precedence over the default target content class you specified for both the content source definition and the site path rule. Note, however, that the value stored in the source file must be a Uniform Resource Name (URN) that matches that of a document profile already registered for this workspace (for example, urn:content-classes:My Content Class).

Categories Can Be Assigned, But Only One Per File

Mapping a source property, typed as a string, to the target property urn:schemas-microsoft-com:publishing:Categories results in SharePoint Portal Server assigning the item to that category. Source values must be valid category names preceded by colons (for example, ":Category 1"). When mapping from META HTML tags, you can map only one value per document. SharePoint Portal Server assigns only a single value to the Categories property.

Date and Numeric Data Types Require Additional Handling

Although SharePoint Portal Server supports a Date property type (dateTime, in Web Storage System terminology), the standard HTML IFilter does not generate date properties from HTML documents as dates.

SharePoint Portal Server conducts no type checking or mapping on the properties. SharePoint Portal Server includes each value in the index as it arrives, in the format returned by the IFilter. In other words, if you map a source property to a target dateTime property, but the source value is a string, the content index stores a string value. This can have unforeseen, perhaps error-inducing, effects on the SharePoint Portal Server client user interface.

You can implement date and type checking by using a small amount of extra custom code and by implementing a custom IFilter. For more information on how to add support for non-text properties when crawling external files, see the section Using the Modified HTML IFilter Wrapper.