SharePoint Portal Server (SPS) is Microsoft’s intranet-based solution for document and information management and collaboration. SPS acts as both a full-fledged document management system, with complete version tracking and change control features, and also an intranet portal that provides company employees with a one-stop shop for locating corporate information.
SPS’s storage engine is the Extensible Storage Engine (ESE), the same storage engine behind Exchange Server and Active Directory. The ESE is a transaction-based database engine especially well-suited for the storage of hierarchical information, such as the information in a document management system. However, Microsoft has announced that it intends to replace the ESE in a future edition of SPS with Yukon, the next version of SQL Server, also known as Microsoft’s unified storage engine.
Note
Despite what you may have heard, neither SPS, Exchange, nor Active Directory use the Access database engine. The confusion comes from the fact that both Access and the ESE are based on Microsoft’s Joint Engine Technology (JET) database engine. Among other differences, the version used in Access is not transaction-based and does not scale as well as the ESE.
| For more information on what future versions of SPS will likely include, see “SharePoint Portal Server,” p. 711 |
Any single SPS server can be a document management server, indexing server, or search server. Of course, in a small environment, one server can be any combination of these, as well. In the next few sections, I’ll explain how each of these primary SPS functions works, and how you can include them in your design.
Note
Don’t confuse SPS with SharePoint Team Services. While Team Services provides somewhat similar functionality, it is in no way as scalable or robust as SPS, and does not provide SPS’s document management, indexing, or cross-enterprise search capabilities. Team Services is essentially a really scaled-down version of SPS suitable for very small workgroups or home offices. For more information on the differences between the two SharePoint products, see the SharePoint Technologies Web site at www.Microsoft.com/sharepoint.
Typical corporate information management usually consists of files located on file servers, and employees emailing files to one another through the corporate email system. Neither of those methods are especially conducive to productivity or collaboration: Since files are difficult to find, there’s no formal, system-enforced workflow associated with them, and there’s no easy way to locate earlier versions of documents. You can establish your own workflow, such as designating a particular folder for approved documents and so forth, but it’s up to you, not the server, to enforce the workflow rules that you create. SPS is designed to provide a structured, enforced environment for document management and publishing.
SPS has six basic features that provide document management functionality:
Version tracking
Document metadata
Publishing control
Routing
Document review discussions
Access control
Version tracking is the ability to track multiple versions of a document, and provide access to any version at any time. SPS implements version tracking through a check-in and check-out process. Whenever a user wants to modify a document, they check it out of SPS’s document library. While checked out, no other user can check the document out for modifications (although other users can still review the latest version of the document). When the document modifications are finished, a user checks the document back into the library. SPS automatically makes the new version available to other users, while maintaining old versions. Although you automatically receive the latest version of a document when you check it out, you can ask SPS to instead provide an earlier version, if desired.
Document metadata is additional information that describes a document. SPS implements document metadata through document profiles, which provide a means to add searchable descriptive information to documents in the SPS document library. For example, you might add attributes for the name of a project that a document is related to, allowing users to locate the document by searching on the project name. SPS can automatically promote document properties from Microsoft Office documents—including author name, document title, subject, and so forth—into the SPS document profiles. If your users are accustomed to working with Office documents, encouraging them to fill in the document properties will help make the SPS document library more useful.
Publishing control is the process of determining what documents are available to users who are searching for information or viewing documents through an SPS portal Web site (also known as a dashboard site). Essentially, the portal is a way for users to find published, ready-to-read information, and publishing control allows document managers to determine what content appears on the portal. Documents may go through several revisions before they are approved for publication, and publishing control ensures that other users only see the final version of the document, not the interim revisions.
Routing is the process of sending a document to editors, approvers, and other users, and plays heavily in the publishing control process within SPS. When a document author chooses to publish a document, SPS can automatically route the document to multiple different users for their approval before actually publishing the document. Approvers receive an email from SPS when a document is awaiting their approval, and they have the option to accept or reject the document. SPS enables you to configure your routing and approval workflows so that they match the workflow already in use within your organization.
Document review discussions are SPS’s Web-based discussions about a particular document. These discussions provide a parallel means of commenting about a document without actually modifying it. Discussions provide a central place for comments about a document, and are much more efficient than the usual back-and-forth users conduct via email when trying to get a document into just the right form. Authors can review the discussions and use them as the basis for further document modifications, and save the discussions for future reference. SPS’s discussions are threaded, making it easy to follow comments and their replies.
Finally, access control is a critical component of any document management system. SPS supports role-based security, which allows you to assign users to roles—such as author, reader, or coordinator—which define the users’ access permissions. Because roles reflect the tasks that users perform on documents, they make it easier to manage per-document access control settings. SPS also enables you to deny users access to specific documents, ensuring that confidential information remains protected.
All of SPS’s document management takes place within the SPS Web store, a hierarchical database engine based upon the ESE. Users can access the documents within the ESE by using a number of different interfaces:
SPS includes an installable file system, or IFS, which allows users to treat the Web store as a network file server, via a mapped drive letter. The concept of an IFS is not new: Windows NT (and higher) uses the IFS architecture for all of its file system. Simply put, an IFS is a file system that the operating system can use. Windows includes a number of IFSs, including FAT, NTFS, and CDFS (the Compact Disc File System). The Web Store IFS simply provides Windows with access to a new type of file system, that being the Web Store itself. With the IFS installed and configured, users can use Windows’s normal file management tools, such as Explorer, to access documents in the Web Store.
Note
While the IFS is great for retrieving information from the Web Store, it’s not ideal for creating new documents or folders. That’s because the IFS doesn’t provide the correct user interface to configure Web Store security. Instead, use SPS’s Web-based interface, which does allow you to correctly configure access permissions to objects within the Store.
The Web Store includes a built-in Web server of sorts, enabling you to retrieve information with a Web browser. The Web Store also supports HTTP extensions for distributed authoring and versioning, called WebDAV. WebDAV allows any WebDAV-compatible client (including Microsoft Office 2000 and higher) to access the objects in the Web Store directly.
SPS includes a Web-based interface that can be used to access and manage the objects in the Web Store.
A SPS document library is called a workspace. A workspace is simply a logical collection of documents, discussions, folders, categories, document profiles, announcements, and so forth. Workspaces may represent a single project within your organization, or you may create a workspace that represents common information that’s used by the entire organization. You can host a number of different workspaces on a single SPS computer, or dedicate a single server to one high-volume workspace, if desired. All workspaces on a single server are handled by a single ESE database engine.
One final feature that SPS offers for document management is subscriptions. A subscription enables users to be automatically notified when something within SPS has been updated. For example, if your company uses SPS to store business process flowcharts, then subscriptions enable SPS to automatically notify process participants whenever a flowchart related to their portion of the business is changed. Users have the ability to manage their own subscriptions, allowing them to receive notifications for the content that is most important to them.
Don’t underestimate the amount of work SPS’s document management places on a server. In all but the smallest organizations, you’ll usually want to have one or more servers dedicated to the task of document management. The maximum number of workspaces you should place on any one server is 15, although a single server won’t be able to support 15 high-volume, heavily used workspaces. Estimating the number of servers you’ll need can be difficult, due to the number of factors that affect server workload:
The number of users that will access SPS to retrieve documents.
The number of users who will be authors or reviewers, participating in the publishing control process.
The number of documents you will maintain, and the amount of metadata that each document will include.
The number of discussions, and the number of messages per discussion, that the server will support.
Whether or not the server will be used exclusively for document management, or whether it will also be used for indexing and/or searching. If the server will be used for indexing, consider whether it will simply index the documents within the workspace, or also index documents outside the workspace for extended searches.
SPS’s indexing and searching capabilities allow SPS to crawl both workspaces and external data sources to create a catalog, or index. Crawling is an automated process in which SPS examines the content located in specific sources—such as the Web store, an Exchange Server, or a file server—and picks out key words from each document, creating an index. The index can be quickly searched by SPS’s search capabilities, and index search results point to the original documents.
Note
Indexing and searching in SPS works pretty much the same way it does with any Internet search engine. The search engines crawl Web sites looking for key words. You can then visit the search engine and perform searches on those key words. The search engine displays search results with links to the Web sites that originally produced the key words, acting as a searchable online index of the Web.
SPS indexing always starts with a crawl of the workspace in which the index exists. You can also specify external content sources, which SPS will crawl and add to the index. Content sources can be represented by URLs, allowing SPS to index almost any kind of content that can be accessed via URL, whether on the SPS server, elsewhere on your network, or even on the Internet. SPS supports the following types of content sources:
Web pages and other files accessible through a Web server
Lotus Notes (4.6a and R5 databases)
Exchange Server 5.5 and higher
Other SPS servers
Files located on a file server
Whenever you create a new workspace, SPS automatically indexes it. SPS does not index any other content sources unless you specifically configure it to do so. SPS automatically updates its index when content within the workspace changes; however, when you want to update the index to reflect changes in external content sources, you must explicitly tell SPS to re-crawl those sources. You can also schedule regular crawls of external content sources to automate the re-indexing process. External sources require special configuration, such as specifying a user account that has access to the content.
Tip
Because indexing—especially of large content sources—can be extremely time-consuming and resource-intensive, SPS allows you to create index workspaces. These workspaces are used only for indexing, and do not provide the document management capabilities of a normal workspace. This allows you to dedicate an entire server to the task of building indexes.
When an index workspace has been built, you typically configure SPS to propagate, or copy, the finished index to another workspace (often on another server). That destination workspace can then utilize the index for user searches. Destination workspaces can accept up to four propagated indexes, enabling you to consolidate several indexes into a single search workspace for your users.
Searching is usually accomplished from a workspace’s dashboard site. Content returned by a search does not have to exist within the workspace; the index used by the search includes the links necessary to retrieve the original content, even if it is external to the workspace. SPS’s search functionality is provided by the Microsoft Search Service, which is the same search engine included in Microsoft SQL Server and other .NET Enterprise Servers, and a superset of the functionality included in Windows 2000’s built-in file search functionality. The Search Service analyzes indexes and compares the index content to the key words used in the search. Content is scored for relevance so that, for example, content with more occurrences of key words receives a higher score. Results are presented to users with highest-scored content first, since higher scores usually mean a more likely chance that the content is of interested to the user.
Keep in mind that indexing can quickly become quite a chore for a server, especially with large content sources. For example, creating an index that includes all of the files on your company’s ten 100GB file servers is going to consume a lot of time and computing resources (including disk space). Plan for that by including multiple indexing servers in your SPS design, and propagating completed indexes to user workspaces for searching. You might even create a centralized search server that does nothing but search, freeing up your document management servers to concentrate on document management tasks.
Here’s one way in which you might utilize indexing and searching:
Your organization includes four departments, and each will have their own SPS workspace. You’ll use two SPS servers to support them, with two workspaces apiece.
You’ll use a third SPS server to index external content. You’ll create one index workspace to index the file servers within your company. You’ll create an additional index workspace to index Web sites of interest to your company’s Accounting department, and a third to index Web sites of interest to your company’s Sales department.
The file server index will be propagated to all four departmental workspaces for use in searches. The two department-specific Web indexes will be propagated only to those departments’ workspaces.
Each department’s workspace will provide a complete, one-stop dashboard site that allows users to search for and retrieve the content of interest to them.
You should also plan to educate your users in the best ways to utilize search capabilities. As a technical professional who is probably accustomed to using Internet search engines, you may take for granted many of the practices you use to generate useful search results. Share those tips with your users, helping them to understand how to use keywords most effectively.
The dashboard is sort of the culmination of SPS’s capabilities, and it’s also a valuable feature in its own right. Dashboards provide a single Web-based interface for document management and searching capabilities, and also allow users to interact with a number of different information sources from within your enterprise and across the Internet.
A dashboard is simply a Web site. SPS automatically creates a dashboard site during installation, which allows users to immediately start utilizing the server. A dashboard site is a portal, which means it doesn’t provide information itself, but instead provides convenient access to information from a variety of different sources. The dashboard site allows users to
Search for information through SPS’s search capabilities.
Browse through categories of content.
Manage their subscriptions.
Retrieve documents using WebDAV-based document check-out, and also check-in documents that were previously checked out.
Approve or reject documents that are awaiting their review.
Publish approved documents.
Dashboard sites are built around Microsoft’s Digital Dashboard technology. This technology simply defines a standard for information modules, and allows the dashboard site to be easily customized to include other modules. Microsoft and many third-party vendors offer downloadable dashboard components—called Web Parts—which allow you to customize your dashboard site. Some of the available Web Parts include
Exchange Server-related Web Parts, which allow users to see upcoming calendar appointments, task lists, or the number of new messages in their Inbox.
News feed Web Parts provide news headlines (with links to articles) from a number of news sources.
ERP Web Parts integrate with popular ERP solutions to bring sales information and other data to the dashboard site.
Communications Web Parts—like the MSN Messenger Web Part—allow users to see which coworkers are currently online, and initiate a conversation with them.
The variety of available Web Parts is virtually endless, and you can sample the available offerings on Microsoft’s SharePoint Web site at www.Microsoft.com/sharepoint. You can also create your own Web parts (using the Web Part Development Kit, also available on the SharePoint Web site) to interface with custom applications or other internal information sources. For example, you might create a Web Part that interfaces with your company’s mainframe computer to display the number of products that have shipped that day, or how far the company has to go to reach that day’s sales goals. The point of the Web Parts and the entire Digital Dashboard concept is to bring all of your distributed enterprise information into a single place. SPS itself is a takeoff on that concept, with its document management and indexing/search capabilities that help bring information together into a single view.
Dashboard sites are associated with a single workspace. When you create a new workspace, SPS automatically creates a new site for that workspace. As a result, you should plan your workspaces to maximize the effectiveness of your dashboard sites. For example, you might plan workspaces based on functional teams or departments within your organization, so that the teams can all share a common dashboard site.
You can also create a top-level workspace for your entire organization. While it might be used for document management of common content, you could more easily use it simply as a portal site. For example, you might create an index workspace that indexed the content of all other corporate SPS workspaces. That “master index” could be propagated to the company-wide workspace, allowing company employees to search across all workspaces from a single location. That company-wide workspace could also be used to post company-wide announcements, conduct company-wide discussions, and so forth. Figure 14.1 shows how the network might look.
SPS is a fairly standalone product. It doesn’t require any other .NET Enterprise Servers in order to function. It does, however, rely on some important underlying technologies provided by the Windows operating system, and it has a strong reliance on Microsoft Office.
SPS is designed exclusively as an intranet product. It’s not necessarily designed to help you share content with individuals outside of your company (although it can do so in conjunction with Content Management Server, which I’ll describe later in this chapter). As an intranet product, SPS relies on Windows directory services to authenticate users. Unlike the majority of the .NET Enterprise Servers, which only work with Active Directory, SPS allows you to install it in either a Windows NT domain or an Active Directory domain (although you must install it on a Windows 2000 Server computer, not an NT Server computer), which gives you quite a bit of flexibility to use SPS in just about any existing Windows environment.
SPS relies heavily on IIS, as IIS provides the platform for the dashboard site, which is the primary interface for interacting with and managing SPS workspaces. You’ll need to make sure that IIS is already installed before installing SPS.
Since it uses IIS, SPS’s dashboard site can take advantage of some features IIS provides. The most important of those features is security. For example, if you want to create an SPS server that handles confidential corporate information, you can configure the dashboard Web site (in IIS) to require secure HTTPS connections, rather than allowing unencrypted HTTP connections. This would require all users utilizing the dashboard site on that server to use encrypted connections, thereby helping to protect the confidential data on the server.
Microsoft Office 2000 and higher include the functionality necessary to work with SPS’s Web Store. This functionality was originally used to access the Exchange 2000 Server Web Store, which is almost identical in architecture to SPS’s. Office XP provides better-integrated functionality, an improved WebDAV handler, and somewhat tighter integration with SPS. Office XP is actually the ideal SPS client, enabling users to check content in and out of workspaces, modify document properties, and so forth, all from within Word, Excel, or PowerPoint.
Although SPS doesn’t exactly integrate with any other .NET Enterprise Servers, you can combine SPS with other .NET Enterprise Servers to provide additional flexibility in your environment.
Content Management Server (CMS) is designed to control the workflow and publishing process for Internet Web content. The product makes a nice complement to SPS if you want to publish information from your SPS workspaces to an Internet Web site. The integration is, however, far from automatic. CMS uses SQL Server as its data store, while SPS relies on the ESE, a completely different database engine. CMS was also acquired by Microsoft from another company, and has yet to be fully integrated with the rest of Microsoft’s product lines. However, companies are using CMS and SPS in conjunction to publish selected internal content to the Web, as well as managing their main body of Web content in CMS.
| For more information on CMS’s features, see “Technology Capabilities,” p. 260 |
Microsoft recently released an Integration Pack for CMS and SPS, which is available from either product’s home page on the Microsoft Web site. The Pack provides better workflow between the two products, and helps bridge the functional gap between them. If you’re interested in using SPS to manage an internal Web development process, and then publish the finished site via CMS, look into the Integration Pack to see if it might be of use to you.
Application Center’s Network Load Balancing (NLB) feature and content synchronization capabilities can allow you to create robust search farms, capable of supporting the search requirements of very large organizations with hundreds of thousands of users. As shown in Figure 14.2, an independent SPS server with an index workspace can index whatever content you need—file servers, Web servers, and so forth. That index can be propagated to an SPS/Application Center “search farm,” where Application Center NLB can ensure that the servers’ content remains synchronized. Users are then load-balanced across the search servers, making the search farm more scalable than a single server could be.
Note
In the design diagrams in this chapter, I’ll use some custom icons to represent the tasks each SPS server is performing. A pair of glasses indicates the search functionality, a pencil indicates that the server is being used for indexing, and a stack of papers denotes document management functionality. So, the server in Figure 14.3, with all three icons, is performing all three tasks.
Exchange Server is actually incompatible with SPS, at least when installed on the same server. Although I don’t really recommend installing multiple .NET Enterprise Servers on a single server (except in the case of Application Center, which is specifically designed for it), you usually can install multiple .NET Enterprise Servers with no problem. Many organizations like to double-up on servers during an evaluation to save on hardware costs, installing products like BizTalk and SQL Server on a single computer.
In the case of Exchange and SPS, though, you can’t do it, shouldn’t try, and don’t be surprised if you do try and everything blows up. The problem is that SPS and Exchange use the exact same database engine, the ESE. In fact, if you browse through SPS’s Setup log after installation, or look through the server’s Event Viewer, you’ll notice a number of messages regarding Exchange Server. That’s because SPS simply exposes functionality and features of the ESE that have always been there. Installing Exchange breaks SPS because bits of Exchange are already installed.
In theory, it’s possible to get the two products to cooperate. In fact, early in SPS’s life, Microsoft thought companies might want to run the two products on one computer and released some white papers describing how to do it. The techniques involved were very precise and far from foolproof. Fortunately, Microsoft’s customers sensibly informed the company that they didn’t want to run the products on the same computer, and Microsoft has wisely withdrawn the papers and announced that it won’t support SPS and Exchange on the same computer.
Note
SPS has a long list of products that it won’t work and play well with, including Site Server, SharePoint Team Services, the Windows Cluster Service, and the Microsoft Office Server Extensions for IIS. Additionally, SPS can conflict with SQL Server installations, as the two products use slightly different versions of the Microsoft Search service.
SPS’s architectural abilities allow you to create a highly distributed architecture, creating a scalable environment that evenly distributes the workload of an SPS environment across many computers. Like most of the .NET Enterprise Servers, though, you can also create very realistic designs based around just one or two servers, which are suitable for smaller environments.
If you want to maintain a small SPS environment, you’ll have to decide if your primary use will be document management or searching. In either case, you can perform a smaller level of work with the other function. However, expecting a one- or two-server design to perform a large amount of document management and searching at once is unrealistic.
Figure 14.3 shows a single-server design in an environment primarily dedicated to document management. The server does, of course, index its own workspace, and in this example it’s also asked to index some files on an external file server. That indexing can be scheduled for evening hours to prevent the indexing process from interfering with daily document management tasks.
You can also perform larger-scale indexing and searching with one server, provided you only need to perform a minimal amount of document management. Figure 14.4 shows an example where one server is used to perform indexing of several file and Web servers, as well as some low-volume document management.
Unfortunately, you won’t know that you’ve hit a server’s capacity until you come close, and its performance starts to fall below acceptable levels. The best way to prepare for that time is to carefully monitor server performance and create trend charts. That way, you’ll be able to more accurately predict the point at which you’ll need an additional SPS computer or two.
| For more information on monitoring SPS performance, see “Optimizing SharePoint Portal Server Performance,” p. 599 |
Larger environments with hundreds of users and tens of thousands of documents will require multiple SPS computers. Here are some design tips you can use when constructing your SPS infrastructure:
Document management workspaces and indexing workspaces can be created on independent SPS computers. Doing so helps dedicate server resources to these tasks; indexing in particular can be resource-intensive and often needs a dedicated server.
Searching can be performed from an otherwise empty workspace by propagating up to four indexes from other index workspaces.
Multiple index and document management workspaces can be created on a single server, but spreading workspaces across servers allows each server to handle larger-volume workspaces.
No server should have more than 15 total workspaces, regardless of volume.
With those tips in mind, take a look at Figure 14.5. In this example, one SPS computer is used both for document management and searching. Its index is propagated from another SPS computer, which only has an indexing workspace. This configuration is similar to the one shown in Figure 14.4, but the indexing function has been broken out onto a separate server. Figure 14.5 is ideal for environments with small to moderate document management and searching needs, but a very large body of content that needs to be indexed.
Figure 14.6 shows a more robust search and index environment, where additional servers are utilized for dedicated searching and indexing. Remember, an index workspace can propagate its completed indexes to any document management workspace. You can use workspaces that are also used for document management, or you can use an otherwise empty workspace, dedicated the workspace—and ideally the entire server—to the task of searching the propagated indexes.
Tip
Adding index servers—a process called scaling out—only works until you’ve got four of them running, because you can’t propagate more than four indexes into a single workspace. With more than four index servers, you’re forced to use multiple search workspaces, which can be confusing for your users. One solution might be to create a main Web page that links to the multiple available workspaces.
If four index servers aren’t enough to handle your indexing workload, then scale up: Use larger, more powerful multi-processor computers with fast disk subsystems and lots of memory. Running them on Windows Advanced/Enterprise Server will allow you to install more processors and memory, allowing each server to perform more work. Datacenter Server also allows a higher degree of scaling up, at a commensurately higher price tag.
The largest SPS environments may need to dedicate a server to a single workspace, and use multiple workspaces to meet clients’ needs. Figure 14.7 shows a large environment that uses two SPS computers for document management, a third for searching, and a fourth for indexing. The search server can be made to include all workspace content from the two document management servers by instructing the indexing server to include the document management servers in its crawls.
Microsoft is hardly leading the world in document management; while SPS is an innovative product with a well-thought-out feature set, document management, indexing, and searching products are all available from a number of other companies. In the next two sections, I’ll give you a rundown of the major players.
In the Windows-based document management world, Documentum is probably the leader of the pack. With years of document management experience behind them, Documentum supports some of the important features that SPS includes, such as WebDAV compatibility, Web interfaces, document management, access control, approval routing, and so forth. Documentum is also a fairly pricey piece of software, and generally requires highly skilled architects and engineers to implement. One thing SPS has going for it is relative ease of installation: It’s one of the few .NET Enterprise Servers where you can truly just run Setup and have a perfectly working server in a few minutes. SPS even automatically launches the workspace configuration wizard after Setup completes, making it very easy to get the server up and running.
Many of the Internet’s leading search engines offer private, corporate index and search solutions. Google (www.google.com), for example, offers the Google Search Appliance, a “black box” that plugs into your network and acts as a private search server. Such “plug and play” solutions are often limited to indexing basic text files, Web pages, and perhaps Office documents; more expensive versions may include the ability to index information in an Exchange or Notes database, as well as other content sources. “Black box” solutions are less scalable than SPS and other software-based indexes, because they can’t be easily expanded to distribute the indexing load of a large environment across several devices.
Pete’s Big Beverages (PBB) has heavy-duty document management needs. Their marketing department alone manages tens of thousands of collaborative documents, and wants to use the SPS discussion features to streamline their document creation process. The rest of the company has a few thousand more documents, all of which are in a constant state of revision as the company grows its product line. The company also has several dozen file servers and internal Web servers, which contain content that employees often have to spend hours trying to find. PBB wants to consolidate all of that content into a single search engine, while leaving the actual content in the same place it currently resides.
PBB’s Marketing department also wants an in-house search engine that includes content from PBB’s competition. This specialized search will allow them to keep tabs on the competition’s press releases and other public information, helping PBB make better competitive decisions in various areas of their business.
Figure 14.8 shows the design that PBB might adopt. One SPS computer has an index workspace dedicated to indexing PBB’s internal file and Web servers, while another is dedicated to crawling competitors’ public Web sites and indexing their content. Those indexes are propagated to a single search server for all employees to use. The Marketing department will have a dedicated SPS computer for document management, and will use their workspace’s internal index for searching marketing content. The remainder of the company will use a fifth SPS computer, which will contain an index for searching collaborative documents.
In this chapter, you’ve learned how SPS is built, and how its various features can help your organization gain better control over document management and collaboration. You also learned how the architecture of SPS allows various tasks to be easily distributed, enabling you to create a highly scalable design that includes document management, indexing, and search functionality. You learned how dashboard sites can be used as a portal to your company’s information, and how the Digital Dashboard technologies can make dashboard sites a one-stop shop for all of your employees’ critical business information.