Larger Deployments

                 

 
Special Edition Using Microsoft SharePoint Portal Server
By Robert  Ferguson

Table of Contents
Chapter  19.   Managing Indexing


A key concept within SharePoint Portal Server is the decentralized management and storage of information. The documents can be maintained within the owning departments by those who know best how to answer the new challenges.

But despite the decentralized management, it is possible to provide a common view of all information that is available within a company. Obviously, this is a resource- intensive task that does not go well together with generating the end- user view of that information. Using indexing workspaces, it is possible to dedicate servers (see Figure 19.10) to this resourceintensive task of crawling for document changes. These consolidated changes will be propagated to a target system where these indices will get merged to a common index that serves the user's search requests .

Figure 19.10. This figure illustrates a larger deployment of SharePoint Portal Server.

graphics/19fig10.gif

Setting Up the Information Infrastructure

If multiple workspaces on various servers administered by different Coordinators come into play, you need to address the common information infrastructure. Everyone in the organization should use the same words for the same thing ”an amount field should, for example, always be used in the same currency. A company with offices in the U.S. and Japan should make a choice for either Japanese Yen or US Dollar as currency. Otherwise, you cannot interpret a search result ”an expense claim, for example, of 12.300 could be a 100 US$ bill.

To overcome the problem that decentralized information remains locked up with the department, you should centrally manage the document profiles (and thus the definition of the custom properties) that are essential for the enterprise. Ideally the category tree would be shared throughout the enterprise. But the current release of SharePoint Portal Server will not maintain categories in a propagated index. Once you have laid out the document profiles, keywords, and categories, you can roll out departmental SharePoint Portal Servers. Rolling up the metadata will ensure that all information remains available for the whole enterprise. This roll-up is done through dedicated indexing machines propagating their index to the enterprise search portal.

The architecture with a departmental document management server, indexing servers, and a single common portal does not resolve two potential bottlenecks.

First it needs the central common portal not only to render the Digital Dashboard, but it also needs to respond timely to user queries. This problem can be solved if the content is propagated to a server that only executes searches. The Search Web Parts on the central common portal can fairly easily be modified to redirect the queries to the dedicated search server. You can even decide to let the departmental workspaces use this central search facility.

The second problem is more profound ”the common portal is a single point of failure and may not be ideally located for all users due to network limitations. With this first version of SharePoint Portal Server, there is currently no recommended architecture to solve this problem.

Infrastructure and Security Considerations

Up to four index workspaces can propagate their index to a common server. It is not possible to "chain" the propagation of indices, nor is it possible to propagate to multiple servers. The names of the indexing workspaces and the name of the target workspace must all be different. This implies that in an enterprise scenario, you need to plan for the location of these index workspaces in particular, as indexing may cause quite some network load. You therefore likely want to place your dedicated indexing servers near the network hubs: In a worldwide operating company, for example, place one in North America, one in Europe, and one in Asia.

Scheduling the Propagation

You also need to plan when the index gets propagated. By default, SharePoint Portal Server automatically propagates its index after creating or updating it. This can be unfortunate, as, for example, with two content sources scheduled to be updated at different times, the index propagates twice.

You can also schedule a task to run a script to propagate on a regular basis. To do so, take a look at the srchadm.vbs script that is in the SharePoint Portal Server CD's support/tools directory. The following command

 cscript srchadm.vbs build /c:<workspacename> /o:prop 

will propagate the index of the indexing workspace with the name <workspacename>.

Windows Security Domains

The security credentials must be shared across all servers, for example by using single domain. Alternatively you can establish trust relationships. This is required due to the Propagation Access Account which must be defined in the indexing workspace as a valid account with local administration privileges on the destination server.

But there is an even more profound reason to have the security credentials shared across all servers. As discussed in Chapter 5, the index stores security information to ensure that only documents that are readable by the user who issued the search request are returned. This security information is built on the server with the workspace index and used on the destination server. For this reason, do not use local accounts in SharePoint Portal Server roles used by the document management system.

Targeting Server Disk Space Requirements

Before a catalog can be propagated from the indexing workspace to the target workspace, you must ensure that there is enough disk space available on the destination server. Not only must the destination server have free space that equals the size of the catalog, also additional working space is required to bring the catalog online after the catalog is copied . Typically, the recommended minimum additional working space is 50 megabytes (MB) of disk space.

TIP

In case of failures, check the Application event log on both servers. Insufficient working space, for example, can only be detected on the destination server. On success, an informational entry will be written in each Application event log.


SharePoint Portal Server uses the propagation access account when propagating indexes from one SharePoint Portal Server computer to another. This account must have local Administrator permissions on the destination server.

Index propagation uses the standard Windows SMB file sharing protocol. Firewalls between the two servers might not allow the SMB packages to pass.


                 
Top


Special Edition Using Microsoft SharePoint Portal Server
Special Edition Using Microsoft SharePoint Portal Server
ISBN: 0789725703
EAN: 2147483647
Year: 2002
Pages: 286

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net