Tải bản đầy đủ (.pdf) (10 trang)

Designing a Microsoft SharePoint 2010 Infrastructure Vol 2 part 22 ppt

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (956.95 KB, 10 trang )

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Maintenance and Monitoring Plan 13-15
Guidelines for Configuring Diagnostic Logging

Key Points
SharePoint 2010 collects data in the diagnostic log that can be useful for
troubleshooting. The default settings are sufficient for most situations. However,
you may want to customize the settings depending upon the business
requirements and the life cycle of the farm. If you are deploying a new feature or
making large-scale changes to the environment, you can change the logging level.
You can change it to a more verbose level to capture as much data as possible
about the state of the system during the changes. You can also change it to a lower
level to reduce the size of the log and the resources that you require to log the data.
You can set the level of diagnostic logging for the event log and for the trace log.
This will limit the types and amount of information that will be written to each log.
Best Practices
The SharePoint 2010 environment may require configuration of the diagnostic
logging settings after initial deployment and throughout the system’s life cycle. Use
the following guidelines as best practices:
• Change the drive that logging writes to. By default, diagnostic logging is
configured to write logs to the drive and partition where SharePoint 2010 is
MCT USE ONLY. STUDENT USE PROHIBITED
13-16 Designing a Microsoft® SharePoint® 2010 Infrastructure
installed. Diagnostic logging can use large amounts of drive space, and writing
to the logs can affect drive performance; therefore, you should configure
logging to write to a different physical drive. You should also consider the
connection speed of the drive; if verbose-level logging is configured, many
entries are written to the log. Consequently, a slow connection may result in
poor log performance.
• Restrict log disk space usage. SharePoint 2010 does not limit the amount of disk
space that diagnostic logging can use. You should limit the disk space that


logging uses to make sure that it does not fill the disk, especially if you
configure logging to write verbose-level events. When the space that is
available to the log file is used, the oldest logs are removed and new logging
data information is recorded.
• Use the Verbose setting sparingly. Verbose logging logs every action that
SharePoint 2010 takes. Verbose-level logging can quickly use drive space and
affect drive and server performance. You can use verbose-level logging to
record a greater level of detail when you are making critical changes and then
reconfigure logging to record only higher-level events after you make the
change.
• Regularly back up logs. The diagnostic logs contain important data. Therefore,
back them up regularly to make sure that this data is preserved. SharePoint
automatically deletes when you restrict log drive space usage, or if you keep
logs for only a few days. When the threshold is met, the oldest logs are deleted
first.
• Enable event log flooding protection. You enable this setting to configure the
system to detect repeating events in the Windows event log. When the same
event is logged repeatedly, the repeating events are detected and suppressed
until conditions return to a typical state.

Unified Logging Service
Office SharePoint uses the Unified Logging Service (ULS) to write content to log
files. In SharePoint 2010, by default, the ULS log is located at C:\Program Files
\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS. When you
plan file permissions for farm administrators, you should consider allowing access
to this folder so that the farm administrator can read the log directly.
The ULS log can be difficult to interpret in text form, so you should make the ULS
Viewer available to those who must read the log. The ULS Viewer enables users
who have access to ULS log files to view the logs by using a user-friendly interface.
You can filter, sort, highlight, and append logs to help to locate data that is relevant

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Maintenance and Monitoring Plan 13-17
to the issue that you are attempting to resolve. You can use this information to
diagnose problems with machines running ULS services or to monitor machines
and the events that they create.
SharePoint 2010 uses correlation IDs, which are identifiers that are internally
associated with every request and are displayed with error messages. By searching
the ULS log for the correlation ID, you can identify the request that caused the
error and resolve the issue.
Additional Reading
For more information about how to configure diagnostic logging for SharePoint
Server 2010, see
For more information about the ULS Viewer, see


MCT USE ONLY. STUDENT USE PROHIBITED
13-18 Designing a Microsoft® SharePoint® 2010 Infrastructure
Considerations for Deploying Software Updates

Key Points
SharePoint 2010 has improved installation and management features that provide
a better end-to-end administrative experience when you install a software update.
The process of deploying software updates has two distinct phases: updating and
upgrading.
Update Phase
The update phase has two steps: the patching step and the deployment step.
The first step is the patching step. During the patching step, SharePoint 2010
copies new binary files to the Central Administration server. You must update all
servers that are running SharePoint 2010, but you should begin with the Central
Administration server to ensure that Central Administration reports the most up-

to-date information. Services that use files that have to be replaced are temporarily
stopped, reducing the requirement to restart the server. However, there are some
instances when you must restart the server.
The second step in the update phase is the deployment step. In this step, the
installer copies support files to the appropriate directories on the server that is
MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Maintenance and Monitoring Plan 13-19
running SharePoint 2010. This step ensures that all of the Web applications are
running the correct binary files and will function correctly after the software
update. The update phase is complete after the deployment step.
The next and final phase to deploy software updates is the upgrade phase.
Upgrade Phase
After you finish the update phase, you must complete the installation by starting
the upgrade phase. The upgrade phase is task-intensive and therefore takes the
most time to finish. The first step is to upgrade all of the SharePoint 2010
processes that are running. The next step is to upgrade the databases. The upgrade
process can run on a single server, so other servers in the farm can continue to
service requests.
You can postpone the upgrade phase. However, inconsistent farm behavior may
result from postponing the upgrade for more than several days. If you postpone for
a longer period, you increase the risk that farm behavior issues will occur.
Planning Considerations
When you plan the deployment of software updates and service packs, you should
consider the following features:
• SharePoint 2010 supports backward compatibility between update versions on
different servers. This enables you to install the update binary files and
postpone update completion to a later time.
• You can use a staging environment to ensure that the software update will
function correctly in your SharePoint 2010 environment.
• There is full support for automatic updates that use Windows Server Update

Services (WSUS), Windows Update, and Microsoft Update. An automatic
update will install the binary files on the farm servers, but you must complete
the software update by running the upgrade on the servers.
• Administrators can monitor the status of the update by using the Central
Administration Web site or Windows PowerShell.

Additional Reading
For more information about software updates in SharePoint Server 2010, see

MCT USE ONLY. STUDENT USE PROHIBITED
13-20 Designing a Microsoft® SharePoint® 2010 Infrastructure
Considerations for Maintaining Staging and Development
Environments

Key Points
When you develop a maintenance plan for SharePoint 2010, you should consider
the different environments in your organization. Large organizations may have a
number of SharePoint 2010 environments, including production, staging, and
development. Each environment has a different role to play in the maintenance of
the SharePoint 2010 infrastructure as a whole.
Many organizations implement various environments to meet their business goals.
Depending on the environments that your company implements, you will need to
ensure that they are managed in an appropriate manner.
Staging Environment
Staging environments provide a safe environment for testing changes to your
SharePoint 2010 infrastructure before you deploy them in the production
environment. A staging environment should therefore mimic at least the key
features and configuration of the production environment to provide a useful
testing platform.
MCT USE ONLY. STUDENT USE PROHIBITED

Designing a Maintenance and Monitoring Plan 13-21
You should use staging environments to perform final tests on the solutions and
content before they are published to content consumers and end users.
Consider using a staging environment to test:
• Incremental updates of data.
• Deployment of software updates.
• Service packs.
• Custom components.
• Add-ons and integrations.

Development Environment
Development environments are used by developers who create custom
components such as Windows Workflow assemblies, Web Parts, and event
handlers. The development environment is not usually identical to the live
production environment, because it typically includes developer tools such as
Microsoft Visual Studio® 2005, and Microsoft Visual Studio Team Foundation
Server.
You should use development environments to provide a platform for the
development of SharePoint 2010 solutions, custom code, and other development
features.
Consider using a development environment for:
• The distribution and management of development virtual machines (VMs).
• License management.
• Source control.

MCT USE ONLY. STUDENT USE PROHIBITED
13-22 Designing a Microsoft® SharePoint® 2010 Infrastructure
Discussion: Developing a Maintenance Plan

Key Points

Question: You must develop a wide-ranging maintenance plan for your SharePoint
2010 infrastructure. What categories would you use to organize your maintenance
tasks?
Question: What is the next step in developing a maintenance plan?
Question: Give examples of tasks and activities for each category that you have
defined.

MCT USE ONLY. STUDENT USE PROHIBITED
Designing a Maintenance and Monitoring Plan 13-23
Lesson 3
Creating a Monitoring Plan for SharePoint
2010

The monitoring features in SharePoint 2010 help you to check how the SharePoint
2010 system is running. Monitoring tools such as SharePoint Health Analyzer and
Performance Monitor help you to analyze and resolve problems, and view metrics
for the sites.
Objectives
After completing this lesson, you will be able to:
• Describe considerations for using SharePoint Health Analyzer.
• Describe considerations for logging usage and health data in SharePoint 2010.
• List guidelines for monitoring search.
• List guidelines for using Performance Monitor to monitor SharePoint 2010.
• Discuss how to develop a monitoring plan.
MCT USE ONLY. STUDENT USE PROHIBITED
13-24 Designing a Microsoft® SharePoint® 2010 Infrastructure
Considerations for Using SharePoint Health Analyzer

Key Points
SharePoint 2010 includes SharePoint Health Analyzer, which is a new analysis tool

that enables you to check for potential configuration, performance, and usage
problems. SharePoint Health Analyzer runs predefined health rules against servers
in the farm. A health rule runs a test and returns a status that tells you the outcome
of the test. If any rule fails, the status is written to the Health Reports list in
Microsoft SharePoint Server 2010 and the Windows event log. SharePoint Health
Analyzer also creates an alert in the Health Analyzer Reports list on the Review
problems and solutions page in Central Administration. You can click an alert to
view more information about the problem and see steps to resolve the problem.
You can also open the rule that raised the alert and change its settings.
You can edit Health Analyzer Report list items, create custom views, export the list
items into Microsoft Office Excel®, subscribe to the RSS feed for the list, and
perform many other tasks. Each health rule falls into one of the following
categories: Security, Performance, Configuration, or Availability.

×