Microsoft Office SharePoint Portal Server 2003 and Windows SharePoint Services 2.0 are rapidly growing in popularity. What does that mean to you as an IT pro? It probably means that one or both of these tools are going to be foisted upon you to manage and extend—if they haven't already.
You can find articles and books to help you understand and manage SharePoint Portal Server and Microsoft Windows Share-Point Services (which we'll refer to collectively as SharePoint for the remainder of this article). You can also find resources that explain how to take advantage of Share-Point's many strengths, but few writers familiarize you with SharePoint's weaknesses. During our work with SharePoint, we've spent more time than we like to admit finding the gaps in SharePoint's capabilities and analyzing the potential solutions. This isn't an exercise in product bashing; we simply hope that understanding how to work around a few of the more-obvious limitations—in radical customization, internationalization or localization at the portal level, and Search scope—will make your SharePoint experience even better, right from the get-go.
Microsoft has listened carefully to its customers through means of the various programs that the company sponsors, including the Developer Advisory Council (DAC), the Partner Advisory Council (PAC), and the Technology Adoption Program (TAP). As a result of these initiatives, the next version of Microsoft Office, code-named Office 12, will address many of the gaps we identify. We're actively working with the Office 12 Beta 1 version of SharePoint, but we can't say much about these improvements until the product matures. And you'll still need to know about these gaps if you're using versions earlier than Office 12.
Gap 1: You Need to Brand Your Portal
Many companies need to brand their portals. Many portal products today rely
on XML technologies to produce architectures that are easy to customize and
extend. SharePoint relies heavily on XML, but Microsoft hasn't made a significant
effort to separate the product's business logic and underlying data from the
presentation layer—making SharePoint particularly difficult to radically
customize. (By radical customization, we mean such things as changing
the global navigation structure, modifying the search result template, or building
new SharePoint site definitions.) Many other portal vendors (e.g., BEA Systems,
IBM, Oracle, Vignette) use their products' ease of customization to position
the products against SharePoint. (These other products' architectures completely
decouple the presentation from the portal components and site structure; SharePoint
has a much tighter coupling of presentation, content, and structure.) Microsoft
has a few documents to assist with any efforts to brand SharePoint, but no one
guiding document exists.
Solve it. Successfully customizing Share-Point requires careful research. You must understand site definitions—complex sets of ASP.NET (.aspx) and XML files written in Collaborative Application Markup Language. CAML is an XML-based language that developers use to create and customize SharePoint areas, sites, and other elements (e.g., lists). Using a tool such as Visual Studio.NET (VS.NET) 2005 or VS.NET 2003 will facilitate the customization. In addition, you'll find a strong working knowledge of ASP.NET programming and of SharePoint object models helpful.
Be aware that some sources suggest using Microsoft FrontPage 2003 to customize SharePoint. Although using Front-Page is indeed the easiest way to customize a SharePoint Portal Server area or Windows SharePoint Services site pages, doing so causes SharePoint to unghost the page from its underlying template. Simply opening a SharePoint page from within FrontPage and clicking Save—even without making any changes to the page—unghosts the page.
Unghosting is the decoupling of a site or area page from the file-system template from which the site or page was derived. When a site or page is unghosted, Share-Point renders the page content and metadata from the database rather than from its originating file-system template. Any subsequent changes that you make to the file-system template won't be reflected on the unghosted page. Because of template caching, rendering pages from the file-system is likely to be faster than rendering them from the database.
Thankfully, Bluedog Limited provides a Web Part, called GhostHunter, that you can use to detect and reghost an unghosted page. GhostHunter reconnects the page to the file-system template from which the page was derived. Figure 1 shows how the GhostHunter Web Part appears on a page that's being evaluated for its ghosted state. One thing to note about GhostHunter: Any changes you make to an unghosted page are lost when you reghost the page.
Therefore, although Microsoft recommends FrontPage 2003 as the tool for customizing SharePoint, we recommend that you avoid doing so. For small team sites that require minor customization, go ahead and use FrontPage 2003, but for major customizations across many sites, use a tool such as VS.NET.
Gap 2: You Need to Support Multiple Languages in SharePoint
Portal Server
Windows SharePoint Services 2.0 improved the product's support of localized
languages to match the languages that Office supports. By installing Windows
SharePoint Services 2.0 language template packs (collectively referred to as
the Windows SharePoint Services 2.0 Language Template Pack) and configuring
regional settings, you can host multiple language sites on a Windows Share-Point
Services virtual server or in a server farm.
After installing the Language Template Pack and during site creation, you add Windows SharePoint Services sites in the supported languages. The only additional step necessary during site creation is to select the chosen language from a Language drop-down box at the bottom of the New Share-Point Site page. (Figure 2 shows a resulting site in French; Figure 3 shows the same site in Spanish.) You can also create localized sites by using stsadm.exe and the create-site operation, specifying the appropriate language pack by using the -lcid switch and the appropriate locale ID (LCID).
The Language Template Pack adds translated Windows SharePoint Services site templates to the file system for every applied pack. Windows SharePoint Services translates all supported pages and common site elements, including the navigation bar, top link bar, and quick-launch bars. Out-of-the-box Web Parts (including the inline content) are also translated, but all custom Web Parts require separate, manual localization. To see the LCIDs of the installed language packs, look under %programfiles%\ common files\microsoft shared\web server extensions\60\template on the server or servers that host Windows SharePoint Services. Each pack resides in the applicable LCID in that directory. Installed language packs also appear in the server's Control Panel Add/ Remove Programs applet.
SharePoint Portal Server doesn't provide the same flexibility in language support as Windows SharePoint Services does. Although SharePoint Portal Server and Windows SharePoint Services support the same languages, SharePoint Portal Server support is restricted to one language per portal instance. The language you select when creating a portal is the only language that any portal instance will support and is also the default language for all Windows SharePoint Services sites in that portal, even though you can host sites in multiple languages within a single Windows SharePoint Services site collection.
Solve it. If you need multilanguage support at the portal level, the most practical solution is to install multiple instances of SharePoint Portal Server. If you need multilanguage support in Windows SharePoint Services as well, you can create one Windows SharePoint Services virtual server that has multilanguage packs installed.
Even though this solution is the best one available now, be aware that installing multiple instances of SharePoint Portal Server increases the burden of administration. You must maintain multiple languages across each Share-Point Portal Server installation and must separately maintain the configuration of each portal server instance. Additionally, there's no easy way to support multiple languages on a single instance of a Windows SharePoint Services site. Trying to resolve these gaps through mirroring content on side-by-side portal instances or multiple sites (each instance or site being configured with a different language) is an additional maintenance burden. But the reality is that supporting multiple languages on any Web platform (Microsoft or otherwise) is an enormous maintenance effort. Each piece of content written in one language must be translated into any other language you plan to support. Automatic language translation technologies are available, but the results are poor. The burden of supporting a multilanguage Web platform can outweigh the maintenance burden of the solution we present here.
Gap 3: You Need to Search Across Windows SharePoint Services Sites
If you've installed Microsoft SQL Server with the Full-Text Search component
and have configured Windows SharePoint Services to use SQL Full-Text Search,
you can take advantage of Windows SharePoint Services' site-search facility.
(See the sidebar "Set Up Site Search," page 42, for details of this setup.)
Even with the SQL Server Full-Text Search component installed and integrated with Windows SharePoint Services, you can't search beyond the boundaries of the Windows SharePoint Services site from which you run a search. You can't include in the query parent or child sites in the site collection or across site collections, or content from other sources outside of Windows SharePoint Services (e.g., the file system, Internet sites). Furthermore, you can use only simple search phrases, no advanced search capability exists, and you can't search attachments to list items.
Solve it. The simplest solution is to install SharePoint Portal Server as the portal layer front end, linking it to your Windows Share-Point Services virtual server and its site collections. Then, from the portal's Site Settings—Configure Search and Indexing page, you can approve or reject sites for content indexing. The SharePoint Portal Server Search (SharePointPSSearch) service will crawl and index approved sites. After indexing is complete, a search from the portal returns results from the portal and all approved Windows SharePoint Services sites.
If you've enabled Advanced Search Administration Mode through SharePoint Portal Server Central Administration, you can further extend this site-directory search capability by creating a site-directory content source. You can add instructions to crawl non-portal content such as file shares, Microsoft Exchange Server public folders, and other Internet sites.
Programming solutions for extending Search also exist. If you host your Windows SharePoint Services sites in SharePoint Portal Server, you can replace the Windows SharePoint Services search Web control with a portal search?capable Web control to search the local site (or all sites in a site-collection hierarchy) from a Windows SharePoint Services site. Third-party solutions, such as CorasWorks Workplace Suite, include Web Parts that perform searches within a site collection or across site collections.
Mind the Gap
There are no perfect software products. Every sophisticated application has some sort of shortcoming, especially when the user base is large and diverse. Identifying gaps and proposing solutions is an essential part of assessing a product or making it work to meet specific needs. If you've identified other SharePoint gaps, tell us about them; we'll try to explore them in future articles.
Ethan Wilansky
([email protected]) is a contributing editor for Windows IT Pro and a chief technologist for EDS in its Technology Strategy and Architecture practice. He has authored or coauthored more than a dozen books for Microsoft.
Jeff Sandler
([email protected]) is a lead technologist at EDS in its Technology Strategy and Architecture practice. He has been with EDS for 15 years as an architect and developer with experience on a wide range of technology platforms.
