Maintain a core SharePoint Environment

In this post we will focus on three major tasks: monitoring, tuning and optimization, and troubleshooting. Monitoring is concerned with the use of tools and metrics to minimize system failures or loss of performance. Tuning and optimization expands on these concepts, providing insight into how to optimize the performance of not only SharePoint, but SQL and Internet Information Services (IIS) as well. Troubleshooting is perhaps the most complex of these tasks and is concerned with establishing performance baselines as well as using both client and server tools to troubleshoot issues as they occur.

Maintaining a SharePoint Environment need focus on these three topics

Create and configure web applications and site collections

After a new farm has been configured and provisioned, the next step is to start building web content. This content is placed within a series of site collections, stored in one or more content databases, and then presented via Internet Information Services (IIS).
After the site collections are created, security can be applied; this security enables proper access to content. Permissions-trimmed search then enables users to quickly locate appropriate content.
Some users may instead prefer to browse content from the site; effective taxonomy design by the SharePoint administration team allows for the navigation of content at a high level as well as the refinement of individual items on a site.

Creating and configuring web applications and site collections includes following consideration

Install and configure SharePoint farms

This post focuses on the installation of the servers and core configurations needed to build up a SharePoint farm.SharePoint farm can be provisioned with the help of firm design and execution of install scripts in systematic fashion

Installation and configuration of SharePoint farms includes following planning and configuration requirements

Troubleshoot a SharePoint environment

Up to this point, your SharePoint project has been all about planning, configuring, and testing.
A pristine new environment awaits and will soon provide SharePoint services to your user
base.
Over the next few weeks, users will be added to your new farm. Any shortfalls in the original
design can then be identified and documented as part of design tuning. If there are any
errors or omissions in the design, they can be examined and remedied as part of the rollout
process.

This objective covers how to:

Summary: 

  • A data collector set can be configured to capture performance counters on a regular basis for analysis.
  • A data collector set created on one server can be saved as a template and then used on another server in the farm.
  • Client-side tracing is available only for BCS.
  • Server-site traces for BCS have matching activity IDs, also known as correlation IDs.
  • The views in the SharePoint Usage and Health logging database can be analyzed and exported to Excel for further analysis.
  • Although the Developer Dashboard has three settings (On, Off, and On Demand), there are effectively only two settings: Off and On Demand.
  • The ULS log has six level settings: none, unexpected, monitorable, high, medium, and verbose.

Tune and optimize a SharePoint environment

Creating an effective SharePoint environment isn’t a one-size-fits-all task. Careful examination
of how the farm is intended to be used often exposes perceived weaknesses in the original
design. Add to that the changing requirements placed on the system by the user base, and
you have a situation that is ripe with tuning potential.
The tuning and optimization portion of your project is the chance for you to tweak the
underlying configuration of the farm, enabling you to both enhance performance metrics and
avoid any limitations placed on the system by its original design.

Tuning and optimizing a SharePoint environment require to:

Summary: 

  • Network Attached Storage (NAS) is supported only for use with Remote BLOB Storage (RBS).
  • As a rule, performance priority should be given first to TempDB files and transaction logs, then database transaction log files, then search databases, and finally database data files.
  • The model database can be used to configure the initial size of a newly created SharePoint content database, but not its autogrowth rate.
  • Splitting a SharePoint content database into multiple database files is a supported (but advanced) way to enhance its performance level.
  • A split-content database cannot be backed up or restored from within SharePoint Central Administration, but must instead be backed up from SSMS.
  • Altering values for the ASP.NET output cache, BLOB cache, and object cache require additional memory and disk resources on the web tier servers and can result in a pronounced performance gain. Additional memory and disk resources are required on the web tier servers, however.
  • The page output cache can be enabled and configured at the web application, site collection, site, or page layout levels.
  • Separating client and intrafarm communications can result in a significant networking performance gain within your SharePoint farm.

Monitor a SharePoint environment

The first few steps after implementation are often the most critical. A sudden uptick in user
adoption shortly arrives and may expose any design inconsistencies not discovered during
performance testing. Previously defined service level agreements (SLAs) with the business
may also be in effect, restricting the times that the system can be down for maintenance.
Ensuring reliability and performance levels during this period is a key requirement for
user adoption of the new platform. Effective administration and monitoring of the Share-
Point environment can capture events, addressing any misconfigurations or design shortfalls
before they affect user adoption.

We need to understand following definition and configuration requirements to monitor SharePoint Environment:

 Summary:

  • SLAs define the service metrics used within a SharePoint farm; these agreements include definitions such as “downtime,” “scheduled downtime,” and “monthly uptime percentage,” which describe the goals of monitoring within the farm.
  • SharePoint farms provide performance counters that enable you to monitor the farm at three distinct levels: server, service application, and site/site collection.
  • The Get-SPLogEvent cmdlet enables you to view trace log events (ULS logs) by level, area, category, event ID, process, or message text.
  • System Center Management Pack for SharePoint 2013 works in conjunction with System Center 2012 Operations Manager to monitor both SharePoint Server 2013 and Project Server 2013 farms.
  • Performance Monitor not only monitors Windows Server 2012 performance counters but also SharePoint counters for subsystems such as search, InfoPath Forms Services, and others.
  • Page performance monitoring is dependent on the counters presented by the ASP.NET output cache, BLOB cache, object cache, and the Distributed Cache Service.
  • The usage and health data collection service allows for the capture and centralization of SharePoint performance metrics within the logging database.

 

Manage taxonomy

Term sets contained within the Managed Metadata service work hand in glove with Share-
Point 2013 search to accomplish functionality such as navigation and product catalogs. After
the correct information has been located in search, term sets continue to provide benefit,
enabling you to both refine search results and filter content within a list.

This objective covers how to:
Subscribe to: Posts (Atom)