Microsoft SharePoint Server 2010 1/4/2010 Microsoft Corporation Rohit Sharma PFE Contents S.No TOC 0 New Feature & Improvements 1 Surveys 2 Content Type 3 Record Center 4 Indexing 5 Workflows 6 SPD Workflow 7 Three State Workflow 8 Approval workflow 9 Upgrade From MOSS to SPS 2010 10 Patch Management 11 Security 12
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Microsoft SharePoint Server 2010 1/4/2010 Microsoft Corporation Rohit Sharma PFE
Contents S.No
TOC 0
New Feature & Improvements 1
Surveys 2
Content Type 3
Record Center 4
Indexing 5
Workflows 6
SPD Workflow 7
Three State Workflow 8
Approval workflow 9
Upgrade From MOSS to SPS 2010 10
Patch Management 11
Security 12
Microsoft Corporation Page 1
NEW FEATURES SPS 2010
SharePoint 2010 Top 10 Features and Resources
Sites
In 2007, we expanded SharePoint to a single platform for intranet, extranet and internet sites. For
SharePoint 2010, we improved the experience for this range of sites spanning browsers, Microsoft
Office and mobile devices. The top five investment areas here are:
1. SharePoint Web Experience – We updated the SharePoint UI to make it simpler to access a
growing range of tools. Highlights include incorporating the Office ribbon, in place web editing, AJAX
responsiveness and richer navigation. We also expanded the reach of SharePoint sites through multi-
lingual support, improved accessibility including WCAG 2.0 support and cross-browser support built on
XHTML compliance.
2. Office Client – We continue to support previous versions of Microsoft Office working against
SharePoint 2010. Office 2010 enhances this with features like offline editing with asynchronous saves
as well as exposing SharePoint features through the new Office Backstage UI. Via the Backstage, you
can access the context around the document including tags, related tagging and people.
3. SharePoint Workspace – In this release, we evolved and renamed Groove as SharePoint
Workspace which provides great local and offline read-write access to SharePoint lists and libraries.
SharePoint Workspace has a consistent experience with Office 2010 and SharePoint 2010 including the
Office ribbon. It supports advanced features like bringing external business data offline and is smart
about synching changes and not entire files.
4. Office Web Apps – We made SharePoint 2010 a great place to host the new Office Web Apps so
you can view and update content from within a browser and include Office content as part of your web
site (e.g. an Excel spreadsheet as part of “Sales Metrics Portal"). The Office Web Apps provide a
familiar user experience, high fidelity viewing and essential editing without loss of data or formatting.
They include Word, Excel, PowerPoint and OneNote. The OneNote client and Web App support is one
of the coolest features of the release to enable multiple people to collaborate on a rich canvas online
or offline. In addition to the Office Web Apps, we updated InfoPath Forms Services and Excel Services
and added, new for 2010, Visio and Access Services.
5. SharePoint Mobile Access – We both improved the experience for mobile web browsers and are
introducing a new SharePoint Workspace Mobile client so you can take Office content from SharePoint
offline on a Windows Mobile device. These clients let you navigate lists and libraries, search content
and people and even view and edit Office content within the Office Web App experience running on a
Content Type in MOSS First we will understand what these content types are. Content Types in MOSS can be treated as a base class with must inherit attributes. Content Types can be created and then used at sites and sub sites on the list and document library level.
In this exercise, you create a custom content type. Then you add two fields to the content type: a new text field
and a field that already exists in Web site. To complete this task, you must do the following:
Create a SharePoint 2010 Project
In this task, you create an empty SharePoint 2010 project in Microsoft Visual Studio 2010.
To create the SharePoint project
1. To start Visual Studio 2010, click the Start Menu, click All Programs, click Microsoft Visual Studio
2010, and then click Microsoft Visual Studio 2010.
2. On the File menu, point to New, and then click Project.
3. In the New Project dialog window, in the Installed Templates section, click Visual C#, click
SharePoint, and then click 2010.
4. Select Empty SharePoint Project from the project items.
5. In the Name box, type Create ContentType and then click OK.
6. In the SharePoint Customization Wizard, type the local Web site that you want to use for this exercise
(such as http://localhost/SampleWebSite).
7. For the trust level, select Deploy as a farm solution and then click Finish.
Create a Content Type
In this task, you create the content type as a feature and add an event receiver.
To create a content type
In this article I am showing you how to create an external content type for sharepoint 2010.
Here I am showing three things
Creating External Content type.
Creating External Data column for list.
Creating External List
Before starting ,you should have an SQL server Table.I have a database with the name BCS
and a table named BCS_customer with two columns NameID and Name
The approval workflow is a simple workflow that Routes a document for approval.
Approvers can approve or reject the document, reassign the approval task, or request
changes to the document. The initial workflow association page is the same as for other
workflows with all the same options.
On the workflow configuration page the options are customized to the approval workflow
and as you can see are quite different from that of the Three Stage Workflow.
Microsoft Corporation Page 68
Starting from the top of the page you have the option to use parallel or serial task
assignment. Below the workflow tasks section you can specify who the approvers are for
a particular instance of the workflow. If you are running tasks in serial mode then the
order that approvers are listed will be the order that tasks are assigned in. Below the list
of approvers is a checkbox that determines whether or not to expand groups. If groups
are not expanded then one task is assigned to the entire group rather than one task per
member. Following that you have the option to allow changes to the list of approvers
when the workflow is started. You can include a custom message if desired and choose a
due date if using parallel mode or a number of days before tasks are due when using
serial mode. Additionally there is a cc list that will include users who are notified but will
not have tasks assigned.
In the lower part of the page you have some general settings that effect workflow
completion.
Microsoft Corporation Page 69
You can specify a number of completed tasks to determine when the workflow is
complete. This is useful when using parallel approval since you may not need every
approver to approve the document. In other words you may have six approvers but only
require four of them to approve before the workflow is completed. You can also choose
to stop the workflow if the document is rejected by anyone or if the document is changed
before approval can complete. Lastly since a document library can require approval for
new content it is also possible to use the workflow to control the approval status in the
metadata for the document. Thus the workflow can automatically set the document to
be approved when the workflow completes. If approval is required on the document
library and you do not allow the workflow to update the status a user will have to
manually approve the document.
The workflow task that is assigned for this workflow allows the user to give feedback on
the document as well as to reassign the task to someone else or to request a change.
Microsoft Corporation Page 70
As the workflow name indicates the task is complete when the document is approved or
rejected.
Microsoft Corporation Page 71
Upgrade
Microsoft Corporation Page 72
Contents
CREATING A SURVEY IN SPS 2010 ...................................................................................................... 13
CONTENT TYPE IN MOSS ....................................................................................................................... 41
CREATE A SHAREPOINT 2010 PROJECT .......................................................................................................... 41
To create the SharePoint project......................................................................................................................... 41
CREATE A CONTENT TYPE.............................................................................................................................. 41
To create a content type ..................................................................................................................................... 41
MANAGEMENT DASHBOARD .............................................................. ERROR! BOOKMARK NOT DEFINED.
AUDIENCE TARGETING ................................................................................ ERROR! BOOKMARK NOT DEFINED.
SharePoint Server 2010 Audiences: also for anonymous users .............................. Error! Bookmark not defined.
Preparing the website ............................................................................................ Error! Bookmark not defined.
Demo – Default Workflows: Three State Workflow ............................................................................................ 54
Demo SPD Workflow ........................................................................................................................................... 60
Test the Upgrade............................................................................................................................................... 100
SECTION 3: PERFORMING THE UPGRADE ......................................................................................................................... 104
Performing an In-Place Upgrade ...................................................................................................................... 105
Performing a Database Attach Upgrade........................................................................................................... 107
Performing a Database Attach Upgrade (continued) ....................................................................................... 112
Validating the Upgrade ..................................................................................................................................... 114
MODULE 2: GENERAL ADMINISTRATION AND SERVICE APPLICATIONS ....... ERROR! BOOKMARK NOT DEFINED.
SECTION 1: CENTRAL ADMINISTRATION .......................................................................................................................... 131
Central Administration Home Page .................................................................................................................. 132
Central Administration Ribbon Menu ............................................................................................................... 135
Demonstration: Exploring the Central Administration Ribbon Menu ............................................................... 136
Web Applications .............................................................................................................................................. 137
Creating New Web Applications ....................................................................................................................... 138
Lab 2A: Creating a Web Application ................................................................................................................. 140
Site Collections .................................................................................................................................................. 141
Creating New Site Collections ........................................................................................................................... 143
Changed Timer Job Features ............................................................................................................................. 147
Improved Timer Job Features ............................................................................................................................ 151
Preferred Timer Server ...................................................................................................................................... 154
Lab 2B: Managing Timer Jobs ................................................................................ Error! Bookmark not defined.
SECTION 3: SERVICE APPLICATIONS ................................................................................................................................ 158
SSPs vs. Service Applications ............................................................................................................................. 159
Service Application Flexibility ............................................................................................................................ 162
Service Application Model ................................................................................................................................. 164
Service Application Proxy .................................................................................................................................. 168
Creating Service Applications ............................................................................................................................ 170
Managing Service Applications ......................................................................................................................... 173
Lab 2C: Creating and Managing a Service Application .......................................... Error! Bookmark not defined.
Classes of Service Application Administrators .................................................................................................. 176
Connecting Web Applications to Service Applications ...................................................................................... 178
Customizing Service Application Proxy Groups ................................................................................................. 181
Publishing and Connecting to a Service between Farms ................................................................................... 184
What’s Inside a Patch? ...................................................................................................................................... 193
Types of Updates ............................................................................................................................................... 195
Types of Updates (Continued) ........................................................................................................................... 197
Service Pack and Cumulative Update Interaction ............................................................................................. 198
Overview of the Patching Process ..................................................................................................................... 199
Monitoring the Status of Updates..................................................................................................................... 213
The Preparation Phase ...................................................................................................................................... 218
Minimizing Downtime Using Parallel Database Upgrade ................................................................................. 220
Minimizing Downtime Using Read-Only Databases ......................................................................................... 222
Upgrade Order and Parent-Child Farms ........................................................................................................... 224
Note: Look for sites or webs where InSiteMap="False". The value false indicates that the site is orphaned. The enumallwebs operation also includes the site GUID (Site ID) of all sites and webs.
After the orphans have been discovered, the next step is to delete them from the environment. The
STSADM operations deletesite and deleteweb have been modified to include a -force parameter
(introduced in SP2) that enables the deletion of orphaned sites. To delete the orphaned sites or webs,
specify the appropriate Site ID (or Web ID) and include the -force parameter.
Delete orphaned site collections
The syntax to delete orphaned site collections by using deletesite is:
Note: gradualdelete parameter was introduced in the April 09 Cumulative Update and deletes larger sites in chunks to prevent performance issues to the environment during deletion.
Database repair tool
You can also remove orphaned items or sites by using the STSADM databaserepair operation. The
databaserepair tool can detect and repair database corruption for many common types of orphaned
situations; for example, when a child site, library, or page does not have a parent container.
The syntax to delete orphaned items or sites by using databaserepair is:
stsadm.exe -o databaserepair
-url <url name>
-databasename <database name>
[-deletecorruption]
The following example shows how to use the databaserepair operation:
Defragment indexes by either reorganizing them or rebuilding them.
Shrink databases to recover unused disk space.
Note: Shrink operations are most effective for a large file or site that has the potential to generate a large quantity of unused space on deletion. Database files can only be reduced to the point where there is no free space remaining.
You can perform SQL database maintenance tasks by running either Transact-SQL (T-SQL) commands or
the Database Maintenance Wizard.
Note: Review the guidance in the database maintenance for Office SharePoint Server 2007 (white paper) at http://technet.microsoft.com/en-us/library/cc262731.aspx.
Use for small non-critical or non-production environments
Advantages
• Farm-wide settings are saved and upgraded
• Customization are already present in the environment
• New hardware is not required
Disadvantages
• The environment is offline while the upgrade is in progress.
• The roll-back plan includes disaster recovery of the original
environment.
• No ability to prioritize how the content databases are upgraded
• No ability to upgrade content databases in parallel for increased
performance.
In the prepare phase, you need to determine the upgrade approach right for your environment.
SharePoint 2010 offers the following four upgrade approaches, each with its pros and cons:
In-place upgrade
Database attach upgrade
Hybrid 1: Read-only databases
Hybrid 2: Detached content databases
This topic focuses on in-place upgrades.
Overview
Performing an in-place upgrade involves installing Microsoft SharePoint Server 2010 (MSS) on the same
hardware running MOSS, or installing Microsoft SharePoint Foundation (MSF) on the same hardware
running WSS 3.0. The in-place upgrade approach upgrades all content and settings from the original
farm as part of a single process. During an in-place upgrade, the entire environment is offline and is not
available until the upgrade completes. In some cases, the quickest and easiest way to upgrade to
SharePoint 2010 is to perform an in-place upgrade. This type of upgrade takes place on existing
hardware, and overwrites the previous SharePoint version.
Many existing MOSS or WSS 3.0 environments do not meet the minimum hardware and software
requirements to run MSF or MSS. You must first upgrade such environments to 64-bit hardware and
software before running an in-place upgrade.
Microsoft Corporation Page 96
Microsoft highly recommends creating a full backup of the environment prior to running an in-place
upgrade. This is because an in-place upgrade cannot be undone once it is started; you will need to use
disaster recovery processes to recover the existing environment.
During an in-place upgrade:
1. The configuration database and the Central Administration site are upgraded.
2. Server-specific data, such as settings within Central Administration, is upgraded.
3. Each Web application, along with each site collection within, is upgraded.
Once the upgrade process is complete on one server, it needs to then be run on all other servers in the
farm, one by one.
Supported scenarios
Microsoft recommends using in-place upgrade for the following scenarios:
A small development (non-production) environment that meets the hardware and software
requirements of MSF or MSS
A small (non-critical) production environment that does not require user access to the content
during the upgrade and that meets the hardware and software requirements of MSF or MSS
Microsoft does not recommend using in-place upgrade for the following scenarios:
Critical production environments that cannot afford to be down for maintenance during the
upgrade process
Large production environments with very large databases
Advantages
An in-place upgrade offers the following advantages:
It saves and upgrades farm-wide settings to MSF or MSS.
Customizations are already present in the environment.
It does not require new hardware.
Site users can use the same URL after the upgrade.
Disadvantages
The disadvantages of an in-place upgrade are:
The environment is offline while the upgrade is in progress.
The rollback plan includes disaster recovery of the original environment.
You cannot prioritize how the content databases are upgraded.
You cannot upgrade content databases in parallel for increased performance.
Microsoft Corporation Page 97
Database Attach Upgrade
15
Database Attach Upgrades
Use for production environments with large databases and
where uptime is critical, or when you are changing hardware
Advantages
• Leverages new hardware
• Approach is easy to test and validate
• Parallel upgrade possible to reduce upgrade time
• Multiple farms can be combined into one farm
Disadvantages
• Farm-wide settings not transferred
• Customizations must be manually installed
• Need direct access to the database servers
• Time consuming
Overview
The database attach upgrade method involves migrating content databases from one SharePoint farm
to another. The destination farm must have all of the settings and customizations in place in order for
the migration to be a success. The old environment is never touched and can be used as a rollback plan
in case the migration fails.
You can use the database attach upgrade to attach content databases, Shared Services Provider (SSP)
databases, and project databases. However, you cannot use it to attach Configuration and Search
databases.
The database attach approach offers improved performance when upgrading large environments
because it enables you to upgrade multiple databases in parallel and also prioritize the order in which
content databases are upgraded based on your business needs.
Microsoft recommends the database attach approach for most production environments because it
involves standing up a clean SharePoint 2010 environment on new hardware, and the rollback plan
simply involves continuing to use the untouched MOSS 2007 or WSS 3.0 environment.
Microsoft recommends using database attach upgrade for the following scenarios:
Production environments where access to data during the upgrade is critical
Environments that require Web applications to be upgraded in phases
Environments with large content databases (above 100 GB)
Microsoft Corporation Page 98
Environments with multiple content databases that can be prioritized and upgraded in parallel
Environments that do not meet the minimum hardware and software requirements for MSS or
MSF
Advantages
A database attach upgrade:
Leverages new hardware.
Is easy to test and validate without any impact on production.
Allows performing parallel upgrade to decrease the amount of time required to complete the
upgrade.
Involves a simple rollback plan.
Allows combining multiple farms into one.
Disadvantages
The disadvantages of a database attach upgrade are:
Farm-wide settings must be recreated in the new environment before the upgrade.
Customizations must be manually installed in the new environment.
It needs direct access to the database servers.
Copying databases over the network (if moving to a new database server) can be time
consuming.
Microsoft Corporation Page 99
Hybrid Upgrade
16
Hybrid Upgrade Approach
Hybrid 1: Read-Only Database
• Migration to the new environment while the old environment is
still online and read-only
Hybrid 2: Detached Content Databases
• In-place upgrade of an existing farm where the content
databases are detached.
You can slightly modify the in-place upgrade and database attach upgrade methods to create a hybrid
upgrade approach. For example, when performing an in-place upgrade in an environment with many
large content databases, first disconnect the content databases before the upgrade. After the in-place
upgrade completes, perform the database attach upgrades in parallel to speed up the process.
There are two hybrid approaches to consider.
Hybrid 1: Read-only databases
Perform a content database migration to a new environment, while providing read-only
access to the old environment during the upgrade process.
This method provides data access to the original environment, while the upgrade is being
completed.
Hybrid 2: Detached content databases
Perform an in-place upgrade of the farm with detached content databases. After the upgrade
completes, attach the content databases in parallel (on the same farm or in a separate farm).
This method allows you to upgrade the farm settings and services, while also taking
advantage of the speed and efficiency of the parallel upgrade approach.
Microsoft Corporation Page 100
Test the Upgrade
17
Test the upgrade
Build test farms
Test the upgrade approach
Test-SPContentDatabase
Build test farms
It is incredibly valuable to build a test farm that can be used to test the upgrade plan and determine
contingency and rollback plans. The test farm can go through multiple dry-runs of the upgrade by using
production data, without impacting production users.
When building a test farm, be sure to do the following:
Use real data. This will help identify real trouble areas in real sites. It will also help
determine upgrade performance.
Use similar hardware. This is also an important step because it will help determine upgrade
performance as well as help predict post upgrade performance.
Validating the upgrade plan in a test environment by using real data and similar hardware will help
validate and refine the upgrade plan and also identify any potential issues early on in a non-production
environment so that the end users are not impacted. Repeating this process iteratively until all upgrade
steps complete successfully without mediation helps ensure a trouble-free upgrade of the real
production environment.
Evaluate techniques
Once a test farm has been built, you can use it to test and refine the upgrade strategy. Running through
the full upgrade plan on a test farm can help you determine the following:
Upgrade process. Will the planned upgrade process work as planned. If not, what is a better
approach?
Microsoft Corporation Page 101
Downtime mitigation. Do the downtime mitigation strategies work as planned? Can we run
multiple upgrade operations in parallel to shorten the upgrade time and thereby minimize
downtime?
Troubleshooting/Validation. What problems were encountered and how do we resolve
them?
Test Customization Upgrade. How does the customization upgrade work? How do
customized sites look after the upgrade?
Test the upgrade approach
Test the upgrade approach prior to the production upgrade. Performing a test of the upgrade is
important because it helps answer the following questions:
What are the exact procedures to complete the upgrade?
How long did it take to complete the upgrade?
What issues were discovered, and how were they resolved?
How did the customizations and sites function in SharePoint 2010?
The database attach process is easy to test because it involves making SQL backups of production
content databases and restoring them to an entirely new farm running SharePoint 2010. There is no
impact to the production SharePoint 2007 farm at any time. The advantage of this process is that the
testing is performed directly on the future SharePoint 2010 production farm, so the results are
extremely accurate. The content databases can be detached and reattached as many times as needed
for testing.
Testing the in-place upgrade is a little difficult compared to the database attach upgrade because you
cannot perform it on the production environment. The only way to test an in-place upgrade is to build
an environment that is identical to the production SharePoint 2007 farm. In addition, you can perform
the upgrade only once without having to perform disaster recovery to reset the environment back to
SharePoint 2007.
Test-SPContentDatabase
The Test-SPContentDatbase PowerShell command is the primary tool used in the test phase. This is a
PowerShell script that can be run on a SharePoint 2010 server to examine a WSS 3.0 or MOSS 2007 or
SharePoint 2010 content databases and report potential upgrade problems in the target Web
application. The information from this command complements the information found in the pre-
upgrade checker report but it helps find problems such as missing dependents in the new environment.
The Test-SPContentDatbase command is used to validate a database against a given Web application.
You can use this command with any post SP2 WSS or MOSS 2007 database or with any SharePoint 2010
database. While not required, the insight gained will essentially reveal the what if errors and warnings
associated with upgrading the database while making no changes to the database. The database itself
needs to be part of a farm and simply needs to be online in SQL. The Test-SPContentDatbase command
also works for version to version and even incremental upgrades between patches.
Microsoft Corporation Page 102
You should always run Test-SPContentDatabase on your SharePoint 2010 farm before adding any
content database to your farm, irrespective of the version. Even if you can create a SharePoint 2010
instance, you should run this command whether or not you are planning on using an in-place upgrade.
This insight is invaluable and is not the same as what you will get out of stsadm –o preupgradecheck.
The following screenshot shows a sample output from running Test-SPContentDatabase:
Microsoft Corporation Page 103
Section 2 Review
18
Section 2 Review
What are the 4 types of upgrades?
Do customizations get put back in place with Database
Attach?
What are 2 commands used to find orphans?
Answer the questions listed on the slide above.
List the four types of upgrade methods available in SharePoint 2010?
Does the database attach upgrade method put customizations back in place?
What are the two commands used to find orphans?
Microsoft Corporation Page 104
Section 3: Performing the Upgrade
20
Section 3: Performing the Upgrade
In-Place
Database Attach
Hybrid – read-only database
Hybrid – detached content databases
Introduction
This section explains the steps involved in performing each type of upgrade .
Objectives
After completing this section, you will be able to perform and validate an in-place or database attach
upgrade to SharePoint 2010.
Microsoft Corporation Page 105
Performing an In-Place Upgrade
21
Perform - In-Place Upgrade
General Process Steps:
• Perform the pre-upgrade steps
• Install prerequisites
• Run setup for the new version
• Install any necessary language packs
• Start the SharePoint Products and Technologies Configuration
wizard
• Monitor the upgrade progress
Overview
The in-place upgrade approach is the simplest. After you perform the pre-upgrade steps, run Setup for
the new version, install any necessary language packs, start the SharePoint Products and Technologies
Configuration wizard, monitor the upgrade process, and then verify the results.
Note: You must be running SP2 of WSS 3.0 in a 64-bit Windows Server 2008 environment to perform an in-place upgrade to SharePoint Foundation 2010. If you are in a server farm environment, you must also be running a 64-bit version of Microsoft SQL Server 2008 R2, SQL Server 2008 with SP1 and Cumulative Update 2, or SQL Server 2005 with SP3 and Cumulative Update 3.
When you upgrade a server farm, install and configure the new version to the servers in the order
described in the following procedures.
Install the prerequisites
1. Before you can upgrade, you must run the prerequisite installer successfully on each Web
server that has WSS 3.0 installed. A prerequisite installer is available to install the software
needed to support SharePoint Foundation 2010.
2. To run the prerequisite installer:
A. From the product disc, open the installation folder and run PrerequisiteInstaller.exe.
B. On the Welcome page of the Microsoft SharePoint Products Preparation Tool, click Next.
Microsoft Corporation Page 106
C. On the License Terms page, select the I accept the terms of the License Agreement(s)
check box, and then click Next. The tool runs, installing and configuring required
software.
D. Click Next.
E. On the Installation Complete screen, verify that each prerequisite is listed as successfully
installed or already installed.
F. Click Finish to close the wizard.
Install SharePoint Foundation 2010
1. Run Setup.exe.
2. On the Read the Microsoft Software License Terms page, review the terms, select the I
accept the terms of this agreement check box, and then click Continue.
3. On the Upgrade earlier versions page, click Install Now.
4. Install the required language packs for SharePoint Foundation 2010.
Note: For more information, refer to the Install available language template packs (SharePoint Foundation 2010) topic at http://technet.microsoft.com/en-us/library/cc287870.aspx.
5. Run the SharePoint Products Configuration Wizard on the WFE server that contains the
SharePoint Central Administration Web site.
To determine which server is running SharePoint Central Administration, open the Servers in
Farm page (http://server_name:adminport/_admin/farmservers.aspx) and note which server
or servers have Central Administration services running. Perform this step before you install
SharePoint Foundation 2010, while SharePoint Central Administration for WSS 3.0 is still
available.
Note: If you have multiple servers that are running SharePoint Central Administration, pick one and use that as the initial server to run upgrade. After you have completed the process on that one, you can continue with any other servers that are running SharePoint Central Administration.
6. Run the SharePoint Products Configuration Wizard on the remaining WFE and application
servers in the farm in any order.
Microsoft Corporation Page 107
Performing a Database Attach Upgrade
22
Perform - Database Attach Upgrade
Before you can migrate your content into a new environment,
you must create that new environment.
• Part of creating the new environment is recreating the web
application, re-applying configuration settings, and copying
other customization over from the old environment.
• Review permissions, hardware, and software requirements
Prepare the new farm
• Create and configure the new SharePoint 2010 farm
• Configure Service Applications
• Create Web Applications
• Put customizations into place
Overview
Although a database attach upgrade involves more manual steps than an in-place upgrade, it is the best
option if you have highly customized sites or custom Web services and applications, or if you intend to
keep the original farm for a while before deactivating it.
Before you can migrate your content into a new environment, you must create that new environment.
Part of creating the new environment involves re-creating the Web applications, re-applying
configuration settings, and copying other customizations over from the old environment. Review the
following information about permissions and hardware and software requirements (similar to the ones
required for an in-place upgrade):
Make sure that you have run the pre-upgrade checker tool (stsadm -o preupgradecheck,
available in WSS 3.0 SP 2 and updated in the October 2009 Cumulative Update) and
addressed any issues before you begin the upgrade process.
Ensure that you have met all hardware and software requirements. You must have a 64-bit
version of Windows Server 2008 or Windows Server 2008 R2. For server farms, you must
also have a 64-bit version of SQL Server 2005 or SQL Server 2008 or SQL Server 2008 R2.
Ensure that you are prepared to set up the required accounts by using appropriate
permissions.
SharePoint 2010 Setup
1. On the Start page, click Install SharePoint Foundation.
Microsoft Corporation Page 108
2. On the Read the Microsoft Software License Terms page, review the terms, select the I
accept the terms of this agreement check box, and then click Continue.
3. On the Choose the installation you want page, click Standalone or Server Farm, depending
on whether you want to use a built-in SQL database or not. Even in a single-server farm
scenario, if you intend to use a SQL instance other than the built-in database, click Server
Farm.
Note: In contrast to WSS 3.0 or MOSS 2007, SharePoint 2010 does not require you to indicate the server role installation type (Web Front End or Complete). This is because SharePoint 2010 always ensures a complete installation and defines the server role based on the services that are actually started and configured on servers.
Microsoft Corporation Page 109
4. On the File Location tab, accept the default location or change the installation path (as a best
practice, Microsoft recommends that you install SharePoint Foundation on a non-system
drive), and then click Install Now.
5. After Setup finishes, a dialog box prompts you to complete the configuration of your server.
Select to clear the Run the SharePoint Products Configuration Wizard check box, and
then click Close to finish Setup.
Note: In server farm deployments, all SharePoint 2010 servers must have the same software update version applied. This means that if you want to add a new server to an existing server farm to either scale out your deployment or to recover a failed server in a disaster recovery process, this new server must have the same software updates as the rest of the servers in your server farm. To simplify the installation process, you can create an installation source that contains a copy of the released version of the software, along with software updates that match the ones installed on your server farm (also known as a slipstreamed installation source). When you run Setup from this updated installation source, the new Web server will have the same software update and SharePoint database versions as the ones on the other servers in your server farm.
SharePoint Products Configuration Wizard
To create and configure the farm, you need to run the SharePoint Products Configuration Wizard. This
wizard automates several configuration tasks, including creating the configuration database, installing
services, and creating the Central Administration Web site. Microsoft recommends that you run the
Microsoft Corporation Page 110
SharePoint Products Configuration Wizard on the server that will host the Central Administration Web
site before you run it on the other servers in the farm.
To run the configuration wizard using the PSConfigUItool:
1. Click Start, point to All Programs, point to Administrative Tools, and then click
SharePoint Products Configuration Wizard.
2. In the "SharePoint Products Configuration Wizard", on the "Welcome to SharePoint
Products" page, click Next.
3. A message appears, notifying you that Internet Information Services (IIS), the SharePoint
Administration Services v4, and the SharePoint Timer Service v4 may need to be restarted or
reset during configuration. Click Yes to continue with the wizard.
4. On the "Connect to a server farm" page, click Create a new server farm, and then click
Next.
5. On the "Specify Configuration Database Settings" page, do the following:
A. In the Database server box, type the name of the computer that is running SQL Server
Note: Use SQL Server alias instead of server names to improve manageability.
B. In the Database name box, type a name for your configuration database, or use the default
database name. The default name is SharePoint_Config.
C. In the Username box, type the user name of the SharePoint server setup account in
DOMAIN\username format.
6. Click Next.
7. On the "Specify Farm Security Settings" page, type a passphrase, and then click Next. Ensure
that the passphrase meets the following criteria:
Contains at least eight characters
Contains at least three of the following four character groups:
English uppercase characters (from A through Z)
English lowercase characters (from a through z)
Numerals (from 0 through 9)
Nonalphabetic characters (such as !, $, #, %)
Note: Although a passphrase is similar to a password, it is usually longer to enhance security. It is used to encrypt credentials of accounts that are registered in SharePoint 2010. For example, the SharePoint 2010 system account that you provide when you run the SharePoint Products Configuration Wizard. Ensure that you remember the passphrase, because you must use it each time you add a server to the farm.
Microsoft Corporation Page 111
8. On the "Configure SharePoint Central Administration Web Application" page, do the
following:
A. Either select the "Specify port number" check box and type a port number
(recommended, if you want the SharePoint Central Administration Web application to
use a specific port number), or leave it to use the default port number.
B. Click either NTLM or Negotiate (Kerberos), and then click Next.
9. On the Configuration Successful page, click Finish.
After you create the farm on the application server, you can add new servers to the farm by following
the same procedure described earlier in this topic for installing SharePoint Foundation on the server
that hosts Central Administration. The only difference is that during Setup, you will be prompted to join
an existing farm.
Microsoft Corporation Page 112
Performing a Database Attach Upgrade (continued)
23
Perform – Database Attach Upgrade (cont.)
Make sure the root site for the web application is included in
the first content database that you attach
You do not have to create any site collections to store the
content before you attach the database; the upgrade process
creates the site collections for you
You can use either PowerShell or stsadm to attach a content
database to a web application
Using SharePoint Central Administration pages to attach a
content database is not supported for upgrading.
When you attach a content database to a Web application, make sure that the root site for the Web
application is included in the first content database that you attach. In other words, before you
continue, examine the root of the Web application in the original server farm to determine the first site
collection. After you attach the database that contains the root site, you can attach other content
databases for the Web application in any order.
Important: You do not need to create any site collections to store the content before you attach the database; this process creates the site collections for you. Make sure that you do not add any new site collections until you have restored all the content databases.
You can use either the Mount-SPContentDatabase cmdlet in Windows PowerShell or the addcontentdb
Stsadm command to attach a content database to a Web application. Using the SharePoint Central
Administration pages to attach a content database is not supported for upgrading. Ensure that the
account you use to attach the databases is a member of the db_owner fixed database role for the
content databases that you want to upgrade.
Note: You cannot attach the same content database more than once to a farm, even on different Web applications. Each site collection in a content database has a GUID associated with it, which is registered in the configuration database. Therefore, you cannot add the same site collection twice to the farm, even in separate Web applications. Although you can successfully attach the database in this situation, you will be unable to start the site collection. If you need a duplicate copy of a site collection in the same farm, first attach the database that contains the site collection to a separate farm, and then use the Stsadm backup and restore operations to copy the site collection over to the other farm. The
Stsadm backup and restore process creates a new GUID for the site collection.
Microsoft Corporation Page 113
Attaching a content database to a Web application by using Windows PowerShell
Verify that you meet the following minimum requirements: You are a member of the
SharePoint_Shell_Access role on the configuration database and a member of the WSS_ADMIN_WPG
local group on the computer where SharePoint 2010 Products is installed.
1. On the Start menu, click All Programs.
2. Click Microsoft SharePoint 2010 Products.
3. Click SharePoint 2010 Management Shell.
4. At the Windows PowerShell command prompt, type the following command:
<DatabaseName> is the name of the database that you want to upgrade.
<ServerName> is server on which the database is stored.
<URL> is the URL for the Web application that will host the sites.
[Updateuserexperience] is the choice to update to the new user experience or stay with
the old user experience (part of visual upgrade). When you include this parameter, the
site is set to preview the new user experience. Omit this parameter if you want the site to
remain in the old user experience after the upgrade.
Important: SharePoint 2010 supports performing several database attach upgrades at the same time, which helps reduce the amount of time taken by an upgrade. Through the use of multiple PowerShell sessions, multiple databases are upgraded, which means that the amount of data upgraded at one time is limited only by your SQL Server resources.
Verifying upgrade for the first database
After you have attached a database, you can use the Upgrade Status page in Central Administration to
check the status of upgrade on your site collections. To view this page, in Central Administration, click
Upgrade and Migration, and then click Check upgrade status.
After the upgrade process is complete, you can review the upgrade log file to see whether there were
any issues during upgrade. In addition, you can review each upgraded site to find and address any issues
with how the content is displayed.
Microsoft Corporation Page 114
Validating the Upgrade
24
Validate
Check log files for Setp.exe and SharePoint Products
Configuration Wizard
Review Upgrade logs
Event Viewer can also provide useful information in case of a
failure
Use Upgrade-SPContentDatabase to resume failed upgrade
processes.
Overview
After the upgrade is complete, you need to validate the results and if things appear to have upgraded
successfully, complete the upgrade and retire the old site. If you find any errors, you must decide
whether to leave the upgrade as is or start the rollback process.
You can review the following log files to discover any issues encountered with running Setup.exe,
SharePoint Products Configuration Wizard, and content upgrade.
The Setup.exe log file for SharePoint 2010
The Setup log file is stored in the temp directory for the user account that is running the Setup
(%USERTEMP% or %WINDIR%\Users\user account\AppData\Local\Temp). It is named SharePoint
Foundation Setup(YYYYMMDD-HHMMSS-SSS).log, where YYYYMMDD is the date and HHMMSS-SSS is
the time (hours in 24-hour clock format, minutes, seconds, and milliseconds).
The SharePoint Products Configuration Wizard (PSConfig.exe) log file
The PSConfig.exe log files are located at %COMMONPROGRAMFILES%\Microsoft Shared\Web server
extensions\14\LOGS. The logs are named in the format
HH_MM_SS_SSS is the time (hours in 24-hour clock format, minutes, seconds, and
milliseconds).
Microsoft Corporation Page 115
randomnumber is used to differentiate between possible simultaneous attempts to run
PSConfig.exe.
When PSConfigUI.exe is run, any errors encountered during the post-setup configuration process are
first displayed on the screen.
The upgrade log file and the upgrade error log file
The upgrade log file and the upgrade error log file are located at
%COMMONPROGRAMFILES%\Microsoft Shared\Web server extensions\14\LOGS.
In SharePoint 2010, the logging capabilities have been expanded and standardized, allowing for easier,
more consistent reporting on the upgrade process. This includes the creation of a unique log for each
upgrade. In addition, the logs generated are error-only, which reduces the need to look through the full
logs to discover upgrade-related issues. The logs are named in the format Upgrade-YYYYMMDD-
HHMMSS-SSS.log, where YYYYMMDD is the date and HHMMSS-SSS is the time (hours in 24-hour clock
format, minutes, seconds, and milliseconds). The upgrade error log file that combines all errors and
warnings into a shorter file is named Upgrade-YYYYMMDD-HHMMSS-SSS-error.log.
In the upgrade log file, search or visually scan for the following entry:
Upgrade session finished successfully!
The presence of this entry indicates a successful installation. If you do not find this entry, you can
identify specific issues that may have contributed to a failure by searching or visually scanning through
the file for the following terms:
Search for ERROR in the upgrade log file to find any failures such as failing components
and faulty database connections.
Search for WARNING to find issues such as missing features or components.
If you find any blocking issues in the log file, you can resolve them and then restart the upgrade to
continue with the process.
Microsoft Corporation Page 116
Section 3 Review
What are the 4 methods for performing upgrades? In-place, database attach, Hybrid - read only, Hybrid
- detached
What is the PowerShell command that replaced stsadm -o addcontentdb? Mount-SPContentDatabase
Microsoft Corporation Page 117
Section 4: Upgrade Considerations
26
Section 4: Upgrade Considerations
Upgrade SSPs to Service Applications
Downtime mitigation processes
Visual Upgrade
Introduction
This section introduces the idea of upgrading SSPs to service applications as well as other considerations
for during and after an upgrade to SharePoint 2010.
Objectives
After completing this section, you will be able to:
Upgrade SSPs to Service Applications via PowerShell.
Identify the methods to reduce downtime during an upgrade to SharePoint 2010.
Perform the visual upgrade of a SharePoint 2010 site after the upgrade.
Microsoft Corporation Page 118
Upgrading SSPs to Service Applications with PowerShell
27
Upgrade the SSP to Service Applications
Can be done through PowerShell
Upgrade-SPEnterpriseSearchServiceApplication
Upgrade-SPSingleSignOnDatabase
Upgrade-SPProjectWebInstance
The important part here is understanding that the upgrade can be controlled almost entirely through
PowerShell. Upgrading an SSP to a Service Application is definitely the tricky part of database attach
methodology. Most small and medium organizations will likely want to start fresh instead of upgrading
these services. Those with large complex search configuration will likely not want to lose their content
sources at a minimum.
The following list shows the PowerShell commands used to upgrade SSPs to Service Applications:
Upgrade-SPEnterpriseSearchServiceApplication. Upgrades the content sources and search
configuration of the Search service application instance to a new service application.
Upgrade-SPSingleSignOnDatabase. Upgrades the SharePoint Single Sign-On database to
Secure Store Service Application. The Secure Store service application allows solutions to
be developed that map user and group credentials to those of external data sources.
Upgrade-SPProjectWebInstance. Upgrades project server databases. This cmdlet applies
only to Project Server deployments.
Microsoft Corporation Page 119
Methods to Mitigate Upgrade Downtime
28
Downtime Mitigation Processes
Read-only databases (v3
SP2, v4)
Parallel content database
upgrades
• Parallel upgrade farms (v3,
v4)
• Single farm, multiple
upgrade sessions (v4)
Content database attach with
AAM redirection (v4)
New options for reducing downtime during upgrade
Depending on the environment and the complexity and number of SharePoint sites, the upgrade process
can take a long time. To reduce downtime during this process, SharePoint Server 2010 supports the
following options:
Use read-only databases to provide continuous access to data. If you perform a database
attach upgrade and if you set the original databases to read-only mode and if you are using
WSS v3 SP2 or WSS v4, the old farm can continue to serve content to users while you
upgrade a copy of the databases on a new farm. If you do this, users can continue to access
the data, although they cannot add new data or update existing data. When the new farm is
ready and all content has been successfully upgraded, users can be switched over to the new
live farm. This method reduces the perceived downtime for upgrades.
Upgrade multiple databases at the same time (parallel upgrade). When you upgrade to
SharePoint Server 2010, you can manually initiate upgrade for multiple databases at the same
time by using the detach content databases hybrid approach for upgrade. In contrast, in
MOSS 2007, only one upgrade process could run at a time, so each database needed to be
processed sequentially.
There is a performance impact when you run the upgrade on multiple databases instead of on
a single database, but it may be faster to upgrade multiple databases at the same time than to
upgrade them sequentially. The number of databases that can be upgraded in parallel will
depend on the hardware in your environment and the structure of the content within the
databases.
Microsoft Corporation Page 120
Note: For more information, refer to the Roadmap for in-place upgrade with detached databases (SharePoint Server 2010) topic at http://technet.microsoft.com/en-us/library/ee731988(office.14).aspx.
Attach content database with Alternate Access Mapping (AAM) redirection. You must
update the network infrastructure to refer the original URL to the SharePoint 2010 production
farm. This can include updating the Domain Name Services (DNS) settings for the original
URL, in addition to changing any firewall or load-balancer settings to direct the original URL
to the SharePoint 2010 Products farm. By using an AAM you reduce the perceived
downtime because users will still be able to access the site under the old name while you
upgrade the databases in the new production site.
You must also set up the redirected URL for the MOSS 2007 or WSS 3.0 farm in DNS, and
change any firewall and load-balancer settings to direct the redirected URL to the MOSS
2007 or WSS 3.0 farm.
The diagram on the slide above shows a mapping of the old farm to the newly upgraded farm and how
to accomplish the upgrade through the use of DNS or AAM redirection..
How AAM redirection works with upgrade
To configure AAM redirection:
1. Create the target farm.
2. Create the target Web application by using the URL from the source Web application.
3. Set up the AAM redirection URL from the target Web application to the source Web
application.
4. Change the network name resolution to point the AAM redirection URL to the source Web
application.
5. Modify the source Web application to use the AAM redirection URL as the primary URL.
6. Change the network name resolution to point the source URL to the target Web application.
7. Upgrade the content databases from the source farm by using the database attach upgrade
method, starting with the content database that contains the root site collection first.
Note: For more information, refer to the white paper at http://technet.microsoft.com/en-
us/library/ee720447.aspx.
Important: AAM redirection is an advanced technique for avoiding downtime during upgrade. It should only be used if other techniques such as read-only databases and upgrade in-place with detached databases would cause an unacceptably long period of downtime for your users. Do not consider using this technique unless you know your
upgrade process will take more than a long weekend. If your upgrade is not likely to take that long, you will not save any time by performing this procedure.
Microsoft Corporation Page 122
Visual Upgrade
29
Visual Upgrade
Users, by default, still see the 2007
version of their site after upgrade
Conversion to the SP2010 version
completed through a link in the Site
Actions menu.
Conversion can be done gradual or
en-mass (through PowerShell
Some sites and web parts are not
compatible and will be
automatically upgraded
Visual Upgrade is a new concept in SharePoint 2010 that has more to do with the actual impact on users
who work with SharePoint on a day-to-day basis. After the actual server upgrade to SharePoint 2010
has been performed, by default all of the SharePoint sites still have the familiar user interface of
SharePoint 2007. This allows the capability to gradually accustom the users to the new SharePoint
interface, if desired.
If the server administrator lets the site owners decide, after a site is upgraded, a preview option is
available in the site user interface. This option provides a preview of the SharePoint Server 2010 look for
the site.
If the owner likes how the site looks and functions, the owner can accept the visual upgrade. If the
owner wants the site to keep the old look and feel, the owner can revert to the MOSS 2007 look.
This functionality lets you check to see what each site will look like with the full SharePoint 2010 user
experience, before committing to the changes permanently. This can be done at as granularly as the
Web (individual sub-site) level. In addition, if preferred, the new visuals can be committed to all sites by
using Windows Powershell scripting on the server.
Training site owners and site collection owners
It is important to train users about the effects of either preserving the look and feel of existing
SharePoint sites or upgrading all sites to the new user interface. Educated users are prepared and know
what to expect, which will minimize helpdesk support and frustrations.
Microsoft Corporation Page 123
If you upgrade all sites to the new user interface, you must inform users about changes and new
features, such as the ribbon, the new page editing interface, and interactive calendars. In addition, let
them know about possible issues that they can expect; for instance, they might have issues with
customizations, such as pages not displaying correctly.
By default, site owners have control over their sites. They can use the Preview New Visuals option
(under Site Settings); shown in the screen shot on the slide; to preview the new user interface and then
switch between the previous and new user interface. This gives them time to ensure that everything
works correctly, and they can fix any issues with their pages that appeared after upgrade. It is important
to use the preview option because once you make the conversion to upgrade the visuals you cannot
revert the site back to the v3 format. When site owners are ready, they can update their sites to the
new user interface. However, site collection owners can choose to finalize the new user interface, which
overrides the control that site owners have over visual upgrade for their sites. If site collection owners
want to keep the previous user interface for their site collection, they also have an option to hide visual
upgrade settings from site owners.
Site owners also need to know that if they make changes to the new user interface while they are in
preview mode and then switch back to the previous user interface, this information may not display
correctly.
Microsoft recommends that you have a plan and set a time limit for how long the previous user
interface should be used in your SharePoint deployment. For example, each site collection administrator
may be given 90 days to work with his or her site owners to transition from the previous to the new user
interface. Ensure that you communicate the time limit to the users to give them a reasonable time to
become familiar with the new user interface and to resolve any issues that might have occurred during
the upgrade. If you set a time limit for the users, you must also inform them that, after this time limit,
you can force through an upgrade of all sites.
Known issues
There are a few known issues to consider with regards to visual upgrade:
Because of the social networking enhancements in SharePoint Server 2010, the existing My
Site templates default to the new user interface after upgrade with the preserve the existing
user interface option selected by using Updateuserexperience through PowerShell or
preserveolduserexperience through stsadm. However, all subpages have the user interface
specified by visual upgrade.
Project Web Access (PWA) sites, which are used to track project data in Microsoft Project
Server 2010, require the new user interface and do not follow visual upgrade settings.
In Excel Services Web Parts, the new SharePoint Server 2010 Web Part properties are
exposed once an upgrade is complete, but before the sites have been moved to the new user
interface. Therefore, although you can set some properties, they will not be effective until you
update the page to the new UI.
Microsoft Corporation Page 124
If you use SharePoint Server 2010, ensure that you use the same version and service pack of
SharePoint Designer.
This feature is not available when performing an upgrade of a single server with the built-in
database.
Performing a Visual Upgrade
In order to maintain proper look and feel for SharePoint sites after the upgrade process, SharePoint
2010 installs both the 3.0 and the 4.0 versions of the Master Pages and CSS stylesheets. In addition, by
default, an upgraded page retains the 3.0 look and feel until it is explicitly converted to the new version.
The Visual Upgrade feature which allows a site to be previewed in the new look-and-feel and then
converted.
The following screenshot shows a WSS 3.0 team site prior to a visual upgrade:
The following screenshot shows the outcome of selecting Preview New Visuals from the Site Actions
drop-down list:
Microsoft Corporation Page 125
If you are satisfied with the preview, go to Site Actions, select Visual Upgrade, and then select Upgrade
All Sites, as shown in the following screeshot:
Microsoft Corporation Page 126
Microsoft Corporation Page 127
Section 4 Review
30
Section 4 Review
How can you upgrade your SSP to Service Applications?
Why would you want to preview the Visual Upgrade?
Answer the questions listed on the slide above.
How can you upgrade an SSP to a Service Application?
Why would you want to preview the visual upgrade?
Microsoft Corporation Page 128
General Administration and Service Applications
Microsoft Corporation Page 129
Microsoft Corporation Page 130
Introduction
This module introduces the changes made to Central Administration and timer jobs in Microsoft
SharePoint 2010. SharePoint 2010 also introduces the concept of service applications. The module
describes how service applications replace Shared Service Providers (SSPs) available in Microsoft Office
SharePoint Server (MOSS).
Objectives
After completing this module, you will be able to:
Describe the role of new elements introduced in the Central Administration UI.
Create Web applications and site collections.
Configure and manage timer jobs.
Configure and manage service applications.
Microsoft Corporation Page 131
Section 1: Central Administration
Introduction
This section introduces the various enhancements made to the user interface (UI) of Central
Administration in SharePoint 2010.
Objectives
After completing this section, you will be able to:
Identify the role of new elements introduced in the Central Administration UI.
Explain the role of Web applications and site collections, and how to create them.
3
Section 1: Central Administration
Central Administration Home Page
Central Administration Ribbon Menu
Demonstration: Exploring the Central Administration
Ribbon Menu
Web Applications
Creating New Web Applications
Site Collections
Creating New Site Collections
Microsoft Corporation Page 132
Central Administration Home Page
The main page of Central Administration displays when you first open Central Administration as well as
when you click the Central Administration link in the navigational menu on the left. This page displays
various sections divided by administration topics available in Central Administration.
The following screenshots show the main sections available on the Central Administration Home page:
System Settings
4
Central Administration Home Page
Is displayed on opening Central Administration as well as
on clicking the Central Administration link in the
navigational menu on the left
Displays various sections divided by administration
topics available in Central Administration
Displays a Yellow or Red bar under the header section to
warn administrators of problems detected by the
SharePoint Health Analyzer
• SharePoint Health Analyzer runs out of a timer job and
looks at the possible health issues in a SharePoint farm
Microsoft Corporation Page 133
Application Management
Monitoring
The main page also displays a Yellow or Red bar under the header section to warn administrators of
problems detected by the SharePoint Health Analyzer, as shown in the following screenshot:
Microsoft Corporation Page 134
The SharePoint Health Analyzer, which runs out of a timer job, looks at the possible health issues in your
SharePoint farm and alerts the administrators about these issues whenever they navigate to the main
Central Administration page.
Microsoft Corporation Page 135
Central Administration Ribbon Menu
Many of the next levels of menus from Central Administration show the integration of the ribbon into
Central Administration. The purpose of the ribbon is to ease navigational concerns from MOSS and
provide a quicker method to make changes to various aspects of Central Administration tasks.
The Central Administration page now provides most options for viewing or changing configuration of
different items in the form of a ribbon instead of the old drop-down menu system used in MOSS.
Application Management is one of the best examples of the ribbon in action. One of the important
things to remember with the ribbon is that similar to the tabs available in Microsoft Office applications,
the ribbon options change depending on the items selected within each of the main menus. This is
known as contextual menu.
6
Central Administration Ribbon Menu
Eases navigational concerns present in MOSS
Helps manage configuration options in the form of a
ribbon instead of the old drop-down menu system
Is similar to the tabs available in Microsoft Office
applications
Contain options that change depending on the menu
choice made—known as contextual menu
Microsoft Corporation Page 136
Demonstration: Exploring the Central Administration Ribbon Menu
8. Open Central Administration.
9. Select Application Management.
10. Select the Central Administration Web application by clicking the white space next to the
application name.
The ribbon now appears and is populated with contextual choices available for this Web
application from this location.
Microsoft Corporation Page 137
Web Applications
A Web application is composed of an Internet Information Services (IIS) Web site (but can have up to
five IIS Web sites with which it is associated) that acts as a logical unit for the site collections that you
create. Before you can create a site collection, you must first create a Web application. Web applications
are created on each Web Front End (WFE) in a SharePoint farm.
Each Web application is represented by a different IIS Web site with a unique or shared application pool
for separate memory spaces. Each application requires an ID to run under. This ID can be a unique or
managed account. You should use managed accounts wherever possible for the ease of administration.
You must assign a unique domain name to each Web application. Using unique domain names helps
separate work areas and create divisions of authentication, and creates easy names for users to
remember to access.
Web applications help you isolate content. When you create a new Web application, you also create a
new content database and define the authentication method used to connect to the database. Each
Web application can hold 100 content databases. You can connect multiple Web applications to the
same content database by extending the application into another zone. There are five zones available to
extend Web applications: Default, Intranet, Internet, Extranet, and Custom. Each zone has a unique URL
associated with it.
Note: More information about these zones is available in Module 5 - Security.
In addition to the content database, you define an authentication method to be used by the IIS Web site
in Microsoft SharePoint Foundation (MSF) 2010.
MSF 2010 offers the following two ways of authenticating users:
Claims Based Authentication. Users log on to a Web application by using Windows
authentication, Forms-Based Authentication (FBA), or Trusted Identity provider (SAML). If
you use FBA or SAML, you must perform additional configuration steps. FBA requires
claims-based authentication, which is introduced as part of Windows Identity Framework and
will be discussed in Module 5.
Classic Mode Authentication. Users log on to a Web application by using Windows
authentication. This is similar to using Anonymous, Basic, Digest, Certificates, NTLM, or
Kerberos authentication methods in MOSS.
Microsoft Corporation Page 138
Creating New Web Applications
You can create a new Web application either through Central Administration or through Windows
PowerShell. In order to create a new Web application, you will need to supply an authentication type;
Web application URL, port, and path; security provider; public URL; application pool; and database name
and server. Optionally, through either the GUI or Windows PowerShell, you can supply a failover
database server, search server, service application connection, and opt-in or out of Customer Experience
Improvement Program (CEIP). The GUI is simply a graphical representation of the Windows PowerShell
command.
To create a new Web application through Windows PowerShell:
11. On the Start menu, click All Programs.
12. Click Microsoft SharePoint 2010 Products.
13. Click SharePoint 2010 Management Shell.
14. At the Windows PowerShell command prompt, type the following command:
A site collection is a group of Web sites that have the same owner and share administrative settings,
such as permissions or search scopes. When you create a site collection, a top-level site is automatically
created in the site collection. You can then create one or more subsites (aka subwebs) below this top-
level site.
Note: A subweb is a division or an additional site within a site collection. You must have at least one site collection before you can create a subweb.
There must be at least one site collection per Web application. Without a site collection, no content can
be displayed. You can create a site collection in an existing Web application, or you can create a Web
application and then create a site collection within that application. Each site collection can only reside
within a single content database, although you can have multiple content databases per Web
application. If you wish to create a site collection in a new content database, you must use the New-
SPSite command in Windows PowerShell with the ContentDatabase parameter.
If your Web application is for a single project or for use by a single team, you should use a single site
collection to avoid the overhead of managing multiple sites. However, complex solutions benefit from
multiple site collections because it is easier to organize content and manage permissions for each site
collection. For example, because there is no built-in navigation from one site collection to another,
having multiple site collections can provide an additional layer of security for site content.
14
Site Collections
Are a group of Web sites that have the same owner and
share administrative settings
When created, automatically created a top-level site in
the site collection, below which one or more subsites
(aka subwebs) can be created
Must be at least one per Web application
Can be created in an existing or a new Web application
Can only reside within a single content database
Can be one or many within a Web application,
depending on the complexity of the solution
Can be created using various site template categories
Microsoft Corporation Page 142
There is no right or wrong answer for when to use a site collection or a subweb. The choice is yours
depending on the site structure that you want to maintain as well as the amount of work you want to
put into the site administration.
SharePoint provides various site templates that you can use to create a site collection for a specific
purpose. These template categories include collaboration, meetings, enterprise, publishing, and custom.
For example, the Publishing Portal template from the Publishing tab helps you create a large intranet
site that has many more readers than contributors, whereas the Team Site template from the
Collaboration tab helps you create a site where nearly everyone will be a contributor.
Microsoft Corporation Page 143
Creating New Site Collections
Before you create a site collection, you must ensure that the following are available:
A Web application where you wish to create the site collection.
A quota template if you plan to define values that specify how much data can be stored in a
site collection, and the storage size that triggers an e-mail alert to the site collection
administrator. Although not required, quotas are a great way to manage the growth of your
SharePoint environment.
A custom-managed wildcard path, if you plan to create the site collection somewhere other
than under the root (/) or the /sites/ directory.
You can create a new site collection either through Central Administration or through Windows
PowerShell.
When using Central Administration to create a site collection, you need to supply the following:
Title. What the site should be known as
Description. A definition of what the site is for
URL. A unique location for the site
Template. The template to use for the base design of the site.
Primary site collection administrator. The owner or person responsible for the site
Secondary site collection administrator. An additional contact or perhaps co-owner for the
site collection
Quota template. The quota that the site collection should use for storage boundaries
15
Creating New Site Collections
Requires the following prerequisites:
• A Web application
• A quota template
• A custom-managed wildcard path
Requires specifying:
• Title
• Description
• URL
• Template
• Primary site collection administrator
• Secondary site collection administrator
• Quota template
Can be created either through Central Administration or through
Windows PowerShell
Microsoft Corporation Page 144
To create a site collection through Windows PowerShell:
15. On the Start menu, click All Programs.
16. Click Microsoft SharePoint 2010 Products.
17. Click SharePoint 2010 Management Shell.
18. Type the following:
Get-SPWebTemplate
$template = Get-SPWebTemplate "STS#0“
New-SPSite -Url "<URL for the new site collection>" -OwnerAlias "<domain\user>" -Template
$template
This example retrieves a list of all the available site templates and then creates a site collection by using
the Team Site template.
Microsoft Corporation Page 145
Section 1 Review
Answer the questions listed on the slide above.
18
Section 1 Review
Where can you create a Web application from?
What do you need to supply to create a site collection via
Central Administration?
Microsoft Corporation Page 146
Section 2: Timer Jobs
Introduction
This section introduces the changes and enhancements made to timer jobs in SharePoint 2010 and also
explains how to manage them.
Objectives
After completing this section, you will be able to:
Identify the changed and improved features pertaining to timer job management.
Explain the role of the new Preferred Timer Server setting in determining which server
processes which timer jobs.
19
Section 2: Timer Jobs
Changed Timer Job Features
Improved Timer Job Features
Preferred Timer Server
Microsoft Corporation Page 147
Changed Timer Job Features
What is a timer job?
A timer job runs a specific Windows service for SharePoint 2010. This job contains a definition of the
service to run and specifies how frequently the service is started. The Windows SharePoint Services
Timer v4 service (SPTimerV4) runs timer jobs. Many features in SharePoint Server 2010 rely on timer
jobs to run services according to a predefined schedule.
To access timer jobs through Central Administration:
19. On the Start menu, click All Programs.
20. Click Microsoft SharePoint 2010 Products.
21. Click SharePoint 2010 Central Administration.
22. Click Monitoring.
23. Click Review Timer Job Definitions.
One of the most notable changes in timer jobs in SharePoint 2010 is that there are now 21 additional
timer jobs over MOSS which has a total of 60 default timer jobs.
The new timer jobs in SharePoint 2010 include:
Application Addresses Refresh Job
Audit Log Trimming
Delete Job History
20
Changed Timer Job Features
A timer job runs a specific Windows service for SharePoint 2010 at a
predefined schedule.
SharePoint 2010 has 21 additional timer jobs over MOSS.
Timer jobs can be managed via the Timer Links menu in the Monitoring
section of Central Administration.
The new timer job features include:
• Scheduled Jobs. Manage the schedule of timer jobs via Central
Administration or Windows PowerShell. View a time-based schedule of the
next jobs to run in order
• Running Jobs. View a list of currently running timer jobs and detailed
information about each of them
• Job History. View an enhanced log of timer job history, sorted by completed
date and time
• Job Definitions. Run and disable timer jobs with the click of a button
Microsoft Corporation Page 148
Document ID Enable/Disable Job
Document ID Assignment Job
Enterprise Server Search Master Job
Health Analysis Job
InfoPath Forms Services Maintenance
Password Management
Prepare Query Suggestions
Product Version Job
Query Logging
Secure Store Service Timer
Solution Daily Resource Usage Update
State Service Delete Expired Sessions
Timer Service Recycle
Web Analytics Trigger Workflows Timer Job
Windows SharePoint Services Usage Data Import
Windows SharePoint Services Usage Data Processing
Word Conversion Timer Job
Workflow
You can manage timer jobs through the Monitoring section of Central Administration. The Timer Links
menu on this section helps you avoid going back and forth to examine timer jobs.
Scheduled Jobs
In MOSS 2007, you need to use the command line to manage the schedule of timer jobs and to even
make these jobs run immediately. You can now manage the schedule of virtually all timer jobs via
Central Administration; you do not need to manage certain timer jobs only using stsadm commands any
longer.
In addition to Central Administration, you can use the following Windows PowerShell cmdlets to
manage timer jobs:
Disable-SPTimerJob
Enable-SPTimerJob
Get-SPTimerJob
Microsoft Corporation Page 149
Set-SPTimerJob
Start-SPTimerJob
Through either Central Administration or Windows PowerShell, you can schedule timer jobs from
making them run in minutes to running them on a monthly basis.
Running Jobs
Running Jobs, which is found on the Job Definitions page, now displays a list of the currently running
timer jobs. From here, you can determine the server that the timer job is running on, progress of the
execution of the timer job, the status of the job, and the time when the timer job started running.
Job History
The logging of timer jobs has been greatly enhanced in SharePoint 2010 over MOSS. As shown in the
following screenshot, you can now view each timer job in a list sorted by completed date and time. The
list also displays the server and the Web application that were affected by the timer job, the duration for
which the timer job ran, and the status of the timer job. Clicking on the status reveals additional
information such as the name of the corresponding content database and error messages, if any,
encountered when running the timer job.
Job Definitions
SharePoint 2010 now offers the ability to run any timer job with the click of a button. You do not need
to first modify the schedule and then wait for the job to run on the next scheduled time. As soon as you
click the Run Now button shown in the screenshot below, the timer job fires after the next configuration
refresh job, usually within a minute or two. You can also disable timer jobs from the same screen.
Microsoft Corporation Page 150
Microsoft Corporation Page 151
Improved Timer Job Features
SharePoint 2010 offers the following improvements in the timer job management functionality:
Pause-resume capability
Timer Service Recycle
Throttling
Pause-resume capability
Pausing behavior in previous SharePoint versions
In previous versions of SharePoint, pausing the timer job service would prevent any new timer jobs from
beginning. However, the timer jobs that were already running could continue to run. The only thing that
was really paused was the ability to start new timer jobs.
However, stopping the timer job service would cause all timer jobs currently running to be terminated
with all progress lost. When the service restarted, the job would not resume where it left off, instead it
would start from the beginning again.
This phenomenon was especially painful when you needed to restart the time job service while a long-
running timer job was in progress.
New pause behavior
In SharePoint 2010, some timer jobs have the ability to save their state or provide some sort of marker,
so that when the job is resumed, it can continue where it left off. This process is similar to that of a
workflow. The state of a timer job is dehydrated when it is paused. When the job is later resumed, the
job is rehydrated using the state information.
22
Improved Timer Job Features
Pause-resume capability
• Allows some timer jobs to save their state and then resume where they left off
• Cannot be currently accomplished manually
• Helps improve timer service recycle experience and reduce resources when
the server is in a throttled state.
Timer Service Recycle
• Helps recycle the timer service on all servers in a farm
• Runs once daily, by default at 6 AM
Throttling
• Prevents any new recurring timer jobs from starting when server is in a
throttled state
• Makes the server pause any pausable running jobs one by one when the
server enters throttled state
• Uses the config refresh job to inform the server when throttling has ended
Microsoft Corporation Page 152
Pause-resume restrictions
There is currently no method in SharePoint 2010 to manually pause or resume an individual timer job by
using the new pause-resume functionality. At this time, pausable timer jobs are primarily used to
improve timer service recycle experience and reduce resources when the server is in a throttled state.
Note: At the time of scripting the content for this workshop, the pause-resume functionality is restricted to content database jobs. These are normally the jobs that run the longest and would benefit from the pause-resume functionality.
Timer Service Recycle
The pause-resume functionality described above allows for a new recycle timer job that is used to
recycle the timer service on all servers in a farm.
How it works
The recycle timer job runs once daily, by default at 6 AM.
When the recycle timer job starts, the timer job service enters warning state.
During this time, no new timer jobs can start (except Config Refresh and job-timer-
locks).
All running jobs that can be paused should now begin pausing one by one.
ULS logs will reflect these warnings.
Determine if the recycle timer job can continue.
If the pausable timer jobs do not stop after the warning time has elapsed, the recycle
timer job is skipped.
If the non-pausable timer jobs are still executing, the recycle timer job is skipped.
If the admin service is not running, the timer job service cannot restart, so recycle is
skipped.
After the warning period expires, recycle begins an approximately30-second countdown
period. At the end of the countdown, the Admin service will restart the timer job service
(OWSTimer.exe will have a new PID).
After the recycle timer job completes:
All paused jobs rehydrate and resume execution.
Any immediate jobs that could not begin during recycle are now run.
Scheduled jobs that could not start will fire again after the next scheduled iteration.
Microsoft Corporation Page 153
Throttling
A new throttling mechanism for SharePoint2010 will be introduced in Module 8. When the
administrator determines that the SharePoint server is running short of resources, the server can be
configured to throttle HTTP requests.
Timer jobs are also affected by this feature as follows:
No new recurring timer jobs will be started while server is in a throttled state. Config refresh,
job-timer-locks, and one-time jobs are exceptions and there may be others on a white list, that
is password roll.
Any running jobs that are pausable will be paused by the server one by one when the server
enters throttled state. Jobs are resumed after the server leaves the throttled state.
The config refresh job, which runs by default every 15 seconds, will be the mechanism for
informing the server when the throttling state has ended and timer jobs can resume normal
operations.
Microsoft Corporation Page 154
Preferred Timer Server
Previous version behavior
Timer jobs were balanced between all available servers.
New behavior
Each content database is now associated with a new Preferred Timer Server setting, as shown in the
screenshot on the slide above. This setting specifies which server will process the timer jobs of the
content database. The preferred server sets a lock on the content database by adding a flag to the
content database. If the Preferred Timer Server is down, it will not be able to renew the lock which will
allow another server will acquire the lock via normal timer job load balancing. When the Preferred Timer
Server comes back up, it will acquire the lock.
How do these values allow for timer job affinity? The timer service categorizes locks into the following
three categories. How the timer service treats each category determines which server picks up the lock.
Preferred locks. Specify that the timer jobs for a specific content database are processed on a
specific server. The preferred server acquires these locks whenever they are available. Once
acquired, the server renews the locks every five minutess.
Non-preferred locks. Specify that the timer jobs are processed on any content database
where the administrator does not specify a preferred server. Non-preferred locks are divided
evenly amongst all the machines that should process content database jobs. There may be
contention in trying to acquire these locks, but it does not matter which server gets an
individual lock as long as they are distributed evenly. Once acquired, the server renews these
locks every five minutess.
24
Preferred Timer Server
Previously, timer jobs were balanced between all available servers.
Now, each content database is associated with a new Preferred Timer
Server setting.
• Specifies the server that will process the timer jobs of the content database,
and the server sets a lock on the database
The timer service categorizes locks into the following three categories:
• Preferred locks
• Non-preferred locks
• Surplus locks
Microsoft Corporation Page 155
Surplus locks. Specify locks that should be owned by another server (preferred or non-
preferred locks) but are not because the server is down. Surplus locks are divided evenly
among all those machines that are actively (which means that the machines own a non-
expired lock) processing content database jobs. After acquiring a surplus lock, the server lets
the lock expire after 10 minutes; they are not auto-renewed every 5 minutess. After
expiration, the server waits two minutes before trying to re-acquire a surplus lock that it
previously owned. This gives the rightful owner a chance to acquire the lock.
Three minutes after expiration, the server can acquire a surplus lock previously owned by
another server. This functionality helps minimize lock churn among servers handling surplus
locks.
Four minutes after expiration, the servers try to acquire any remaining locks. This
functionality helps handle cases where a timer job service crashes while holding locks.
Although surplus locks are attempted to be distributed evenly, the crashed server will appear
to be active for up to 10 minutes when its locks expire. The four-minute failsafe shortens the
time that a lock can go without someone claiming it and continuing processing, which could
otherwise take up to 13 minutes.
Microsoft Corporation Page 156
Microsoft Corporation Page 157
Section 2 Review
Answer the questions listed on the slide above.
26
Section 2 Review
Where can you manage timer jobs from?
How do you display the currently running timer jobs?
Can you set the server from which a specific timer job should
be run?
Microsoft Corporation Page 158
Section 3: Service Applications
Introduction
This section introduces the concept of service applications and how to use them.
Objectives
After completing this section, you will be able to:
Differentiate between SSPs and service applications.
Identify the role of various components involved in the service application model
architecture.
Explain the relationship between service application proxies and service application proxy
groups.
Create and manage service applications.
Connect Web applications to service applications.
Customize service application proxy groups.
Publish and connect to a service between farms.
27
Section 3: Service Applications
SSPs vs. Service Applications
Service Application Flexibility
Service Application Model
Service Application Proxy
Creating Service Applications
Managing Service Applications
Classes of Service Application Administrators
Connecting Web Applications to Service Applications
Customizing Service Application Proxy Groups
Publishing and Connecting to a Service between Farms
Microsoft Corporation Page 159
SSPs vs. Service Applications
SSPs were all or nothing
When you create a new SSP in MOSS 2007, you get all the services and overhead that comes with that
SSP. For example, to get just Excel Services, you had to create a new SSP with all of the overhead of the
other services.
Web applications were limited to consuming from a single SSP
An individual Web application in MOSS 2007 can consume from only one SSP. Consider this scenario.
You have a Web application that is consuming services of one SSP, but you want to create a profile
service other than the one being provided by the SSP. You want to be able to use the existing SSP for all
services except profile, but you cannot do it because there is no reuse of services between SSPs.
Therefore, you would need to create a new SSP, duplicate all of the settings for the services from the
first SSP, and then create the new profile service the way you want it. It is not a very efficient process for
what you want to accomplish.
SSPs were tied to a single farm
Although MOSS 2007 offered the ability to share SSPs across farm, it was tricky. When a Web application
in a content farm wanted to consume the services of a services farm, it had to consume all of its services
from that farm; the application could not choose to consume only certain services from an application
farm and other services from its own SSP.
Deploying SSPs was difficult
The overhead involved in creating an SSP is cumbersome and overly time consuming.
28
SSPs vs. Service Applications
SSPs:
• Were all or nothing
• Limited Web applications to consume from a single SSP
• Were tied to a single farm
• Were difficult to be deployed
• Were difficult to manage and troubleshoot
Service applications:
• Replace the MOSS 2007 SSPs
• Framework is now in MSF 2010
• Are a la carte
• Are classified into two categories: MSF and SharePoint Server
Microsoft Corporation Page 160
SSP management and troubleshooting was difficult
The management of SSPs is cumbersome because you cannot administer individual services. Because of
the added complexity, troubleshooting a service in an SSP is also a tedious process. You also need to be
cautious about the effect that troubleshooting one service would have on the rest.
Benefits of service applications
Service applications replace the MOSS 2007 SSPs
In SharePoint 2010, SSPs have been replaced by service applications. These applications act
independently without being grouped as an SSP.
The service application framework is now in MSF 2010
The ability to create an SSP was available only with MOSS 2007; WSS 3.0 did not offer the ability to use
or create an SSP. The platform for shared services is now part of the MSF 2010 platform (formerly WSS).
MSF 2010 ships with two shared services:
Business Data Connectivity Service, formerly known as the Business Data Catalog
Usage and Health data collection service, which is a new service that will be discussed in
Module 8
Service applications are a la carte
A big change in services in SharePoint 2010 is that all of the individual services that made up the SSP are
now available as service applications, which can be consumed and managed individually. You should not
think of service applications in terms of a single EXE or DLL, but rather as a complete application.
However, service applications are of no use unless they are consumed; this is where service application
proxies come into play.
A service application proxy knows how to talk to a service application, exposed on the application server
by a custom service. Now, you can have a consumer, such as a Web Part, that talks to the proxy to
communicate with the service. The consumer does not need to know where that service is running.
Available service applications
MSF
Business Data Connectivity Service
Usage and Health data collection
SharePoint Server
Access Services
Document Conversion
Excel Services
Managed Metadata Service
PerformancePoint
Search Service
Secure Store
Microsoft Corporation Page 161
State Service
Visio Graphics Service
User Profile Service
Microsoft Corporation Page 162
Service Application Flexibility
As shown in the diagrams on the slide above, the service application model in MSF 2010 is much more
flexible and scalable than the one in MOSS 2007. Here are some examples of how.
Service applications can be tied to a specific piece of hardware
In MSF 2010, you can pick and choose the machines that you want to run on a particular service by
starting instances on just the desired servers.
Web applications and service applications have a many-to-many relationship
In MSF 2010, one Web application can consume as many service applications as it wants, in any
combination it wants. This combination can be totally different from another Web application.
Examples of a few combinations are:
24. Web applications can consume individual service applications in different combinations.
25. Multiple instances of the same service can run on the same machine. For example, you could
create two different BCS service applications and have instances of both running on the same
machine.
26. In some cases, a Web application can consume more than one service of the same type. For
example, you can have multiple SharePoint 2010 metadata service applications, each
containing a distinct set of terms, consumed by a single Web application. This way, the Web
application would have access to all of the terms in both the services.
29
Service Application Flexibility
Service applications can be tied to a specific piece of hardware
Web applications and service applications have a many-to-many relationship
Service applications offer improved scalability, load balancing, and fault
tolerance
Microsoft Corporation Page 163
Service applications offer improved scalability, load balancing, and fault tolerance
Scalability. Service applications offer more of a cloud environment. You add just those
services that you need, where you need them.
Load balancing. MSF 2010 has a built-in load balancing between service applications.
Requests are divided to services by using a simple round robin scheme. You can even write
your own load balancer, if you like.
Fault tolerance. You can start multiple service instances for a single service application. If
one of the instances goes down, the others can take over.
Microsoft Corporation Page 164
Service Application Model
A service can mean many things; you can have an NT service, a Web service, a SharePoint service
application, or a SharePoint service instance. This topic describes the service application model
architecture and what is meant by a service in the context of a service application.
Service
In generic terms, a service is something that does some useful work. In the context of a service
application, a service indicates the binaries and supporting files that get installed onto the file system.
You can view several individual services within the Services on Server section of Central Administrator.
A service does not do anything until it is started.
Service machine instance
Once you start a service, you have a running instance of a service; you do not have an instance of the
service until you start it. Once the service is started, behind the scenes, the service is added to a load
balancer which lets SharePoint know which servers in the farm have the running instances of that
service.
30
Service Application Model
Consists of:
• Service
• Service machine instance
• Service application
• Service consumer
• Service database
• WCF Web service
• Application directories
Microsoft Corporation Page 165
Service application
A service application is not the physical service itself. Instead, you can think of it as more of the
management and configuration interface that helps control a particular service. For example, when you
create a search service application, you must specify the content sources and perform all of the other
configuration tasks that go along with search. The search service application does nothing until you start
the service instances on the individual machines which will carry out the work of this application.
Service consumer
The service consumer is the code—a Web Part, a Windows PowerShell cmdlet, or another Web
service—that initiates the request for the service. The consumer does not need to know where the
service exists; all it needs is a reference to a service application proxy and pass it the request. The proxy
will do the rest.
Microsoft Corporation Page 166
Service database
Each service application can have its own associated database. However, this is not required. MSF 2010
has only two service applications, BCS and Usage and Health, and will therefore only have two
databases. SharePoint Server 2010, on the other hand, will have many more.
When consuming service applications, the front-end servers never make a direct connection to the
database server(s). All communication must go through the Web service, which will in turn
communicate with the database server, as necessary. This is true within a farm as well as between
farms.
WCF Web service
In MSF 2010 and SharePoint Server 2010, the Windows Communication Foundation (WCF) Web service
replaces the ASP.NET Web services (ASMX) used in MOSS 2007. To connect to a WCF service, you must
have an address, a port, and abide by the contract which describes how the service can be used. The
SharePoint WCF service applications will be hosted within the SharePoint Web services site.
The ports for these Web services have changed. There are multiple binding possibilities for SharePoint
Web services:
HTTP: 32843
HTTPS:32844
TCP:32845
Named pipes
While a farm can be in either Classic Mode or Claims Based Authentication, service application
communication will always use Claims Based Authentication.
Microsoft Corporation Page 167
Application directories
In IIS, the directory for hosting the service applications differs between MSF 2010 and SharePoint 2010.
For MSF 2010, the location is:
C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\Web Services\
For SharePoint Server 2010-specific service applications, the location is:
In MSF 2010, service applications expose their services as WCF Web services. In order to connect to
these services, the WFE servers must use an application proxy. Application proxies are virtual links used
to connect Web applications to the service applications. Application proxies are automatically created
when you create a service application.
When a Web Part or a control on a page needs to perform some work, it needs to know how to contact
the Web service that is going to perform the work. The Web Part or the control passes the request to
the service application proxy which is responsible for connecting to the Web service. Each server hosts
the topology service, which enables the proxy to determine which server is running the service
application. The proxy will ask the Application Discovery and Load Balancer service application which
32
Service Application Proxy
Is a virtual link used to connect Web applications to the service
applications
Is created automatically during the creation of a service application
Asks the Application Discovery and Load Balancer service application
about the server that can service the request sent by the Web Part
Can run on a farm different than the farm where the application server is
running; just needs the Web service in the farm where the service
application proxy is running
If in the local farm, is not created by administrators, but appears along
with the service applications in Central Administration
Appears as a GUID virtual folder within the IIS Web site, SharePoint
Web Services.
Might include modifiable settings
Can exist in multiple service application proxy groups
Microsoft Corporation Page 169
application server can service the request. The Application Discovery and Load Balancer service
application will return the URI of a running service instance. The proxy will then make a connection to a
WCF service running on the application server.
The proxy could be running on a farm different than the farm where the application server is running. As
long as the Web service has been published in the farm where the proxy is running, the proxy will be
able to make a connection to that service by using the same process as above with the Application
Discovery and Load Balancer service application. If the proxy is in a local farm, it is not created by the
administrators, but appears along with the service applications in Central Administration.
When a new service application and proxy are added to the farm, the proxy will appear as a GUID virtual
folder within the IIS Web site, SharePoint Web Services. This site runs off of HTTP port 32843 and HTTPS
port 32844. The site will connect to the application pool that you specify at the time of its creation.
Often, this will appear as a GUID as well.
Some proxies might include settings that can be modified. For example, for the Managed Metadata
service application, you must indicate which proxy is the default taxonomy store.
A single proxy can exist in multiple service application proxy groups.
Let us consider the example of the Excel Web Access Web Part to understand how the whole process
works.
27. When the Excel Web Part wants to connect to an Excel service application, it will send the
request to the service proxy.
28. The proxy must know the WCF service endpoints that it should connect to.
29. Assuming that the administrators have configured the topology proxy (NOT the topology
service) in the consuming farm, the topology proxy contacts a topology service on any
service in the remote farm.
30. The remote farm returns a list of URIs to the topology proxy.
31. The load balancer on the consuming server then alternates through the available service
endpoints.
32. Periodically, the topology proxy will contact the publishing farm for an updated list of the
available endpoints.
33. The load balancer will keep an in-memory list of cached endpoints. The list will either be
updated by the topology service updates or temporarily taken out of the rotation, if the
endpoint is unavailable (service error returned or no response).
Microsoft Corporation Page 170
Creating Service Applications
Creating a service application using the Farm Configuration Wizard
The primary purpose of the Farm Configuration Wizard is to automatically install service applications for
a farm. This wizard is normally used in small test or demonstration environments where finer control
over how a service application is created may not be as important.
When running the Farm Configuration Wizard, you have the opportunity to select one or more services
to install. Any service already installed in the farm will be grayed out to prevent their selection.
You must consider the following when running the Farm Configuration Wizard to create service
applications:
You are presented with the option to create only those services that are not already
configured. If any instance of a particular service application is already running in the farm,
the option to select that service will be grayed out, irrespective of whether or not that service
application was created via the Farm Configuration Wizard.
When you use the Farm Configuration Wizard to create a service application, the service
instances for that application will automatically be started on all servers in the farm. Note that
this is not the case when you create service applications manually, where if an instance is not
started, the service cannot be consumed.
All service applications created using the Farm Configuration Wizard will each use the same
service account. This affects only those services that you select for installation when running
the Farm Configuration Wizard.
34
Creating Service Applications
Via the Farm Configuration Wizard:
• Presents the option to create only non-configured services
• Automatically starts the service instances for an application on all farm
servers
• Makes all service applications use the same service account and share the
same application pool
• Appends a GUID to the content database names of the service applications
Via Central Administration
• Uses serviceapplications.aspx available in the Application Management
section of the Central Administration Home page
• Requires starting an instance of the service on at least one server via the
Manage services on server link
Via the SharePoint Management Console
Microsoft Corporation Page 171
All services instantiated by the Farm Configuration Wizard will share the same application
pool.
The content databases for service applications created via the Farm Configuration Wizard
will have a GUID appended to their name. This is not the case when you manually create
service applications via other means.
Creating a service application using Central Administration
Most administration for service applications in Central Administration is done via
serviceapplications.aspx, which can be accessed via the Application Management section of the Central
Administration Home page.
The screenshot below shows the Manage Service Application page with a list of all the service
applications in the farm. The New button in the Service Applications tab of the ribbon reveals a list of
services that you can choose from to create a new service application. When you select a service, the
options for configuring that particular service are selected by default.
Before you can use a service application, you must start an instance of that service on at least one server
via the Manage services on server link.
Microsoft Corporation Page 172
Creating a service application using the SharePoint Management Console
You can also create a service application via the SharePoint Management Console. An overview of the
steps is included below. The lab exercises that accompany this module will step through the process in
more detail.
34. Start a service application instance. The service application should have already been
installed.
35. Create an application pool for the service application to use. Alternatively, you can use an
application pool used by another service. However, remember not to use an application pool
being used by a Web application.
36. Create the service application.
37. Create the service application proxy.
Microsoft Corporation Page 173
Managing Service Applications
You can manage all service applications via the serviceapplications.aspx page in the following two ways:
Click the service application.
Highlight the service, and click the Manage button on the Service Applications ribbon.
You also can use the Properties button on the serviceapplications.aspx page to list the basic properties
of a service application that you specified at the time of its creation. Note that you cannot view the
properties of all service applications.
The following screenshot shows the basic properties of a sample Business Data Connectivity service
application:
37
Managing Service Applications
Can be done via the serviceapplications.aspx page in
the following two ways:
• Click the service application.
• Highlight the service, and click the Manage button on the
Service Applications ribbon.
Can also be done via the Properties button on the
serviceapplications.aspx page
Microsoft Corporation Page 174
Microsoft Corporation Page 175
Microsoft Corporation Page 176
Classes of Service Application Administrators
Unlike SSPs in MOSS 2007, in MSF 2010, you can assign administrators to individual service applications.
There are primarily three classes of administrators associated with service applications.
Farm administrator
The farm administrator has full control of all service applications.
Delegated service administrator
Highlight a service application on the serviceapplications.aspx page, and click Administrators in the
ribbon to add administrator(s) for the service. A service application administrator is assigned Full Control
over all service applications.
Delegated feature administrator
Certain service applications also allow delegating the administration of certain features specific to that
service application. At the time of scripting the content for this workshop, no service applications
included in MSF 2010 have any features available for administrative delegation. However, there are
some such service applications in SharePoint 2010. The following screenshot shows the Business Data
Connectivity and User Profile service application, where a user account can be delegated to administer
the entire service application (Full Control) or to administer only specific features such as managing
profiles or audiences.
40
Classes of Service Application Administrators
Farm administrator
• Has full control of all service applications
Delegated service administrator
• Is assigned Full Control over all service applications
Delegated feature administrator
• Can be delegated to either administer the entire service
application (Full Control) or administer only specific
features such as managing profiles or audiences
• Can also be assigned permissions from within the
management interface of a service application
Microsoft Corporation Page 177
Remember that this is not the only possible place administrative feature delegation can take place.
Within its management interface, a service application can allow the management of rights to the
features of that application. For example, the Managed Metadata service application that is included in
SharePoint 2010 has the ability within its management interface to designate term store administrators.
Microsoft Corporation Page 178
Connecting Web Applications to Service Applications
When you create a service application in SharePoint 2010, a service application connection, also known
as service application proxy, is created. This connection associates the service application to Web
applications via membership in a service application connection group (also referred to as service
application proxy group). The following diagram displays the service application proxy group related to a
Web application and the service applications within that group:
Service application proxy groups
A Web application can consume any number of service applications. Service application proxy groups
are a logical container for grouping these service applications for use by a Web application.
42
Connecting Web Applications to Service Applications
Is achieved by using service application proxy groups
• Are logical containers for grouping service applications for
use by a Web application
• Can be either default or custom
o All service applications created via the Farm Configuration
Wizard are added to the default service application proxy
group
• Can be created when creating a Web application, but can
be modified afterwards
• Can be edited using Central Administration
• Can have a service application connection added or
removed to them by using Windows PowerShell
Microsoft Corporation Page 179
By default, all service applications created via the Farm Configuration Wizard are added to the default
service application proxy group. Any new Web application will be by default associated with the default
service application proxy group. If you create a new service application by using Windows PowerShell
instead of by using Central Administration, the new service application does not automatically become a
member of the default service application proxy group unless you supply the -default parameter.
You can create service application proxy groups at the time of the creation of Web application; however,
they can be modified afterwards.
Note: The default service application proxy group is the only reusable proxy group. Custom proxy groups can only be associated with the Web application where the customizations were made; they cannot be reused by another Web application.
To edit an existing service application proxy group by using Central Administration
38. Verify that the user account that is performing this procedure is a member of the Farm
Administrators SharePoint group.
39. On the Central Administration Home page, click Application Management.
40. On the Application Management page, in the Service Applications section, click
Configure service application associations.
41. On the Service Application Associations page, select Web Applications from the View
drop-down menu.
42. In the list of Web applications, in the Application Proxy Group column, click the name of
the service application proxy group that you want to change.
43. To add a service connection to the group, select the check box that is next to the service
application that you want to add to the service application proxy group. To remove a service
application connection from the service application proxy group, clear the check box next to
the service application that you want to remove. When you have made the desired changes,
click OK.
Note: You can also change custom service application proxy groups by clicking Manage Web Applications from the Central Administration Home page, selecting a listed Web application, and then clicking Service Connections on the ribbon. However, you cannot
change the default service applications proxy group through this page.
To add a service application connection to a service application proxy group by using Windows
PowerShell
44. On the Start menu, click Administrative Tools.
45. Click SharePoint 2010 Management Shell.
46. At the Windows PowerShell command prompt (PS C:\>), type the following command, and
then press ENTER:
Microsoft Corporation Page 180
Add-SPServiceApplicationProxyGroupMember [-Identity <the service application proxy
group>] [-Member <members to add to the service application proxy group>]
To remove a service application connection from a service application proxy group by using
Windows PowerShell
47. On the Start menu, click Administrative Tools.
48. Click SharePoint 2010 Management Shell.
49. At the Windows PowerShell command prompt (PS C:\>), type the following command, and
Recycle, Throttling, and Preferred Timer Server. In addition, you learned how to add and manage service
applications as well as create service application proxy groups and connect them to other SharePoint
farms.
50
Module 2 Summary
In this module, you learned about:
• The role of new elements introduced in the Central
Administration UI.
• How to create Web applications and site collections.
• How to configure and manage timer jobs.
• How to configure and manage service applications.
Microsoft Corporation Page 189
Module Patch Management
Microsoft Corporation Page 190
Microsoft Corporation Page 191
Module Patch Management
Introduction
Patch management is one of the most important functions that a Microsoft SharePoint administrator
needs to perform. This module provides insight and understanding into the patching process used for
SharePoint 2010.
Objectives
After completing this module, you will be able to:
Determine an upgrade approach appropriate for your SharePoint environment.
Describe the improvements in the SharePoint 2010 patching process over MOSS 2007.
Reduce the downtime associated with patching.
Microsoft Corporation Page 192
Section 1: Patching Overview
3
Section 1: Patching Overview
What‘s Inside A Patch?
Types of Updates
Service Pack and Cumulative Update Interaction
Overview of Patching Process
Upgrade Approach – In Place
Upgrade Approach - DBAttach
Introduction
This section introduces the various types of updates as well as the two possible upgrade approaches
available for Microsoft SharePoint 2010.
Objectives
After completing this section, you will be able to:
Identify the various components of a patch.
Differentiate between the various types of updates available for SharePoint 2010.
Identify the phases involved in the patching process.
Explain the features of two upgrade approaches available for SharePoint 2010.
Microsoft Corporation Page 193
What’s Inside a Patch?
4
What’s Inside A Patch?
Packages – Compiled, executable installer files that
contains updates to one or more products
• Global Package
• Localized Package
Updates - Contained in the package in the form of a
series of MSP files.
Transforms - Contained in the update (MSP file) itself, in
the form of MST files
Microsoft provides several different kinds of software updates for SharePoint 2010. Before you study
the details of these updates, Microsoft recommends that you learn the key terminology used to describe
the inner components of a patch.
Packages
A package—sometimes called a patch—is a compiled, executable installer file that contains updates to
one or more products. Examples of packages are the executable (.exe) files that you download to install
a critical on-demand (COD) hotfix, cumulative update (CU), or service pack. Packages are also known as
MSI files.
When you install a particular update for a given deployment of SharePoint 2010, you need to install the
following two package(s) to ensure that your deployment is up to date:
Global package. This updates the core components of SharePoint 2010.
Localized package. This updates the language-specific components of SharePoint 2010.
Historically, localized packages were released only in languages that were specifically
requested, but in response to feedback from customers, they are now released in every
language.
The core components of SharePoint 2010 are language-agnostic. Any language-specific items of code are
stored in separate DLL or resource files. Many farm deployments have additional SharePoint language
packs installed in the following scenarios:
Microsoft Corporation Page 194
Where English is not the primary language spoken in the region where the farm is deployed
and therefore, a region-specific language pack has been installed—for example, a French
language pack installed by an organization based in France.
Where a global deployment of SharePoint 2010 has one or more farms that span and support
multiple regions that require language packs to support the languages of those regions. For
example, a SharePoint 2010 deployment that provides services to users in Germany, Spain,
and the Middle East may have installed German, Spanish, and Arabic language packs.
In summary, an out-of-the-box installation of SharePoint 2010 is like having a localized version in the
core language. For example, an installation of SharePoint Server 2010 in U.S. English will include the
region-agnostic core components plus the U.S. English localized components. This example deployment
is commonly (and incorrectly) viewed as a non-localized version of SharePoint Server 2010.
Updates
The actual update itself is contained in the package in the form of a series of MSP files. You can run
these MSP files directly, rather than execute the installer package that contains them. The drawback to
running these files directly is that, after the update is installed, the SharePoint 2010 Configuration
Wizard automatically runs in silent mode and invokes a build-to-build upgrade. This may be a problem in
a multi-server farm environment, not only because the binaries will be out of sync between the servers,
but also because the version numbers of the back end databases might be incremented (depending on
which MSP file is run and what changes were implemented by the update in the version that was
running before the MSP file was run).
Transforms
A transform is contained in the update (MSP file) itself, in the form of an MST file. The transform guides
the installation of the update based on the environment. An update can include different transforms to
support different environments; for example, an update may have one transform to be used with an
RTM build of SharePoint Server 2010 and another for the June 2010 CU build of SharePoint Server 2010.
If a transform for the current installation of the product is not available, you will get an error message
that the product is not recent enough to be updated. For example, in SharePoint 2007, you will receive
this error if you try to apply the April CU to an RTM build, because the April CU was released after
Service Pack 2 (SP2) was released, and RTM support ended after SP2 shipped.
Microsoft Corporation Page 195
Types of Updates
5
Types of Updates
Hotfix
• Critical on-demand (COD)
• Microsoft update
• Post-service pack rollup
Cumulative Update
• Cumulative updates per component
• Server-Package Cumulative Update
o SharePoint Server 2010 server-package includes SharePoint
Foundation 2010 server-package
o Includes all of the latest global and localized updates
o Includes all updates since RTM
o Does not include Fast Search for SharePoint or Office Web
Applications components updates.
Let us now take a look at the different kinds of software updates available for SharePoint 2010 in a little
more depth.
Hotfix
A hotfix is generally created to address a specific problem raised by a customer. There are three
different types of hotfixes:
Critical on-demand (COD). A COD hotfix is available to address critical problems that
cannot be handled via the CU delivery cycle. COD hotfixes are limited to emergency
situations; for example, an issue that blocks normal business operations for the customer or
an issue for which there is no effective workaround. COD hotfixes are included in the next
CU that is released.
Microsoft update. Occasionally, based on the criticality of an update, a COD hotfix is made
available for public download or a Microsoft security update is released as a public update for
SharePoint 2010. The US DST Hotfix - KB941422 is an example of a security update that was
released as a Microsoft update for SharePoint 2007.
Post-service pack rollup. This update package includes any SPLock hotfixes, which are
hotfixes that were developed during the SPLock period. The SPLock period is a lockdown on
service pack development that is meant to help achieve stability in the development process.
Any hotfixes that have been produced before the SPLock period is declared are integrated
into the next service pack. SPLock hotfixes are never distributed publically and are only
made available during Microsoft Customer Service and Support engagements. SPLock
hotfixes require special handling because if the next service pack is applied without the post-
Microsoft Corporation Page 196
service pack rollup, the fix is lost. This could cause data loss, so Microsoft is very careful
about releasing these SPLock hotfixes and provides detailed guidance for each customer
scenario.
Cumulative Update (CU)
A CU includes all updates that broadly affect support issues that have been released since the last
service pack. CUs are typically released on a bi-monthly basis. There are two formats of CUs:
Cumulative updates per component. In this format, updates are released for components
individually. For example, the June 2010 CUs for SharePoint 2010 were released in this
format, where there were separate update packages for SharePoint components, including
SharePoint Foundation 2010, Search, etc. It is important to note that localized updates for
these components are also released separately.
Server-package CU. A server-package contains the latest of every hotfix update that has
ever shipped for every component in Microsoft SharePoint Foundation (MSF) 2010 and
SharePoint Server 2010. Consider a scenario where you want to build a new SharePoint
Server 2010 farm. You can apply the latest service pack and the latest SharePoint Server
2010 server-package CU and be completely up-to-date.
Note: There might have been a COD hotfix beyond the CU. However, COD hotfixes receive the least testing of all updates, and Microsoft does not recommend that you install them simply to keep your environment up-to-date.
A few key points should be noted on the structure of the new update format for SharePoint 2010:
All of the latest global and localized updates for SharePoint Server 2010 are in the SharePoint
Server 2010 server-package. However, the server-package does not include Fast Search for
SharePoint or Office Web Applications component updates.
All of the latest global and localized updates for SPF are in the SharePoint Foundation 2010
server-package.
The SharePoint Server 2010 server-package includes the SPF server-package.
The list of what is in any CU package is an accumulation over time of what has shipped since
RTM. It is important to understand that CUs only affect those components for which a hotfix
has actually been built. In contrast, a service pack updates all of the MSI files.
Microsoft will always strive to releases CUs in a server-package format; however, this is not always
possible due to late breaking issues. These issues can and do occur while building or testing any type of
update, which can change the delivery date and also have an impact on the type of package delivered.
Microsoft Corporation Page 197
Types of Updates (Continued)
6
Types of Updates (continued)
Service Pack
• Includes all Hotfixes and CUs, plus additional stability and
performance improvements
• After a service pack is released, the n-1 build is supported
for approximately 12 months.
o Once a build is announced unsupported, cumulative
updates will not typically ship with a transform for these
builds
Service Pack
Service packs include all of the updates for SharePoint 2010, which means all hotfixes and CUs, but not
the SPLock hotfixes described previously. Service packs also deliver important stability and performance
improvements that might not have been requested specifically by customers, but were found internally
by the product group. These improvements incorporate further enhancements to user security.
After a service pack is released, the n-1 build is supported for approximately 12 months; after 12
months, updates for an n-1 build will not typically be shipped. Once a build has been announced as
unsupported, CUs will not typically ship with a transform for these builds.
As an example, let us take a look at what happened with SharePoint 2007. RTM for Windows SharePoint
Services (WSS) 3.0 and Microsoft Office SharePoint Server (MOSS) 2007 went out of support on January
13, 2009, which resulted in SP1 becoming the minimum supported build. From this date onward, CUs
did not typically ship with a transform for any builds prior to SP1. Microsoft still reserves the right to
ship these transforms for limited periods of time past the 12 months, but it is a choice made under
certain circumstances. Since August 2010, CUs cannot be applied directly to the SP1 version of
SharePoint installations; SP2 is the minimum requirement.
Microsoft Corporation Page 198
Service Pack and Cumulative Update Interaction
7
Service Pack and Cumulative Update Interaction
Occasionally, a service pack and a cumulative update
(CU) will be released almost simultaneously
Install the latest service pack and latest CU server-
packages to get full set of latest updates
• It is likely that the CU will contain fixes (e.g. post-service
pack rollup) not included in Service Pack.
• The Service Pack will contain updates not included in the
CU.
Occasionally, a service pack and a CU will be released almost simultaneously. An example of this is the
release of the April CU on April 30, 2009 and the SP2 release on April 28, 2009 for SharePoint 2007.
This SP2 includes every hotfix, security update, infrastructure update, service pack, or any other update
that was released for SharePoint 2007 through February 2009. This follows the behavior of any service
pack for SharePoint in that all updates released since RTM will be included in the service pack until
SPLock begins. Therefore, all hotfixes that were released in CUs prior to the April CU are included in SP2.
In general, it is likely that the CU will contain fixes, such as post-service pack rollup, that are not included
in the service pack.
However, if only the CU is installed, and not the service pack, some of the updates included in the
service pack will not be present in the environment. For the fullest set of updates to be installed,
Microsoft recommends that you install both the service pack and the CU.
To explain further, the April CU for SharePoint 2007 includes only a subset of SP2 files—those that were
updated in response to a hotfix request. In contrast, SP2 contains product improvements and updates to
many other files that are not impacted by a hotfix request. The volume and diversity of fixes in SP2 is
much greater than those in the April CU. The general guideline is to install the latest service pack and
the latest server-packages CU to get the full set of latest updates.
Microsoft Corporation Page 199
Overview of the Patching Process
9
Overview of Patching Process
1. Update Phase
• Copy new binaries to SharePoint server
• Copy support files to appropriate directories on
SharePoint server
2. Upgrade Phase
• Upgrade all SharePoint processes
• Upgrade Databases
It is important to understand that deploying patches in a SharePoint Server 2010 environment is a two-
phase process—updating the software and upgrading the software. Each phase has specific steps and
results which are discussed below.
Update phase
In the update phase, the package containing the patch is executed, which effectively has two steps.
In the first step, new binary files are copied to the server. Any services that are using binary files that
need to be replaced are temporarily stopped. Stopping services reduces the requirement to restart the
server to replace files that are being used. However, there are some instances when you must restart
the server.
The second step in this phase is the deployment step. In this step, the installer copies support files to the
appropriate directories on the SharePoint Server. This step ensures that all the Web applications are
running the correct binary files and will function correctly after the update is installed.
The update phase is complete after the deployment step. The next and final phase in the patching
process is the upgrade phase.
Upgrade phase
You must complete the update 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 the SharePoint Server processes that are running. After the processes are
upgraded, the databases are upgraded automatically. Although it is possible to postpone the upgrade
Microsoft Corporation Page 200
phase, postponing it for more than several days may result in inconsistent farm behavior. The longer the
postponement, the larger the risk of farm behavior issues. This is discussed further in Section 3 of this
module.
There are two approaches that you can adopt to carry out the upgrade phase—In-Place and DBAttach.
Microsoft Corporation Page 201
Upgrade Approach: In-Place
10
Upgrade Approach – In-Place
All farm components (SharePoint processes and
SharePoint databases) are upgraded sequentially.
Uses PSConfig
• Command-line tool
• Graphical User Interface
In the in-place upgrade approach, the complete farm is shut down by disabling incoming requests to the
Web Front-End (WFE) servers and the upgrade phase is carried out by running the PSConfig tool. When
you run this tool, all SharePoint farm components including SharePoint processes and SharePoint
databases are upgraded sequentially. During the upgrade process, the farm will be completely
unavailable to users. You can run the PSConfig tool from the command-line, or you can run the GUI
version of the tool.
Microsoft Corporation Page 202
Upgrade Approach: DBAttach
11
Upgrade Approach - DBAttach
Content databases are disassociated from the farm
All farm components are upgraded (SharePoint
processes)
Content databases are associated again with the farm
―attached‖ and upgraded on the fly
Advantages of DBAttach:
• Attach content databases in order of importance.
• Clever administration can allow for increased throughput –
more on this in Section 3.
PowerShell Cmdlet to attach content database:
• Mount-SPContentDatabase
In the DBAttach upgrade approach, before the farm is upgraded, all SharePoint content databases are
disassociated from the farm. The upgrade phase is then carried out by running the PSConfig tool. When
you run this tool, all SharePoint farm components are upgraded sequentially. This will be a fairly quick
process because the content databases are no longer attached to the farm and consequently, will not be
upgraded.
As with the in-place upgrade, when you run PSConfig, the farm will be completely unavailable to users.
Once the upgrade is complete, the farm is accessible, the content databases can be attached back to the
farm, and they are upgraded as they are attached to the farm. As soon as a content database has been
attached and the upgrade is completed, users can access the content within that database.
The advantages of this approach include:
You can attach databases in the order of importance and have content within important
databases made available more quickly, without having to wait for all databases to be
upgraded.
With clever administration, you can increase the throughput of upgrade by using multiple
DBAttach threads and even multiple farms.
Note: More details on increasing the upgrade throughput and minimizing downtime are covered in Section 3 of this module.
Microsoft Corporation Page 203
Note: You can attach content databases to a SharePoint farm by using the Mount-
SPContentDatabase Windows Powershell cmdlet.
Microsoft Corporation Page 204
Section 1 Review
12
Section 1 Review
What is the difference between an MST and an MSP?
Should a cumulative update always be installed before a
service pack?
What are the two main advantages of using the DBAttach
approach over In-Place?
Answer the questions listed on the slide above.
What is the difference between an MST and an MSP?
Should you always install a CU before installing a service pack?
What are the two main advantages of using the DBAttach approach over in-place?
Microsoft Corporation Page 205
Section 2: Improvements in Patching From Previous Version
13
Section 2: Improvements In Patching From Previous Version
Backwards Compatibility
Performance improvements
PSConfig Improvements
Monitoring the status of updates
Introduction
This section discusses the improvements made to the patching process in SharePoint 2010 over that of
MOSS 2007.
Objectives
After completing this section, you will be able to:
Explain how the patching process has been improved using the backwards compatibility
capability.
Identify the performance improvements made to the upgrade mechanisms, which directly
impact patching.
Identify the improvements made to the way in which PSConfig handles the upgrade phase of
patching.
Explain the various tools available to track the status of updates across all servers in a
SharePoint farm.
Microsoft Corporation Page 206
Backwards Compatibility
14
Backwards Compatibility
Allowing Update phase to occur separately to Upgrade
phase
Patches can be installed on servers without immediately
incurring downtime
• Must be within compatibility boundary
Certain scenarios where this may be useful:
• Benefit from a critical patch without experiencing downtime
• Reduce maintenance windows within which we incur
downtime
• Databases running at different versions
To apply a patch in SharePoint 2007, you need to install the patch on a given server in the farm. After
the package installation has completed, it automatically launches PSConfig at the end, which helps you
upgrade the server and dependent farm components. Running PSConfig invokes the upgrade of all
databases which can potentially be a long-running operation, during which time the server farm is
unavailable to the end users.
In SharePoint 2010, patches are built so that while they are being installed on SharePoint servers,
SharePoint databases can still run at a previous patch level, as long as this patch level is within a
compatibility boundary, effectively allowing the update phase to occur separately from the upgrade
phase. This gives you some flexibility on when patches are installed and when databases are upgraded.
Patches released at version N maintain backwards compatibility to any back end databases whose
versions are within [N-1, N], where N is a minor release point such as RTM or SP. When a SharePoint
server runs with an older back end, it is said to be running in compatibility mode. The minor release
points are likely to be the compatibility boundaries. However, Microsoft reserves the right to introduce
a compatibility boundary, as required, based on the updates that may be required to be made to the
SharePoint product code.
The backwards compatibility capability may be useful in the following scenarios:
You can benefit from a critical patch such as a security fix without experiencing downtime.
In other words, you can install the patch on all of your SharePoint servers gradually by taking
WFE servers out of rotation one at a time and installing the patch. Not only does this give you
Microsoft Corporation Page 207
the immediate benefit provided by the patch, but also allows you to defer the database
upgrade to a later, more convenient time; for example, a scheduled maintenance window.
You can reduce your maintenance windows by installing patches on SharePoint servers, as
described in the previous point, and by simply using your maintenance windows to carry out
the upgrade phase, at which point your databases will be upgraded.
There may be situations when databases are running at different versions, and you need to
recover a specific content database from an older version of a backup (still within the
compatibility boundary). The backwards compatibility feature of patching is useful in such
scenarios.
Microsoft Corporation Page 208
Backwards Compatibility (Continued)
15
Backwards Compatibility (continued)
Shouldn‘t leave in this state too long!
SharePoint servers should all be consistent
Databases may incur upgrade when mounted/attached
• Databases outside of compatibility boundary will
automatically upgrade
• Databases within the compatibility boundary require
Upgrade-SPContentDatabase
Although the backwards compatibility feature allows you to postpone the upgrade phase, as mentioned
earlier, doing so can result in farm behavior issues. In addition, it is important to ensure that all
SharePoint servers are consistent, and not at varying version levels.
In SharePoint 2007, when databases are attached to a SharePoint farm, the upgrade process starts
automatically if the databases are at an older version than the farm. In SharePoint 2010, the upgrade
behavior depends upon whether or not the database is within or outside the compatibility boundary.
While databases outside of compatibility boundary will upgrade automatically, databases within the
compatibility boundary will not do so and will maintain their existing version. You can upgrade
databases within the compatibility boundary on a per content database basis by using the Upgrade-
SPContentDatabase Windows PowerShell command.
Microsoft Corporation Page 209
Performance Improvements
16
Performance Improvements
Fewer schema alteration actions
Database Upgrade State indication
(avoid round trips)
Parallel Database Attach:
• Multiple content databases can be attached in SharePoint 2010
at the same time
o Just use multiple Windows PowerShell sessions
• Parallelism has benefits and limits
o Parallel upgrading multiple databases on separate spindles
should be much quicker than serially upgrading them
But don‘t expect it to be as fast as the time it takes to upgrade your
largest database on its own
Several performance improvements have been introduced to the upgrade mechanisms within
SharePoint 2010, which directly impact patching.
Note: The Microsoft SharePoint product group endeavors to reduce the amount of changes made to the schema of SharePoint databases with updates, because these types of update actions take a long time to perform.
In SharePoint 2007, if the patching process had to enumerate all the site collections once at the
beginning and then later on in the process, it was not smart enough to save that information. In
contrast, in SharePoint 2010, the site collection list is cached, preventing the patching process from
asking the content database for the same object twice.
In SharePoint 2007, the way stored procedures are upgraded is not very efficient either. When you
patch, all stored procedures are dropped and the new ones are copied over. This process is incredibly
inefficient, especially when only a small part of a stored procedure has changed. In contrast, in
SharePoint 2010, it is only the deltas that are copied to make the required changes. As a result, if you
have a lot of databases, you should experience significant performance gains.
In SharePoint 2007, only one upgrade process could run at a time, meaning each database needed to be
processed sequentially. As discussed in the Upgrade module (Module 3), SharePoint 2010 offers the
capability of attaching multiple databases at the same time, called parallel database upgrade. It is,
however, important to consider both the benefits and limitations of upgrading databases by using
parallel database upgrade.
Microsoft Corporation Page 210
Using the parallel upgrade approach to upgrade multiple databases on separate spindles should be
much quicker than serially upgrading them, but do not expect it to be as fast as the time that it takes to
upgrade your largest database on its own. If the databases are stored on the same spindle, it is likely
that it will take longer for the upgrade to complete due to disk contention. SQL IOPS and memory are
very important in the performance of a parallel upgrade. The number of parallel upgrades that you can
perform at one time depends on your hardware and the structure of the content. It is not easy to
provide guidance on this configuration because it will be different for every environment.
Microsoft Corporation Page 211
PSConfig Improvements
17
PSConfig Improvements
PSConfig can be run on multiple boxes concurrently
• PSConfig will put a lock on the farm it is upgrading
• Each instance of PSConfig looks for a lock or the upgrade
status
PSConfig checks build levels of binaries are consistent on all
servers in farm before executing
In SharePoint 2010, the following improvements have been made to the way in which PSConfig handles
the upgrade phase:
PSConfig can be run on multiple servers concurrently. When PSConfig is run the first
time, it puts a lock on the farm that it is upgrading. Any subsequent instances of PSConfig
that are executed look for a lock on the farm. Consequently, if an instance of PSConfig is
already running on one server in the farm, any subsequent instances of PSConfig that have
been started on other servers in the farm will be aware of this. Although the processes will be
running, they will not attempt to upgrade any farm components until the first lock in the farm
has been removed and they can place a lock on the farm themselves.
PSConfig checks to ensure that the build levels of binaries are consistent on all servers
in a farm before executing. When PSConfig runs, it first checks that all components across
all servers in the farm are at a consistent build level. If the build levels differ, PSConfig will
not allow you to proceed with the upgrade.
The following screenshot shows an example of PSConfig identifying a mismatch of component build
levels across servers within a farm. Note that the Next button is grayed out.
Microsoft Corporation Page 212
Microsoft Corporation Page 213
Monitoring the Status of Updates
19
Monitoring the Status of Updates
Central Administration
• Product Install / Database Status
• Health rules
PowerShell:
• Get-SPContentDatabase
o Validate NeedsUpgrade Property
• Get-SPProduct -local
STSADM –o localupgradestatus
In SharePoint 2007, it was very difficult to keep track of the patches installed, ensuring that versions of
components across servers in the farm matched, and ensuring that the patches had been correctly
deployed. In SharePoint 2010, you have a greater number of farm components to consider, and it is
more likely for different components to be at different build levels within a farm. An even greater
concern is if you have different servers with the same components at different build levels.
SharePoint 2010 has some new built-in tools that allow you to track the status of build levels of all
databases and components across all servers in your farm.
Central Administration
Central Administration now provides one central location—the Check Product and Patch Installation
status page—where you can view the status of build levels for all components across all servers in the
farm. This page also notifies you if any servers have a patch that needs to be installed and if there are
inconsistencies between the servers in the farm, meaning another server in the farm has a specific
component at a higher build.
Central Administration also provides the Database status page to show the status of all databases,
indicating if any actions are required. For example, if the databases are in compatibility mode, this will
be stated on the Database status page and upgrade will be recommended.
In SharePoint 2010, you also have a series health rules as part of the Health Analyzer pertaining to
patching which will fire when certain criteria are met. These health rules are useful to keep
administrators aware of potential problems and address them in a proactive manner. A subset of these
rules include:
Microsoft Corporation Page 214
Databases require upgrade.
Databases are running in compatibility range, upgrade recommended.
Product/patch installation or server upgrade required.
Windows PowerShell
You can use the following Windows PowerShell cmdlets to check the build level status of components
within your farm:
Get-SPContentDatabase. Check the NeedsUpgrade property of this cmdlet to determine if
a specific content database requires upgrade. A value of false indicates that the database is in
compatibility mode.
Get-SPProduct –local. This cmdlet checks the local server for build levels of SharePoint
binaries and indicates if any components on the local server are missing any patches.
stsadm
The following stsadm command iterates through all local services and content databases within a farm
and indicates if any objects (including site collections) require upgrading:
STSADM -o localupgradestatus
Microsoft Corporation Page 215
Section 2 Review
20
Section 2 Review
What are three scenarios where the Backwards Compatibility
capability may be useful?
Is it advisable to keep build levels of different components
within a farm at different versions?
Name two performance improvements to the upgrade engine
in SharePoint 2010?
Answer the questions listed on the slide above.
What are three scenarios where the backwards compatibility capability may be useful?
Is it advisable to keep build levels of different components within a farm at different
versions?
Name two performance improvements made to the upgrade engine in SharePoint 2010.
Microsoft Corporation Page 216
Section 3: Patching Process
21
Section 3: Patching Process
Patching Strategy
Preparation
Minimizing Downtime
Upgrade Order and Parent-Child Farms
Verifying Success
Common Failures
Introduction
This section discusses how to minimize the downtime associated with patching as well as the order in
which upgrades should be completed. It also explains how to verify the success of patching.
Objectives
After completing this section, you will be able to:
Identify the factors to consider when selecting a patching strategy appropriate for a
SharePoint farm.
Identify the tasks involved in the preparation phase of patch installation.
Explain the various methods available for minimizing downtime while patching.
Identify the considerations to be taken care of when deciding upon the order to perform
upgrades in parent-child farm relationships.
Verify the success or failure of the patching process.
Identify the common issues encountered during patch installation.
Microsoft Corporation Page 217
Patching Strategy
22
Patching Strategy
Factors to consider:
• Amount of downtime that is acceptable
• Amount of resource available
Available options:
• Install the update and do not defer the upgrade phase
• Install the update and defer the upgrade phase
• Install update with the lowest possible downtime and defer the
upgrade phase
You must consider the following factors when selecting a patching strategy appropriate for your farm:
The amount of downtime that is acceptable for installing the update
The additional staff and computing resources that are available to reduce the downtime
involved
You must also consider how the strategy enables you to manage and control the update. In terms of
downtime reduction, you can use one of the following options, ordered from most to least downtime:
Install the update and do not postpone the upgrade phase.
Install the update and postpone the upgrade phase.
Install the update with the shortest possible downtime and postpone the upgrade phase.
The various methods available to minimize the upgrade downtime are described later in this section.
Microsoft Corporation Page 218
The Preparation Phase
23
Preparation
Plan the patch deployment strategy
Create a communication plan
Back up the environment
Document the environment
Test
Plan the patch deployment strategy
Determine the patch deployment approach and the required downtime minimization. In addition to
determining hardware, space, and software requirements, you should include the following in your
update strategy:
The update sequence for the farm servers
The order of operations
The downtime limits and how you plan to reduce downtime
A rollback process, if there is a major problem
Create a communication plan
It is very important to communicate with site owners and users about what to expect during the
patching process. The administrator should inform them about the downtime and the risk that the
upgrade may take longer than expected or that some sites may need some rework after upgrade.
Back up the environment
To ensure that you can recover the existing environment in case something goes wrong during the
patching process, Microsoft recommends that you back up the SharePoint 2010 environment before you
start installing the update. A failed software update can be caused by factors other than the update
process, such as media failure, user errors (such as deleting a file by mistake), hardware failures (such as
a damaged hard disk or permanent loss of a server), power failures, etc. Test the farm backups before
you start to deploy the patch. You need to be sure that these backups are valid and restorable. This will
Microsoft Corporation Page 219
ensure that you have the ability to recover data if there is a hardware failure or data corruption during
the update process.
Document the environment
Be sure to document the farm environment, including any custom components in the farm, in case you
need to rebuild them. In addition, document unique things about your farm, such as:
Any large lists
Any sites with large access control lists (ACLs)
Any sites that are critical to your organization
Having a list of these items will help you quickly validate your environment after you apply a patch.
Test
The rigor, thoroughness, and detail of your tests determine the success or failure of the patch
deployment. In a production computer environment, there are no safe shortcuts, and there are
consequences from insufficient testing. Therefore, you must build a test farm that is representative of
the production environment. Microsoft recommends that you use a copy of the production data to
determine potential problem areas and monitor overall system performance during the upgrade. The
key indicator is the length of time that it takes from the beginning to the end of the deployment process.
This should include backup and validation. You can incorporate this information in the order of
operations scheduled for the upgrade. If possible, use hardware in the test environment that has
equivalent performance capabilities to the production servers.
Microsoft Corporation Page 220
Minimizing Downtime Using Parallel Database Upgrade
24
Minimizing Downtime
Parallel database upgrade with multiple threads
Parallel database upgrade using multiple farms
As discussed in Section 2, SharePoint 2010 offers you the ability to upgrade databases in parallel by
using multiple threads. Another approach that you can consider is to use one or more separate,
temporary small farms to perform the upgrade. In this approach, you attach the content databases to
the original farm after they have been upgraded.
The steps to use temporary small farms to upgrade the content databases are as follows:
56. Set up multiple (for example, two) temporary small farms that are running SharePoint 2010.
Take the original farm offline, for example, by changing the load balancer or IIS Web
applications to stop service requests, or by turning off all the components and services on
each server computer in the farm.
57. Detach the content databases from the original farm.
58. Install the patch on all servers and run the PSConfig tool to upgrade the servers, services, and
the configuration database.
59. Attach the content databases to the temporary small farms and upgrade them in parallel.
Detach the content databases from the small farms after the upgrade is completed.
60. Re-attach the content databases to the original farm.
61. Confirm that the upgrade has finished successfully by checking the Check product and
patch installation status page in Central Administration.
This approach could be combined with the first approach so that you have parallel database upgrades
using multiple threads on multiple temporary farms.
Microsoft Corporation Page 221
The diagram on the slide above illustrates a database upgrade using a temporary farm. In order to carry
out parallel database upgrades using multiple farms, the number of temporary farms in the diagram
would be increased.
Microsoft Corporation Page 222
Minimizing Downtime Using Read-Only Databases
25
Read-only databases approach:
1. Create a new temporary farm (target patch version)
2. Set content databases in original farm to read-only
3. Detach databases and attach to temporary farm
4. Change routing / DNS to point users to the new
temporary farm and verify access to ‗Read Only‘ farm
5. Upgrade production farm using the PSConfig tool and
verify the upgrade was successful.
6. Detach content databases from temporary farm and
attach to original fully upgraded farm
7. Switch routing / DNS back to original fully upgraded
farm
Minimizing Downtime (continued…)
The read-only databases approach provides a live read-only copy of the farm during the upgrade. This
approach minimizes downtime by giving end users read-only access to the content that is being
upgraded in another farm. Once the databases are upgraded and tested, they will be attached back into
the original farm, so the only downtime experienced is when the users need to be pointed to the
temporary farm and then back to the original farm once the upgrade process is complete.
You can also use the parallel database upgrade technique to compliment this approach, ensuring even
further reduced downtime and a faster upgrade.
The steps to use temporary small farms to upgrade the content databases are as follows:
62. Create a new temporary farm (target patch version).
63. Set content databases in the original farm to read-only.
64. Detach the read-only databases from the original farm, and attach them to the temporary
farm. These databases will upgrade to the target patch version as they are attached. At this
stage, parallel threads could be used to increase the throughput of database upgrades.
65. Change routing or Domain Name System (DNS) to point users to the new temporary farm,
and verify access to the read-only farm.
66. Upgrade the production farm by using the PSConfig tool, and verify that the upgrade was
successful.
67. Detach content databases from the temporary farm, and attach them to the original fully
upgraded farm.
Microsoft Corporation Page 223
68. Switch routing or DNS back to the original fully upgraded farm.
Microsoft Corporation Page 224
Upgrade Order and Parent-Child Farms
26
Upgrade order:
• In a multi-server farm environment you should decide which
server to upgrade first.
• Aim to maximize number of components upgraded within one
operation.
• Often Central Administration server is targeted first
o If multiple CA servers exist, upgrade original first
Parent-Child Farms:
• Update Parents first
• Search example
Upgrade Order and Parent-Child Farms
Determining the upgrade order
When applying updates in a multi-server farm environment, you need to decide which server to upgrade
first, or more specifically, which server should you first run the PSConfig tool on, after the update
binaries have been installed on each of the servers in the farm. Although you can run this upgrade
operation on more than one server in the farm at a time, it will only actually upgrade one server at a
time. With regards to the upgrade order, there are many possible upgrade scenarios. A few examples
are discussed below.
A point to bear in mind is that the first server where the upgrade operation is run will initiate the
SharePoint content database upgrades, which is the longest running operation within the upgrade. In
addition, the services that have been enabled on servers will affect which components will be upgraded;
for example, a server on which the Search service is enabled will upgrade the search components. It
makes sense to optimize what is happening in an environment by upgrading multiple components
within the same upgrade operation when the first server is being upgraded. Depending on the way your
SharePoint environment is structured, it may not be possible to upgrade every single component at the
same time. The first server that you choose should upgrade as many components as possible, and the
next server that you choose to upgrade should maximize the number of components it is upgrading. This
way, any failures that are experienced can be dealt with sooner rather than later.
After all the major roles have been upgraded, the PSConfig tool will be run on the remaining servers one
at a time. Upgrading these remaining servers will be a comparatively quick process. It is generally a good
idea to target the Central Administration server first. The reason for this is to ensure that you have a
Microsoft Corporation Page 225
working Central Administration site in case you need to manage your configuration because one of the
subsequent servers failed to upgrade.
If more than one server hosts the Central Administration site, it is important to first upgrade the server
that hosts the Central Administration site that was created first. The reason for this is that the Central
Administration site that was created second will have links back to the first site, so it is important not to
upgrade the second site Central Administration when the first is not available.
In larger farms, it can be more difficult to choose which server to upgrade first. There are many different
possible upgrade scenarios, and a strategy should be put in place following the logic described above.
Parent-child farms
In parent-child farm scenarios, Microsoft recommends updating the parent farms first, followed by the
child farms. The reason for doing this is that the farms could be out of sync with each other. The
updated parent services should be resilient to work with both updated and non-updated child farms,
whereas if you update a child farm beyond the parent, it is possible that the child farm could return data
in a way that the parent does not understand or expect, which could cause inconsistent results.
Although this is likely to be a rare occurrence, it is theoretically possible, so the best practice is to keep
the parent at the same or later version than the child farms.
To illustrate this with an example, if an update changes how the search crawler works, the target would
not be aware of these code changes, whereas the source would be. In other words, if the child farms
were updated first, the behaviour of the child sitedata.asmx could potentially be altered through an
update, and a parent farm at an older build could potentially not be ready for those changes.
Conversely, if the parent is updated first, a crawler update would need to be created and tested to work
against an older version of the code as a target (that is, a separate farm scenario). This has been tested
by Microsoft.
Microsoft Corporation Page 226
Verifying Patch Installation Success
27
View the upgrade log file
View the Upgrade and Migration status pages in Central Admin
Check version numbers on certain files and registry keys
Examine the SQL Server schema
Verifying Success
There are several approaches that you can take to verify the success of a patch deployment.
View the upgrade log file
In addition to viewing the installation results in the Upgrade.log file, you can use this log file to
troubleshoot a failed installation. The Upgrade.log file is written to during the upgrade process. By
default, this log is stored in C:\Program Files\Common Files\Microsoft Shared\web server
extensions\14\LOGS. However, if the SPTimerv4 account cannot write to the default Upgrade.log, it may
write to \Documents and Settings\SPTimerv4 account\Local Settings\Temp\Upgrade.log. A separate
upgrade.log file is created per upgrade session.
You can view Upgrade.log as the upgrade takes place. Third-party tools are available to automatically
refresh the file as it is being written to. Alternatively, you can use a simple tool such as Notepad to open
and view the file. Close Notepad and re-open the file to view the latest actions that have taken place.
In Upgrade.log, various sequences and actions are repeated. This is by design. If multiple content
databases or multiple Web applications exist within a SharePoint environment, each of these sequences
and actions will be repeated for all objects in turn.
View the Upgrade and Migration status pages in the SharePoint Central Administration Web
site
Use the status pages discussed in Section 2 to verify the success of patch deployment. In addition to
these pages, you can use the Upgrade Status page to view all upgrade sessions carried out, detailing
both successful and failed attempts.
Microsoft Corporation Page 227
Check version numbers on certain files and registry keys
If you need to investigate the success of patch installation in more depth, verify the version numbers of
OWSSVR.dll and Microsoft.SharePoint.portal.dll.
Examine the SQL Server schema
You can also verify the success of patch installation by using SQL Query Analyzer to examine the SQL
Server schema. Although the version of DLL files and the registry are updated during the first part of an
upgrade—when the files are being copied—the SQL Server schema is upgraded only after the PSConfig
tool is run.
Microsoft Corporation Page 228
Common Patch Installation Issues
28
Data issues
• Connectivity to data sources
• Orphaned sites or lists
• Hidden column data
Lack of space
Patch installation not recognized
• Get-SPProduct -local
Common Failures
Data issues
The following data issues can cause errors or warnings during an upgrade:
Connectivity to data sources. If your servers cannot connect to the databases, they cannot be
upgraded.
Orphaned sites or lists, or other database corruptions. In the upgrade log files, you may
see errors such as the following:
WARNING The orphaned sites could cause upgrade failures.
Or
ERROR Database [Content Database Name] contains a site (Id = [Site Collection
Identifier], Url = [Site Collection URL]) that is not found in the site map.
It is crucial to fix any orphaned items or database corruptions, and then run upgrade again.
Hidden column data. If the upgrade process adds a column to a list, and a custom column
that has that same name already exists in this list, the custom column is renamed. After
upgrade, you might need to readjust your views to include the renamed column.
Lack of space
If you run out of space—for example, for transaction log files on your database servers—upgrade cannot
continue. Free some space, or increase the size of the transaction log file before you resume upgrade.
Security and permissions
If you receive an error about an unknown account, or if a database is not upgraded, verify the following:
Microsoft Corporation Page 229
For an in-place upgrade, ensure that the account that you are using to run the PSConfig tool
is a member of the db_owner fixed database role for all the databases that you want to
upgrade. If it is not a member of this role, you might see an error about an unknown user
account when the wizard starts upgrading the databases.
For a database attach upgrade, if you are moving databases between instances of SQL
Server, ensure that you verify that security is configured correctly. Check that the accounts
that you are using have the appropriate fixed roles and permissions on the databases, and that
they will still be valid accounts if you upgrade across domains.
Patch installation not recognized
Occasionally, after installing a patch on the servers in a multi-server farm and attempting to begin the
upgrade phase by running PSConfig, the tool does not recognize that the patches have been installed on
the servers in the farm. All patch package installations do not invoke the Product Version Job timer job,
so when you run PSConfig, it is not aware of the updated binaries on the server. Although this job runs
regularly within 24 hours, you can also force run it by executing the following Windows PowerShell
cmdlet on each server to have them update their values:
Get-SPProduct -Local
Microsoft Corporation Page 230
Section 3 Review
29
Section 3 Review
What approach can be adopted to minimize downtime and
provide a level of access to end users during patch
deployment?
What is the best practice for patching parent-child farms?
What are the ways patch deployment success can be
verified?
Answer the questions listed on the slide above.
What approach should you adopt to minimize the downtime and provide a level of access to
end users during patch deployment?
What is the best practice for patching parent-child farms?
What are the various ways that you can verify the success of a patch deployment?
Microsoft Corporation Page 231
Module Summary
30
Module Summary
Patching Overview
Improvements In Patching From Previous Version
Patching Process
This module described the patching model in SharePoint 2010. It introduced the new capabilities of the
patching mechanisms in SharePoint 2010 compared to the previous versions of the product and then
explained the end-to-end patching process, including more advanced and complex techniques that you
can leverage to minimize downtime when deploying patches.
Note: For more information on patching techniques and approaches, and for a list of the most recent patches released, refer to the resource center at http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx.