The 5 Best-Kept SharePoint Management Secrets

Microsoft SharePoint Server is an incredibly versatile tool for setting up portals and Web sites that facilitate communication and collaboration within a company, between companies, and with Internet users at large.

This versatility and the ability of SharePoint to boost productivity has made it the fastest-growing product in the history of Microsoft.

Many of the benefits associated with SharePoint are made possible by its tight integration with Microsoft Exchange, Internet Information Server, SQL Server and other complex Microsoft infrastructure products. As a result, managing and keeping SharePoint available and finely tuned can be challenging and time-consuming. The following five tips, tricks and shortcuts help make SharePoint easier to deploy and manage regardless of the size of your configuration, or whether you are using a physical or virtual server implementation.

#1: Don’t Stumble Into the ‘Wrong’ Configuration

Far too many companies initially implement a SharePoint configuration that is not adapted to their specific business needs. Before we discuss how to select the right configuration for your organization, here’s a quick primer on two crucial elements that will drive this decision-making process:

1. The three main SharePoint server roles:
   • Web Front End Server (WFE): Uses low to medium resources, depending on the services configured. The WFE serves the content to the audience as the go-between between the back-end database and the application server.
   • Application Server: Uses more system resources, especially for Excel Calculation services, Query services and indexing. The Application Server does all the back-end heavy lifting.
   • Database Server: Uses very high system resources. The Database Server stores and maintains all of the content that is created by the users.
2. Virtualizing SharePoint:
   

   Small configuration on physical servers

   Virtualization is a great option for making your SharePoint configuration run as efficiently as possible, because you can adapt and grow the virtualized environment faster and more easily than you can a physical server configuration. Generally speaking, virtualized SharePoint server environments provide a better user experience and are less expensive to deploy. When adding another server to a virtualized environment, often the equipment cost is literally $0.

Small SharePoint configurations can be implemented in one of two ways: separate physical servers with everything loaded on bare metal, or as a virtualized environment. Physical server configurations work well but have a higher cost of expansion. In the virtualized environment, both the WFE and the Application Server roles would exist on the same machine.

In either virtualized or physical server settings, the Database Server role would reside on a separate server to gain the flexibility to migrate to a larger farm as the organization grows.

Virtualized small configuration

A medium SharePoint configuration can support up to about 5,000 users and uses two WFEs for high availability and load balancing, a single Application Server, and two mirrored Database SQL servers, for a total of five servers. In a virtualized medium configuration, the WFE can be combined with the Application Server, but the Database Servers will still be kept on separate physical servers.

With large configurations, organizations will benefit most from choosing a virtualized environment. There are three Application Servers and five WFE roles, but one is specifically set outside of the load-balancing loop to be used for the query service role. This will maintain the user experience at the highest level possible. See the accompanying figures to get an idea of how a large virtualized SharePoint configuration can be set up.

#2: SharePoint Is Simple to Set Up – But It’s Very Hard to Set Up Correctly!

There are some pitfalls to be aware of during the SharePoint setup process.

1. Don’t use a personal account to do the initial SharePoint installation.

   Never use a personal SharePoint account to do an initial SharePoint installation, since GUID (globally unique identifier) information about the user that installs SharePoint is retained and accessed when the SharePoint Products and Technology Wizard is accessed. If the account used to install SharePoint is deleted, it may not be possible to uninstall or successfully apply patches and/or cumulative updates. Always use a domain account that isn’t a user or temporary account. The account can be disabled once the installation is complete and enabled when needed.

2. Never choose stand-alone installation.

   Microsoft gives administrators not one, but TWO opportunities to make the wrong choice here: first when you are asked to make an initial selection between Stand-Alone or Custom, and again when you select Custom, the first option presented is to do a stand-alone installation. You should never select a stand-alone installation. This will set up the SharePoint environment with Microsoft’s Free SQL Express Database Engine, which doesn’t support enterprise workloads very well. Another option available with custom installation is the ability to select the Web Front End Only configuration. This will not install any of the application server services and/or roles, which can severely limit the flexibility of the SharePoint farm in very subtle ways — one of them being the ability to quickly repurpose a WFE or APP server with SharePoint roles if one of the farm’s servers experiences a failure. To avoid these potential pitfalls, it is always a best practice to use a complete install.

3. Always use CLIConfg Tool.

   CLIConfig is a tool that is part of Windows Server 2008. This is really a hidden gem which places a “shim” between your SharePoint environment and its database back end. This tool makes it possible to revert or make changes to the environment — such as moving to a clustered or mirrored SQL Server — without having to reconfigure the entire farm.

4. Choose Kerberos over NTLM (NT LAN Manager).

   Access control issues can become overly complex in SharePoint. To simplify security issues from a user and administrator perspective, consider using Kerberos rather than NTLM. Kerberos allows pass-through authentication, eliminating some of the “double-hop” issues with NTLM when attempting to access third-party applications. You also don’t have to assign an Application Pool to each Web application, and you can instead group them logically so that the users are not prompted for authentication each time they switch between applications.

5. Use Active Directory to manage permissions.

   SharePoint has Security Groups, but it’s often easier to assign permissions using Active Directory groups for any cross-organization sites. This also eliminates possible ACL issues when you have more than 2,000 users. Although SharePoint has the ability to manage millions of users, there are limitations within its security group architecture that can surface over the life of a deployment.

#3: Monitor These Top 5 Indicators

The following five indicators are the most important (if not the only) data points that you’ll need to monitor to keep SharePoint running smoothly. That’s because they are the source of the most common problems that impact performance and the end-user experience.

ol.thisol { font-weight:bold } ol.thisol span {font-weight:normal }

1. Content Database size

   Try to keep your databases under 100 GB to limit your maintenance windows and exposure to errors while installing patches. You can use quotas to help limit your database sizes, such as a 5 GB quota, which would impose a limit of 20 sites per Content Database.

2. SPTimer Service

   The SPTimer Service functions as the heartbeat of SharePoint and controls the indexing of content, querying of content, backup/restore jobs, and profile imports. The user experience is directly related to the SPTimer Service.

3. Indexer Performance

   This service can consume lots of memory and dominate CPU resources. It should be monitored closely when using the Indexer in a mixed-mode environment. Instead of using Microsoft’s dedicated query server to monitor Indexer performance, use the host file so that you can decide which interface you want to work with.

4. User Experience

   Monitor usage reports to see what pages are loading and check if any Web Parts are causing problems. Make sure the network communication is strong and available, especially between the SharePoint environment and the database. Issues related to load balancing can be easily detected here as well.

5. Storage Usage

   Keep tabs on WFEs when used in a Query Services role, since it keeps copies of the index files and opens content to search for keywords. The Index Server itself can get very large but can be moved while in production within a small maintenance window. SQL Server databases can grow exponentially, especially in the first few months of your SharePoint deployment.

#4: SharePoint AppDev Has a ‘Rule of Two’

There are two main rules when working with SharePoint Application Development. First, deploy any custom Web parts, page layouts and any other customizations as a SharePoint solution. This will ensure that files are placed efficiently and correctly on the servers. As you do this, you’ll also want to future proof your design by preparing your solutions for SharePoint 2010.

Second, save Master Page files with SharePoint Designer, since they are put immediately into the database. Failure to save files in this manner can increase database IOPS and thus significantly slow down database performance, since every page view request based off of the Master queries the Database Server instead of the local server. For the reasons explained in rule No. 1, Master Pages should also be deployed as a solution within SharePoint.

#5: Content Management – Keep It Simple to Avoid Issues

Partly because it is so easy to deploy and use, SharePoint is particularly prone to content management issues. The most important step to take once you have your SharePoint farm up and running is to create a plan for organizing content. Assess how the content is going to be populated and look for logical groupings and breaks to balance your deployment between shared service providers, Web applications, content databases, libraries and securities.

Overloading site collections creates super-sized URLs, which are an indication that your site hierarchy has gotten too big and too complicated. This also creates issues with backup, restores and patching. There are several ways to simplify and tame the organic growth of SharePoint. Utilizing separate Web applications for business units, departments and/or content topics is a good way to keep the URL size low.

The ability to assign more than one content database size is a feature that isn’t readily apparent within the initial setup and configuration of a SharePoint environment. However, it can play a crucial role in keeping growth in check. The soft limit on content database sizes is 100 GB. Exceeding that size will increase service outage times for patching and may lead to database locking issues. Each site collection can either share a content database or have its own content database within a Web application. Take advantage of this option to set quotas so you can limit the size of the site collections and calculate in advance the size of your content databases. Also, focus on simplifying URLs and content to avoid multiple folder levels. Since content libraries can hold hundreds of documents, folders are not your friend.

SharePoint is capable of displaying multiple views to help reduce the need to dig for content. Using metadata — titles, descriptions, groupings, other searchable metadata — will allow users to customize views and find what they are looking for more easily. You can also use additional Web applications to divide sites up and display customized content for each user, which also keeps content databases smaller and decreases the time needed for restores.

Keeping SharePoint optimized for performance and availability will increase the productivity of business users and reduce the need for IT administrators to troubleshoot problems. By using these five management secrets and choosing the right virtualization configuration for your environment, you will keep SharePoint humming and receive fewer service calls than the Maytag repair man.