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