| SharePoint Portal Server is really starting to catch on at SmallTime! This latest project, to provide superior search capabilities for the Product Support organization, hopes to capitalize on the flexibility of the Portal's dashboard site to create a central point of access. By doing so, Product Support will not just tweak their existing search services. Instead, they will actually consolidate search services throughout the Product Support department, and provide a robust department-wide utility for working smarter (see Figure 21.3). Figure 21.3. Note the multiple GUI interfaces and various standalone "search service" systems employed prior to the SharePoint Portal Server implementation. Afterward, access to SmallTime's various product support tools requires only Internet Explorer.  Business Problem to Be Solved Product Support is responsible for providing pre-sales telephone support to new prospects and existing customers, as well as limited telephone post-sales support. As such, they require access to the latest SmallTime product specifications, engineering manuals, quick reference guides, technical support database, and more. They currently maintain a slew of client GUI interfaces and have trouble with version control of these sometimes proprietary client/server-based toolsets. As a result, the Product Support engineers spend too much time getting to the data they need, and therefore less time supporting their customers. They believe that a Web browserbased powerful search tool may be the solution to many of their problems. SmallTime Product Support wants to limit the number of search tools and access methods they currently support. Searching needs to be comprehensive, covering both internal and external data source requirements (intra-SmallTime as well as across the Internet). The Product Support group 's search services are expected to grow in usethey exploit their albeit currently restrictive search capabilities in a big way today. It is also noted that very few people actually create or manage content. Support Organization In what looks to be a SharePoint Portal Server Search Services deployment, IT is both concerned about proper sizing, and excited that they may be able to retire two of their legacy in-house search utilities/applications. With their hardware partner's assistance, and a quick sanity -check phone call to Microsoft, it was verified that the volume of traffic and number of hits, I/Os, and content sources would drive a four-server SPS design, consisting of two dedicated search servers and two dedicated crawl servers. Solutions Architecture As noted earlier, this SharePoint Portal Server deployment requires dedicated server resources to crawl and categorize data, and additional server resources dedicated to searching. The crawl servers will be used to create and update indexes. These servers will be dedicated to crawling content sources. They will not be used for document management or searching. The servers dedicated to searching will contain one workspace each for every two indexes to be propagated. Each index is propagated to the workspace on the particular server dedicated to searching. Some SharePoint Portal Server document management features may be leveraged for a small number of documents, but overall this functionality will not be a focus of the project. From a solutions architecture perspective, it was important to provide maximum headroom to the search and crawl servers neither one of these types of servers were installed on an existing Exchange 2000 or other server, for example. This design tenet also removed the complexity inherent to such an architecture. Planning Tasks To prepare for this SBU search services deployment, the following high-level planning- related tasks must be addressed: -
Determine skill-sets and then identify team leaders for the various SPS functions that are detailed below. -
Procure and prepare the servers, and install the prerequisite software required by SharePoint Portal Server. -
Connect the servers to the corporate IT network backbone, and the public net. -
Determine the number, type, and location of content sources, how often they will be crawled, and how the indexes will be updated. -
Plan for the layout and other required customization of the workspaces. -
Determine the level of operations and enterprise management support required after deployment. As the Product Support organization grows larger, the search services may be beefed up by adding additional dedicated search servers to meet new search and indexing requirements. The size of your organization, the number of workspaces/indexes, and the number of end-users will drive the decision to include additional server search resources. Installing the Search Servers SmallTime will address the following tasks during installation: -
Install SharePoint Portal Server on the servers procured and dedicated to searching. -
Create one workspace, via the New Workspace Wizard at the end of the installation. -
Skip creating index workspaces on these dedicated search servers. -
Specify the SMTP server for each search server by using SharePoint Portal Server Administration. Configure the SMTP server to receive approval email, and to receive subscription notification email. -
For the workspace on each server, use SharePoint Portal Server Administration to configure the workspace contact as a Coordinator on the workspace node. This enables the workspace contact the ability to customize the dashboard site. -
To dedicate each server as a search server, employ SharePoint Portal Server Administration to adjust the resource usage controls. Installing the Crawling Servers For each of the crawl servers, the following tasks will be addressed during installation: -
Install SharePoint Portal Server on each server procured and dedicated to crawling. -
Create four index workspaces per server. -
Maintain the previous list of index workspace names , noting the server on which they are stored, and the destination server and workspace where they are propagated. -
For each index workspace, identify and configure the Coordinator -
Similar to the search servers, use SharePoint Portal Server Administration to adjust the resource usage controls to dedicate the server resources for crawling. -
Note that it was determined that both Microsoft Exchange Server 5.5 and Lotus Notes content sources would need to be crawledeach crawl server was configured for this capability as well. Of course, the team discussed dedicating one server to Exchange 5.5 and one to Lotus Notes. In the end, though, it was decided that it made more sense to cover all bases redundantly, such that if one server was unavailable, the other would be capable of accessing all content sources.  For detailed Exchange Server 5.5 and Lotus Notes crawling procedures, as well as procedures geared toward crawling other content sources, see "How Microsoft SPS Crawls," p. 454. Security Considerations One key holdup in the project was determining who would be the workspace contacteach workspace needs such a contact, someone who acts as the point of contact for workspace-related issues. It had been incorrectly assumed that the server administrator would act as the workspace contact. Eventually, a security team leader was identified, who also acted as the security liaison to IT and assisted in assigning and modifying roles and rights. Workspace and Dashboard Considerations It is important to note that destination workspaces can only accept up to four propagated indexes. If SmallTime ever wishes to create more than four index workspaces on a server dedicated to crawling, they will need to create additional workspaces on the destination server to propagate the additional indexes. Further, they may simply use multiple index workspaces to better focus content sources. For example, one index workspace might be dedicated to crawling the internal organization and a second index workspace could be dedicated to crawling content out on the Internet. SmallTime had to decide how many workspaces to store on the servers dedicated to crawling, noting the four index limit. Client Access Considerations Now that the servers dedicated to crawling and searching are installed and ready to go, and workspaces are created and customized, the client components of SharePoint Portal Server may need to be installed. Note that any user can use the dashboard site for document management features and for searching without having to install the client components on his computer. This is accomplished via Internet Explorer version 4.01 or later. However, to perform Coordinator functionssuch as configuring security, adding content sources, or even creating document profilesthe client components will be required on each end user 's computer within Product Support. In our project here, this requirement will primarily impact Product Support's IT liaison and the various SPS team leaders. Some of these individuals are already running Microsoft Office XP, and are therefore covered. Others will need to actually load the client components that ship with SPS. Accessing the Workspace Once these client components are installed on the appropriate users' computers, as required, each user must then add a Web folder that points to the workspace. The format of the workspace address is http://server_name/workspace_name. SmallTime decides that scripting this final piece of the puzzle might make sense, so as to automate the process and therefore minimize support calls from new users wishing to leverage these search services. But they also document the process, and disseminate this throughout the Product Support team, noting that the procedure for adding a Web folder varies depending upon the operating system installed on the client machine. For example, in Windows 2000 Professional, click on My Network Places and then use the Add Network Place Wizard to add a Web folder that points to http://server_name/workspace_name. In Windows 98, click on Web Folders in My Computer, and then use the Add Web Folder to add a Web folder. Operations and Other Go-Live Considerations Product Support's IT liaison also needs to work with IT and the Product Support business/team leaders to determine how often each of the search and crawling servers must be backed up, decide whether or not this backup process should occur automatically, and determine whether to store the backup image on another computer. In addition, it must be determined whether a duplicate of one or more of the servers dedicated to searching or crawling should be created at a remote office for disaster tolerancethere is no need to duplicate one locally, they decide, as each crawling and searching server already is redundant. For approaches and ideas on backing up and restoring SPS, see "Designing a Backup and Restore Strategy," p. 326.  |
