Putting data into a repository is one task; getting the data out is quite another. Getting an aggregate view of the huge amount of information available in a company's network is often a difficult undertaking. SharePoint Portal Server's solution is to create one access point (i.e., the portal) to information assembled from multiple discrete sources. Everyone is familiar with Web crawlers (e.g., AltaVista) and with the problems associated with the process of assembling information through crawling. Asking a search engine to locate documents relating to a topic such as Win2K is a guarantee that you'll find many more items than you can handle; even a refined search might not be able to target the information you truly need. Combined with outdated or missing links, crawling can be a frustrating experience.
SharePoint Portal Server's crawling technology is different from Web crawling in two respects. First, the product can combine information from many different sources, including external and internal Web sites. Being able to aggregate information from network file shares, Exchange Server public folders, Lotus Notes databases, and Web sites into one search operation is a powerful feature. SharePoint Portal Server supports different types of crawl behavior—scheduled, fast incremental, notification-based, and adaptive—to provide control over the amount of crawling activity that occurs. (Adaptive crawling uses models of document volatility—literally, how often document contents are expected to change—to reduce the time spent indexing stale documents.)
Second, SharePoint Portal Server's indexing technology does a much better job of categorizing data than Web crawlers do. The server product uses support vector machine categorization, a hefty term for automatic categorization. When you provide SharePoint Portal Server with a well-structured document that uses styles and properties to convey its contents, the server's Category Assistant feature can learn from the document's structure, then automatically categorize other documents with similar structures. For example, white papers on the Microsoft Developer Network (MSDN) Web site follow a particular format. After SharePoint Portal Server learns the structure of an MSDN white paper from one example, the product can recognize other white papers that it encounters. The value of this interesting concept, however, depends on users' disciplined structuring of documents.
Note that crawling doesn't retrieve data and place it in the SharePoint Portal Server database. Just like Web crawlers, SharePoint Portal Server notes a data item's location and content, then stores that information. SharePoint Portal Server stores actual documents only when you explicitly load them into a document-management workspace.
SharePoint Portal Server uses a modified version of the search engine that ships with Exchange 2000 and Microsoft SQL Server 2000 to accommodate features such as Category Assistant and Best Bets. The latter feature helps users find the documents that might be the closest to the users' needs. A Best Bet often results from a direct match between a search criterion and a keyword set on a document. For example, if you use replication as a keyword for a white paper, SharePoint Portal Server will present the white paper as a Best Bet to anyone who searches for "replication."
Maintaining several search engines (i.e., for Exchange Server, SharePoint Portal Server, and SQL Server) is clearly inefficient, so in the future Microsoft will probably combine the engines into one system service. However, the company has given no firm indication of when this combination will happen.
A Resounding Success?
How successful will Microsoft be in creating a clear differentiation between SharePoint Portal Server and third-party document-management systems? The focus on department-level deployments is a good first step. The product's independence from AD will help encourage acceptance of the product in organizations that haven't yet deployed a Win2K infrastructure. Like all products, though, SharePoint Portal Server has some obvious weaknesses.
The inability to connect SharePoint Portal Server machines to form a seamless document-management solution for distributed organizations is one such weakness, and the relative lack of granularity in the role-based permission model is another. Lack of support for offline access is a particular pet peeve of mine, and the new server offers no equivalent of Exchange Server's offline slave replica folders. Therefore, road warriors and other offsite users must connect to the network to work with documents. Another problem comes to light when you connect across a slow connection, such as a 28.8Kbps phone link. A client PC and a SharePoint Portal Server machine transmit an enormous amount of data (relatively speaking) when users check in, check out, or publish documents. I understand that a great deal of work is probably going on behind the scenes, but Microsoft needs to reduce the bandwidth demands to make constant travelers such as myself truly happy. However, I acknowledge that SharePoint Portal Server is designed to meet the needs of people who work with documents on a daily basis, so accommodating remote access probably ranks low on the required-feature list.
Microsoft also needs to work out some obvious deployment concerns. How much difficulty will we have with the requirement that users change the way they manage documents if they want to maximize the server's benefits? How can we protect workspaces against virus-infected documents? (Sybari Software and Trend Micro are working on antivirus solutions for the product but didn't have any final releases at the time of this writing.) How do we build a disaster-recovery plan to protect a SharePoint Portal Server machine against hardware failures? Time and experience will help solve these problems, but don't expect nirvana overnight.
A Good Start
For a first release, SharePoint Portal Server incorporates a lot of interesting technology. This easy-to-use document-management server might be a fitting replacement for network file shares and Exchange Server public folders. The server will undoubtedly be a fine fit for organizations that have based their technical infrastructure on Microsoft Windows and Office. Future releases will certainly improve upon this release, but if your organization needs to bring documents under better control sooner rather than later, consider implementing SharePoint Portal Server now.