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:

Manage search

One of the cornerstone technologies present in SharePoint 2013, search is pervasive. The
capability to search and render content can appear in navigation, filtering, search queries, and
many other locations. Search is also capable of reaching across boundaries, surfacing content
present in other line of business systems.

This objective covers how to:

Manage site and site collection security

Securing a SharePoint installation can involve several different configuration levels. These
levels vary in complexity from simply granting or removing access to a single item to deciding
what applications should be run on a web application or what content can be displayed
within a site.

This objective covers how to:

Create and maintain site collections

Now that all your web applications are created, and users are capable of effective authentication to your web applications, it’s time to turn your attention to configuring individual site collections within this environment. The initial architecture of the environment starts to take shape as site collections begin to follow one of two possible structural designs.
Additionally, well-governed provenance of self-service site collections enables users to
begin to collaborate in a managed fashion.

This objective covers how to:

Provision and configure web applications

The web applications that support your SharePoint installation are the first component that
your users encounter. An incorrectly configured web application can vary in experience
from being entirely nonfunctional (misconfigured authentication mechanisms) to being
functional but inconsistent (in the case of poorly configured alternate access mappings).
Configuring this level of the farm also becomes your first effort at maintaining effective
security and governance mechanisms.

This objective covers how to:

Create and configure a User Profile Service application

The User Profile service (UPA) application is a collection of databases and functionality focused
on individual users in a SharePoint 2013 installation. This functionality can be limited in
scope to a single farm or made available across multiple SharePoint farms in the enterprise.
This service is used to provide user profiles, profile synchronization with enterprise directory
services, audiences, the My Site host and individual My Sites, and social notes and tagging.

This objective covers how to:

Create and configure a Managed Metadata Service application

The Managed Metadata Service (MMS) within a SharePoint farm provides a way to define
taxonomical structures that can be carried out through the entire farm. These structures
include term sets, which can be used for assigning metadata to lists/documents and controlling
navigation, and content type hubs, which can be used to centralize and standardize the
deployment of specific content types within your enterprise.
This objective covers how to:

Create and configure enterprise search

Creating an effective Enterprise Search implementation is probably the most complex component
of a SharePoint installation. Defining how Search will connect and extract information
from disparate sources will require detailed administrative interaction with other system
administrators to be successful.
This objective covers how to:

Plan and configure farm-wide settings

After the initial installation of your SharePoint farm is complete, the next logical step is to
configure some of the core farm services that are used across all web applications and sites.

This objective covers how to:



Plan installation

In this section, we will cover the configuration steps required to set up a SharePoint farm
at a very basic level. Establishing a core infrastructure plan that is both repeatable and well
managed will help guide us toward the goal of a solid SharePoint installation.
This objective covers how to:

Plan and configure farm-level security

The last objective focused on securing the farm from intrusion and data corruption from external sources. This objective focuses instead on how to secure the farm from the inside, assigning the appropriate administrative permissions and creating policies that help secure assets contained within the SharePoint infrastructure.
This objective covers how to:

Plan and configure platform security

Securing a SharePoint environment requires a significant amount of coordination between
the networking, data, and SharePoint team at your organization. Configuration efforts vary in
scope from altering core settings on your SharePoint web tier servers to altering SQL settings
at the data tier, and enabling/disabling firewall configurations at the networking level. All
these changes combine to form a more secure SharePoint implementation.
This objective covers how to:

Plan and configure authorization

After a user has been authenticated, he or she can then be validated when attempting to
interact with resources in a web application; this validation process is called authorization.
This objective covers how to:

Plan and configure authentication

Authentication is a mechanism within a system that verifies the identity of the requestor as
genuine; this mechanism has nothing to do with the assignment of rights or permissions.
After a requestor has been authenticated, authorization can then be granted, providing access
to system resources.
Authentication is required on three different occasions for on-premise installations of
Microsoft SharePoint:
  • User authentication A user is trying to access SharePoint resources
  • App authentication An installed app is trying to access SharePoint resources
  • Server-to-server (S2S) authentication Two-way resource access between servers
    (Exchange/Lync/SharePoint) in the enterprise

SharePoint does not provide any authentication mechanism; it merely uses those provided
by other systems. The Active Directory Domain Services (AD DS) provider is a good
example of an authentication mechanism that can be used by SharePoint.
This objective covers how to:
Subscribe to: Comments (Atom)