Use these workarounds to avoid inevitable frustration with minor annoyances
Microsoft's 2007 wave of SharePoint Products and Technologies—including Windows SharePoint Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007—contains robust document management, collaboration, and web content management capabilities right out of the box. Over the years, however, organizations that have deployed SharePoint 2007 have vocalized certain annoyances about the product. These annoyances don't amount to insurmountable obstacles, but they can prove to be discouraging to administrators charged with maintaining and optimizing a SharePoint environment.
Every SharePoint administrator probably has a unique list of frustrations, but I've come up with a list of the most common annoyances that I've encountered. Most of these problems have workarounds that the administrators can use to mitigate their effect; others require the help of the third-party solution.
By default, built-in links and navigation to SharePoint sites don't extend beyond the site collection level. In other words, each site collection acts as a navigational island, showing only links to sites within the individual site collection. Clicking the Home button in a site collection takes a user to the root of a site collection—not to the root of the web application. This idiosyncrasy can be confusing to end users, especially in environments that have many site collections.
Best scalability practice is to deploy multiple site collections—to spread them among content databases and to provide for better manageability. So, many SharePoint administrators find themselves with no obvious way to create a single seamless web experience for their users, with one Global Navigation solution for all site collections within a web application.
Microsoft provides the ability to modify Global Navigation by using a SiteMapProvider—specifically, the Microsoft.SharePoint.Navigation.SPXmlContentMapProvider—and by modifying the master page to reference the custom SiteMapProvider. However, this isn't a solution that users can modify within the default GUI. You can find further information about this SiteMapProvider in the Microsoft article" SPXmlContentMapProvider Class (Microsoft.SharePoint.Navigation)" at msdn.microsoft.com/en-us/library/microsoft.sharepoint.navigation.spxmlcontentmapprovider.aspx.
All SharePoint content is stored in a series of content databases stored in a Microsoft SQL Server database. These content databases store all documents, list data, web parts, and other customizations and are therefore a crucial component of a SharePoint environment. Unfortunately, however, Microsoft—by default—deploys only a single content database for a new web application, and many organizations have let this single database grow larger than 100GB (the maximum recommended size for a content database).
To work around this problem, Microsoft recommends creating more than one content database and deploying content across multiple site collections. The downside is that there's no way in the GUI to determine which database a new site collection will go into. Trying to organize content by database—for example, giving a specific department its own content database—can get frustrating.
There are two possible solutions to this problem. The first solution is the easiest, but it applies only when you're creating a site collection in a new content database. For this scenario, simply create the site collection using the Stsadm command-line utility and use the -createsiteinnewdb switch. For existing content databases, simply increase the maximum number of sites that can be created in that database under the Content Databases link in the SharePoint Central Admin tool. Set the number to be much higher than any other database, and SharePoint will automatically home the site collection there.
Although SharePoint can tie into and use Active Directory (AD) security credentials for authorization, there are limitations to this concept when you use AD groups for granting security rights. If an administrator wants to grant all the members of an AD group rights to a site collection, for example, he or she can add them from within SharePoint, but there's no way within the administrative interface to determine who is a member of a specific group. Instead, the administrator needs to leave SharePoint and use a different tool such as the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in to determine the membership of the group.
There's no easy, native way to overcome this limitation from within SharePoint, but there are third-party administration solutions for SharePoint and custom-built utilities that perform LDAP lookups against AD to help overcome this annoyance. One solution, an RSSBus web part (www.rssbus.com/products/sharepoint/templates/template.aspx?webpart=ldap.ListGroups), allows for this type of functionality.
Depending on the method by which users access SharePoint, and the security settings of the browser, users might end up having to authenticate multiple times throughout their session. This problem is particularly true when a Microsoft Office client such as Word or Excel is in use.
Fortunately, this annoyance is fairly well documented, and can typically be resolved by changing browser security to automatically use the user’s credentials or re-use the credentials initially used. For most organizations, this means adding the SharePoint server URL to the Local Intranet security zone in Internet Explorer (IE), which should remove most repeat authentication prompts.
The concept of the Shared Services Provider (SSP) in SharePoint 2007 creates a host of scalability annoyances that SharePoint administrators have been dealing with for years. For example, there can be only one index server per SSP, which makes the indexing component non-redundant and requires setting up scenarios involving index servers in different farms, indexing content from other locations. Other farm architectural limitations limit the scalability of SharePoint in ASP models—most notably the requirement that every web role server contain every web application in that farm, which significantly increases overhead and reduces the number of web applications that can be deployed.
The good news is that SharePoint 2010 does away with the concept of the SSP. The new version replaces SSPs with a Services model, in which every shared service has a corresponding SQL Server database that farm members utilize. In addition, the restriction of having all web applications on every web role server is gone.
The bad news is that these annoyances are difficult to address in SharePoint 2007. However, administrators have had some success with third-party solutions for making the index component redundant and scaling SharePoint by creating multiple farms. Management of these types of environments can be cumbersome once you reach a certain scale, however, which explains why SharePoint 2010 kills SSP.
Every technology has its annoyances, making its users wonder what the developers were thinking! This article is by no means an exhaustive list of all the SharePoint idiosyncrasies that can lead administrators to yank out their hair, but it should provide an understanding of some common problems. With a good understanding of SharePoint's limitations—and the right workarounds—the product's limitations can be overcome. And let's look forward to the inevitable improvements in SharePoint 2010.