handout for print share point server 2010

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

mobile browser.

http://www.sharepointjoel.com/Lists/Posts/Post.aspx?ID=267


Communities In the first post, I talked about breaking down organization and technology silos as key driver of our

vision. Since then we have tried to make SharePoint the ultimate Swiss army knife for collaboration

with smart connections across people and teams. You told us you want to embrace new Web 2.0

approaches within a unified experience which we included in SharePoint 2007. For SharePoint 2010,

we expanded and enhanced the set of collaboration and social networking tools for both organic and

managed communities across your organization. The top five investment areas:

1. Collaborative Content – Building on the new SharePoint user experience, we made it much easier

to create and find content in SharePoint sites. This includes not only improved blogs and wikis (both

simple and enterprise) but also calendars, discussions, tasks, contacts, pictures, video, presence and

much more. With Office 2010, multiple people can simultaneously author content on a SharePoint site.

2. Social Feedback and Organization – With SharePoint 2010, we are introducing a consistent

experience for organizing, finding and staying connected to information and people including

bookmarks, tagging and ratings. We have taken a holistic approach across search, navigation, profiles,

feeds and more. We are bringing together informal social tagging with formal taxonomy described

below so you can choose the right approach for a given set of content. We have been using these

features internally for a while and I think you will find the not only useful but fun.

3. User Profiles – We enhanced user profiles to reflect colleagues, interests, expertise – either via

explicit tagging or recommendations based on Outlook and Office Communicator. The model is opt-in

http://blogs.msdn.com/blogfiles/sharepoint/WindowsLiveWriter/SharePoint2010_13F16/image_2.png


so users can manage what information is shared publically. They decide when an interest is something

they want to share or be asked about by others in the organization.

4. MySites – We significantly enhanced MySites in SharePoint 2010 building on the updated

SharePoint UI and user profile. We streamlined MySites to give you quick access to your content,

profile and social network while continuing to let you customize, target and personalize pages to the

needs of different roles and users in your organization. The enhanced newsfeed helps track interests

and colleagues.

5. People Connections – In SharePoint 2003, we introduced a universal person hyperlink and

presence icon so you can always navigate to a user’s MySite, send them mail, start an IM, call, etc. In

this release, we enhanced this UI in conjunction with Outlook and Office Communicator as well as

greatly improved the colleague tracking and people search features with new algorithms and user

experience leveraging expertise, social data and more. MySites also include a new interactive

organization browser built using Silverlight to give you another way to navigate the organization. In

larger companies, org. chart browsing via the address book is one of the most popular features in

Outlook and we think this takes that experience to the next level.

Content SharePoint 2007 brought together document management, records management and web content

management with a consistent user experience, architecture and platform. We built a common

http://blogs.msdn.com/blogfiles/sharepoint/WindowsLiveWriter/SharePoint2010_13F16/image11.png


platform for metadata, security, workflow, etc. SharePoint 2010 adds scale and depth in these areas

as well advancing the user experience. The top five investment areas:

1. Large Lists and Libraries – We made architecture and user experience investments so you have

much larger document libraries with metadata driven navigation to help users go quickly to the

content that is most important to them. Libraries will scale to tens of millions and archives to

hundreds of millions of documents. This is a key investment for high-end document and records

management but also helps organizations with lots of smaller sites. We enhanced the workflow

capabilities and tools in SharePoint Designer.

2. Enterprise Metadata – We are addressing your feedback to support content types and taxonomies

across not only across sites but also server farms. We have made applying this metadata easy (and

valuable to users) in both the SharePoint and Office client user experience. The top-down taxonomy

and bottoms-up social tagging (sometimes called folksonomy) combine to help improve search,

navigation and people connections.

3. Document Sets – We are introducing a way to manage a collection of documents as a single

object for workflow, metadata, etc. within SharePoint and Office so experience more closely models

your work product (e.g. a proposal that may contain a presentation, budget, contract, etc.).

4. Web Publishing including Digital Asset Management – We made a number of key

improvements to make it easier to publish rich sites on the intranet or internet. We used the new

browser ribbon and editor experience to speed site customization, content authoring and publishing

tasks. We added digital asset management features like thumbnails, metadata and ratings for images

as well as video streaming from SharePoint. Finally, we improved content deployment robustness from

authoring to production for larger scale sites.

5. Governance and Records Management – Compliance is an increasingly important requirement

for organizations. We enhanced the Records Managements features in 2010 building on the scalable

storage and enterprise metadata support described above. We improved the sophistication and

flexibility of our governance tools. Just a few new features include location-based file plans, multi-

stage dispositions, in-place records and e-discovery.


Search As discussed in my first post, enterprise search is a big investment area for Microsoft from Search

Server Express to SharePoint’s standard search to the new FAST Search for SharePoint. We added

depth at all levels in 2010. While many customers will be fine with the base SharePoint search

capabilities, FAST Search for SharePoint will meet the most sophisticated needs. FAST Search for

SharePoint supersets the base SharePoint user experience, APIs and connectors. This is the first step,

but a big one, and we will add more consistency and enhancements across our tiers of search in the

future. We will continue to sell and enhance FAST ESP standalone as well. The top five investment

areas here:

1. Interactive Search Experience – We built a richer search experience providing flexible

navigation, refinement and related searches. Both Standard and FAST Search for SharePoint get query

completion, spell checking, wild cards and more. FAST enhances this experience enabling feature

content for common queries and providing more flexible navigation and document thumbnails and

previews including in slide navigation of PowerPoint presentations which is a common end user

scenario.

2. Relevance – We improved the out-of-box ranking and expanded the relevance factors including

social data such as tagging and usage (clicks). FAST Search adds more configurable set of relevance

inputs for custom applications and specialized corpuses.



3. People Search – We greatly improved people finding based on social networking and expertise

algorithms and tailored user experience for people including getting views of authored content. As

users frequently do not know or recall the spelling of people’s names, we built a new phonetic search

algorithm that works much better than previous approaches to spell checking for names. In testing,

we had a lot of fun coming up with crazy ways to misspell each others' names to see if we could

stump it.

4. Connectivity – We know lots of data lives outside SharePoint so expanded and improved our

connectors to index web sites, file servers, SharePoint, Exchange, Lotus Notes, Documentum and

FileNet. The updated Business Connectivity Services (previously the BDC) described below makes it

much easier to index an arbitrary source such as a custom database. You can create this search

connection without code using the new SharePoint Designer.

5. Scale and Platform Flexibility – We made significant performance and scalability improvements

through our search technology. Optimizing for 64-bit helped but we also introduce partitioned indices

and scale-out query servers in SharePoint search this release. FAST scales-out even further and has

significantly more pipeline extensibility to handle the largest collections and most complex value-

added processing and search applications. We think both end users and IT will be immediately excited

about the new capabilities supporting hundreds of millions of documents with great index freshness

and query latency.



Insights Historically, business intelligence has been a specialized toolset used by a small set of users with little

ad-hoc interactivity. Our approach is to unlock data and enable collaboration on the analysis to help

everyone in the organization get richer insights. Excel Services is one of the popular features of

SharePoint 2007 as people like the ease of creating models in Excel and publishing them to server for

broad access while maintaining central control and one version of the truth. We are expanding on this

SharePoint 2010 with new visualization, navigation and BI features. The top five investment areas:

1. Excel Services – Excel rendering and interactivity in SharePoint gets better with richer pivoting,

slicing and visualizations like heatmaps and sparklines. New REST support makes it easier to add

server-based calculations and charts to web pages and mash-ups.

2. Performance Point Services – We enhanced scorecards, dashboard, key performance indicator

and navigation features such as decomposition trees in SharePoint Server 2010 for the most

sophisticated BI portals.

3. SQL Server – The SharePoint and SQL Server teams have worked together so SQL Server

capabilities like Analysis Services and Reporting Services are easier to access from within SharePoint

and Excel. We are exposing these interfaces and working with other BI vendors so they can plug in

their solutions as well.

4. “Gemini” – “Gemini” is the name for a powerful new in memory database technology that lets

Excel and Excel Services users navigate massive amounts of information without having to create or

edit an OLAP cube. Imagine an Excel spreadsheet rendered (in the client or browser) with 100 million

rows and you get the idea. Today at the SharePoint Conference, we announced the official name for

“Gemini” is SQL Server PowerPivot for Excel and SharePoint.

5. Visio Services – As with Excel, users love the flexibility of creating rich diagrams in Visio. In 2010,

we have added web rendering with interactivity and data binding including mashups from SharePoint

with support for rendering Visio diagrams in a browser. We also added SharePoint workflow design

support in Visio.


Composites The single biggest area we increased our investment from SharePoint 2007 was making it easier for

everyone – users, IT, partners, etc. – to build custom solutions on SharePoint that automate

processes and connect disparate information. Some of the scenarios are more IT driven. Analysts

often call them “Composite Applications”. Others are more end user centric or “Mash-Ups”. We

thought “Composites” was a good short word to describe the breadth of solutions built with

SharePoint. The top five investment areas:

1. SharePoint Designer – We revamped the SharePoint Designer experience to focus on the building

blocks of a SharePoint solution vs. HTML source code. The user experience gets easier including the

Office Ribbon and new tools for building workflows and connecting to external data. We have made

SharePoint Designer customizations safe out-of-box in 2010 so IT can let users customize sites

without risk. SharePoint Designer is also a great tool for mashing-up SharePoint (which now exposes

REST) and external data.

2. InfoPath Forms Service – InfoPath is the best way to have a common form definition render in

the browser as well as in a rich and offline client. For 2010, we improved the design environment to

make it easier to build rich forms declaratively with little to no code and more client-side validation.

We have also made it straightforward to use InfoPath forms as native SharePoint forms both on the

web and when offline from within the SharePoint Workspace client.



3. Access Services - Users have long loved the ability to create database applications quickly with

forms and views. Access Services lets you publish new Access solutions to a SharePoint site where

they can be managed centrally and accessed (necessary pun) from a web browser.

4. Sandbox Solutions – In SharePoint 2007, custom code requires the farm administrator to trust

the code running on the server. In SharePoint 2010 we are introducing a new SharePoint custom code

sandbox with isolation and resource limitations (memory, SQL, CPU) that allows administrators to let

others safely add and consume custom solutions without impacting overall farm performance and

stability. While it does not cover the full SharePoint object model it addresses key scenarios like

custom web parts and event receivers. We will use this and the client side object model described

later to support custom SharePoint solutions in SharePoint Online as well.

5. Business Connectivity Services – We expanded the read-only Business Data Catalog from

SharePoint 2007 to support create, read, update, delete, search and offline access to line-of-business

(LOB) data. This data, such as a customer record from a database, web services, etc. is called an

External List in SharePoint 2010 and it is mapped to an External Content Type so this data looks and

behaves like native SharePoint lists. You can not only update this data from within SharePoint but can

take it offline from SharePoint Workspace and, where it makes sense like contacts, in Outlook with

offline editing. There is great support for BCS in SharePoint Designer and Visual Studio 2010. This

perhaps our biggest “Wow, how did you do that?” demo. We will be building on the BCS for future LOB

connectivity solutions.



Administration We understand the most critical capability for you to introduce these features to your users is making

it easier to manage. We have gotten a lot of great feedback in this area and made big investments for

SharePoint 2010. As I have mentioned in previous posts, our experience with our CAT team, running

SharePoint Online with SharePoint 2007 and targets for higher scale informed the design of SharePoint

2010. You have the choice of Server, Online or a mix. Even if you run SharePoint yourself, you benefit

from our design and experience with Online. Beyond the fundamentals of scalability and reliability

which got a lot of focus, the top five investment areas:

1. Improved Upgrade – We changed the model for SharePoint 2010 vs. the previous release. We will

get your existing sites up and running with the existing SharePoint 2007 user interface including your

customizations. You can preview and switch to the new UI at your convenience. With SP2 of

SharePoint 2007, we released an upgrade checker tool that reports any potential issues. There are two

key things to think about in planning the migration. First, as we announced a while ago, SharePoint

2010 is 64-bit only. Second, thin about places where you may have invested in custom code than can

be replaced with out-of-box features such as the new enterprise metadata features described above.

2. Throttling, Health Monitoring, Analytics – Performance and reliability was a big focus for this

release to address the scale of the largest organizations, web sites and the SharePoint Online service.

We invested in optimizing the SharePoint, Windows Server and SQL Server architecture for scale and

availability. We introduced more resource governors throughout SharePoint to prevent bulk operations

or asynchronous jobs from slowing down the server. We built in proactive and extensible health

reporting, monitoring and resolution in SharePoint 2010 based on analyzing a wide range of

deployments. We will enhance this based on your feedback and our experience during the Beta and

beyond. We are introducing a new usage analytics logging and reporting and are publishing the SQL

schema for this analytics database so you can create your own reports.

3. Web and PowerShell Admin – We improved the web based administration interface for

SharePoint 2010 and put it through the level of usability testing we had previously focused on for end

user features. However, the biggest thing we heard from you was an improved scripting interface for

SharePoint for simplified administration of farms. With the release of PowerShell, we were able to

switch over all our administration to that framework and will ship with hundreds of commandlets you

can use, edit and enhance. The administration framework is built on a new multi-tenant model we are

be using on SharePoint Online but know is also of interest to 3rd-party hosters and large organizations

looking to do server consolidation.

4. Scalability and Availability – We made the shared services and federation model much more

flexible to support richer scale out as you add services, sites and applications to SharePoint. We

reduced the downtime for SharePoint 2010 with improved patching and SQL Server configuration,

backup-restore, log shipping support and more.

5. Identity Management and Security – We have introduced more flexibility identity lifecycle

management including updates between SharePoint with identity sources like Active Directory, LDAP

servers and HR applications.


Development I covered the higher-level solutions features under “Composites” above. Many of these enable building

solutions with much less code than possible before. We also invested in a number of lower level

development features as well for hard core developers. The top give investment areas:

1. New SharePoint APIs – This bullet is a blog post itself! The new UI framework has more

extensibility in the ribbon and natively uses XSLT DataViews in lists vs. previous CAML views. There

are new APIs for AJAX and Silverlight applications that make it make it much easier to access

SharePoint data with less code and better performance. We significantly improved list access and

programmability with REST, ATOM, JSON and LINQ including richer data relationship, validation, joins

and projections over SharePoint lists which as described above can now reach far higher scale points.

2. Application Lifecycle – We have converged and improved on WSP as the packaging and

deployment format for SharePoint solutions. You can save as WSP in SPD and bring that into Visual

Studio 2010.

3. Visual Studio 2010 Support – SharePoint 2010 is a first class target for Visual Studio 2010. This

includes F5 deployment and debugging (applause welcome …) as well as designers for various

SharePoint project types, web parts, workflow, business connectivity services and integration with the

VS Server Explorer. The early feedback on this has been so great, we decided to highlight it in Steve

Ballmer's keynote at the SharePoint Conference.



4. Developer Dashboard View – If you have the rights, you can turn on a mode for a SharePoint

page which will render at the bottom to show full trace and latency through the SharePoint, .NET and

SQL layers. You can use our reporting tools described earlier to identify any slow pages in your site

and then turn on this view to see a custom web part has bogged down the page by making repeated

expensive SharePoint object model calls.

5. Development on Windows 7 – We now support development on Windows 7 and Vista client

machines. Although it isn’t a supported configuration for production, we heard you that you want to

use it as a development environment.



Feature Name / Area SharePoint Server 2007 SharePoint Server

2010

Sites

Office Integration Included Improved

Line-of-Business Integration Included Improved

Read/Write capabilities New

Enterprise Management Operations Included Improved

Management tools and reporting Included Improved

Web Analytics New

Mobile Connectivity Included Improved

Full-fidelity viewing New

Editing to mobile New

Office Interaction Included Improved

Read/Write capabilities Included Improved

Robust User Experience Included Improved

Contextual Ribbon New

Microsoft Silverlight New

Office Web Applications New

Tagging New

Audience Targeting New

Communities

People profiles Included Improved

Photos and presence New

Microblogging New

Ask Me About New

Note Board New


Recent activities New

Organization Browser New

Add colleagues Included Improved

Social bookmarks New

Tags New

Tag clouds New

Tag profiles New

Blogs Included Improved

Wikis Included Improved

Enterprise wikis New

Ratings New

Colleague suggestions Included Improved

Keyword suggestions New

Content

Compliance Everywhere New

Flexible Records Management New

Shared Content Types and Managed

Metadata Service New

Content Organizer New

Rich Media Management New

Document Sets New

Word Automation Services New

Support for Accessibility Standards New

Search

People and expertise search Included Improved


Search from Windows 7 and

Windows Mobile Included Improved

Common connector framework for indexing and federation Included Improved

Scale and performance via improved

topology architecture Included Improved

Ability to build search-powered

applications Included Improved

Refinement panel and sorting New

Search in context New

Social behavior improves relevance New

Thumbnails, previews, and view in browser New

Advanced content processing with

strong linguistics New

Insights

KPI details New

Dashboard Designer Included Improved

Enhanced navigation, including filtering and sorting (top/bottom 10,

switchable measures) New

Publish more workbooks New

JavaScript Object Model New

PowerShell scripting New

Richer fidelity with Excel

workbooks New

Support for Analytical Services

formatting New

Additional data sources, including

external lists and "PowerPivot" workbooks (naming to come) New

Improved strategy map connection

and formatting New

Seamless management of dashboard

content Included Improved


Integrated filter framework New

Calculated KPIs New

Improved visualizations New

Chart Web Parts New

Business Intelligence Center New

Composites

Browser-based customizations Included Improved

Business Connectivity Services New

SharePoint Designer Included Improved

Human workflows Included Improved

Forms Services Included Improved

Visio Services New

Access Services New

Sandboxed Solutions New

SharePoint 2010 Service Applications Architecture (SSA)

If you have any experience in administering MOSS farms, you probably already know how

isolated Shared Service Providers (SSPs) can be and how extremely difficult is to restore an SSP

in case of disaster recovery. The good news is that for SharePoint 2010 SSPs are gone and we

now we have more flexible services that can be shared even between farms – SharePoint Service

Applications (SSA).

Before we take an indepth look at SSA, we will need to take a look at the terminology Microsoft

uses when describing the new Service Applications architecture.

Core functionality Name Description

Service A set of binaries installed on the server farm which


are capable of some functionality.

Service Application The Service described above but configured for a

specific SharePoint farm.

Service Application Proxy The Proxy service is really a pointer to a Service

Application within the farm that exists on the Web

front-end.

Service Instance The instance of the Service Application running on

the application Server.

Service Consumer A feature such as a Web Part which is using the

Service Application to communicate with end-user

and present the service results to the browser.

Table representing new core-service definitions

SharePoint 2010 Architecture vs SharePoint 2007 Architecture

In the example architecture below you can see that we have two SSP’s in the farm, each has its

own set of Services and applications. In this SharePoint 2007 environment you can’t share

services between SSP’s and especially between farms. You have to setup new services for every

SSP you create.

Office SharePoint Server 2007 Service Architecture

In the SharePoint 2010 architecture below, you can see we do not have the SSP. It is simply not

needed since we are now using Application Service instances for every web application we

choose and the services can be shared between different web applications. In our example we are

using the same User Profiles service for all web applications, and dedicated services for every

application such as Search Service, BCS (BDC) Service, Access and Visio Services, etc. You


may even share the Service Applications between SharePoint farms under Service Application

Publishing.

SharePoint Server 2010 Service Architecture

Because of these architecture changes, it is now more complex to plan and design the SharePoint

environments based on farms and services. In SharePoint 2007 we simply had to create an SSP

and applications under it, with all the required services attached to the isolated SSP environment.

Whilst SharePoint SSA is a major advance, not all services can be published (which means not

all can be shared between SharePoint farms):

Services that can be published Services that cannot be published

Users and Profiles (People related applications) Usage and Health Services

Metadata Services Site Services

Business Connectivity Services (BCS) Project Services

Search Services Excel Calculation Services

Secure Store Services Access Web Services

Web Analytics Services Visio Web Services

Word Web Services

Performance Point Services

Service Application Publishing possibilities for SharePoint 2010

In general, services that are based on Web applications (Word, Visio, Access, and Excel) cannot

be shared between farms but they still can be shared between the web applications so it is


probably not a major issue. Now, the overall concept of the new SharePoint Services architecture

is now clear, let’s go deeper and see how it works from administrative viewpoint.

To use a Shared Service, you must first provide a Service Application (which is really the service

instance) valid for the farm where it is deployed. Service application contains:

• Admin Interface (for service management within the farm)

• IIS Application Pool

• Associated databases (may use more than one database, but may not use any depending on the

service design)

• Server Instance (the process or web service that is running physically on the server)

Worked Example using SharePoint SSA

We want to create a new service application instance for our farm – Visio Graphics Service, so I

go ahead and choose this service from a list:

Service Applications screen in Central Administration

Next we have to provide the instance a name. Select the application pool (it is always good

practice to create new one) and we need to decide if we want a Proxy attached to the Service

instance. For this example, we want the default proxy added so we left this box checked (the

default behavior).


Visio graphics Service Application setup window

Service Applications list with our newly created instance.

Our newly created instance is now visible in the IIS Server. To identify our newly created (or

any other) service instance, open IIS Manager and navigate to the ―SharePoint Web Services‖

web application:


IIS 7.5 SharePoint Web Services list

Now a big minus – we only see a long GUID that isn’t readable. The simplest way to find our

newly created service is to explore each GUID until we found our service name inside.

Explorer window with the Visio Graphics Service files.

Please note that the Microsoft has redesigned the services to be an SVC extension (WCF Web

Services) instead of ASP .NET web services (ASMX extension).


SharePoint 2010 Search - What’s next for IT-Pros

SharePoint 2010 Enterprise Search includes many relevant improvements for IT professionals. The

biggest change is without doubt the new and more scalable deployment architecture. Beyond that,

SharePoint 2010 offers many other useful changes including an improved administration dashboard,

built-in administration reports for monitoring the performance of the search engine over time and

complete PowerShell support enabling scriptable administration. Last but not least, SharePoint 2010

also ships with an improved connector framework allowing IT-Pros to easily configure indexing of

remote repositories. The following sections will introduce you to more technical details on these

improvements for IT professionals.

New Scale-Out Architecture

The search engine in Microsoft Office SharePoint Server 2007 suffered from a number of scalability

problems that have all been addressed in SharePoint 2010 by the introduction of a new scale-out

architecture. The scalability issues found in MOSS 2007 and resolved in SP2010 include the following:

High query latency and slow crawls when the search index grows to millions of items. The

official limit of 50 million items per index does not perform well in practice.

Non-redundant index server role making it a single-point-of-failure and a performance

bottleneck with respect to crawl speed.

Non-redundant property database making it a single-point-of-failure and a performance

bottleneck with respect to crawl speed as well as query latency.

The SharePoint 2010 search engine introduces a new and highly componentized deployment

architecture to resolve these scalability issues. The available components that IT-Pros must learn how to

deploy include; 1 Administration Component, 1 Administration Database, 1+ Query Component, 1+

Crawl Component, 1+ Property Database and 1+ Crawl Database. This componentization of the search

engine offers the following features and benefits:

Index Partitioning enabling a search index to be partitioned across multiple query servers,

which will in turn work in parallel on each query. This enables deployment architectures with

sub-second query latency up to about 100 million indexed items.

Index Mirroring enabling query failover by cross mirroring the search index on the query servers

(passive mirroring) or mirroring it to a parallel set of query servers (active mirroring).

Multiple Stateless Crawlers offering improved crawl performance and high availability of crawls.

Stateless refers to the fact the crawlers are redundant and they do not keep a copy of the index

on the server as was the case with the index server in MOSS 2007. Consequently, crawlers have

a low disk space requirement.

Multiple Crawl Databases for improved crawl performance. Supports native SQL mirroring for

failover.

Multiple Property Databases for improved query performance. Supports native SQL mirroring

for failover.


Figure 1 shows a sample deployment with a partitioned and mirrored search index, multiple property

databases, multiple crawlers and multiple crawl databases.


Figure 1: Sample SharePoint 2010 Search deployment.

Improved Administration experience

The consolidated administration dashboard introduced with the MOSS 2007 infrastructure update has

been carried along and improved in SharePoint 2010. Hence, the search administration experience will

be very familiar to search administrators familiar with the MOSS 2007 administration experience. The

dashboard provides IT administrators with a quick overview of the state of the search engine and easy

access to its configuration. Significant improvements include:

Topology editor for adding, updating and removing search components in a deployment.

Support for managing custom content sources directly in the Web UI (Required custom code in

MOSS 2007).

Support for regular expressions in Crawl Rules.

Ability to prioritize Content Sources.

Improved Web analytics reports for monitoring search usage.

New administration reports to monitor the performance of query components and crawl

components in a deployment.


Web part based dashboard page allowing for easy customization with custom Web parts.

Advanced monitoring though Microsoft System Center Operations Manager (SCOM).

The screen shot seen in Figure 2 illustrates the look and feel of the dashboard and Figure 3 shows a

sample report on the crawl rate over time.

Figure 2: Consolidated Administration Dashboard


Figure 3: Report on crawl-rate over time

PowerShell Support

Say goodbye to STSADM and hello to Microsoft PowerShell - virtually every administrative operation in

SharePoint 2010 is now scriptable through a rich palette of PowerShell Cmdlets1[1]. Enterprise Search is

no exception here – it ships with 100+ PowerShell Cmdlets enabling scripted administration of search

artifacts like:

Search Service Application

Crawl, Query and Database components

Content sources

Crawl rules


Crawled metadata properties

Managed metadata properties

Search scopes

Ranking model

And much more…

Executing PowerShell commands is easy; simply login to the server and launch the SharePoint 2010

Management Shell from the Windows start menu and type the PowerShell command or script to

execute. Figure 4 below shows how to add a new Content Source for crawling a file share using the

Cmdlet named New-SPEnterpriseSearchCrawlContentSource.

Figure 4: Sample command executed from the SharePoint 2010 Management Shell

To list all SharePoint 2010 Cmdlets, type:

Get-Command –pssnapin “Microsoft.SharePoint.PowerShell” | format-table name

To view the usage of a Cmdlet, type:

Help <Name of Cmdlet>

To view the detailed usage of a Cmdlet, type:

Help <Name of Cmdlet> -full

Improved Connector Framework

The SharePoint 2010 Enterprise Search Engine also ships with a new connector framework leveraging

the new Business Connectivity Services (BCS)2[2] to index external content. The framework does along


with improved tool support in SharePoint Designer 2010, enable administrators to configure the

indexing of external content through the following generic connectors:

Database connector

Windows Communication Foundation (WCF) / Web Services connector

.NET connector with callouts to custom code

Developers can additionally develop custom connectors in managed code (.NET) to efficiently index any

custom repository not supported by the BCS. The connector framework supports indexing of structured

content (rows and columns) and unstructured content (documents) along with security descriptors

(ACLs) on each item. The latter enables automatic security trimming of search results at query time. This

is a big improvement over the Business Data Catalog in MOSS 2007, which can only index structured

data without associated security descriptors.

These improvements over the BDC eliminate the need to develop complex Protocol Handlers to index

documents and security information from custom repositories. However, the Protocol Handler

connectivity framework is still present and used by SharePoint 2010 to index SharePoint content, File

shares, Web sites and People profiles. But the new connector framework is leveraged when indexing

content from Lotus NotesTM, Exchange Public Folders and DocumentumTM.

Figure 5 outlines the overall architecture of the new connector framework.

Figure 5: Connector Framework Architecture


Create a Records Center

Simply create a Records Center by selecting the correct site template:

When creating a Records Center in SharePoint 2010, the following features are enabled:

Content Organizer

E-mail Integration with Content Organizer

Hold and eDiscovery

Metadata Navigation and Filtering

Offline Synchronization for External Lists

SharePoint Server Enterprise Site features

SharePoint Server Standard Site features

Team Collaboration Lists

The new look of the SharePoint 2010 Records Center:

http://blogs.msdn.com/blogfiles/mcsnoiwb/WindowsLiveWriter/SharePoint2010RecordsManagement_9F45/image_8.png


The “Submit a Record” button let users upload (and add metadata to) documents. The documents will be added to

the “Drop Off Library” and then moved to the correct library/folder according to the rules added by the records

manager.

Note: Activate the “In Place Records Management” feature on the Site Collection level to fully take advantage of the

Records Center. The feature has to be activated to mark incoming documents as records:

Create / enable Content Types The Content Organizer uses Content Types (and related metadata) as criteria for where to move incoming documents.

Content Types must therefore be created (or enabled) before routing functionality are enabled.

Create libraries for storing Records I created a document library; “Contracts 2009” and added a rule “Contract” to the Content Organizer. When

documents are submitted, the Content Organizer will move any documents related to the Content Type “Document”

into the “Contracts 2009” library. You can create as many libraries/folders and content organizer rules you need to

best control your records.

In my “Contracts 2009” document library, I went to Library Settings and enabled “Automatically Declaration”. Now, all

documents added to the library are automatically flagged as records.:






Create Content Organizer rules I added rules by selecting: Site Settings / Site Settings / Site Administration / Content Organizer Rules:

What happens if my target library doesn’t have the necessary Content Type enabled? I tried to create a rule which is

using the Content Type “Dublin Core” as a criteria. I wanted all documents related to “Dublin Core” to be moved to






the “Contracts 2009” library. As you can see from the message below, all target libraries also need necessary Content

Types enabled for the Content Organizer to be able to move documents into the library.

Retention Schedule Retention Schedule is, per default, enforced on the Content Types, but it is possible to define retention schedules on

library/folder level too.

Retention schedule using Content Types

I went to Site Action / Site Settings / Galleries / Site content types (on Site Collection level), then I clicked on the

content type “Document”.



Then i clicked on “Information management policy settings”, checked the “Enable Retention” and was given the

choice of running different retention schedules on Non-Records and Records:

I chose to use a different retention schedule, and clicked “Add a retention stage for records…”. I was given the choice

of setting different actions when the event fires.






It’s possible to add multiple actions, and each stage will occur one after the other in the order they appear on the

page:

Retention schedule using Library/folder

Retention schedules are possible to configure directly on a document library. I went to my “Contracts 2009” library

and selected “Document Library Settings. Under “Permission and Management” I clicked “Information management

policy settings”. Here, I changed the source of retention by clicking on the “Change source”.

When choosing a different source a message will pop up, that basically says that you’re overriding the retention

schedule at the Content Type level:






Then a form was presented, where I added my retention events and actions.

In-Place Records Management A new capability in SharePoint 2010 is In-Place Records management. Instead of moving a document to a specific

Records Center, you declare the document as a record and it will be handled as a record in the site it was created in.

After the the document is declared as a record, it can have policies and restrictions different than when it was a

document. The policies are added to either the Content Types or directly on the document libraries (see the Retention

Schedule paragraph above).

Documents can be declared as records either manually or automatically.

Manual record declaration can be configures on Site Collection level and overridden in each document library. In Site

Collection settings you have the following options on how declarations of records should be done:



When Record Declaration Availability is set to “Available in all location by default”, a new icon appears on the Ribbon:

A document will get a padlock added to its icon when declared as a record:






Again, you can override the record declaration availability on the document library level:

Automatically declarations of records is possible by checking the “Automatic Declaration” option in the document

library settings.






Creating a Survey in SPS 2010 The new interface to add lists to content is so cool, completely based on Silverlight

I added a new Survey List to my Site and i can observe the new branching feature for customize

the flow of the questions in the survey, First you should create the survey’s questions using the

http://geekswithblogs.net/images/geekswithblogs_net/gotchas/WindowsLiveWriter/Sharepoint2010NewBranchingfeatureinSurve_11C8F/image_2.png


add Questions option in the Settings menu

Once we have completed the questions,

we have add Branching Logic using the Setting menu and editing the questions.

In my case i have 4 questions about programming languages, the second question have the

branching logic to continue with the survey flow.



As we can see this is a really simple and useful feature to manage the content of the surveys in

Sharepoint Foundation.



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

http://www.sharepointkings.com/2009/01/content-type-in-moss.html


I. Creating External Content type

1. For the first step you have to create an external content type using Sharepoint

designer 2010

2. Open your site in SPD 2010

3. Click on External Content Type.


4. Click on New External Content Type

5. You will get a screen as shown below Click on Add Connection


6. I have selected SQL Server as the option. You have other options also here

7. Next you have to give Data connection with my Database server name and database

name. You can also configure out which identity is used here to talk to the database.

Please make sure that you may need to grant permissions on the SQL Server itself

for the appropriate user.

8. After That it will add the tables in the connection as shown below.

9. Click on the table and select All operations


10. From the next screen you have to select the columns you want to display


11. If successfully added you will get a screen like below

12. Click on Create Profile Page


13. You are done with External Content Type creation

II. Creating External Data column for list

1. Go to Sharepoint list and create a column of type External Data.

2. As shown below select the External Content Type we just created


3. Click OK

4. Select the options as shown below


5. In the below Screen you can see the data populated from the BCS_Customer Table

III. Creating External List

1. You have to go back to your Designer and click on the Create list and Form

2. Give proper name for your list click OK


3. Once done you will get a an external list connected to our SQL table you can

add/update/delete data resides in SQL Table

Content Type Definition: A content type is a reusable collection of settings we want to apply

to a certain category of content. Content types enable us to manage the metadata and behaviors

of a document or item type in a centralized, reusable way.


Problem that can be solved with Content Type: Suppose we want to store two entirely

different kind of documents such as software specifications and legal contracts in the same

document library. The metadata we would want to gather and store about each of these

document types is also very different. In addition, we want to assign very different workflows to

the two types of documents.

Solution with the content Type: Content types enable us to store multiple different types of

content in the same document library or list. In the preceding problem statement, we could

define two content types, named Specification and Contract. Each content type would include

different columns for gathering and storing item metadata, as well as different workflows

assigned to them. Yet items of both content types could be stored in the same document library.

Content Type Settings:

We can further extend content type functionality by using them to assign additional settings,

such as workflows, or even custom attributes, to items.

A content type can include the following information:

· The metadata, or properties, you want to assign to this type. These are represented by columns

added to the list or document library when you add the content type. Only site columns can be

added to a content Type.

· Custom New, Edit, and Display forms to use with this content type.

· Workflows available for items of this content type. These can be defined to start automatically

based on a selected event or condition, or through user selection.

· For document content types, the document template on which to base documents of this type.

· Any information necessary for custom solutions associated with this content type. We can store

this information in the content type as one or more XML documents.

Content Type Creation:

We can create column and content types in three ways:

· Using the Windows SharePoint Services user interface

· Using the Windows SharePoint Services object model

· Deploying a Feature that installs the content type based on an XML definition file.

Here we need to be careful while selecting the above described methods to deploy the Content

Type. Basically when a new content type is created and added to the root site’s gallery, it is made

available to be added to any list. Then when that content type is added to the list, the content

type is copied to the list and given a new id and a reference to the root site’s content type.

When changes are made to a content type through the SharePoint user interface by adding a

column, the user has the option to “Update all content types inheriting from this type”. Selecting

yes causes the page to call the SPContentType.Update method to push the changes to every

instance of the content type within the site collection.

However, when changes are made to the content type using SharePoint feature infrastructure,

the changes are only made to the content type definition, not to all the “children” of that content

type.


Workflows

Demo – Default Workflows: Three State Workflow

The three state workflow that ships with WSS is useful for tracking the status of an item

throughout some portion or the entire lifecycle of the item. The workflow is so named

because one of the requirements of the workflow is that any list or content type that it is

associated with must have a choice column with at least three different choices. The

value of the choice column will be set programmatically by the workflow in order to show

the status or state of the item that the workflow is running against. If the list or content

type doesn’t have a choice field with three choices you will not be able to complete the

association for that content type or list.

The three state workflow requires two lists to support it. A Task list is used to handle

individual actions that will be taken by the users who interact with the workflow. The

history list keeps track of events within the workflow itself.

Because of all of the options available to it the Three State Workflow can be very

complicated to configure.

Demo Steps:

Here I am showing you how to use sharepoint default work flow named three state work

flows.

A three-state workflow can be used to track documents in a SharePoint document library by using 3 different states.

I have document library with the following fields as shown in the image below


1. Important field need for a three state work flow is State field containing any three

states.Here I have three states named

a. New

b. On Review

c. Completed

2. Go to Document library settings-->then work flow settings


3. From the new screen select Three-State Work flow

4. Select start this work flow when a new Item is created.

5. Click Next


6. By Default it will take the Choice column you created

7. You can write custom email messages as shown below


8. Then click OK

9. Your three state work flow is now associated with the document library. It will send

email as per your configuration.

10. It will automatically create a task list and saves the activities for our reference


Demo SPD Workflow

1. Create your new approvers group and populate it with the desired users.

Click “Create Group” in the ribbon

Fill out the form

Click the “Create” button

Add the desired users to your new group

http://mossseo.files.wordpress.com/2010/09/clip_image001.png

http://mossseo.files.wordpress.com/2010/09/clip_image003.jpg

























2. Open the site/sub-site using SharePoint Designer 2010

3. Once the site is opened in SharePoint Designer 2010, you can create a new workflow

by selecting File/Add Item/Reusable Workflow.

Choose reusable workflow if you wish to use this same process in other areas.

4. Provide a meaningful name to your new workflow, and select the appropriate content

type. For this example, we will name it “Josh and Jim Approval” and use the

“Document” content type.

Provide meaningful workflow name and specify the appropriate content type, click the


















“Create” button.

5. You may receive the following pop up dialogue in SharePoint Designer 2010, just let it

do its thing.

6. Now we get to define the steps to our new workflow (the fun part). You will see the

following in SharePoint Designer 2010:

Note: One pretty cool feature is the ability to insert an “Impersonation Step.” The

contents of an impersonation step will run as the auther, not as the user who started the

workflow.

7. For this example, let’s say we want Josh and Jim to be notified when large files are

uploaded to the site. We will start by defining the condition which triggers the workflow,

and then we will specify the corresponding action.











Since we want to fire off this workflow when a large file is uploaded, we will select

“The file size in a specific range kilobytes” condition from the dropdown.

8. This site is configured to reject files larger than 2GB, so we will specify a file size

range between 1-2GB, which will catch all files 1GB and larger in size.

9. Now we specify the action. For this, we need to insert a new step.











10. Select “Send an email” for this action.

Note: the example is a very simple conditionally driven workflow, however for a more

sophisticated workflow, use SharePoint Designer 2010 to build in nested steps:

11. Your screen should look like this:

Click “these users”











12. See this screen:

Click the Lookup book icon to the right of the “To” field so we can locate the approvers

group we created earlier.

13. Now select the “People/Groups from SharePoint site…” and click “Add>>”

14. The below dialog pops up, if you know all or part of the group you want to use, type it

in the search box and click the search button, select the correct group in the results (in

the example, it’s “Approvers – HR Docs”), but it could be any group you wish. Click the






“OK” button.

15. Click the “OK” button for all dialogs until you are back to the orginial one. Specify the

Subject, and Body of the email.

16. Click the “Publish” button in the ribbon and you are done!

Now you have a workflow which was created using SharePoint Designer 2010 and is also

reusable











Demo – Default Workflows：Approval

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.


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.


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.


As the workflow name indicates the task is complete when the document is approved or

rejected.


Upgrade


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.

Workflows ........................................................................................................................................................... 54

Demo – Default Workflows: Three State Workflow ............................................................................................ 54

Demo SPD Workflow ........................................................................................................................................... 60

Demo – Default Workflows：Approval .............................................................................................................. 67

SECTION 1: OVERVIEW OF SHAREPOINT 2010 UPGRADE ..................................................................................................... 76

Changes and Improvements to the Upgrade Process in SharePoint 2010 .......................................................... 77

Pre-Upgrade Check ............................................................................................................................................. 79

Pre-Upgrade Check Output ................................................................................................................................. 82

PowerShell Upgrade Commands ......................................................................................................................... 83

Improved Upgrade Logging ................................................................................................................................ 85

Section 1 Review ................................................................................................................................................. 86

SECTION 2: UPGRADE METHODOLOGY ............................................................................................................................. 87

Learn ................................................................................................................................................................... 88

Pre-Upgrade Steps .............................................................................................................................................. 90

In-Place Upgrade ................................................................................................................................................. 95

Database Attach Upgrade .................................................................................................................................. 97

Hybrid Upgrade ................................................................................................................................................... 99

Test the Upgrade............................................................................................................................................... 100

Section 2 Review ............................................................................................................................................... 103

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

Section 3 Review ............................................................................................................................................... 116

SECTION 4: UPGRADE CONSIDERATIONS ......................................................................................................................... 117

Upgrading SSPs to Service Applications with PowerShell ................................................................................. 118

Methods to Mitigate Upgrade Downtime ......................................................................................................... 119


Visual Upgrade .................................................................................................................................................. 122

Section 4 Review ............................................................................................................................................... 127

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

Section 1 Review ............................................................................................................................................... 145

SECTION 2: TIMER JOBS............................................................................................................................................... 146

Changed Timer Job Features ............................................................................................................................. 147

Improved Timer Job Features ............................................................................................................................ 151

Preferred Timer Server ...................................................................................................................................... 154

Lab 2B: Managing Timer Jobs ................................................................................ Error! Bookmark not defined.

Section 2 Review ............................................................................................................................................... 157

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

Section 3 Review ............................................................................................................................................... 187

MODULE 2 SUMMARY ................................................................................................................................................ 188

MODULE 7: PATCH MANAGEMENT ............................................................................................................. 191

SECTION 1: PATCHING OVERVIEW ................................................................................................................................. 192

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

Upgrade Approach: In-Place ............................................................................................................................. 201


Upgrade Approach: DBAttach ........................................................................................................................... 202

Section 1 Review ............................................................................................................................................... 204

SECTION 2: IMPROVEMENTS IN PATCHING FROM PREVIOUS VERSION .................................................................................. 205

Backwards Compatibility .................................................................................................................................. 206

Backwards Compatibility (Continued) ............................................................................................................... 208

Performance Improvements ............................................................................................................................. 209

PSConfig Improvements .................................................................................................................................... 211

Monitoring the Status of Updates..................................................................................................................... 213

Section 2 Review ............................................................................................................................................... 215

SECTION 3: PATCHING PROCESS .................................................................................................................................... 216

Patching Strategy .............................................................................................................................................. 217

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

Verifying Patch Installation Success .................................................................................................................. 226

Common Patch Installation Issues .................................................................................................................... 228

Section 3 Review ............................................................................................................................................... 230

Module Summary ............................................................................................................................................. 231


Introduction

This module introduces the methods for upgrading to MSF2010 as well as the strategies for upgrading.

It describes how to test the upgrade process and then how to actually perform the upgrade.

Objectives

After completing this module, you will be able to:

Describe the new and improved upgrade features available in SharePoint 2010.

Analyze a SharePoint farm for possible upgrade problems by using preupgradecheck.

Differentiate between the various types of options available for upgrading to SharePoint

2010.

Perform and validate an in-place or database attach upgrade to SharePoint 2010.

Upgrade SSPs to Service Applications via PowerShell.

Describe the methods available to reduce downtime during an upgrade to SharePoint 2010.

Perform the visual upgrade of a SharePoint 2010 site after the upgrade.


Section 1: Overview of SharePoint 2010 Upgrade

3

Section 1: Overview and What’s New

What‘s New, What‘s Changed, What‘s Gone, What‘s Not

Supported

Pre-upgrade Checker

PowerShell Upgrade Commands

Introduction

This section provides an overview of the upgrade process in SharePoint 2010 and introduces some of

the changes made to the upgrade feature since MOSS.

Objectives

After completing this section, you will be able to:

Identify the new and improved upgrade features available in SharePoint 2010.

Determine the possible upgrade problems a SharePoint farm by using preupgradecheck.

Identify the PowerShell commands available to perform upgrades.

Identify the improvements made to upgrade logging in SharePoint 2010.


Changes and Improvements to the Upgrade Process in SharePoint 2010

4

What’s New, What’s Changed, What’s Gone, What’s Not Supported

What‘s New

• Upgrade preparation tools

• PowerShell upgrade cmdlets

• Visual Upgrade

• Parallel Upgrade Pipelines

What‘s Changed

• Additional Upgrade methods

• Improved Upgrade status

logging and reporting

• Improved Read-only

database support

What‘s Gone

• Gradual upgrade

• Side-by-side installation

What‘s Not Supported

• Upgrade from a farm running

earlier than WSS v3 SP2

• Direct upgrade from WSS

v2/SPS 2003

SharePoint 2010 offers several new and changed items that can affect the upgrade process.

What’s new

The following items are new to this version of SharePoint:

Upgrade preparation tools. These include Preupgradecheck and TestSPContentDatabase.

PowerShell upgrade cmdlets. These cmdlets enable you to perform upgrades on content

databases and resume the upgrade process after a failed upgrade.

Visual upgrade. By default, when you upgrade from WSS 3.0 or MOSS to SharePoint 2010,

each site collection retains the same look and feel until you perform a visual upgrade .

Downtime reduction via parallel upgrade pipelines. This is done by upgrading multiple

content databases at the same time.

What’s changed

SharePoint 2010 also introduces changes to some existing upgrade features.

Additional upgrade methods through the use of hybrid approaches

Improved upgrade status logging and reporting

Improved read-only database support

What’s gone

The following upgrade features have been completely removed from SharePoint 2010:

Gradual upgrade


Side-by-side installation

What’s not supported

SharePoint 2010 does not support the following upgrade scenarios :

Upgrade from a farm running WSS 3.0 earlier than SP2

Direct upgrade from a farm running WSS 2.0 or SPS 2003. You must first upgrade from

WSS 2.0 or SPS 2003 to WSS 3.0 or MOSS 2007 before upgrading to WSS 4.0 or

SharePoint 2010

Upgrade from a prerelease SharePoint Foundation installation.


Pre-Upgrade Check

5

Pre-Upgrade Check

In WSS/MOSS SP2: stsadm –o preupgradecheck

The Stsadm command provides a rule-based scanning operation to determine whether servers in an

existing SharePoint environment meet the core requirements for upgrading from WSS 3.0 and related

products to future releases of SharePoint products and technologies.

The command to run a farm scan is:

stsadm –o preupgradecheck

The command to run a local server scan is:

stsadm -o preupgradecheck -localonly

The screen shot above shows example output from running the preupgradecheck command.

These commands help you scan farm servers before starting an upgrade to ensure that some

upgrade prerequisites are met and to detect known issues that can prevent the upgrade from

completing successfully. The results of the scan enable you to address any issues that are identified.

Pregupgradecheck does not:

Supersede the Microsoft Best Practices Analyzer for WSS 3.0 and Microsoft Office 2007

system.

Automatically fix upgrade issues that are identified.

Prerequisites and permissions

Each server that you want to scan must have Service Pack 2 (SP2) for WSS 3.0 installed in order to

initiate a scanning session and generate a report about the upgrade readiness of the server.


To be able to run a scan with the upgrade checker, you must be a member of the Farm Administrators

SharePoint Group and have administrator permissions on the server that you need to scan.

Rules

There are two types of rules used by the preupgradecheck —informational and error. Informational

rules provide upgrade related statistics that help plan upgrades. Error rules provides information

about items that the administrator will need to fix prior to starting the upgrade.

The following table shows a listing of the rules used by the preupgradecheck tool.

Name Description Local server or

farm Severity

ServerInfo Specifies all servers that are running

SharePoint bits in the farm

Local Information

FarmInfo Specifies the components of this farm Farm Information

UpgradeType Specifies the upgrade types supported by the

farm

Local Information

SiteTemplates Specifies that the farm uses the following site

definitions

Local Information

Features Specifies the features installed on the farm Local Information

LanguagePacks Specifies the language packs required for the

farm

Local Information

AAMURLs Specifies the AAM URLs within the current

environment that need to be considered

when upgrading

Local Information

OSType Specifies that this server machine in the farm

does not have the 64-bit edition of Windows

Server 2008 or later installed

Local Error

DatabaseSchema Specifies that the content databases are

modified by user, and cannot be upgraded

Farm Error

DataOrphan Specifies that content databases contain

orphans

Farm Error

SiteOrphan Specifies that some sites cannot be

referenced properly

Farm Error

UnfinishedGradualUpgra

de

Specifies that this farm is currently being

upgraded via the gradual upgrade process

Farm Error

MissingWebConfig Specifies that this Web site does not have a

web.config file

Local Error

InvalidHostNames Specifies that invalid host names are found Local Error

InvalidServiceAccount Specifies that the application pool account

must be fixed

Local Error

DatabaseReadOnly Specifies that the databases in this farm are

configured as read-only and the upgrade will

fail unless they are configured as read-write

Farm Error

WYukonLargeDatabase Specifies that the databases in this farm are

hosted on the Windows Internal Database;

Farm Error


Name Description Local server or

farm Severity

uses SQL Server technology as a relational

data store only for Windows roles and

features, such as Windows SharePoint

Services, Active Directory Rights

Management Services, UDDI Services,

Windows Server Update Services, and

Windows System Resources Manager; and

are larger than 4 GBs.

WYukonLargeSiteCollecti

on

Specifies that the site collections in this farm

are hosted on the Windows Internal

Database and are larger than 4 GBs

Farm Error

Note: The rule file is located in the %commonprogramfiles%/Microsoft Shared/web server extensions/12/config/preupgradecheck.


Pre-Upgrade Check Output

6

Pre-Upgrade Check output

As rules are processed during the pre-upgrade scanning, the results from each rule are written to an

XML log file and a text log file. These log files are written to the %COMMONPROGRAMFILES%\Microsoft

Shared\web server extensions\12\LOGS directory and use the following naming convention, where a

random number is used to differentiate between possible simultaneous attempts to run the pre-

upgrade command:

PreUpgradeCheck_YYYYMMDD-hhmmss-millisecond-random-number.XML

PreUpgradeCheck_YYYYMMDD-hhmmss-millisecond-random-number.LOG

Both log files contain the following information:

The checks that were run

The issues that were found

A description of how to fix the detected issue or a link to a Microsoft Knowledge Base

article that pertains to the issue

After the scan is finished, the XML results are transformed to an HTML format that can be viewed as a

page in the default Web browser. The file name of the transformed XML is

PreUpgradeCheck_YYYYMMDD-hhmmss-millisecond-random-number.HTM.

The screenshot on the slide above shows an example output from the preupgradecheck tool.



7


Mount-SPContentDatabase

Upgrade-SPContentDatabase

Mount-SPContentDatabase

This command helps attach a content database or multiple parallel databases to a SharePoint farm. To

attach multiple parallel databases, you just need to run multiple Mount-SPContentDatabase commands

in different command windows.

Essentially, this command works similar to STSADM –o addcontentdatabase. However, if you need to

perform a parallel content database attach, Microsoft recommends using the Mount-

SPContentDatabase command because it provides several more parameters when compared to the

STSADM equivalent.


This command is strictly used for resuming a failed in-place or database attach upgrade. In contrast, the

STSADM –o Upgrade command can resume binary and database upgrade, but more holistically. The

STSADM is the fail safe command because it will check both the binaries and all of the databases. If you

have problems with one particular database, the Upgrade-SPContentDatabase is obviously the best

choice to resume its upgrade. The command is not just used for failures, but also to restart the upgrade

of a database where issues have been addressed.

Alternatively, you can use the psconfig.exe –cmd upgrade –inplace v2v –passphrase < passphrase > –

force command. This command should be used for troubleshooting in-place upgrades with early binary

upgrade failures, and it even goes a level higher than stsadm.


Test-SPContentDatabase

This command is used to check the upgradability of a database in a farm. It is very similar to

preupgradecheck, except that is can used against 2007 and 2010 databases. You can even point it to a

database that is not attached to the farm.

Test-SPContentDatabase -Name -WebApplication [-AssignmentCollection ] [-DatabaseCredentials ] [-

ServerInstance ]

Test-SPContentDatabase –name SPContentDatabase –WebApplication http://test

http://test/


Improved Upgrade Logging

8

Improved Upgrade Logging

New Logging Features

• Unique log is created per upgrade

• Log files in the ULS logging directory

In SharePoint 2010, the logging during the upgrade process has been much enhanced since the last

version.

The following are the new upgrade logging features available in SharePoint 2010:

A unique log is created per upgrade. Each time an upgrade pipeline is called upon, it opens a

new log that includes the timestamp for when the upgrade session started.

The log files are located in the ULS directory. By default, this directory is in the C:/Program

Files/Common Files/Microsoft Shared/Web Server Extensions/14/Logs folder.

A separate log is created, just for errors, which contains the callstack information. Callstacks

assist in more detailed upgrade troubleshooting.

The primary SharePoint upgrade log records:

Information about the old and new build numbers.

Command and parameters that initiated the upgrade.

Information about whether the upgrade was based on a timer job.

There is also a secondary log, with a results section, which points back to the primary log. The secondary

log includes a cumulative list of errors, warnings, databases upgraded, issues detected or fixed, and even

the suggested action to be taken by the administrator in order to resolve the issues. This log also shows

details such as GUIDs, URLs, and item names involved in any of these errors. In addition, the log contains

victory conditions to indicate a successful upgrade.


Section 1 Review

What does the visual upgrade do? It displays each page by default in the WSS 3.0 format and gives you

preview of the 2010 format before selecting to make the MSF2010 version permanent.

What is the purpose of the preupgradecheck? The preupgradecheck is designed to give the

administrator and idea of the readiness of the web applications and site collections for upgrade.


Section 2: Upgrade Methodology

10

Section 2: Upgrade Methodology

Learn

Plan/Prepare

Test

Implement

Validate

Introduction

The SharePoint 2010 upgrade methodology involves the following five phases:

Learn

Prepare

Test

Implement

Validate

This section introduces the learn, prepare, and test phases. The actual upgrade implementation and

validation is covered in the next section.

Objectives


Identify the pre-upgrade steps and best practices.

Determine the pros and cons of each type of method available for upgrading to SharePoint

2010.

Test the upgrade before implementing it in a real production environment.


Learn

11

Learn

Determine the upgrade approach

Review upgrade best practices

Review Supported and unsupported methods

• Stand-alone to stand-alone

• Server farm to server farm

• Migrate to 64-bit hardware first

• WSSv2/SPS2003 to WSS3/MOSS2007 before WSSv4/SP2010

Review supported and unsupported upgrade methods

When you upgrade, you must upgrade to the same kind of installation: stand-alone to stand-alone, or

server farm to server farm. You cannot migrate from stand-alone to farm or vice versa during an in-place

upgrade process. However, either before or after you upgrade, you can change the size and scale of a

server farm to suit your requirements. In addition, if you perform a database attach upgrade, you can

attach the databases to a different installation type.

Physical topology guidance

The Microsoft SQL Server topology, in addition to your network, physical storage, and caching, can

significantly affect system performance. In planning your hardware, remember that for in-place

upgrade, the server or server farm that you upgrade must be running a 64-bit version of Windows

Server 2008 R2 or Windows Server 2008 with SP2. For server farms, 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.

Migrating from a stand-alone server to a server farm

If you want to change from a stand-alone server to a server farm, you can do so before you upgrade. To

do this, you must first create a new farm, and then move the databases from the stand-alone server to

the server farm.

Migrating from 32-bit hardware

You cannot perform an in-place upgrade from WSS 3.0 to SharePoint Foundation 2010 if you are on 32-

bit hardware. If you start in 32-bit, you must first migrate to 64-bit hardware.


Pre-Upgrade Steps

12

Perform pre-upgrade steps

Shrink the size of the environment before the upgrade

Use enumallwebs to collect information about each site

collection and site within a web application

Fix existing issues

Run preupgradecheck (stsadm –o preupgradecheck )

Remove orphaned sites

Optimize SQL databases

Upgrade customizations

Create a backup

Perform a full backup of the environment

As is always best practice before any upgrade, perform a full backup of the existing environment.

Shrink the size of the environment before the upgrade

Prior to upgrading the environment, determine what content can safely be deleted or archived out of

the environment. Eliminating unneeded content can improve the overall performance of the upgrade.

The following guidelines and tools may assist with cleaning up the environment.

Identify large site collections

Locate the largest site collections in the environment so that an analysis can be performed on what

content can be removed or archived from the site to free up the space. In addition to removing

potentially unnecessary files, consider moving the larger site collections (over 15 GB) to dedicated

content databases for best performance during the upgrade.

You can use the STSADM enumsites operation to get a list of every site collection in a given Web

application and return information about each site collection, including the approximate size of the site

collection and the site owner.

The following example shows how to use the STSADM enumsites operation:

stsadm -o enumsites -url http://portal >sites.xml

Note: Microsoft recommends to output the results to an xml file, and then view the results

as a table formatted list in Excel.

http://portal/


Note: For more information on how to use the enumsites operation, refer to http://technet.microsoft.com/en-us/library/cc262492.aspx.

Apply quota templates to large site collections

The use of quota templates in this situation is not to limit the size of site collections but to provide a

detailed report on the largest libraries and documents of that site. After applying a quota template to

the site collection, browse to /_layouts/stormon.aspx and review the detailed storage report. Large

amounts of unnecessary data can be caused by unrestricted version history on libraries.

Use the Site Auto-Confirmation Deletion feature

Enable a feature in MOSS 2007 that will alert all site collection owners to confirm whether or not they

are still using their site collections. Sites that are no longer needed can be deleted or archived; however,

make sure that you have an initial backup before performing this step.

Record blocked types

Blocked file types are not preserved during upgrade. Copy the list of blocked file types and save it in the

upgrade worksheet so you can reapply the settings after the upgrade. This list is not preserved even

during an inplace upgrade. In any upgrade you should make a copy of the list of blocked file types.

Create sites from the current SharePoint template files (STP)

The SharePoint migration process does not migrate your STP files. Therefore, you must create empty

files out of these STPs and migrate them, and then save them as templates back again after the

migration is done.

Fix existing issues

Fix existing issues in the SharePoint 2007 environment, or content databases, prior to the upgrade to

SharePoint 2010.

Run the pre-upgrade checker

The STSADM preupgradecheck operation performs a farm-wide validation to ensure that the

environment is ready to be upgraded to SharePoint 2010. The preupgradecheck operation does not

perform any repairs; instead, it provides a list of issues and possible remedies. Remediate the problems

reported before attempting to upgrade.

Run the STSADM enumallwebs operation

The enumallwebs operation was included in the MOSS post SP2 April Cumulative Update. This

operation is helpful in determining what templates, language packs, and orphaned sites may exist in a

given content database. For orphaned sites, the tool determines whether or not the site exists in the

sitemap table of the configuration database, which helps further troubleshoot such sites.

The syntax of the enumallwebs operation is as follows:

stsadm -o enumallwebs

http://technet.microsoft.com/en-us/library/cc262492.aspx


-databasename <database name>

[-databaseserver <database server name>]

Note: For more information on how to use the enumallwebs operation, refer to

http://technet.microsoft.com/en-us/library/dd789634.aspx.

Note: Microsoft recommends to output the results to a text file to make the results easier to read.

The following example shows how to use the STSADM enumallwebs operation:

stsadm -o enumallwebs -databasename WSS_Content -databaseserver DBSERV4 > info.txt

Remove orphaned items or sites

You can delete orphaned items or sites by using the STSADM operations deletesite, deleteweb, or

databaserepair. The first step is to locate orphans by running the following commands.

To find orphans by using databaserepair:

stsadm -o databaserepair -url http://portal -databasename WSS_Content

Note: This command is read-only. To delete the orphans, you need to specify the -deletecorruption parameter.

To find orphans by using enumallwebs:

stsadm -o enumallwebs -databasename WSS_Content -databaseserver DBSERV4 > info.txt

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:

stsadm -o deletesite -force

[-gradualdelete]

-siteid <site ID>


-databaseserver <database server name>

http://technet.microsoft.com/en-us/library/dd789634.aspx


Note: For more information on how to use the deletesite operation, refer to

http://technet.microsoft.com/en-us/library/cc261873.aspx.

The following example shows how to use the deletesite operation:

stsadm -o deletesite -force -siteid 91599D94-8654-3221-87CB-54378B61FEDB -databasename

WSS_Content -databaseserver SQLSERV1

Delete orphaned webs

The syntax to delete orphaned site collections by using deleteweb is:

stsadm -o deleteweb -force

-url <URL name>

-webid <Web ID>


-databaseserver <database server name>

Note: For more information on how to use the deleteweb operation, refer to

http://technet.microsoft.com/en-us/library/cc262877.aspx.

The following example shows how to use the deleteweb operation:

stsadm -o deleteweb -force -webid 138b8e7c-b228-3965-cf98-edcabc1bf321 -databasename

WSS_Content -databaseserver SQLSERV1

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>


[-deletecorruption]

The following example shows how to use the databaserepair operation:

stsadm -o databaserepair -url http://portal -databasename WSS_Content -deletecorruption

Optimize SQL databases

SQL database maintenance can improve the performance and operations of SharePoint databases.

Microsoft recommends performing the following database maintenance tasks before upgrading to

SharePoint 2010:




Check database integrity.

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.



In-Place Upgrade

14

In-Place Upgrades

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 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.


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)


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.


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.


Test the Upgrade

17

Test the upgrade

Build test farms

Test the upgrade approach


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?


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.


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.


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:


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?


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.


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.


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.


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.


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.


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


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.


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.


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.


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:

Mount-SPContentDatabase -Name <DatabaseName> -DatabaseServer <ServerName> -WebApplication

<URL> [-Updateuserexperience]

Where:

<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.


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

PSCDiagnostics_MM_DD_YYYY_HH_MM_SS_SSS_randomnumber.log, where:

MM_DD_YYYY is the date.

HH_MM_SS_SSS is the time (hours in 24-hour clock format, minutes, seconds, and

milliseconds).


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.


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


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


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.


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.


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.


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

http://technet.microsoft.com/en-us/library/ee720447.aspx

http://technet.microsoft.com/en-us/library/ee720447.aspx


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.


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.


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.


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:


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:


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?


How can you upgrade an SSP to a Service Application?

Why would you want to preview the visual upgrade?


General Administration and Service Applications


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


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.


Section 1: Central Administration

Introduction

This section introduces the various enhancements made to the user interface (UI) of Central

Administration in SharePoint 2010.

Objectives


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



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


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


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:


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.



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


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


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.


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.


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:




14. At the Windows PowerShell command prompt, type the following command:

New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -

ApplicationPoolAccount <ApplicationPoolAccount> -Port <Port> -URL <URL>

Where:

<Name> is the name of the new Web application.

<ApplicationPool> is the name of the application pool.

<ApplicationPoolAccount> is the user account that this application pool will run as.

<Port> is the port on which the Web application will be created in IIS.


<URL> is the public URL for the Web application.

Example:

New-SPWebApplication -Name "Contoso Internet Site" -ApplicationPool "ContosoAppPool" -

ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe") -Port 80 –URL

"http://www.contoso.com"


Lab 2A: Creating a Web Application


Site Collections

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


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.



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


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


To create a site collection through Windows PowerShell:




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.


Section 1 Review


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?


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


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



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:



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


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


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


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.



SharePoint 2010 offers the following improvements in the timer job management functionality:

Pause-resume capability


Throttling


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



• 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.


• 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


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.


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.


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.



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


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


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.


Section 2 Review


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?


Section 3: Service Applications

Introduction

This section introduces the concept of service applications and how to use them.

Objectives


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



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:

• 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


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


State Service

Visio Graphics Service

User Profile Service



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 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


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.



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


Consists of:

• Service

• Service machine instance

• Service application

• Service consumer

• Service database

• WCF Web service

• Application directories


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.


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.


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:

C:\Program Files\Microsoft Office Servers\14.0\Web Services\



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


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


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).



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


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


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.


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.



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


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



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


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


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.



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


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


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.


46. At the Windows PowerShell command prompt (PS C:\>), type the following command, and

then press ENTER:


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.


49. At the Windows PowerShell command prompt (PS C:\>), type the following command, and

then press ENTER:

Remove-SPServiceApplicationProxyGroupMember [-

Identity <SPServiceApplicationProxyGroupPipeBind>] [-

Member <SPServiceApplicationProxyPipeBind[]>]



At any point in time; you can customize the list of service applications associated with a Web

application. You can also modify which services belong to the default service application proxy group. By

default, all service application proxies are included in the default service application proxy group.

Custom proxy group

When you select a Web application and click Service Connections, you are presented with the option to

either use the default service application proxy group, or select [custom] from the drop-down list and

select only those service applications that you would like to associate with that Web application.

Note: You cannot use the custom proxy group for one Web application with a different Web application.

44


At any point in time, the list of services belonging to the

default service application proxy group can be

customized.

When configuring the Service Connections for a Web

application, either the default service application proxy

group can be used, or [custom] can be selected to

associate only specific service applications with that Web

application.

The custom proxy group for one Web application cannot

be used with a different application.


Customizing the default service application proxy group

SharePoint 2010 allows you to modify the groups of service applications associated with the default

service application proxy group; this will affect all Web applications consuming the default service

application proxy group. To change the service applications that belong to the default service

application proxy group:

50. Click default within the listing of Application Proxy Groups.

51. From Configure Service Application Associations, choose the service application proxies

which should be associated with the given Web application, as shown in the following

screenshots:


Handling multiple service applications of the same type

In MOSS 2007, only one of each type of service could belong to a single SSP. In contrast, MSF 2010

allows creating many service applications of the same type and associating them with a single Web

application; for example, you can associate two Business Data Connectivity Service applications with a

single Web application. Some features such as a Web Part may be able to take advantage of consuming

multiple service applications of the same type. For those features that do not need this functionality,

you must create one service application as the default, whenever there is more than one.



Just as service applications can be consumed individually within a farm, they can be shared and

consumed individually across farms. The following service applications can be consumed across farms:

Business Data Connectivity

Managed Metadata

People

Search

Secure Store

Web Analytics

The farm that contains the service application and publishes the service application so that other farms

can consume it is known as the publishing farm. The farm that connects to a remote location to use a

service application hosted by the remote location is known as the consuming farm.

To share services across farms:

52. Exchange trust certificates between the farms. In order to consume service applications

across farms, the server(s) hosting the service applications must authenticate the Web

applications that are trying to connect and use the services provided. In order to accomplish

this, certificates must be exchanged between farms as follows:

C. The administrator of the consuming farm must provide two trust certificates to the

administrator of the publishing farm: a root certificate and a security token service (STS)

certificate. STS is a claims-aware service and will be discussed in greater detail in the

47


Service applications can be consumed individually within or across

farms.

To share services across farms:

1. Exchange trust certificates between the publishing and consuming

farms.

2. On the publishing farm, publish the service application.

3. On the consuming farm, connect to the remote service application.

4. Add the shared service application to a Web application proxy

group on the consuming farm.

To control which accounts can be used by the current and other

farms to connect to the published service applications, add or

remove the accounts by clicking Permissions on the Manage

Service Applications page.


security module of this workshop. These certificates must be imported into the publishing

farm.

D. The administrator of the publishing farm must provide a root certificate to the

administrator of the consuming farm.

By exchanging certificates, each farm acknowledges that the other farm can be trusted.

53. On the publishing farm, publish the service application. On the farm on which the service

application is located, the administrator must explicitly publish the service application.

Service applications that are not explicitly published are available only to the local farm.

54. On the consuming farm, connect to the remote service application. After the publishing

farm has published the service application, the administrator of the consuming farm can

connect to that service application from the consuming farm if the address of the specific

service application is known.

55. Add the shared service application to a Web application proxy group on the consuming

farm. The administrator must associate the new service application connection with a local


Web application on the consuming farm. Only Web applications that are configured to use

this association can use the remote service application.

Permissions

A service application can control which accounts can connect to it. The account connecting to a Web

service is normally the application pool account backing the connecting Web application. By default,

local farm permissions will be enabled. You can add or remove accounts by clicking Permissions for a

particular service application on the Manage Service Applications page. This is useful when you are

trying to have other farms connect to the published service applications so that you can control which

accounts can be used not only by this farm but also by the other farms to connect.


Section 3 Review


Ans In SharePoint 2010, SSPs have been replaced by service applications. These applications act

independently without being grouped as an SSP. A service application can control which accounts can

connect to it.

Ans The GUI is simply a graphical representation of the Windows PowerShell command.

Ans A service application can control which accounts can connect to it.

49

Section 3 Review

What is the most important difference between SSPs and

service applications?

How can you manage service applications through Windows

PowerShell?

What is the role of a service application proxy?


Module 2 Summary

In this module, you learned about the various changes made to the Central Administration UI in

SharePoint 2010 and how to work with the new look and feel. You learned how to create Web

applications and site collections, both of which can be created through either Central Administration or

Windows PowerShell.

The module also explained the changed and improved management functions for timer jobs, including

Scheduled Jobs, Running Jobs, Job History, Job Definitions, pause-resume capability, Timer Service

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.


Module Patch Management


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


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.


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


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.


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:


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.


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-


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.


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.



7


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.


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


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.


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.


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.


Note: You can attach content databases to a SharePoint farm by using the Mount-

SPContentDatabase Windows Powershell cmdlet.


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?


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?


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


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.



14


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


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.


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


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.


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.


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.



17


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.


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:


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


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?


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.


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


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.


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.


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


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.


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.


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.


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.


68. Switch routing or DNS back to the original fully upgraded farm.



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


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


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.


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.


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.


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:


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


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?


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?


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.

http://technet.microsoft.com/en-us/sharepoint/ff800847.aspx