Administration Requirements

                 

 
Special Edition Using Microsoft SharePoint Portal Server
By Robert  Ferguson

Table of Contents
Chapter  22.   Example Scenario 3 ”Enterprise-Wide Solution


Administration across the board is much more challenging for an enterprise-wide deployment than a departmental-based Portal solution for one primary reason ”complexity. The number of servers, roles of those servers, and the specific or custom hardware and software configurations deployed drive administration complexity. The Active Directory design, and inclusion of each server into this design, also presents challenges to administration, especially in highly distributed solutions.

The Need for Greater Manageability

Enterprise-wide SharePoint Portal Server implementations leveraging structured processes require greater management capabilities over their information. They need capabilities like formal publishing processes and the capability to search on different file formats or from multiple data stores. Here, manageability refers to managing the data as opposed to managing the solution from an IT perspective.

Custom Web Parts may play a role in assisting users to better manage their data, too. Web Parts can be developed that facilitate improved data organization across the Portal. Data related to general administrative tasks, for example, may be accessed via the enterprise Portal's home page, while administrative tasks specific to a business group may be accessed only from a custom Web Part configured to display a Web page with links specific to the group .

To read more about deploying and customizing Web Parts, see "Dashboards and Web Parts," p. 344.

Other specific administration challenges related to enterprise-wide SharePoint Portal Server deployments may be found in the following sections.

Index Management and Other Search Services

Index management becomes more and more critical as smaller Portal solutions grow. The time required to propagate indexes to other servers from index workspaces, not to mention performing full index updates, can become considerable.

Supporting other search-related services quickly becomes daunting tasks in and of themselves . Creating and managing categories, supporting multiple workspaces, and maintaining subscription services are two potentially time-consuming examples.

Modifying the Thesaurus

Modifying the thesaurus for large enterprise-wide implementations becomes a critical task as well, especially as multiple languages/dialects are addressed by the Portal, or additional business groups leverage the Portal, each with their own "definition" of business-specific terms and group-specific vernacular. And the fact that an administrator may affect search ranking by assigning weights to specific words or acronyms adds to his workload as well.

Configuring Crawling

The sheer number of documents in a large implementation could easily force the inclusion of several to many dedicated crawl servers, similar to what we have seen at Global. Microsoft published numbers indicating that a Portal server can crawl approximately 3,500,000 documents. However, this would be prohibitive in a single-server productive system where the Portal Server might be addressing searching and other functions. The solution is to spread out the crawling among a number of servers, then, such that the system is capable of crawling the number of documents expected to be crawled on a daily basis in say, a year or two from now. Another approach would be to plan on adding incremental servers once the number of crawls surpasses perhaps 2,000,000 ”this approach requires "going back to the well" for budget money, however, and simply may not be an option.

The Importance of IFilters

Installing and registering IFilters is required when using proprietary file extensions. The "unknown" that an enterprise-wide implementation may introduce is simply the variety of data formats that could be managed by the Portal in a year or two.

Other Administration Requirements

Miscellaneous challenges will serve as potential administrative stumbling blocks throughout the project lifecycle, unless addressed early on and in a regular manner throughout the Portal lifecycle. These include areas like

  • Licenses per Server ” Estimating the number of licensed users that each server within a complex Portal solution can support is difficult indeed. For many deployment scenarios, whether large department or worldwide multi-site organizations, supporting 10,000 licensed users per single SharePoint Portal Server computer is not uncommon.

  • Enabling "Best Bets" ” Though easy to enable, Best Bets can become cumbersome and ineffective as an organization adds users and groups with different Authors and therefore varying "definitions." Over time, these varying definitions will have to be addressed ”documentation standards ease this pain!

  • Documents per Server ” Microsoft has indicated that one million document versions may be stored by a single SharePoint Portal Server computer. Choices regarding deployment details like the extent of the category hierarchy must be determined before a number specific to your Portal implementation can be determined.

  • Documents per Index ” A single SharePoint Portal Server computer can crawl something in the neighborhood of 3.5 million documents. Of course, when all of this data finds its ways into an index, the real challenge of managing and sifting through large indexes becomes a key challenge to an enterprise Portal deployment.


                 
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