In the continuing series of year-end “tune-up” tips for your collaboration and unified communications systems from Azaleos, we focus on keeping SharePoint 2010 operating at maximum efficiency and availability. Here are its 2011 top 10 management tips for SharePoint.
Click through for 10 tips to keep SharePoint running smoothing, as identified by Azaleos.
Planning for authentication, performance, capacity and future growth, either at the initial design phase or after deployment is one of the most important exercises of building and maintaining SharePoint 2010. SharePoint is deceptively complex and lack of planning both in the initial stages as well as the long-term can cause pain points within service applications, storage and server resources that start small and become major headaches in the future.
This is one of the most underutilized features within SharePoint, yet it is critical to maintaining a properly functioning environment. SharePoint isn’t capable of self-managing the size of its database and with users constantly adding new content, the data store will continue to the grow if you don’t impose defined limits. Quotas give you the opportunity to ask the right questions in order to keep the content stored in SharePoint relevant and fresh, while maintaining a supportable database. Always start with a small quota template (typically 1GB) and grow out from there.
SharePoint 2010 has a lot of additional services beyond the ability to store content within a list or library. These other services also consume storage and resources and need to be taken into consideration when sizing a SharePoint environment. Specifically, the Search, User Profiles, Web Analytics and Usage and Health Services can quickly create storage issues and pain points that will impact performance and perceived latency. Take the time to size SharePoint appropriately for the requirements of your environment.
There are two stages for the recycle bin. The first stage is used for user-recoverable content and is stored within the site collection. This consumes space against the site collection quota (see previous slide). User-recoverable content has a default limit of 30 days, and then it is moved to the second stage recycle bin. The second stage recycle bin is used by the site collection administrator and/or support staff to recover content that may have been deleted and/or expired from the first stage recycle bin. It consumes 50 percent of SharePoint’s total quota size, so you should enforce a quota or it will continue to grow out of control.
The only types of sites that can be easily moved between content databases are site collections. Utilizing site collections to manage database storage can provide flexibility, but can also put additional boundaries within the environment. Maintaining a site collection structure based on teams, projects and departments will allow individual sites to grow organically. It also imposes some security limitations and gives each site collection a different look and feel. Understanding this beforehand will help you better plan your site collection structure.
Assigning the correct organizational units/containers within the Active Directory structure will allow the User Profile Service to only target the required users and groups. This will prevent SharePoint from accessing service and other miscellaneous accounts and ensure the optimal performance of the User Profile Service.
SharePoint’s ability to index and present query results from content sources outside of SharePoint can provide a huge benefit in an organization’s ability to find content quickly and effectively. However, it comes at a price. If your SharePoint environment is utilizing the out-of-box search (OOB) capabilities, then plan for 15 percent of the total sum of external content to be stored in order to generate the index file. If the environment is utilizing FAST Search for SharePoint 2010, then assume 30 percent. These are conservative estimates. You can possibly use as little as 10 percent for OOB search and 20 percent for FAST, but you will need to monitor it carefully as you add additional content. It is common for SharePoint administrators to overlook storage requirements for these content sources when planning for SharePoint search.
SharePoint 2010 is extremely scalable and flexible depending on the deployment architecture, but it does have limitations. Microsoft provides some guidelines around limits and boundaries for SharePoint, but these should be taken with a grain of salt. They are based on controlled lab testing that is not always representative of real-world scenarios. A good rule of thumb is to stay within 50 percent of Microsoft’s suggested limits and boundaries. This doesn’t apply to all of them, but it’s a good starting point. This will ensure that the administrative sub-systems within SharePoint stay intact and perform as expected.
Poorly designed storage architectures for SharePoint content and services databases as well as the associate log files and index files are one of the leading causes of performance problems. Proper planning for storage requirements and understanding the reads and writes that individual databases and file stores utilize will ensure SharePoint maintains expected performance levels over its lifetime. SharePoint database logs and temp DBs typically consume the majority of the storage sub-system resources, followed closely by the search and services database and file stores. Content has much lower impact on the overall performance. If your deployment is experiencing latency, whether actual or perceived, it’s always good to start here when troubleshooting.
A proper SQL deployment can mean the difference between a high-performance SharePoint deployment or a constantly sputtering system that consumes support resources and time. Ensure that your SQL deployment is adhering to best practices and that the SQL environment has the resources it needs. This includes memory and CPU resources. Make sure your SQL Server configuration is tuned to optimize performance, especially if the SharePoint deployment is an instance within a larger SQL cluster that is sharing resources. Pay close attention that the instances within the cluster aren’t over-committing resources and competing.
